本人从事咨询工作多年,二十年一线数字化规划咨询经验，提供制造业数智化转型规划服务，顶层规划/企业架构/数据治理/数据安全解决方案资料干货.
如果想要学习IT咨询规划提升解决方案制作能力，核心逻辑需要从业务和技术两个方面入手，关键要素是要打通业务和技术的衔接问题，保证两方面相互支撑，贯穿发展。
业务驱动IT，而IT最终为业务目标服务。打通两者之间的衔接，关键在于分析和解决问题的能力，通过大量的项目实践提炼，逐步形成方法论。比较快捷的学习路径是先学习头部咨询公司的方法论，然后有针对性的付诸实践，通过实践后不断的总结和复盘，逐步又形成了自己做事情的方法论和最佳实践。
笔者一直从事IT行业，接触过各类咨询公司，就IT规划咨询来说，IBM的规划咨询方法论更加宏观和理论化，HP的方法论则偏陈旧也不足够体系化，但HP团队沉淀扎实，落地性强。而埃森哲的方法论是笔者最为推崇，从理论框架体系，到最终的解决方案和落地实践演进，较为系统及完整
学习金字塔原理应用
很多人都看过金字塔原理这本书，这本书主推结构化思考逻辑，而逻辑的静态支持是金字塔和树状结构，动态支撑和归纳和演绎，分析和解决问题方法论。
理解金字塔原理后，最终方案报告的文档呈现也应会符合金字塔结构，可参考下图。
埃森哲的IT规划或解决方案是完全遵循金字塔原理的，要么是动态按阶段展开，要么是静态架构图的金字塔分解展开。
规划方案首先阐明方法论或研究思路
对于埃森哲，常用的IT规划咨询方法可参考如下三阶段：
在第二阶段蓝图设计中实际涵盖了四部分的内容，那么整体的逻辑结构在第二部分就应该按上面四个内容展开到二级目录章节。整体的叙述思路基于上述的阶段和步骤逐步展开来即可。这样整体的方案结构是完整的。
构建静态金字塔架构并逐层分解
对于静态呈现如何满足金字塔结构，比如大家常用的树状图，分类图等都是满足金字塔结构展开的。在IT领域，在阐述解决方案的时候，经常使用到的是各类的架构图。
架构图的构建逻辑最重要的是分层，分层当中包括分组。一个完整合理的架构图应该是满足金字塔结构的，比如分层可以作为第一层，而分层里的分组可以作为金字塔里面的第二层展开。
在IT规划和咨询方案里，当需要给出一个总体解决方案或需要给出一个总体架构的时候，优先会考虑采用类似架构图进行呈现，而且需要完全满足金字塔结构。同时基于自顶向下的细化逻辑逐渐分层进行呈现和展开。
比如可以先构建粗粒度的顶层架构，或一级框架：
然后对顶层架构进行分解和展开，描述二级或三级架构：
末梢触点可以描述单个业务系统，基于这张逐层展开描述方式，那么整体内容就不会和主干脱节，同时层次逻辑清晰且可追溯。
分层和多维度框架思维
埃森哲在自己的IT战略规划、业务流程优化等诸多咨询报告里面，经常会使用分层模型和多维分析模型，即从多层面、多角度、多维度描述事物，往往会更加透彻。
比如针对IT咨询规划，埃森哲给出了自己的IT战略顶层框架构建模型，参考下图：
从上图可清晰的看出，战略规划包含三层架构。整体架构重点还是业务，技术和管控三个关键层面，同时又体现战略驱动业务，业务驱动IT的核心思路。
比如笔者在编制解决方案的时候，也会经常参考三层模型的架构思路，参考如下：
基于该架构图可以对业务解决方案，系统解决方案和管控治理方案进一步展开，形成二级架构图，完全遵循金字塔逻辑架构思路。比如在业务解决方案中，仍然先给出整体业务方案架构，在逐层细化分解。
学习分析和解决问题的方法论
在IT规划咨询的过程中，不应完全照搬某一个方法论，而是需要基于自己的实践经验总结参考其他项目经验从而给出一个最终的解决方案。
但是即使这样仍需要考虑提供的解决方案的完整性及合理性。就好比一些集团企业请知名的咨询公司做业务或IT类咨询，其实核心目标和改进点集团领导都已清楚，但是仍然需要聘请咨询公司来进行咨询。简单来说就是企业的管理层往往是凭经验给出了一个结论，仍然需要咨询公司去向下证明结论是正确与否。
对于问题分析和解决，具体可参考如下步骤展开：
第一阶段：问题分解和基础素材对应
该阶段的重点任务是将目标进行分解，然后将论据映射到分解的子问题上。
在该阶段需要结合知识库积累以及外部资源，对资料进行梳理分析，将无用的素材论据进行过滤。
最后留下的就是能够完全支撑目标的有用论据材料。
第二阶段：粗粒度对应，进一步排序和整合
第二阶段需要进一步材料进行整合和归纳，形成解决模块，然后将解决模块对应到子问题域。
在解决模块形成过程中，还需对素材论据进行优先级排序，确定材料的重要性，即在最终呈现的位置上的前后关系。
第三阶段：进一步归纳并从归纳到演绎反转
经过前两阶段的论据整合，已经基本形成框架，但仍然比较散。
因此在第三阶段需要进一步归纳整合，形成一个完整的整体。不论是静态的金字塔结构，还是动态的流程结构都需要看到，最终的解决方案中各模块必须是一个整体。
其次通过归纳反转给出完整解决方案，然后再来进一步演绎呈现给出的解决方案中的各个解决模块是足够的支撑各个子问题的解决的。通过各个解决方案模块的集成和联动最终完成大目标的解决。
接下来再来看下，埃森哲相关的规划咨询报告里面常用的一些问题分析解决思路和工具。
给出整体的研究方法
埃森哲咨询报告经常采用的思路就是在章节的开始位置给出研究方法的动态图，该图会明确描述章节的承上启下，章节里面的关键活动之间的关系。也就是说你研究方法看明白了，也就明白了作者输出本章节内容的思考过程。
以下图为例，在进行平台架构愿景展开前，先给出研究思路。
从上图可以清晰地看到本章的关键输入和输出以及一些标准规范依赖。这个图也清晰表达了本章节的核心内容逻辑。
配合详细流程和集成分析去找寻问题
对于任何一个规划咨询项目，首先需要基于业务目标和IT目标去分析当前的现状，梳理问题，最后才会考虑如何系统形成解决方案。
对于埃森哲的方法论有两种最常用找寻问题点的方法，即配合流程图去分析，或是配合集成点去分析。
配合流程图分析往往可以找寻到组织岗位，角色，业务活动不合理的点。而配合集成点去分析往往容易发现当前端到端流程协同上的问题和断点。
对于流程分析找寻问题点，参考下图：
通过该图可以详细的看到问题点在哪里，问题的描述，问题和整个业务流程和业务活动的关系究竟是如何的。
对于集成和交互图，可以用于分析具体集成上的问题点，如下图：
而这些具体问题点分析都将应用到后续的整体解决方案构图，集成架构规划等。同时需要在最终的解决方案中论述，以上的这些问题点都通过新的架构规划解决掉了。
从定性到定量的差距分析
在进行IT规划的现状诊断分析过程中，为何差距分析如此重要？
因为差距分析本身就体现了问题和目标驱动的核心思想，即目标和现状之间的差距。
差距分析本身有很多类型，比如：
业务现状和业务目标之间的差距分析
IT现状和业务目标之间的差距分析
IT现状和业界标准和标杆对比的差距分析
所有的差距分析最终都是为了找到具体需要解决或改进的问题点，并将这些问题点进行整合后形成一个完整的解决方案。
差距分析分为定性分析和定量分析。
对于定性分析一般是通过对一线的业务人员或技术人员进行现场访谈或者通过调查表调研的方式进行问题收集和整理。因此定性差距分析一般也仅仅是从业务，技术，管理，效率等大的维度方法进行初步的问题收集和整理。如下图：
但是简单的定性分析往往很难评估问题的严重程度或影响面等，因此当前规划咨询更多的会引入定量差距分析的方法。
定量分析简单来说类似结构化决策的思路，即需要基于当前分析的问题，首先基于业界标准或最佳实践制定科学的维度，同时基于不同的维度和量化原则进行评分。在量化评估后更加容易分析具体的业务场景和问题点究竟在哪里。
比如在进行应用架构的量化评估中，可以从重用度，成熟度，完备性，集成性等多个维度进行量化评估后打分，最后再进行加权评估。
在完成所有业务系统的定量分析后，最终形成一个定量评估结果。
学业务流程分析和建模方法
在前面谈到了IT咨询规划核心还是业务驱动IT，从业务流程调研和分析入手，那么对业务流程的调研就需要形成完整的流程分析和调研方法论。而这块当前用的最多的还是ARIS的流程建模思路。
就埃森哲的咨询规划报告来看，对于业务流程建模框架是比较完整的，基于完全基于ARIS的思路。
如果单独对业务活动进行分析如下：
当把要给完整的业务流程分析清楚后可以看到核心的业务功能操作，业务对象，岗位角色，工具技术支撑等内容全部也就分析清楚了。而这些也正是后续进行业务架构规划，应用架构规划的基础。
当我们去分析跨业务域，跨部门的业务流程协同的时候，又可以看到具体的协同边界点，而这个正好又是后续进行应用集成架构梳理和分析的基础。
业务流程建模分级
业务流程建模本身是从企业价值链和端到端流程分析展开的一个完整自顶向下的过程。从最底层的价值链分析，到二级三级流程，再到最底层的EPC事件流程图，以形成一个完整的业务流程建模框架，整体框架分级如下：
到了最底层的EPC流程链，基本可以和应用系统功能实现中的软件需求和用例建模匹配。
比如对于最底层的EPC事件流程图可以到很细化的颗粒度。
包括在进行流程建模后，基于流程输出进行跨组织，跨省的流程差异对比和分析，如下图：
而这个差异分析本身也是找寻问题点，并优化和整合出一个最终流程的基础。也正是这个原因可以看到流程建模，流程梳理和优化是一个相当细化的工作。
形成As-Is到To-Be的流程梳理
当进行详细的流程分析和建模的时候，就容易看到具体的流程断点，岗位职责不清晰的地方等，而这些整合式需要优化和改进的点。
正是这个原因，任何改进点或解决方案都不是凭空产生的或简单的照搬业界标准或最佳实践。而是应该真正从企业当前业务目标，流程现状出发，去梳理和分析流程，去评估差距，然后找到最适合企业的解决方案。
学习IT治理管控模型
埃森哲的IT战略规划中有一部分非常重要的内容，即IT治理管控框架体系的构建。管控治理直接影响到最终的解决方案是否能够最终落地实施。
埃森哲给出过一个完整的管控治理框架如下：
从上图可以看到管控框架覆盖了多方面内容，包括工具技术支撑、组织、流程、业务、运营、人员等。
任何一个完整的管控模型首先就是要确定组织，流程，工具支撑，接着才是基于具体的业务域，业务系统的内容，基于生命周期展开的思路制定具体的管控点。比如埃森哲给出的主数据管控能力框架如下：
其外围是组织，流程，工具技术，而里面则是覆盖主数据域的具体管控内容。
当然一个完整的管控治理模型本身也可以按照业务，技术，组织三个维度来进行分解，然后基于动态的生命周期展开形成一个完整的管控体系，参考下图：
这张二维矩阵式的方式可以从静态分层和动态生命周期两个维度的详细分解具体的管控内容。比如笔者前期在做SOA规划建设项目的时候，整理的SOA治理管控框架体系图基本也是参考该方法形成。
