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