现场推广工作如何来做2

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

案例
项目经理小李在一个项目上带领团队调研完成后，觉得基本上可以搞清楚用户业务流程，就带了三个人在现场进行一个月的封闭式软件配置，为此专门找用户要了一间办公室，每天都工作到夜晚。但用户对小李的工作不但不认可，还经常催促他们加快进度，小李感到用户太苛刻了。
点评

    项目团队的推广失败，其一种行为模式往往是项目团队把自己思路向用户描述一下，甚至没有什么描述，就闷头大干。用户项目组不知道如何参与项目团队工作，只好去监督项目团队，成为项目的监工。而用户项目组又不清楚系统的思路和实施套路，只能按照领导意图来给项目团队施加压力，而不是和软件公司一起分担压力，这样状态下的项目自然难以受控。所以项目团队做的都是事倍功半的工作。
    把用户，至少是用户项目组变成可实施的力量，并帮助他们推广实施项目，而不是依赖个人力量推动实施。把他们由项目监工变成项目执行者，项目团队成为监工和顾问，这样的实施才轻松有趣。
    让用户真正参与项目实施工作，虽然用户累一些，但大家有了团队的感觉，心情反而更愉快，说个套话：往往在这个阶段和用户建立了战斗的情谊，为今后验收、回款、配合请其他客户参观、考察都奠定了牢固的基础。所以电子商务项目团队在项目推广过程中要反复强调和贯彻与用户一起参与的方式，得到用户认可，在实际工作中落实。
    例如软件安装，项目团队可以和用户约定，只示范装3台，然后安排用户方面的人装3台，项目团队在旁边指导，如果连续三次安装都成功，项目团队就可认为正常情况下没有问题，其他的都可以交给用户处理，项目团队只需要处理意外问题。
    例如进行业务操作培训，项目团队先要经过讲解示范，确认用户项目组明白，立即请用户项目组操作，确认用户已经掌握了操作，那么后面的培训可以主动邀请用户项目组成员讲解，项目团队提供技术咨询，今后培训工作策划组织都可以逐步交由用户项目成员负责，较后一般问题基本不需要项目团队亲自解决，大多数基层用户都习惯和自己人交流解决问题，项目团队只负责解决软件的疑难杂症，而且某个业务被大部分人熟练掌握后，项目团队的工作主要就是新的业务流推广方案验证和设计规划，以及保障项目进度的相关管理活动。这样一轮轮循环，就可以让用户项目组慢慢成为实施的主体，而且在这个过程中用户项目组成员的能力可以得到极大成长和进步，他们也会感谢项目团队给予自己的帮助。
    一旦实施能力转移了，项目团队并不需要经常到现场工作，因为项目团队到现场工作成本极高；一般情况下项目团队在现场解决问题，培训技能，达成后续工作计划，完成本次业务目标就必须返回公司。
    用户项目组不能解决问题的时候，项目团队要全力解决问题，要第一时间安排现场响应，如果不能及时解决，或解决得不顺利，项目团队应第一时间通报给用户，也请用户理解支持。
    不过坦率地说，很多没有经验实施工程师本身也不知道如何推动项目，因此去激发用户时就缺少足够的影响力和行动能力，就只好亲历亲为，被动响应，在自己能力不足的阶段花费更多时间在现场积累经验也是必要的。
    ◆光打雷不下雨，缺少高管支持
    很多时候仅仅和用户项目组达成一致意见还不够，还要和用户高管达成一致。否则在项目遇到阻力的时候，得不到更多资源响应。
    与用户项目组达成一致的实施方案要向用户高管汇报，汇报要点不在OA软件功能和配置细节，而在于目标是否认同，资源投入计划是否可行，可能会有哪些风险，采取了哪些措施保障，如果出现一些项目阻力，需要提前得到领导哪些授权或政策支持。
    特别要向领导汇报取得认同的工作就是，将和信息化相关的基础工作(例如数据录入、业务执行)变成有制度保证的岗位要求和流程要求，这样制造业信息化工作推进才有制度保障。
    取得高管支持较有效的手段是建立向高管汇报的机制，这样才能够让高管定期清楚知道项目进展和需要给予的支持，项目组成员也会因为可以经常得到高管授权和肯定而努力推动项目。
    向高管汇报时要注意的是，每次汇报应该准备一些积极的内容，值得肯定的内容，的确有进步的内容，否则仅仅是诉苦汇报，是不能指望高管对一个无能的团队给予更多的支持的。
    ◆边界总在变更
    有的项目实施过程中，用户不断提出一些新的要求，希望项目团队能够给予解决。这个时候有的实施人员顶不住用户的压力，被迫答应解决，结果就导致项目的边界总在变更，项目目标在一次次变更中不断变形游离，较终模糊不清，项目也就陷入不断开发，不断提出新问题的循环之中。
    ◆做人不好
    有的项目存在严重人员沟通问题，用户对项目团队不放心，宁可把项目团队留在现场不离开，担心项目团队走了不再来了。
    这种原因就是实施人员没有建立足够诚信，往往是一个阶段工作没有做完，没有确定到应完成的里程碑点，就安排做其他工作，甚至就是不够认真负责，敷衍了事。
    用户听信实施人员下次来解决问题的承诺，结果实施人员在多个项目现场奔波中并没有投入精力解决软件问题，或者没有促进公司解决问题，使用户并不满意。
    有的时候团队调度周转不灵，版本发布推迟，用户不能看到项目团队按计划兑现承诺，也会不相信项目团队的工作，因而要求派人到现场长期蹲点解决问题。
    其实如果问题不能解决，蹲点也无济于事；如果问题能够解决，往往是双方沟通协调后，在软件公司先解决软件问题然后再到现场解决实施问题。软件公司人力资源一般都很紧张，将人压在现场，几乎是让自己问题在软件公司内部陷入无人推动的境地。
    所以供应链管理项目团队一定要做好较坏的打算，和用户慎重承诺，说到做到，有问题时要全力保障问题及时解决，给用户两个印象：第一项目团队很认真守信，第二项目团队时间珍贵，每次只能解决关键问题，实施还是靠用户自己解决。
    第三节现场推广工作如何才能做好
    做好现场推广工作关键在于前期各项工作质量。
