企业做数字化转型，常见的一幕是这样的：战略讲了，项目立了，预算批了，真到了需求、设计和建设阶段，大家却开始各说各话。业务部门从自己的职责出发提需求，产品线盯着自己的目标推进，IT 按系统边界拆功能，管理层看投入、回报和风险。每个人都很忙，也都觉得自己有道理。问题在于，客户、产品、协议、伙伴、资产、流程、系统、项目，这些东西并没有被放进同一套业务表达里。结果就是：项目互相重叠，关键能力没人负责，钱花在局部优化上，战略一路往下传，最后传成了另一个东西。这时候，企业缺的往往不是系统，也不是项目，而是一套共同理解业务的结构。
业务架构的价值，首先不是出图，更不是给 IT 多加一层包装。它最实际的作用，是把企业里那些分散、重复、口径不一的业务内容重新梳理出来，变成一套跨部门都能听懂、也能反复使用的业务语言。
因为企业真正稳定的东西，通常不是流程图，不是组织架构，也不是某个系统界面，而是它长期要做的那些事：管理客户、管理产品、管理协议、服务渠道、控制风险、维护伙伴、管理资产。这些才是企业运转的骨架。问题是，企业时间一长，这些骨架就会被切碎。一个客户，几个系统几种定义；一类产品，不同条线不同口径；同一个业务动作，换个部门就换一套流程。最后大家看到的都是碎片，看不到整体。业务架构做的，就是把这些碎片重新收回来。
业务架构喜欢讲能力，不是因为这个词高级，而是因为它够稳。能力说的是企业要做什么，先不急着争论怎么做。比如客户识别、产品管理、协议管理、渠道服务、风险控制，这些都可以作为能力来看。等能力讲清了，再去讨论流程怎么跑、组织怎么分工、系统怎么支撑、数据怎么治理。这一步如果省了，后面就很容易吵成一团。大家都说要提升客户体验，听上去像共识，实际上根本不是。有人想到界面优化，有人想到流程改造，有人想到客户主数据治理，还有人想到渠道整合。词是同一个词，脑子里装的完全不是一回事。能力地图的作用，就是把这些混乱的理解拉回到同一张桌子上：到底碰的是哪几项能力，哪几项能力需要增强，哪几项已经重复建设，哪几项到现在还没人负责。很多企业的问题，不是不会干，而是连自己到底在干什么都没说清。
战略通常很大，项目通常很小。大话和小活之间，最怕中间断掉。业务架构的价值，就在这条连接线上。一个靠谱的路径其实很朴素：先看战略意图，再识别受影响的业务能力，再分析这些能力的差距、依赖和优先级，最后才落到项目组合、路线图和方案范围。比如企业说，要从产品中心转向客户中心。听上去很对，但这句话本身没法指导建设。继续往下问，事情才开始变清楚：到底影响客户识别、客户洞察、客户权益、服务履约，还是渠道协同？这些能力现在由谁支撑？哪里重复建设？哪里责任不清？哪里会直接影响客户体验和合规风险？问题问到这一步，战略才算落地。否则，“客户中心”很容易变成一句正确但没用的话，最后落成几个页面改版、几项功能优化，再配一份看起来很努力的汇报材料。
大型组织做投资决策，最常见的两个坑，一个是重复建设，一个是价值说不清。这两个坑，业务架构都能照出来。它至少能看清四件事：项目是不是对着战略重点，几个项目是不是在改同一块能力，项目之间有没有前后依赖，钱是不是投到了最值得投的地方。如果一个项目连自己要提升哪项能力都说不明白，通常就说明两件事：要么它本来就没想清楚，要么它只是借着项目名义抢资源。这种情况并不少见。很多项目写得很热闹，技术方案也很丰满，但一落到业务能力上，立刻就空了。它说不清自己解决什么问题，也说不清自己和其他项目是什么关系。这样的项目，往往最容易花钱，最难见效。业务架构的价值，就在于它逼着组织把这些账提前算清楚。
业务架构要在组织里站住，不能总靠讲概念。管理者不关心你能力地图画得是不是漂亮，也不关心术语是不是标准。他们关心的是更现实的事：战略能不能落下去，跨部门的问题能不能讲明白，投资能不能少浪费，项目能不能更快出结果。所以，业务架构真正该卖的，不是“架构成果”，而是决策支持。
很多企业今天不缺战略，不缺项目，也不缺系统，甚至也不缺预算。真正缺的，是一套能把业务看清、把战略拆开、把项目接上、把投资放准的结构。业务架构如果做不到这一步，它就只是一个听起来很高级的词。做到了，它才算真的有用
转载自公众号-企业架构EA之家
