现场管理-如何做现场推广

8如何做现场推广?8.1现场推广工作可进行条件？如何通过现场推广让用户项目快速上线，是很多实施工程时关注的问题。如果一个项目非常简单，和以往工程基本类似，那么辅导上线就非常轻松，根据企业业务和产品特点做好业务手册和应用规范，直接安装调试，验证无误就可以大面积推广，实施周期可以大大缩短。但对于很多大型项目，有很多不确定性或个性的内容，要进入现场推广阶段需要做很艰苦的工作。在一个项目实施过程中，如果要想让现场推广工作快速有效进行，其实是需要做大量高质量的前期工作，现场辅导系统上线应用不过是一个很自然的结果。现场推广工作可以进行在具备四个条件情况将非常顺利：1)经过充分现场功能验证，确定产品功能基本能连串起一个或几个基本业务流，并得到用户项目组书面认可；2)产品的稳定性和性能在可预见并发环境下性能能达到可使用要求；3)针对基本业务流的业务操作手册全部编制完成，并对相关用户完成培训；4)用户和公司都可以投入一定资源，主要是用户方有可独立推广资源。功能能不能支撑一个业务是进行现场推广的最必要条件，很多人为了项目交差或者应付用户，匆忙装机、配置和辅导，最终用户发现用起来不是很顺利，经常出现BUG，或者对业务支持并不能达到要求，对就失去信心，再来推广，阻力就大，非常困难。功能可以支持的情况产品稳定性和性能也很重要，如果产品稳定性和性能不足，项目往往也容易陷入停滞。至于业务手册和用户推广资源也是顺利进行现场推广的必要条件。实际项目实施过程中，往往是这些条件都不能满足的情况必须进行现场推广，否则无法将项目推进到一个阶段，得到用户认可，以便验收回款，但实际上效果并不见得容易达到。我个人体会现场推广顺利不顺利，其实不在现场时间长短，而是你为现场推广准备工作细致程度关联性更强。要想出差少也能控制项目，就必须寻求合理的项目控制策略。8.2现场推广工作为什么进展慢？很多项目在快速完成业务调研和基本配置之后，就好象进入了一个平淡期，业务已经似乎清楚了，配置也按要求完成了，但用户好象就是没有什么用，大部分人也没有积极性，项目进入了一个僵持期，为了推动项目企业项目组或信息化负责人不断催促我们实施人员进入现场，推动项目。而我们的实施人员也非常努力地在现场推动，推动，再推动，直到推不动，项目成为一个胡子工程或者是拉面工程。项目现场推广时间无限延长对用户，对软件商，对实施人员都是一种极大的伤害和折磨，我们认为项目推广时间无法确定或者确定后无法结束恰恰是一个项目失控的症状。泡现场其实是典型的项目失控特征之一。我们可以分析为什么经常出现用户要求实施人员来泡现场？从实施的角度来看，无非是以下几种原因或原因的综合。8.2.1软件总是出问题很多项目从一开始到现场推广是一段痛苦的经历，在推广过程中简直就是软件捉虫记。不断往前进一步，不断发现新的严重影响使用的BUG，导致项目停滞，去解决BUG，往往要耗费大量时间，然后再费尽力气再进一步，再发现BUG，再暂停，再去解决BUG，如此形成一个恶性循环，项目走走停停，周期不断延长，用户失去信心，而且觉得我们工作质量太低，慢慢不相信我们，对我们充满抱怨。软件存在问题是客观的，没有不存在BUG的软件，无非是多少严重程度的问题。这应该是一个理智实施人员开始工作的限定条件：用可能存在BUG的系统解决问题。但是我们往往犯的一个错误，人总是有意识无意识假定软件就应该是没有问题的。无论是用户还是实施人员都有这样的心态。如果软件总是存在BUG，规划在干什么？开发在干什么？测试在干什么？那么多管理流程和制度为什么不能保障？在我们的宣传往往又是稳定可靠的情况下很多人对这些事情就有了一种反感和抵触的情绪，进而认为自己现场工作不顺利，都是公司的错，都是软件的问题，我是无能为力的，出现这样的心态才是最大的问题。其实我们现在已经明确了，软件发现BUG是肯定，这是我们可以预见的项目风险。我们作为一个实际项目控制者，必须采取主动的项目控制对策，才能有效管理项目。这个时候最有效的方法就是加强对软件的验证，根据自己项目业务过程，不断测试，发现是否存在严重问题，并采取相应的对策解决。如果不是严重问题，可以先寻求替代方案(寻求替代方案可以是群策群力的过程)，不影响项目实施进度，然后让公司规划部门将其纳入可接受的版本规划时间，如果公司响应能力不足，我们将要把其作为项目风险提前和用户沟通，寻求支持和理解。如果存在严重问题，肯定影响项目进展，就应该全力在公司推动解决BUG，然后再去现场更合适。否则到了现场问题响应不及时，被用户指责之下非常容易被动，失去对项目的控制权。这个时候实施人员要么只好无原则承诺我们开发会解决来转移自己的压力，然后让公司承担大量开发响应申请，要么只好表示我们一定来解决问题，大量时间在现场推动一些无关重要的细节。真正明智的实施人员一定会自觉花费大量时间做业务流验证，确保项目功能可用够用，能够支撑一个或几个完整业务流，没有重大程序隐患才会去现场推广。在软件某些业务存在极大问题的时候项目团队不应该去现场，而是推动这些问题解决完成才能去现场，去现场时间多少不会成为用户是否认同我们的标准，去了能否解决问题才是用户是否认同我们的最后标准。可以少去不去，但是每次去之前一定很清楚自己能解决什么问题，哪怕是很小的一个问题，解决问题完成培训，落实用户自我计划就可以回来。如果软件发现还有问题却一定要去现场，前提就是你还有其它可选择的业务方案或管理行为要去解决，这些问题可以和发现的问题独立存在，无关紧要。有的实施人员可能抱怨，为什么一定要我在公司推动这些事情，其实这倒未必，一个好的实施人员发现一个项目存在问题，可以及时反应到公司，通过软件配置管理和开发流程解决，但一定要按照配置管理要求把项目情况反映到位，如果反映不清楚才需要到公司协助，多出来的时间就可以多响应一些项目，这样一个实施人员同时响应两到三个项目是很容易做到的。8.2.2要推广的业务流不完整很多项目也做了一些验证工作，到了现场随着业务的展开，还是不断发现BUG。这就说明我们并没有建立一套可独立推广的完整的业务流，只能说在项目实施过程中我们只就部分业务流进行了验证，到了现场才发现实际业务情况并非如此，因而又陷入困局。而能否拿出完整的可操作业务流推广方案是项目调研质量紧密结合在一起的，项目调研完成后，一定要可以拿出完整实现的业务流实施思路和方案，这也是自我评判实施调研工作是否完成的一个尺度。如果调研完成了，只有一堆细节信息，却没有完整的业务流框架，这个调研对实施而言就不能算成功，这个阶段工作也就不能算结束，还要花时间搞清楚为止。但我们在调研过程中未必一定要搞清楚所有业务流和实现方案才能往下走，我们可以先解决完一个业务环节再往下走，把企业复杂的业务流程化整为零，形成相对完整的部分，用一个清晰效益目标牵引或做为愿景，促成企业一个业务流程一个业务流程不断前进。但对于单个业务流程而言，配置一定要完整，一定可以看到用这个系统把企业实际中哪一件事情真正走完了，然后还比较方便，甚至是前期不方便，但可以完整实现。如果实施不能得到这样的几个业务流方案，并反复站在用户的角度推想可能存在哪些问题，验证的质量就不会高，也不可能在现场顺利推广。如果每个项目都能做成一个完整业务流，只要有10个成功的项目，软件在很多方面就会达到非常优化好用的状态，再进行推广经验的移植效益将极大发挥。8.2.3和用户就推广实施方案没有达成一致有的时候，实施工程师也拿出来一些业务实施方案，但一进入推广，用户并不认可，要求按自己的思路来，这样经常是边推广，边争论，然后不断调整推广目标，下面的人就等待观望，我们不得不调整部署，重新开始实施过程，甚至是软件配置和功能验证过程。这样看来有清晰的业务实施方案也未必就能顺利推广，业务推广还必须和用户项目组达成一致意见。要和用户达成一致，并非是某个业务可用不可用，而是我们是否可以找准用户也可以认可的价值点。举一个例子，我们很多项目要求用户入库数据，以方便今后图档的管理和查询。很多用户一实施就不认同，反而要我们上工作流或项目管理。这样就项目推广目标没有达成一致，结果就容易反复，反复后用户可能发现没有基础数据工作流和项目管理也跑不好，最后还是搞基础数据录入，但一上一下的折腾过程中，大部分用户可能已经不看好项目实施。为了让用户认可推广目标对应的业务流，我们往往要想好关于业务价值的说辞，这个说辞推导要有力，而且有数据事实证明，而且有可清晰看到的价值，这样的业务才可能有人跟着走。换句话说，你想让别人做什么事情，一定要有一个可以看得到或者想象得到的效益可期待，否则业务推广目标很难达成一致，即使用户同意按你的思路去做，最终也一定反悔。就以我们说图纸是否可以方便查询是很重要价值点为例，如果仅仅强调这一点用户开始可能还不觉得，一旦录入数据开始就觉得怎么信息化尽是干苦力活？积极性很快就会演变成阻力。所以要推广自己的业务流一定要和用户项目组就推广目标达成一致，达成一致才能快速推广。事实上我们要先和用户分析如果图纸不好找有什么后果？能举几个真实的事例吗？如果好找真的有效益吗？为了这些效益值得我们投入这么大成本去做吗？如果遇到阻力领导会支持我们吗？这些效益和目标经过反复设身处地的换位思考，和用户项目组达成一致了，才能成为项目推广顺利进行创造条件。目标明确了只能说是大方向的事情落实了，和用户项目组要达成一致的事情还包括具体的策略，如何做才能保障这个目标实现？这个思路也要达成一致。还以图档管理为例子，原来的图纸不好找，需要解决，这个目标认同了，不等于事情可以启动了，还要和用户组就如何管理的方案达成一致。那么在系统如何管理图纸呢？我们可以以产品结构建立树状视图，我们可以根据各种特征建立分类视图，我们可以根据阶段建立项目阶段输入输出视图，我们可以根据文件类型建立关联视图等等，这些思路也要先和用户项目组达成一致，让他们觉得这些思路和方案不但能够解决问题，而且以往管理上的一些优点也可以被继承，这样的方案才比较有推动力。管理的思路明确了，如何去做也要考虑清楚，而不是走一步看一步。我们是安排专人录入数据，大家去利用，还是安排每个人都录入一些数据，逐步积累，我们是从新产品开始积累，还是把老产品数据也立即录入系统，我们每个人每天可分配工作时间大概是多少，这个时间段经过培训可以录入的数据量是多少，这样按一周数据录入量计算全部图纸录入完成大概需要多长时间，能否在系统实施可接受周期内，如何保障每个人的数据录入时间，如何组织培训，确保每个人都可以掌握操作。这些工作细节都需要沟通确认，而且计划分解得越详细，执行力越强。因为所有最复杂的事情都变成了很简单很小的独立工作，每个工作完成需要的技能都很单纯、时间很小，在落实时阻力就小。如果思路得到确认，我们就可以和用户项目组一起建立一个计划，落实我们的设想，再发动大家按计划运行。一旦计划确定，要立即行动，我们应按计划高质量完成工作，然后就是催促用户项目组按照计划完成他们的任务，并提供技术支持，这个阶段我们要明确技术支持阶段我们就不需要大面积现场工作，除非有系统不能解决的问题如果用户按计划在执行，我们还需要不断主动了解进度，形成一种进度反馈，根据进度快慢采取适当措施保障项目目标在实施周期内实现。实际上通过和用户就实施方案达成一致，我们也就传授了一个很重要的项目管理套路：认同目标，明确策略，建立计划，立即行动，不断反馈。可以说任何事情只要这样做，就很难失败。8.2.4没有激发用户的主动性一般情况下现场推广很多用户认为主要是靠软件公司来落实，的确在很多企业由于体制观念的原因，在这些方面需要软件公司多做很多工作。但实际上一个项目大量依赖软件公司人员推动，这个项目失败概率会比较高，越是成功的项目，用户主动性越强，用户才应该是项目实施的主体。用户自己的项目不是用户自己实施，却要依赖我们实施，这样的项目我们如何成功？我们之所以推广失败往往是我们把自己思路给用户一描述，甚至没有什么描述，就闷头大干，用户不知道如何参与我们工作，只好去监督我们，成为项目的监工，而他们又不清楚系统的思路和实施套路，只能按照领导意图来给我们施加压力，而不是和软件公司一起分担压力