Dynamics 365 实施常见问题及避免

项目管理中，解决问题的方法没有对错，只有是否适合自己，以下经验仅仅是个人的观点，分享出来是为了跟同行进行交流，给初学者在项目实施过程中一些参考案例及思路。
经历过ERP的实施后发现，大部分的项目实施都很辛苦，尤其上线前后，顾问们都加班加点的干活，但是上线后仍然发现有很多问题，我见过和听过的问题主要有以下几类。
    1. 性能问题
    2. 主数据问题
    3. 业务流程问题
    4. 操作问题
    5. 功能Bug
或多或少问题都可以归结到上述几类中，性能问题： 这一类在各个项目中经常遇到，前面也有专题从技术角度去进行了阐述，这里不再多叙。操作问题：可以通过培训来解决。这篇文章针对其他几类进行一些探讨。

主数据问题：这部分的问题相对比较严重，很多ERP的专著中也会提到，主数据是ERP的重中之重，其实很好理解，主数据有问题就会导致业务出问题，所以主数据的重要性人人都知道，但实际项目中还是有各种各样的问题。首先从甲方的角度，甲方应该要非常重视主数据，指派专人进行主数据整理，不能因为说数据量大嫌麻烦而不认真准备。从乙方的角度，应给与甲方足够的指导，要帮助甲方理解主数据需要的字段，甚至提供模板，帮助甲方梳理主数据的创建，更新，停用等流程，确保主数据在系统中的正确性和安全性。对敏感的主数据，尤其是对业务造成影响的，比如客户组，供应商组，物料组等不能让用户轻易就可以对这些字段进行修改。建议二次开发主数据检查功能，只有检查合格的数据才可以使用后续的业务。

业务流程问题：这部分问题居多，有调研时没有调研到的问题；有新需求变动；有流程规划不合理；有流程变更引起的连锁反应导致功能不一致；有只考虑正向操作不考虑取消或退货的操作；总之，功能不完善的都归属这一类。这一类建议每个项目必须有个总设计师。只有各模块的负责人，出问题后各自为阵的做法在小项目中是可行的，大项目中就会出现各种问题，尤其是新增或修改功能导致其他功能不可用，导致用户对系统的不信任。修改到最后，项目容易导致失控。越临近项目尾声(由于时间原因，顾问都会追求快速解决问题，不能够周全的考虑问题）, 越容易出现意想不到的问题。

功能Bug：这一类属于业务流程和数据都没问题，但是结果不是预期结果。这类问题的测试往往是测试场景考虑不全，测试不够充分。所有的定制在设计好功能之后，就要考虑测试场景，对所有可能有影响的场景都要测试。数据的测试建议都是3 以上。 如果是接口，要测试三个以上文件导入，三个以上Web Service调用同时进行。普通功能的测试行应在3行以上。为什么是3以上，我也没仔细思考原因，实践中发现1~2条数据发现不了问题，三条以上就能出现问题。类似的实战案例遇到过多次，仅仅是经验分享，没有理论依据。

文章最后，我想说，项目的成功有很多因素，我们可能很难找到一套确保项目成功的秘诀，但是把可能导致失败的因素多加注意和避免我认为是能够增加项目成功的概率。
除了以上避免外，个人还有几点经验，这些经验看起来好像大家都知道，但是实际执行起来确很难。
    1. 项目计划：建议除了正常计划外，需要做个双周滚动计划，计划发送到所有干系人。项目经理不仅仅是计划的制定者，监督者，更重要的是要确保计划执行所需的资源保障。
    2. 过程管控：只看结果不看过程的做法，实践证明是比较失败的。 因为，等到结果不行的时候，时间往往已经浪费掉了，要在规定时间完成项目就必须对过程进行管控，按计划进行项目追踪。
    3. 专家判断及项目监理：PMP的理论中，遇到问题有一个通用的办法，就是专家建议。小项目可以不需要专家及项目监理。10人以上的项目，建议聘请专家第三方项目监理对项目方案进行咨询以及交付物的检查。专家可以是兼职的，也可以是甲方内部的关键人物，乙方的高级顾问但是并不一定在本项目上。第三方项目监理应脱离乙方和甲方，能够公正的对待项目。检查也应该是事先制定标准，不应事后找问题，监理方应是资深顾问能够发现问题，并提出很好解决方案，协助项目走向正规。比如FDD的编写，要给出模板。代码编写，要给出开发规范，详细列举最佳实践要求。检查标准可以不断完善。
   4. 测试： ERP的测试一定要确保熟悉功能的人来测试，不能找不熟悉的人去测。甲方的关键用户最好在测试前就培训就绪，乙方在提交给甲方测试之前必须确保功能在测试环境是经过验证的。