在ERP项目实施前，我们企业除了担心软件的适应度和厂商的实施能力之外，也非常的担心项目实施过程中的风险，无论厂商如何强调自己的“实施方法论”，但毕竟我们企业没有实施过，其方法论是否适用是打问号的，甲方乙方间的这种买卖利益关系是无法回避的，那么甲方如何才能做到有效的限制乙方的“实施方法论”呢？又怎么能做到心中有数呢？我们不妨参考“里程碑式评估”的方法。

1. 调研阶段的评估
当项目立项确定后会接触所有的厂商，不管是用什么方式参与进来的，都逃不过要求调研，调研的问题或者方法各厂商大同小异，作为甲方就会面临同样的问题被问及若干次，难免让业务部门心生厌恶，毕竟大家还有日常事务工作要处理，那么如何把握好这个度呢，我给大家的建议是先从若干参与厂商中找一个综合实力最高的厂商做全面调研，这里有两个作用：首先当然是要厂商充分了解我们甲方的业务流程和需求，其次是在厂商咨询顾问的带领下挖掘、整理自己的需求，同时我们交流学习ERP的工作原理，为未来的培训做普及预演，第一次做需求调研务必要细、要全，关键是让业务部门清楚自己“要什么”。
接下来其他厂商要不要同样做调研呢？这个要具体问题具体分析，如果企业中明确了项目组的工作，并限制了时间节点，那么可以集中投入时间和人力，不过我们仍然要考虑业务部门的“情绪”，所以我的建议是在带着第一次全面调研的方法和问题去和其他厂商直接交流，这时候除了做厂商间的对比之外，也要汲取厂商对于同一个问题的解决思路方法，然后继续完善自己的需求。当然，如果这时候有其他厂商提出来要做系统的调研，或者后期依次为由推脱责任，不妨记厂商过一次，因为一个成熟的厂商会把每一次交流都当作需求调研的机会，并系统的整理出来，可谓每次交流都在做调研。
当所有的厂商都调研完毕后，我们必须要求各厂商都做调研汇报，作为甲方的业务部门要一起参与评估，评估的具体明细和标准要预先讨论确定，评估完毕后，基本上就可以筛选出意向的厂商了。我们不妨在这次评估会上把整个项目的报价也让厂商一起报出来，供我们做预算参考。
以上和大家分享的算是在选型阶段的粗调研结果，可以做为蓝本模板的，但是否具有实施价值是需要参考的，因为这时候所有的厂商机会都是一样的，所以厂商的调研以及我们自己的需求都不是最终版，当确定合作厂商后，不妨让该厂商带着这个调研蓝本再做一次二次调研，把初次调研时没有弄明白、有争议的问题都弄清楚，这时候我们再来评估一下，把和厂商、业务之间的争议都解决掉，通过这两次的评估，我们自己要做到心中有数，嘴里有话，在接下来的实施过程中不至于翻旧账。
2. 实施范围的评估
在项目正式实施前，厂商会把调研的结果先行评估，这时我们便可以一起坐下来讨论项目的实施范围，这时候我们不会再如调研那般细致，一般会在众多需求中找到一组企业要求最迫切的几个点，不可以眉毛胡子一把抓，这一点我们企业一定要自己先行分出轻重缓急，如果业务部门不相上下，那么高层决策领导要出来摆平哦，不然看起来哪个都重要都要先实现，结果可能就是煮成一锅粥。但确定下来实施的范围，也基本上圈定了风险的边界，目的是明确的，目标是可衡量的，有一句话我们必须记牢：如果你不能评估你要的东西，那么就要你能评估的东西。评估实施范围还可以界定厂商的能力，不至于在项目结尾验收时扯皮拉锯，所以说评估实施范围也是控制实施风险的有效手段之一。
3. 业务主线流程的评估
业务主线流程是串起企业过程的“任督二脉”，且以此为纵轴，把部门与部门、岗位与岗位之间的逻辑关系、职能关系、工作标准、甚至制度规范都贯穿起来，最终以“数据表单”的形式层级的向后递进地传递，环环相扣，但厂商是实施前是一定要模拟出企业的业务主线流程然后才可以确定逻辑关系甚至底层的编程和数据库设计，所以当厂商绘出企业的流程图时，我们要组织各业务领导一起评估，看看这个流程是不是我们想要的，这也是体察厂商咨询能力和实施能力的关键指标之一，如果这个流程图都画的差强人意，那么只能说明厂商不能完全理解我们的业务模式或运营模式，在上文所提到的调研汇报评估环节中是要包含这个流程设计的，倘若流程流程设计是泛泛的、框架型的、通用的，基本上可以判定厂商的“用心”指数了。
4.模拟运行测试评估
在项目实施过程中，我们企业都会提出让厂商搭一个DEMO来看，在选项过程中大家都会有这种疑虑，“说的不错，先做出一个来看看怎么样”，这个demo不管对于我们企业还是厂商都要认真评估，当然，这时候的厂商还没有确定下来，所以不管哪个厂商都不会根据企业的要求模拟出百分百的系统来，实打实的按照企业的BOM表去设计也是打折扣的，所以作为我们企业来说，关键是看“像不像”，而不是“是不是”，如果能够模拟出主要的业务流程，或者能够说明白数据的来龙去脉，我们就可以通过了，也就说这个阶段的模拟只是“相面”，先看看什么模样。
当确定完了合作厂商，在系统正式上线前我们必须有一个demo运行评估，这个demo已经基本上算是正式系统的前身了，参与评估的不但要有业务领导，更要有一线的业务骨干，这是一个“修正纠偏”的过程，流程运行是否通畅、表单格式是否正确、审批逻辑是否无误，系统设置是否有bug，等等，都是这次评估的指标，具体评估内容还得咱们企业一起决定。
上文的各项关键阶段的评估如果做的扎实，我想这个demo评估也不会背离太远，如果评估结果达到企业的期望值，我们不妨可以宣布系统正式上线的时间了。
5. 月结/年结评估
这个评估完了基本上就是项目结尾验收了，那么项目实施的到底怎么样呢？验收的标准怎么定呢？难道还是开始时我们确定的需求吗？抑或是曾经界定的实施范围？这些都不是，决定验收标准的只有一项，那就是数据，无论我们前期做了多少的准备预案，但月结/年结时错误连连，最终形成的财务或业务报表都是错误呢，那么基本上可以判定项目失败了，道理很简单，ERP中跑的数据不是我们要的数据，无论厂商怎么强调数据“跑”地多么的准确，但结果却“跑”错了方向，这怎么验收呢？所以说月结/年结时的评估更是重中之重，评估的结果直接影响到项目的成败，同样也影响到厂商的收成嘛。这个阶段参与评估的人员嘛，主要还是要看各业务骨干，他们才是关注数据流转过程的裁判员，老板的关注点当然是数据最终的结果了。
所有的ERP案例都在强调“项目风险”的必要性，风险是存在的，控制风险也是有办法的，给风险栓上“缰绳”，我们都不是诸葛亮，但我们可以多学学司马懿，把每一个里程碑阶段都设置一个“评估”路障，只要企业和厂商实时地、通透的沟通，有效执行阶段评估，稳扎稳打、步步为营，我们还担心什么呢？