从埃森哲IT规划咨询方法论里究竟可以学习什么

　　在我头条前面的文章里面分享过一些IT咨询规划的材料，也分享过一些IT系统解决方案，技术方案类的文章。对于IT咨询规划来说本身也是一个渐近发展的过程，从最早的信息化规划，再到企业架构规划，再到融合云计算和SOA思想的企业私有云规划，发展到最近又融入了更多的云原生，中台，微服务的思想。
　　如果要学习IT咨询规划和解决方案制作能力，实际上需要从业务和技术两个方面入手，同时要真正打通业务和技术的衔接问题。
　　业务驱动IT，而IT最终为业务目标服务。而打通两者之间的衔接，最关键的地方又在于分析和解决问题的能力，而这个能力在通过大量的项目实践后，逐步就浓缩成了方法论。比如你学习了大咨询公司的方法论，然后去实践，通过实践后不断的总结和复盘，逐步又形成了自己做事情的方法论和最佳实践。
　　比如在我前面分享过的一些IT咨询规划，SOA规划方面的材料，实际也是在大咨询公司方法论的基础上融入了实践后总结提炼的内容逐步形成。
　　所以方法论本身不是凭空产生的，而是通过大量实践抽象总结出来的。前人形成的方法论本身有价值，但是是否能够真正应用好为你服务，还需要你自己更多的思考和总结。
　　由于自己一直从事IT行业，因此接触的各个大的咨询类公司和合作沟通也比较多，就IT规划咨询来说IBM的规划咨询方法论更加宏观和理论化，原来HP的方法论则偏陈旧也不足够体系化，但是HP团队本身的技术底子不错，技术落地性好。而对于埃森哲的方法论是我个人比较推荐的，从理论框架体系，到最终的解决方案和落地实践演进，整体比较完整。
　　对于埃森哲的IT规划案例，网上有很多分享可以下载，在这里不再给出，而是对里面的一些关键点进行总结和思考，看看究竟从里面能够学习什么内容。学习金字塔原理应用
　　相信很多人都看过金字塔原理这本书，这本书的核心是讲结构化思考逻辑，而逻辑的静态支持是金字塔和树状结构，动态支撑和归纳和演绎，分析和解决问题方法论。
　　那么看明白金字塔原理后，最终类似PPT呈现也应该完全符合金字塔结构。
　　在前面谈PPT呈现逻辑的时候我总结了上面这张图，即一个PPT应该是完整的金字塔结构，其呈现逻辑包括了动态逻辑，静态逻辑，同时动态和静态相互融合使用。
　　整个PPT展开就是一颗完整的金字塔结构，没有任何一页PPT是孤立的。即我们谈任何一页PPT的时候都可以朝上追溯到具体属于哪个架构图，属于哪个大的阶段展开。
　　MECE法则：完全穷尽，相互独立。你做完的PPT的每一页都要有出处，是在整个树结构上，是可以从枝条或树叶一直追溯回主干和树根的。一个完整的PPT内容架构不应该有任何一页类似树枝一样掉落在地上。
　　对于埃森哲的IT规划或解决方案类文档，基本是完全符合金字塔原理的，要么是动态按阶段展开，要么是静态架构图的金字塔分解展开。
　　规划方案首先阐明方法论或研究思路
　　看埃森哲的规划类PPT材料，你会发现基本都是在PPT首页就会先阐述清楚整个规划或解决方案所采用的研究思路或方法论。也就是说方法论是整个金字塔逻辑架构的最顶层节点，包括后续的章节目录全部都需要基于方法论的整体框架思路进行展开。
　　对于埃森哲常用的IT规划咨询方法如下：
　　如果整体方法论是如上图，那么整体的文档或PPT结构就应该分为三个的章节。
　　在第二阶段蓝图设计实际包括了四个部分的内容，那么整体的承诺逻辑结构在第二部分就应该按上面四个内容展开到二级目录章节。你整体的叙述思路基于上述的阶段和步骤逐步展开来即可。这样整体的文档或PPT结构是完整的。
　　比如我们经常说PPT里面有一页内容是讲IT系统集成架构，而这个集成架构实际可以朝上追溯到2。2IT应用架构总体蓝图，而应用架构本身又可以朝上追溯到第二阶段蓝图设计。
　　构建静态金字塔架构并逐层分解
　　对于静态呈现如何满足金字塔结构，比如我们常说的树状图，分类图等都是满足金字塔结构展开的。但是在IT领域，在阐述自己的解决方案的时候，经常会使用到各类的架构图，比如业务架构，应用架构，技术架构等。
　　而对于架构图前面也谈到过，最重要的是分层，分层里面又有分组。一个合理的架构图本身应该是完全满足金字塔结构的，比如分层可以作为第一层，而分层里的分组可以作为金字塔里面的第二层展开。
　　也就是架构图比简单的树状结构可以呈现更多的层次，关系等可视化要素。
　　在IT规划和咨询方案里面，当你需要给出一个总体解决方案的时候，或者需要给出一个总体架构的时候，优先需要考虑采用类似架构图进行呈现，而且需要完全满足金字塔结构。同时基于自顶向下的呈现逻辑，可以分层进行呈现和展开。
　　比如你可以先展现粗粒度的顶层架构：
　　然后对顶层架构进行分解和展开，描述二级或三级架构：
　　到最细节你可以描述单个业务系统，如供应链管理系统的应用功能架构和功能说明，基于这张逐层展开描述方式，那么整体内容就不会和整体主干脱节，同时层次逻辑清楚可追溯。多谢分层和多维度框架思维
　　前面谈到了整个文档或咨询报告的输出应该完全满足完整的金字塔逻辑结构。而埃森哲在自己的IT战略规划，SOA规划，业务流程优化等诸多咨询报告里面，经常会使用分层模型，多维分析模型，而这些也是我们认识和理解实物的关键方式。
　　即从多个层面，多个维度看待事物，往往才能够更加透彻。
　　比如IT咨询规划，埃森哲给出了自己的IT战略顶层框架构建模型，具体如下：
　　完整的战略规划包含了从公司的业务战略出发，以业务流程为抓手，以IT管控为保障，确保系统实现的落地。整体的三层架构重点还是业务，技术和管控三个关键层面，同时又体现战略驱动业务，业务驱动IT的核心思路。
　　公司的业务战略最终驱动了IT战略，而业务流程最终又驱动了IT应用系统的建设。业务和IT需要双向协同，相辅相成，同时又形成一整套的治理和管控架构体系。
　　再比如，在SOA架构规划里面，埃森哲给出过一个SOA能力交付模型，涵盖业务应用架构，技术架构和管控架构。技术架构涵盖集成蓝图、系统蓝图、基础蓝图。具体的SOA能力交付模型参考下图：
　　通过这张三维架构模型，可以更加清楚的理解业务，技术和IT管控之间的关系和集成。理解和分析事物要全面，那就必须将三者全部考虑进去，并进行有效集成和协同。
　　比如我自己在进行相关解决方案制作的时候，也会经常参考三层模型的架构思路，来构建一个完整的解决方案架构图，如下：
　　基于该架构图你可以对业务解决方案，系统解决方案和管控治理方案进一步展开，形成二级的参考架构图，以形成完整的金字塔逻辑架构。
　　比如到了业务解决方案后，仍然先给出整体业务方案架构。
　　学习分析和解决问题的方法论
　　如果你是从事做IT咨询规划工作，你估计会经常谈到方法论，而方法论本身就是分析和解决问题能力的体现。而对于埃森哲在IT咨询规划里面经常用的分析和解决问题方法论，相当来说是比较完整的，值得去参考和学习。
　　对于经常做IT规划咨询的，往往并不会完全从零照搬一个方法论，进行详尽的现状分析，调研和差距分析后才能够给出一个解决方案，而是会基于自己的实践经验总结参考其他项目经验快速的给出一个最终的解决方案。
　　但是即使这样你也需要考虑你给出的解决方案是完整的，是能够将来龙去脉说清楚的。
　　就好比我经常说一些大的企业请国外大的咨询公司做业务或IT类的咨询，实际核心的目标和改进点领导都清楚了，但是为何还要请咨询公司来做规划咨询。简单来说就是企业的管理层往往是凭经验给出了一个非结构决策和结论，也就是给出了一个结果。但是需要咨询公司去向下证明这个结论是正确的。
　　对于问题分析和解决，我在前面给出过一个核心思路如下：
　　第一阶段：问题分解和基础素材对应
　　在这个阶段重点就是将目标分解为子问题，然后将论据映射到对应的子问题上。
　　在这个过程中你已有知识库积累可能不足够，这个不要紧，那么需要你进一步学习，进一步上网搜索资料，对资料进行分析，同时将没有的素材论据全部要清理掉。
　　最后留下的就是能够完全支撑目标的有用论据材料。
　　第二阶段：粗粒度对应，进一步排序和整合
　　到了第二阶段做什么？简单来说就是要做抽象和归纳的事情了，即进一步对你的材料进行整合和归纳，形成大块的解决模块，然后将解决模块对应到子问题域。
　　在解决模块形成过程中，我们还需要对素材论据进行优先级排序，确定材料的重要性，哪些在最终呈现的时候应该放在前面，哪些应该放在后面等。
　　第三阶段：进一步归纳并从归纳到演绎反转
　　前面三个论据形成了，但是仍然比较散。
　　因此我们需要进一步进行归纳，将其形成一个完整的整体，不论是静态的金字塔结构，还是动态的流程结构都需要看到，你最终的解决方案中各模块必须首先是一个整体，不能散。
　　其次从归纳反转到延期，给出完整解决方案，然后再来进一步演绎呈现你给出的解决方案中的各个解决模块是足够的支撑各个子问题的解决的。
　　通过各个解决方案模块通过集成和联动最终完成大目标的解决。
　　那么我们再来看下，埃森哲相关的规划咨询报告里面常用的一些问题分析解决思路。
　　给出整体的研究方法
　　当进入到一个大的章节的时候，你会发现整个章节里面有很多的内容输出，那么这些输出之间是什么关系，是如何形成的，整个章节内容如何是承上启下的，这些都必须进一步交代。
　　否则进入到某个章节，第一页就是整体解决方案架构，那么往往让人摸不着头脑。
　　对于埃森哲咨询报告经常采用的思路就是首先在章节的最开始给出一个研究方法的动态图，在该图上可以明确的看到章节的承上启下，章节里面的关键活动之间的关系。
　　也就是说你研究方法看明白了，也就明白了作者输出本章节内容的思考过程。这也是我们经常强调的，实际上学习一个思考过程远远比简单输出一个解决方案架构更加重要。
　　比如下图，在进行平台架构愿景展开前，先给出研究思路。
　　从这个图可以很清楚的看到本章的关键输入，关键输出，和关键的一些标准规范依赖。看明白这个图基本也清楚了本章节的核心思考逻辑。
　　配合详细流程和集成分析去找寻问题
　　对于任何一个规划咨询项目，首先你是需要基于业务目标和IT目标去分析当前的现状，去找寻和诊断问题，其次才是考虑问题如何解决形成解决方案。
　　问题的找寻有粗有细，但是都需要有理有据，而对于埃森哲的方法论里面你可以看到最常用的两种找寻问题点的方法，即配合流程图去分析，或者是配合阶集成点去分析。
　　配合流程图分析往往可以找寻到组织岗位，角色，业务活动不合理的点。而配合集成点去分析往往容易发现当前端到端流程协同上的问题和断点。
　　对于流程分析找寻问题点，如下图：
　　通过该图可以详细的看到问题点在哪里，问题的描述，问题和整个业务流程和业务活动的关系究竟是如何的。也就是说自我论证清楚问题不是凭空产生的，而是基于企业实际的业务流程和业务场景分析得出的。
　　对于集成和交互图，可以用于分析具体集成上的问题点，如下图：
　　而这些具体问题点分析都将应用到后续的整体解决方案构图，集成架构规划等。同时你需要在最终的解决方案中论述，以上的这些问题点都通过新的架构规划解决掉了。从定性到定量的差距分析
　　在进行IT规划的现状诊断分析过程中，为何差距分析如此重要？
　　因为差距分析本身就体现了问题和目标驱动的核心思想，问题即目标和现状之间的差距，而差距分析正好是分析当前的现状和目标之间的距离。
　　差距分析本身有很多类型，比如：业务现状和业务目标之间的差距分析IT现状和业务目标之间的差距分析IT现状和业界标准和标杆对比的差距分析
　　所有的差距分析最终都是为了找到具体需要解决或改进的问题点，并将这些问题点进行整合后形成一个完整的解决方案。
　　差距分析分为定性分析和定量分析。
　　对于定性差距分析一般是通过对一线的业务人员或技术人员进行现场访谈或者通过调查表调研的方式进行问题收集和整理。因此定性差距分析一般也仅仅是从业务，技术，管理，效率等大的维度方法进行初步的问题收集和整理即可。如下图：
　　但是简单的定性分析往往很难评估问题的严重程度或影响面等，因此当前规划咨询更多的会引入定量差距分析的方法。
　　定量分析简单来说类似结构化决策的思路，即需要基于当前分析的问题，首先基于业界标准或最佳实践制定科学的维度，同时基于不同的维度和量化原则进行评分。在量化评估后更加容易分析具体的业务场景和问题点究竟在哪里。
　　比如你原来的问题是业务系统高峰期响应缓慢，而最终的量化评估结果则是涉及到月结的业务系统在月末到月初20天左右实际系统响应时长平均增长30以上，CPU平均负荷超过80。
　　当有了这些量化的数据后，我们更加容易进行有针对性的解决方案制定。
　　比如在进行应用架构的量化评估中，可以从重用度，成熟度，完备性，集成性等多个维度进行量化评估后打分，最后再进行加权评估。
　　在完成所有业务系统的定量分析后，最终形成一个定量评估结果。
　　学业务流程分析和建模方法
　　在前面谈到了IT咨询规划核心还是业务驱动IT，从业务流程调研和分析入手，那么对业务流程的调研就需要形成完整的流程分析和调研方法论。
　　而这块当前用的最多的还是ARIS的流程建模思路。
　　就埃森哲的咨询规划报告来看，对于业务流程建模框架是比较完整的，基于完全基于ARIS的思路，同时对于流程分析和调研的分层，各层输出也是相当细化的。
　　业务流程（BP，BusinessProcess）是为达到特定的价值目标而由不同的人系统分别共同完成的一系列活动；业务流程应该包含流程流程活动相关的组织、角色、事件、功能、输入、输入等所有元素。
　　如果单独对业务活动进行分析如下：
　　当把要给完整的业务流程分析清楚后可以看到核心的业务功能操作，业务对象，岗位角色，工具技术支撑等内容全部也就分析清楚了。而这些也正是后续进行业务架构规划，应用架构规划的基础。
　　当我们去分析跨业务域，跨部门的业务流程协同的时候，又可以看到具体的协同边界点，而这个正好又是后续进行应用集成架构梳理和分析的基础。
　　业务流程建模分级
　　业务流程建模本身是从企业价值链和端到端流程分析展开的一个完整自顶向下的过程。从最底层的价值链分析，到二级三级流程，再到最底层的EPC事件流程图，以形成一个完整的业务流程建模框架，整体框架分级如下：
　　到了最底层的EPC流程链，基本可以和应用系统功能实现中的软件需求和用例建模匹配。
　　比如对于最底层的EPC事件流程图可以到很细化的颗粒度。
　　包括在进行流程建模后，基于流程输出进行跨组织，跨省的流程差异对比和分析，如下图：
　　而这个差异分析本身也是找寻问题点，并优化和整合出一个最终流程的基础。也正是这个原因可以看到流程建模，流程梳理和优化是一个相当细化的工作。
　　形成AsIs到ToBe的流程梳理
　　当进行详细的流程分析和建模的时候，就容易看到具体的流程断点，岗位职责不清晰的地方等，而这些整合式需要优化和改进的点。
　　包括最终的业务解决方案或系统解决方案的形成，往往也可以依托流程梳理和分析进行。让最终的读者更加容易清楚的看到具体的改进点在哪里？对日常业务流程有哪些优化和影响。
　　也正是这个原因，我们一直在强调，任何改进点，任何解决方案都不是凭空产生的，更加不能简单的照搬业界标准或最佳实践。而是应该真正从企业当前业务目标，流程现状出发，去梳理和分析流程，去评估差距，然后找到最适合企业的解决方案。
　　类似当前企业数字化转型过程中，你去参考别人企业的方案构建自己的业务中台或数据中台，最终都是水土不服，无法真正发挥中台的价值和作用。学习IT治理管控模型
　　在前面谈到埃森哲的IT战略规划，实际上里面有一层的内容即IT治理管控框架体系的构建。管控治理是进行IT咨询规划中相当重要的一个内容内容。直接影响到你最终的解决方案是否能够最终落地实施。
　　埃森哲给出过一个完整的管控治理框架如下：
　　从这个图可以看到管控框架覆盖了工具技术支撑，组织，流程，业务，运营，人员等多个方面的内容。这个也是构建一个完整的管控能力框架的基础。
　　任何一个完整的管控模型你都可以看到，首先就是要确定组织，流程，工具支撑，接着才是基于具体的业务域，业务系统的内容，基于生命周期展开的思路制定具体的管控点。比如埃森哲给出的主数据管控能力框架如下：
　　其外围是组织，流程，工具技术，而里面则是覆盖主数据域的具体管控内容。
　　当然一个完整的管控治理模型本身也可以按照业务，技术，组织三个维度来进行分解，然后基于动态的生命周期展开形成一个完整的管控体系，如下：
　　这张二维矩阵式的方式可以从静态分层和动态生命周期两个维度的详细分解具体的管控内容。值得所有的管控框架构图参考。比如我在做SOA规划建设项目的时候，整理的SOA治理管控框架体系图基本也是参考该方法形成。
　　包括我在前面整理云原生的管控治理框架的时候，仍然采用这张方式构图。