TOGAF八步一法笔记2

1. 业务需求和验收标准

一旦方向确定，接下来的关键就是：创建业务需求、明确验收标准

当“预备阶段”完成，能力愿景和范围被管理层确认后，我们正式进入能力建设的“实施轨道”。而这个轨道的起点，是两个核心动作：

1. 创建真正的业务需求
2. 定义清晰的验收标准

这不是IT自己闭门造车，而是由业务部门主导提出、架构引导梳理、IT协同建模的过程。

信息化：企业做大的关键支撑手段

我们始终坚信：信息化，是企业在组织规模不变的前提下，实现“做大做强”的不可或缺的核心手段。为什么？
因为当企业的业务量、管理复杂度、地域分布、客户数量不断增长时，仅靠传统的手工流程、层级管控、经验决策，已经无法支撑高效运作。

我们靠什么突破瓶颈？

1.  靠系统打通流程
2.  靠数据驱动决策
3.  靠平台提升协同效率

这就是信息化的价值：需求旺盛从何而来？源于外部竞争压力下的能力焦虑

今天我们面临的需求“井喷”，不是偶然，也不是业务部门“瞎折腾”。
根本原因在于：
 外部竞争环境剧变，企业生存压力加剧，
 我们必须快速提升业务能力，否则就会被淘汰。

这是一个周期性的工作流程：每次做能力规划，都要完整走一遍“规划—建设—治理—调整战略”的循环。每个阶段都要独立验证，确保规划和落地都符合最初的需求。

在日常工作中，每个环节都离不开甘特图的辅助。最好让业务人员、架构团队一起参与进来，协同共创，用迭代的方式持续推进，让规划更贴合实际。

我们根据和业务沟通的频率来划分迭代。如果是一轮完整的规划+建设全部做完，才拿给业务方看：“你看，我做出来的这些东西，是你想要的吗？”——这种“最后才交付”的方式，叫“交大迭代”，也叫“大瀑布”。这种方式风险很高，基本等于“闭门造车”，现在很少用了，因为很容易做错、白干。

我们把工作分成几个关键阶段：规划、能力建设、评审与迭代。正确的做法是：在每个阶段开始和结束时都要评审（阶段之间必评审），确保方向正确；在阶段内部要加强协同（抓协同），让业务团队深度参与，边做边对齐，实现“共建共造”。

比如：规划时一起定目标，建设时一起跟进，而不是等到全部做完才给业务看。这种方式叫“分阶段迭代”，能及时发现问题，减少返工。

相反，如果只做一次大循环，到最后才交付和反馈，就会导致周期长、返工多、风险高，这种“大步快跑”的模式是不可取的。

总结：

阶段之间：必须评审（把关方向）

阶段内部：加强协同（业务与团队共建）

避免大周期迭代，提倡小步快跑、持续反馈，才能高效交付、少走弯路。

共识，必须通过正式决策流程来达成。真正的共识，体现在管理层的承诺上；而管理层的承诺，要以班子会议纪要的形式明确下来——只有上了会、纪要发布了，才算决策成立，才具备权威性。 重要前提：任何能力规划或组合调整，必须上班子会审议通过，预备阶段的意见不能替代正式决策。

正式决策后，需明确三个关键要素：

1. 范围（Scope）——“做什么”
   指的是“能力组合”的边界：我们到底要推动哪些核心能力建设？重点投入哪些领域？这是规划的前提。
2. 原则（Principles）——“怎么干”
   是我们倡导的做事文化和行为准则，例如：能力导向（以构建长期能力为核心）

业务驱动（从实际业务需求出发）、分工协同（跨部门协作，不各自为政）、统一架构（避免重复建设，保障系统一致性）这些原则必须写入会议纪要，作为后续工作的指导依据。

裁剪（Tailoring）——“灵活调整”，在统一原则下，允许根据实际情况对方法、流程或范围进行适度裁剪，但裁剪要有依据、有审批、有记录，不能随意跳过关键环节。

裁剪（Tailoring）——不是随意删减，而是有方法的适配裁剪，不是拍脑袋省步骤，而是在实际场景中，对方法、交付物、模型（视图） 进行合理调整。具体包括：

裁剪的前提是：你得先知道“标准是什么”，才能决定“怎么减”。所以，先写下来、学起来，一开始不熟没关系，随着实践深入，自然就掌握了。

