★ FEATURED ARTICLE 简介这份埃森哲IT规划咨询方法论文档适合IT咨询顾问、解决方案架构师及企业IT规划人员阅读用于建立从业务目标到技术落地的系统化分析框架。文档完整梳理了埃森哲方法论的核心理念以业务驱动IT通过金字塔原理进行结构化拆解并围绕问题分解、粗粒度整合、归纳到演绎反转三个阶段展开针对静态架构图的分层逻辑、多维度框架思维以及定性到定量的差距分析均有具体说明也涵盖配合流程图与集成点分析寻找问题的方法。文档中关于研究方法动态图的说明可帮助读者看清章节间承上启下的逻辑对打造符合金字塔原理的解决方案结构尤其有参考价值。资源包共1个文件为docx格式压缩包大小约1.16MB。已有370人学习下载适合希望借鉴头部咨询公司方法论、提升解决方案制作能力的学习者。1. 为什么你做过那么多IT规划最后全都堆在柜子里吃灰“IT规划咨询方法论”这几个字前几年总跟着一份某国际咨询机构传出来的文档一起出现被当成数字化转型立项的模板来用。它解决的问题不是“上什么系统”而是“为什么上、先上什么、上完之后业务怎么变”。适合三类人企业里牵头做IT规划的负责人、帮企业做规划的咨询顾问、写售前方案但总觉得逻辑不严的人。这套方法论真正的价值在于把规划从“报菜名式项目清单”变成一条完整推导链业务战略到业务能力业务能力到应用系统应用系统到数据和技术最后落到投资与节奏。2. 这套方法论到底在讲什么五阶段模型与三张核心视图表面看它是一堆模板和表格实际是一条决策链。IT规划最怕的不是方案不够先进而是结论没有推导过程。五阶段模型的价值就在于强制顺序每一步都要回答一个明确的问题答不上来就停下来。2.1 五阶段模型从战略对齐到落地支撑的完整链条我把这套方法论的骨架理解为五个阶段每个阶段对应一个核心问题阶段要回答的问题关键活动主要交付物战略对齐业务要去哪IT要支撑什么高层访谈、业务战略解读、行业对标业务与IT对齐报告现状诊断现在有哪些系统能力差在哪系统盘点、访谈问卷、问题梳理现状诊断报告目标蓝图未来应该长成什么样蓝图设计、四层架构、治理设计目标蓝图与架构说明差距与路线差距在哪先做什么后做什么差距分析、项目群定义、优先级排序实施路线图与投资估算落地支撑过程怎么管标准怎么定治理落位、项目管理、规范编制落地管控方案五个阶段不能跳也不能倒。我见过不少规划项目为了赶进度把现状诊断阶段压到两周只访谈几个人就去画目标蓝图结果方案跟现状完全脱离。常见做法是先花三到四周做盘点和访谈再用两三周做诊断分析然后才进入设计。顺序只要倒了后面的结论全都是飘的。当然不是所有项目都要五阶段全走一遍。几十人规模的子公司可以把前三个阶段合并用两周做完但“先摸现状再谈目标”这个顺序不能省。省掉的阶段迟早会在评审会上以“这个项目我们还没想清楚”的方式还回来。2.2 三张核心视图现状视图、目标视图、差距视图怎么写三张视图是整个方法论里最容易被低估的工具。它们不是一个“过去、现在、未来”的名词包装而是三种完全不同的表达方式。现状视图回答“我们现在是什么”。它把应用系统、业务流程、数据流向、IT组织和治理现状叠在同一张图或一套图里看。画这张图最容易犯的错是把它画成网络拓扑全是服务器、防火墙、链路。正确的画法是以业务流程为主线标出每个环节由哪个系统支撑、哪些数据在系统间流转、哪些环节还靠手工。业务人员要能在这张图里认出自己的日常工作。目标视图回答“未来是什么”。这张图画的是目标业务能力、目标应用群、数据架构和治理模式。它表达的是“应该”不是“现状”。目标视图里的每个框都应该是从战略和差距推导出来的不是设计者凭空想象的。我给自己定过一个习惯画了一个框就要能说清楚它对应哪个业务能力、解决哪个现状痛点。说不清的框先拿掉。差距视图把前两张叠在一起逐项标注差距。差距不是简单画个箭头要编号、要标优先级、要写影响范围。这张图是高管和IT部门之间最好的沟通界面高管看方向IT看工作量。差距视图里的每一项都应该能对应到后面路线图里的一个项目否则这个差距就是纯描述不构成规划。2.3 先业务后技术这条推导链为什么不能倒过来整套方法论背后只有一条推导链业务战略推导业务能力业务能力推导流程与组织流程与组织推导应用系统应用系统推导数据需求数据需求推导技术选型最后才是实施路线和投资。链路顺序不能变因为每一步都要消耗上一步的结论。为什么不能反过来先定技术因为技术选型一旦前置后面所有工作都变成给决定找理由。比如规划刚启动管理层就说“我们要建数据平台”于是团队把大量时间花在论证平台架构上业务侧的流程断点、数据责任归属反而没人认真查。等到蓝图阶段发现业务的真实瓶颈是主数据混乱但平台方案已经写进立项书只好硬着头皮推下去。边界在哪里不是不选技术而是把技术选型放到蓝图阶段的后期。规划里可以写平台能力要求比如实时性、弹性、容灾标准但具体产品留到项目设计阶段去比选。还有个常见的误用把这条链理解成直线做完一遍就交差。实际它是个环落地过程中反馈出来的问题会回到战略层形成滚动规划。只有把“规划—建设—反馈—再规划”这个循环跑起来方法论才算真正落地。3. 把As-Is摸清楚访谈提纲、系统盘点和业务能力地图现状阶段做扎实规划就成功了一半。所谓扎实不是指文档厚而是每一条结论都有人可以追是谁说的、在哪个场景说的、有没有证据。第2章的框架再完整如果现状输入是错的后面所有推导都会跟着歪。3.1 访谈提纲三层设计高层、中层、一线各问什么访谈是收集事实的主要手段但访谈不是聊天是用一小时验证一组假设。我一般把访谈对象分三层每层问的问题边界完全不同访谈对象建议时长核心关注点代表性问题方向高管层30分钟以内业务战略、经营压力、对IT的抱怨未来两年业务重点是什么哪些事情因为IT太太慢做不成业务中层45到60分钟流程现状、系统支撑度、数据可用性你日常决策最缺哪块数据上一个系统为什么没用起来一线操作15到30分钟操作效率、重复劳动、系统体验哪些环节靠手工和电子表格哪些信息要跨几个系统才能拿到访谈配比我一般按高管、中层、一线约1:5:3来安排。一个中型集团做规划访谈人次到三五十是正常的问卷作为补充手段再收一两百份。中层的信息密度最高他们既懂业务细节又知道系统怎么用要留足时间。高层的半小时里不要问操作层问题问多了也答不准还浪费了最贵的访谈资源。每场访谈结束当天必须整理记录记三件事发现了什么问题、有什么证据、是谁说的。这里面有个提问技巧就是不要问引导性问题。想问系统是不是慢不要直接问“你们的系统是不是很慢”改成“在哪些环节等待时间最长”。前者得到的是附和后者得到的是事实差距很大。3.2 系统盘点表一张电子表格把现状变成资产地图访谈是人的视角系统盘点表是机器的视角。规划项目至少要把核心业务系统全部过一遍字段设计比数量重要。字段填写说明系统名称全称加简称业务部门主要使用部门不唯一时列前两个覆盖流程对应业务能力地图里的哪几项能力用户数量活跃用户数不要写注册数使用状态在用、半闲置、待退役三选一上线时间按业务实际使用时间算主要供应商开发方和运维方分开写部署方式本地机房、云托管、混合部署集成对象上下游系统与接口方式年运维成本尽量取上一年的实际发生数问题备注卡顿、重复录入、数据不一致等这张表最常被漏掉的是集成对象。很多人只填系统自身信息不填接口关系等画目标蓝图时发现链路根本对不上又要返工补访谈。盘点过程中一定会遇到“无人认领系统”——不知道谁在用、没有负责人、业务部门说没见过。这种系统单独标记不要直接并进现状视图先弄清使用情况再说。为了防止盘点变成填表游戏我会要求每个系统至少要有一名IT人员和一名业务人员双重确认。系统清单确认后再用三色状态标一遍正常、半闲置、待退役。这张表后面既是差距分析的输入也是投资测算里“哪些系统要改造、哪些要替换”的依据。3.3 业务能力地图用一张矩阵给系统覆盖度打分业务能力地图是把访谈和盘点结果合成一张图的关键工具。先分层再评估L1是业务域比如营销、供应链、生产、财务L2是业务能力比如营销域下面有客户管理、线索管理、活动管理L3是更细的流程一般画到L2就够规划用了。每个L2能力都要评估系统的支撑情况打四档充分支撑、部分支撑、缺失、存在但未用。注意最后这一档“存在但未用”最容易引发讨论它代表企业买了系统但业务没接纳这是个管理问题不是技术问题。业务域L2能力对应系统支撑档位备注营销客户管理某客户管理系统充分支撑功能够数据质量待提升供应链需求预测靠电子表格缺失无专用系统高层强烈关注供应链渠道库存可视某ERP中的模块部分支撑经销商数据靠邮件汇总这张矩阵做完现状阶段的基本素材就齐了。后面画目标蓝图时蓝色部分代表要建新系统或选型黄色部分代表要优化推广绿色部分代表保持加强。常见误用是把“系统覆盖度”当成“业务能力成熟度”这两者不是一回事系统覆盖度高不等于业务能力强也可能只是业务在低水平上被系统化了。评估的时候要分开打分避免自欺欺人。4. 从As-Is到To-Be差距分析、四层架构与治理落位现状摸完下一步是把“现在”翻译成“目标”。这个翻译过程最容易出问题要么差距写得像流水账要么架构画得像技术选型书。第4章把翻译动作拆成三段每一段都有明确的输出物和验收标准。4.1 差距分析两种写法问题清单与能力差距矩阵调研结束后手里的素材是大量问题和事实这时候要分两步走。第一步整理成问题清单第二步转换成能力差距矩阵。问题清单是论据差距矩阵是结论两者不能混着用。问题清单的字段至少要包含编号、问题描述、业务影响、证据出处、严重度、初步改进方向。严重度用高、中、低三档不要搞五档三档足够决策。每条问题都要能指出处某次访谈记录、某张盘点表、某份财务报表都算。没有出处的问题视为没有证据。能力差距矩阵把问题升级成决策语言业务能力现状评分目标评分差距优先级需求预测143高渠道库存可视242高财务结账341中评分用1到5现状评分来自调研判断目标评分来自业务战略和标杆对标。差距是两者之差优先级再由战略匹配度和业务影响修正。汇报时主文档只放矩阵问题清单放附录备查。还有一种写法是把问题清单全部堆到胶片上十几页都是抱怨听众记不住评审结论自然难产。这里有个边界要注意差距不等于缺系统。有些差距是流程问题有些是数据问题有些是组织责任问题。直接跳成“所以要买一套系统”是规划里最常见的偷懒行为。判断标准很简单如果这个差距通过调整流程和职责就能解决就不应该出现在采购清单里。4.2 四层目标架构业务、应用、数据、技术各画什么目标蓝图的核心是四层架构四层各有各的回答和评审人。架构层回答什么问题主要产出评审人业务架构业务流程与组织怎么设计业务能力总图、流程框架业务部门负责人应用架构用哪些系统支撑业务能力应用全景图、系统群边界、集成关系IT与应用负责人数据架构数据放哪、谁负责、怎么流转数据域、主数据清单、数据流向图数据负责人技术架构用什么平台承载运行部署形态、平台能力、安全与容灾技术负责人业务架构这一层不要出现系统名。它只表达业务能力和流程是所有后续架构的依据。如果业务架构画不清楚后面三层画得再漂亮也是无根之木。我见过不少团队跳过业务架构直接画应用拓扑结果系统边界随设想跑评审时业务方完全不认账。应用架构要画的是系统群而不是单个系统。比如客户管理、订单管理、合同管理可以归到某个业务系统群共享一套用户和权限体系。集成关系是这一层最容易忽略的画的时候至少要标注接口的实时性要求是同步还是异步、是批量还是实时。不标清楚后面的技术架构没法做容量和性能设计。数据架构要确认三件事数据域怎么划分、主数据归谁管、数据在系统间怎么流转。主数据没有责任部门数据治理就是空话。技术架构层我不推荐写具体产品名写平台能力要求就够了比如容器化、弹性扩展、统一身份认证、异地容灾。产品选型留到项目设计阶段规划阶段过早写死产品后面只能为这个决定打补丁。4.3 IT治理与管控模式蓝图上最容易一笔带过的部分四层架构画完很多规划就算结束了实际上还差最后一块治理。蓝图定义“未来长什么样”治理定义“未来由谁建、谁管、谁拍板”。没有治理的蓝图落地时每个决策都要吵一轮。治理设计从一张决策权矩阵开始。常用的是RACI思路R负责执行A最终拍板C被咨询I被告知。一个简化的IT决策矩阵长这样决策事项IT规划系统建设运维变更预算审批集团IT中心A/RAA/RA子公司ITCRRC业务部门CC/IIC矩阵做出来之后对应IT组织建议常见分三层规划层负责蓝图和标准建设层负责项目交付运维层负责日常运营。小规模组织可以一人兼多角但职责边界必须写清楚。规划里不要把治理写成一整套制度业务流程今天先立三条主流程需求申请与评审、项目群管理、变更与运维。三条流程跑通再逐步加。治理设计里还有个容易踩的坑是“有流程没负责人”。写了流程但没指到岗位等于没写。每条流程至少要有一个OwnerOwner不一定是执行者但他要对这条流程的运转结果负责。这是规划和落地之间衔接最紧的一环。5. 避坑IT规划项目最容易翻车的五个环节前面所有环节都做对了规划也不一定顺利。但以下五个环节只要踩中一个前面功夫大概率白费。这些坑和工具、模板无关全是习惯问题。5.1 蓝图做成技术方案业务方全程“听不懂”现象评审会上业务高管看着十几页网络架构、中间件、部署拓扑图终于开口问了一句这张图告诉我业务会有什么变化会场安静了三秒。原因设计人员的注意力全在技术上用技术架构图替代了业务蓝图没有先回答业务侧最关心的问题。解决出图顺序调整为业务架构、应用架构、技术架构。每一页架构图标题位置写清楚它支撑了哪个业务能力、解决了哪个断点。找不到对应业务价值的图不要放进主文档放进附录当支撑材料不丢人。5.2 现状调研只访谈IT部门业务需求全靠猜现象蓝图初稿给业务部门看对方翻了翻说“这不是我们的真实痛点”。回去查调研记录访谈名单里大半是IT人员。原因约IT人员省事约业务中层要协调时间潜意识里默认IT最了解系统问题。但系统好不好用业务侧说了才算数。解决访谈和问卷里面向业务人员的比例不低于七成这个比例在计划阶段就写死。访谈提纲先给业务高层过一遍校准方向。最终每条痛点都必须能追溯到具体角色和部门追不到的一律不算数。5.3 路线图项目排得密密麻麻先上哪个说不清现象路线图几十个项目排到第三期被问到“为什么这个项目排第一期”回答是“因为这个是基础”。继续追问基础是什么没了后续。原因期次安排没有统一排序标准凭系统模块的直观先后顺序拍而不是按业务价值和依赖关系排。解决先用打分维度给候选项目排序常用维度有战略匹配度、业务收益、实施风险、紧迫程度、资源可用性。打完分再过一遍依赖关系凡是“系统A不上系统B就没办法开始”的依赖关系优先于分数。最终的期次表让业务高管确认一轮业务收益的权重本来就是业务判断不是技术判断。5.4 投资测算拍脑袋只有一个总额现象财务要求拆分到项目级问“这个数字的依据是什么”答不上来。最后只能按项目数量把总额几分凑出一张明细。原因投资测算是规划收尾前两天突击出来的没有测算模型也没有写清楚假设边界。解决投资测算按两个口径分开列一次性建设费用和年度运维费用。运维费用建议按建设投资比例加绝对值修正同时给出低、中、高三档区间不要报一个看起来精确其实站不住的数字。测算表前面单列一节写假设覆盖范围、用户规模、系统数量、云化比例、实施方式是自建还是外购。没有假设的测算就是拍脑袋这条写进测算模板第一行。5.5 交付文档厚得像词典核心逻辑一页讲不清现象汇报约定一小时前四十分钟还在讲调研方法核心结论来不及展开决策被延期到下一轮。原因交付团队怕内容不够全面被挑刺把过程材料全堆进正文文档成了资料汇编不是决策材料。解决每个主文档的第一页固定放“核心判断与建议”三到五条结论加依据写在最前面。访谈记录、盘点明细、评分表全部进附录。汇报时按核心判断讲不按文档目录讲。文档是备查用的汇报才是决策场景两个场景不要混在同一套结构里。6. 一份规划合不合格用三张图就能验证我判断一份IT规划能不能进入立项阶段方法很简单不看厚度只看三张图能不能讲明白。第一张是业务价值连接图。这张图把“业务痛点、IT投入、业务收益”画在一条线上每一个规划项目都要能写出一句清晰的话比如预测准确率低导致库存积压建设数据平台预测偏差从百分之十几降到个位数。这句话写不出来的项目不应该出现在路线图里因为它没想清楚为什么做。第二张是目标架构全景图。这张图要让业务和技术两个角色都能看懂业务人员能找到自己的流程和能力被哪些系统支撑技术人员能看到系统边界、集成关系和数据流。一般结构是中间放业务流程下面是应用群旁边是数据域不需要放技术拓扑。第三张是三年项目路线图。每个项目至少带四样信息工期、投资区间、依赖项目、里程碑。投资不要写死一个数标低中高三档区间。依赖关系用箭头标清。一个项目在这张图上缺信息说明它还没被定义清楚。验证技巧我习惯叫它三十分钟评审法请业务、财务、IT各一位负责人只给这三张图先看十五分钟然后回答三个问题。这张图和我的业务相关吗钱花在哪、为什么花第一个项目什么时候能看到效果答得上来规划可以推进立项答不上来文档再厚也要回去补。这个习惯是从一次教训里长出来的。那次的痛点就是问题清单堆了上百条决策层看完抓不住重点差点把一个低优先级的项目排到了第一期。从那以后我给自己定了一条规矩规划定稿前必须先用这三张图自己完整讲一遍讲不顺的地方就是逻辑没闭环的地方。架构文档可以写厚但呈给决策层的永远要能被三张图讲清楚。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