◆要组织高质量的业务调研
    业务调研阶段在产品比较熟悉的情况下，可以边调研边建立原型测试，这样在现场调研时对可推广业务进行设计和验证，构思业务流程操作手册、数据规范手册和各种样例，到了真正推广的时候思路早就经过了反复推敲，非常可行。
    ◆要对关键用户组织成功的培训
    培训就是让用户进行推广，软件公司协助配合，要相信用户的积极性、主动性和能力，要不断激发他们在这些方面的潜力。
    从一开始到现场工作就要反复安排精心组织的培训活动，让用户理解我们的思路。
    项目解决方案或思路一定要组织各种类型会议在现场反复讲解，达成一致，非常关键的问题不要回避或模糊化，例如管理业务的思路。大方向明确后一些技术小细节可以淡化，不要在开始的时候纠缠细节，较后把细节发展成一个大目标，会分散项目精力。
    培训的时候，在操作上应该准备实例化的内容，应该让主要(主导)用户操作后自我评价掌握程度，直到熟悉为止。
    培训思路要站在业务流的高度规划，让用户相信项目团队对他们业务的理解和描述非常准确到位，打消用户顾虑。
    ◆要提前做充分的内部业务验证
    内部业务验证一定要自己亲手测试，而不是依赖软件测试部门的结论。项目团队通过业务验证推导用户业务流程实施思路不是可行的过程，这个工作别人是无法取代的。
    一般情况下测试部门只能按照功能验证，不太可能完全按照业务验证，可能无法覆盖到某些项目业务上的操作，但项目团队到现场时，用户一定会发现这些操作可能还存在一些问题，如果推广会造成用户满意度下降，进而需要返工开发，这种反复将导致公司工作流软件开发管理成本急剧上升。
    在验证过程中项目团队要注意软件是否有易用性、性能和功能上的问题，要尽快提供给公司相关部门，找到替代解决方案或者列入可接受的版本发布计划中，这样才能保证在现场出现任何技术问题时，项目团队都有对策，承诺可改进周期时也比较有底气，不会随意延期跳水。
    作为项目经理和实施工程师必须对自己拿到现场实施的产品功能了如指掌，才能说是在业务上合格。不可想象一个对新功能、新版本不熟悉的人去现场指导用户实施能取得好的效果。这个熟悉过程只能通过内部验证来反复强化，而且内部验证阶段还需要准备新功能培训教材和升级数据等相关指导教材。
    内部验证不是要让产品完全没有缺陷才能启动后续工作，而是通过自己验证充分评估产品对主要业务线的支持程度，有多少是可以通过与用户沟通克服的，有多少是无法克服的，必须解决后才能去推广的，有多少是必须解决但可以暂时忍受的。并及时和