经常听实施顾问们说：“好希望做一个从头到尾的项目啊！”
想要从头进入一个项目，中途不被调走，一直只做这个项目，从头做到尾，这样的项目当然做起来很爽，会有一种一切尽在掌握的感觉，可惜完美是暂态，残缺才是常态，大部分的项目，不是你从中途进入，就是你从中途退出，或者你既从中途进入也从中途退出。
中途接手的项目，你遇到的困难会比正常项目遇到的困难多得多，所以，从中可以总结的经验教训，也比正常项目要多得多。
你可能会发现，没有人交接，没有项目文档，产品是二次开发的，你不懂产品，也不懂业务，总结起来你可能会遇到的困难有：
人员全变动：甲方原关键用户离职、乙方原产品经理离职、乙方原实施顾问离职，乙方原开发离职。
文档全丢失：没有需求文档，没有方案，没有产品设计文档，没有开发说明书。
产品全不会：非标准模块，都是二次开发的，之前你没有负责过这种产品的实施。
业务全不懂：你之前没有实施过这类业务的相关项目。
假设，你就遇到这样一个困难全集合的项目，本来早就上线了一个工厂，但是现在客户又新建了一个工厂，需要做推广实施，那么，你要如何应对？
首先，要做好心理建设，要意识到，能够有工作交给你，就是你的价值所在，不然公司为什么要给你发工资？困难都是纸老虎，你弱它就强，你强它就弱。有了足够的勇气和信心，然后再来看如何把这些困难都克服掉。
先跑下产品，大致熟悉一下有些什么功能。
然后去跟新的关键用户先了解要推广些什么业务，问下跟目前已经上线的业务的区别，一般来说，新的关键用户就算不知道到底产品是如何操作的，起码对他们自己的业务还是熟悉的。
问清楚他们要推广的业务，再去把前期的业务在系统里面的实现方式找出来。没有人来介绍，就自己去找人学习，没有文档，就自己补文档，主要是方案和手册。
对于甲方来说，关键用户离职，相当于可以用于内部推广的人员没有了，所以甲方才会来找乙方再次帮忙推广，关键用户虽然离职了，但是只要还有人在用，那就还会有最终用户，最终用户虽然搞不清楚系统的来龙去脉，但是起码他知道在他这个环节是如何使用的，只要把每个环节的最终用户都找出来，都学习一遍，你就可以学会整个业务流程的业务和产品操作。
此时你最担心的，莫过于觉得这样去问，会失掉自己的专业性，可是装不下去的时候，确实就不能再装。
实施顾问换人很正常，跳来跳去也很正常，如果你实在是拿不准这样做行不行，那你就问问你的领导，积极探讨方法，总比告诉你的领导你搞不定要好。
至于说应该找哪些最终用户，你可以去系统里面查系统里面有些什么角色，每种角色里面再找一个操作频率较高的用户。
谁的操作频率高，你可以观察系统的在线人员，经常在线的操作频率一般就高，如果你的系统没有在线人员的统计，你还可以去查操作日志，如果连操作日志都没有，你就找到业务的起点，然后问这个用户，跟他对接的下个环节是谁，然后这样问下去也能把流程和用户都梳理出来，也就是通过用户再到系统里面反查出这个用户对应的角色。
比较麻烦的，是了解系统的数据逻辑关系，最终用户一般都不会知道这些，比如初始设置的商品信息，是手工新增的，还是系统通过集成协同过来的，这种情况可以求助开发去查代码，也能找出来。
通过一个业务流程的学习，你差不多就可以对业务和产品操作都有所了解。在这个过程中，你通过记录，实施文档也有了。
然后你还要了解系统有没有做过集成，集成了软件还是硬件，还是都有，如果有，你还需要让新的关键用户联系第三方软件或者硬件厂商，跟他们了解集成的情况。了解推广的时候接口是否需要二次调试，以及调试的时间，周期，要做些什么准备来调试，比如是不是要等新厂的硬件全部安装完毕才能进行调试，还是只要安装一个就可以进行。
这些都了解完毕，你差不多就可以进行正式调研或者补充调研了，把客户的推广需求，推广的新业务流程都梳理一遍，调研完毕，你就可以开始测试系统。
重点要测试的，除了新工厂的流程是否可以在系统里面跑起来，还要测试系统是否支持多工厂模式，之前二开的时候有没有考虑到这些架构问题，只要架构不出问题，其他需要优化的问题就不会太大。
把产品需要完善的地方提交给开发完善，后续就可以正常实施推广了。
先要找到方法，理解能力只是影响你实施的快慢而已。
