人分为很多种
1.现实型的员工 - 动手能力强,思考能力差; -程序员;擅长工具;
2.研究型的员工 - 动手能力差,思考能力强,抽象能力强; -系统分析,架构师;擅长事,物;
3.传统型的员工 - 会压抑自身的个性,以职位及工作决定性格;-会计,出纳,金融顾问;擅长事;
4.进取型的员工 - 个人冲劲特别足,有时间就会充实自己;-销售,经理;
5.社交型的员工 - 喜欢和人打交道; -经理;擅长人;
6.艺术型的员工 - 喜欢出头,喜欢成为焦点;
- 静态数据准备
数据准备阶段要求客户方提供完整的基础档案，但在手工作业模式下往往没有统一的分类编码体系，甚至没有统一的名称很难如期准备完整的数据，即便花费了大量的时间将数据整理完毕，其正确性也难以保证，导致不断出现重复，核对修改数据，这样经常使的原计划在一周内完成的数据准备工作在一个月后才能完成，而实际的业务数据已经发生，这给后期的业务处理带来很大的麻烦，导致项目总是与旧系统“并行”或者”模拟运行“，无法实现按计划顺利切换。
数据准备环节是项目能否成功实施的关键之一
- 不具备开始实施的基本条件,仓促启动项目
项目启动前客户经常一再强调时间的紧迫，最好是马上派人来培训、实施。实施顾问到达现场后才发现培训条件不具备，客户对实施的认识基本没有。实施人员到现场培训客户才发现，原来还要准备这么多的基础数据和期初数据，“看来这不是一两天能完成的，你们先回去，等准备好了再开始实施把。”在这种准备不足的情况下启动项目必然会造成大量的重复劳动，浪费人力资源。
- 需求扩大
客户经常会认为软件可以解决一切问题、代替管理，而这个问题能不能解决，项目的实施范围、目标是什么都不清楚。项目越做越大，小型做成了中型，中型做成了大型，大型做成了超大型，都是需求扩大导致的不良结果。项目经理应该将重点放在对项目的控制方面，需求一扩大，就如同河堤出现了缺口，会越来越大，失去控制。
项目经理一定要坚持一个最基本的原则：一般不要轻易答应这样的要求——你给我们做个什么。今天一个，明天肯定会有第二个，后天会有第三个……。只要你答应一次，就会一个一个接踵而至，永远没有结束的时候，项目肯定会失去控制，也不可能最终验收。为了把需求控制在一定的范围，要避免与一般业务人员交谈，树立顾问的权威和信心，要以专家的姿态与客户接触。
对于中小型项目，把需求控制在一定范围内，一定要让客户明确实施的范围和目标。具体就是，关于这个项目，哪些事情我们能做或应该做，哪些事情我们不能或不应该做。
问：实施时候，需求也是拖延我们实施很多时间的重要因素之一。客户迟迟不上线，不上线我们就无法验收。那我们该怎么办呢？
答：首先，你们要有一些策略的调整。你们是以什么为验收标准。以客户上线为验收标准是不科学的，因为什么算上线定论不一。我们推荐做一件事情验收一块。
如安装配置完了。验收一块。基础数据完成了，验收一块。每次培训后，验收一块。每次考试后多少人上岗了，验收一块。上岗多少人，多少天算实施结束，不同的时间有不同的费用，所以我们就不用担心客户拖延我们的时间，其实他是在消耗在他的钱，所以他肯定着急。否则就是你急他不急。
对于需求，我们不限制客户提需求。因为需求真是公说公有理，婆说婆有理。很多客户对于过去的操作习惯而不接受现有操作方式，需要改回去。既然又回到了过去，那么我们上新的系统又有何意义？但这样讲不能解决问题。
正确的解决方法是：
1：首先和客户领导（不是CIO）在实施前就说清楚。上线使用肯定会遇到用户想把功能改回去的现象。首先取得客户领导的支持。这样在用户反对抱怨的时候还能继续开展下去。
2：提需求，必须是真正操作软件的用户。谁操作哪块谁提哪块的需求。
3：而且没使用的时候，不能提需求。你用都没有用，你什么都不了解你就提需求？而且这样的需求往往是不成熟的，到应用得心应手的时候发现还得改。企业信息化总是从浅入深的，所以需要功能的细节层次也是每个时间阶段不一样的。
4：提需求不能见一个提一个，随时随地提。提需求必须以1周或2周或1个月为一个需求周期。因为，这样的周期便于客户使用深入，有时客户使用熟悉后就觉得需求不必要了，而且这个周期给我们安排修改任务也有好的安排时间。
5： 提需求，要写上需求的模块，提需求的部门和人和人的职位，提需求的时间，需求的内容。然后把需求内容做成DOC标准格式文件，首先送给计算机室人审核。因为最终用户提的需求站的高度仅限于自己需要，所以计算机室人员有一个综合的衡量。每个需求计算机室人员要写上需要的限制时间，如在1个星期内必须改好或必须在2天内改好。不同的修改周期要求会打乱开发部的任务安排，所以需要费用的补偿，而且开发有工作量，当然也需要费用。所以不同修改天数限制有不同的开发费用。一提到钱，客户就必须自己思考一下了。否则，需求任意提，双方没有相互约束的条件了。
- 客户重视项目实施 缺乏关系用户参与，客户方人力资源难以保证
项目负责人必须全程参与项目实施，客户方需要由专人负责人员协调、方案讨论、需求确认、计划审定并与实施顾问一起推动项目实施。但是，客户只注重结果，经常要求顾问怎么做，不听实施顾问的建议和意见，而实际结果恰恰与预期的截然相反；或者是因为缺乏人员配合，项目不能继续进行；或者是项目运行后，企业自己根本不能负责维护和后期的优化，客户认为项目实施是软件供应商的事，他们只要学会使用就可以了，但是这个系统最终是要企业来维护和优化的。
项目实施初期有大量的工作需要项目组落实，而客户方往往因为业务、人员的原因延期。项目经理要定期进行阶段工作总结，分析存在的问题，总结项目实施的阶段性成果，制定下个阶段的实施计划，争取企业管理者的重视和信任。
取得客户方的信任和重视是项目顺利实施的基本保证，各项任务能按时完成，实施方与客户方共同推进，大家一起解决问题，项目实施自然会向好的方向发展。
- 培训效果急于求成，培训不够正规，培训环境、人员、课件因陋就简，培训的效果也就大打折扣
客户对软件的功能、流程及设计思想认识不足，后期的沟通协调、方案设计、流程设计还照搬手工模式，或坚持手工模式，不能接受新系统带来的变化，项目经理的方案便难以实施。因培训效果不佳，引起后期数据输入错误太多，实施顾问不得不花费大量时间核对数据，纠正数据错误。
好的培训有助于客户真正理解软件的处理流程和设计思想，接受新系统带来的变化，帮助实施顾问设计优化的方案。关于项目管理的培训可以帮助我们规避项目风险。
培训一定要让客户了解实施的整个过程以及各个阶段的内容和目标，要让客户明白实施能给客户带来的价值是将软件先进的设计思想与企业的实际结合，能够帮助企业培养一批既懂业务又懂计算机技术的复合型人才。培训效果不好的项目，客户满意度肯定不高。
- 产品与技术软件
产品与技术软件产品总是存在一些小的、细节方面的问题，有的客户可以通过变通的办法解决，有的客户就根本无法接受变通的方案。
但是我们知道标准的软件产品根本不可能解决这样的问题，所以实施顾问要尽快拿出一个解决方案，因为这个问题不解决业务就无法处理，这个“抽单”问题一直拖延着项目进度。实施顾问将这个问题反映给实施经理、技术顾问和技术总监，技术总监召开项目分析会议，在征求实施顾问、实施经理、技术顾问和客户的意见后决定：在保持标准软件的数据库结构和总体构架不改变的前提下，对“抽单”业务进行客户化开发。短短三天时间，“抽单”的问题解决了，项目继续按照计划进行，随着这个问题的解决，客户和实施顾问也重新树立了信心。
产品能力是一名合格的顾问必须具备的最基本的能力，对产品的每一个细节都了如指掌，这样才能设计出优化的方案，减少项目实施的风险。更高的要求是技术，通过技术手段解决一些具体问题，如通过数据导入、编写触发器、客户化开发来解决一些实际问题。
- 销售人员不切实际的承诺
销售人员在承诺之前要听取实施顾问的意见，对与有利于销售而且实现起来不是很困难的要求可以答应，但是根本无法实现的要求一定要谨慎处理。你只要答应了就得实现。我们要保证客户的成功应用，销售与实施相互理解，达到销售与实施的良性互动，这样实施才能更好地服务于销售、服务于客户。
- 项目实施过程不必要的与手工并行阶段
客户会要求软件系统与手工并行几个月，然后再切换到新系统，想法和做法都没有错，但是结果却往往事与愿违，项目一直并行，无法切换，带来了大量的重复工作。很多企业的手工业务极不规范，账账不符、账实不符，而软件系统要求极为严格，这些不规范的业务在软件中根本不能处理，为了取得和手工一致的结果往往是调账，在数据库中直接修改数据，这样，软件的严谨性、科学性根本不能保证。人机并行给业务人员带来的不是工作量的减少而是增加，这样的软件客户肯定不能接受，而切换的条件也不具备。
我们主张模拟运行，通过完整的少量的数据测试、验证方案的正确性，正确的输入获得正确的结果就可以了。这样我们就可以把注意力转移到如何优化、如何达到最佳效果上来。
我们要说服客户，我们的最终目标一定是正式运行而不是并行或模拟运行，要敢于放弃旧的系统才能拥有新的系统。
- 实施顾问及客户化方案
实施顾问经验不足，对产品的理解不够全面，缺少相关行业的实施经验也会导致客户化方案无法实施，参数与选项不适合企业，很多业务无法处理，客户需求难以得到满足。
实施顾问在经验不足的情况下一定要通过各种手段和方式捕捉客户需求，对需求要反复推敲，只有准确把握客户需求的前提下才能设计出优化的适合客户的方案。设计的流程和方案要经过测试，逐一确认。交易数据和流程相互之间存在较复杂的关联，要系统地、全面地分析问题，忌“只见树木不见森林”的方案。为了保证方案的合理性，应组织顾问按照专家决策方法进行决策，顾问各自发表意见，选择一个最佳方案。
- 项目文档管理
