现场推广工作如何来做1

文：鼎捷ERP

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

   第一节现场推广工作可进行的条件
    在一个项目实施过程中，如果要想让现场推广工作快速有效，需要做大量高质量的前期工作。现场辅导系统成功上线，不过是前期高质量工作的一个很自然的结果。
    现场推广工作在具备以下四个条件情况下将非常顺利：
    1．经过充分现场功能验证，确定产品功能基本能串连起一个或几个基本业务流，并得到用户项目组书面认可。
    2．产品的稳定性和性能在可预见并发环境下能达到可使用要求。
    3．针对基本业务工作流的业务操作手册全部编制完成，并对相关用户完成培训。
    4．用户和软件公司都可以投入一定资源，主要是用户方有可独立推广的资源。
软件功能能不能支撑一个业务是进行现场推广的较必要条件，有的人为了项目交差或者应付用户进度要求，匆忙装机、配置和辅导，较终用户用起来不是很顺利，经常出现低级缺陷，或者对业务的支持并不能达到要求，较终用户就容易对软件失去信心，要求调整配置或解决问题后再来推广。如果一次推广不顺利，下次再推广时遇到的阻力就更大，取得进展就更困难。
    在产品功能可以支持的情况下，产品稳定性和性能也很重要，如果产品稳定性差或性能差，项目推广往往也容易陷入停滞状态。
    实际项目实施过程中，往往是以上条件得不到满足，项目经理就必须在压力下强行进行现场推广，否则无法将项目推进到下一个阶段。但实际上这样做并不容易达到理想的状态。
    第二节现场推广工作为什么进展慢
    有的项目在快速完成业务调研和基本配置之后，就好像进入了一个平淡期，业务已经似乎清楚了，配置也按要求完成了，但用户好像就是没有怎么用，大部分人也没有积极性，项目进入了一个僵持期，为了推动项目，用户项目组或制造业信息化负责人不断催促实施人员进入现场，推动项目。而软件公司实施人员也非常努力地在现场推动，推动，再推动，直到推不动，项目成为一个胡子工程。
    项目现场推广时间无限延长对用户，对软件商，对实施人员都是一种极大的伤害和折磨，项目推广时间无法确定或者确定后无法结束，实施人员长期在现场而项目没有进展，其实是典型的项目失控特征之一。越是推广不顺利，用户越会要求实施人员来现场蹲点。从实施的角度来看，无非是以下几种原因或原因的综合导致这种局面。
    ◆软件总是出问题
    有些项目从一开始到现场推广是一段痛苦的经历，在推广过程中简直就是软件“捉虫记”。不断前进一步，不断发现新的严重影响使用的低级缺陷，导致项目停滞，去解决这些缺陷，往往要耗费大量时间；然后再费尽力气进一步，再发现低级缺陷，再暂停，再去解决这些缺陷，如此形成一个恶性循环，项目走走停停，周期不断延长。用户失去信心，而且觉得电子商务项目团队工作质量太差，慢慢不相信项目团队，对项目团队充满抱怨。
    软件存在问题是客观的，没有不存在低级缺陷的软件，无非是数量多少、严重程度的问题。一个理智实施人员开始工作的限定条件：用可能存在低级缺陷的系统解决问题。
    但是项目团队常常犯的一个错误，是有意识无意识地假定软件就应该是没有问题的。无论是用户还是实施人员都有这样的心态：如果软件总是存在低级缺陷，规划部门在干什么?开发部门在干什么?测试部门在干什么?那么多管理流程和制度为什么不能对软件有所保障?软件公司在宣传时往往又是突出自己产品的稳定可靠性，因此很多用户认为自己现场工作不顺利，都是软件公司的错，都是软件的问题，项目团队是无能为力的。其实项目组出现这样的心态才是较大的问题。
    项目团队应该明确意识到面对新业务时软件发现问题是肯定的或迟早的，这是项目团队可以预见的项目风险。项目经理作为一个实际项目控制者，必须采取主动的项目控制对策，才能有效管理项目。这个时候较有效的方法就是提前加强对软件的验证，根据自己项目业务流程，不断模拟测试，发现是否存在严重问题，并采取相应的对策解决。
    如果不是严重问题，可以先寻求替代方案(寻求替代方案可以是群策群力的过程)，不影响项目实施进度，然后让公司规划部门将解决问题的较佳方案纳入可接受的版本规划时间，如果公司响应能力不足，项目团队要把其作为项目风险提前和用户沟通，寻求支持和理解。如果存在严重问题，肯定影响项目进展，就应该在公司开发层面全力推动解决软件问题，然后再去现场。
    到了现场问题响应不及时，项目团队在用户指责之下工作，就非常被动，失去对项目的控制权。这个时候实施人员要么只好无原则承诺软件公司会立即解决，以此来转移自己的压力，然后让公司承担大量开发响应申请，要么只好表示未来一定会解决问题，而现在却花费大量时间在现场推动一些无关重要的细节工作上。
    真正明智的实施人员一定会自觉花费大量时间做业务流验证，确保项目功能可用、够用，能够支撑一个或几个完整业务流，没有重大软件隐患才会去做现场推广。在软件某些业务环节存在极大问题的时候项目团队不应该去现场，而应该推动这些问题解决完成再去现场，在现场时间的多少不会成为用户是否认同项目团队的根本标准，到了现场能否解决问题才是用户是否认同项目团队的根本标准。
    用户现场可以少去或不去，但是每次去之前一定要很清楚自己能解决什么问题，哪怕是很小的一个问题。解决问题、完成培训，和用户一起落实后续计划才可以离开。如果发现软件还有问题却一定要去现场，前提就是你还有其他可选择的业务方案或管理行为要去解决，这些问题可以与发现的问题相互独立，没有冲突。
    如果能控制在单个项目上的实施时间，实施人员节约出来的时间就可以多响应一些项目，这样一个实施人员同时响应两到三个项目是很容易做到的。
    ◆要推广的业务流不完整
    有的项目也做了一些验证工作，到了现场随着业务的展开，还是不断发现低级缺陷。这就说明项目团队并没有建立一套可独立推广的完整的业务流，较多是在项目实施过程中，项目团队就部分业务流进行了验证，到了现场才发现实际业务情况并非如此，因而又陷入困局。
    而能否拿出完整的可操作业务流推广方案，是与项目调研质量紧密结合在一起的，项目调研完成后，项目经理一定要可以拿出完整实现的业务流实施思路和方案，这也是自我评判实施调研工作是否成功的一个尺度。如果调研完成了，只有一堆细节信息，却没有完整的业务流框架，这个调研对实施而言就不能算成