治理（Governance）——真正的“准入门槛”，比裁剪更重要的，是治理。
也就是说：谁来管？怎么控？有没有权威机制？

必须通过信息职能（如IT部门、架构委员会）建立架构管控机制。要有明确的治理架构和治理结构：谁审批、谁执行、谁监督。所有能力建设、架构变更，都要在这个体系下进行评审和放行。如果没有治理结构，就等于“没驾照上路”，再好的规划也落地不了。

如果信息部门只是“服务中心”，只负责扛着企业顶层设计，却没有实权，只能引导、不能管控，别人跟不跟你走、用不用你的架构、遵不遵从标准，都无所谓——那你还搞什么顶层设计？根本落不了地。所以，我们必须在治理结构上赋予信息部门真正的权力。

这个权力不是为了管人，而是为了做到：讲规范、守诚信、重公正、行有道。你想，一个“引导者”如果没有权力，光靠“专业魅力”去推动变革，能成吗？  嘴上说“我懂技术、我有远见”，就能让业务部门听话？  从来不行！历史上从来没有靠“魅力”把信息化管好的企业。

专业能力是基础，但没有治理权力，就无法形成约束，无法确保统一，无法杜绝重复建设。

所以，必须明确：

1.  信息部门不只是服务者，更是架构管控的责任主体
2.  要有审批权、评审权、标准制定权和监督权
3.  所有重大系统建设，必须通过架构评审，否则不批预算、不上线

这才是“企业架构治理”的底线：  有责，就必须有权；有权，才能控得住。否则，一切顶层设计，都是纸上谈兵。别扯发挥魅力作用，只能发挥权力的作用，说明一个控制者你最起码得有判决权，不因此你看这里面控制就解决了信息部门、业务部门什么关系？在业务能力建设上解决裁判信息部门、业务部门是什么？球员这个思维你必须得转转不过来你就别玩。可以说转不过来的企业就用企业架构做了技术架构规划。继续玩转过来的企业，才是真正去玩面向能力，以能力为导向的这种发展行动。

好了，一个导向，三个要素，一个位置。记牢了131，这是理解预备阶段的131。这个时候，关于所谓为了这个131的事儿，其实就是你企业教师做领导层访谈。

 “131”模型：理解预备阶段的核心框架，记住一个口诀：“1个导向、3个要素、1个位置”——简称“131”

1个导向：业务驱动、能力导向（一切为了业务价值）

3个要素：范围、原则、裁剪（前文已讲）

1个位置：治理结构（信息部门要有管控权）

 “131”是预备阶段的纲领，所有准备工作都要围绕它展开。

 预备阶段的关键动作：领导层访谈

所谓“做131”，本质上就是企业架构师要开展高层领导访谈，目的是在正式立项前，统一思想、争取支持。

谁必须见？

在推动“重大数字化项目”前，必须与以下关键领导沟通：

董事长、总裁、常务副总、分管领导、（如有）党委书记

目标：一圈谈下来，能达成共识、明确范围、推动建立治理机制

两种后续路径，取决于访谈结果

路径一：共识已成 → 召开项目启动会

如果领导层基本认同，没有重大分歧 方法介绍后也无异议

 那就可以正式面向业主单位召开项目启动会，进入下一阶段

路径二：仍有阻力 → 推动高层汇报，借势推进

如果你发现个别领导有意见，或支持力度不够

但你觉得这事必须做、值得做那就推动一次面向全体高层或港务层（领导班子）的正式汇报

目的：不是说服一个人，而是公开亮出方案，看整体反应
结果判断：

如果多数认可 → 可形成集体决策，压制少数异议

即使有人保留意见，只要大局已定，也可推进

 总结：预备阶段的本质，不是写文档，而是“做共识”。

通过“131”框架引导高层对话，用访谈铺路，用汇报造势，最终实现：

有人拍板（决策）

有责可追（治理）

有据可依（原则与范围）

这才是企业架构能落地的前提：先赢人心，再推架构。

在推动重大变革时，如果方向明确、多数支持，哪怕有少数反对，也可以“少数服从多数”，果断推进——这是组织决策的基本原则，事情能定下来，就可以往前走。但如果多数领导层都反对，而你信息部门还硬要推，会有什么结果？不会有好果子吃！——项目注定落不了地。

为什么？因为落地靠“两个轮子”：

上面靠领导力，下面靠执行力

领导力：决定“要不要做”，提供资源、拍板决策、协调矛盾

