1. MRP到MRP2到ERP到MES为什么是逐步发展的
转载，供参考。
软件开发项目进度控制
一、影响软件开发项目进度的因素
要有效地进行进度控制，必须对影响进度的因素进行分析，事先或及时采取必要的措施，尽量缩小计划进度与实际进度的偏差，实现对项目的主动控制。软件开发项目中影响进度的因素很多，如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施中，人的因素是最重要的因素，技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。常见的问题有以下几种情况：
1、80-20原则与过于乐观的进度控制
80-20原则在软件开发项目进度控制方面体现在：80％的项目工作可以在20％的时间内完成，而剩余的20％的项目工作需要80％的时间。这个80％的项目工作不一定是在项目的前期，而可能是分布在项目的各个阶段，但是剩余的20％左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉，使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。有些领导看到软件交付给用户了，就一块石头落地“总算交差了”，同时又可能撤出一些被认为不必要的人力资源。但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。这样的结果是拖延了后期的工作，同时如果软件还不成熟的话，会给用户造成不好的影响。
2、范围、质量因素对进度的影响
软件开发项目比其他任何建设项目都会有更经常的变更，大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧，用户是想改就改，造成需求的蔓延，项目经理有时还不知如何拒绝，加上要说“我能”的心理因素，一般都会答应修改。这样集少成多，逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了，但经检验其质量没有达到要求，则必然要通过返工等手段，增加人力资源的投入，增加时间的投入，实际上是拖延了进度。不管是从横向或纵向来看，部分任务的质量会影响总体项目的进度，前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响
资源，最主要的还是人力资源，有时某方面的人员不够到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。还有一个很重要的资源，就是信息资源，如某些国家标准、行业标准，用户可能提供不了，而是需要去收集或购买，如果不能按时得到，就会影响需求分析、设计或编码的工作。其他资源，如开发设备或软件没有到货，也会对进度造成影响。
预算其实就是一种资源，它的变更会影响某些资源的变更，从而对进度造成影响。
4、低估了软件开发项目实现的条件
低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。软件开发项目团队成员，有时甚至是企业的高级项目主管也经常低估项目技术上的困难。低估技术难度实际上也就是高估人的能力，认为或希望项目会按照已经制定的乐观项目计划顺利地实施，而实际则不然。软件开发项目的高技术特点本身说明其实施中会有很多技术的难度，除了需要高水平的技术人员来实施外，还要考虑为解决某些性能问题而进行科研攻关和项目实验；
其次，低估了协调复杂度，也低估了多个项目团队参加项目时工作协调上的困难。软件开发项目团队成员比较强调个人的智慧、强调个性，这给项目工作协调带来更多的复杂度。当一个大项目由很多子项目组成时，不仅会增加相互之间充分沟通交流的困难，更会增加项目协调和进度控制上的困难。
另外，企业高级项目主管和项目经理也经常低估环境因素，这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。低估这些条件，既有主观的原因，也会有客观的原因。对项目环境的了解程度不够，造成没有做好充分的准备。
5、项目状态信息收集的情况
由于项目经理的经验或素质原因，对项目状态信息收集的的掌握不足，及时性准确性完整性比较差。另外其它一些原因也会造成这种现象。某些项目团队成员报喜不报忧，不希望别人知道自己工作的不好的情况，例如软件程序的编制，可能会先编制一些表面的东西，现有界面，看起来好像完成任务了，实际上只是一个“原型系统”或演示系统。给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况，将对项目的进度造成严重的影响。当然，如果出现这种需要时时刻刻都互相提防的氛围，管理人员就应该从管理的角度，从制度的角度检讨一下，进行改进，让大家实事求是地进行沟通。温伯格说:“无论你多么聪明，离开了信息，对项目进行成功的控制就是无源之水、无本之木。”
6、执行计划的严格程度
没有把计划作为项目过程行动的基础，而是把计划放在一边，比较随意去做。例如对于项目团队内部沟通或外部沟通，在计划中要说明清楚人员、周期、方式、方法，不能遗漏，但在实际项目过程中，可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。若项目计划本身有错误，执行错误的计划肯定会产生错误。如，计划制订者在计划系统框架设计考虑上的错误、进度安排上的失误等。实际的项目实施中，除了这种错误之外，还可能因为项目执行上的错误，造成项目的麻烦。例如，项目的客户及其他项目干系人没有及时为项目中出现的情况采取必要的措施或者所采取的措施的不适合具体的情况、没有效果或者有副作用等。另外，如果在项目中的某项工作（如某个子系统或模块、组件）被转包给第三方开发后，不能进行有效的管理，也会造成进度上的延误。
7、计划变更调整的及时性
渐近明细是项目的特点，特别是对于软件开发项目，并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些，随着项目的进展，特别是需求明确以后，项目的计划就可以进一步的明确，这时候应该对项目计划进行调整修订，通过变更手续取得项目干系人的共识。计划应该随着项目的进展而逐渐细化、调整、修正。没有及时调整的计划或者是随意的不负责任的计划的项目是难以控制的。在高技术行业，日新月异是主要特点，因此计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式，随着项目的进展进行不断细化、调整、修正、完善。对于较为大型的软件开发项目的工作分解结构可采用二次甚至多次 WBS 方法。即根据总体阶段划分的总体 WBS ，需求调研阶段结束、概要设计完成后专门针对详细设计或编码阶段的二次 WBS 。由于需求的功能点和设计的模块或组件之间并不是一一对应的关系，所以只有在概要设计完成以后才能准确地得到详细设计或编码阶段的二次 WBS ，根据代码模块或组件的合理划分而得出的二次 WBS 才能在详细设计、编码阶段乃至测试阶段起到有效把握和控制进度的作用。有些项目的需求或设计做得不够详细，无法对工作任务的分解、均衡分配和进度管理起参考作用，因此要随着需求的细化和设计的明确，对项目的分工和进度进行及时的调整，使项目的计划符合项目的变化，使项目的进度符合项目的计划。
8、未考虑不可预见事件发生造成的影响
假设、约束、风险等考虑“不周”造成项目进度计划中未考虑一些不可预见的事件发生。例如软件开发项目还会因为项目资源特别是人力资源缺乏、人员生病、人员离职、项目团队成员临时有其他更紧急的任务造成人员流动等不可预见的事件对项目的进度控制造成影响（即项目按时完成是基于如下假设：人力资源不会缺乏、人员不会生病、人员不会流动）。企业环境、社会环境、天灾人祸等事件对项目的进度控制造成影响。对项目的假设条件、约束条件、风险及其对策等对于进度的影响在项目计划要进行充分的考虑，在项目进展过程中也要不断地重新考虑有没有新的情况，新的假设条件、约束条件、潜在风险会影响项目的进度。假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成；约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如牺牲进度、质量等等；假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性、造成的影响、采取的措施。实际上像没有考虑人的疾病、人员流动这些情况本身也不是什么问题，因为任何人都不可能把所有以外的情况都考虑完整，实际上也没有必要。但有些诸如下班或节假日的加班时间都被安排用于项目工作的情况就会造成更多的项目不确定性。在可能的情况下当然要对所有可能情况都做到有备无患，但是有的时候也要冒一定的风险，同时对于风险的防范也需要考虑如果防范的成本大于风险本身造成的损失和影响，则这种防范是没有必要的。
9、程序员方面的因素对进度的影响
程序员方面有两种常见的心态影响了进度的控制：一是技术完美主义、二是自尊心。
技术完美主义的常见现象是，有些程序员由于进度压力、经验等方面的原因，会匆忙先做编码等具体的事情，等做到一定程度后会想到一些更好的构思，或者看到一些更好的技术的介绍，或者是觉得外部构架可以更加美化，或者是觉得内部构架可以更加优化，这样他们会私下或公开对软件进行调整，去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的目标并没有影响，相反可能带来不确定的隐患。这种做法不是以用户的需求为本、或以项目团队的总体目标为本，可能对软件开发进度造成较大的影响。
自尊心的常见想象是，有些程序员在遇到一些自己无法解决的问题时，倾向于靠自己摸索，而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室等方式匿名地向别人求教。如果运气好会很快地解决，否则要花很多实践摸索。而如果向周围的人求教，可能摸索几天的问题别人早就解决了。
10、未考虑软件开发过程的循环、迭代特性
对软件开发的各个过程分类过于精细，制定进度计划时各项工作过于紧凑、没有弹性，造成的后果是，定期提交项目进度阶段报告的制度只有在表面上起到效果，按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”，强行的规定会使人产生一些错误的认识：如在项目计划中“规定”某个时间只能做某某类别的事情，那么严格执行的后果就是编码阶段就不能修改文档；另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了，而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误；如果上下阶段是同一个人，就可能非正式地修改上一阶段的错误，但占用的时间和精力却是下一阶段的，并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是，用户在合同中限定了提交软件系统的时间，实际上这个时间对完成项目任务来说是远远不够的，但计划只能按照合同来进行，所以要不用户让步，要不只能按照时间的约定提交实际上还未完成的软件系统，完成系统的安装，但这时候的“完成阶段任务”只是一个表面现象，系统虽然安装了，但可能是没有经过严格彻底测试的，也可能是只完成了部分的功能，省略了某些功能，有些是整块功能省略，有的是省略了某些功能的某个过程，如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能，而是实现了比较粗糙的功能。这样，系统交付并不意味着项目的完成，而在项目交付之后还要花更多的时间。
11、其他因素
以上这些因素是影响项目进度的几个主要方面，除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素，这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等，都会对项目进度造成影响，这是因为由于软件开发的特性。因为篇幅有限无法一一列举，只能在此分析一些常见的因素。
不可否认，软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目，其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验，虽然我们说，顾客是上帝、以顾客为中心，但并不是说我们要把主导权交给他们，而关键是我们如何去主导、引导、把握。因此，项目控制的好坏与相关人员人际关系方面的经验也有关系。
尽管存在很多不可控的因素，我们的任务是首先分清哪些是可以控制的，哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域，减少不可控的领域，二是不要在“不可控”上花太多时间，而是多花一些时间把可控的工作控制好，做好防范措施，减轻不可控因素对项目进度的影响。
项目进入实施阶段后，项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系，需要项目经理去平衡。
二、项目进度控制的目的
项目进度控制和监督的目的是：增强项目进度的透明度，以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。
1、根据计划进行监控
项目控制的第一个目的是根据计划对项目的各项活动进行监控，即根据已经制定并取得共识的软件开发项目计划来监控项目的实际表现和进度。为此应该根据项目计划来监控项目计划参数的实际值，这些参数包括进度表、项目成本、工作量、工作产品和任务的属性、使用的资源、项目成员的知识和技能；根据项目计划来监控项目团队所作的承诺是否已经或可能兑现、原来的确定的风险是否可以避免或减少损失，是否有新的风险出现；根据项目计划来收集、管理、使用项目数据；根据计划监督项目干系人的参与情况，监控各项任务承担人的参与活动；定期进行必要的进度评审，确定项目是否存在重大偏差、跟踪变更请求和问题报告直到变更或问题得到解决；在项目的里程碑对项目的成果进行评审。
2、管理纠正和预防措施
项目控制的另外一个目的是管理纠正和预防措施，即当项目进度或者结果已经或即将与计划有严重偏差时，对需要采取的纠正或预防措施进行管理。为此应当收集并且分析项目进行中可能存在的问题，并以此确定解决这些问题的纠正或预防措施；对已经确定的问题采取纠正和预防措施；监控要实施的纠正和预防措施，分析措施采取以后的结果，判断这些措施的有效性，确定和记录纠正与计划结果存在偏差的问题而采取的必要且合适的措施。
项目执行过程中仅仅靠最初建立的一份“完善”的基准计划是不够的，最好的计划也未必会一直有效。根据项目任务渐进明晰的特点，特别是软件开发项目的特点，在项目进行过程中，肯定需要在适当和必要的时候对项目进行变更控制，这种控制过程包括定期搜集有关项目进展情况的信息，把实际进展情况与计划进展情况进行对比；如果实际进展情况比计划进展情况有差距，或可能会有差距，就应当采取纠正或预防措施。变更控制应当在项目期间定期进行，这里所说的变更控制不一定要进行真正的变更，而是说要定期对变更进行控制。
如果在项目生命周期内的某一时间点，把实际进度与计划中约定的进度相比对，显示出项目已经延误或即将延误、超出预算目标或不符合质量要求，就必须采取纠正或预防措施使项目回到正轨上来，重新符合计划的安排要求。在已做出执行纠正或预防措施的决定之前，应评估一下纠正与预防措施的有效性和无副作用性，以确保纠正措施使项目回到项目的工作范围、时间和预算约束内，并对项目的其他目标不会造成太大的影响。
3、在各种项目目标中进行平衡
如果经过评估确定项目确实已无法控制，就应当下定决心以牺牲软件功能范围、工作成果范围（如某些中间文档）、成本预算、进度计划或软件质量中的某一项目标为代价，来保住项目最重要的那些目标，在各种项目目标中进行平衡，最终确定一个最合适的解决方案。有效的项目控制的关键是定期及时测量实际进程，并与计划进程相比较，如有必要就立即采取纠正或预防措施。指望不采取纠正和干预措施，问题就自行消失的想法是不现实的。问题越早发现就越好改正，造成的影响和损失越小。问题越提前发现就越好采取预防措施，可以用最小的代价避免造成损失。基于项目实际进展情况，就有可能准确预测项目进度计划和成本预算的实施情况，以便顺利完成项目。如果这些项目参数超出项目目标的限制范围，就必须马上采取纠正措施；如果发现这些项目参数有超出项目目标的限制范围的趋势，就必须马上采取预防措施。
软件开发项目实施中进度控制是项目管理的关键，若某个分项或阶段实施的进度没有把握好，则会影响整个项目的进度，因此应当尽可能地排除或减少干扰因素对进度的影响，确保项目实施的进度。
三、软件开发项目常用进度控制措施
1、项目进度控制的前提
项目进度控制的前提是有效地项目计划和充分掌握第一手实际信息，在此前提下，通过实际值与计划值进行比较，检查、分析、评价项目进度。通过沟通、肯定、批评、奖励、惩罚、经济等不同手段，对项目进度进行监督、督促、影响、制约。及时发现偏差，及时予以纠正；提前预测偏差，提前予以预防。
在进行项目进度控制时，必须落实项目团队之内或之外进度控制人员的组成，明确具体的控制任务和管理职责。要制定进度控制的方法，要选择适用的进度预测分析和进度统计技术或工具。要明确项目进度信息的报告、沟通、反馈、以及信息管理制度。
项目进度控制应该由部门经理和项目监控人员共同进行，之所以需要部门经理参与，是因为部门经理负责项目一般要负责一定人事行政的责任，如成员的考核、升迁、发展等。他们只有通过软件开发项目才能更好地了解项目成员，项目也只用通过对他们有切身利益的管理者参与管理才会更加有效。
2、项目进度控制主要手段
项目计划书：作为项目进度控制的基准和依据，项目负责人负责制作项目计划书。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控，如果由于某些原因阶段成果提前或延后完成，项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的，应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施，在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整，以保证基准和依据的新鲜性、有效性。
项目阶段情况汇报与计划：项目负责人按照预定的每个阶段点（根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等）定期在与项目成员和其他相关人员充分沟通后，向相关管理人员和管理部门提交一份书面项目阶段工作汇报与计划，内容包括：
a、对上一阶段计划执行情况的描述
b、下一阶段的工作计划安排
c、已经解决的问题和遗留的问题
d、资源申请、需要协调的事情及其人员
e、其他需要处理的问题
这些汇报将存档，作为对项目进行考核的重要材料。
在计划制定时就要确定项目总进度目标与分进度目标；在项目进展的全过程中，进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防；协调项目参与人员之间的进度关系。
在项目计划执行中，做好这样几个方面的工作：
检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据，积累资料，总结分析，不断提高计划编制、项目管理、进度控制水平。
做好项目计划执行中的检查与分析。通过检查，分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。
及时制定实施调整与补救措施。调整的目的是根据实际进度情况，对项目计划作必要的修正，使之符合变化的实际情况，以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周，或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑，计算调整后的各时间参数、关键线路和工期。
3、进度控制内容
从内容上看，软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。组织管理包括这样几个内容：
（1）项目经理监督并控制项目进展情况；
（2）进行项目分解，如按项目结构分，按项目进展阶段分，按合同结构分，并建立编码体系；
（3）制订进度协调制度，确定协调会议时间，参加人员等；
（4）对影响进度的干扰因素和潜在风险进行分析。
技术管理与人员管理有非常密切的关系。软件开发项目的技术难度需要引起重视，有些技术问题可能需要特殊的人员，可能需要花时间攻克一些技术问题，技术措施就是预测技术问题并制订相应的应对措施。控制的好坏直接影响项目实施进度。
在软件开发项目中，合同措施通常不由项目团队负责，企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。项目经理应该及时掌握这些工作转包的情况，按计划通过计划进度与实际进度的动态比较，定期向客户提供比较可靠的报告等。
软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。这些信息主要是：预测信息，即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测；决策信息，即对实施中出现的计划之外的新情况进行应对并做出决策。参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人；统计信息，软件开发项目中统计工作主要由参与项目实施的人员自己做，再由项目经理或指定人员检查核实。通过收集、整理和分析，写出项目进展分析报告。根据实际情况，可以按日、周、月等时间要求对进度进行统计和审核，这是进度控制所必须的。
4、不同阶段的项目进度控制
从项目进度控制的阶段上看，软件开发项目进度控制主要有：项目准备阶段进度控制，需求分析和设计阶段进度控制，实施阶段进度控制等这几个部分。
准备阶段进度控制任务是：向业主提供有关项目信息，协助业主确定工期总目标；编制阶段计划和项目总进度计划；控制该计划的执行；
需求分析和设计阶段控制的任务是：编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划，控制相关计划的执行等。
实施阶段进度控制的任务是：编制实施总进度计划并控制其执行；编制实施计划并控制其执行等。由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。
为了及时地发现和处理计划执行中发生的各种问题，就必须加强项目的项目的协同工作。协同工作是组织项目计划实现的重要环节。它要为项目计划顺利执行创造各种必要的条件，以适应项目实施情况的变化。
5、关于进度落后时的“赶工”措施
进度落后的情况下，有几种措施来弥补，如加人、加班、加激励等等，这些都是增加资源而又未必会见效的方法。根据Brooks原则，在某些项目进度延迟的情况下增加人手，有可能会使项目的进度更加延后。因为对于新加入本项目的员工来说，对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加，可能会使项目的工作效率急剧下跌。而加班造成的疲劳会再次使工作效率降低。增加激励会造成工作成本却不断的向上攀升。这些措施并不是完全不可取，而是项目经理要考虑适度原则。最好是要全面分析项目进度延迟的原因，如果确实是不合理的项目交付时限要求，就应当通过沟通变更为合理的项目时限要求，以免因为这样一个不合理的时限要求造成对软件质量或团队成员心理上的负面影响，最终导致项目最终的失败。否则应从技术、团队成员心态、环境等方面查找原因，找到提高效率、加快进度的方法。
2. 怎样才能成为一名成功的MES实施顾问
辛辛苦苦熬了几个月的通宵，终于确立了MES需求，规范了工作流程，系统配置也完成了，正准备按部就班MES系统上线时，企业用户突然改变了需求，不想这么做了，提出了新的需求。
对于MES实施顾问来说，正如晴天惊雷，这也是所有MES顾问最感到恐怖的事情。因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。
1、需求变更：迁就or拒绝?
从MES项目立项开始，需求就是MES实施顾问的心头之痛。随着对MES的深入认识、项目环境的变动，企业内外部多种因素都可能使客户对MES的需求不断改变。如果不能有效处理这些需求变更，项目实施进度必将一再调整，上线日期也会随之一再拖延，项目成员的士气也将越来越低落，严重的还会直接导致MES项目失败。
需求变更，本应是客户的权力，但也是实施顾问的为难之处。如果确需变更，当然要满足客户需要。问题是不能让变更权力滥用，把一些无关痛痒的变更宠惯养成堂而皇之的变更。例如，我曾经在某MES项目中属于“谦虚型”，对于客户提出的变更，无论大小都给予解决，客户对此非常满意。然而，项目进度却拖得很长，项目一再延期。相比之下，在另一个项目上我显得稍有些“盛气凌人”，对于客户提出的需求变更，大多都不予理睬，客户对此不是很满意。不过，该项目的进度控制得较好，基本能按期完成项目。
按后一种“盛气凌人”的做法，对客户的要求一概不理，自顾自地按照最初的需求和计划实施，很可能会由于没有用户的参与，使得MES系统与用户的需求相差甚远，导致验收通不过，收不回尾款而使公司利益受损。对于客户来说，达不到需求的满足也浪费了投资。事实上，客户不满意，则项目就不算成功，实施顾问辛勤劳动最后就只能落得个“没有功劳，只有苦劳”的份。
但按前一种“谦虚型”做法，完全顺着客户的意见走，客户满意度就一定会高吗?其实也不一定。由于需求变更会带来工作量的大量增加，甚至可能会出现大量的无效劳动。而且，频繁变动的需求也会导致实施质量下降，留下许多隐患。因此，一味的迁就用户将会使进度一拖再拖，实施方案一改再改，变更越来越多，士气越来越疲，公司越来越不满意，用户越来越急。到最后，实施顾问会发现这个项目已经成为了一个“不可能完成的任务”。
2、需求变更为什么总是做不完?
在MES实施过程中，实施顾问所要面对的将是一系列和多方面的考验。经常发生而又最令人头疼的恐怕就是需求变更了。客户变更需求是MES项目与生俱来的特性，也是一个无法避免的事实。需求变更的表现形式是多方面的，如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。它会导致MES实施过程中成本增加、进度拖延等风险，而且越往后的变更产生的风险将越大。
以笔者参与的多个MES实施项目的实际经历来看：需求变更泛滥是非常可怕的事，尤其是到了项目实施后期，客户不断对移交的MES系统提出修改意见，甚至有时刚刚重新完成的更改，客户又要求改回去或改成另一种模式。需求变更越来越多，实施顾问只能疲于应付。“无底洞”是大部分实施顾问进行MES项目的共同感觉。
实施顾问作为项目的承担者，在规定时间内利用有限资源保质保量的完成项目，让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗? 我们分析一下出现需求变更的根源：
① 合同签订马虎，没有真正明白客户需求
签订合同时缺乏对客户需求认真对待，导致需求描述不清，为后期的实施工作带来困惑。MES销售顾问为使客户能够快速的签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，往往是销售顾问一看“应该”只是一个小小的修改，没有太大的影响，所以直接答应能变更。
该问题的关键是合同签署的太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚，后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围，可以为以后各项实施工作的开展奠定深厚的基础。
② 研时没有深入理解客户需求
在MES上线前的需求调研分析阶段，项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进行。更严重的是，实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案，没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导一拍脑袋提出新的需求时，实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分，双方对需求的理解就会产生差异，就会导致移交MES系统时才使问题暴露出来，客户只能频繁的提出需求变更。
③ 没有明确的需求变更管理流程
没有明确的需求变更管理流程，就会使需求变更变得泛滥。并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。
比如MES界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改没有严格把关流程，有些小需求看起来工作量不大，但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。
④ 没有让客户知道需求变更的代价
对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对实施顾问的辛苦就会难以体会。在评估代价过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗?”。
3、如何有效控制需求变更?
需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。例如授权、审核、评估和确认，在实施过程还要进行跟踪和验证。有句通俗的话说得非常好：“需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”
用户需求的变更总是不可避免的，所以我们要以积极的心态去接受和控制用户的需求，而不仅仅是埋怨。对待客户频繁的需求变更，应采取有效办法应对，避免事态蔓延，不让客户养成随意变更的毛病。
① 合同约束
需求变更给MES实施带来的影响是有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。
虽然MES项目合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。有一个笑话，就是许多销售顾问都开玩笑说他们都是清政府。为什么是清政府?清政府的特点之一就是丧权辱国的条约太多。
② 建立需求变更审批流程
要明确需求变更审批环节、审批人员、审批事项、审批流程等。目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。
有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响，以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有书面材料，当用户发现由于业务变化而引起的需求变更，需要提出书面申请。这样对所有的变更，双方的项目负责人都能做到心里有数。而且用户在递交书面变更申请时比较慎重，一般都在内部经过讨论后进行，这样减少了因用户内部看法不同导致的反复变更。
③ 对于零星变更，集中研究、批量处理
每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目运行的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划，注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱的变更不做，保大局弃小变。
④ 评估各种需求变更的影响
客户的需求是永远不会满足的，可能一天一个样,为了达到控制频繁的需求变更。需要将需求变更后产生的成本进行评估与量化，形成分析报告提交双方领导。否则，一味的妥协只会让项目进一步恶化，实施顾问需要掌控客户及公司的进度成本，把客户的每一次需求变更进行成本分析。确认哪些需要收费变更，哪些可以免费配合客户。这样既可以维护客户关系，又不致造成公司无谓的损失。
⑤ 确认客户是否接受变更的代价
要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果，通过与客户的协商，项目组可能会得到回报或者即使没有回报也不会招致公司和客户双方的埋怨。
如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更，更不是所有的需求变更都需要立刻修改。客户一般对MES不甚了解，他们认为很简单的事情，但可能解决起来会很复杂。以笔者的经验来看，一般来说用户的镀金需求可以延期解决甚至不考虑。用户的新增需求如果不是影响到核心业务的实现，也可以安排在现有功能的完善之后。
⑥ 每月变更记录上报双方领导
最后，实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案，可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权，逐步让不合理的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常的项目执行氛围和良好的工作习惯，也为可能受到变更所带来的责任问题留下伏笔。
最后，要特别提醒，要在MES项目开始就对项目组和客户进行宣传和培训，让所有成员都理解变更控制的重要意义。
3. 用友系统ERP实施完了，为什么还要做MES
ERP实施顾问是一种综合技术知识和管理能力的职业，门槛高所以很多人进不来，但是只要能进来，在成长中一般都可以磨练出来，就是说ERP实施顾问的成长需要积累，需要在实践中不断完善和提高。 以下是对ERP顾问职业所具备的知识和能力结构的十大建议。 1、一定的计算机、网络技术基础 身为ERP软件实施顾问，你不能不了解你的产品，当然你可以了解得粗略，不必象技术工程师那样精通，你要能够回答客户提出的大部分问 题，所以需要你掌握的知识非常综合、全面——强调的是广度而不是深度，当然，如果你的深度够好，那么会更加有利。如果你的深度不够，经常回答不上客户的问 题，没关系，关键是你要留一个缓冲余地，你要知道，你应该从哪里获得帮助和支持。优秀的ERP实施顾问，应该懂得如何调度资源。 以下为我认为ERP实施顾问应该掌握的技术： （1）ERP软件本身，主流的管理软件如用友、金蝶、SAP、甲骨文等。 （2）系统管理知识，包括WINDOWS 2003，UNIX。 （3）数据库知识，包括SQL2005、ORACLE、DB2等等主流数据库，SQL技能。细分可为查询分析器的使用，数据表的操作，报表的基本技能等等。 （4）网络知识。网络协议配置、网络拓扑等。 （5）一定的硬件知识，如服务器、交换机等。 2、ERP行业知识 管理信息化行业知识浩如烟海，没有人可以掌握全部。把握好你的定位，你要了解全部的产品有什么，但你要选定一个方向，在这方面成为专家。既要广博，也要有自己的专精所在。 不要贪多，很多东西知道框架即可，用的时候懂得较快地搜索、查找出来即可。时间精力极为有限，有些东西要懂得放弃。 3、管理知识和项目管理知识 应当具备丰富的管理知识。要与客户保持好关系，要有良好的服务意识。客户管理层是项目推 进中最好的资源，一定要取得他们充分的信任和合作。如果你不了解管理知识，你难以让客户信服和接受。管理软件之所以需要ERP实施顾问，就在于实施顾问能 够通过资源调度使它具备生命力，没有产品是尽善尽美的，但是一名尽责的、优秀的ERP实施顾问，却可以弥补产品本身的不足。网络上管理知识应有尽有，只看 个人的吸收能力。另外的一个好的学习途径就是客户方管理人员，他们的管理经验更有实效性。所以，在项目的实施过程中，我们事实上就可以学到很多管理知识。 这也是这项工作的诱惑和魅力之一。 作为ERP实施顾问，项目管理非常重要。要掌握基础的项目管理知识，掌握项目管理常用的软件工具。如果你是由技术工程师转型而来，观念上的转变至为重要。 erp实施顾问不是替客户做事，而是指导客户做事。所以尽管你眼看着一个简单的问题却在客户手中无法解决，禁不住着急，想要代做，也请你管住自己。牢牢记 住实施顾问的定位，不要混淆。事实证明，这是很多做惯了技术服务的工程师在转型到实施顾问时的一个瓶颈。身为ERP实施顾问，你的专业化，恰恰是体现在 “项目管理”上面。项目管理的知识，可以充分利用互联网，用BAIDU、GOOGLE去搜。 另外，一个ERP实施顾问，他是一个客户和研发的中间人。那么他就要给客户设计方案时候，不但要满足客户的需要，而且要了解研发的难处实现的可能性。好的方案不但要了解系统还有了解行业。同时要了解研发的技术以及一些数据库结构的设计以便同时为客户、研发服务。 更重要的一点就是实施计划的制定，考虑的客户的迫切心理，和研发的实际进度。为了迁就客户，计划过于紧密，研发就会出现质量问题，反而不好。时常要降低客 户的期望值，也是一种方式。同样东西，研发都是3号提交，客户希望5号，和客户希望1号。当研发只能3号时候，最好能让客户答应5号。然后3号给他们。他 们会有意外惊喜，甚至觉得你为了提前2天做了，很多工作，可能在其他地方给你通融。 4、计算机专业英语水平 国际软件厂商研发的ERP系 统，是用英文开发的，相关资料，尤其是最新的资料基本都是英文的，如果英语不灵，那真有点被动。就是本土软件的顾问也应该学好专业英语，了解主要的国外厂 商产品，及时吸收外文最新知识，这对你是很有益的！不过英语不好的同学也不用着急，这里说的是专业英语，掌握计算机和管理领域的常用词汇就基本可以满足工 作需要了，当然懂的越多越好。 5、ERP实施顾问应有一个清爽整洁、职业化仪表。 要知道顾问基本上是一个服务性质的工作，必须得到客户方的认可，必须让人家喜欢和你相处。不修边幅的人，不适合担任ERP实 施顾问。你的气质与风度，你能否征服你的客户让他们接受你，信任你，是项目顺利进展的关键。曾有客户讲过，如果他们不接受实施顾问本身，也就难以接受实施 顾问带来的一切。除了相貌，气质，还有谈吐。彬彬有礼、条理清晰、善于表达，是良好沟通的基础。当然，自信心也很重要。而职业化，不仅仅是实施顾问的要 求，它是身在职场的人们都必须具备的常识。如果想在这方面得到提高，可以去买本公关礼仪方面的书或者查询网站上的相关知识。另外可以多留心一下那些公认有 修养、善谈吐人士的言谈举止，逐渐地养成习惯，固化下来。 6、不断的学习新知识 上述几条，不是独立存在，而是相辅相成，技术、管理、企业业务流程，都需要不断地学习。知识是日新月异的，必须与时俱进，活到老学到老，你往往需要在知识上走在客户的前面，有时候你必须要向客户学习，要学的东西永远太多，所以想要成为一名优秀的ERP实施顾问，时间管理是必须要掌握的，如何合理的安排时间、有效利用时间是一门大学问，需要自己不断探索、总结。唯有热爱这个行业，对它感兴趣，甚至到了吃饭、走路、坐车、如厕也常常思考相关的问题。 7、一定的运气和机遇 机遇也是非常重要的，一定要善于寻找机遇，创造机遇，抓住机遇。 想要成为优秀的ERP顾问，需要一个漫长的过程，要多多用心，潜心体会，自然会有心得。常常要耐得住寂寞清静。多付出，不要太在意回报。坚韧不拔，终将修成正果。优秀的实施顾问，前途必然是光明的。 8、职业发展路线 现在ERP实施顾问的职业发展前景被业界看好，未来五年管理信息化行业将需要5-6万名ERP顾问，不仅大学毕业生想进入这个领域，很多职场人也很想转型做ERP实施顾问。目前，大家共同的问题是这个领域要求综合素质高，没有相关经验的人进入门槛是个问题！不过要是真的想在这个领域发展还是有机会的，用友集团成立了一个交用友管理软件学院（.cn）的教育机构，专门为想进入ERP领域的人进行系统化训练，解决门外汉的门槛问题，好的一点是他们是推荐就业的，毕业后大部分留在用友体系，一小部分推荐到用友的客户单位，再提示重要的一点，入学他们是有面试和考核的，资质不好的是进不去的。 目前的情况看，有工作经验的人转型做ERP顾问更有优势，可迅速升级做售前顾问、项目经理职位。以下是ERP顾问职业常见的职业发展路线。 1、初级实施顾问，中级实施顾问，高级实施顾问，实施总监，研发部总经理； 2、初级实施顾问，中级实施顾问，高级实施顾问，售前顾问，高级售前顾问， 销售经理，销售总经理 ； 3、初级实施顾问，中级实施顾问，企业信息化项目主管，信息总监（CIO）。 做ERP实施顾问是要经常出差的，但是在企业方做信息化项目很少出差，但是需要的知识结构和能力基本相同，部分ERP实施顾问（女性偏多一点）转型到企业里发展，最后做到CIO的位置，也是一个不错的职业发展路线。
4. 新韶光MES系统项目实施团队的组建是什么样子的
一个完整的MES项目团队，大体上会包含以下类型的人员：项目经理、业务顾问、系统架构师、开发工程师、实施工程师。
5. 想了解MES实施工程师工作内容，是否需要经常出差，频率需要具备哪些能力
这是个很有抄前景的职业，需要比较强的综合能力，
可以看看人家的招聘要求。
职责：
1、负责MES项目的业务调研、流程梳理、需求分析、详细设计以及现场实施；
2、负责已实施MES项目的运维和技术支持；
3、负责完成项目实施过程中各类文档、汇报材料的编制。
任职要求：
1、专科及以上学历，机械、化工、自控、计算机等专业；
2、具有独立工作和独立解决问题能力，主动进取心和团队合作精神；
3、具有良好的表达能力和沟通能力，善于引导客户提出需求；
4、能适应长期出差；
5、熟悉MES软件产品，具有3年以上MES项目实施经验者优先；
6、熟悉工厂DCS控制系统、自控仪表、以及石油石化、煤化工、精细化工等行业生产管理业务者优先。
6. 我以前在化工厂做化工工艺，现在跳槽出来，公司安排去做外协，做MES实施工作。虽然做项目实施有出差补助
其实我倒是蛮喜欢你这MES的工作
7. 如何打造一个成功的MES系统
这个问题可以从两个角度理解，即甲方和乙方。
从乙方的角度来理解，也就是如何开发出来一套成功的MES系统，这个话题很大，涉及到需求分析、产品设计、技术开发、产品测试以及运营推广等一系列的事情。
从乙方角度能做到打造成功的MES系统，基本上就可以算是一个成功的创业了。
不过，我觉得这个问题的理解，可能更多是从甲方的角度，就是您可能是一家甲方的公司，你们要上MES系统，你们想要知道如何上一套成功的MES系统。
如果这个理解没错的话，根据我们跟很多企业实施MES系统的经验，企业可以从以下的几个层面来考量——如何打造一个成功的MES系统。
首先，要考量企业为什么要上MES？企业是否适合上MES？
可以考虑以下这些个问题：
1 企业是否有上MES的明确的目的？
2 企业是否有上MES要解决的具体问题？
3 衡量MES系统成败的指标是什么？
4 企业对MES功能和性能是否有明确的考量？
5 企业是否有上MES配套的业务人员和IT人员？
这些问题的答案，决定了最后如何衡量MES是否成功，以及企业上MES是否具备必须的条件。
其次，企业明确上MES的目标，也确定了适合上MES，接下来就是要做好MES产品和厂商的选型。
MES产品和厂商的选型，也需要考量几个方面：
1. 对MES系统选型在产品和技术上做衡量，包括：
1.1 产品上的功能满足度
1.2 产品的易用性和良好用户体验
1.3 技术上的成熟性和稳定性
1.4 技术上的定制性和拓展性
1.5 技术上的先进性
2. 对备选MES系统厂商在案例上做考量，包括：
2.1 MES系统厂商是否有足够多的案例？
2.2 MES系统厂商是否在相同或类似行业里有可参考案例？
3. 对备选MES系统厂商的资质做考量，包括：
3.1 MES系统厂商具备怎样的资质？
3.2 MES系统厂商的财务运营状况？
3.3 MES系统厂商受到的其客户的评价？
3.4 MES系统厂商实施人员的数量、经验？
3.5 MES系统厂商实施人员在相同或类似领域内的经验？
选定了MES产品和厂商之后，接下来就是具体MES实施了，这其中更多的是项目管控的事情。
项目管控，一方面涉及到企业内部资源的管控，比如组建项目团队，需要业务人员、IT人员等都参与到项目当中，并在项目的进展中推进进度、把控质量；另一方面涉及对MES厂商资源的管控，包括对MES厂商提供的项目人员的能力的评估，对于厂商项目进度的推进和管控，对于厂商提供同的产品和服务的把控。
项目管控的具体涉及的细分层面很多，比如进度、任务、费用、变更等等，详细了解可以参考PMP的内容。
最后，整个项目的实施基本结束前，要对系统做评估和验收。
根据项目开始时，确定的项目成功的标准，逐项的评估MES厂商提交的项目成果，判定是否满足当初制定的成功标准；满足则为合格，不满足则需要限期整改，直到满足标准。
所有的过程搞定之后，一个MES项目才算是成功搞定，一套MES系统才算是打造成功。
以上，供参考。