时间: 2021-08-03 09:20:35 人气: 16 评论: 0
笔者在文中分享了他参与的一个B端IT咨询项目的实施流程，并分析了复**后的心得体**。
我做过的IT咨询项目不少，可真正收费的IT项目并不多，大多的咨询都是为了后续的项目实施做铺垫。
我所在的公司并不是专业的IT咨询公司，不像IBM 、埃森哲，IT咨询是他们的主业。
在我的职业生涯中，第一次收费的咨询项目印象深刻：
给一个央企分公司做咨询，金额不大，几十万的项目，打败了很多咨询公司中的标。因为我们当时也不太愿意做这个咨询项目，所以报了并不低的价格，结果就中了，还是比较幸运。
通过这个项目，让我们公司打入了对方的采购部，从而把我们的安全产品推了出去。虽然咨询没多少钱，安全项目却赚了不少钱。
我是这个咨询项目的负责人，所以印象深刻。通过这个咨询项目的实施，我大概把整个咨询项目实施流程做个介绍，复**一些经验和教训，希望对有志于做IT咨询的小伙伴有些帮助。
项目启动的时要写个简洁、专业、漂亮的PPT，把本次咨询项目的目标、项目组以及里程碑计划做总体介绍。
项目组人员要和里程碑计划、咨询费用匹配，你不能说就2个人一个月搞定，这样显然和一个50万的项目不匹配。
所以，项目启动**尽量多去一些人，哪怕这些人只是友情支持凑个数。当时这个项目启动的时候我们去了6、7个人，还去了一个公司领导以示重视。启动**一结束，真正投入干活的也就2、3个人。
还有另外一点也很关键，要在启动**上把需要甲方配合的工作说明白，把甲方关键人员也拉进来，让他们明白项目要想成功也要一起行动，不能只做个看客。
通过项目启动**正式成立甲乙方联合项目组，明确了项目目标和里程碑计划。
这个过程大概分为资料收集、调研提纲、调研执行、调研总结。
这一步经常被忽略，特别是在对咨询项目很有把握的时候更容易被忽略。
实际上，收集资料作用很大，收集来的资料初步分析，能初步抓住一些业务关键点，是下一步调研提纲编写的重要输入。
先要确定调研对象，通过调研对象来确定调研方式：
一对一访谈或者是研讨**都要提前准备访谈提纲，访谈提纲建议按照调研的业务主题准备。
调研时，建议至少2个人参加：一个人负责提问，一个人负责记录。针对一些特殊情况要记得录音，有些用户讲的内容比较快，而且不愿意跟你重复讲，这个时候通过录音记录下来，访谈后再重复收听才能掌握要点。
访谈后要输出访谈纪要，讨论**后要输出**议纪要，调研问卷收到反馈后要输出问卷分析报告。通过调研后的分析、抽象、总结，对业务和系统现状的痛点才能比较了解，下一步才能对症下药，给出更加契合的方案。
另外需要注意的是：除了对业务现状的调研外，还需要调研系统现状。我们最终要做的是IT规划，所以要了解情况系统的建设情况，才能有的放矢，考虑如何利旧现有系统，新的系统如何与旧系统衔接，只有这样才能输出完美的咨询方案。
现状调研完成后，已获取了业务和系统的现状，但要想输出一般比较完整的IT咨询方案，这些还不够，还需要进行对标，一般体现在三个方面：
很多B端产品在业界都是有成熟规范、模型的，比如：
做这类对标最大的益处就是：让你的咨询方案更加专业、层次更高，有了这些业界规范做背书，方案的层次一下就提高了。
如果市面上已经有了比较成熟的产品，我们再去做，就要拿这些成熟的产品去做竞品分析，B端产品不像C端产品那样，装个APP实际用一段时间就能大概体验出来。
这里有个小窍门：很多B端产品是有免费试用版的，在网上注册一个账号可以拿来试用，甚至可以花点钱去买一些B端的云服务。如果你是做云计算相关的产品，那就可以花钱买个便宜的云服务去体验。
另外，要在网上找相关资料，类似百度文库这种开放分享的平台，买个**还真能拿到一些质量比较高的文档，这些文档也是做竞品分析的依据。
这个对标也很重要，很多时候客户找我们咨询，就是想知道类似问题友商都是怎么解决的，比如：中国联通想知道中国移动的解决方案；小米手机想知道华为荣耀的供应链策略等。
这个时候，如果我们有能力拿到友商的相关方案，而且能结合友商的方案给出针对性的建议，那客户一定觉得物**所值，加分不少。
友商的资料，一般来说有两种获取渠道：先前做过类似友商项目或者通过公司的销售渠道获取，这些积累在项目启动前就要先收集好。
IT咨询方案一般就是包含5个部分：业务视图规划、功能视图规划、系统视图规划、技术架构规划、演进和部署。
先前写过一篇类似的文章，不做详述，这里把方案要点说一下：
一般功能视图的推导，有3个输入，分别是：
基于这三个输入，经过分析、提炼、归纳形成最终的功能视图。
为了保证功能视图的完整性，在设计功能视图时，需要保证业务视图与IT功能映射。
通过功能视图规划，明确了要满足业务运转需要建设的IT功能。
这些IT功能可能有几百项，可能需要不同的IT系统来承载，系统划分的原则如下：
这个步骤需要明确：建设不同系统的所需要的IT技术能力。
一般的IT应用的技术架构分为几个层次：访问层、应用层、数据层、基础设施层。
需要基于现状评估的结果，比对目标架构，提出提升举措，并将提升举措组合成IT建设项目。
最后，对项目进行优先级评估：一般从业务战略、商业价值、功能复杂度、需求紧迫性、功能依赖关系5个方面分析，得出IT系统建设的演进规划方案。
中期汇报的目的是给项目一个纠偏的机**，说是汇报，其实就是一个高层领导的调研，找高层领导访谈，拿着一个基本成型的方案去聊，领导也能有的放矢，给出针对性的意见。
一般中期汇报**出现三种情况：
1. 方案内容基本与领导的想法和思路契合，这时领导**根据你的方案提出很多中肯、具体的意见。如果是这种情况，那这个咨询项目基本完成80%了，后面只要把方案做些完善补充，就能交付验收了。
2. 还有一种情况就是：方案写得挺多，可是没有很好地契合领导意图，这时领导**比较严厉，直接给大思路上的纠偏，基本上方案的80%都要推翻重现再来了。
3. 最后一种情况是：内容本质上与领导意图契合，可因为方案的组织或是现场讲解的原因，没有很好的抓住领导。这个时候就要在后续几天，尽快组织PPT的结构，并找机**再汇报，按照领导理解的思路讲出来，这样就万事大吉了。
一般的咨询项目交付就是给甲方出咨询报告，也就是一堆的PPT或者word，最大领导同意了，这个项目也就验收了。
我做过的这个咨询项目比较特殊，我们不但要把咨询报告交付给甲方，还要在这一步的基础上把咨询方案交接给第三方实施厂商。也就是说，我们的咨询方案是要最终落地到IT系统的，由负责实施的厂商把系统开发出来，这个难度是非常大的。因为咨询一般比较高大上，直接交给开发方厂商是看不懂的，要落地开发，就要转化位具体的需求。这个事情工作量非常大，当时和实施厂商谈好交付业务需求说明书给他们，然后他们依据业务需求出详细的软件说明书进行开发。
但是，交付过程出了问题：我们毕竟是咨询项目，最后交付的业务需求说明书他们并不满意，感觉粒度还是太粗，没办法落地；而我们认为已经很接地气了，完全可以作为业务需求交付。
因为这个事，当时的实施厂商还专门发邮件给甲方，投诉我们未达到交付要求，后来我和销售想了个办法把这个事解决了。我和销售把实施厂商的负责人叫到我住宿的酒店，然后关起门来聊了一下：我跟他说，我把业务需求说明书写得相对粗，是为了给你留下足够的发挥空间，你可以在落地层明很好地控制细节，这是双赢的局面；反之，如果我把需求写得很细致，你就没有发挥空间了，只能按我们写的内容做，这样是双输的局面。甲方其实并没有太在乎用户需求说民书的粗细，只要我们双方达成一致，这样三方都**满意。
这样一番话下来，实施厂商也就不在纠结了，还主动跟我说：当时那个投诉邮件，不是他的本意，都是他的领导非要让他发。
后来自然涛声依旧了，项目顺利地完成了最终交付。
奋斗De奶爸，微信公众号：奶爸的小客栈（ID：naiba2000），人人都是产品经理专栏作家。10年以上产品、项目管理实战经验，关注企业供应链、数据中心、IT监控等产品，喜欢琢磨，希望把有价值的产品理念和实战经验传递给需要的人。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