执行力：决定“能不能做”，一线团队愿不愿意冲、有没有动力干

 如果领导层不支持，等于领导力缺位，那下面的执行力再强也“冲不起来”——没人愿意为一个没背书的项目拼命。

以 TOGAF 的 ADM（Architecture Development Method）为例，预备阶段（Phase A: Architecture Vision）的核心任务就是建立高层共识。

先与高层对话：不是问“你们要什么功能”，而是问：

企业未来3-5年的战略目标是什么？

当前最大的业务挑战和转型方向是什么？

哪些能力是必须构建的？

提炼架构愿景：将高层的战略语言转化为架构语言，例如：

“提升客户响应速度” → “构建以客户为中心的服务集成架构”

“推动全球化运营” → “建立多区域可扩展的数据治理框架”

用愿景引导需求挖掘：后续的部门调研，不是“收集需求”，而是“验证和细化愿景”，确保基层反馈服务于顶层设计

1. 业务架构的核心

就是打破“部门墙”和“层级链”，让流程围着客户转，实现跨部门、跨层级的“纵横贯通”。

1. 传统流程：以“职能”为中心 → “竖井式”流程

特点：每个部门只管自己那一段。

财务管报销，不管员工体验；

销售管签单，不管交付落地；

IT管系统稳定，不管业务快不快。

结果：流程被切成一段一段，客户要“求爷爷告奶奶”，跨部门沟通靠“感情”和“关系”。

形象比喻：像一条蛇被切成几段，每段自己扭，整体不动。

1. 新时期业务架构：以“客户”为中心 → “端到端”流程

您说的“以客户为中心”正是现代业务架构的灵魂。

核心问题转变：

不再是：“我们这个部门该做什么？”

而是：“客户从开始到结束，要经历什么？我们怎么让他爽？”

体现形式：跨阶段、跨角色

跨阶段：从“线索→商机→签约→交付→服务→复购”，全流程打通。

跨角色：涉及销售、售前、交付、客服、财务、法务……甚至高层审批。

在业务建模中，这些统称为 “参与者（Stakeholders/Actors）”，不管是平级协作还是上下审批，都是流程中的“角色”。

1. “纵横贯通”到底是什么？——业务架构的终极目标

纵横贯通 = 流程自动化 + 权责清晰化 + 数据实时化

1. 怎么做？三步塑造客户中心的业务架构

第一步：画“客户旅程地图”（Customer Journey Map）

找到核心客户类型（如：大客户、个人用户）

描绘他们从“动心→购买→使用→推荐”的全过程

标出痛点、断点、等待点

第二步：设计“端到端业务流程”（如使用BPMN）

用流程图展示：谁（角色）→ 在什么时候 → 做什么 → 输出什么

强调跨部门交互（消息、文档、系统调用）

示例：
客户下单 → 订单系统 → 库存检查 → 若缺货 → 自动触发采购流程 → 通知销售延迟 → 客户可选退款或等待

第三步：定义“业务能力”与“组织匹配”

提炼出支撑流程的关键能力：如“快速报价能力”、“敏捷交付能力”

明确这些能力由哪个部门/团队负责，是否需要新角色（如“客户成功经理”）

1. 架构落地

能分解、能分配、能分责，是业务架构能否落地的“生死线”。

业务架构与组织结构的关系：谁该听谁的？

您说的“业务架构决定了组织架构运输架构”——虽然表达生动，但意思精准：
业务流程是“货”，组织是“车”，车要为货服务，不能货去迁就破车。

 三、“三分”落地：流程出来了，怎么让人认账？

您说的“能够分工、能够分配、能够分责”，其实就是：

让每个部门看了新流程后，能说：“这事该我干，我认！”

但这很难，为什么？因为：老流程下，责任模糊，“三个和尚没水喝”

新流程要求跨部门协作，但考核还只看本部门KPI没有明确的“角色-活动”映射，干不干、干好干坏都说不清

 解决方案：建立“流程-组织-责任”三对应

只有做到这“三分”，流程才不是“纸上画画”，而是“责任落地”。

 四、现实难题：组织结构“不忧不改、不动不碰”怎么办？

很多企业：“组织结构千万别碰，就这样，基于现有组织做业务架构”——这是典型的“山上压流程”：山上有庙（现有部门），流程必须绕着庙走；明明该直路，偏要绕三圈，只为不“动部门”。

 应对策略：分两种情况处理

 高段位做法：先做“流程穿越演练”，让领导亲眼看到“因为部门墙，客户等了15天”，再提组织调整，成功率大增。

 五、业务架构怎么做？三步走 + 两个关键

 三步方法论：