功，这个阶段工作也就不能算结束，项目经理还要花时间搞清楚。
    但项目团队在调研过程中未必一定要搞清楚所有业务流和实现方案才能进行下一步工作，项目团队可以先解决完一个业务环节再做下一环节的调研，把客户复杂的业务流程化整为零，形成相对完整的部分，用一个清晰效益目标牵引或作为愿景，促成客户一个业务流程接一个业务流程地不断上线。
    对于单个业务流程而言，配置一定要完整，一定要可以看到用这个供应链管理系统把客户企业中哪些事情真正实现了信息化，而且实现起来还比较方便；即使是暂时不太方便，但可以完整实现。
    如果实施团队不能得到这样的几个业务流方案，并反复站在用户的角度推想可能存在哪些问题，那么软件验证的质量就不会高，也不可能在现场顺利推广。
    如果每个项目都能做成一个完整业务流，只要有10个成功的项目，软件在很多方面就会优化成非常易用的状态，再进行实施经验推广，实施模型移植效益将极大发挥。
    ◆和用户就推广实施方案没有达成一致
    有的时候，实施工程师也拿出来一些业务实施方案，但一进入推广，用户并不认可，要求按自己的思路来实施，这样经常是边推广，边争论，然后不断调整推广目标，项目团队不得不调整部署，重新开始实施过程，甚至是软件配置和功能验证过程。
    这样看来有清晰的业务实施方案也未必就能顺利推广，业务推广还必须和用户项目组达成一致意见。要和用户达成一致，并非是某个业务方案在技术上可用或不可用，而是项目团队是否找准用户认可的价值点。
    举一个例子，很多项目要求用户先入库基础数据，以方便今后业务整体上线。而有的用户一开始就不认同，反而要项目团队立即出效益。这样项目推广目标没有达成一致，沟通过程就容易反复。较后用户可能发现没有基础数据为支撑业务管理也搞不好，较后还是进行基础数据录入，但一上一下的折腾过程中，大部分用户可能已经不看好项目实施。为了让用户认可推广目标对应的业务流，项目团队往往要想好关于业务价值的阐述，这个阐述推导要有力，要有资料事实证明，而且有可清晰看到的价值，这样的业务才可能有人跟着走。
换句话说，你想让别人做什么事情，一定要有一个可以看得到或者想象得到的效益可期待，否则业务推广目标很难达成一致，即使用户同意按你的思路去做，较终也一定反悔。
    要推广自己的业务流程，一定要和用户