山东青岛网站建设公司,效果图网站接单,北京软件开发培训机构,企业所得税怎么算2020目 录
前言
2 如何做业务调研#xff1f;
2.1 调研工作如何组织#xff1f;
2.2 调研准备阶段容易犯哪些错误#xff1f;
2.3 调研准备阶段容易犯哪些错误#xff1f;)
2.4 调研准备阶段容易犯哪些错误#xff1f;
2.5 现场调研阶段容易犯哪些错误#xff1f;
2.…目 录
前言
2 如何做业务调研
2.1 调研工作如何组织
2.2 调研准备阶段容易犯哪些错误
2.3 调研准备阶段容易犯哪些错误)
2.4 调研准备阶段容易犯哪些错误
2.5 现场调研阶段容易犯哪些错误
2.6 现场调研阶段容易犯哪些错误
2.7 现场调研阶段容易犯哪些错误
2.8 现场调研阶段容易犯哪些错误)
2.9 现场调研阶段容易犯哪些错误
2.10 现场调研阶段容易犯哪些错误
2.11 调研工作方法推荐
2.12 接口调研背景知识(上)
2.13 接口调研背景知识(下)
2.14 调研后续工作落实阶段
3 如何写解决方案
3.1 解决方案难写在哪里(连载十五)
3.2 坏的解决方案有哪些特征(上)(连载十六)
3.3 坏的解决方案有哪些特征(中)(连载十七)
3.4 坏的解决方案有哪些特征(下)(连载十八)
3.5 写好方案心得(上)(连载十九)
3.6 写好方案心得(下)(连载二十)
3.7 方案分类及用途(连载二十一)
4 如何做产品演示
4.1 什么是演示(连载二十二)
4.2 演示的目的
4.3 售前演示为什么效果不好(上)(连载二十三)
4.4 售前演示为什么效果不好(下)(连载二十四)
4.5 售前演示工作应如何组织(上)(连载二十五)
4.6 售前演示工作应如何组织(下)(连载二十六)
4.7 如何准备标准演示套路(上)(连载二十七)
4.8 如何准备标准演示套路(下)(连载二十八)
4.9 如何进行现场演示(一)(连载二十九)
4.10 如何进行现场演示(二)(连载三十)
4.11 如何进行现场演示(三)(连载三十一)
4.12 如何进行现场演示(四)(连载三十二)
4.13 如何进行现场演示(五)(连载三十三)
4.14 如何组织演示后工作(连载三十四)
4.15 演示方案准备经常考虑的问题(连载三十五)
5 如何做用户考察
5.1 前言(连载三十六)
5.2 典型用户有什么意义
5.3 典型用户应如何管理(上)(连载三十七)
5.4 典型用户应如何管理(下)(连载三十八)
5.5 用户现场考察应如何组织(上)(连载三十九)
5.6 用户现场考察应如何组织(中)(连载四十)
5.7 用户现场考察应如何组织(下)(连载四十一)
6 如何做公司介绍
6.1 前言(连载四十二)
6.2 哪些情况下需要公司介绍
6.3 正式陈述时常见错误
6.4 口头和会面介绍时常见技巧(连载四十三)
6.5 在客户处进行公司介绍三个要点
6.6 如何对在公司考察客户做介绍(连载四十四)
6.7 做好总部公司介绍的三个决窍
6.8 公司总部接待考察客户要注意的细节
7.1 培训工作在项目实施中作用(上)(连载四十五)
7.2 培训工作在项目实施中作用(中)(连载四十六)
7.3 培训工作在项目实施中作用(下)(连载四十七)
7.4 培训工作应如何组织(连载四十八)
7.5 培训注意事项(连载四十九)
7.6 总部培训
8 如何做现场推广?
8.1 现场推广工作可进行条件(连载五十)
8.2 现场推广工作为什么进展慢
8.2.2 要推广的业务流不完整(连载五十一)
8.2.4 没有激发用户的主动性(连载五十二)
8.2.6 边界总在变更(连载五十三)
8.3 现场推广工作如何才能做好(连载五十四)
9 如何做项目验收?
9.1 验收工作应如何组织(连载五十五)
9.1.3 主动沟通(连载五十六)
9.1.4 写好备忘录(连载五十七)
9.2 如何催款
10 如何做项目团队管理
10.1 前言(连载五十八)
10.2 好的项目团队构建要求
10.3 好团队的两个特征(连载五十九)
10.4 如何看待项目经理在团队中作用
10.5 团队建设心得和误区(连载六十) 1 前言
在IT行业特别是管理软件实施行业能够成为一个成功的项目经理是非常困难的一件事情一个成功的IT经理被要求熟悉计算机软硬件知识精通企业业务背景拥有良好的沟通技巧和说服能力当然在项目团队中还必须具有威信和执行力这样的人才简直是完人。
一般人即使努力也不可能达到这样的一个完美的项目经理的境界如果相信自己努力就可以做到可能是受哪些成功书籍的毒害太深。
更多的项目经理是拥有岗位并非拥有岗位技能但可笑的是往往是一个人刚刚被发现具备这样的潜质就会没有多少机会实施项目而是陷入另一种疲于奔命的状态。
因为一个具有丰富实战经验的人对企业最有价值的场合不是深入实施某个具体的项目而是进入售前。
管理软件销售是最合适顾问式销售技术但很难想象一个没有实际实施项目经验的顾问可以有效把握企业需求和打动对软件供应商本质上都保持狐疑的潜在客户这些都只有通过经验丰富的项目经理才可以做到。
如果一家软件公司的问题还是生存的问题这样优秀的实施顾问最合理的选择就是售前咨询顾问。很多用户往往在合作后感觉到售前和售后交流时存在巨大落差就是因为售前你看到的是已经证明过自己的顾问售后你看到的就是还需要证明自己的顾问。
笔者自己也是走过了这么一条路所以现在想一想做项目经理难做管理软件的项目经理尤其难五年下来忙得不亦乐乎。常常笑言自己是职业“三陪”陪客户交流陪客户考察陪客户吃饭。
不过和大量客户交流也的确从另一个角度丰富了本人的阅历也对整个管理信息化事业的建设从另一个角度(售前)增加了新的认识在本文本人将自己售前售后一些工作心得分为九种技能(业务调研解决方案产品演示用户考察公司介绍用户培训现场推广项目验收团队管理)分别整理成文希望能给在这个行业内拼搏的同道一些启发。
2 如何做业务调研
2.1 调研工作如何组织
很多人认为调研工作极难水平最高的人才能做好一次调研软件工程中也强调需求获取是最难的事情。有的人要么认为不过如此甚至是一个普通技术支持都可以做的工作。
现在有很多企业上管理软件之前都希望软件公司派人来了解情况提出针对性建议。这其实给很多软件公司销售经理出了个难题自己亲自上企业不信任而且也不专业请公司派咨询顾问过来资源难以协调响应不及时用户也不满意而且贻误商机随便来一个技术支持又不能保证调研质量在后续工作中也难以让用户信服。
其实难和不难在于是否用正确的方法做事经常用正确的方法做事人眼里是没有难事的。
虽然说调研工作质量和调研个人能力是直接相关的有丰富经验的人在很短时间内就可以完成高质量的调研取得被调研用户的认可没经验的人花费大量时间在现场了解情况可能还是给用户一个不懂行的印象。
但最有经验的人也不可能了解所有的行业他们对于一些陌生的行业一样可以将调研工作完成得很好我发现有经验的调研人员和没有经验调研人员最大的区别是他们是否按照正确的过程组织调研工作按照正确的方式做事自然会更容易取得成功有无其它行业经验只是成功调研的一个积极因素而已。
在一个有调研经验的业务人员眼里调研决不是现场调研这么简单无论是售前还是售后调研工作本身都可以分为三个阶段。
第一个阶段叫调研准备阶段这个阶段要完成调研计划的确认调研背景资料的准备两方面的工作。这个阶段工作质量将对能否顺利开展调研工作起到关键保障作用。
第二个阶段就是现场调研阶段根据调研计划完成各项调研工作并取得用户认同。
第三个阶段就是调研后续工作落实阶段调研结束后往往要准备产品演示技术交流解决方案等工作所以调研结束后一定要趁热打铁把后续工作落实到一定程度才能再做其它工作此时调研工作才能算结束。
这是很多人忽视的一点以为调研成功事情就结束了其实调研工作和后续工作往往不是同一个人准备高质量调研信息如果不能及时有效完整传递到后续工作者头脑中调研工作实际上是更大的机会成本丧失。
从商务的角度来讲售前调研还存在一个时机问题调研本身应该是商务策划中的一个环节。
很多商务人员和用户接触以后技术讲不清楚业务谈不清楚只好给一个模板化的方案给用户结果这种方案又没有说服力大家的方案高度雷同用户无法鉴别往往提出一个请求是否请安排贵公司业务人员做一个调研然后再提供一个针对性方案
有经验的销售人员还应该明白调研是一个适当实际要去做的工作不应该被用户牵着走应该是整个商务策划中的一部分不过这不是本文阐述重点本文将重点介绍业务调研需要的技能。
2.2 调研准备阶段容易犯哪些错误
一般接到一个调研工作任务后大家都会去编制一个调研工作现场工作计划同时进行一些调研准备工作。
根据我的观察在调研准备阶段大家常常存在这么几个错误。
2.2.1 第一个容易犯的错误不清楚调研的的目的
很多人编制计划写本次现场工作目的时往往是这样写的“完成项目现场调研工作”。
其实完成现场调研工作不是计划本次活动的目的而恰恰是完成本次调研目的的有效手段。
那么调研的目的到底是什么呢
真正的调研目的有三条
对用户让用户认为调研者已经非常了解或者有足够能力了解企业现有业务流程。
对竞争对手如果是售前调研还要随时制造给竞争对手的门槛了解竞争对手给我们设计的门槛。
对公司调研获得信息足够让后续者进入下一阶段工作。
我们很多人认为调研时一定要搞清楚企业业务可是一定要切记能够评价你是否了解企业业务的人不是你公司的成员而是用户。
如果用户都认为调研者非常或者有能力了解他们的业务他们自然也比较相信这个调研者的后续的解决方案或产品演示。
如果用户都认为调研者非常或者有能力了解他们的业务调研者说服或者高质量帮助公司的同事进行后续工作自然不在话下。
明白这个目的的人在调研阶段就会设计大量的机会不断强化用户对调研者的认同感。如果最终用户认同了调研者或者大量的用户认同了调研者无论是对售前打单还是售后实施就开始取得了最广泛的支持项目成功的机会就在不断的增加。
有的企业业务非常复杂企业用户自己都可能搞不太清楚不太可能在短期内了解全部业务细节特别是售前调研阶段用户不太可能有积极性花费大量时间配合进行调研工作这个时候调研工作目的就是要能让用户充分信服调研者所在公司或团队是有能力了解企业业务。有了这个信任基础后面很多工作也容易推进。
有的项目用户同时安排几家供应商在同一时间段或者在很紧凑的一个时间段安排几家供应商都用两三天的时间做一个调研此时所有供应商恐怕都很难立即对项目情况有一个完备的了解这个时候与其说调研目的是搞完全清楚企业业务流程不如说是让用户认为我们在这个领域最有经验最有可能搞清楚企业业务流程进而给竞争对手制造进入门槛。
所以在调研工作中要通过规范的业务程序让用户感觉到我们作为一家大公司的风范通过业务交流让用户认可我们在这个领域的专业知识和技能通过业务需求确认突出我们强项给竞争对手制造压力同时了解竞争对手给我们制造了哪些门槛灵活化解或者为后续技术交流工作提供可利用的信息。
我们调研工作质量越高认同程度越高对手压力就越大。一般对手在压力下出错的机会就越多我们了解充分准备也容易充分这样我们项目成功的概率就越大。
调研一旦结束调研者还要清楚一个环节调研后要做什么是做解决方案还是做技术交流还是做产品演示还是做实施方案 不管进行什么工作特别是在后续工作是公司其它同事配合完成的情况下调研者有责任有义务确认自己调研工作信息明确被需要获知这些信息的同事收到并理解并能很好开展后续工作。
做到这一点调研工作才能算结束否则调研者个人认为其调研工作质量很高后续者如果对调研情况不认同或者对调研业务报告不理解后续工作质量还是没有保障这个时候调研工作并没有发挥作用所以调研者就是从尊重自己工作的角度而言也要安排时间让后续人员认同和理解自己的业务调研内容。
实际上有效的团队在调研过程中会随时收集团队成员对调研记录的意见不断动态调整调研过程而不是在最后调研结束时一骨脑让团队成员吸收大量信息。同样有经验的人员在规划一个项目时也一定会考虑调研工作和后续工作的协同提前要求各个阶段人员及时沟通和配合。
2.2.2 第二个容易犯的错误计划不够细致
很多人调研计划落实具体活动的时候往往只有这么简要的几句某年某月某日在某地某部门进行业务调研。
这样写计划要么是不清楚调研从哪里下手只好先这样写着到现场再走一步看一步要么就是自以为有一些调研经验知道如何处理所以在写计划时为了糊弄内部分管领导好歹也写了质量上偷工减料。
实际上我们写一个计划写给谁看计划是我们给用户分管领导确认的用户领导对你的工作内容了解越清楚他帮助你安排工作就越方便。
用户领导或者有时候是用户协调人也一定希望我们在现场的工作紧凑合理不浪费彼此的时间。但用户并不清楚如何做这种调研他们能做的就是按照我们意见尽量安排合适人员配合。
如果你的调研是某几天要来你们这里调研的话语实际上用户领导可能会回答拿你们先来来了再说。结果现场大部分时间都在协调调研资源和等待上大量时间都无价值的浪费掉。
所以一份好的计划应该是可操作可执行的也可以让用户看明白的。
我个人建议计划不妨细化到每天的上午下午分别调研哪个部门需要怎样资历人员配合需要配合多长时间将了解哪些方面的业务问题需要准备哪些相关资料。这样也便于用户领导配合安排。
而且一份详细的计划做为开始正是恰到好处的体现了我们的专业背景和职业素养。还有什么比这更划算的呢我们只需要做一份合理的模板每次多写几个字就可以换来一个好的印象。
还有一点必须要明确的是写一份详细的计划并非一定要让计划时间变得很长。任何调研工作都不可能把所有情况搞清楚调研并不是一次就可以结束的事情。
实际上在一个项目中要随时有调研的意识一旦发现新的事实和历史调研不符合我们马上可以重新完善我们的调研结论进行相关调整。
所以知道这一点我们每次调研都有一个成本的概念调研的目的对内只是获得可以进入下一阶段工作的足够质量信息即可。
有时候一两天的调研也可以达到这个目的调研同样可以结束。
即使是一天的调研计划同样可以认真细致地准备。
2.3 调研准备阶段容易犯哪些错误
2.3.1 第三个容易犯的错误计划没有在内部沟通
很多人接到调研任务将计划写好立即就开始和用户沟通工作精神很好是不折不扣的行动派。
但是前面已经强调过调研工作不是一个单独的业务行为调研是承上启下的一个工作。所以我们的调研计划一定要征求客户经理参与过调研其它人员意见一些重点项目甚至是公司高管的意见看看是否还值得推敲。
最关键的是内部沟通计划的过程是和其它部门约定后续工作配合的过程通过内部沟通在完善调研合理性基础上实际上确定如果调研工作结束如何将我的工作移交给其它人便于其安排后续工作。
调研者不要匆匆忙忙搞完一个调研提交一份文档就投入另外一个项目。然后客户经理过了一段时间又要求演示然后演示准备者看着业务调研报告云里雾里的时候又无法和调研者当面深入沟通一下业务无法高质量开展工作。
所以做内部沟通的时候实际上也是调研者的一个自我保护和别人约定阶段工作的输入输出文档和质量要求那么做完这份工作后续同事也就能够独立开展工作而是是纠缠不清。
例如有的项目在调研阶段就要同步准备演示方案那么调研者最好在调研阶段就清楚谁负责这个演示配置并在调研期间约定和其有效沟通方式便于在调研进行时可以考虑如何准备。
如果很明确要进行这类工作但又没有安排演示准备人员。调研者作为一个职业人员我们至少要尽到提醒客户经理去申请资源提前准备的责任。
帮助自己团队成员少犯低级错误也是一个成熟职业经理人的心态不管你的工作岗位有多么重要或者不重要。
此外在内部沟通时如果是售前项目要考虑和客户经理沟通一个很重要的问题调研的切入时机。
一般情况下不要轻易的做第一个调研者做第一个调研者一定要安排能力强的人在用户关系不错的情况下经过调研做好工作给后续对手制造压力。
因为用户如果发现后续者能力不强或者不够职业会加强对第一个调研者的认同感。
但是如果你派的人能力不足那就给对手超越的机会此时再次安排调研已经很难挽回第一印象分。
不做第一个调研者除了规避这方面的风险之外还有一个比较大的好处不做栽树人要做栽果子的人。
很多用户往往并不清楚他们要购买的软件到底是什么东西所以第一批调研者很多精力要花费在灌输概念的工作上如果基本概念不清楚用户往往不能提出有价值的需求调研时往往没有边际。
第二个调研者再进行调研时用户就会清楚很多事情回答问题质量就比较高同时我们也可以有机会了解对手的牌进行针对性准备后发制人。
当然何时切入调研应该更多程度上是客户经理考虑的工作我们调研者至少要知道客户经理对这个问题是如何考虑的。此外调研一般要客户经理到现场配合所以调研计划行程安排也一定要得到客户经理确认防止出现意外变化。
不过说实话在这个行业内基本上客户经理是很幼稚的调研工作往往是盲目启动草草收尾。
2.3.2 第四个容易犯的错误计划没有得到用户确认
我们有的人把调研计划做好告诉用户形成就准备按计划去现场了这样的调研者不及格。
有的人会提前发邮件或传真给用户然后电话确认收到然后确认时间无问题然后再去这样的调研者60分。
有的人不但会确认计划时间还会认真了解计划内容是否认同和有相关业务人员配合得到肯定承诺后再去这样的人80分。
有的人还会准备一些前期调研文卷和资料准备清单让客户经理配合落实后再去调研这样的人100分。
我们至少要做到80分
计划发给用户后用户一般是不会认真看和落实的这是中国人做事的习惯特别是一些地位不高的联系人可能连为这个事找领导这个协调的胆都没有。
所以打电话确认的时候一定要请用户确认是否可以按计划进行得到肯定答复后再出发这样第一计划执行保障性会高一些第二也给别人留下一个认真的印象。
这个计划落实的工作也可以和客户经理沟通后请其利用其在企业的人脉落实。
最近我有一个同事就犯了一个这样的错误代理在合同签订后非常着急催促我们去现场落实调研工作这位同事就立即制定计划并发送给代理同时电话确认收到计划然后就立即按计划动身。
结果到了现场代理说用户还没有准备好你怎么就来了我们的同事也很郁闷计划上说如果有问题就打电话没有问题就不用打电话既然没有打电话反对当然是按计划执行。结果双方的开始很不愉快这就是不了解中国人的办事特点造成的中国人是预期性的事情一定要口头沟通确认担责任的事情一定要书面沟通确认。
2.4 调研准备阶段容易犯哪些错误
2.4.1 第五个容易犯的错误没有认真进行准备
调研要认真准备但说来容易做来难很多人调研前的准备工作其实都是很随意的。
没有经过认真准备的调研到了现场很可能对各种突发情况措手不及。
从应付各种用户刁专古怪的问题的角度而言调研准备永无止境。
好的调研准备工作可以包括这么18个方面
1、如果有的话一定要认真阅读商务合同和技术协议。
2、阅读前期技术方案和各类备忘录。
此点非常重要不仅仅要阅读还要保证自己工作质量和规范和前期保持一致一个行为高度一致性的公司是核心竞争力很强的公司。
此处有一个很重要的工作一定要向前期参加工作人员了解是否已经收集了一些资料并想办法获得已经搜集的资料和问题尽量避免重复询问这对用户会造成巨大不满。如果万一前期资料不能获得也要另外提前准备好说法避免这种情况出现。
3、和项目前期人员(咨询顾问、客户经理和平台主管)充分沟通。
听取他们的建议使自己调研更有针对性。
4、熟悉公司已实施的相近项目的情况。
他们企业业务调研报告和解决方案将对我们现在工作很有帮助甚至在调研过程中给我们很多思路上的启发。
5、熟悉相关软件产品的功能及发展方向。
很多人在工作中不注意和规划人员的沟通其实在调研前确认自己了解产品的发展方向现有和近期可实现的功能对调研时遇到一些很难回避的技术问题就可以做到心中有数提前想好说法。当然最好的说法是这个功能我们已经实现了在某某项目上也是这样要求的。
6、了解企业所处行业的行业特点、竞争态势、产品研发特点。
这些要从公司特别是网上查询资料分析建立一个基本的业务原型这样在调研时可以让用户感觉到我们还是做了很多工作对项目很认真。
7、准备同用户交流时的软件原型或交流PPT。
有的时候用户在调研过程中提出要我们做一个培训和软件演示的要求一般情况下我们应该避免在售前调研阶段做这个工作因为这些要经过精心调研仔细准备后再进行质量更高。
但在售后实施调研时我们可能要先主动做这个软件演示和理念培训工作收敛用户的思路引导项目边界所以调研者也应提前对这些方面工作做一准备。即使是售前也很难完全避免这个情况不但要准备而且在语气上还要有所区分。
8、准备企业业务调研问卷。不一定要给用户但一定可以让自己不遗漏该问的问题。
9、设计业务调研方案。业务调研方案可以将自己调研经验不断积累形成体系化的经验大家现在看到的文字就是我不断完善业务调研方案的结果。
10、设计业务调研计划。计划一定要用心用心才能做好。
11、准备业务调研培训材料。
到现场调研时需要让用户知道我们的调研方法和思路用户才好配合也认可我们的专业化程度这个应该结合公司流程和自己体会进行准备。
12、软件安装盘和加密狗。有备无患。
13、电脑笔记本。IT农民的必备劳作工具如果没有就用笔记本解决问题没有电脑前麦肯锡一直是手记录问题现在他们还是提倡手记录因为方便。
14、WINDOWS2000/SQL SERVER/ORACLE安装盘等常用工具软件安装盘。有时候很有用。
15、别的项目常用样例及标准配置用户很难提供明确需求的时候让他们看看我们在别的企业成功样例有助打开思路也体现我们给用户带去先进管理方式和成功经验的合作初衷。
16、公司各种流程管理文档。对于一些用户了解我们公司内部问题的时候如果搞不清楚该什么讲的时候不要信口开河翻翻资料再说。
17、可能涉及业务难点培训资料和问题集。
用户的问题千奇百怪多准备一点没错不断积累这些问题就是一个个人知识完善的过程。
18、公司小礼品。
调研完成后送给调研对象一个小礼品是很容易给对方留下好印象的机会。如果有政策一定不要浪费。
实际上我们每个做过调研的人扪心自问调研准备18条我们到底做了几条
也许认真不认真就是我们一个工作到底有没有质量的根本原因。
2.5 现场调研阶段容易犯哪些错误
调研计划确认抵达现场就需要进行调研工作。在调研工作阶段我们常常容易犯以下错误。
2.5.1 常见错误一立即进入调研状态
很多人非常努力一到现场就开始按计划进行调研工作。
其实调研计划到现场第一件事情不是启动调研而是再次确认调研计划。
这样做的理由有三点
第一虽然很多企业和你电话口头认同了计划但只有调研者到现场了才会真的重视所以我们必须要重新确认计划保证我们的计划需要的调研配合资源已经落实
第二确认调研计划往往不是和协调人确认要主动通过这个机会见一见企业负责的高管很多时候企业也会安排这个一次见面。和高管见面要做好三件非常重要的事情
一、汇报我们的计划请其再次确认并请其协调资源安排人员配合。
记住给领导沟通最有效方式之一就是“多请示多汇报”。根据我个人的经验一般领导看过的东西不如口头汇报的东西印象深刻汇报也是建立领导对我们认同的手段。
很多时候被调研人员不愿意配合我们进行调研因为这样可能会影响他们正常工作或者有其它顾虑所以当调研工作是领导的工作任务安排他们配合积极性就高了。
很多时候领导也不能立即协调完所有的工作特别是这个时候可以要求领导配置一个专门的联络人由他出进行联络工作可能的话也要求其全程参与调研这样的人会给调研带来极大方便。
二、汇报我们的调研工作方法让高管觉得我们做事很有套路同时请其提出意见做相应客户化调整。
在汇报计划的同时要顺便告诉高管我们调研工作方法先做什么后做什么每天需要如何开始要花费多少时间调研花费多少时间在整理是否要开一次业务分析会需要哪些人参加。
领导明白你思路了也就知道我们这些天工作量都会很饱满很有组织性也就对调研工作有信心并积极支持。
此外领导可能提出一些要求例如进行培训或者其它要求我们可以根据实际情况确定是否要进行或者不进行。此时就有可能需要调整计划内容和时间。
三、借汇报机会领导了解他们上项目的初衷。
很多时候领导看待一个项目角度和高度和我们进行下层调研人员理解是不同的这个时候和领导交流其对项目的想法是有助于我们在调研工作进行时判断一些业务需求是否真的符合企业领导的构思并可以寻求更好的方案。
从调研的角度了解不同人员对同一个项目的需求也是调研工作的一个内容。领导层往往是管理性思维业务层往往是技术性思维两种思维达成一致才能设计一个好的方案。这些都需要通过调研获得。
第三和高管见面要约定如何汇报工作的机制。
调研如果有一段时期不可能天天找领导汇报也不能不汇报那么这个时候就可以请示领导每几天安排一次当面汇报还是书面汇报。
多和领导见面多用肯定语气沟通就会让领导不断强化对我们积极的印象逐步将感情的天平倾斜到对我们有利的方面。
不过有一点首次和高管汇报工作原则一定要言简意赅不要表现自己。
让领导建立对自己个人专业认同感就可以说达到目的了对于一个领导认为有专业技巧的人见面的机会他是一定会继续提供的所以不要追求一次搞定这都是极为有害的冒进思想。
低调切入等调研过程中收集足够事实了再根据情况确定是否逐步抬高调门表现自己的思路是更稳妥和合理的策略。
和高管见面可能存在一个时间不确定因素。所以在调研准备阶段计划确认时尽量先保证这个时间如果到现场时间不能保证必须留机动调整的可能一般情况下可以进行企业历史企业现状网络硬件组织机构等方面的业务调研也可以为领导见面提供沟通的素材。
此外高管并非一定是企业的最高领导高管是依据企业规模和项目规模动态确定的一般选择汇报高管对象的原则是对项目直接负责的人上级或以上级别的人。
企业大了高管并非只有一位有的汇报必要时该重复就重复不要给别人不尊重的感觉。
2.5.2 常见错误二匆忙地进入调研状态
计划一旦得到领导确认很多人就立即着手调研这个时候容易犯的错误就是匆忙地进入调研状态。
进行具体调研业务前首先是和企业调研协调人确定今天一天的调研计划和资源可以到位如果万一今天计划所在配合资源不在给企业调研协调人几个替代性调整方案其负责落实到位后才能放心的开展调研。这就避免出现上午调研完了发现下午没有人配合了的情况。
这个提前预约时间即尊重被调研用户又让被调研用户有所准备保证质量。
那么安排用户配合调研工作在可能情况下一定还要得到其直接主管领导的确认让访谈者上司出面安排会面会保证调研者的积极性他就不必担心调研影响正常工作而导致直接领导不满。
这些工作完成后还不以开始调研而是针对所访谈的对象再一次回顾自己要问的问题理清发问的思路不要想到什么说问什么。
想清楚后就可以开始调研了但和被调研对象见面不要三句话不到就立即进入主题必须有一点点铺陈才能展开调研。
这个铺陈包括三个方面第一是自我介绍有时候还包括公司介绍调研者也是公司的活名片第二是了解被调研者的背景对其配合调研表示感谢顺便奉承一下例如说能得到您这样有经验人员配合是我们非常高兴的事情让其有一个好心情开始配合调研工作第三是对调研总体内容和时间有一个说明说明我们想通过调研能为其业务设计好的信息化支持手段让其配合时做到心中有数乐于协助。
做完这些工作才不是匆忙展开调研工作。
2.6 现场调研阶段容易犯哪些错误(二)
2.6.1 常见错误三不断地问问题唱独角戏
很多人在开始进行调研的时候准备了一份业务调研问卷所以在调研的时候就按照调研问卷开始提问这个方法对刚开始做调研的人是很有用的可以帮助他在对业务不熟悉的时候不至于无话可问。
但这样调研的后果就是调研者在唱独角戏。调研者不停的提出问题被调研者不断的再回答好象成了一种审问和被审问的关系这样的调研状态虽然可以收集大量信息但从调研角度而言不是最佳的选择。
真正有经验的调研者首先是先向用户了解整个业务过程在具体业务过程中顺便了解我们想重点关心的问题。
被调研的用户如果没有经过精心准备是无法回答很多具体的问题的他也不知道你为什么要问这些问题这样的问题问多了用户一定很厌烦也会产生一些戒备心理。
但是所有用户一定很熟悉自己每天进行的业务并知道业务中他感觉比较痛苦的一些问题。所以调研的方式应该是站在用户的角度了解业务有了一个对业务的总体认识再了解细节也就更深入和细致。
所以好的调研者要充分的让用户讲话自己只是在提话题让用户有兴趣有心情把自己知道的事情完整有序地讲明白。
举一个例子我们做PDM调研的很多关心你用什么设计软件产生哪些格式每月设计几个项目产生多少图纸但如果是一个个问题这样问下去对用户而言的确是一种折磨。还不如问他你每天设计任务是如何获得的如何开始需要哪些资料参考做完了以后形成什么文档交给谁在这个过程中您觉得什么地方不太方便在整个业务调研过程不断顺便问一句这样的任务你每个月大概接多少多的时候多少少的时候多少每次出图量多少用什么软件设计为主之类的问题。
这样交流的好处是用户对熟悉的业务可以很自如的进行表达和沟通而不至于让整个交流变成一个单向的信息收集交流的气氛会越来越好问题也会越谈越深入而不仅仅停留在一些准备的表面问题上。
而且很多问题在一次业务沟通中就交流完成了不需要反复去问增加被调研者的工作强度也节约了调研者的时间。
一个小块业务问题问完后立即要做的一个工作也是很重要的工作立即主动复述用户所讲的业务和过程让用户确认你明白他所说的内容。
当用户发现他说讲的内容你可以理解并接受的时候是很高兴的第一觉得自己没有白讲第二他就开始认为你也是比较熟悉业务或者有能力熟悉业务的人员了第三如果发现复述有什么不对可以立即纠正。
所以调研不是调研人员的独角戏而是用户为主介绍我们只要起到引出话题复述内容的作用即可。一个滔滔不绝的用户应该是一个成功调研的特征。
调研结束后一定不要忘记的一句话就是感谢
感谢之余还要请用户有时间审核我们的调研记录。
根据麦肯锡的建议有些人在快结束会谈时可以再提出一个相对敏感的问题这个时候问题人容易放松会有心情回答一些一开始不愿意回答的问题这个办法有时候可以试一试。
2.6.2 常见错误四不注意收集异常的事实挖掘背后的需求
很多人做调研问问题很积极沟通也很有技巧但是就是缺少一些职业敏感很多很有价值的信息用户已经说出来了就是不注意。
一般多次调研的人很容易发现很多业务在不同的企业都是一样的渐渐在调研中失去新鲜感其实调研不是简单了解企业业务流程而是要找到业务流程中问题。用户请我们来就是准确发现问题然后再提供解决方案的。
可以如何发现问题呢
问题往往是隐藏在意外事故之中的如果听到一件和流程不符合的事情或者和管理预期不符合的事情这些事实就是异常的事实值得我们高度重视深挖穷究。
为什么会产生这个事实原因是什么这个原因到底是什么产生的一层一层了解下去就象拨笋一样最后把事情分析得很透彻和明白了问题的解决思路也就出来了。
比如有的企业更改非常多很多调研人员就写上一句更改管理业务很重要。或者更改管理是要重点解决的问题可以为什么企业有这么多更改呢这样一查下去就会发现不同企业造成更改的原因是不同的不同的原因自然要用不同的药去诊疗才能收效。
如果我们不关注细节不收集大量支持我们的事实等我们真有机会见高管的时候我们又怎么让企业领导相信我们这些相对年轻的人可以找到企业的病根并有好的解决思路呢
唯有事实大量的事实会帮助我们说服企业的领导支持我们。
所以在调研过程中要随时分析现有流程存在的问题而且一定要找到事例证明问题存在并事后分析可能存在的改进点。
打动用户的力量就在在于你对其业务了解的程度
2.7 现场调研阶段容易犯哪些错误(三)
2.7.1 常见错误五每天调研工作时间太长
有的人有一个习惯喜欢把调研工作都完成后才开始写调研报告认为这样有整体感。有的人每天从早调研到晚用个把小时整理下调研记录。这些都是不好的调研习惯。
其实每天调研的时间一般不要超过四个小时
对每个个体一次访问的时间也不要超过两个小时
四个小时的调研内容是需要用同等长度甚至更长时间整理才能成型成体系的所以在每天的调研计划中必须要和企业沟通好我们自己的工作方法保障我们整理调研内容的时间。不要让用户以为我们每天没有调研的时间没有在工作实际上为了整理四个小时的调研内容往往要用掉八个小时。
如果要想控制每次调研时间又不至于遗漏关键信息比较好的方法有两个。
第一是将要调研的问题结构化建立结构化的问题可以方便自己快速把调研信息转换成调研记录也容易防止遗漏问题。
问题结构化就是针对一类业务将一组相关问题形成一个开放性和封闭性的问题引导区这样在短时间内可以把一个业务快速搞清楚被调研者也容易顺着业务思路解释。
第二就是尽量不要一个人调研应该两个人调研如果两个调研者中有一个是企业项目组成员就更好因为大家可以一起在调研中互相补充可能会遗漏的问题。而且可以一个主问一个主记合理分工提高单位时间内的调研生产率。
调研完成后要及时迅速把调研内容转化成文字而且要转化为结构化文字不是用户说什么我们写什么。这样做有很多好处
第一避免遗忘好记性不如烂笔头调研过程中不停把信息记录在本子上但可能还是有一些遗漏必须用一些时间趁着大脑有印象赶紧补记下来。
第二写记录的过程就很容易发现一些自己感觉清楚但实际上并不清楚的内容这些内容马上可以形成第二天的问题进一步确认把调研逐步推向深入。
第三每天写清晰完整的调研记录可以立即反馈给用户确认修改用户也会认可我们的职业精神和专业水准而且每天都看到具体的工作内容记录工作成果也容易得到确认。
第四可以反馈给公司相关同事让他们立即提供反馈意见调整调研进程。
第五整理的过程就是对企业问题深入思考的过程这是一个很有趣的脑力劳动。
有的人想在这些方面偷懒不随时注意整理调研信息最终调研报告质量就不会太高缺少深入的分析也就不能为后续工作提供有价值的信息。
2.7.2 常见错误六聆听而不是提供解决方案
有的人在用户提出一个疑难点的时候很希望把自己的产品特色展示出来花了大量时间讲自己的卖点和特色给用户做了大量启蒙工作。
当然有些用户还会对一些特色功能念念不忘并拿来要求其它供应商提供。
其实在调研过程不是做解决方案的过程调研就是为解决方案奠定基础的过早在调研过程中提供问题的答案有如下坏处。
没有经过精心准备的演示可以有几个亮点但很难形成整体打动别人决定性力量反而浪费了调研的时间影响了为有价值解决方案制作的调研时间。
提供解决方案往往是临时思考没有经过全面分析难免偏颇为了表现能力而承诺一定可行的内容发现实际上并不是那么容易导致后期实施骑虎难下。
做项目不是一个人在做而是一个团队在做如果没有沟通就向用户提供了自己的思路可能会给整个团队的思路带来干扰解决方案一定要在内部达成一致才能提供给用户。
一些的确非常成熟有特色的业务解决方案可能会提前泄露给竞争对手对手可以针对性进行准备导致杀手锏失灵。
所以调研过程中不要过多花费精力介绍我们的产品而是做一个好的发问者和聆听者用耳朵去听用心去想用大脑去分析用户的信息去发现有价值的内容。
2.8 现场调研阶段容易犯哪些错误(四)
2.8.1 常见错误七没有开业务分析会
很多人做完调研就按计划打道回府准备后续工作其实有经验的调研人员还会多做一个工作就是开一个针对企业领导、项目负责人和主要业务层面的调研工作汇报会。
我们说调研目的是让用户让用户认为调研者已经非常了解或者有足够能力了解企业现有业务流程。
单个用户是否建立这种认识我们是通过复述技巧实现的。但对于企业领导又如何知道我们了解企业业务呢
有人说这些将在解决方案中完整体现不过说实话有几个人相信我们这些管理供应商写的多达百页的文档企业里会有三个以上的人看一遍
都是在浪费纸张而已
所以在调研完成之前在调研计划中调研者应主动安排或者创造这么一次汇报的机会专门陈述我们对企业业务和要解决关键问题的认识这个认识陈述好了企业自然对供应商刮目相看就算有一些偏差也可以立即得到纠偏的机会。
这个汇报会时间不一定要很长但可以让企业领导真切感到我们调研工作的成效我们对事实把握可靠程度我们对企业业务了解深入程度我们对问题分析细致程度我们在该领域的专业程度即可。
有了这个阶段性总结调研工作就可以说顺利完成了可以进入下一阶段准备工作了。
不过在业务分析会上一定要注意一点不能用过高的姿态切入。
有的人经过调研确实发现了企业一些问题也想到一些很好的解决思路。于是其在业务分析会上企图指点天下痛陈不足确有严加改进必要的时候就有可能犯一个大错误的时候。
有了表现欲就容易昏头。
业务分析会一个铁的原则就是不要轻易说自己用户的不足即使要说也应用一种委婉的方式表达指出可进步的地方而不是指出落后的地方。指出不受控的地方而不是失控的地方指出实现不方便的地方而不是指出无业务管理覆盖的地方。
这些都是做业务分析会要替自己客户考虑到地方不要随意批评别人不足也不要以为企业没有人知道这些毛病更不要以为他们不知道这些毛病该如何解决有时候无非是外来的和尚无牵挂好念经而已。
2.9 现场调研阶段容易犯哪些错误(五)
2.9.1 常见错误八只重视正式沟通不重视非正式沟通
调研工作特别是在正式调研活动中有些问题并不方便了解所以调研工作还包括一些非正式场合这些场合适合调研者问一些相对敏感或者自己有看法但没有把握的问题。
所以调研不仅仅在工作计划中所列走访座谈会议等形式中也在和用户一起聚餐等非正式沟通活动中。
只要调研计划没有结束所有的时间都是为调研而准备的走路闲谈吃饭都是可以进行调研的机会不一定要正式场合才能开始调研。
这种非正式沟通信息一样很重要而且往往是真实运行企业的信息和正式调研得到的信息正好可以互相印证。
在非正式沟通中调研者还可以和企业一些人建立友好的关系为今后工作也奠定了良好的基础。
所以好的调研者不仅仅是一个专业人员在非正式场合也是一个可以让别人说话的人这样的调研行为才是完整的。
2.9.2 常见错误九关键业务只询问了个别人意见
一些业务在整个调研工作中是占据很重要分量而且涉及多个业务部门这个时候调研就要记住“兼听则明偏听则暗”一定要把业务涉及不同部门意见都听到也要把不同人对同一业务描述进行对比调研从中能发现很多错误。
此时不可因为觉得调研内容很饱满或者时间紧张而只做单点调研关键业务一定要从其它人那里不断得到印证。
不过再问第二个人的时候就可以用主动复述业务的方式请其重点指出不对的地方加快调研进度。
2.9.3 常见错误十调研时有选择问问题
有的调研者在调研阶段就非常小心特别是在其对自己软件不足的地方有足够了解的时候总想在调研阶段引导用户接受自己的系统绕过这些自己产品不足的地方这也是一种错误的做法。
首先如果调研发现用户迫切需要很有价值的问题是公司目前不能解决的问题并不等于不调研就可以回避无论将来在技术答辩还是售后实施这个问题总是要冒出来与其回避不如主动搞清楚汇报给公司看看到底有什么办法可以解决。
真正的问题都是回避不了绕不过去的。
我个人意见越是有公司明显不能解决的问题越要调研清楚搞清楚来龙去脉为公司今后产品发展提供完整的需求建议作为一家负责任的软件公司首先要承认自己的软件不可能解决所有的问题但一定要在发展过程中逐步解决更多的问题调研时都回避了不就失去了公司产品发展的机会了吗
其次如果有选择性问问题就会遗漏一些关键性业务这样对调研整体质量有影响在后续工作中容易被动。
至于不想将用户一些天马行空问题或者的确不想引发他们高度兴趣的问题回避的方法不是不通过调研而是认真记录但不提供在正式文档的方式规避。
很多人很多需求都是一时灵感没有经过认真思考所以口舌之快过了也就过了不形成文字记录他自己也不记得自己说过什么了。如果是真的关键问题在后续复述确认调研记录还有业务分析会上还会提出来的这个时候再确定写入正式文件也不迟。
对于这些暂时不能满足的需求和超出范围的需求可以另外整理一份内部文档给公司分析。
2.10 现场调研阶段容易犯哪些错误(六)
2.10.1 常见错误十一一次调研就企图锁定需求
很多项目启动后轰轰烈烈进行了一次深入调研然后开始配置开发实施忙得不亦乐乎。好象把企业问题搞清楚了就应该是实现和解决的阶段。
实际上很少有人能够在短短几天内把企业的问题搞清楚即使你努力进行了半个月甚至一个月的调研在实施过程中你还是会发现对很多问题认识我们依然不够深入不够完整。
这个时候我们应该意识到我们依然还需要进行调研切不可因为是大规模调研完成了对此时的调研就随意了不留记录不进行确认了。
事实上这些调研信息要随时记录确认并最终完善到项目解决方案中可以这样说信息化项目中始终要有随时开始调研的意识如果我们承认信息化需求是无止境的话那么调研也是无止境的。
为什么不能通过一次调研锁定需求呢
正确的需求是系统成功的关键。预先锁定需求的假设前提是用户不经过系统上实践的过程用户就能预先精确的提出所有的系统需求。
某些简单软件或者具有极高技术水平的用户可能可以但是一般情况是用户只对其目标和需求最初只有模糊笼统的认识许多细节都不清楚。要求一个只有初步设想的用户或个别用户负责人准确无误地说出全部需求显然是不切实际的。
用户为了证实和细化他们的设想往往需要在某个系统上持续不断学习和实践的过程。特别是在大型管理系统软件上。
即使经过深入细致的预先锁定需求的工作当人们实地观察和使用了目标系统以后也常常会改变原来的某些想法对系统提出一些新的要求以使系统更加符合他们要求事先锁定需求的方式其实也会经过多次反复甚至完全失败。
大型软件的开发需要系统分析员、软件工程师、程序员、实施经理、用户领导、用户负责人、具体用户等众多各类不同层次不同技术水平人员的一致协调努力因此良好的通信和相互理解对于保证工程成功至关重要传统的需求锁定方法假设使用适当的文档可以做到项目参加者之间清晰、准确、有效的沟通。但是各种文档本质上是被动、静止的通信工具通过它们来理解一个动态系统是困难的。
用户变更需求是正常的用户没有实际操作过软件之前无论你怎样描述都会有对软件功能理解不一致的地方可能是技术协议上书面文字表达一致但对实际软件操作理解不一致可能根本就是不用不知道哪里不适合自己的需求。
打个比方就象买衣服无论别人怎样推销客人一般都会试一试觉得合身再买我们一般比较大的项目都没有让用户体验过而且在推销时说了很多动听的话自然期待高失望也高而且用户为适应ISO认证或PDM/ERP系统必然伴随组织机构和业务流程重组这里面有很多反复的过程对应的文档设计流程对软件操作提出变更是正常的。
我们的问题不再于要用户不变更需求而在于找到一种方法让用户认识到我们的软件能发挥作用当有新的需求时通过使用我们软件建立的信任关系重新形成新的业务这也是调研时要保持一种理念。
2.10.2 常见错误十二调研工作表现不职业
有的调研人员工作很努力但在现场很难得到用户的认可就是因为经常表现出一些职业不成熟的缘故甚至有的表现是不道德的。
常见不成熟职业表现有
1、 不征求用户同意就翻看其资料(如果有的竞争对手敏感资料想获得也一定不要给别人看到)
2、 调研过程中电话短消息不断
3、 在用户现场上网工作时顺便聊天看和工作无关的内容
4、 没有征求用户同意使用用户电话
5、 用户同意使用电话讲起来没完没了
6、 对用户现有各方面状态流露轻视的态度例如认为用户条件不成熟管理不到位表现出眼界高人一等的想法。
2.11 调研工作方法推荐
2.11.1 每日调研流程
1、提出调研内容请企业项目组成员配合预约人员时间安排访谈
2、访谈
3、当场复述内容确认理解对方表达的问题
4、立即将整理访谈结果形成文档记录确认需要继续了解的内容和未清楚的内容
5、如果需要安排时间请被访谈对象确认访谈文档记录特别是一些关键名词定义部分
6、和企业项目组成员配合约定下一时间段访谈安排。
2.11.2 访谈成功的九个要点
让访谈者上司安排会面
调研前应向调研者介绍调研内容和时间大概安排让其心中有数
聆听不要发表指导意见要靠和用户交流发现问题核心所在
随时收集和记录事实寻找异常现象发掘管理改进需求认真记录并探讨原因
尽量两个人一起采访最好一个是企业项目组的成员
复述、复述再复述
一次不要问得太多
在结束会谈后又提出一个问题
访谈结束后一定要表示感谢
2.11.3 良好的结构化调研顺序
先了解企业基本情况和项目组成员情况由此建立对企业初步认识对项目有个初步判断
再了解企业组织结构和岗位设计由此确定访谈对象
再逐个按照业务口了解业务流业务流要关心业务可以划分为哪些阶段每个阶段应该是相互独立彼此穷尽的。
每个业务阶段要问清楚业务目的输入数据和输出数据过程步骤每个步骤的负责人什么时候开始什么时候结束。
输入数据其什么作用有哪些信息传递到输出数据中。输出数据又起什么作用是指导下游还是反馈上游。
业务流程调研质量评判标准就是能否清晰简明画出企业业务流程图和数据流程图。
2.11.4 售前和售后调研的不同
售前调研一般是为产品演示技术交流做准备同时调研过程要注意突出自己强项给竞争对手制造门槛。
售后调研一般是为解决方案项目实施做准备同时调研过程中要注意寻求项目价值点利用价值点置换项目边界尽量把项目边界最小化项目才容易成功和受控。
售前调研一般由商务主动和用户协商时机根据实际情况确定先调研还是后调研。售后调研必须尽快启动而且应该在项目启动大会后展开调研。
售后调研前一般要和企业高管亲密接触取得支持。在启动大会上对调研方法和需要取得支持告诉企业配合人员后进行。
售前调研一般要协助拿项目所以不要轻易发表对问题倾向性看法要了解事实用比较文饰的语言表达对问题的认识通过对事物认识深度获取支持。售后调研可以相对直接提出问题摆事实陈厉害争取最大范围重视进而获得支持。
2.11.5 如何写调研日志
调研日志有三个要求工作过程清晰化调研内容结构化不明内容有后续计划。
首先调研日志上要看出本日你调研了哪些部门走访了哪些人用了多少时间获取了哪些业务的信息这就叫工作过程清晰化。
然后调研内容不能是流水帐记录必须将被调研者的话组织成一个个合理的单元这些单元独立可以反映某个业务层面的情况然后整体上构成一个业务调研报告的部分。
不同的信息结构化方法可能不太一样有的适合用表格有的适合用文字段落有的适合绘制图形(例如框图鱼骨图等等)。
调研日志最后要说明今天调研中还有哪些问题需要进一步明确并有认真记录。
2.11.6 如何写调研备忘录
调研备忘录一般情况下并不是把自己调研日志的内容汇总重新罗列因为调研日志和业务调研报告就是做这个工作的。
调研备忘录和一般的备忘录一样主要是说明本次现场工作进行了哪些工作内容达到了怎样的目的和企业约定的下一步工作安排是什么并得到企业负责人签字认可。
备忘录主要让用户看到我们做事的规范性而且在今后合作中将不断用同一格式备忘录强化我们在规范上的一致性同时备忘录要让用户感觉到我们本次现场调研工作时间紧凑内容丰富层次清晰让用户对我们形成良好的印象。
2.12 接口调研背景知识(上)
现在管理软件项目中接口需求很多很多项目接口实现得并不理想原因就在于接口协议质量不高而接口协议是和接口调研紧密相关的。一般接口调研和其它调研方法是一样的但要做好接口调研就必须具备一定的专业知识这可能是能否做好接口调研的关键。
接口协议除一般性协议要素外应该包括如下内容
2.12.1 接口技术实现方式
接口方式最高级一种是主动式。
即通过直接对其它软件的数据库进行操作。这种方式因为涉及到对用户数据读写操作对于对方软件而言安全性是最大的问题验证的复杂程度也最高。主动式基本有两种方式
1)DATA方式通过数据库语言对数据库进行直接读写。这种情况要求对对方数据有详细认识。需要对方的人员可以提供数据库的详细资料。为了保障数据的安全要界定对读写要求。一般和用户自行开发的系统会比较多出现此类要求商品化ERP很少提出这种方式。
2)利用其它软件提供的工具。除了直接对数据进行读写外有些软件也提供了一些工具(可能是控件函数脚本等)。可以通过这些工具对数据库进行操作。例如现在神州数码易飞ERP就全部采用控件方式接口。
这种情况下要提供这些工具的详细使用说明。
接口方式相对主动式的就是被动式开放。
同主动式对应即开放软件商自己的数据库或开发接口给其它供应商读取数据。这种方式涉及到软件商提供的数据或开发程序。对方要我们的哪些数据将成为了解需求的重点。按提供方式的不同可以分为以下四种。
1)DATA方式。即开方我们的文件或数据库格式给对方。由对方软件直接读取数据。这样的情况一般在企业有开发能力而且只需要信息提取(不是写入)时才使用。这种情况很少。
2)脚本方式。早期的脚本语言多是一种专用高级编程语言。实现了基本的程序流程语句简单的数据结构在此基础上提供访问软件内部数据的语句。通过这类专用语言用户可以对程序进行界面配置实现简单的功能扩展给用户提供了一定的灵活性。而只需用户懂一点程序设计知识即可。这类语言的缺点是没有通用性功能有限由于解释执行速度受到很大限制并且应用软件开发商实现专用编程语言及调试环境有较大难度。对于应用程序需实现三个要求就可拥有脚本语言编程接口
A)应用程序的对象模型
B)适合应用程序对象模型的对象
C)脚本语言编程引擎
前面两个方面需要应用程序用组件对象模型的方式构造。采用组件方式是软件开发的发展方向提供对象模型是一件很自然的事情。第三个方面有通用脚本语言编程引擎供选择微软的ActiveX脚本编程引擎可以免费使用VBA脚本引擎需要购买。ActiveX脚本引擎实现了基本功能没有调试环境。VBA是一种通用编程语言其核心就是应用广泛的VB拥有大量函数支持窗口编辑能力强大的调试环境。很明显微软希望VBA成为应用软件二次开发的通用语言。例如CAPP和国外PDM的接口就属于这种开放方式。
3)链接库方式。基于结构化的软件可以提供软件内部使用的动态连接库供用户使用。动态连接库是速度最快的接口应该说是一种很好的选择CAPP目前的二次开发接口就属于动态连接库方式。
但是动态连接库在接口升级时会遇到麻烦用户程序难以和正在运行的应用程序进行数据交换。用户也难以使自己的模块(用户实现的动态连接库)嵌入应用程序。因为动态连接库的通常首先实现的(至少要定义输出函数接口)而后才能使用动态库。但应用软件开发时用户实现的动态库根本不存在AutoCAD的ObjectARX用一种特殊的机制才使AutoCAD可以使用用户开发的动态库。目前国内很多AutoCAD二次开发软件就是使用ObjectARX开发的可以完全的嵌入AutoCAD。
4)COM组件方式。COM对象接口基于组件对象模型的软件可以提供软件的COM对象接口。组件应用程序由多个组件打包而成组件之间的联系是一种松散耦合使其中某个组件的改变不影响其他组件应用程序修改改进变得方便。这就如同一台复杂的机械设备的各种零部件用螺栓连接起来零部件可以轻易更换。而传统应用程序就像所有零部件都通过焊接连接的如果要改进只能重新做一个新的。组件程序由于由许多具有位置透明性(无需知道组件的位置)的组件构成可以很容易实现分布式应用。组件架构强调实现对象模型开发接口是基于对象的符合用户的思维方式比动态库提供的API更易于理解使用。组件是完全与语言无关的,任何过程性语言够可以用来开发组件根据不同的需求可以轻易的用不同语言开发应用程序的不同部分用户可以选择任何过程性语言做二次开发。通过COM的底层机制可以访问运行中的应用程序对象实现与运行中程序交换数据。用户组件也可以易于嵌入应用程序中。COM的主要问题是运行速度比动态库慢特别是自动化接口对系统稳定性要求高于动态库要求系统的COM平台能正常工作。
最常用也是最安全成本最低的接口方式是中间文件接口。
双方的数据交流通过中间文件进行。这种方式由于比较灵活接口双方都比较明确工作。而且重要是的接口双方的软件升级对于接口本身(对方软件本身)可以说没有影响。是目前采用较多的接口方式。
如果是中间文件的还需要确定是全量式接口还是增量式接口。
接口本身是为了双方数据可以保持交流和数据一致性进行的。一方提供数据另一方根据对方的数据来更新自己的系统的数据。所以对于哪些信息是新加哪些是删哪些是更新要进行判断。从数据提供方而言可以提供以下几种
全量按软件数据内的数据提供全部的数据不进行区分哪些是增哪些是删。这种方式需要用户对比自己内部的数据进行区分哪些是增哪些是删。
增量由数据提供方进行对比后区分哪些数据是要更改的哪些是要删除的。对方软件根据数据提供方提供的文件直接更新数据库。这种方式的重点是要掌握同什么数据对比得出增减记录。另外对不不同的记录(增/减记录)是提供不同的文件还是在同一文件内对于不同的记录做上标记也是要定义的。此时可能就要在接口字段上定义更改标识更改单号版本号等信息。
2.13 接口调研背景知识(下)
2.13.1 接口内容
接口方式一旦确定就需要确定接口的内容。
接口内容首先要确定接口入口从哪里开始汇总接口数据接口数据每次包含多少对象这些对象是如何联系在一起的。例如接口数据每次都从一个完整的产品上开始汇总或者从一个完整的工程任务上开始汇总或者从任意零部件上都可以发起汇总。
第二接口内容要确定接口时机要明确哪些字段由数据提供方(其它系统)写那些读在什么时候进行。也就是约定当数据达到怎样的规定后才可以启动接口输出此时也可以约定接口输出负责人员。例如当产品结构发布相关工艺数据也发布后才能启动接口如果有明确接口时机要求接口程序应适当做校验性判断防止提供不正确的数据给下游系统。
第三接口内容要确定接口格式。
接口格式包括明确数据交换提交的方式是文件级还是数据库级然后明确交换文件的名字存盘路径。
明确文件的格式包括文件或数据表包含的字段名字段次序字段类型字段长度分隔符(如是文本文件)是否必填默认值下游系统对应含义实际数据样例接口对应数据来源该字段在实际操作中填写规则。
第三接口内容要确定接口样例。
接口技术协议附件必须包括用户方提供的样例数据样例数据必须具备典型特性能够覆盖企业各种可能的实际数据情况保证验证样例数据对接口测试的完整性
如果一个样例不能覆盖可以提供足够样例数据用户方可提供多个样例直到可覆盖各种可能情况为止。
用户方要保证样例数据的规范性。此时可能还需要针对接口样例提供数据规范性录入操作说明。
依据所提供样例最终得到的接口中间文件将以完整实例作为验证标准依据。如果有多个样例则需提供多个完整的接口中间文件实例。准备接口样例将大大加快验证时间和接口程序调整反复时间也有利于企业供应商快速就接口协议达成一致性理解是看起来慢实际上最快的有效接口方式。
2.13.2 接口数据一致性握手方式
接口数据的一致性通握手方式来保障。一致性分为静态一致性动态一致性双向一致性。
静态一致性如物料编码信息原始工艺设计信息。
动态一致性如设计更改信息在一个系统内的数据更新后要求另一个系统内的数据也要进行相应的处理。握手方式即明确如何让对方系统得到要进行更改的信息(也可能是依靠人员来进行手工操作)这样对方系统对接口文件进行处理。
双向一致性复杂的系统甚至要求对方系统处理的数据结果要进行反馈。从而更新本身系统的数据。这里面也要对反馈进行定义。
2.14 调研后续工作落实阶段
2.14.1 如何写业务调研报告
调研结束后第一个必须尽快整理出业务调研报告业务调研报告主体内容可以在业务分析会上得到用户确认。
写业务调研报告应该结合软件供应商特点形成一个比较统一的汇报目录模板有了模板整理起来就快不同软件关心业务内容不同模板也应该不一样。
一般而言业务调研报告目录可以分为三个大的部分第一部分是业务基本情况介绍第二部分是企业业务流程图和数据流图第三部分是项目关键价值点。
凡是不设计业务流和数据流但必须要描述的内容例如企业的一些基础数据情况我们把其作为企业的基本情况介绍例如企业概况企业设计数据统计情况企业工艺数据统计情况企业标准化编码规定等等做基本情况介绍时要把握两个原则
第一是结构化不要散乱将相关性强的一组基本情况设计成表格填写这样既方便填写又不容易遗漏。
第二是按照调研先后顺序组织和业务流顺序尽量一致。这样不但层次清晰而且可以直接将每天调研日志内容复制修改就可以得到最终结果大大提高工作效率。
业务流程图和数据流图有大量标准工具和方法指导建议这里大家去找相关专门知识学习本文不在这里展开。
第三部分项目关键价值点是非常重要的项目价值点组织也必须符合结构化层次不要将很大的价值和很小的价值并列排放应该将最大的价值可以相互独立做为一层然后将小价值分别归类到不同大价值下形成一个价值支撑体系这个支撑体系也是解决方案的实现思路。
2.14.2 业务调研报告完成后续工作
业务调研报告完成后必须赶紧去找后续工作同伴按照约定的工作计划把调研报告交给他们如果有时间还可以安排一个内部业务分析会议做一个全面的介绍。
帮助团队成员可以准确理解调研报告启动后续工作才是一个调研的工作结束。
如果你能按照以上方法进行调研相信你的调研质量一定很棒这样的话不管后续工作是什么我相信你都会得心应手的去完成或者帮助你的团队成员去完成。
这也就是调研最大乐趣所在。
3 如何写解决方案
3.1 解决方案难写在哪里
3 如何写解决方案
3.1 解决方案难写在哪里
很多人对写方案非常没有信心一涉及到方案的事情就束手无策到处求人。
作为一个公认的方案打手意思是写方案就象打字员一样我觉得我在这方面确实是有绝活。
我基本上都是在方案提交前一两天接到写方案的任务而我自己的事情一般又比别人多一点也不能不做只好心里大骂一句骂完后就打电话搞清楚别人的要求边问就边构思整个方案的推导思路和结构提纲。
因为你不敢让你的同事知道你只能用很少的一点时间写方案(基本上我真正动笔写方案的时间都在2~4个小时以内)让他们担心方案的质量和进度保证进而对自己的后续工作质量没有信心。所以我其实也特别紧张注意力也特别集中大脑也高速反应基本上几分钟电话或面谈完思路基本就有了然后该干嘛干嘛找一些零散的小时间把思路不断推导一下然后到了一个比较安静和完整的时间段前才开始写这个时候基本上要写的话都想清楚了只需要不断敲字敲字的时候也是注意力也特别集中大脑也高速反应越写思路越开很快也就完工了。
写方案不难知道怎么写才难。关于写方案我只总结一点结构化地去组织你的思想。
有结构就有思路有思路就有方案。
另外真正写方案的人对自己写过的方案是永远不会满意的只有这样每次都会进步一点点解决方案水平质量就会随公司能力不断增长。
当然我曾经问过很多人你到底为什么写不出好的方案呢
基本上原因可以归为四类
3.1.1 第一种是没有体系
一旦用户要求提供关于PDM的方案很多人大脑是一片空白完全不知道从哪里下手。很多人说起自己的产品来好象知道不少卖点不过真要写出来又觉得无从下笔。
这种情况一般是写方案者不熟悉自己产品体系造成的知道一两个甚至更多的产品卖点不难但难就难在成体系知识就是成体系的点构成的而不是一句一句离散的说法构成的。
因为我们这个行业从业人员说句不客气的话大部分对所销售实施的管理系统并没有很深入的研究都是半路出家从头开始在学习过程中熟悉在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后才能够写出完整的方案否则就是一个单元也要费尽脑汁。
所以一个人要想写好一个方案首先要把自己产品的来龙去脉功能模块适应领域典型客户实施情况有一个全面的了解这样才能建立一个完整的知识体系然后逐步补充竞争对手知识和一些技术性知识不断深化自己的知识体系。
3.1.2 第二种是没有思路
有很多用户看多了模板化的方案以后想看一些针对他们自己的业务的个性化内容这个时候有的人按照标准方案模板修改还勉强能对付但对于个性化内容针对性方案就速手无策了。
这种情况从根本上讲还是写方案者不熟悉企业业务造成的写方案特别是针对性方案不仅仅要求了解企业的需求而且要知道这些需求是在何种业务需求下产生的用户提出这样的要求到底想解决什么问题把这个问题找出来一般针对性解决思路就有了有了思路自然可以很好的写方案。
所以一个人要写好方案还需要了解下游客户的业务了解业务最有效的方法就是亲自做几次详尽的业务调研有了业务调研做基础在调研过程中把握用户关注重难点问题自然可以比较好的确定方案的个性化内容思路。
解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。
3.1.3 第三种是没有素材
一般不经常写方案的人在写一个方案的时候即使有想法有思路但往往也会很累就是因为缺少足够的素材。很多项目现在都是投标不同用户可能有不同投标的要求这样很难用一个方案去适应所有的用户因此在每个方案中都有一些需要准备的内容。
这些内容基本上是通用的但如果没有足够积累每次编制方案就需要花费大量时间去准备造成方案完成周期过长。
所以写好方案必须具备这三个条件第一方案编制者对企业业务要很熟悉或者有相关业务调研经验第二方案编制者对产品非常熟悉至少对自己产品功能模块作用很清楚第三方案编制者手上有大量可公用的素材库。
3.1.4 第四种是没有层次
很多人刚和用户接触没有多久为了表现自己对客户的重视马上表示要提供方案当然有的客户刚刚开始选型也不知道到底要什么搞也要供应商马上提供一个方案。
结果拍胸脯容易写方案难自己写不出来只好求公司公司没有安排专人了解情况只好按模板制作一个用户一看几个供应商内容都差不多觉得不好又总结出一些个性化要求于是大家有开始折腾第二轮方案。
其实方案编制在不同阶段有不同策略不要轻易提供方案。刚开始接触是可以提供项目合作建议书类似可行性报告项目需要考察软件技术可以提供标准的产品技术白皮书到了经过售前调研有所准备在演示前后阶段和其它竞争对手刺刀见红的时候才在知己知彼的基础上提供解决方案或者投标书。
过早提供方案只能匆匆了事时间紧急质量自然不高自然也就觉得方案难写。想急就又能解决问题的事情本来就是一般人做不来的。
方案想要写得好一定要用心用心就一定要耗时间指望用几个小时写出一个高质量的方案是不可能的。如果你做了精心调研你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作明白了这一点大家都可以经过练习写出好的方案。
3.2 坏的解决方案有哪些特征(上)
3.2.1 第一个容易犯的错误只有论点没有论证
不好的解决方案粗看起来非常厚重其实都是功能罗列象产品手册摘要版不象方案书。
不好的方案是一大堆内容淹没在一堆纸里面也不知道想说什么给你一个厚度证明我们的工作质量很高。我们国内许多的企业客户特别是大型企业都很在乎这点认为可以从方案厚薄中看出对项目重视程度。
如果你做了精心调研你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作有个金字塔式的写做原理也就是说文章一定是有结构的。
所以真正好的方案不一定厚但能看出你用心你认真。
现在的解决方案一个不好的倾向是“长、厚、全”看起来面面俱到其实对决策者没有帮助。
所有的方案无差异性每家供应商都说自己能解决这些问题而且都有成功案例。
结果所有的方案都无法给决策者简明的判断依据不得不费更大劲去做产品演示和用户考察。
其实很少有企业高管不知道自己的毛病在企业你随便去找一个人对问题都能讲一通在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。
通观这个方案并没有研究为什么企业会产生这么多问题问题是这些问题是什么产生的为什么出这么多问题而是不断说“我能我能选我选我”。
如果不能找到解决这些问题的原因简单地去解决这些现象就象治病不能治根一样。这样一个模板化自我膨胀化的方案想打动用户的心是非常困难的。
不好的解决方案最大的问题就象写一篇议论文能够发现问题(这个也是模板化的可惜中国企业大部分没有意识到自己很多问题并不少见总以为自己是特殊的一类企业)提出答案(搞信息化)但没有论证(为什么搞信息化和企业管理进步有联系呢)。
没有论证的东西不管内容陈列得多么繁复名词多么吓人但是无法打动用户特别是那种理性的用户。
看到方案时候其实很多用户下不决心他会感觉每家都差不多。
如果从没看过方案的人突然看到这几个方案你为什么会感觉某个方案写得好呢关键是有的方案图画的好通过图通过表会感觉这个公司还不错很规范。但对内容认可程度并不高实际上没看懂。
3.2.2 第二个容易犯的错误业务解决方案成为功能列表
解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列或者参照软件用户手册罗列这种解决方案不是按照用户业务去准备的内容而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。
大凡按照功能列表组织的解决方案用户会有一个体会庞大而庸长但要看到自己想看到的部分非常困难。
而且这种方案还有一个特点一个问题反反复复的提在业务背景中指出某个问题讲一通在价值分析中又重点解释一通到了功能介绍时又将某个问题来龙去脉概要说明一下给用户感觉是一堆资料的堆积哪里体现出了方案的针对性呢
按功能列表准备方案的做法在很长一段时间内不会消失这和我们普遍是4P销售人员还缺少SPIN(顾问式)销售人员有关在资源不足的情况下要保证效率就只能提供功能列表方案了。
3.3 坏的解决方案有哪些特征(中)
3.3.1 第三个容易犯的错误结构不清晰
不好的解决方案最共性的毛病是结构不太好没有清晰的思路。
没有思路的方案质量很低用户在审阅过程中也不会体会到和一个专人人士通过文字交流的乐趣他不得不从供应商混乱的思路中发掘亮点看看到底是谁能解决企业的问题真是一件痛苦的工作。
一种常见的方案结构毛病就是重复的内容在不同的章节反复出现例如在第一章介绍了对某个问题的分析提出企业的需求这第二章介绍方案价值的时候又用不同语句组织类似内容到第三章解决方案描述中还是要把问题描述一遍给人感觉思路不连贯结构臃肿。
这里有一个方案提纲的提纲我们以这个提纲为例子说明结构不清晰的方案。
1 公司简介及资质文件
1.1公司简介 1.2 自有产品及代理产品情况 1.3 重点工程介绍 1.4 公司资质复印件 2 分项标价表 3 ***PDM系统技术解决方案 3.1 ***PDM系统技术解决方案 3.2 ***PDM系统具体功能模块 3.3 报表及明细汇总 3.4 应用工具及封装接口 3.5 用户及权限管理 3.6 拼图打印 3.7 编码管理 4 实施计划 4.1 实施步骤 4.2 实施计划 5 培训计划 5.1 系统培训对象 5.2 主要培训内容 5.3 培训方式 6 实施人员资质 6.1实施人员组成及工作职责 6.2实施人员资质说明 7 质量保证及售后服务 7.1 质量保证 7.1.1 工程技术力量的研发水平 7.1.2 工程技术力量的实践经验 7.1.3 管理水平 7.2 售后服务承诺 7.2.1 技术支持与服务的内容和承诺 7.2.2 技术支持与服务的保障 8 开目典型用户 9 有关技术秘密的声明 10 附件
这个方案第一部分、第二部分是用户投标要求必须如此但第三部分技术解决方案应该是重点这个部分结构就很奇怪。
一般好的方案结构标题就是论点内容就是用事实进行论证子目录是上级总目录论点的分论点逐层论证下来方案显得逻辑性结构性很强看看目录就能看出方案的逻辑推导体系。这就是所谓金字塔文档体系。
这个方案显然不是这样的看起来一大堆内容有经验的人一看就知道是内容的罗列。
例如第三部分总标题是技术解决方案结果第一个子标题还是技术解决方案撞车一定层次感都没有。而且第一子章节技术解决方案后马上是功能模块技术解决方案理论上包括功能模块不是一个层面的东西技术解决方案应该和实施策略服务策略平级的内容所以一定要谈谈自己技术解决方案不如用技术解决方案思路或者特色来表达和功能模块也就是一个层次分论点统一支持技术解决方案这个大题目。
具体功能模块后面跟着一大堆章节就更奇怪里面每个都是具体的功能模块为什么成为和具体功能模块平级的内容应该设置为具体功能模块子章节为妥。
很多人可能觉得用户对这个点很关心要重点突出所以一定要单独立一个章节其实不必然结构清晰的方案用户看起来才不费心反而想这个方案将具体功能模块报表及明细汇总、应用工具及封装接口、用户及权限管理、拼图打印、编码管理列为同一层面内容反而叫人看不出排列的思路在厚厚一大本方案中寻找对应关心内容并不容易。
其实不如把技术解决方案分为两大部分一部分介绍整个方案的实现思路对于工作比较忙的人可以看这块中对企业业务和逻辑的分析是否到位相当于整个方案的精华版一部分介绍整个方案的技术支撑模块对于项目具体负责人就可以深入研究技术支撑和业务思路之间是否存在合理的组织关系。
在第二部分技术支撑模块中根据业务逻辑或业务顺序设计功能模块的介绍。
例如一般企业是首先考虑静态技术资料的受控管理在受控的基础上要求尽可能集成设计软件中的信息然后要对设计过程建立严密的动态控制体系此外还希望得到一些设计过程的专业支持例如变型设计二级工艺路线管理等等最后要求提供一些编码企业资源库等等辅助工具。这就是我们实现企业需求的一个大的业务思路在这个业务思路下我们可以将技术支撑模块分为相应的五个部分。
到这里整个方案大的框架就有了我们需要设计一下分标题使用户一看就可以进入自己关心的内容而且每个部分都是对所属总标题的呼应支持在业务环节上也是“相互独立彼此穷尽”的环节。
在标题的设计上不要过于简单例如技术资料管理应该说有效的技术资料管理因为有效才成为技术支撑模块进而呼应前面业务实现思路中的描述。
3.1 业务实现思路 3.2 技术支撑模块 3.2.1有效的技术资料管理 3.2.2深入的数据集成 3.2.3严密的过程控制 3.2.4灵活的设计支持 3.2.5辅助设计工具
在上面这个思路基础上我们就开始结合企业业务和产品功能进行考虑分标题下级的结构我们用第一有效的技术资料管理为例子。
有效的技术资料管理到底要解决哪些业务问题才算完整呢我们现在就开始将企业管理技术资料的业务进行罗列在业务思路中逐步说明。
企业管理技术资料是以产品为线索区分的所以第一要说清楚产品资料如何管理
产品下所有零部件是以特征为线索区分的所以第二要说清楚零部件资料如何管理
有些零部件还具有共图共工艺的特征所以第三要说清楚系列零部件资料如何管理
进一步有的企业还有系列产品所以第四要说清楚系列产品资料如何管理
系列产品可能存在大量配置关系所以第五要说清楚各种规则下产品配置资料如何管理
有的企业产品配置型号在生产中还存在批次关系所以第六要说清楚不同产品批次资料如何管理
有的企业已经存在了大量历史设计资料所以第七要说清楚历史产品资料如何入库管理
在资料入库时有个问题每个人管理资料习惯不太一样全部统一成一种管理方式是必要的但可能失去一些灵活性所以第八要说明为个人自组织资料提供哪些支持
最后要说清楚产品资料为什么入库管理后是安全的
我们现在总结一下这些技术资料管理手段如果都提供了应该是完整而且层次清晰的这样的话第一个子标题下的分标题又有了。
3.2.1有效的技术资料管理 3.2.1.1 产品资料管理 3.2.1.2 零部件资料管理 3.2.1.3 系列零部件管理 3.2.1.4 系列产品管理 3.2.1.5 产品配置管理 3.2.1.6 产品批次管理 3.2.1.7 资料入库管理 3.2.1.8 个人资料管理 3.2.1.9 资料安全管理
再看看这个标题和业务思路这里面体现的一个结构化方式恰恰是“一句话一个意思一层意思推动一层意思”到最后就象剥笋一样层层剥开问题解决思路也就步步清晰了企业看起来也就很明白。
那么我们还可以继续细分用户提出的各种业务需求把企业各种业务要求对号入座例如下面有一组需求
有的企业要求用户访问控制有的企业要求提供角色权限管理有的企业希望按产品目录授权有的企业要求全部存放在服务器的数据库中有的企业希望支持多数据库独立访问 有的企业要求提供备份工具等等。
我们现在看看这些业务是否都应该是关心资料安全的所以应该放在资料安全管理目录下而且这些需求也可以分为不同层次一些是和权限有关的一些是和存储和备份有关的这样很快又可以把子标题和分子标题设计出来了。
同样我们可以推导出如下另外几个部分的提纲
3.2.2深入的数据集成 3.2.2.1 主流CAD的集成 3.2.2.2 CAPP的集成 3.2.2.3 和其它常用工具软件的集成 3.2.2.4 数据挖掘统计工具 3.2.2.5 和其它PDM/ERP系统的集成 3.2.3严密的过程控制 3.2.3.1审核管理 3.2.3.2发布管理 3.2.3.3更改管理 3.2.3.4项目管理 3.2.4灵活的设计支持 3.2.4.1 变型设计业务支持 3.2.4.2 二级工艺管理业务支持 … … 3.2.5辅助设计工具 3.2.5.1 编码管理 3.2.5.2企业资源管理器 … …
这个结构化体系一旦出来后整个方案的思路是否清晰明了下笔容易了呢
结构化体系最大的好处是不乱今后用户提出任何业务需求或者产品功能如何扩充都很容易对号入座或者扩充子标题。这也是体现了一种分类管理的思想。
当然这个分类思路根据不同业务特征允许存在多种可能而且分类层次应不超过5级标题否则文章的可读性不佳。
如果一定要超过5层就可以采取其它排版方式体现。
3.4 坏的解决方案有哪些特征(下)
3.4.1 第四个容易犯的错误口语书面语混杂遣词造句不严谨。
不好的解决方案还有一个毛病就是口语书面语混杂遣词造句不严谨。
有的人写作时顺着思路走口语化成分很多例如本人的行文基本是口语化的也体现了这个毛病。当然大师级人物的确可以将文章写得明白如话但是对我们这些人而言方案是代表公司正式对外的文档一定不要出现口语和书面语混杂的情况。
例如太多的儿的我们你们等等都是口语化语言不应该大量出现在正式方案中。
有的人写方案比较图表现喜欢指出用户的不足这个时候喜欢用很激烈的语言。例如缺少管理业务失控后果很严重等等语句这样的遣词造句是不严谨的方案用语不要追求“语不惊人誓不休”。而是理性分析认真推导句句讲逻辑。
实在要用一些事实说明企业的问题不要用刺激性强的语言例如说企业业务存在问题可以说业务有可改进的地方例如说企业管理失控可以说管理上存在很难受控的环节。
这样的表达企业反而容易接受不出问题。
3.4.2 第五个容易犯的错误没有认真检查存在大量硬伤。
不好的解决方案制造过程往往是找一个同类方案然后主要工作是“CTRLC”“CTRLV”。
很多人就图快省事没有很好的核对结果往往容易出现如下几种错误
第一有些企业在一个方案中用了不同的称呼(这个也要养成一个习惯在一篇方案中一个企业用一个简称和一个全称)替换不完整结果在方案中出现了其它企业的名称非常不礼貌
第二有时候替换过头把一些案例中类似的话也替换成为给用户名称闹出笑话。
第三只注意了文字替换不注意图形中的替换结果文字是一个用户的图片是另一个用户的感觉不尊重。
第四是只注意了文字替换忽视了页眉页脚的替换特别是注意了首页或目录的页眉页脚没有注意正文的页眉页脚。
第五是案例不对明明是汽车行业的用户案例全部都是其它行业的感觉在这个行业没有经验。
第六是联络方式不对很多时候将别的营销区域方案拿过来用服务信息都没有更正过来。
第七是存在大量技术硬伤有时候为了突出软件技术实力将大量专家都不一定看得懂的词汇大量堆砌其实连软件公司自己都搞不清楚采用了哪些。
企图通过让用户对概念和名词发晕进而对软件产生信赖的方式已经过时解决方案应该实事求是说明业务问题不要在名词上忽悠。.
3.4.3 第六个容易犯的错误过于突出自我
很多人写方案大量出现“**软件公司”内容甚至每个产品都恨不得加上自家标识。在很多地方行文造句都是“我能我行我有…”等语气。
这种方案很容易给用户过度营销的感觉。我们给用户写的方案在售前建议尽量用用户做前缀例如说某某企业PDM项目不要总在说某某供应商PDM的话给用户一种相对的针对性感觉这个方案的确是为用户准备的。
在售后实施方案中软件公司的名字只需要出现一次后面就不需要反复出现因为大家都知道是你的产品何必反复体现我们更应该把用户的注意力集中到产品本身就应该具备的功能和支撑业务上而不要形成某某可以某某不可以的印象。
3.4.4 第七个容易犯的错误没有评审。
方案提交给客户之前一定要经过评审。
没有开发点的方案一般经过自评和互评即可自评时要重新审视整个方案的结构、问题描述、遣词造句等方面特别是用替换修改的企业名称和营销平台等方面的内容尽量减少低级错误。
自己评审过的方案一定要给一个其它的人评审。
互评时要重新审视整个方案的结构、遣词造句等方面的内容。
对于有开发点的方案要经过公司的评审。提交给公司评审的方案一定是已经过自评和互评的方案而且要注明主要看哪些部分以及编写这些部分的背景知识。
3.4.5 第八个容易犯的错误没有体现公司产品最新进展。
一般人写解决方案首先不是想着如何说清楚用户的业务如何在公司产品中体现出对业务的支持而是想赶紧找一个模板把这一关走过去再说其实很多时候就是对每个阶段工作没有质量意识最后导致工作处处被动。
所以写解决方案一定要根据公司最新产品功能认真组合功能实现企业业务甚至可以考虑利用未来半年内会发布的功能认真组合因为解决方案离正式实施往往需要半年甚至更长的周期。
很多时候解决方案一抄再抄都是一两年前的模板自然缺少竞争力和说服力。
这个问题的核心是公司有没有专人专岗负责对标准解决方案的维护和更新发布机制其实比较好的一种做法结合典型项目技术公关推动解决方案水平不断完善和提高。
3.5 写好方案心得(上)
3.5.1 动笔前先打一个电话
一般情况下方案撰写人只是按照别人要求提供方案并非直接利用方案的人所以在写方案之前问问需要方案的同事甚至是用户听听他们对方案的想法和建议对自己写方案会有很大帮助。
很多时候方案准备完成方案接受者并不满意方案的组织需要返工修改所以动笔前先打几个电话问问别人要什么不但可以提高方案准备命中率甚至可以获得大量现成的思路建议对自己写方案大有好处。
3.5.2 一定要努力按业务逻辑去写。
一般写方案最简单的方式就是按照软件自己的思路和功能模块组织因为有大量现成的材料可用。但这样方案对用户并非是一种最佳选择因为客户要转换到供应商的思维才能看懂方案字句之间的含义。
如果从以客户为中心角度出发方案应尽量让用户容易看懂好理解自然也就取得了几个印象分。
我们方案就是要先仔细探讨企业业务不是将调研结论一罗列而是从业务分析得出业务需求最后描述技术实现手段。从这个意义上讲解决方案要按照简明的操作手册来准备。
3.5.3 按标准套路写方案
不同类型的方案都有自己的套路例如可行性报告解决方案建议书等等都有标准的套路我们应尽量按照标准套路准备方案不要自成体系在套路下发挥套路就体现了一种结构化体系化的思维模式。
关于常用套路我们另有一章说明。
3.5.4 先构思提纲经过讨论最后动笔
很多时候方案准备时间并不充分很多人接到任务压力之下立即开始动手这往往是不好的工作习惯有时候有模板的确可以快速出活但时间长了就养成一种惰性替换方式抄方案还勉强真要遇到有个个性化问题因为在平时写方案过程中思维始终不经过结构化思考的练习真到方案模板没有覆盖的情况就没有办法应付。
好的方案特点是标题就是论点。结论做为标题马上拿出来。
好的方案是观点鲜明立场明确有理有据有血有肉。
所以有方案要写一定不要急着写而是想自己的提纲这个完整提纲目录之间的逻辑联系和业务衔接自己在心里面推导得比较有力和充分了才开始动笔快速拿出提纲有了提纲写起来思路就不会断电写起来才快。
好的方案一定是做了论点。
论点是假设的例如说搞PDM有价值。
你说价值有三个方面能降低成本提高质量能缩短交货期。这都是你的假设。
你怎么知道成立就要找些事实去证明它。
我们现在都喜欢找什么事实呢你用了这个功能所以你的论点就成立因为你有这个功能所以你的效率提高了。
这都是扯蛋为什么用了PDM企业就能做到这几点。根本没逻辑推导。
不是还有大把企业用了ERP用了PDM还不是该咋的咋的钱都打水漂了。
假如你有好多论点论点怎么组织呢你比如我要搞信息化信息化有大价值小价值对不对你要把它都列出来列出后你还要想一想这个价值和那个价值是不是包容的关系
好处一定是每个好处都是独立它是有层次每层上的好处是平级的大好处包含多个小好处这些好处倒推出来就响应支持你的论点这种方案看了以后别人就会理解并支持你。然后每个好处一定是在前一个好处的基础上往前推动一步最好得出一个强有力的论证过程。
所以好的方案必须是金字塔型的论据论证最后构成坚实的基础。
如果有条件的话这个思路还应该和大家讨论特别是一些重要方案一定要先反复讨论提纲大家各种意见和思路在提纲中统一了再动手写。这样就不至于遇到写了一半被人否定推倒重来的痛苦了。
3.5.5 找一个安静的地方和完整的时间段开始
写方案最怕中间不停被人打断这样思路连贯性会很差。所以我无论接到多么紧急的方案编制任务也不会急着去写而是把手头该处理的小事情处理干净然后保证开始后的时间相对安静和完整这样才能保证方案的质量。
而且写方案一定要保证在一个时间段内初步拿出完整的推导思路和结构提纲才能结束去干别的事情这样以后就是逐步补充和丰富内容不至于还在为结构苦恼不清楚从哪里下笔
3.6 写好方案心得(下)
3.6.1 认真准备阅读提示和摘要
一个方案往往厚厚一本更多是充点门面领导是不会真看的。万一要看也就是看看包装是否精美和头几页文字。
所以方案可以单独附一份摘要这是关于整个方案业务分析和解决思路的精华部分当然也可以带一点实施方法和典型用户的介绍。
这样就可以让自己方案思路在短短几页纸中清晰描述和表达出来这种提炼过的语言和文字往往更能打动人心。
一般写一份厚方案只需要一天写一份薄方案需要一周要求在三页纸内说明问题需要一个月能把书读薄是能力的体现。
对于方案也一定要提供一份阅读指引告诉不同的人其关心的内容可以在哪些章节直接获得方便其阅读。实际上我们观察很多论文和书籍序言都有一段来说明这个文字的结构其实这也是一个标准做法。
3.6.2 注意排版
方案一定要注意排版印刷要干净封面要隆重装订要精美方案就是一个公司的脸面虽然不是说一份方案可以决定项目但一份看上去都不好的方案一定很让人怀疑公司的能力。
我们很多人见过外企的文字一般都非常精美排版很漂亮大家一看就觉得是专业人士所为。
所以方案的文字和图表内容最好请专门的美工设计一套标准的排版体系对方案整体可读效果会起到极大促进作用。
现在很多方案都是密密码码内容是多可以有什么用
不如取巧少写一些文字多在排版上动脑筋实在想不出好的排版是什么回事的去买基本畅销书你会发现可读性好的书往往有一个技巧叫“留白”。
方案文字段落边框之间保持适当距离特别是边框合理留白会让一份方案可读性大大提高。
象本文这样的文字如果加上留白设计可读性就会很不错。
3.6.3 注意积累素材
写方案无论如何按照企业业务组织基本上90%内容是相同的不过是根据不同思路进行组织而已毕竟软件功能不会在短期内发生巨大改变方案涉及功能也没有理由发生大的改变所以方案中很多素材是可以通用的。
包括一些公司通用素材更是要随时积累补充完善和归类存档这样在写方案时才不会因为寻求这些基本素材浪费大量时间。
基本素材收集还要注意随时和公司公开宣传口径保持一致防止引用过期素材。当然标准素材最好由公司统一维护。
获取其它素材的途径比较多主要有
现场初步需求调研与交流
与熟悉类似项目的销售经理、技术支持工程师、实施工程师沟通、了解
营销平台交流
企业网站
相关行业资料介绍
书刊
……
一般可以从企业网站获取企业介绍。从网站获取的企业介绍需经“角色转换”和“内容筛选”角色转换是指站在公司的立场描述该企业的情况介绍要把第一人称改为第三人称。内容筛选是指主要介绍企业信息化的基础包括企业的经济实力、管理水平、已完成和正在进行的信息化项目等内容。
3.7 方案分类及用途
3.7.1 方案的种类
目前公司为客户撰写的方案分为建议书、解决方案、投标书。技术白皮书应作为统一的资料提供。
建议书是用于动员客户启动项目或者用于客户初步选型阶段的技术支持以入围
解决方案是用于洽谈技术协议和合同之前的技术交底或者用于议标阶段以技术和实施服务等优势战胜对手
投标书是用于客户招标的技术交底以综合实力战胜对手。
3.7.2 方案的基本结构
3.7.2.1 建议书的基本结构
建议书的侧重点是分析客户实施某项目的宏观和微观形式、现存的诸多问题提出实施该项目的必要性和紧迫性再介绍相关产品和技术的发展现状公司的产品特点和优势落脚点是公司已具备相当的实力与公司合作成功率最大、风险最低。建议书的基本结构如下
引言
现状分析与诊断
相关技术的发展现状
公司相关产品的特点
公司具备的实力和基础
结束语
各个部分撰写技巧如下
引言部分
从全国、行业的信息化现状分析入手说明信息化是大势所趋再从本行业的产品特点出发分析信息化需要注意的关键问题最后介绍企业的情况特别是信息化的已有基础包括企业的经济实力、管理水平、已完成和正在进行的信息化项目等说明该企业已具备实施本项目的基础。
引言部分可分为
制造业信息化现状
本行业信息化特点分析
信息化的基础
现状分析与诊断部分
从本项目所涉及部门的业务现状描述和分析入手找出问题并提出相应的解决办法。
现状分析与诊断部分可分为
业务现状描述
问题分析与诊断
相关技术的发展现状部分
主要介绍本项目所涉及的PDM/CAPP/CAD等技术产生背景、发展过程以及发展趋势等内容并说明这些技术已是成熟的实用性技术。
相关技术的发展现状部分可按软件产品类别分别介绍最后有一个小结。
公司相关产品的特点部分
主要介绍公司相关产品的主要特点说明公司相关产品是符合其发展趋势的先进和成熟的产品。
公司相关产品的特点部分可按软件产品类别分别介绍最后有一个小结。
公司具备的实力和基础部分
主要从公司简介、完整产品线、研发能力、实施与服务体系等方面说明公司已有足够的能力承接本项目并以成功案例证明与公司合作成功率高、风险最低。
公司的实力部分可分为
公司简介
完整产品线
雄厚的研发能力
科学的实施与服务保障体系
成功案例
结束语部分
阐明公司愿与企业强强联手结为(战略)合作伙伴关系共同推进企业乃至本行业的信息化建设。
在结束语部分要明确提出合作建议内容对于一些战略合作伙伴关系不能轻易宣讲和承诺一定要经报公司批准之后方可承诺。
建议书的要求是简短紧凑内容详实便于用户决策可以在一份建议书中形成几个可选方案推动用户决策。
3.7.2.2 解决方案的基本结构
解决方案的侧重点是分析现存问题提出功能需求及相应技术实现手段并辅以实施保障措施说明用户需求是可以实现的。解决方案的基本结构如下
引言
现状分析与诊断
系统规划与设计
系统技术方案
系统实施方案
服务内容及措施
典型案例
结束语
引言部分
从全国、同行业的信息化现状分析入手说明信息化是大势所趋。再从本行业的产品特点出发分析信息化需要注意的地方。接着介绍企业的情况特别是信息化的已有基础包括企业的经济实力、管理水平、已完成和正在进行的信息化项目等说明该企业已具备实施本项目的基础。最后通过公司介绍说明有能力承担该项目。
引言部分可分为
制造业信息化现状
某行业信息化特点分析
信息化的已有基础
公司介绍
现状分析与诊断部分
从本项目所涉及部门的业务现状描述入手分析出问题并提出改进建议得出实施系统的必要性和紧迫性以及需要解决的问题
现状分析与诊断部分可分为
业务现状描述
问题分析与诊断
系统规划与设计部分
根据现状分析提出的需求对本系统从总体目标、指导思想、总体框架等方面进行总体规划与设计。总体目标是从企业已有明确的总体目标中结合用户需求提炼出来的不能简单照抄还需适当调整与补充。总体框架包括体系架构、运行模式以及其它企业关心的问题等。
系统规划与设计部分可分为
总体目标
指导思想
总体框架
体系架构
运行模式
……
系统技术方案部分
从基本功能介绍、关键问题解决方案两个层面介绍具体的技术方案。基本功能介绍是对本项目所涉及的产品在标准模块功能基础上适当补充各模块的新增功能或用户的特殊功能。关键问题解决方案是就企业特别关心的问题(包括管理和技术两个方面)、企业特殊需求中有一定难度的问题以及管理方面需要改进的问题等提出解决方案和建议。
系统实施方案部分
从本项目的预期效益入手分析项目实施存在的风险接着介绍公司规避风险的实施保障措施最后给出初步实施进度计划和培训计划。实施规划要结合用户的实施打算如果系统规模比较大可以结合用户的需求适当进行目标分解分期完成。
系统实施方案部分可分为
预期效益
风险分析及对策
指导思想
指导方法
实施管理
实施规划
实施进度计划
系统培训
服务内容及措施部分
从公司能为客户提供全方位服务承诺入手阐述公司技术支持与服务的保障措施让客户无后顾之忧。
服务内容及措施部分可分为
服务内容及承诺
技术支持与服务保障
典型案例部分
用公司典型用户的案例进一步证明公司提供的技术方案是先进的、实用的形成一套科学的、可操作的实施方案。典型案例选择的针对性表现在行业、特殊需求、项目类型等方面有相似之处。
结束语部分
阐明公司愿与企业强强联手达成合作伙伴关系共同推进企业乃至本行业的信息化建设。
解决方案注意业务分析系统规划技术方案三部分不要反复出现重复的内容或者为了表达自己技术方案是扣着业务需求而在系统规划和技术方案中再次反复描述需求如果发现有这样的问题就要精心去组织方案提纲。
此外解决方案要避免浮夸和务虚的内容要尽量让用户看到可操作的内容例如在实施方案中用户最关心的是在实施分几个阶段每个阶段相互配合工作是什么谁去做合适阶段结束的标志是什么每阶段工作需要多长时间根据企业实际情况有哪些风险如何规避基础数据如何准备历史数据如何录入工作流程应用前后有何变化这些是用户真正关心的内容。
所谓实施方法论实施原则实施指导思想实施团队结构等看起来饱满其实是务虚的内容少写写得越多用户越不得要领实施方案的要害是具备不具备可操作性。这里面的原则就是计划越细化越具有可操作性。
3.7.2.3 投标书的基本结构
投标书是针对标书的解决方案包含解决方案的全部内容再增加公司优势和相关附件。投标书总是原则是按照用户提供的招标书要求准备用户要求如何提供资料就如何提供不要任意发挥。
常见投标书的基本结构如下
引言
现状分析与诊断
系统规划与设计
系统技术方案
系统实施方案
服务内容及措施
开目公司的优势
典型案例
结束语
相关附件
开目公司的优势
相关附件
相关附件按照招标书的规定组织附件。
3.7.3 方案的针对性
为使方案具有鲜明的开目特色方案必须具有一定的针对性。不同类别方案的针对性有不同的体现。
建议书的针对性体现在同行业的信息化特点分析本企业已有的信息化基础、本企业的现状描述与问题分析等方面。
解决方案和投标书的针对性有相同的表现主要体现在同行业的信息化特点分析、现状分析与诊断、总体目标、关键问题解决方案、实施规划与进度计划、典型案例等。
现状分析与诊断部分、实施规划与进度计划部分不能简单把客户名称更改就变成另外一家的情况。
总体目标部分有企业的个性如果需要可以分解成近期、长期、远期目标。
解决方案中可单独把企业关心的关键问题单列为一部分紧密结合企业的需求特点不能简单套用标准说法必要时可以通过定制配置实现。
解决方案中的关键问题与投标答辩PPT中的关键问题有区别。投标答辩PPT中的关键问题主要是展示我们优势部分以攻击对手的劣势部分但一定要有绝对的把握。
4 如何做产品演示
4.1 什么是演示
入行五年售前售后演示最少也有两百次也算有一点经验了今天把我个人做做产品演示的体会做一总结希望对所有想做好演示的人员提供一点帮助和指导。
产品演示不是演讲也不是答辩更不是培训。
尽管在很多表达和现场互动技巧上演讲答辩培训和演示都有相通的地方。
演讲更侧重对某一个问题看法的陈述主要是交换观点允许争鸣听众可以不同意你的观点但一定会捍卫你发言的权利。
除了常见的演讲比赛外很多时候演讲者是受邀请以一种被尊重状态出场是处于一种比较从容的心态下开始的。
演讲的过程一般也是比较连续不会被随意打断的。
答辩更侧重对话双方的交互具有很强的考核目的通过对答辩问题的反应答辩主持方来主动判断他想获取的信息。
答辩的过程一般是不连续的随时都可以中断响应不同的问题答辩的节奏和压力也更为紧张时间非常紧凑。
培训更侧重于传授操作此时被培训者已经认可培训者所在公司和产品在过程中更多的是教学相长形式可以多种多样根据不同培训层次灵活组织。
演示不然演示是有极强的目的性。演示往往是要在有限的时间内(比答辩要舒展)面对一群不同心态或者不明心态的人快速把自己所在公司、公司产品和服务包括自己最大范围内推销出去。演示过程中还要随时准备开始各种技术答辩应付各种刁难。
演示是主动影响客户(用户)的过程售前演示也是主动和竞争对手竞争的过程演示更是个人魅力展现的过程。
整个演示就是一场复杂的脑力游戏看看我们有什么办法在短短1到2个小时内更能抓住用户的心
4.2 演示的目的
4.2.1 售前演示的目的
介绍公司通过自己的言行和产品介绍展示公司的形象
强化自己的优势给竞争对手设置一定的技术门槛
讲出自己能为用户做什么解决什么问题愈是用户关心的问题愈要主动沟通和交流让用户对软件产品技术和实施能力放心
进一步判断用户关注的项目重难点了解我们前期准备的不足采取针对性后续对策。如果是这个项目一定要解决的问题目前产品又无法实现的内容必须尽快反馈给公司决策。
4.2.2 售后演示的目的
介绍公司和产品让广大具体用户认可公司取得最大范围品牌认同减少实施阻力
宣讲对企业问题的认识提出自己的业务解决思路主动控制项目边界
通过现场互动进一步判断用户关注的价值点是否在项目边界内确认是否要调整项目边界尽快反馈给实施团队或公司决策
除了目的不同外售前演示比售后演示更具有挑战性用户更可能具备不合作性演示没有达到目的将可能导致不可挽回的局面。
一般在管理软件售前项目中产品演示效果不佳和典型用户考察效果不佳两个因素可以导致直接出局没有挽回的余地。所以产品演示一定要解决用户对我们技术能力上的顾虑保证得到进入下一轮筛选的机会。
所以本文重点将放在对售前演示工作的说明上以下内容基本上都针对售前演示说明售后演示可以参考并简化部分内容进行即可。
4.3 售前演示为什么效果不好(上)
坦率地说我们业内大部分管理软件演示总体来讲不是特别理想并没有深入打动用户。它为什么不理想呢我个人认为有六个大的原因。
4.3.1 第一是演示没有整体策划。
成功的演示绝对不仅仅是两个小时的精彩发挥要保证这个精彩发挥必须做大量的基础工作才行。好的演示一般都有一个人在精心进行整个演示活动的策划是整个项目商务活动中必要的一环而不是一个在孤立准备的活动。
商务人员往往期望有一个“高”人到现场做一个精彩绝伦的演示让竞争对手甘拜下风让用户眼前一亮然后再四平八稳的把事情摆平这种事情基本上不存在。
之所以某些人演示做的好一点只是因为他准备的比别人多得多如果演示者平时每天花半小时去演示三个月后水平将是非常厉害的。
而现在许多人因为有某个单子才想起要准备演示这个时候自己能演示什么呢只好先看看谁能搞定这个事。这样必然会导致某几个人水平越来越厉害而大家都不厉害业务肯定做不好都找这几个人这几个人累死而自己做业务总是束手束脚嘛这不是一个很好的方法。
只要做好准备每个人都能成功的做演示。要做好演示就不要随意演示。
不要以为产品有几个亮点商务人员就想给用户“镇”一把。想这样演示的因为准备不足或者没有套路结果用户第一眼就看不中会不断的让你演示反反复复。
结果干了一件什么事呢不断给别人启蒙摘桃子的是别人。
即使在一次演示中效果很好也不意味着项目就是你的而是在成功演示后安排大量后续工作。一般管理软件项目周期很长在短期之内你不做太多投入把大单搞下来但一定会有一个很密集的时间投入了密集的资源做一系列的事让上上下下都认可你了后面再按部就班进行。
这就要求要提前规划演示一般商务人员要提高半年或一年判断大概在什么时候演示比较合适。
策划什么呢
第一要演示哪些东西让用户很接受。
如果要想知道这个事首先要通过接触对企业基本业务做个判断判断以后安排技术工程师或总部协调资源进行一次到位的调研然后提前半年、一年准备做一个相对来说比较和企业个性化特征吻合的配置这叫技术准备。
第二如果安排演示一定要考虑演示达到目的了后续最理想的工作安排是什么是不是可以马上安排用户和公司考察这样他会在一个很高的情绪下不断认可公司实力。
一定要考虑演示以后效果好怎么效果不好怎么办我们往往是演示了就完了其实这个事根本没完。
第三演示给谁看一定要保证这个人到位。
演示的时间宁可推迟一定要保证你希望来看的人一定要到场如果不在场就不要演示没有意义。
4.3.2 第二是演示没有套路。
很多人对软件理解不同喜欢按照自己的思路去发挥每个人都进行发挥结果导致整个公司的演示没有统一的套路。
如果没有统一演示套路演示行为就无法标准化没有标准化的东西在管理上很难受控也就很难保证质量很可能某几个人演示很不错大部分人演示不到位那就赶紧把这几个人的套路标准化并推广。虽然企业有很多差异但还是可以寻求共性无非是针对不同类型多准备几种统一的套路。
套路是一致的但并非是说所有的人都在背台词而是说所有的人用比较一致的思路去讨论问题谈问题的实现方案特别是一些共性的问题。
4.4 售前演示为什么效果不好
4.4.1 第三是套话理念太多。
在策划演示套路时要更多考虑一个问题不是我们有什么功能而是这些功能按业务能不能串起来。在考虑演示内容时不要空谈理念在讲到一个业务线的时候把想法拔高一下在合适的时候自然地带出来。
如果大量在谈理念一是低估了用户的知识面二是提高了用户的期望值三是大量时间并没有让用户看到实在的东西谁也不会下决心购买概念用户特别是技术型用户更愿意看到实际的内容对于高管在交流时谈谈理念可能更合适。
演示不能单调的只是将PPT的内容念出来而已PPT的内容要简单主题明确而演讲者脑子里的东西则一定要充分口语化表达。
4.4.2 第四是演示时机不好。
过早演示往往是演示效果不佳的一个重要原因很多客户经理其实缺乏销售管理软件的经验和从容自信也缺少业务内涵因此当发现一个项目信息后他们往往不知道下一步可以做什么要么被动地随着用户要求走要么就积极主动创造调研和演示的机会期望通过一次良好的演示或者用户考察达到他们想要的目的。
实际上一个大的管理软件项目售前周期是很长的匆匆忙忙去调研演示效果往往不好。我本人发现在长期跟踪的项目上往往是早起的鸟儿没虫吃。不要怕耽误一个月两个月时间可以按部就班进行当然那些客户经理自己都没有跟踪主动找上门来的紧急客户项目例外。
为什么呢一般客户不可能一开始就完整知道这个概念和自己的业务需求经过很多供应商多轮次攻关后客户才能比较清楚一些概念和自己的业务需求关系也就比较容易看懂演示演示也能达到目的。
大项目上是不会有太多的演示机会的特别是在多竞争对手情况下宁可等到公司准备就绪确定演示策划和实现计划后才能客户预约哪怕耽误一些时间也不用担心给客户解释清楚一般都会理解的。越是急着演示越可能成为用户启蒙者而不是签单者。
4.4.3 第五是演示人员能力不足。
演示这个工作不是谁都可以做的它对人员综合能力有极高的要求显然这种能力人员在任何一个公司都是稀缺资源但是几乎每个大项目都需要进行演示在拥有能力的人员不能到位的情况下只好用能力不足的人员去做演示自然效果不佳。
4.4.4 第六是演示准备周期太长
很多项目用户提出要求演示客户经理为了表示对项目的重视也为自己争取到一个表现的机会一定是满口应承。
应承过后很多客户经理就会陷入困境迟迟不能调度到演示人员去现场演示。如果让自己或技术支持去讲肯定是讲不清楚达不到效果。
如果让公司顾问来讲顾问太少单子太多都不知道什么时候才能轮到自己这里即使来了一个顾问也是没有什么准备匆匆忙忙效果也不一定好。
当用户发现供应商对答应的演示时间一拖再拖就容易怀疑供应商的组织能力和产品实际水平最终演示时也不能足够重视结果参与人员不足自然难以达到效果。
所以作为一个软件企业要想办法让演示组织工作程序化演示套路标准化有一个团队在全力支持演示各个环节工作。软件企业让可能要进行演示的人员不断练习保证每个人演示可以达到一个基本的质量保证企业随时具备四到五个可调度能清楚演示自己主导产品人员是非常重要的基础工作。
4.5 售前演示工作应如何组织(上)
一个好的演示是需要经过大量复杂精心准备的系统工程是团队合作的产物是反复演练的产物。演示工作是有一定的内在规律的。
演示工作一般分为演示准备演示后续跟进三个环节每个环节工作侧重不同但应该有一个总体演示工作组织策划人。
演示策划人未必一定就是演示者本人但一定要是可以对项目可以长期跟踪负责的人而不是临时的外部成员(例如从总部借调的咨询顾问资源)。
很多时候总部顾问只是策划人达到演示目的可通过合理方式调度的资源有了专人负责演示过程才能有策划忙而不乱进退有序。
很多项目跟进半年来还没有任何关于演示的策划一直要等到客户通知才匆忙通知准备一切都没有计划性或者用客户工作突发性强为借口回避自己工作不到位。
从这个角度出发我个人认为演示策划人应该是一名有经验的商务人员在整个售前项目生命周期内策划一次或几次(对于大型项目可能是必要的)成功的演示本来就是商务人员的本职工作。对于没有经验商务人员接手的项目其直接主管领导需要负责并同时传授和指导相关操作经验以便下次其可以独立操作。
一般售前演示工作准备包括以下几个环节。
4.5.1 和客户建立比较紧密的商务联系
在进行演示工作之前一般情况下应该建立了良好的商务工作基础。
例如了解企业组织结构决策模型和决策层建立比较充分的联系和良好的第一印象为演示工作创造一个良好的认同氛围让大家可以带着认同和学习的心态去看演示。
也要了解是否有竞争对手进行了演示效果如何用户对哪些内容比较感兴趣哪些感觉不够展开以便我们进行针对性准备。
我们在商务上容易犯的一个错误是客户经理不知道如何去打动用户面对用户提出来的业务需求又无法满足只好承诺先调研后演示通过这些工作驱动项目往有利于我们的方向进行。
其实客户经理未必要有很好的技术背景但在商言商无论你卖什么让客户信任你所在公司才是商务工作的本质。客户经理应该主动考虑我如何让用户建立对公司的信任演示工作是整个信任工作中建立技术信任的一个环节。在此之前客户应该对客户经理本人已经建立基本的认同才能进行后续工作。
4.5.2 申请有能力的人进行业务调研
好的演示是针对重点(业务流)和难点(用户极度关心的技术问题)演示针对用户的痛处演示针对用户的层次演示而不是罗列我们功能的演示。
要做到这点一定要安排时间做用户的需求调研和业务分析实际上大部分用户也会主动要求我们做这个工作。
要得到能对演示起到指导作用的需求调研和业务分析关键就在于演示策划人一定要安排具有相应能力的人或者调研者在有相应能力的人指导情况下去做业务调研。
一个能力或经验不足的人调研结论对演示并没有实际意义这个时候用户就会比较失望花费了大量时间调研但居然演示内容针对性不强这样的演示效果可想而知。
所以成功演示前往往有一次比较到位的需求调研和业务分析过程。
业务调研有两个可选择的策略如果客户提供的时间很短一定要协调派能力强的人甚至就是演示者本人来调研
如果时间比较充分人力资源又比较紧张的情况下可以派一般的技术工程师和实施工程师多花一点时间按照公司调研套路和演示者要求将问题搞清楚再让演示者准备演示方案。
4.5.3 进行内部沟通
好的演示是团队的产物是群策群力的结晶。没有人是全能和面面俱到的每次成功的演示往往都经过了营销人员咨询顾问、规划经理、公司高管、还有实施项目经理的充分交流和讨论形成对问题的共识后做到的。
一旦确定要给用户进行演示就有很多内部沟通工作要做第一件事情是按公司流程申请到合适的资源进行演示准备并安排足够的时间准备且保证客户可以接受演示时间。
资源的协调和计划的落实是演示策划人的职责所在这就是售前的项目管理重要内容。如果是卖产品销售经理能胜任如果卖项目就必须是懂项目管理和策划的人才能胜任。
要协调的资源可能很多包括演示人员配置人员开发人员甚至高管。这些都必须在一个完整商务策划中体现形成一个攻击波团不要一下子来个演示然后又没有跟进工作安排要在一个比较短的时间内给客户一些组合拳有力地打动他们。
落实资源后演示策划人要让公司上下人员对演示思路和准备工作达成共识。
共识包括三个方面
第一选择怎样的产品线或模块组合很多管理软件系统是很复杂的在短时间内全面演示是不现实的所以一定要合理选择产品线组合或功能模块组合争取在最短时间内让用户明白我们产品能力边界。并准备对应产品线的演示思路和说辞很多公司这些标准产品都有标准的演示套路可借鉴适当调整即可。
第二建立对产品能力的信心管理软件实施成功率不高很多客户经理在销售时心理是发毛的底气不足这样的状态很难要求他充满自信的演示一旦在演示过程中遇到一些刁难心理素质不过硬的人可能就提前崩溃。所以演示前要一定要让演示者充分看到产品能力建立共同的信心。
第三确定是否要协调资源快速开发某些功能点或者按照用户数据建立演示环境。
大部分演示就是按照标准套路进行毕竟很多企业存在共性的内容并不需要一个企业准备一套东西这样成本很高。
但对于一些重要的项目在演示前一定花费时间做定制配置不做样板化的介绍。用用户的数据用户的言语用户的报表演示还是值得的。
定制配置的要害就是一定要在项目资金允许的情况下公司决策层认可的情况下规划方向认同的情况下开发资源接受的情况下(这些都内部沟通的内容)演示出用户最想看的内容而不是我们最有心得的内容。
要达成这些共识不经过大量沟通是不可能的没有沟通很容易出现演示前后同一公司不同人员说法口径不统一的情况对项目并没有好处。
4.6 售前演示工作应如何组织(下)
4.6.1 编制演示方案
内部沟通完成达成共识后就可以进行演示准备演示准备这个环节就是要按照共识来准备一份演示方案。
有了演示方案演示时才能心中有数让别人提意见时也有了一个参考的依据今后演示方案也可以作为公司知识积累和业务持续改进基础。
完整的演示方案应包括三个部分
第一是演示产品线和其它软件环境包括操作系统数据库和演示时要调用的其它应用程序或各种资源(例如动画动态库等等)
第二是演示的思路演示一定有一个整体思路贯穿这个思路根据演讲的内容、听众的特点和演讲的环境而且尽可能按照企业业务准备而且简明扼要说明了自己是如何按照业务思路连串软件功能模块达到支撑业务模块的目的。
演示思路要考虑你想告诉听众什么先要确定演讲的目的。准备工作的每一个步骤始终要围绕这个目的进行。只有这样才能保证你的演示方案有针对性且高效率。
第三是演讲词和配套操作顺序要写清楚什么操作提供怎样的说辞操作的时间在哪里哪些需要提前操作或打开界面提高演示效率哪些操作可能需要较长时间等待(例如汇总)需要准备更充分的说辞操作进入界面和数据位置哪些操作在演示时不能做这些都要逐段落实写明。
一般认真准备了详细的演示方案现场演示就不会失去思路操作也不会零乱往往可以达到很好的效果。
演示方案的准备应该是公司级的行为经过长期积累完善的演示方案就是一份积累了全公司业务经验和产品功能的解决方案可以成为实施标准配置产品规划需求和理念来源(准备售前演示过程也经常可以发现软件不足和可以改进的地方)测试的标准业务测试大纲培训的标准软件平台咨询顾问部也可以按照这个演示套路定制解决方案形成几个精练友好的业务解决方案范本。
这样的话软件公司可以通过演示方案把高管到基层员工从外部业务部门到内部业务部门从销售前期到实施后期通过这个售前演示技术准备活动达成了高度统一大家的经验和知识就有了一个共同的积累平台。
4.6.2 反复排练
如何在现场进行一个好的演示我的建议只有一条练习练习再练习
只有这一条没有别的捷径。
成功的演示无论演示者经过多少实战必要的针对性练习还是非常重要的。
如果是理念演讲为主没有太多的操作排练1~2次基本效果是有保障的如果是产品演示特别是需要多人配合的话至少要练习3轮以上。
如果是产品演示经验少于10次的人建议至少在内部演练5次以上。
建议为每小时的演讲作10小时的准备随着你的经验日益丰富你会发现所需准备时间会逐渐减少。
试讲次数越多越好。如果你对自己有信心听众就会相信你。
演讲的时间包括使用视听工具和回答听众提问的时间因此试讲中要留出这些时间。
每次试讲都要逐渐脱离讲稿。
试讲过程可以对着镜子练习而且尽量大声。
试讲练习到一定时间可以安排录音或旁听这样可以发现很多自我感觉良好下无法发现的问题。
排练是一定要确认自己对所要介绍PPT的内容或者演示操作内容非常了解起码要做到看到一页(步)就能想到其后三页(步)所要演示的内容。
内部演练一定要有2个以上比较有经验的人站在用户角度上评点让他们充分提出改进意见根据意见马上调整。
内部评点还有一个工作是模拟真实用户问题刁难演示者对一些关键问题提前准备说辞也是排练时要完成的工作。
怎么挑毛病呢基本上你在讲时下面坐的想打瞌睡这种演示肯定是失败。坐在下面眼睛还能睁着感觉你讲的有一二点收获这种排练就比较有感觉了。
如果演示是定制配置更由于可能存在新开发功能产品稳定性还没有完整测试此时演示前一定要反复进行操作排练测试确保不出意外。
内部排练有两个经验第一经过排练一定比没有经过排练强第二排练过的人现场讲演效果一般比练习效果强没有排练过的人现场讲演效果一般比练习效果差。
一个人经过反复排练以后往往有种压抑的欲望需要渲泄把这种渲泄的欲望放到现场效果一般都不错。而不练习的人一到现场就畏惧感加重最后也无法正常发挥。
如果一些相对演示经验比较丰富的人都认为这个演示方案有说服力演示效果没有大的问题对对手、企业各种情况都进行针对性预演答辩通过就可以准备上战场。
4.6.3 约好演示时机和用户
产品演示是目的性极强的工作就是要通过演示打动用户促成其选择或实施我们的软件。
产品演示一般也要经过大量时间准备成本很高。如果参加演示的人不到位演示再好成效也不大将不得不再次安排演示这种反复将导致工作成本急剧增加反复演示也未必也能保证演示资源和效果。
因此产品演示对象一般要追求参加人尽可能多让对软件选型有影响的人员尽量参加特别是技术类型人员争取都能参加。
因此演示前演示策划人一定要和用户详细约定在商务工作做到一定基础之上后利用相互的信任关系使得用户愿意配合调动一切应该来也可以来的人员参加产品演示会保证演示的效果。
要做到这一点就是在确定公司可安排的演示资源后立即和用户做大量沟通确定应参加人员可参加人员比较合适的时间段场地和设备在这些条件都具备情况下安排演示。
如果演示条件不具备宁可和用户反复解释也不轻易安排演示演示讲得就是“一击必中”如果没有这个效果就不如多花一些时间在预约工作上。
4.7 如何准备标准演示套路(上)
4.7.1 售前演示工作要不要标准化
有人认为演示时企业实际情况千变万化难有一定之规自然也很难准备标准化的演示套路而且企业业务情况不同用标准化的套路去应对效果可能达不到应该采取定制演示。
这个说法看起来有道理但实际上无法操作定制演示的前提是比较详细的需求调研如果每个项目都做如此投入的话供应商根本无能力负担而且需求调研即使很到位也未必能保证产品演示就能准备到位。
其次定制演示对演示者个人能力要求很高一个企业不可能大量存在这种强人能人定制演示要么人力资源响应不到位只能用比较低水平人员去演示要么演示准备周期过长这两种情况都是无法接受的。
从另外一个角度看企业业务虽然千差万别但是以机械行业为例生产模式也不过是单件、多品种小批量、大批量三类设计模式往往也就是新产品研发、变型设计、系列化设计几种常见类型完全可以用统一的平台来支持相应演示套路也可以针对不同企业类型标准化。可以说业务是标准化的定制一般也不过是数据是个性化的。
如果精心准备了完全按照实际典型企业业务运行的标准化演示套路有很多好处
可以结合准备标准化演示套路工作将一个公司在不同行业企业业务经验有效总结和抽象出来形成指导产品发展的业务规划模型。
对营销工作而言我们业内的营销人员是不会去总结研究产品细节的也不太熟悉企业的运做模式这样推销管理软件时有很多困难。一旦公司层面准备一个条理分明思路清晰亮点突出操作固定的演示套路营销人员将大大降低对公司产品学习和掌握的成本并能够培养出一批能够按照公司要求介绍产品特色的人员解决售前演示资源瓶颈问题。
售前演示准备必须根据企业业务走。演示套路内容应是从实际实施工作中总结出来的一般能在企业实施得很好的业务演示效果也不错而且可以代表产品目前可实施的最高水平。那么对实施工作而言这样的演示套路对实施人员打开思路提高配置水平有很强的导向和示范作用。
对产品规划工作而言通过精心准备业务演示套路时就容易发现一般软件产品不是功能过少而是很难连续串起来支撑某一方面的完整的业务。在售前演示准备过程中由于按照完整企业内在业务逻辑准备就可以提前发现产品在规划方面的问题可以及时和不断改进我们产品中一些不足。
对产品测试工作而言测试也可以按照售前演示套路准备实际业务测试大纲提高功能测试外的业务测试覆盖率可以解决很多实施人员抱怨测试人员不了解实际业务测试工作和实际业务脱节的问题而且可以在标准演示套路基础上编制自动化测试脚本。
对于咨询顾问部而言定制解决方案时候可以按照标准演示套路支持的业务模式来准备这样售前方案和售后实施可以极大保持思路一致性不至于售前一套说法售后一套说法用户感觉上当受骗。
对培训工作而言企业所有培训也应围绕标准演示套路商务人员要能自如按照标准套路操作和演示实施人员要能结合业务调研完成标准套路配置、实施和培训测试人员要能理解演示套路中体现企业业务逻辑发现软件不友好的地方规划人员可以通过演示套路判断产品对企业业务模型支持是否足够应如何改进。这样培训平台就是全公司统一的。
这样的话一个公司从高管到基层员工从外部业务部门到内部业务部门从销售前期到实施后期通过这个售前演示标准套路准备活动达成了高度统一大家的经验和知识就有了一个共同的积累平台企业对用户就真正具备了广泛的一致性。
有了这样的平台企业才可以真正积累公司层面的知识管理避免大量的发散性行为。很多公司并没有认识到一个可培训可操作的演示平台比大量繁复的文档更有利于工作更有利于培训更有利于产品进步更有利于公司知识积累。
很多公司的策略是做产品既然是产品就应该可以形成相对固定的套路去服务不同类型的客户也就意味着公司可以形成相对固化的套路这个对公司形成统一的认识非常重要公司往往不是缺想法而是这些想法不系统不深入更多的是灵光一现不能积累和继承。
个人以为标准售前演示套路准备意义重大需要一步步通过演示工作去强化公司层面的工作导向将其意义最大化效益最大化工作协同价值最大化积累成本最小化专人专岗长期制度化负责。
4.8 如何准备标准演示套路(下)(
4.8.1 如何准备标准演示
准备标准化演示并不难不同公司产品不一样演示套路和侧重也不会一样但都可考虑按照以下思路进行。
第一要成立专人负责的岗位和相应制度否则能准备一次不错的演示但总不能随着产品发展和实施业务创新而不断更新演示套路。一般这个工作可以让咨询顾问兼任。
第二要清楚演示给谁看不同人员关心重点不太一样因此建立可以准备侧重政府领导专家教授企业高管技术人员四个层面的演示体系。
第三要让公司能力最强的人参与到标准演示套路中来直接准备演示套路的人应该是对企业业务了解配置水平最高的人这样才能最快有效把公司知识积累到标准演示套路中并定期请规划、开发、实施、测试、销售、咨询各方面精英人员参加内部组织的演示套路评估提出基于各类业务的改进要求不断完善和改进产品功能和演示套路。
第四要形成和标准演示套路配套的标准演示方案和常见问题解答指南演示方案要口语化强调可操作性类似于表演时的剧本。
第五要让演示准备工作和规划、开发、实施、测试、销售、咨询各个部门培训工作主动衔接起来定期根据标准演示套路进行不同侧重点的部门培训快速把能力扩散出去。
第六要让咨询顾问和实施顾问根据标准套路准备标准解决方案和实施方案形成一致性。
个人以为完成以上六个方面的工作才是一个完整有质量可结束的标准演示工作。
4.8.2 不断结合实际情况总结演示套路
实际进行演示的时候演示者临场自由发挥成分还比较多演示完全不发挥不可能。
首先应要求演示者能按照标准演示套路照本宣科进行这样可以保证最基本演示质量然后在大量实际练习中把产品功能和企业业务能够融会贯通最后才能够在现场高度自由发挥。这三个阶段不能逾越否则现场一人一个样总结标准套路的工作就会失去意义。
既然有发挥就有好也有不好所以公司还必须总结每次实际项目特别是售前演示效果无论成败总结得失并将意见反馈到演示准备部门持续完善持续改进每天都能进步1%的对手才是最可怕的对手。
一般反馈意见可以从以下几个方面改进和考虑
如果是功能上对手具有我们没有的特色应反馈给产品规划部门跟踪业务规划改进
如果是操作过程演示层次不清晰不连贯应考虑如何结合业务形成更有效演示方式和表达语言
如果是产品性能不足导致演示时拖泥带水应反馈给测试部门作为缺陷加以改进
如果是人员表达不到位导致产品特色没有清楚讲解出来应考虑逐步加强培训加快知识扩散周期。
4.9 如何进行现场演示(一)(
4.9.1 建立演示心态
作为一个演示者要有一个平和自信积极的心态。相信自己可以取得成功和得到用户的认可。
好的演示心态天线在自我定位重视和敢于挑战对手临场发挥三个方面。
好的演示心态下演示者是不会心浮气躁上来就攻击对手指望一棍子打死别人搞定客户
好的演示心态下演示者不会看到强手就害怕发虚看见对手实力不强就轻视是遇弱我强遇强更强勇于面对压力和挑战正常甚至超常发挥
好的演示心态下演示者在演示过程中不会遇到一点挫折就心灰意冷会做好多次反复交流的准备这个多次反复交流就是客户对你还有兴趣的一种表现
好的演示心态下演示者对自己精心准备的套路和功能也不会过于自信用一种平和的语调和对事业执作的激情感染用户打动用户让客户相信我们是一帮想做事肯做事会做事的人演示时无论得分失分都不要高调肚子没有货的人才喜欢炫耀
好的演示心态下演示者在演示过程遇到设备和软件操作意外一定不会紧张紧张就让别人看笑话。即使是出现很严重地低级软件错误也会不慌不忙重新开始不需要做太多没有必要的解释一定要解释也应该是幽默的方式。用自己的从容镇定感染用户建立用户对自己的信任对公司的信心。
根据个人经验一个好的心态演示者往往是哪些对自己的公司对自己的团队对自己的产品对自己的能力有充分自信的人才能上阵不要用那种对公司没有认同对产品表示怀疑的人去演示他们在演示过程中抗击干扰和打击的能力往往不好。
很多人在第一次演示或者头几次演示时很难克服一种恐惧心理这种心理诱因很多但往往是越害怕越想越想越害怕还没有开始讲自己就先崩溃了。
对于恐惧心理最有效的方法就是转移注意力和积极的心理暗示。把注意力集中在演示内容本身上而不是别人对于你演示质量的评价上并不断提醒自己一定可以做到比对手更好。
这里有一些标准放松方法可以提供给大家使用
对着镜子试讲想象你面前是你的听众。
可能的话在实际演讲会场进行试讲。
确保你一直可以清楚地看到你的笔记或小字条让自己觉得就算是忘词也可以看到下一步该讲什么。
深呼吸并保持微笑。
4.9.2 准备演示环境和检查设备
准备环境事先可考虑以下要点
后勤方面谁在组织者这次演讲(了解详细情况)
交通如何安排(计划并检查旅行安排)
会 场会场大小和形状如何(向组织者索取一份楼面布置图)
可用那些设备(弄清你要用什么设备避免用不熟悉的设备)
时 间 表谁在你之前发言(弄清你是否有机会听他们发言)
谁将把你介绍给听众(一定要事先向介绍人做简要介绍)
实地检查在演示前最好能够提前到演示场地检查并提前调试设备。
场地和设备检查一般要注意这么几个环节演示场地大小座位分布光线明亮度由此确定自己演示时应站的方位和投影的方位。
如果有扩音系统要提前测试一下确定自己发音大小。
测试投影系统和网络连线是否正常电源开关是否可用线路长度是否足够如果有问题应提前解决。
如果现场有自己不熟悉的设备尽量不要在演示时使用或者提前请人调整好。
演讲位置光线是否充足能方便为其它人所看到没有视线阻挡物。必要时要调整座位分布以有利于演示进行。
如果是有重要领导和专家检查的大型汇报演示还要注意这么几个环节
给领导和专家设置贵宾座和领座牌
在演示场地内外布置欢迎牌和标语
在演讲桌上布置鲜花等修饰品体现专业和隆重程度
在主要就坐位提前放置饮料和相关资料并且注意资料饮料排放前后左右一字对齐。
4.10 如何进行现场演示(二)(
4.10.1 演示时要注意的一些细节
4.10.1.1 如何注意演示姿势
演示站位也有技巧一定要正面面对大家尽量看到最多的人。
如果围着一个圆桌你应该靠在最前面你能看到所有人但是你应该站在主要人物的对面。
听众的数量对你组织演讲的方法有很大影响。听众人数少你和听众就有充分机会进行交流。你可以边演讲边回答听众提问也可以就有关问题征求听众的意见。听众人数多你与听众的沟通只可能以单向交流为主发言方式就应完全不同。
有时候演示只来了二三个人不一定要大张齐鼓的讲可以考虑一下是不是大家坐在一个距离比较近的方式去沟通会更好一些。
人比较多的时候站起着讲人比较少的时候坐着讲站起来讲的比较容易观察每个人的反应。
如果是选择站立姿势身体站直两脚稍稍分开体重均匀地分布在两脚上手臂在身体两侧自然下垂。这是最无明确表态的姿势是中性的身体语言。如果你了解不同姿势的含义你就可以在此基础上创造不同的印象。例如身体稍微前倾显得积极友好——好像你在邀请、鼓励听众。反之身体稍作后倾就显得消极还可能有点挑衅意味。
演示过程中可以恰当使用手势一般人使用手势最大问题是有一些不好习惯性动作会出现解决这种不良动作最有效方法是看演示过程录象。
4.10.1.2 要不要派发名片
演示前可以不派名片要派就全部要派。
而且派发时由领导沿一定顺序分发不应跳过某人再分发也不应先发普通人再发领导。
领导没有入场之前可以先给其它人发领导入场后根据情况决定是否分发名片。
4.10.1.3 演示前等待时间怎么办
演示前等待时间是很尴尬的时间所以一般演示者可以请其它人去检查设备自己找一个安静地方考虑思路等到时间差不多时再入场避免这段真空时间。
如果用户没有及时到场主要演示者要体现一定专家身份可以安静等待人数不多时可以适当交流。这个时候商务人员可以适当活跃气氛让大家不觉得等待时间过于尴尬。
4.10.1.4 演示着装
演示衣服最好是正式的特别是正式演示而且所有人着装应该统一最好是西装。
西装最好是一个颜色灰色或者蓝色这是标准职业装。
4.10.1.5 关闭手机
演示期间一定要保证无手机铃声最好的方法是直接关机。所以应提前告诉你的同事你的工作时间防止干扰。
如果确实有紧急事情不能关机请其它同事演示时间内代管。
4.10.2 演讲开始时紧张什么办
即使是很有经验的演讲者每次开始演讲的时候都有一些紧张而且在演讲的时候必要的紧张是需要的。必要的紧张会使人注意力高度集中大脑在快速紧张地思考从而可以更好的把演讲思路搜索出来并根据用户反应进行内容和言语上的调整。
但是有的演讲者一紧张就忘词结果开始时就有一些不流畅结果越来越紧张。这种情况就需要大量的进行演示练习和试讲。练习和试讲可以消除演讲者由于对内容不熟悉造成的紧张而且大量的试讲会累积一个人的发表欲望经过多次准备的人会逐步对自己演讲建立一些信心并有发言的欲望整个过程就容易有激情不那么畏惧。
很多时候紧张就是因为对自己讲演的内容不熟悉没有信心导致担心自己发挥不正常影响整个计划越怕鬼越闹鬼。
此外演讲开头人总是有些紧张的这个时候演讲者可以多注意观察会场通过目光交流发现有兴趣的用户看到用户有兴趣了自己就逐步有一些信心慢慢就不紧张了。
此外设计一个轻快有趣的开场白也是一个有效的手段如果在一开始用户对你的开场白就有了兴趣或者发出了笑声这个时候演讲者一般都可以松弛下来进入一种良性的演讲状态。
最后注意语速用中等偏慢的语速介绍内容也是逐步释放紧张的一种方式。很多人一紧张讲话就会无意识加快一快听众就更不容易明白不明白就没有兴趣这种表现会反馈到演讲者身上进而形成演讲者的焦虑焦虑的演讲者这个时候往往不自觉越讲越快这个过程陷入高度紧张恶性循环不能自拔。
4.11 如何进行现场演示(三)(
4.11.1 演示过程中听众感觉厌烦或注意力不集中怎么办
很多时候即使你做了精心准备到了实际上阵却发现好象感兴趣的听众并不多这个时候演示者往往比较受打击有的人就比较紧张觉得用户对自己的内容不感兴趣脑袋一紧张就不灵光能把事先准备的内容讲完就一头大汗。
一旦发现用户对内容不感兴趣演讲者要紧急判断是自己准备的内容对用户的针对性不够还是演讲时间安排在一个比较容易疲惫的时间段如果是前者演讲者要立即改变演讲的话题逐步将内容往用户感兴趣的方向上引如果是后者演讲者就要发挥语言技巧增加互动提供一些幽默的段子调动大家的兴趣。
本人曾经参加了一次国产软件鉴定会来的都是企业的领导和信息化负责人整个上午领导和专家用学术性语言做了冗长的汇报上午的会议一直12点半才开始吃饭到了下午1点半就要开始我们的产品介绍会这时来参加会议的人几乎全部都昏昏欲睡我们前一个介绍人员又座在椅子上讲了半个小时的理念一看大家几乎都要睡了也很机警请我上来讲。
我上来以后并没有就坐而是站在离大家比较近的地方开始第一句话就是说“各位上午开了一上午的会肯定很疲劳了我呢想结合我们实施工作讲一些比较实际的东西谈谈我实施工作中一些小故事”。
这里我就使用了两个技巧第一是站立当你近距离站立在别人面前的时候由于别人是坐着出于礼貌就不得不抬头看你一抬头精神就不一样了一勾头就肯定继续睡下去了第二一直在听各种理念肯定很厌烦我主动说将一些实际的故事大家就有了一些兴趣有了兴趣自然就容易进入听演讲的状态。
在后面的演讲中我就放弃了用技术语言介绍的原计划全部用一个又一个实施过程中的酸甜苦辣的小故事和用户交流在用户一阵阵笑声中交流就取得很好的效果到了演讲结束用户纷纷主动索要我们的名片。
要避免出现用户厌烦的局面第一在演示准备前弄清楚对象确保你所讲的内容切题且适合他们特点不然就砍掉。
第二演讲者整个演讲过程要有激情很多时候用户并没有记住太多内容但记住了那个演讲很不错的人和那个人所代表的公司。这个时候听众记住的可能只是那个演讲者的精神面貌状态而已。
你积极的态度、活力和热情将增强你演讲的说服力。演讲的具体内容或许会被忘记然而你的态度、活力和激情将深深地印在听众的脑海中。
第三演讲过程中语言要抑扬顿挫千万别只有一个语调并和听众保持目光接触目光接触要注意随时看到整个会场所有人员并保持微笑让他们感觉到你很重视他的表情反馈。很多操作性演示者为了确保自己操作不失误往往花费大量时间看电脑进行操作这是不对的整个演讲过程中听众注意的中心只能是演讲者本人不是软件操作只有当演讲者觉得用户需要看操作的时候才主动引导用户注意观看软件操作。特别是在一些需要大量时间操作的环节如果将注意力集中在操作上会让用户产生软件很慢的感觉其实在实际操作中速度并不慢但由于在这个特定的场合用户往往会形成这样一种心理印象。
第四演示过程中演示者不要经常无意识挪动鼠标来回拖动界面分散用户注意力。界面不应反复切换应该一个界面一个界面把软件思路和业务流程配合关系讲透再切换下一个界面或PPT。
第五控制一次演示的时间。成年人集中注意力的时间限度约为45分钟。在这段时间内他们只能吸收演讲内容中的三分之一最多七个概念。将演讲要点限制于三到四个并在演讲开始与演讲中加以强调最后再加以重复。尽量用一个有吸引力的标题来概括你的演讲但不要太概括或太含糊。
4.11.2 演示过程气氛不积极怎么办
演示者发现听众精神状态不够好的时候首先要把自己精神状态调整过来不要受影响。我们许多人是很容易受打击的很容易受环境的影响。一定把这个势气调动起来。演示者有了精神状态就有激情有了激情就会感染别人哪怕你讲的不好别人也认为这是个想做事的人他对你的演讲也会一定程度上认可。
此外为什么演示效果不好呢让大家跟我互动的时候演示者经常会问一些问题很多问题并不需要听众回答而是让听众进入思考让听众跟着演示者思路去思考“我们企业里里有没有这个问题呢这个事有没有解决呢”
然后演示者再告诉听众怎么做所以演示者不要光谈功能谈概念而是先谈企业的常见问题是什么原因是什么如果解决了好处是什么然后告诉听众怎么做这时听众就会有兴趣。要不断地问问题调动他然后不断的讲好处你的业务线自然就串起来了因为你是为了一个好处解决一个问题又带一个问题又解决了。这就叫完整的解决方案。
在成功的演示里好处太多就没有重点一般只需要归纳出三个好处即可多了记不住。
演示时应该让观众有一种参与感就象讲相声一个吹、一个捧一样。不要一个人唱戏。
应该适当地在演示时向观众提一些问题比如企业的产品、任务情况对软件的了解情况是否使用过相关软件等。
也可以顺便拉几句家常使气氛活跃起来。讲某些概念比如对象、配置、参数化要把概念讲通俗一些使观众能够听懂。
4.12 如何进行现场演示(四)(
4.12.1 投影仪连不上什么办
在做演示之前一定要检查好硬件设施。但即使这样也会出现无法提前检查或者意外发现演示厅里的投影仪接不到笔记本上的情况。
此时关键是不能着急和冷场。在演示时应准备一些公司的简介和客户关心信息并进行口头介绍将时间拖到投影仪接好。
然后在随后正式介绍中弱化这一部分的介绍将耽误的时间赶回来。
本人就曾经遇到这么一次情况投影仪突然罢工结果就按照业务思路不慌不忙一口气在没有电脑情况下做了一个小时交流客户听得很深入一个小时后投影仪修复再看软件客户理解得很快对我们产品很认可。
4.12.2 演示中客户的主要负责人总接电话怎么办
领导接电话一定要等人少时直接停下来表示尊重或者继续用比较慢的速度讲然后等领导停下来说“某总刚才我给大家介绍了一下什么内容”快速补过给足面子又不冷场。
4.12.3 多个公司连续演示你排在后面此时客户已经开始听觉疲劳怎么办
演讲很多时候不是你最先讲那么别人讲得好的内容要能立即化入你的过程中巧妙利用别人烘托自己也无形中让客户将别人亮点记到你的头上。
别人讲得大家昏昏欲睡时可以先准备一个笑话和有趣的PPT给大家刺激一下用一个轻松的心态进入交流的氛围。
有一个有趣的开场白是很不错的选择不过如果讲一个大家都知道的笑话或者和演讲内容没有关系的笑话却不是一个好的主意。
4.12.4 演讲过程准备好的配置突然死机或者不能出来怎么办
第一不要紧张继续进行你的陈述就当操作是正常的。
第二马上同时手工调整如果正常可以继续说刚才我介绍的“***功能现在大家可以看一下”
第三如果实在问题严重无法快速解决解释一下原因例如机器中毒了很多突发问题。所以计算机安全很重要。
第四自我解嘲进入下一个功能介绍还是不当回事。你越紧张用户越怀疑。
打动用户更多的是你陈述而不是一时半会无法领会的界面和操作有点问题你不在乎用户也就不会认为是大问题至少你的镇静可以为你捞回印象分
第五强调一下笔记本机器配置不好或者装了太多系统我经常拿着3年前本子做演示速度慢一点用户反而理解。
4.12.5 演示时有人打叉怎么办
当你在演示时频频有人打叉问出各种各样的问题有可能是某人非常迫切希望你跳跃性介绍他关心的内容。
也有可能是提出对演示者非常不利的问题甚至是攻击的问题。
因此在演示软件时要注意重点突出不重要的例子可以根据观众的要求适当调整或者不演示。不管何种情况您可以这样回答“请允许我花20分钟先介绍一下软件的基本功能再回答您关心的问题”来保持正常的演示顺序。
对于观众提出的问题可以表示赞许“您这个问题提得很好我们开目软件已经考虑到了”“您的建议非常好我会向公司领导汇报考虑您的建议”“您可能有些小小的误会其实这个功能是有的”。
对于确实是刁难性的问题可以说“关于这方面的问题我们可以在演示完以后再详细讨论”“这方面的情况我不太清楚”“这方面您是专家”“软件的优势不是绝对的有些软件确实在某些功能上比我们方便一点但在与***有关的主要功能上我们是非常方便的”等再约私下进行讨论。
对于一些刁难的人大多数情况他是想表现一下自己多奉承一下让他获得心理上的满足即可没有必要与之争论太多。当然对于少数确实是故意为难的人也可以明确作出回答争取大多数人的支持。对于关键的决策人要始终保持温和的态度。
4.12.6 演示时用户临时表示时间不够怎么办
“我没有时间你不用演示了我们这儿对软件熟悉的人很多只要留套软件留份资料我们看一看就行了”
可以回答“我的演示很快不会占用您太多的时间”“我们这个软件与其他软件相比有很多优点值得您花一些时间看一下”“我可以简单地把功能和特点演示一下相信您会大开眼界的”。
不过给领导留一份详细的资料的十分必要的。
4.13 如何进行现场演示(五)(
4.13.1 演示过程用户要求改变主题怎么办
演示者在演示的时候一定要有激情有好的状态但是千万别太自信要能应变。
万一听众听着听着说“这些东西我不想听你直接讲是什么东西”突然来这么一下怎么办可能听众里就有对手的钉子故意难看你一下。
这种事情无法避免只能预防首先在排练的时候自己人要给自己人发难在内部排练时尽量模拟真实极端情况。应变也是练出来多经过几次实际演示也会积累很多经验。
真正有经验的演示者在一个演示方案中可以从几个地方作为开始多设计几条路万一客户不愿意听还可以从其关心的点切入等其接受了还是逐步展开我们完整的解决方案思路。
4.13.2 演示过程如何答辩
一般软件产品演示完成后用户会主动安排或者临时提出一些问题这个时候就比较考验演示者的快速反应能力也能体现一个公司的综合实力。
特别是在一些竞争性项目上部分听众会带有挑衅的口气向你提出责问这个时候如何有效应对从容自如完成答辩也是非常重要的演示得分环节。
本人的经验在演示过程中遇到疑问甚至是刁难都是正常的不要畏惧把这个工作当作演示工作中的一种常态。
用户问得问题越多是对你的产品有兴趣的一种表现大家应该高兴的去解答问题而且这个解答过程中无论用户处于什么心态我们要保持微笑和认真聆听的态度。
针对答辩有几个重要的技巧
第一对于一些比较复杂的问题或者一个用户提出了多个问题首先不要急于解答要先用笔快速记下来边记边寻求最合理的解释也可以防止遗漏用户的问题以免用户发现你遗漏后再提一次感觉你在回避问题我们毕竟不是外交场合是技术交流技术问题不应回避。
第二在回答问题前可以把一些复杂问题或多个问题复述一遍即请用户确认又为自己争取思考的时间但对于有些很简单或者明确的问题要立即肯定积极自信的回答例如用户在演示时没有注意到他关心的一个内容这个功能有的确是软件常规功能我们可能就没有重点介绍这个时候要立即和肯定告诉他这方面我们没有问题不能犹豫磨蹭。
第三回答问题反应要快针对问题本身不做发挥言简意赅。一般答辩时间不会很长时间宝贵不要对于某一个问题长篇大论用结构化思路或回答套路快速扼要让用户听到答复并礼貌性问一问不知道这样回复您觉得满不满意之类结束。如果对一个问题解释过多可能也不是一下子能解释清楚的反而会越解释越怀疑越觉得累。
第四有些用户问的问题可能带有恶意或者的确是软件的软肋此时不应回避要迎着问题解答可以通过介绍我们正在开发的产品或正在规划的思路来肯定性回答越是自己不强的内容越是要在演示时讲透我们的业务思路反而用户会少在答辩时提问题越是在演示时回避越容易被提出来并刁难。
而且这个时候我们可以用“你这个问题很好你说出了很多用户关心的问题你这个问题的确很有难度看来您对***很有了解”之类开头缓和气氛拉进距离增加思考的时间。
第五如果企业内部有我们的支持者不仿先设计一些有利于我们的问题让他们提向我们和竞争对手这样也是一个有力的武器。
最后对于一些纯技术性问题可以要求用户会后进一步单独交流避免出现不得不花费大量时间解释一些大部分人不感兴趣的问题。
如果有条件是多人参加演示的话可以就个人专长对问题回答提前做一分工准备一些可能要回答问题清单并提前设计回复这样在演示现场时也可以互相配合快速有序完成任务。
答辩考核的是一个公司和个人的综合能力所以真正答辩的精髓不在现场快速反应而在平时对企业管理业务、产品规划、业务知识、实施理念多个环节的知识积累答辩优秀的人往往也是在知识面和深度上下工夫最多的人这才是成功答辩的秘诀。
4.14 如何组织演示后工作
4.14.1 争取约见重要领导
演示结束后如果有机会演示团队一定要和参加演示主要领导甚至是没有参加的重要领导。
不要放过这个有利的时机和重要领导沟通的机会建立印象分在演示过程中可能更多用业务的思维讲产品技术能力但和领导沟通的时候更多的用管理的思维讲产品技术能力这两种沟通往往不能在一次演示中兼顾到位但可以主动创造机会在后续活动中实现。
当然和重要领导见面机会并非可以有软件供应商控制但和重要领导沟通的工作意识随时保留饭桌上就是很好的场合。
4.14.2 提供备忘后续跟进
演示无论实际效果如何一定要留专业的备忘录一定要和用户约定后续工作计划并按照备忘的承诺推进后续工作。
所以重要项目现场演示过程中应安排专人记录将演示过程和过程中大家提出的问题和回复逐一记录对于一些暂时无法清楚解释的问题约定后续解释工作安排。这种专业备忘整理能力是很能反映一个公司职业能力和职业水平的。
商务工作在演示达到目的的情况下就可以更加良性的运做包括马上根据这次情况和对手反馈准备解决方案公司考察用户考察选型方案招投标方案和答标演示等等。
在没有达到目的的情况下更要进行权衡是否进一步加大投入扭转局势还是无力回天集中精力做其它项目。
4.14.3 总结演示得失形成反馈文档
演示结束后要针对演示实际效果形成反馈评估文档针对演示者个人能力针对标准套路组织水平针对产品技术能力结合竞争对手和用户意见形成反馈意见这将形成有力的产品规划动力和演示准备改进动力。
很多项目在一开始接触时就可以发现一些现有产品无法满足的部门如果在售前系统演示后用户还坚持要实现的功能如果此时提前给公司评估和规划在未来实施时就赢得了时间的主动权。
永远要比对手多走一步才能赢得最终的胜利。
4.14.4 一流演示的效益
每次好的演示都可以培养出一个能战斗的领队型策划型人才每次都能让客户经理认识到公司强大实力和产品能力对自己未来工作充满信心。
每次通过售前充分的演示准备和排练可以培养团队作战的感觉建立一个强有力的集体这样的项目售前演示最容易凝聚人心建立信心。
演示工作最失败的不是一个项目得失而是内部成员对公司和产品信心丧失。
4.14.5 失败演示的特征
没有演示策划
没有进行需求调研演示时无法用客户能理解语言沟通
过早的进行了演示
没有认真评估演示产品线或模块
演示没有套路
演示没有就用户可能的提问做准备
没有后续工作跟进
4.14.6 一流演示人员应有哪些素质
实际项目实施经验
良好的口头和书面表达能力
表现欲
丰富的知识面
快速业务调研能力
快速学习能力
快速反应能力
4.15 演示方案准备经常考虑的问题
4.15.1 听众分析
会有多少人来听演示讲
听众的平均年龄是多少
听众的男女比例怎样
听众了解你的主题吗
听众是自愿来的还是别人要求他们来的
听众有何共同点
听众有何先入之见
听众有何文化特点
所有的听众或某一些听众是否认识你
评估听众的可能对问题反应情况。
4.15.2 根据听众人数调整演讲方法
4.15.3 演讲的结构类型与材料相适应
4.15.4 使用叙述法
叙述的基本技巧在于使发言有一个明确的开始、中间部分和结束。这种技巧最常用于讲故事。你要成功地演示遵循这一基本格式来组织演示是很重要的演示的引言就是开始部分中间部分就是演示的中心主题和观点(用你认为最适合的结构类型提出)而结束部分则由你的结束语构成。在结束部分重提核心主题如有必要再回答听众的提问。记住重要的是在演示各阶段的开始时和结束时向听众提供明确的有关线索。
4.15.5 编制简化提纲
准备一份书面的演示提纲是很有帮助的。在书写提纲的过程中组织演示的方式会逐步明朗起来。在演讲过程中带可用提纲来提醒自己。将你的三四个要点标上“一”、“二”、“三”和“四”然后在它们下面分别写上二级标题(1、2、3)。如有三级标题就用A、B、C标出如此等等。提纲要写得简单使之一目了然。
4.15.6 设计开场白
要想在演示一开始就给听众留下好印象最好的办法是你显得坚定而自信。
有经验的演示者总是每次设计开头的两句话这样就可以把注意力集中在如何打动听众上而不必过于关注该说些什么。
一个成功的开场白会概略地说明你将作的演示简要地告诉他们你将提出的观点。讲些趣闻轶事以亲切友好的方式来活跃气氛并吸引听众的注意力。但要牢牢记住在演示刚开始时听众的注意力并不最集中因此要在演讲开始几分钟之后再提出你最有力的观点。
4.15.7 听众注意力的持续时间
以45分钟的演讲为例听众在演示刚开始时注意力很集中10分钟后达到顶峰到30~35分钟注意力消退。最后当演示快结束时注意力又增强。所以演示方案中要设计关键内容和听众注意力之间的对应关系。
4.15.8 设计过渡词
用清晰的线索来贯串演示是很重要的。安排好观点与主题思想的逻辑顺序让听众轻松地跟上你的演示。当介绍新的内容时要将前后观点紧密地联系起来。
因此不同演示点之间一定要设计易于接受的过渡词帮助听众把思路联接起来。
4.15.9 运用重复
演示时作扼要的重述是强调要点的有效方法。组织演示内容时在每个要点的结束部分及在整个演示的结束部分安排一些重复。但是简单地重复你前面讲过的话是不够的。要用不同的措词使你的观点听起来既新鲜又熟悉。
4.15.10 难忘的结尾
一个好的结束的重要性不亚于一个好的开头。示意听众演示已近尾声是十分重要的。用“我要讲的最后一点是……”或“总而言之……”等使听众注意到你就要总结你所说的话了。他们会很高兴有机会补听他们可能漏听的观点。
4.15.11 强调观点
强调演示的要点相当重要。强调要点的方法可以是先向听众提供演示“目录”资料然后讨论你所提出的问题最后通过作总结来结束。
4.15.12 撰写口语化讲稿
要注意把书面材料以口头方式告诉听众时听起来会有很大不同。要学习以自然的口语方式写讲稿这样你的讲稿就符合平时的说话习惯并适合作口头演示。
4.15.13 将演讲方案浓缩为提示卡
如果你想使用提示来演示首先要写出完整的演示稿包括所有要点和用来阐释、说明这些要点的例子。以这个稿子为起点你可以将演讲内容浓缩为提示。将从稿子中选出的关键词或短语清楚地写在编过号的卡片的一面。一张卡片上不要写得太多要保证住处的简洁和明确。
准备讲稿确定了演示的结构而且组织好了收集到的材料后将发言完整地写出(或打印出)。编辑、修改这个稿子直到读起来觉得通顺而有节奏时为止。
准备提示卡从最后一稿中抽出要点写到编过号的卡片上。为清晰起见每张卡片上的提示应不超过两个。
可以用黑墨水写绝对必要的内容而可以删除的内容则用其他颜色的墨水写。
4.15.14 注明演讲的节奏
想一想是什么因素促使演讲成功那通常是时间的安排。演讲的无声部分即停顿在传达演讲内容的过程中与说出来的话同样重要因为它们是听觉上的标点符号。在撰写讲稿时要考虑听众听起来会感到怎样。不管你演讲时用提示卡还是完整的稿子在你觉得必要的地方例如在需要强调的观点旁边或在两个完整的观点之间写上“停顿”两字。试讲时也要使用这些停顿。使用沉默需要有勇气一个注明的停顿应持续三秒左右这比平时说话时的停顿要长一些。
5 如何做用户考察
5.1 前言
5.1 前言
入行五年做了一些相对成功的项目而且所做项目离公司总部比较接近因此经常有机会接待客户提出的典型用户考察请求。其实每个业内成功的项目经理都有一些售前的经验甚至在售后出色的人才会主动被抽调到售前也许是有经历的人的话更能打动客户的心。今天把我个人做典型用户考察接待的体会做一总结希望给大家提供一点帮助。
5.2 典型用户有什么意义
一个项目在技术上决定成败有两个重要环节一是产品演示二是用户考察。两个环节都很重要而且往往在很短一个时间段内完成(相对整个项目跟踪周期)所以典型用户考察工作不能不认真对待甚至要作为售前售后最关键的工作来对待。
现在很多用户非常怕被软件供应商忽悠对考察工作尤为重视甚至不通过供应商引见自己去打电话暗访明查有的担心我们提供电话是经过事先联系形成默契的还主动多打电话问几个人了解软件应用情况到底怎么样。
因为无相关行业用户应用示范或者因为典型用户考察效果不好导致项目无法拿下的情况是非常常见的。
好的典型用户对售前项目有多大的辐射意义并不需要去强调做商务的人都明白这一点但典型用户不仅对售前有意义对实施规划都有更大的意义。
一般典型用户应用比较深入往往累积了很多成功的经验这些经验往往是比较成熟的套路可以总结推广到其它相关类似用户身上获得比较快的实施效益。应该说每个典型用户身后都对应一套完整可推广业务实现实施模型值得很好总结。
典型用户应用比较深入往往能提出更多更有价值的需求这些需求对产品发展有很好促进作用典型用户一般又愿意和我们长期合作通过详细解剖典型用户需求和业务模式可以缩短软件供应商了解行业业务的时间形成有效产品规划指导产品发展。
典型用户还是一个公司营销开发团队是否有信心的关键一般公司开发人员无法直接关心用户但营销和实施不一样如果一个公司到处都找不到典型用户的话这个公司营销和实施工作开展也不会顺利人员流动将非常频繁大家对公司也没有足够的信心。如果一个公司拥有一批成功用户所有员工基本上就会把精力更投入到业务中因为大家会觉得既然别人能成功我应该也有机会成功而不是一致责怪公司这里不行那里不到位导致事情没法做。
5.3 典型用户应如何管理(上)(
和产品演示一样典型用户管理也是一个系统工程不是通过突击就可以实现的。要想管理好典型用户就应该在公司层面有专人定岗定责进行管理没有专人管理典型用户信息业务一定会出问题。
典型用户管理应该经过三个层次
5.3.1 典型用户确认
首先要将对公司市场工作最有利的典型用户筛选出来这些用户其实在售前跟踪时就可以通过客户ABC分类加以明确这样即使某些客户在第一次合作时项目金额并不大也可以在在项目实施过程重点保障资源重点投入。
一般选择典型用户名单考虑以下七个因素
1) 应用效果有三类用户可以做典型用户。第一是成功进行了大量应用的用户最好的典型用户是实际业务每天都要大量人员利用系统进行工作的用户而且在实施过程中有很好的参考作用的用户这样有实际应用效果的用户最能让其它用户相信软件公司的能力第二是一些应用面还不够大但基础数据都基本录入典型业务流都可以实现的用户第三是非常有特色的用户也可以作为典型用户。当然实际应用效果是选择典型用户首要因素。
2) 商务关系所谓典型用户就是希望能够替公司提供宣传的用户这些用户论高管还是中层干部或者基层操作人员应该认同软件公司产品愿意推荐软件公司的产品如果没有好的商务关系用户甚至对软件公司还存在意见即使应用情况不错也要考虑是否适合做典型用户。典型用户的商务关系应该一直有专人负责跟踪和维护仅仅靠客户经理和实施经理维护是不够可靠的。
3) 行业影响力影响力越大越好一般情况下行业影响力大的用户公司应在商务和实施时区别对待重点投入而不要简单受项目金额大小左右否则可能造成服务资源不够做臭一个丢掉一片。
4) 业务应用丰富以技术信息化软件而言要考虑典型用户至少能覆盖有设计有工艺无设计只有工艺两种研发模式有设计无工艺的可以直接看有设计有工艺的类型。否则用户考察时会提出感觉没有看到自己想要的内容。有设计的用户应该覆盖到一种三维软件一种二维软件。这样的考察效果才能达到全面完整业务类型丰富而不是一个用户实施比较成功参观就一定有好的效果要选择一个业务应用尽量丰富的企业。一般随生产模式(单件多品种小批量大批量)不同业务应用丰富的企业也要选择几种类型才能适应不同生产类型用户考察需要。
5) 地域辐射力典型用户地理位置应该交通方便不然会增加客户交通成本也增加公司接待成本而且无法起到长期辐射作用。一个全国性公司一定要考虑在全国建立可参观考察的典型用户网络仅仅只有几个典型用户参观考察对用户本身也是一种巨大的骚扰而且对很多地域性用户不方便出省考察的客户是很难做到有效辐射。
6) 服务资源典型用户并非一定是所有问题都解决了的用户往往是经常性需要服务的用户因为应用深入需求比较多而且系统不能停一停就容易出问题但很多时候典型用户要协助软件公司做一些参观考察工作这个时候往往需要提前解决一些软件应用问题以便让典型用户在考察前有一个好的状态这样典型用户如果完全没有服务资源往往会出问题。
7) 介绍资源典型用户接待客户参观时效果一个重要因素是企业有无能交流并把业务和信息化实施过程问题介绍清楚的人员如果有一个这样业务能力比较突出又全程参与项目实施过程的人员能介绍项目实际情况是最好不过。
典型用户确认未必一定要以现在是否可以立即参考考察做依据而是应该综合以上因素以后确定名单然后通过一系列工作努力让这些用户成为可以参观考察的用户。
5.3.2 典型用户分级确定服务模式
典型用户名单确定后立即要根据典型用户可考察参观实际效果情况对典型用户分级。
第一类典型用户是可以随时安排参观考察的典型用户。
第二类典型用户是可公开宣传但不方便或不愿意接待参观的典型用户。
第三类是可以在售前非公开资料和口头介绍的用户。
第四类是千万不能公开介绍和宣传的用户一些典型应用不佳用户。
第一类用户应加强商务联系签订宣传合作协议保障定期走访服务让典型用户和我们长期合作心情舒畅
第三类、第二类典型用户要根据情况确定是否可投入资源使其向第一类第二类用户逐步转化一个公司第一类典型用户多了市场口碑就起来了甚至服务价格就可以提高了。
一、二、三类用户都要明确详细的服务模式并落实到具体实施部门或区域团队管理并定期检查服务工作是否完成和质量这样才能形成一个闭环的管理体系不至于口头重视实际上因为没有利益(国内目前大部分项目服务是无法收费的)保障而无资源投入。
第四类用户也很重要有些用户在业内或当地知名度极高但软件公司在这里遭遇了滑铁卢所以公司一定要动态审查在方案、公司介绍、对外提供典型用户名单上尽量不要出现此类用户名单避免被潜在客户咨询或提出参观要求时被动。
5.4 典型用户应如何管理(下)(
5.4.1 宣传模式规划
典型用户的辐射效力体现在四个领域
售前主动介绍(文字和口头介绍)
客户现场参观考察
媒介(新闻性媒介和专业期刊)
行业或政府主办经验交流会议
所以典型用户分级后应根据这四个辐射效力领域分别设计相应的套路针对不同典型用户提供组合管理方案。
首先要为典型用户提供在公司网站介绍材料公司宣传手册公司各种方案材料公司售前PPT公司内部培训材料保持一致的宣传介绍材料。
完整的典型用户宣传介绍材料应包括以下几个内容
企业LOGO
企业厂区或典型产品照片
企业概述(有地位突出地位无地位突出业务特色)
企业应用软件情况介绍
企业应用现场或鉴定现场照片
企业高管或项目负责人对项目一句简短而经典的评价
企业应用效益
项目获奖情况(是否获得国家省部市级信息化建设项目奖励或者进入863主题计划)
其次典型用户现场参观考察工作需要组织的第二个方面下文专门另文介绍。
第三典型用户媒介报道也非常重要第一种是商业性媒介报道主要是重要客户签单取得阶段性验收最终结项通过重要机构鉴定和获奖应及时在公司网站合作媒体上发布新闻材料这类消息软件公司要有很强的主动宣传意识。
除了直接商业报道外还有一种软媒介报道就是和典型客户项目负责人合作就项目实施特色应用或者实施经验发表专业学术性文章在专业刊物上扩大知名度同时也为很多企业项目负责人解决很多实际问题。
最后应用良好的典型用户经常有机会参加政府行业或者集团内部主办的经验交流会或者鉴定会软件公司在申报项目的时候也经常需要请典型用户合作作为项目用户单位并需要配合盖章因此我们应建立典型用户的资料库随时备双方做汇报材料准备用。
如果有以下材料一般都应保留
详细的企业情况介绍(企业概况、行业地位、产品系列、人员组成、联系方式)
企业信息化总体规划方案
企业项目招标书(选型评分表)
企业项目投标书或者项目售前解决方案
企业实施解决方案
企业对外项目实施经验总结或成果汇报材料(文字和PPT)
软件公司内部实施经验总结(突出业务特点和功能应用特色)
项目双方主要负责人员简历(应每年保持更新)
其它值得管理的资料
完成这三个层次的工作典型用户管理应该说就是比较完整业务过程。
5.5 用户现场考察应如何组织(
一般信息化项目用户都会提出现场考察典型用户的要求那么如何组织用户现场考察工作呢
典型用户考察组织有三个层面
5.5.1 第一是公司层面
软件企业对于已明确可以现场考察的用户应要求建立考察模式并由专人负责维护一般就是项目实施团队负责设计项目现场考察行程地点业务介绍套路实施应用介绍套路和相关PPT并和企业接待人员充分沟通就交流必须向潜在客户讲到的亮点保证前来参观用户可以看到项目实施过程中的功能特色或实施特色不虚此行也是对潜在客户的一种尊重。
公司还要提前和典型用户沟通确认现场实施状态评估项目可考察性确定是否需要一些服务资源投入或者请典型用户进行专门准备。
公司还要注意和典型用户约定考察参观方式和考察频率了解典型用户安排方式是现场参观还是投影集中介绍还是在某个业务地点集中介绍典型用户一个月希望接待几批考察对象本月是否有重要任务不方便接待考察等情况。这些情况要提前通知到各地客户经理知情方便对潜在用户进行介绍。
公司还要收集整理不同考察用户关注的针对性问题或者考察评分表形成问题集和参考评分表备案这些内容将可以成为公司规划产品发展了解用户功能需求和实施要求的重要渠道也是向其它潜在用户提供如何考察的素材资料对于一些共性问题还可以形成公司级标准解决方案有利于各个方面人员和客户沟通。
最后公司要协调项目实际负责实施人员或者对项目情况比较熟悉业务能力很强的顾问型人员在考察期间全程陪同至少要保证现场有软件商的实施人员陪同。
这些工作一般有公司或者级别较高主管部门协调组织落实。
5.5.2 第二是客户经理层面
具体到某个项目考察这是客户经理应该负责的工作。
首先客户经理接触到一个项目应该要主动判断是否安排用户考察用户考察是否和公司考察放在一起进行还是在本地典型客户处安排考察在什么时候进行为妥。
根据这个判断客户经理再根据企业业务特点和需求和公司提前沟通确定可参观用户对象请公司相关典型用户负责人员提供若干典型用户相关资料以备用户查问。
一旦客户提出考察要求要提前和典型用户或通过公司和典型用户预约时间。注意尽量避开用户负责人不在公司陪同参观介绍人不在企业休息日或者拉闸限电(这个是近年中国特色)等情况紧急响应安排行程和场地并把前来考察用户详细情况(人数性别级别行程关注点)形成文档提交公司。
客户经理还需要了解潜在客户关注的问题很多用户会提前设计一系列针对性考察问题这些问题要提前发送公司典型用户负责人准备并通过公司或亲自和典型用户沟通介绍前来企业情况前来人数和时间希望考察内容可能要问的问题以便让典型用户自我介绍时更清楚情况能够达到较好的考察效果。
考察过程原则上客户经理应全程陪同客户经理在陪同过程中要做三件事情
1、随时和公司内部沟通通报情况和提醒注意
一般前来考察的客户需要通过客户经理介绍给相关人员并单独和相关考察接待人员沟通说明一些文字描述可能遗漏或者不容易写清楚的情况。整个考察过程中要随时注意进行这类沟通保持公司一致性。
2、亲自安排好客户的衣食住行
客户经理让客户感到亲切认同就是成功这些都是通过接待细节中体现所以客户经理要亲自做好这些工作为今后商务工作奠定感情基础。
3、写备忘录
客户经理全程陪同最重要目的是随时了解客户在考察过程中交流思路判断项目技术或商务侧重点应该是什么便于进行下一阶段商务和技术公关策划很多交流内容不是当事人是无法清楚表达和了解的。因此一定要利用这个机会充分了解用户想法甚至趁热打打边鼓促进客户下决心。
考察完成后客户经理要主动帮助用户准备一份考察备忘录。一般企业出来考察回去是要写汇报材料的但大部分人出来考察因为行程紧张并没有立即组织材料只是简单记录这样一轮考察下来再去组织准备工作量也不小而且信息遗忘可能很大。其实很多人并不擅长写文档如果这个时候有一份可参考的资料对这些用户该是多么方便的事情。
所以客户经理要主动在用户考察完成后写一份记录考察过程的备忘录备忘录可以分这么几个内容考察日程安排考察用户情况介绍和应用情况介绍考察过程交流关键内容及回复记录。这样的备忘录将非常有利于我们后续工作有这样现成的素材在难免用户会直接引用一引用汇报给领导就给我们增加了成功概率特别是当竞争对手都没有做这个工作就体现了我们的用心。
认真做事只能把事做对用心做事才能把事情做好就是这个道理。
备忘录体现了我们对考察后工作的间接控制保证考察印象能有效传递但备忘录有一个原则客观中立可以回避弱点但不能夸大粉饰。
5.6 用户现场考察应如何组织(中) (连载四十)
5.6.1 第三是考察顾问层面
一般情况下客户考察应安排一个顾问型人员在考察期间全程陪同因为用户在考察期间是最容易进入实际环境感受容易看到别人实施过程思索自己项目规划的时机如果能得到高水平咨询顾问交流和指点的机会会给软件公司增加很多印象分。实际上考察走马观花能看到什么有的企业比较有经验能深入了解一些情况大部分企业考察看不出太深的内容只能说在考察过程中谁能在短短几个小时内了解到客户的担心和疑惑并合理通过考察行程展现出来
此外很多典型用户自己用得不错但缺少系统的总结介绍时没有层次而且他们一般也不太清楚参考企业到底关注侧重点是什么介绍时容易突出自己的特色但没有考虑参观企业到底想看到什么这个时候顾问就要巧妙利用自己丰富实施经验和判断力以及和典型用户良好人际关系引导介绍交流思路让参观用户看到东西学到东西。
无论能否成功合作潜在用户花费成本考察我们就应该尽力让他们了解项目实施效益和风险以后他们在信息化建设过程中可以少走一些弯路。
所以一个好的考察顾问往往是整个用户考察的真正灵魂有没有一个这样的高水平顾问对整个考察效果质量是两个档次明白这一点客户经理也应该清楚要让自己的考察达到效果有没有这样的一个人是非常重要的一定要尽量协调好时间让考察顾问有充分时间陪同如果公司没有这样的人员考察过程就只能听天由命让典型用户自己发挥。
但这样的考察最大的可能问题是很多项目业务和潜在用户实际不一样潜在用户总觉得和自己类型不相似总是想看到一个和自己一样的企业而且成功实施这样就比较放心。
且不论用户这样的认识是否正确但的确一个软件供应商也很难让若干典型客户代表所有的企业业务情况。如果一个软件商有如此足够实力拥有全面可考察的典型用户自然最好但实际上这是理想情况而且很多用户行程安排又决定他们没有足够时间去考察其它类型用户所以很多用户考察完后总有顾虑觉得自己想看到内容没有看到这个问题如果有经验丰富顾问弥补介绍是一个补救的办法。
当然作为公司尽量在各个地区培养不同类型的用户是非常重要的工作。
5.6.1.1 考察顾问应该注意的三个环节
考察顾问和客户在一起一般要完成三陪工作第一是陪交流第二是陪考察第三是陪吃饭。
客户在去考察典型用户之前一般会先安排和公司顾问做一个交流那么这个时候顾问要充分介绍自己产品特点回答用户关心的问题了解用户关注问题快速判断是否可以在要考察的典型用户里看到和说明如果看得到自然最好如果看不到就要考虑相应说辞从而能够很好地在考察时候让用户得到一个满意的回复。
这个时候顾问要低调亲切沟通给客户建立一种专业沉稳的可信赖印象在现场考察的时候才容易发挥出彩。
顾问和用户交流往往存在几个难题第一是原来不认识比较陌生如何快速让客户进入状态第二是顾问对企业往往也比较陌生如何快速了解企业情况进而合理提供建议。对于顾问应在用户来之前做一些案头工作查看售前相关资料和上网了解企业产品是很好的办法。
能否快速让客户进入状态一是顾问应有一定商务知识善于制造沟通气氛最重要的是顾问能很快让用户觉得自己比较专业进而有沟通的兴趣。
要做到这点一般顾问应该也是一个实施经验很丰富的人员否则顾问只是名义上的顾问而已。
一个有丰富经验的顾问在陪同考察和吃饭时才能有效说服用户建立信任。而且一个有丰富经验的顾问不仅仅是业务经验丰富还应该有一些杂的知识面例如在行车路上顾问就是一个导游讲环境讲发展讲文化让用户可以先轻松一下也建立一个好的气氛。
5.6.1.2 现场考察三原则
尽量让用户自己介绍顾问只在关键时候点题或者在局面不利时候出马不要喧宾夺主
介绍情况不可任意夸大实事求是不要怕客户看到不好的方面应该真诚和客户户探讨如何才能实施好项目取得用户的信任。甚至在客户来到现场之前多铺垫一些低调的话。
只介绍功能不介绍实施。有的用户对技术非常感兴趣对实施难度不够重视这样的用户要在技术上让其放心后合理感觉到实施方面的难度进而认同找到一家好的供应商合作才能成功的道理。
5.7 用户现场考察应如何组织(下)(连载四十一)
5.7.1.1 现场考察介绍技巧
用户用得不好看功能。不好就是不好可以不主动谈但可以通过功能介绍说明软件应有的能力。
用户用得好看应用看每天有多少人建立多少数据事实比任何数据都有说服力。
介绍软件功能要用讲效益的方式去讲用比较精练的话去引发用户的兴趣。
例如我介绍一个用户用KMCAPP编制工艺的好处用了一句话在这个企业80%工艺数据不是手填的。很多用户就很感兴趣这样我就有充分时间展开如何合理规划工艺数据建库查表自动计算广播等等通过实地演示让用户感受到信息化的好处。
讲实施过程要用讲故事的方式去讲例如我介绍一个用户实施过程用了四上四下说同志搞革命三上三下本人做这个项目四上四下通过介绍四上四下说明项目一把手作用如何体现项目团队应该有怎样品质人组成一个项目成功最重要的要素是什么这样用户在听故事的同时就不知不觉接受了你的理念。
讲故事还要追求轻松幽默。例如我和客户讲企业实施磨合痛苦的过程就用了一个方轮的故事。
有一个用户给我讲原来没有用电脑好象每天走路上班感觉也很好后来上了电脑就象骑自行车每天轻松了许多现在单位上了这个先进的ERP/PDM高兴得不得了因为开上汽车了车型款式还特别漂亮一看仪表系统就知道是进口货各种驾驶信息一目了然原来自行车是没法比但一摸方向盘一踩油门就是无法启动下车一看天啊咱们这车轮子是方的
这样客户就很轻松在笑声中明白就跟两口子新婚一样所谓实施关键在磨合。所以搞信息化一定要做好长期磨合的心理准备没有这个准备离婚率一定会大大上升。
再如我讲实施上线的难度就提了一个走不完的20米说我们企业系统管理员在项目上线最繁忙的时候每天从办公室走到厕所这20米是无法走完的每次还没有到厕所就被两边部门人员喊进去解决问题只能等别人下班吃饭赶紧冲到厕所去解决问题这样的故事在笑声中就把很多不好说也不容易说清楚的事情和意思表达出来了。
但是讲实施风险的话题要慎重体现难度大的事情也可能打消用户实施积极性要慎重讲到了气氛再讲。
讲故事还要将一些具体实施思路和做法体现出来让用户对我们经验和专业水平表示认可。有的用户对信息化软件基础数据录入不够重视也不清楚如何推广软件这个时候我就会讲一个三毛钱的故事。
我讲我们开始软件安装到位大家都不愿意用说是软件不能用结果企业就下令3毛钱一条数据结果就有人开始录还真得到了钱。这个时候我往往开玩笑说我们当时开发人员要求去现场实施协助录入数据以我们水平一天录入1000条数据很容易这可就是300元的收入了
大家一看有钱拿就纷纷录入数据这个时候领导就把政策停了大家刚想责问领导说原来各位说产品不能用所以不能录入数据现在发现你们都可以录入数据了总不是各位给钱就配合信息化工作不给钱就不配合信息化工作吧
这样在大家都掌握基本操作后进行一次考试考试过90分的企业每人奖励500过80分奖励300这下子大家积极性都调动起来了一个月后领导宣布进行第二次考试这次80分以上都奖300并宣布两个月还要进行考试不及格要处分。果然两个月后再考试90分以上奖300不及格罚200。
通过三次考试就达到了拔尖鼓劲鞭策的目的而且将软件操作和应用一层层扩散出去最终形成大面积使用的不可逆转的趋势。
很多人听了这个故事对项目管理目标驱动激励效应就有了更深的认识自然也对顾问对顾问所在公司多了一份信任。
5.7.1.2 饭桌上再烧一把火
一个好的顾问在陪同考察完毕一定记得如果安排一同就餐在饭桌上还得根据客户情况继续烧一把火。
不过既然到了吃饭时间工作就不应该是主题这个时候比较好的方式是可以从介绍公司文化逸事或者发展思路方式尝试用更高的思维层次和客户沟通不要再纠缠过多在技术细节上这样客户可以比较轻松边吃边聊将一些感兴趣问题又提出来和我们交流进而继续获得影响客户的机会。
记住客户前来考察是最脱离自己企业环境可独立思考的时间也是最容易接受别人的时间整个考察工作如果精心准备和规划自然能给客户留下深刻的印象对项目成功起到关键的作用。
6.1 前言(连载四十二)
入行五年经常碰到需要和各种人等介绍公司的情况特别是在公司总部接待重要贵宾考察积累了一些经验今天把我个人做公司介绍的体会做一总结希望对所有需要介绍公司人员提供一点帮助和指导。
6.2 哪些情况下需要公司介绍
公司介绍是用比较短时间内让客户对公司业务能力有一定了解甚至是深刻印象为今后合作开一个好头。
一般公司介绍有这么几种类型
第一是正式陈述在重大招投标答辩场合产品演示场合一些公开会议上这个需要很正式地介绍公司基本情况和实力。
第二是口头介绍在商务和实施工作中碰到一些人关注或者不了解在没有特意安排的情况下进行口头介绍。
第三是会面介绍一般是和客户约定会面时间在会面的机会介绍自己的公司和产品。
第四是参观介绍客户或客户到总部来参观在参观过程中介绍公司文化和发展等各方面情况。
不同情况下介绍公司的要求是不一样的所以下面我分开介绍。
6.3 正式陈述时常见错误
6.3.1 反复介绍原来介绍过的内容
正式介绍是一个很正规和重要的场合而且是在双方进行各种接触到了一定程度的时候才有机会进行的工作因此可能有很多人对软件公司已经有很多了解因而来听陈述的重点内容不是软件公司基本情况而是软件功能或者项目实际情况。但对一部分人可能对软件公司不太了解因此在正式介绍时根据已经介绍过的内容确定取舍不要反复讲以前很多次介绍过的内容而是要突出公司竞争优势点其它内容在没有明确要求的情况下尽量一带而过不要挤占重点内容介绍时间。
我个人经验介绍内容一定要结合客户关心部分强调几个点一般就是三点公司优势例如可以介绍的内容一般是规模地位实力客户数行业经验规范性服务能力研发能力完整的解决方案自主版权公司发展速度最新情况通报等等内容但不要面面俱到效果反而不好要选择最能打动人的关键点组织。
把力量集中反而印象深刻。
6.3.2 介绍速度过快
正式介绍一般有时间限制公司介绍又必须首先进行有的人很想在正式介绍时把公司情况尽量完整进行说明又担心用时不够为了解决此问题就用比较快的节奏介绍公司。
但参与正式介绍场合的人往往也是有一定级别的人习惯用一种比较舒缓平稳节奏听取汇报而且用很快的语速开始会给人留下紧张不够大气的印象进而对公司印象也不佳而且短时间内的灌输也不见得有效果。
所以宁可裁剪内容也不要介绍公司内容时过快。
6.3.3 一些细节用时过多
有的人在介绍公司时觉得有一些很重要的内容例如公司历年获奖情况一张张把证书慢慢放给客户看如果不是客户要求的话这样的介绍方式并不好。
站在客户的角度这是一种包装手段不是实质性内容这些内容介绍多了容易给人不实在印象。
此外大家可能都有一个经验看电影的时候片头时间越长越烦最终让我们记住电影名字的还是电影本身内容。
在做公司介绍时没有重点把一些自认为重要的细节讲得过多都是对客户时间的浪费。
6.3.4 资料无更新
我经常看到很多人不注意和公司相关部门沟通总是用自己习惯的PPT或者材料去介绍公司到了2005年了公司材料上的成就和案例还是停在2003年这样给用户的感觉是不是这两年你们公司没有什么发展了
所以一定要注意资料更新而且资料一定要保证所有公开资料的一致性特别是介绍内容和公司宣传资料一致性。
为了弥补资料不够及时的问题在介绍时可采用一个技巧可以用通报方式补充说明例如可以在介绍时非常自豪的讲“下面我向大家通报一个好消息我们刚刚在***”简短说明意思即可。
6.3.5 介绍定位过于自恋
很多公司自我介绍一个典型感觉不象是写给客户的倒象是写给公司老总的自我陶醉的文字。
公司介绍材料充满自我炫耀自我膨胀自我肯定就是没有站在公司能为客户提供什么产品和服务内容的角度去组织材料。
好的介绍是告诉客户我能为你做什么不是因为我有多么好快来选择我吧同样的内容用不同的方式组织介绍效果也自然不一样。
6.3.6 没有激情
特别是对于经常正式介绍公司的人还有一种情况可能因为讲的次数过多对重复的内容没有感觉缺少激情。
一个人介绍公司时没有自信没有一种在此从业引以为荣的自豪又如何让客户从你个人身上感觉到你所在公司的成就
从容自信充满感情介绍公司是一个职业人必须能调整自己情绪做到的一点基本素质。
6.3.7 采用危险的表达
有的商务人员对一些内容不太清楚在介绍时犯一些常识性错误例如把CMM说成是通过三级认证ISO存在认证CMM没有认证只有评估对内行这是错误说法。
例如过于强调我们人员多有360多人可能现在正式提供给公司手册上人员已经是260人了
又例如习惯性强调我们的EAIP平台和电子政务等内容其实这些部门或业务已经整合调整不再进行了。
这些介绍硬伤是一种危险表达会让用户觉得我们不真诚或不专业。
另外就是为了获得竞争优势采用一些危险的提法例如强调我们国内第一我们实施成功率最高我们最有行业经验我们可以现场开发等等说法。谁能证明你是第一或是最优秀呢
在用户没有实际了解之前不过是虚夸用户实际了解后可能更认为你言过其实更加不信任你。
我们有个项目例如强调我们某个产品发展历史很悠久但实际上发展时间只有三年版本升级很快结果客户私下打电话了解相关用户有的用户告诉他用的版本很老一直没有升级有的用户告诉他用的是新版本刚发行但不稳定很快客户决定放弃我们这家公司。
没有诚信不会长久。
6.3.8 没有专人管理正式材料
有的商务人员说我也不想有介绍硬伤我也想知道公司的最新进展但哪里去找呢
因此随时更新公司介绍材料提供标准说法并下发应该有专门人员负责和维护否则很容易在细节上吃亏出问题。
6.3.9 着装随意不统一
参加正式介绍人员着装正式统一应该是个很基本要求也是对客户的尊重。
一旦一个人要介绍公司就一定要注意不可在随意和过于放松情况下介绍自己的公司因为过于放松状态下介绍公司难免给人一种对公司不太认同的印象既然谈到公司无论在什么时候都不是私事就应该打起精神开始。
6.3.10 随时练习
有人以为自己介绍公司很多次经验一定很好就不注意准备但在现场就发现要么容易冲口而出要么罗里罗嗦讲个没完又抓不住重点。
练习练习不断改进这才是真理。
6.4 口头和会面介绍时常见技巧(连载四十三)
口头和会面介绍一般都是在一种相对非正式场合进行例如办公室面对面进行一些汇报时寒暄内容之一。
这个时候介绍公司内容和正式介绍类似但要注意时间不要太长一般三分钟内为佳用户有兴趣再展开。
但这个时候交流往往有很多意外情况所以我觉得自己事先一定要有准备几个版本的说法应付不同情况同时保持自己的不卑不亢。
6.4.1 不知道型
例如有的时候你一讲我是**公司某某某的时候客户来一句“**公司没有听说过干什么的”。
没听说型的客户是很正常的这个时候可以说“*工请允许我用三分钟简单给您介绍一下具体内容略”。
6.4.2 反感型
比不知道的情况更糟糕的时候客户会说“听说你们在某某项目上很不成功是不是这么回事”
面对这种用户的挑战千万不要急于否认只会增加反感也不要紧张失败的案例大家都有不要因为拿出一个不成功的例子就觉得没有希望。
我们可以先承认后化解“看来*工了解过一些我们的情况的确我们有一些项目没有做到位在很多行业其它地区我们还是有很多成功的合作例如在某某如果您不反对的话我想介绍一下我们公司最近的一些情况。”
6.4.3 我知道型
有的用户一听我们公司名号就说你们不就是那个做CAD的吗这个时候我们就要顺藤摸瓜夸奖客户“看来先生对我们公司很有一些了解不如我给您介绍一点最新情况”也可以用化解误解方式进行“看来先生对我们公司很有一些了解其实我们不但CAD做得有很大影响这几年我们发展得还不错在CAPP/PDM领域我们也是国内最好的供应商之一所以今天希望有机会给您详细介绍一下”。
6.4.4 领导型
有的用户很忙也很紧张根本没有时间听你讲太多东西我们可以开门见山“我们是国内最有经验的CAD/CAPP/PDM供应商听说您的企业有****问题我们正好有这方面的经验所以过来和您一起沟通一下看看有什么我们可以帮上忙的地方”不过这样举问题有一定风险所以可能的话应有所调研了解。
6.5 在客户处进行公司介绍三个要点
无论是正式陈述还是口头介绍公司有三点一定要讲到
业务讲到我们能为您提供什么做什么如何合作。
实力谈到和我们合作为什么可以放心。
案例说到我们不是在说大话有很多用户和我们一起取得了成功并有案可查。
这三点没有说到就不是一个完整清晰的公司介绍换句话说无论介绍时间长短和场合都可以介绍完成这三点内容就是好的公司介绍。
建议公司介绍思路组织可以用以下顺序组织
1)公司业务面—2)产品体系—3)组织架构和服务体系—4)合作建议—5)成功案例—6)发展历程和荣誉
对于公司业务面介绍可以设计一些具体问题引发兴趣
对产品体系介绍要突出重点强调完整解决方案可以用案例说明我们在具体项目上给用户成功的解决方案包括自己的产品也包括和别人产品的集成
组织结构用图说话强调研发体系和服务体系的规范管理可以列举一些数字例如我们软件测试人员和开发人员比例关系我们某些产品自动化测试覆盖率我们每年一个工程师服务工作日等等。
合作建议关键是要有针对性不要泛泛而谈让客户感觉客户经理只是在讲套话。
成功案例一突出用户多二突出合作双赢效益三突出我们和用户长期合作共同发展的服务思路。
发展历程介绍要快速精练给人感觉蓬勃向上富有朝气对于公司历史荣誉重点显示最新荣誉其它一带而过可邀请客户访问公司网站了解公司最新动态和文化。
6.6 如何对在公司考察客户做介绍(连载四十四)
对来公司参观考察型客户介绍公司是有技巧的一般这样的客户对公司基本情况都有所了解而且都是公事公办的正规介绍来到公司很多人又不清楚客户的来路别的不敢讲只好把公司情况又热情介绍一遍甚至接待人主管领导轮番轰炸客户碍于情面心理上其实已经反感了。
其实客户到总部来了反而要少谈公司少介绍产品(一般技术问题还有专门交流时间)多看特色。一般客户对软件公司是很好奇的又不生产物质产品很难和其产品线比较因此没有什么考察经验可以参照。要通过介绍让用户留下深刻印象并不容易。
我个人经验这个时候介绍公司有三讲
第一是讲故事我们这个时候不要呆板的介绍公司而是要讲故事例如我们谈公司人数可以请用户看老照片结合老照片讲公司创业艰辛到发展壮大历程边讲边和客户互动看着老照片听着开目人创业的故事客户就容易从心理上喜欢这个朴实认真的公司了而不是简单被一个漂亮装潢的大楼打动。
第二是讲特色特色主要指公司管理上特点一般管理上特色是结合组织机构介绍进行的要给用户生动介绍我们的组织机构我们可以和企业类比的方法一般我讲研发部就和用户说这是我们的生产车间请他们看源代码管理工具看安全保密条例到测试组就和用户说这是我们的质检车间请他们看软件自动测试工具这些是客户很少见到但见到后有很容易认可软件公司规范可靠的细节而且有新鲜感。
第三是讲文化我们给客户在公司做介绍不仅仅要介绍公司经历和管理特色还要通过这些内容突出我们公司积极向上勤恳努力的文化。
在发展上获得用户认可在管理上获得用户赞赏在文化上和客户形成共鸣这就是在总部进行公司介绍的目的。
6.7 做好总部公司介绍的三个诀窍
根据公司的发展历程和组织布局设计标准套路的介绍词保证每次介绍质量。
精心设计介绍流程和路线让用户在每个部门都可以看到他们关注的内容例如在实施部看项目管理体系在研发部看规范代码控制过程在质控部看软件质量保障体系在营销部看公司获奖荣誉。
找一个熟悉公司的人员专门接待熟能生巧并定期请其汇报介绍工作改进意见。
6.8 公司总部接待考察客户要注意的细节
准备热情的欢迎牌注意欢迎牌一定不要把几个客户单位并在一起宁可多写几张纸
如果总部不能抽烟提前告诉用户请求理解
一定尽量安排高管接待以表重视高管如果忙可以事先说明接待时间短一点
和客户交流时准备精美的宣传资料记录交流问题的纸和笔
请客户参观我们的获奖陈列室
安排一次体现当地特色的餐饮
如果时间充足安排到旅游点参观
临走记得送用户一些土特产礼品
全程安排好用车计划不要出现用户长时间等车的情况
整体接待不要过于殷勤要在用户关心考察内容上下工夫接待工作原则是得体大方亲切不犯低级错误。
7.1 培训工作在项目实施中作用(上)(连载四十五)
7.1.1 培训工作的目的
在IT管理软件实施项目中培训是贯穿整个项目过程中从一开始介入项目就有培训在业务调研阶段我们可能要答复用户一些概念性问题在现场验证推广阶段可能我们要花费大量时间传授软件功能在辅导上线阶段更是要随时解答用户疑难问题。
好的培训可以让用户熟练掌握实施方法自主推动项目增强对项目认同感可以大大减少软件公司现场服务难度和时间效益十分显著。
作为一个IT项目经理一个很现实的问题就是很难一个人在一段时间内只负责有限个项目越是商务能力强单子越多的公司这个问题越突出。
很多IT项目经理或实施人员不得不周旋于多个用户忙得焦头烂额疲于奔命用户并不领情因为用户觉得你对他不够重视服务质量并不高。
一个很有意思的情况就是很多用户强烈要求我们要保证项目的人力投入要求派实施人员长驻现场我们很多实施人员也的确长期在用户现场蹲点但事实上这样效果好象也不明显很多项目推进依然并不顺利。
要是一个人同时负责两个在进行项目蹲点必然是治一经损一经。往往因为不能经常性服务一个项目导致一些小问题会积累成大问题最后即使去现场推动成本也很高。
一个项目经理或实施人员应该强迫自己考虑这么一个问题一个人到底可不可以同时负责3~6个项目到底有没有办法做到这一点
如果一个人负责多个项目思路可行而且服务质量还能被认可大概在目前业内你才有可能获得相对理想的收入否则实施生涯就是一场痛苦混乱的经历。
有的人说当然可以你给我配置36个人我就可以同时负责36个项目。
没错这个思路实质上是说如果你在一个项目中有替代者通过替代者帮你行使一些相对容易的工作你就可以集中精力多做一些复杂的工作。这几乎是唯一的办法至于形成一个团队三个盖子五个杯通过调度让每个杯子都能盖一会只是一种补救管理调度手段。
这种调度能力会随着盖子和杯子绝对数量增加而变得脆弱不堪。而且一个项目人员如果经过不具备稳定性信息沟通失灵信息不对称现象将非常突出。
如果软件公司不能给你配置或调度替代者的话怎么办
答案就只有一个出路在企业培养替代者。
如果我们充分重视用户培训工作让用户也成为可以独立实施我们软件的人不也就一样达到了配置人员进行实施的目的这样就象我仅仅只需要给我的替代者一定时间指导前期可能现场多一些后期可能电话多一些有了替代者同样可以达到管理项目的目的。
所以我个人经验就是在项目中培训工作的根本目的是让用户在很短时间内可以自己独立实施项目而不是仅仅会用某些操作。
如果仅仅是会用某些操作当项目遇到大量困难的时候用户还是会找软件公司希望通过软件公司的手推动很多事情但是别忘了当企业自己本身没有或者找不到推动一件事情的动力的话很难想象软件公司有多大的作用。
不过有意思的就是很多用户高管非常赞同我的想法培训的目的就是让企业可以自己推动信息化工作不能总是依赖软件公司某个人或软件公司。
一个实施人员和用户系统管理员的差别到底是什么
我们强在软件技术全面而用户系统管理员只需要知道和他们相关内容部分维护即可
我们强在靠体系化方法推进项目而用户系统管理员更善于利用企业实际潜规则推进项目
我们强在一些思路理念比较清晰但用户系统管理员更了解企业实际情况和业务特点。
所以如果我们能把我们的技术、方法、理念传递给用户核心成员或者是系统管理员的话我们就可以在企业培养一个有效的替代者这个替代者如果有足够动力被激发能发挥作用和能量可能比我们自己都要大。
让用户控制项目我们提供软件工具和智力帮助这将是现阶段中国IT服务的有效生存之路如果服务可以收费用户且愿意外包才可以主动替代用户实施推进项目。
实施人员对培训目的要有一个清楚的认识帮别人就是帮自己。
要想少出差就得让用户在现场能独立工作。
实施工程师最好的选择就是让用户可以自己实施常规功能而且要灌输一个重要理念软件公司的工作只是保障项目所运行业务需要的产品功能完整可用而不是帮助企业利用软件做业务录入数据那是企业自己的事情而且只有企业自己也可以独立实施维护软件了软件的实施才是真正成功和有保障。
7.2 培训工作在项目实施中作用(中)(连载四十六)
7.2.1 用户能不能培养成替代者
有的人说用户怎么可能在很短时间内就具有独立实施项目的能力
第一用户不象我们有专门时间学习和培训第二用户不象我们有足够动力和压力。
我自己个人在项目实施中体会是不要低估用户的智力和毅力的确不是所有项目用户都具有被培养的潜力但在很多项目中从来就不缺乏能够培养成为一个好的实施者的用户而且这样的人只要一个就足够了只是我们自己并没有花时间去找到一个大家认可这样的一个人而已。
用户虽然没有太多时间学习培训但衡量我们培训工作的质量标准就是看培训有没有做到在很短时间内将一个人快速培养成材可独挡一面。
我们很多培训并没有达到这个目的那说明我们还需要在培训工作上想办法动脑筋而不是简单将事情归结为复杂只会说一件事情复杂的人不如说自己无能更妥当一些。
更何况在单个项目上用户对很多操作可以不必知道学习工作量并不象完整培训一个实施人员那么大。
第二用户也有业务上压力项目上压力也有自我突破学习新技术的动力未必不愿意配合我们工作何况我们只是找一些核心的用户有心的用户进行高强度培训不是要求所有的人都有同等能力。
我们再看一看一个软件公司新进人员在多长时间内必须独立去现场工作最多三个月。短短三个月为什么他就可以去现场工作呢就是因为培训。
另外再想一个问题这三个月他一直在接受培训吗显然不是好象只是简单培训了一段时间可以入门了然后就通过查阅资料和请教方式去自我成长。
其实学习软件很少有靠人手把手教出来的基本上高手都是摸出来的。而且在摸的过程中往往是在一段时间内高密度的研究一个软件直到明白。以后即使这个软件功能上有什么扩展和发展学习成本将非常低。
在最短的时间内做最大量的事情这就是成功将用户培养成替代者的秘诀。
成功的培训周期一定不长一定是在最短时间内不断反复强化某些业务环节操作形成习惯。
不要指望用户自己会自动自发地在一段时间后掌握操作而是在一段时间内大量练习强化掌握后再逐步琢磨如何应用逐步熟练后达到一个很高的境界。
很多用户并不缺乏IT知识只是不太清楚具体软件操作和对框架的理解由于熟悉业务对软件和业务工作结合点价值点的认识和理解可能比我们自己还要强。
对这样的用户换句话说我们已经弄懂的东西传授给用户恐怕并不需要三个月。我们一个项目实施周期短的话也要半年长的话要两三年这么长的一个周期内居然一个实施人员安排不出来时间给用户培训而且培训到可以达到独立实施的能力。
这种现场自我反省更多的是我们在工作意识上工作方法甚至我们自己对软件理解操作熟练程度上有欠缺所以导致我们软件能力无法传递给用户也得不到认可。
就我本人实施工作实际体会无论是国营企业还是民营企业无论是大企业还是小企业绝大部分都可以培养用户实施者。的确有的企业做这件事情难度大些成本高些。
但无论怎么样我们有无极强烈意识在企业建立一个项目团队让项目团队得到资源保障让项目团队关键人员推动项目实施一旦发现项目中这种情况和局面不存在就想千方百计去做到这一点
这就是我们能否培养替代者的关键意识。你认为可以可行你就会去做。
7.3 培训工作在项目实施中作用(下)(连载四十七)
7.3.1 培训工作为什么质量不高
坦率的说我们现在整个行业培训工作质量是不高的至少是参丝不齐的。我个人认为主要原因有四
第一缺少高质量的按业务组织的培训教材。
很多软件公司特别是管理软件公司并没有一套完整的结合业务的培训教程更多的是功能手册和配置手册这样的内容很难理解更不能传授能力。
很多对软件有兴趣的人并不需要太多时间指导但一定要给他很容易上手的教程。所以国内很多人都可以自学复杂的CAD软件或三维设计软件坦率的说这些软件操作比任何一个管理系统还要复杂但很多人就是可以自学和教材丰富有关。
第二培训者的能力缺少验证。
我们很多软件实施工程师强在技术能力弱在业务理解力和表达能力到对得上一句俗语茶壶煮饺子有货倒不出。对于技术型人员主动培训用户在心理上也是一种挑战。
可能有的人是心里明白就是说不清楚让人看着着急。
心里明白表达能力不足还好更糟糕的是很多人心里也不明白或者是半瓶醋在那里装明白典型的小黑蒙大黑最后用户说天下乌鸦一般黑。
在标准业务教程没有到位的情况下要对培训者培训工作进行主动考核和管理才能保证培训质量。
其实办法很简单学校招老师是如何进行的试讲如果你还没有准备好手册并不等于不可以传授知识那么就请你讲内部公开课没有达到清晰明白讲清楚软件功能和业务的人员首先自己加强培训。
第三不重视培训工作。
很多实施人员总觉得培训很多细节给用户很麻烦我把所有配置都调整到位系统到了一个可用的状态然后你要掌握的操作就是那么几步我把这些都教给你不就完了然后我再提供一个业务手册你参考看看不就行了干吗要花费大量时间和精力在现场培训又不是没有事情做
甚至有的人可能还在想软件还有问题我精力应该放在解决问题上而不是培训。
结果无论人在现场不在现场大量时间都是一个人在忙碌的配置调试然后请用户检查验证。然后好早点走人去下一个现场解决问题。
欲速而不达这样的项目越是到了大规模推广时实施人员越头痛根本不能走开一走开就出问题大量的出问题别的项目要是同时推广实施人员的行程几乎就是难以兼顾自己就不要做任何休息了。
是否重视软件培训千方百计想办法让用户会用好用爱用软件是一个好的实施人员的价值。
第四忽视软能力培训。
很多软件培训工作特别是管理软件培训工作不仅要培训功能还要传授实施方法。
要告诉用户遇到问题如何分析是需求还是缺陷分别如何处理
要告诉用户如何判断实施阻力软件实施到哪一步可能会有什么困难如何化解
要告诉用户你应该如何培训其它的同事如何将能力传递扩大
如何界定一个项目边界和近期目标并逐步实现所有实施人员都应具备的软能力这都是要传授给用户的这样用户才可以真正起到一个管理控制者的作用这样的用户才能独挡一面也会通过项目实施得到在企业内部的肯定和认可也就有实施的动力。
7.4 培训工作应如何组织(连载四十八)
要准备一次成功的培训要考虑一下几个工作首先是培训内容策划然后培训计划编制和确认然后是具体培训组织工作最后是培训考核和反馈。
7.4.1 培训内容策划
培训前要根据不同培训对象不同培训内容不同培训阶段不同培训师资进行内容策划。
要针对用户层次实施阶段设计培训主要内容。
想好每个阶段目标用户应掌握的内容作为自己实施目标中一部分并通过相关培训活动达到。
一般培训内容可分为
业务调研培训重点在告诉用户我们工作方法和相互沟通配合方式
解决方案培训重点在告诉用户我们软件业务模型和整体实现思路
功能验证培训重点让项目组或系统管理员掌握软件基本操作进行功能验证
辅导上线培训重点在让一般用户掌握相关部分业务操作让系统管理员可以掌握常见配置和维护工作。
培训策划还包括选择培训对象不是企业每个用户你都要培训的而是选择一个或几个重点用户培训确定其掌握基本能力然后辅导重点用户培训别的用户逐步扩大影响。
如果企业比较大还需要策划分几批培训分别培训什么内容。
培训策划还包括如果将培训工作成果汇报给企业并形成共识。
而且一旦有重点用户可以在实施人员辅导下独立培养别的用户操作了或者进行了大面积普及操作培训并达到目的要立即给企业领导汇报除了汇报成绩确定项目进入一个新的里程碑外汇报一方面要求企业主管领导表扬这样的用户保护其积极性一方面也要企业领导知道我们是真的来做好项目所以我们不但提供软件还在真正为企业培养自己的信息化实施人才别忘了这是很多项目招标时的要求。
这里面通过汇报也对企业领导进行了培训灌输了我们是工具我们是智力支援者不是实施主体的理念如果软件有问题我们来解决如果软件没有问题企业要自己用软件功能在我们指导下主动解决问题。
而且让领导知道了如果遇到问题可以请企业自己中谁负责解决实际上也帮重点用户提高了在领导面前的曝光率肯定有好处。
培训策划还要考虑培训的地点和成本包括人力成本和时间成本一定要合理安排高效紧凑。
7.4.2 培训计划
培训策划的阶段成果是培训计划培训前要将培训计划制定好并通知到最终参加培训的用户这是很重要的工作。
培训计划应该先在内部经过大家确认落实资源后才能提交用户。
一份完整的培训计划要确定培训目标详细分解培训时间、培训内容、培训师资说明培训地点、签到方式和考核方式让用户提前做到心中有数方便准备。
7.4.3 培训组织
培训计划编制前要和相关培训资源进行沟通确认是否可按时间进行培训工作同时要检查培训场地是否足够是否有足够资源上机练习是否有其它必要设备等这一切就位后还要和用户确认最终培训人数时间安排和其它相关可能工作。
如果用户是到软件公司培训还要落实用户的餐饮安排住宿安排接送安排参观安排订票安排礼品安排并列计划报公司批准认可后执行这些都是一次成功培训组织中要考虑的工作。
培训组织要特别重视培训环境的质量高质量的培训环境应提前准备好相关软件环境并调试通过不要等用户开始上机才进行安装。
培训组织中最重要的工作是完成培训教材的编制并提交审核或主动安排审核。
审核培训教材的方法有两点一是确认教材思路是否清晰细节是否完整二是看培训者讲解是否易懂和教材一致。其中对讲解能力的验证要更强于教材的验证没有教材一样能做好培训没有好的辅导讲解能力很难做好培训。
基本上很多公司对这个工作是忽视的也是没有人负责的这是一个很大的问题这种事情验证成本并不高因为可以采用认证资格的方式进行一个好的培训人员对其培训能力的验证在一段时间内只需要验证一次就行而这个能力至少可以在一年内发挥巨大的作用。
本人亲自检查过很多对软件的讲解说个不中听的话这样的培训能让用户明白我们是干什么的都难别说让他跟着你走按共同的意图推进项目。
此外培训教材中数据录入规范也是培训重点内容这个讲解倒不难实施人员要结合企业实际精心准备是关键。
数据录入规范准备要点有三条
1、 习惯填写方式说明及样例
2、 正确填写约定及样例
3、 常见问题处理方法
7.4.4 培训考核和反馈
培训效果如何要从两个方面去验证一是对用户掌握程度的了解这就要通过培训考核去完成。
一方面要了解我们培训的质量这就要通过培训学员的反馈来了解。
任何集中完整培训工作都要提前结合企业实际业务准备适当难度培训考题这也是培训审查工作内容之一。
培训成绩原则上要反馈给个人和企业相关组织单位这样才能形成一个反馈激励机制我们可以采用“优秀鼓励落后不提以先进示范带动整体提高”的策略促进培训深入开展。
第二培训完成后要请学员填写培训效果反馈表这样对培训老师形成一个反约束为了让培训学员有一个好的效果反馈就不得不精心准备培训工作而不是敷衍了事。
考虑到实现成本和实际能力及企业情况考核和效果反馈表可能不太容易操作但从长远来看有没有培训考核和反馈的培训工作质量一般是两个档次以上的差距这也是一个客观规律。
培训效果反馈表要提交给培训老师和公司相关培训管理部门由其安排进行培训改进工作。
7.4.5 好的培训行为习惯
随时随地随人随事的培训
培训的工作并非一定要专门的时间专门的地点进行实施人员要利用一切机会用各种易于接受的方式将思路、操作或配置传递给用户并随时从用户处获得反馈改进内容。
在培训中互相学习
培训过程一方面注意传授内容给用户也要抓住一切机会向用户学习业务知识业务知识越多今后培训准备也就越到位培训内容也就越生动。
随时记录培训中发现的问题
培训过程中会经常出现一些用户提出的问题很多都是很好的改进建议要立即记录并反馈给公司对软件进行持续改进。
7.5 培训注意事项(连载四十九)
一定要事先准备好业务手册或者培训教材没有教材的培训工作质量无法保障
培训过程中比较好的讲解思路是
先讲业务后讲思路
先讲思路后讲操作
先讲操作后讲配置
先讲配置后讲维护
培训过程中如果没有投影可以充分利用各种工具软件实现同步教学例如“NETMEETING”工具实现多台电脑同步放映。
上机辅导一定要有人陪同主动答疑。
培训操作要先手把手操作示范一次示范后立即要求用户练习几次确定用户掌握后才能结束一次培训辅导。
在培训中要及时大胆诚恳鼓励用户的每一个进步在培训过程中完成软件思路和管理理念灌输和培训方法的灌输。
传授用户如何记录软件缺陷和分析缺陷的方法让用户可以按照要求提供此类数据减少自己为了一个小问题去现场的概率。
传授用户用各种远程协助工具进行软件辅导的方法让用户适应在线辅导减少出差成本。
7.6 总部培训
7.6.1 为什么要考虑到总部安排培训
有的时候现场培训用户经常受工作干扰无法连贯进行培训活动有的时候用户主动希望到软件公司进行培训总部培训也是培训策划中一个内容是安排到总部培训还是在现场培训是要根据用户重要程度和效益来评估的。
对于一些大型项目特别是用户执行力不够现场培训效果不佳的项目安排一次紧凑合理的总部培训会收到很好的效果。比起在现场反复培训每次培训效果都不到位一次紧张有序的总部培训往往成本更低。
而且在软件公司培训用户换了环境可以协调更多人和用户交流用户此时更容易接受我们的管理思路并达成一致有利于后续工作推进。
在总部培训还可以和商务进行协同搞好接待工作有利于建立个人交情用户也愿意在后续工作中配合我们开展工作了解我们工作流程按照我们制度配合而不是简单埋怨责怪。
所以总部培训是很好的一个培训组织方式。
7.6.2 总部培训经验
很多用户要求到总部培训实施人员或者客户经理只给公司一个通知人就送过来了用户到总部培训至少要做好三个准备工作
和公司培训负责人事先排好计划沟通资源确保到位
和客户经理一起安排好接待工作尽管很多用户我们不负责住宿餐饮游玩但从中国实际情况出发在成本接受范围内适当安排一些招待游玩根据用户报销水平落实好用户宾馆和订票这些细节会极大提高用户对我们认可程度。
确保培训工作有实施项目组成员参加总部培训一个重要目的不是简单让用户掌握操作而是让用户变成项目主体实施者也就是自己人所以无论是现场培训还是总部培训项目组一定要有人和用户泡在一起只要用户还没有走就必须时刻有人辅导和培训。
我们有的项目培训实施人员没有亲自参与或者晚上用户上机练习自己因为远就先回家都是因小失大你如何对待别人将来在项目中用户也是如何对待你。
总部培训结束后一定要做好培训备忘录让用户回去对其公司负责人有个明确交代至少要说明我们的工作质量是没有问题的。
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 没有激发用户的主动性(连载五十二)
一般情况下现场推广很多用户认为主要是靠软件公司来落实的确在很多企业由于体制观念的原因在这些方面需要软件公司多做很多工作。
但实际上一个项目大量依赖软件公司人员推动这个项目失败概率会比较高越是成功的项目用户主动性越强用户才应该是项目实施的主体。用户自己的项目不是用户自己实施却要依赖我们实施这样的项目我们如何成功
我们之所以推广失败往往是我们把自己思路给用户一描述甚至没有什么描述就闷头大干用户不知道如何参与我们工作只好去监督我们成为项目的监工而他们又不清楚系统的思路和实施套路只能按照领导意图来给我们施加压力而不是和软件公司一起分担压力这样进行的项目自然难以受控。所以我们这样做的都是事倍功半的工作。
把用户至少是用户项目组变成可实施的力量并帮助他们推广实施项目而不是依赖个人力量推动实施把他们由项目监工变成项目执行者我们成为监工和顾问这样的实施才轻松有趣。
让用户真正参与项目实施工作虽然用户累一些但大家有了团队的感觉心情反而更愉快说个套话往往在这个阶段和用户建立了战斗的情谊为今后验收回款参观都奠定了牢固的基础。
所以我们在项目推广方案中要反复强调和贯彻这一思路并得到用户认可在实际工作中落实而且用户掌握的技能要清晰写进备忘录这样就可以请他们中具有相关技能的人去解决问题。
例如软件安装我们可以和用户约定我只示范装3台然后安排用户方面的人装3台我们在旁边看如果连续三次都成功我们认为基本上问题不大其它的都可以交给用户处理我们只需要处理意外问题。
又例如进行某个业务操作培训我们先要经过讲解示范确定用户项目组明白立即请用户项目组操作确定他们掌握了操作那么后面的培训可以主动邀请用户项目组成员讲解我们提供技术咨询今后培训工作策划组织都可以逐步传授给用户项目成员负责最后一般问题基本不需要我们出马大面积基层用户都习惯和自己人交流解决问题我们只负责解决软件的疑难杂症而且某个业务被大部分人熟练掌握后我们的工作主要就是新的业务流推广方案验证设计规划还有保障项目进度的相关管理活动。
这样一轮轮循环就可以让用户项目组慢慢成为实施的主体而且在这个过程中用户项目组成员可以得到极大能力成长和进步他们也会感谢我们的帮助。
一到现场工作任何时候都要确定这个游戏规则
实施推广以项目组为主我们负责技术支持负责推广实施能力的传帮带
一旦实施能力转移了我们并不需要经常来现场工作因为我们来现场工作成本极高
一般情况下我们只需要在现场解决问题培训技能达成后续工作计划完成本次业务目标就必须返回。
我们不能解决问题的时候我们会全力促成问题解决一旦解决我们第一时间安排现场响应但如果我们解决不及时不顺利我们会第一时间通报也请用户理解支持。
不过坦率的说很多实施工程师本身也不知道如何做这件事情思路也是乱的也不会做计划这样的话去激发用户就缺少个人魅力和行动能力就只好亲力亲为被动响应这个时候为自己能力不足付出代价也是没有办法的事情。
8.2.5 光打雷不下雨缺少高管支持
很多时候仅仅和用户项目组达成一致意见还不够还要和用户高管达成一致。否则在项目遇到阻力的时候得不到更多资源响应。
达成一致的实施方案要给用户高管汇报汇报要点不在软件功能实现和配置细节而在于目标是否认同资源投入计划是否可行可能会有哪些风险采取了哪些措施保障如果出现一些项目阻力需要提前得到领导哪些授权或政策支持。
特别是要向领导汇报取得认同的工作就是将和信息化相关的基础工作(例如数据录入业务执行)变成有制度保证的岗位要求和流程要求这样信息化工作推进才有制度保障。
取得高管支持最有效手段是建立和高管的汇报机制这样才能够让高管清楚知道项目进展和需要给予的支持项目组成员也会因为可以经常得到高管授权和肯定而努力推动项目。
给高管汇报要注意的是每次汇报应该准备一些积极的内容值得肯定的内容的确有进步的内容为好否则仅仅是诉苦汇报是不用指望高管对一个无能的团队给予更多的支持的。
8.2.6 边界总在变更(连载五十三)
有的项目实施过程中用户不断提出一些新的要求希望我们能够给予解决。
这个时候我们有的实施人员顶不住用户的压力被迫承诺答应解决结果就导致项目的边界总在变更项目目标在一次次变更中不断变形偏离游离最终模糊不清项目也就陷入不断开发不断提出新问题的循环之中。
用户提出需求要进行分析一般用户需求有三种情况
第一种的确是软件规划没有合理解决的问题而且无法绕过去或者绕过去对用户项目就没有什么合理的价值了。
这类需求在业务调研阶段就要主动思考和确认在功能内部验证配置业务流时就要发现并向公司反馈强力推动解决不要等到现场推广时让用户去发现然后再去改这样可能浪费了好几个月宝贵的时间。
第二种是软件易用性和稳定性或者性能方面的问题但的确有替代方案或者暂时可以接受。
对于这些需求我们应该给予解决但要和用户解释这些需求必须纳入统一版本规划实现不可能今天提出要求明天就改好这样开发管理快是快但长远可维护性一定很差所以在功能验证阶段要主动和用户项目组提出项目推广过程中哪些功能可能会产生问题需要大家提前做好沟通工作和说辞一旦出现应用者不满意的情况我们还可以想办法提前打预防针心里有数的处理疑问不至于被动响应甚至自己都没有发现用户提出的缺陷或者种种问题。
如果处理得好在一个长周期项目内(例如半年或者一年)如果能够提前识别这些需求纳入规划开发响应那么最终项目验收的时候这些问题也就比较顺利地得到解决。
第三种是用户应用后产生一些新的业务思想希望也通过计算机加以解决这些业务需求可能包含很有预见的需求也可能是灵光一现也可能是将其它系统需求要求我们系统也加以实现。
这类需求对内我们可以反馈给公司相关规划人员去合理讨论但坚决不能给用户任何承诺超出合同边界的需求在一个项目中是绝对不可以轻易响应的否则开个一个口子就无法拒绝用户各种合理不合理但都不在本项目边界内的需求项目也就越做越长无法收场。
这种需求最简单的方法是以合同为准按合同办事。
比较好的处理流程如下
a) 先要详细搞清楚用户业务需求到底是什么核心要解决的问题是什么很多用户表达的问题和要解决的手段往往是分离的我们不要把解决问题的手段和问题混淆在一起另外有时候要解决的问题是因为另一个问题不方便造成的要先分析清楚
b) 和用户项目组沟通协调确定问题的确存在且需要解决且能确定解决的需求
c) 和项目经理沟通判断该问题是否在方案价值点覆盖范围内而且影响主导业务正常运行如果是提交需求建议和缺陷报告给公司规划评审如果不是先要和用户沟通看其是否愿意作为后续合作内容或者另外追加费用解决不和本项目目标混淆在一起
d) 如果用户坚持要开发要及时向公司汇报并坚决执行公司意志。
8.2.7 做人不好
有的项目存在严重人员沟通问题用户对我们不放心宁可把我们关在现场不回来生怕我们走了不再来了。
这种原因就是实施人员没有建立足够诚信往往是一个阶段工作没有做完没有确定到应完成的里程碑点就不得不做其它工作甚至就是不够认真负责敷衍了事。
用户听信实施人员下次来解决问题的承诺回家结果实施人员在多个项目现场奔波中并没有投入精力解决软件问题或者促进公司解决问题下次不得不被迫过来又没有真正解决问题用户并不满意。
有的时候调度周转不灵版本发布推迟用户不能看到我们按计划兑现承诺也会不相信我们的工作采取要求派人现场长期遵点解决的要求。
其实如果问题不能解决遵点是没有用的如果问题能够解决往往是双方沟通协调后在软件公司先解决然后再到现场解决的软件公司资源一般都很紧张将人压在现场几乎让自己问题陷入无人催动的境地。
所以我们一定要做好最坏的打算和用户慎重承诺说到做到有问题全力保障问题及时解决给用户两个印象第一我们很认真守信第二我们时间珍贵我们每次只能解决关键问题实施还是靠用户自己解决。
8.3 现场推广工作如何才能做好(连载五十四)
作好现场推广工作关键在于前期各项工作质量。
8.3.1 第一要组织高质量的业务调研
业务调研阶段在产品比较熟悉的情况下可以边调研边建立原型测试这样在现场调研时对可推广业务设计和验证构思业务流程操作手册数据规范手册和各种样例到了真正推广的时候思路早就经过反复推敲非常可靠
8.3.2 第二要对关键用户组织成功的培训
培训就是让用户自我进行推广我们软件公司协助配合要相信用户的积极性主动性和能力要不断激发他们在这些方面的潜力。
a) 从一开始到现场工作就要反复安排大量精心组织的培训活动让用户理解我们的思路
b) 项目解决方案或思路一定要组织各种类型会议在现场反复讲解达成一致非常关键问题不要回避或模糊化例如产品管理的思路。但一些技术细节可以淡化例如表格格式或者汇总时一些小要求不要纠缠这些细节
c) 培训的时候在操作上应该准备实例化的内容应该让主导用户操作后自我评价掌握程度直到熟悉为止
d) 培训思路站在业务流的高度规划让用户相信你对他们业务理解和描述非常准确到位打消用户顾虑忧。
8.3.3 第三要提前做充分的内部业务验证
内部业务验证一定要自己亲手测试而不是等测试部门结论。
因为我们通过业务验证推导我们业务流程实施思路是否可行的过程这个工作别人是无法取代的。
测试部门只能按照功能验证不能按照业务验证可能有一些业务上操作瓶颈无法覆盖但我们到现场用户一定会发现因此造成用户满意度下降进而要返工开发导致公司管理成本上升。
而且验证过程中我们要发现软件是否有易用性性能和功能上问题要尽快提供给公司相关部门直到寻求到替代解决方案或者列入可接受的版本实现计划中这样才能保证在现场出现任何我们心中有数即使是承诺可实现周期也比较有底不会乱跳水。
此外作为项目经理和实施工程师必须对自己拿到现场实施产品功能了如指掌才能说是在业务上合格不可能想象一个对新功能新版本不熟悉的人去现场指导用户实施这个只能通过内部验证来保证操作熟练程度以及准备新功能培训教材和升级数据等相关指导教材。
在内部验证不是要让产品没有缺陷才能去现场而是通过自己验证充分评估产品对主要业务线的支持程度有多少是可以通过沟通克服的有多少是无法克服的必须解决后才能去现场的有多少是必须解决但可以暂时忍受的。并及时和规划开发沟通达成一致的解决意见才有面对用户的智慧。
最终做到在现场用户发现缺陷之前我们心中有底有对策有替代方案可以承诺用户我们大致解决时间并按时间兑现进而建立用户对我们来现场工作的期待感和信任感而不是抱怨我们拿着有问题的版本来只会引发新的麻烦进而导致项目失控。
8.3.4 第四要做现场验证。
现场验证就是让用户项目组充分评估新版本的好处和不足之处确定是否升级一旦升级出现用户不满就可以事先采取对策克服而不是到处救火
如果验证结论是不能满足要求就千万别到处装机推广那是自寻死路宁可回去改好再来也不能强行压。
现场验证过程也就完成对用户的培训让用户项目组承担起实施责任软件功能是否满足要求是软件商的责任通过验证实施就是用户的责任这个工作要做得好还需要建立和用户项目组充分信任的关系。
所以现场验证要做好推广风险评估提前采取对策此外要找到用户实施推动人协助他们推广项目最后验证通过给领导汇报取得支持召开项目推广启动会这个时候再进行推广工作就很容易了。
8.3.5 选择适当的推广边界
一般情况下推广应用要考虑解决完一个业务环节再往下走把繁复的企业业务化整为零设计为相对完整的几个部分一个部分一个部分实现。
而且每个部分一定要有一个清晰效益牵引或做愿景这样大家才有跟随实施的信心和热情并在一个台阶达到以后再上一个台阶逐步扩大应用范围每个阶段实施难度实际上就降低了。
记住只要某个业务流用起来了往往就可以验收了此时项目推广内容和合同边界未必等同。
8.3.6 建立和用户的个人友情
为了推广顺利实施人员也可以和用户一起吃饭娱乐增进感情也是有效的团队建立策略。
当然建立友情未必就是靠请客吃饭造就的请客吃饭一般不会建立深厚的友情友情是项目中同甘共苦中建立的。
9.1 验收工作应如何组织(连载五十五)
实施项目最快乐的事情就是项目验收可是经常是没完没了的信息化不见不散的项目组验收之路何其漫漫。
我在整个项目经理技巧中都反复强调任何工作达到成效并不在一时一地事情做到位而是在平时工作积累中将事情细节做完善做到位很多想要的结果就自然达到了。
项目验收就是我们最想要达到的结果一旦项目验收对很多人还意味着一件现实的事情就是我们可以回款了可以获得项目提成收入了同样项目验收也是一系列细致工作完成到位的结果而不是某个点的成功或者个人能力就可以促成的事情。一个项目的验收未必是一次性活动而是由一系列验收准备工作组成的在最终验收之前我们已经将很多阶段工作细化并得到认可执行项目验收就是一个水到渠成的事情。
下面我们就一起讨论一下如何进行项目验收。
9.1.1 项目验收的条件
很多人会奇怪这个问题还需要谈吗肯定是按照合同和技术协议验收。
其实在业内目前项目合同和技术协议现状是一个项目不管金额大小个性化开发多少软件功能模块几乎是一个不少用户要求我们承诺的服务内容也是一个不少供应商在竞争压力下的营销过渡承诺很难完全避免杜绝如果要以完成合同和技术协议为标准进行验收业内的大部分项目个人以为达到预期要求的可能非常之少。
当然这和技术协议架构方式有关一般最开始技术协议只谈服务内容和实现目标很笼统结果在实施过程中很容易出现业务需求爆炸的情况软件商难以应付。
这种情况下软件商就开始逐步细化产品功能点按功能点确定软件细节只要功能点满足理论上就应该满足用户业务需要用户就应该验收至于业务能否运行更多的是用户的责任这里面更多的体现了软件商的自我保护。
实际运做时无论技术协议多细致对用户而言根本没有太大的参考价值用户只会考虑其业务是否真的在运做并以此作为检验我们项目是否可以验收的标准当然有的项目可以通过商务运做在业务实现不太好的情况下也能验收。
所以现在一般的模式管理软件项目是按照服务内容分几个业务目标完成一个业务目标就完成一阶段验收收取一部分实施费用。
所以项目验收的最小条件是一个或某几个基本业务面能够开始大面积的应用。
这些基本业务面是不是很简单或者是不是很稳定或者人员是不是一定全部都上线或者业务面上功能是否存在可改进功能都不一定但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以了。
9.1.2 确定里程碑
我们现在知道如果要真做好一个项目完成项目验收条件是以业务是否可用为考量角度。不是一定得实现所有用户的需求也不是只有将一些所谓的技术难点解决用户就可以用起来并验收而是我们可以完成一定的阶段应用业务目标。
所以要想成功验收不是我们什么都承诺什么技术问题都实现项目才能做好而是和用户沟通代表公司和用户就项目业务实施目标达成一致。
因此我们从进行业务调研的时候就要主动控制项目的业务边界将一个一个业务流根据企业实际情况合理组织实施顺序形成我们项目实施计划中的里程碑点明确达到里程碑点的条件并得到双方一致正式认可。
在中国管理软件售前工作和用户还无法建立长期合作关系面对不是很成熟的用户和疯狂的竞争对手我们在生存压力下可以先和用户建立合作关系一旦能合作就相对容易和用户建立信任关系有了信任就可以慢慢教育用户用户一旦理解很多事情的复杂性不是软件单方面可以控制的反而会理性地和我们一起解决问题。
因此我们要相信用户是理性的他一定会坐下来和我们一起谈那到底怎样解决问题呢最终可以达成合理的结果然后我们全力去冲刺每个里程碑。
里程碑的好处第一是将复杂的业务目标分解为一系列简单的目标即降低了难度又使每个阶段实施重点突出精力集中在一点上自然可以更有效解决问题。第二里程碑界定目标包含了一个一个相对独立应用台阶可以促进用户项目一个台阶一个台阶往上走用户只要达到了一个里程碑项目在这个业务实现台阶上就可以进入不可逆转的状态不会走走停停经常从头开始。
在具体项目中这些里程碑内容都可以设计在每个项目中成功设计里程碑的关键就是最小化项目边界然后和用户高管和中层干部甚至在某些项目上还要和基层达成一致。
我们控制边界的前提是我们自己要有可置换的因素这就是用价值换边界。
我们必须在深刻了解用户业务基础上提出我们的业务目标阐明项目价值所在让用户接受业务目标并按照这个业务目标去实施而不是纠缠在有什么功能没有什么功能。
功能很重要但考虑用功能如何支撑业务流程更重要。
所以一个人在项目中最大的力量往往源自对业务深刻而理性的把握。
成功项目验收的核心就是边界的确定。
没有双方高度达成一致的里程碑认可也就是没有项目目标约定没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标导致计划不可控制更谈不上验收。
很多人希望通过详细解决方案来定义项目要实现的内容和业务目标这是很有必要的但解决方案得到认可并非是通过用户审核就可以的结果应该想办法让用户一起参与解决方案思路思考变成用户自己推导出来的业务实施目标未来才不容易变形。
因此我们建议在确定里程碑的时候和不同层面人员大量沟通目标确定达成一致在产品比较成熟的情况下能否就项目边界达成一致是最关键的工作一旦这个目标达成就很容易制定计划执行和落实。
确定每个里程碑后续工作可以参考下面的标准流程。
9.1.3 主动沟通(连载五十六)
一般项目业务目标清晰后就可以按照业务目标分解相应工作逐步落实在落实过程中有一个很重要的工作是很多实施人员会忽视的就是主动沟通。
项目中一定要有沟通策略和高管如何汇报工作进展取得支持和中层如何就业务目标不断确认逐步清晰和基层如何就项目应用操作模式达成一致持续改进都需要通过沟通反馈完成。
沟通的作用对于高管是让他们清楚我们一直按照项目目标前进每个阶段工作进展是否顺利影响项目正常运做原因是什么需要哪些资源帮助。和高管沟通比较多的话第一个好处高管经常听汇报就知道项目进展程度可以安排反馈检查看是否具备象我们所说进展这样一旦认可了各个阶段目标后最终要求高管签字结项也就顺理成章。
第二个会哭的孩子有奶吃一把手工程核心就是高管支持项目运行而做到这一点关键就是通过合理汇报让高管对一个逐步前进的工作进行业绩的承认高管一旦认为某个事情比较容易成功了反而容易追加资源保障完成这就是信息化的“马太效应”。
一个工作高管经常性不知道进展怎么会支持呢当然谁去汇报可以在项目中界定是企业还是我们软件实施商但一定要和高管主动汇报。
给高管汇报技巧就是简洁明了真实客观有理有据分析问题提出对策建议请其决策即可。
中层往往是项目主要的推动力量和实际执行者也往往是对具体业务需求最主要要求者他们对企业实际运做过程最清楚提出要求最具体而且项目验收与否没有中层的同意往往也是不太容易做到的。
要达到项目的目标没有中层的配合也是非常困难的和中层的沟通往往是不断动态调整项目目标逐步清晰化项目目标和细节的过程。
往往通过前期业务调研只能对企业项目目标有一个大的宏观的认识但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中双方项目组要不断沟通特别是企业中层沟通才能逐步认识越来越深刻最终达成一致。
和基层的沟通主要体现对最终用户的关怀定期主动和最终用户沟通消除一些怨气让用户能坚持用下去这个时候我们往往发现很多用户真的是非常可爱尽管软件还有很多值得改进的地方但他们一旦认可我们团队反而会尽心尽力帮助我们推动。
个人以为一般在项目中要坚持每个月到一个半月写一份详尽《情况简报》分别通报企业项目负责人部门负责人项目组成员。
《情况简报》应先发邮件然后一定电话落实收到并口头简要汇报特别是高管层千万不要以为发了就等于别人会去看一定要口头跟进汇报一次保证企业各方面负责人对项目进展做到心中有数。
另外实施工程师无论是否在现场保证每周至少和操作用户、系统管理员沟通一次主动和用户接触不要等到用户有问题再来找我们解决。
这样反而可以逐步释放用户一些火气真要救火的时候我们反而有一些从容周转的时间一回生二回熟到了验收的时候也好说话。
9.1.4 写好备忘录(连载五十七)
在一个漫长项目周期中很多工作做了也就做了认可了也就认可了时间一长也就忘记了很多承诺和约定到了验收的时候就翻出来重新要这种事情很多人可能都经历过明明说得可以先不做的内容最终验收的时候又成了必要条件。
所以在一个项目中要顺利验收一定要写好备忘录把平时项目过程中重要阶段点双方达成的共识详细记录下来以备查询。
项目组在每次现场工作都必须要写备忘录备忘录必须注明现场工作天数按时间段写清楚工作内容性质和时间长度。
例如培训工作要写清楚培训人员名称培训内容培训小时数培训掌握效果
例如装机工作要写清楚装机软件装机台数是否可正常使用等等细节。
每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。下次工作则根据前次备忘录的双方约定继续进行保障项目在每次工作基础上不断前进并用备忘录约束双方的行为。
备忘录标准的写法是先简要汇报阶段工作中内容要用积极肯定性的文字给自己前一段工作或者一些提法给出正面结论这样大家看了才有信心。
这个工作内容往往是上一阶段约定要解决的内容而且在这次现场工作中得到解决的内容要考虑和上一次备忘录约定工作内容的呼应很多人写备忘录纯粹是为了备忘而备忘备忘录三大功能第一是备忘第二是缴功第三是约定后续工作安排推动事情继续前进。
所以写备忘录首先要讲上一次我们约定什么工作这次是否完成完成质量如何没有完成是什么原因造成的是否纳入下一次解决的内容这样的文档才有体系也能体现出一个人整个项目过程中的脉络否则写这么多备忘有什么用
结论出来后后备忘录要详细描述自己所做工作细节细节越详细越好让项目组彼此认可工作内容和质量而且对服务工作量可以有一个客观的评估。
而且在写备忘录时发现自己大量时间并非在有效沟通或者在推动项目实施上那么意味着项目已经是在失去控制路上应该立即引起警觉并采取措施解决。
备忘录最后还要约定下一阶段双方工作安排在后续工作中严格按照备忘录设计自己的工作计划了解企业项目组进展如果企业项目组方面配合出现问题在下次备忘录中要明确指出责任承担方给用户形成一定的压力从而更好推动项目走向前进。
一些重要的项目目标约定或者验收意见可以单独写备忘录在最终验收时可以作为依据。
这样一个备忘录一个脚印推动项目向目标前进每个备忘录都在前一阶段工作上有一点点进步最终项目验收就是水到渠成的事情。
除了实施备忘录外实施人员最好给每天工作做详细记录实施备忘录个人认为只是一个工作进度大概描述而且可能会有水分因而需要有一个每天工作的详细记录用于自己或者团队成员准确把握项目脉搏及时发现问题个人也能随时做项目回顾用户的反复也能随时记录在案如果出现项目延误也能有理有节和用户应对。
9.1.5 精心准备一次成功的汇报
如果项目准备验收了一般要安排一次验收鉴定这个鉴定可能是要请专家来看可能是企业内部组织也可能就是几个人认可签字即可。
因此如果要验收最后鉴定这个工作质量要高。
要准备好一套模拟现场环境的演示环境要有足够真实的数据要设计一套体现应用特色介绍流程要准备一套详实汇报材料和相应PPT。
要保证验收大会顺利通过其实是在验收大会前将相关汇报工作和现场应用情况和企业领导做过汇报并得到充分认可。
9.1.6 平时做人的积累
对于项目一个实施人员要为公司考虑节约成本同时也兼顾客户利益是比较难以决策的。
特别是在一个多可能同时负责多个项目的时候想每个项目都应该全力以赴是很困难的。这样难免让用户觉得我们响应不及时有问题不解决特别有些问题不是我们一个个体能够解决的长期下来用户可能会积累很多的怨气。
因此实施人员平时做人要讲诚信讲原则无非是三条
做不到的事情千万别随意承诺
承诺的事情一定要努力做到
每次做到的事情都进步一点点。
有这三条用户会慢慢接受稍微长一点的响应周期也会用更多积极性眼光看现在的问题也相信问题一定有人响应也一定可以得到解决。
我们很多人做项目遇到困难在公司内部没有想尽办法去解决认为我自己这么努力承受这么大的压力而别的同事好象没有什么压力心理不平衡就容易回避放弃。拖拖拖拖到无法再拖的时候在用户那里就没法抬头只能被动挨打。
如果按照以上三条原则做事反而简单不做做不到的当然这个做到做不到不是个人判断而是和公司内部协调达成一致后的意见做得到的一定按承诺做好项目就会简单。
实施过程中可以留一手有些好功能或者便利的地方可以不全部告诉用户毕竟在合同边界中没有涉及在验收前可以作为条件和用户去置换。
9.2 如何催款
首先要主动提出回款要求这是很多实施人员最难做到的一点不知道如何开口担心开口后被动。
其实要钱这个事情最难的就是开口要开口要了就简单了为公司催款是天经地意的事情你是在为公司生存催款也是为了有钱才能提供更好的服务要理直气壮的去要钱。
就象很多人催别人还自己借给他的钱一样难就难在自己的心理顾虑上。
不管项目实施地好不好一开头要钱用户马上就会提出不合适这个时候我们要趁机了解现在不合适具备什么条件就是合适立即和用户约定回款条件有了回款条件等于给自己清晰约定了双方工作目标那么这个回款条件马上写进备忘录达成一致意见。
所以项目中只要觉得具备一定条件就要主动提出验收验收速度取决于对验收目标是否达成一致。
不断提出验收要求就可以不断就项目目标进行清晰定位反复三次后验收目标就清楚了这个时候双方项目组就该解决的问题就尽快解决不能解决的就想办法例如进行价值置换或者追加资源投入或者紧急开发或者变更合同等等。
回款条件也不要立即写成备忘录先不断提出各种可行回款条件逐步选择最合理的条件以加深印象并不断利用各种汇报的机会 明确最终写到备忘录中成为未来验收工作开展依据文件。
一旦目标一致清晰后实施团队要全力保障回款条件实现一旦达到回款条件还别忘了请商务人员做去商务工作个人也不是万能的搞技术的可以催钱但不要去要钱。
10.1 如何做项目团队管理之前言(连载五十八)
入行五年做了一些项目现在最大的体会发现目前整个管理信息化实施尽管每家公司都提供了很多方法去指导提供了很多流程去约束但效果不大。
为什么呢因为管理软件实施需要一个人在四个方面都必须很强才能顺利推动这四个方面是企业业务管理理念软件功能人际沟通。实际上一个好的实施人员必须是一个能力非常强的知识复合型精通项目管理技巧的人才。
在产品基本成熟后一个成功的项目是靠个人能力去保障的流程和方法论只能给有潜力的人行动启发而不是指南。这就是目前的现状。
而这种人才的获得是非常偶然或者是需要长时间积累的但整个IT行业是一个年轻人的事业大量不足30岁又没有多少行业经验的人活跃在一线项目服务整体质量不高在所难免。
IT人注定是奔波劳碌命一个现场赶往另一个现场的奔波中知识的更新和积累非常缓慢不如说是吃老本更合适而IT公司为了应付用户需求也是招架不及成本难以控制更不可能在业务培训上下功夫结果就是一大批有潜力不职业的实施人员在IT业浪费了青春。
通过高薪吸引高水平的项目管理型人才或实施人员进入IT管理软件实施工作其实是一个伪命题。毫无疑问当前一个具备以上技能的人员在IT业可以获得的回报是远远少于其它行业是不可能吸引多少人才加盟的可能每家公司都有一些高人与其说是为利益最大化不如说是和爱好重叠在工作中有乐趣。
但一个公司高人是有限的不可能让这个高人去应付所有的工作否则这个高人只能给每个项目一点点精力还不如一个花费大量精力在某个项目上的能力低一点的人的效果。我们在高度竞争的情况下不太可能引进高人去实施成本无法承受也不能让一个高人去面对所有的项目让高人崩溃。
根据我的观察业内很多忙人共同的特点是售前售后一肩挑几乎是一个突发事件跟一个突发事件没有喘气的机会最终的结果只能是黯然引退。
所以解决这个矛盾必须寻求另外的出路。
我个人的建议是公司第一要做好知识管理并通过IT产品为核心整理自己的知识将对企业业务和管理理念支持通过连贯的功能体现在产品中并形成售前售后一致的标准实施和演示方案并不断完善。
此外就是建立项目团队通过团队能力组合去弥补个人能力不足在团队中建立学习型文化通过亲自示范传递很多软能力技巧也许是目前摆脱困境的办法。
10.2 好的项目团队构建要求
一个好的项目团队绝对不是一种性格一种单一能力的人的组合。任何一个人想做项目经理实际上从一开始就要考虑如何构造你的项目团队。这些考虑包括如何建立实施能力的合集形成共同的价值观和行为模式等方面。
项目经理在建立项目团队时容易发生两种误区第一要求别人有团队精神第二是指望别人有为项目目标牺牲自己时间的精神。
这样建立团队只能说是期望值过高最终团队很难一起长期合作。
个人有没有团队精神不是关键而是你建立的团队对不同的人是否有包容精神发挥他们的长处抑制他们的短处。
要做到这点就是通过合理的利益机制去保障不要指望用什么精神力量去长期维护一个团队的斗志。
要知道很少有能在半年内结束的管理软件项目所以也不要指望个人一开始就愿意为了项目成功去牺牲自己的利益。
个人认为建立好的团队把握住两个方面就容易第一是团队成员价值观接近第二是团队具有合理的利益分配机制。
一个能成功合作的团队最好的方式是选择具备同样价值观的人加入团队。
国内项目很难做好的一个重要原因就是信息化长期艰巨性和企业需要立竿见影的效益之间的矛盾。
这个时候无论个人能力多么强恐怕都无法立即满足很多用户的期望值因此团队必须要有长期抗战的心理准备这个时候肯承担责任的人非常适合加入团队。
作为一个管理软件实施项目一定要选择那些有耐心有韧劲有担待的人去负责项目这样的人才能把项目做好。
因为一个人肯担责任就会努力去解决问题在解决问题过程中其技能一定会在很短时间内得到很大提高这个人业务能力怎么样是可以解决的问题。
但一个人不肯承担责任不肯努力解决问题问题就永远停留在原处不被解决即使开始技能不错后来也不能适应项目需要。
很多项目往往因人而成因人而废。这个现实告诉我们很多时候我们必须花费足够精力去选择这样的人。个人认为现在中国这么大选择40~50个认同这样价值观对待遇要求也可以接受的人员一定有只是我们没有去发现总是通过一大堆其它条件去选择人员有关。
例如我们总是要求一个实施人员有计算机软硬件知识良好制造业背景对信息化管理软件实施有深刻认识对软件功能熟练掌握。
这些都是对人硬能力硬指标的要求但是无法衡量一个人的软能力而在项目实施中软能力是最重要的。所以我们在选择成员的时候要和人力资源部门有力协调不要选择大量硬指标的人第一是难找第二是不好管理难以协调一致和产生认同感。软能力的衡量要考虑最大方面就是价值观而不是现成的业务技能。
根据个人观察能够快速在项目中独立担负责任的人从一开始他对这个行业一无所知到可以独立完成任务在有人指点的情况下一般只需要半年甚至更短。
所以完全不必担心这些新员工能否成长而是应该担心新员工能否得到良好的指点。
选择好团队人员只是一个开始一个团队一起协同工作一定是可以通过工作获得相应的回报这个回报一定要有一个大家认可的合理分配机制。没有这个合理的机制团队也会因为失去激励和公平而人心涣散。
做到合理的分配机制在项目控制过程中非常难因为国内同样规模和难度的项目有的企业金额80万有的企业40万甚至有20万软件公司为了解除现金流压力最后都会承诺去做。这些项目要做好都需要消耗同样的项目人力资源。
如果一个人做了一个80万的项目一个人做40万的项目可能工作量差不多但项目提成收入可能差距就是一倍。这个问题也就是存在所谓“肥单瘦单”的说法。
即使两个人做的同样是40万的项目项目复杂程度可能差别很大工作量差距也是好几倍提成收入又差不多。
就算是两个项目金额复杂程度差不多付款条件不一样也会对可预期收入产生直接影响。根据不同公司的政策往往实施人员更乐意或者不乐意选择首期款比例高的项目。
还有一种常见情况一个项目大家一起做才能完成两个人在项目中花费工作量不一样解决问题难度也不一样这个时候如何平衡两个人的提成收入分配也很关键。
开始合作的时候大家往往比较容易齐心协力解决问题但如果到了利益分配的时候大家觉得受到不公平待遇估计你的团队也就开始瓦解。
解决这个问题的办法我觉得很难从两个方面入手也许容易做一点一是在团队内公平透明优先奖励符合我们价值导向的人第二是必须认识到这个是一个项目经理管理团队最需要花费精力的地方必须保证时间去思考和解决这个问题。我们中国人一不缺智商二不缺情商但比较缺钱商孟子说民不患寡而患不匀大概是我们可以参考的一个思路。
实际上我认为建立一个实施团队不要照搬那些管理理论的理想描述去做关键就是这两个问题有没有一致的人有没有合理的分配机制。
10.3 好团队的两个特征(连载五十九)
一个好的团队一定是分工明确的团队。
很多IT管理软件项目要么是一堆人泡现场要么是孤胆英雄。
因为遇到事情的时候用户的感觉是没有人真的去负责这就说明在项目中没有真正的项目经理
这就是在一个团队中没有明确谁对项目负责如何负责技术问题谁负责商务问题谁负责管理问题谁负责到了真有事情每个环节都忙但响应和处理效率并不高。
实际上用户愿意选择能够解决问题的人而且愿意解决问题的人合作。但这个人往往是项目经理因为项目经理一般实战经验丰富技能不错而且对项目最终负责压力最大结果项目经理就成为这样的人。但项目经理一般要负责多个项目每个用户都喜欢他他很快就在多个项目中变成每个用户都不喜欢的人这就象一个人的情人不能太多太多也难应付。
所以合理分工的原则是帮助项目经理充分发挥自己价值让团队成员能力能充分体现。一般项目经理应该强在对企业业务把握能力能快速发现项目的价值点进而通过良好的沟通技巧在团队内和用户处就项目目标达成一致并形成可执行的后续计划。
这也就是所谓计划组织控制三步曲。
项目经理不应该让用户认为是一个技术很强的人当然项目经理技术可以很强否则用户会不认可实施人员的能力反过来要求项目经理到位而团队成员技术能力也会因为没有足够实践机会而成长缓慢。
不能成功让用户接受自己团队成员能力的项目经理注定是疲累不堪和失败的项目经理。
此外项目经理技术性比较强而且在管理软件实施过程中要带一些顾问的性质这样的角色最好不要和回款直接挂钩可以出面提醒用户按期支付款项但不应该直接去要钱这些工作应该通过商务经理完成。一个人上来谈目标下来谈收钱会给用户一种不真实的感觉是否你为了回款而设置比较低的目标
所以一般在一个团队中应该有项目经理实施经理客户经理三种角色。
项目经理项目经理最大的作用是控制项目边界代表项目组和用户就项目目标达成一致然后组织资源保障项目得以实现。项目经理要保证为了达到预定时间内的目标可以配置资源和时间去完成这件事情而不是到处救火亲自去解决问题。
实施经理主要是从技术上保障项目顺利运行的配置实现并保证让用户可以独立应用并推广软件在积累一定经验后可以独立完成解决方案编写和产品完整演示。
客户经理是当项目达到合同约定条件时负责催款和回款相关的商务工作。
个人认为实施经理和项目经理最大区别不就在于一个同时只能搞定一两个项目项目经理可以同时搞定5~6个项目。
项目中三种角色缺一不可每个角色在自己能力范围内发挥作用互相协调配合一致非常重要。而且项目经理要让用户清晰知道遇到何种问题可以如何和我们项目组联系我们会如何解决大概需要多长的时间。
这样的团队最大的问题是是否遵守同样的行动规则也可以理解为对外是否具有一致性。这也是一个好团队的特征。
有的项目商务经理为了便于回款或者签单容易过度承诺给后期实施制造极大障碍有的实施人员在现场发现一些新的问题容易犯个人英雄主义自己去承诺解决但并不先和项目经理沟通有的实施人员如果不是特别安排基本上不会去主动和用户交流有的实施人员几乎每天都和用户电话联系有的项目经理经常和用户联系实施人员反而不去联系这些都是行动规则不一致的表现。
在一个团队是否遵守同样的行动规则首先是价值观一致。
例如我们是否都认为如果用户现场出现各种问题我们应该先全力促进解决问题再来谈问题的责任而不是一开始就说这不是我的错这个不归我管
我们是否认为为了让用户满意我们必须随时准备牺牲自己的时间和精力
这些都是很重要的问题。
第二是养成事先沟通的习惯。不要自己去决定所有的事情也许你的决定没有错比别人去做也会效果更好但是在没有得到明确授权范围内的事情一定要先在内部达成一致后行动否则容易出现做了别人也不领情的情况。
很多事情也很难一开始就形成规范或者文件指导但只要我们清楚这些事情应该先内部达成一致总是有办法对于一些规律性的东西就慢慢形成惯例可以减少沟通的成本这也就是所谓团队默契的形成。
第三是每个人的沟通频率在一个项目中各个阶段保持一致关键沟通信息应互相清楚不同角色沟通频率节奏要合理搭配。
第四是对项目边界和不同角色责任承诺对用户说法要一致这个是通过内部沟通达成一致后要和用户明确的。
10.4 如何看待项目经理在团队中作用
IT业流动率高做实施的流动率相对开发可能更高一些一个项目最怕中途换人但这种情况在业内非常常见用户非常担心自己的项目出现这种情况往往要求在合同前期指定项目实施人员这是一种无奈也无用的做法。
所以软件公司应该将自己业务上比较优秀的人提拔出来给予项目经理的职责培养其管理意识而不仅仅是技术意识给个人比较大的成长空间和较好的待遇这样有利于核心员工的稳定再由核心员工带领团队去做一个项目这样项目因为人员流失造成项目中断的风险就最低。
所以对于公司而言项目经理不能是一个一般性岗位是一个具备能力核心员工才能担任的岗位这个岗位能让核心员工在比较长时间内稳定开展工作并通过项目经理带领团队实施促进团队能力提升保持团队队伍稳定。这对于一个项目可能是非常重要的一点。
从项目实施角度来看努力去负责一件项目是很不容易的事情特别是这种管理软件实施所以一个项目团队中必须有一个项目经理。
项目经理就是无论是其责任心还是职责规定都是那种寻找努力促进事情发生从不轻易放弃的人。
项目经理是一个团队的精神领袖他的言行直接对团队起到一种示范作用。
一般认为项目经理未必一定是一个团队的技术领袖但实际在目前国内要想成功控制管理软件项目项目经理至少得是一个业务精通者。
一个对企业业务不熟悉对管理软件不熟悉的人担任项目经理更大的可能是造成一场灾难尽管也许他具备很好的项目控制能力。
总之项目经理要成为一个让用户和团队成员都信任和放心的人这种精神领袖的地位是靠项目经理能力和个人魅力逐步得到大家认可后在一个集体中放大和加强的。
10.5 团队建设心得和误区(连载六十)
10.5.1 加强沟通保持一致
项目管理强调团队达成一致再行动但达成一致的关键是先在内部广泛达成一致再对外沟通。
这个原则有两点在操作中很容易出现问题的地方第一是项目经理事无巨细都需要了解和沟通协商成本太高导致沟通效率很低。
内部沟通非常必要但也没有必要事事沟通反而打击团队成员工作积极性。项目经理应该实现和团队成员约定不同类型事件沟通方式和频率保护团队成员工作主动性同时保障项目始终受控。
第二项目经理自认为能力很强按照一些项目管理理论说法项目经理先和客户达成一致目标然后协调资源完成目标内部资源不听调度就非常恼火。
现在一个出色的项目经理一般都无法专心做一个项目所以项目中主要实施工作还是要依赖其它团队成员完成因此在一个团队中对于软件实施有不同认识和意见是很正常的项目经理一定要先多花一些时间在内部沟通千万不要以为内部一致性很容易达成。
我们员工更习惯的思维模式是既然你都已经决定了我照你的做就是还问我意见干什么如果员工觉得项目经理思路不对他们可能不是优先考虑执行而是想证明自己是对的这也是知识型员工的特色。所以宁可先多花一些时间告诉项目经理自己的判断最后和用户会谈达成的结论会比较顺利地传递成为团队共同认识。
10.5.2 参与和顾问式领导方式
很多项目管理书籍告诉我们领导有方的项目经理从来不教人如何工作由项目成员自己决定怎样完成任务。
我个人认为项目经理工作恰恰是要给新员工示范正确的做事方式只要条件许可还要亲自示范在项目需要受控的时候多一点独断专行少一点成员自由发挥是非常重要的事情。
项目经理的示范只需要一次通过示范让项目成员感觉到正确的做事方式可以有效达到目的这也是项目经理建立权威的自然时机。
在中国缺少职业教育的高学历人群比比皆是如果相信这些拥有高智商的人能够顺利完成工作就大错特错高学历的人把很多简单的事情搞得无比复杂的情况到处都是很多人自以为是自作聪明最后还是要别人去开屁股。
也许在国内项目经理不需要过于精细的管理但在国内不能确定团队成员工作方式和能力之前项目经理还是要多做示范保证团队成员工作方式是按照基本的职业方式进行后才能让他们自主发挥。
10.5.3 控制过程还是目标管理
很多管理理论总是强调不要仅仅重视结果要注意过程没有过程质量的保障最终的结果输出也是偶然的不可靠的。
这个理论一点都没错不过问题是实际上项目经理在过程控制上花费的时间越多花费的精力越大项目反而越难以控制。
因为管理软件实施对人的综合能力要求太高当一个人的能力还不能达到业务要求的标准的时候最需要的是培训和示范而不是责问为什么你的工作不到位
就象本人写前八章一样能够把这些事情正确执行方法知道的人都不多有实际经验的人更少对能力不足的人去控制过程还有控制的必要吗
这个时候最重要的是建立业务规范在业务规范大家有能力执行的情况下再去考察业务规范符合度加强过程控制才有效。
我们很多软件企业不断强调自己的流程和方法论但员工经常流失很多新员工在现场工作的时候什么方法论都不管用他们充满恐惧的想我到底该做什么我该什么做。
过于强调过程管理最大的一个体现就是汇报多层次复杂增加了很多管理活动但又看不出这些管理活动的价值。结果是很容易重复汇报或者多头汇报。口头汇报完成的工作还要书面汇报日常汇报过的工作还要专门总结汇报现场记录的工作还要单独汇报。
经常反复汇报在项目管理的理论中也有说明这是打击团队士气的有效方法。
本人建议汇报突出两点坏消息先汇报例如不能按照计划完成的工作要汇报需要紧急协调资源的消息要汇报这些随时发生随时搞清楚原因随时汇报随时采取行动。
第二与其反复了解进展不如提供清晰的目标管理。
也就是说项目经理接受和交代任务的时候一定要清楚自己任务的范围质量要求进度要求。
对任务理解是否达成一致的最简单方法就是请任务接受人当场复述。任务接受人如果不清楚任务的内容进度和质量要求一定要问清楚才能去执行如果不清楚怎么做也要立即沟通请教不能先好好好回头告诉别人我搞不定。
本人曾经给一个员工布置一个修改方案的任务电话里说了6点修改意见问他清楚了吗非常自信的回答我知道了放心。
本人很不放心的又问一句给我复述一遍。很流利的说了四条然后问我哎呀还有两条呢
所以在接受任务的时候还要一个职业习惯好记性不如烂笔头。
在国内目前项目实施水平现状下个人以为目标管理严格的目标考核机制远远比过程控制更能达到管理目的只有当大面积的人可以按照目标完成项目的时候过程管理才能发挥不可替代的优势。
10.5.4 信任团队成员
项目经理一般都是业务能手很多时候看到项目成员做一些很简单工作都做不好马上亲自动手先搞定问题否则项目耽误不起但常此以往项目经理就是眉毛胡子一把抓活该累死。
项目经理要信任和授权成员独立完成任务既然都在一个团队就要用人不疑疑人不用。坚决大胆要求团队成员努力学习独立掌控局面项目经理逐步演变为对目标进度的控制者。
当然这个时候项目经理要加强对员工工作的指导但项目成员往往分布在不同的现场项目经理要结合不同项目拜访计划的时机采用走动式管理。在现场不断并亲自验证成员的工作方式立即指正和改进加以示范。
信任不是放任自流以信任的名义对团队成员的工作放任自流是项目经理失职和偷懒。
而且项目经理要时时考虑让让用户成为团队中的一份子从一开始就全力培训用户是减少实施成本的最有效方式。
团队成员一个比较共性的问题就是很多人会问没有资源没有人我怎么开展工作。这样的团队成员可能会辜负项目经理的信任。
这是很大的一个误区一个人有能力的表现就是能做别人认为很难做到的事情如果事事有资源你才能把工作做好能说明什么这种事情谁都能做。
而实施工作就是在各种缝隙里寻求合理的答案项目经理在信任团队成员的时候也要让团队成员建立承受压力迎接挑战的心态也就是所谓情商吧。
10.5.5 建立向上的团队文化
项目经理一般都是个性很强的人不太可能用同样的方式约束项目经理的做事方法当然越是成功的项目经理行事方法越具有共性。
而项目团队成员和项目经理的互相认同对一个团队成长非常重要也是工作能否快速进展的关键。
项目经理要及时认可成员工作随时用进展鼓舞团队士气。对很多人而言物质奖励的预期是很清楚的一件事情国内的项目经理一般也没有多大空间去对项目成员工作进行物质奖励因此在这样的边界条件下我们更要寻求利益机制以外的团队合作方式。