参考对标（Learn），看同行、标杆企业怎么设计类似流程（如：华为的IPD、阿里客户中台）

不是照抄，而是“启发思路”建立基线与目标架构（As-Is vs To-Be）

基线架构：我们现在是怎么跑的？（现状流程）

目标架构：客户想要的、战略要求的流程应该什么样？

差距分析：从现状到目标，差在哪？卡点在哪？

识别BPR改造项（Bridge the Gap）

BPR = Business Process Reengineering（业务流程再造）

找出必须改的关键流程节点，如：

合同审批从7天压缩到1天

客户投诉响应从跨5个部门变为“首问负责”

业务架构的四个核心步骤（先记牢）：

业务梳理：识别关键业务事项

流程展现：还原业务流程（流程建模）

问题发现：诊断流程中的痛点与瓶颈

目标优化：提出改进方向与能力建设目标

口诀：梳流程、现流程、找问题、定优化

谁来做？角色分工要清晰

在整个过程中，必须坚持一个原则：业务驱动，业务主责。
企业架构师（或“企业教练”）的角色是引导者、协助者、推动者，而不是替代者。

企业架构师的五大作用：“焦点导评助”

记住五个字：焦、点、导、评、助

焦：聚焦关键能力主线（每条能力线单独推进）

点：点明问题，点出优化机会

导：引导业务团队自己梳理，不越位

评：评审流程合理性、一致性、可落地性

助：提供助手支持（如人手、工具、模板），但不是责任主体

强调：“助手”是帮忙，不是担责，如果业务部门说“人手不够”，你可以协调资源支持，但不能替他们做决策、写内容。一旦你变成“主笔”，就失去了业务驱动的意义

 如何开展？组织方式与方法

组织机制：每条能力主线，召集三类人参与：

主责部门（牵头）

相关部门（协同）

下属单位（执行层代表）

沟通方式：按阶段逐一访谈，提问引导：

“这个阶段，你们部门有没有参与？”
“涉及哪些业务事项？”
“输入是什么？输出是什么？谁审批？”

如何找“阶段”？

用价值流思维来划分业务阶段（如：需求→规划→建设→运营）

后续会详细讲“价值流建模”，先记住：阶段 = 价值流动的关键节点

在业务梳理初期，不同部门输出的内容质量不一、颗粒度不统一、详略程度不同，这没关系。
关键是要迈出第一步，让大家开始转变思维、走上这条路。

但必须坚持一个铁律：谁梳理，谁负责 —— 谁的孩子谁抱走，谁的苦恼谁承担。

也就是说：

如果是医药部门做的业务梳理，那就是医药部门的责任；

如果是国企、事业单位的某个业务处室梳理的，问题就归那个处室；

不能说“我随便写写”，然后让信息部门去“收拾烂摊子”。

因为后续的应用架构、数据架构、系统建设都要基于这份业务架构来设计。
如果源头是错的、空的、虚的，后面全都会走偏。

 所以要明确：业务架构是业务部门的责任，不是信息部门的“替罪羊”。

 举个真实例子：刘绍勇 —— 企业家推动变革的力量

刘绍勇，曾长期担任南航总裁，后来调任东航董事长。
他在南航期间，就大力推动企业架构建设；到东航后，又主导了东方航空的企业架构规划与能力建设。

他特别强调：以能力为中心的数字化转型。

我们今天能用手机买机票、电子登机、在线值机，要感谢像刘绍勇这样的企业家。
当年如果没有他推动电子客票系统的创新和能力建设，我们现在可能还要在大街上排队买纸质机票。这就是企业家的战略眼光和推动力的价值。

正确的做法应该是什么？

每年由业务部门主动开展业务梳理（如医药部门）

梳理成果（包括业务事项、流程、问题、优化目标）提交给信息部门

信息部门基于这些真实、责任明确的业务输入，统一开展：

企业架构规划

项目组合设计

数字化建设落地

总结：三句话记住核心理念

业务架构必须由业务主责，谁的孩子谁抱走

初期质量差不可怕，可怕的是没人真梳理、没人真负责真正的变革，离不开有远见的企业家引领方向,只有责任到位、业务真参与，企业架构才不是“空中楼阁”，而是支撑战略落地的坚实底座。