|
很多介绍业务架构的文章都会说“业务架构是战略到执行的桥梁”，那么业务架构到底是如何在战略到执行的过程中发挥作用的呢？ BIZBOK中定义了一条战略到执行的路径（见图1），分为5个阶段：澄清战略、评估业务影响、构架业务解决方案、制定项目计划、实施解决方案。 图1：战略到执行的路径
上述5个阶段是把战略逐步转化为可执行的项目和解决方案的过程。业务架构在每个阶段都可以发挥作用，但其价值却是从左到右递减的，因为很多问题到了项目执行阶段才发现就很难解决了，应该尽可能在项目规划中就进行规避。BIZBOK鼓励业务架构从业人员花更多的时间在左边的2-3个阶段，也就是要“往前走”。 回顾过去几年的工作，绝大多数时候我们都是在右边的阶段4和5中开展业务架构的。例如：某项目要开发一套IT系统，我们就专门为这个项目设计一套业务架构；某个业务领域要开展数字化转型，我们就专门为这个领域设计一套业务架构。输出件无非是几页PPT，给领导们汇报之后就被束之高阁。业务也好、IT也罢，都不会因为那几页PPT而发生任何变化。显然这跟BIZBOK倡导的“往前走”存在差异，那怎样做才能“往前走”呢？ 2019年6月，我前往荷兰参加BAGuild大会，会上的一个演练环节让我找到了答案： 引导员给每个人发了一张一页纸的案例，描述了一家数据分析公司X，他们跟不同的合作伙伴签订协议，从伙伴处获取数据，并根据客户的诉求进行数据加工，从而为客户提供加工后的信息。问题在于，X公司跟不同伙伴签订的协议条款不同，甚至跟同一个伙伴签订的不同协议的条款也不同，在使用这些数据时，X公司经常无法判断哪些数据只能引用、哪些数据可以被二次加工，导致X公司面临来自伙伴和客户的各种挑战。管理者希望成立一个IT项目，尽快解决这个问题。 引导员要求每个小组进行2轮研讨：第一轮研讨不要使用业务架构方法，用自己最熟悉的方式制定项目计划；第二轮则必须使用业务架构方法，进行影响评估，并制定项目计划。 在第一轮研讨时，我并没有意识到用或不用业务架构方法有什么区别。按照我们惯常的做法，既然业务问题已经说清楚了，接下来就应该分析存在哪几种业务场景（如：只能引用数据的场景、可以进行数据二次加工的场景），细化每个场景的业务流程，并在流程图上标识问题点，针对每个问题点设计解决方案。在此基础上，我还炮制了一个项目计划，一共4个里程碑，M1完成现状和问题分析，M2完成解决方案开发，M3完成试点，M4正式上线。第一轮研讨结束时，我自信满满地代表我们小组进行了发表。 第二轮研讨开始时，引导员给每个小组发了一页参考材料，上面画了3条价值流，一条是“签订合同价值流”、一条是“处理数据价值流”，还有一条“信息管理价值流”，每个价值流阶段下还分别匹配了一些业务能力。他要求每个小组基于这些价值流和业务能力开展影响评估并制定项目计划，并对比第一轮的结果，谈谈自己的体会。 在呆坐了20分钟之后，我终于意识到，他所说的“用业务架构方法”其实是指基于业务架构的价值流、业务能力，以及二者之间的mapping关系，对企业面临的问题进行影响分析和优先级排序，识别哪些价值流阶段、哪些业务能力对解决问题最重要、或差距最大，并以此为依据制订项目计划。 对比这两轮研讨，我终于认识到，所谓“往前走”，其实是要用价值流和业务能力对战略进行影响分析，也就是把战略放到整个企业这一复杂系统中，进行更全面的影响评估，找到真正的问题所在。只有把问题识别清楚，才能制订出全面的业务解决方案，确保战略执行的结果符合预期。在第一轮研讨中，我的问题在于一头扎入问题的细节，放弃了对问题本身的思考。这就好像去医院看病，病人说头疼，医生就给开感冒药，万一头疼的原因不是感冒，而是其他问题导致的怎么办？在没有对问题进行全面的影响分析之前，就不断向下挖掘，会让我们而丧失全局视角、陷入细节，变成只会“头痛医头，脚痛医脚”的庸医。 2. 演练不算数，有成功案例吗？ 也许你会说，上面的例子只是个演练，现实中真的有企业这样做吗？在BA Guild网站上能够找到一些案例，这里摘取其中2个做简要介绍。 2.1 USPTO案例Paula Mihalek曾代表US Patent and Trademark Office（USPTO）在2015年的BA GuildInnovation Summit上分享了他们基于业务架构开展影响分析和项目规划的案例。2013年，为了应对商标、专利申请量的快速增长，USPTO启动了TMNG（Trademark Next Generation）项目，并采用业务架构方法进行影响分析、项目规划和优先级排序。 首先，他们在整个USPTO层面梳理了20多条价值流、19个L1能力、100多个L2能力。 图2：USPTO价值流 图3：USPTO业务能力 然后，他们在价值流层面进行影响分析，发现“Register Trademark”和“Allow Statement Of Use”这两条价值流中，都有一个Examine阶段，即ExamineApplication和Examine SOU，这两个阶段对商标申请的效率影响最大。于是，这两个价值流阶段就构成了TMNG项目的第一个Release。 图4：USPTORelease规划 第三，他们在这两个关键价值流阶段下匹配上了业务能力。在不同价值流阶段下重复出现的业务能力被视为“可重用”能力。重用次数越多的能力，在项目计划中越应该尽早实现。例如“Agreement Terms Management”是一个业务能力，在ExamineApplication和Examine SOU阶段中都会用到这个能力，这个能力对应的IT解决方案实现后，将会在其他价值流阶段中不断被重用。 TMNG项目持续5年，从第一年整个项目组围绕1个Release进行开发，到第四年6个Release同步开发，就是因为前期开发的解决方案不断地在其他价值流阶段重用，使项目组有能力在项目后期“越跑越快”。 2.2 FedEx案例Cari Brose和Jeff Green曾代表FedEx在2017年的Business Architecture Innovation Summit上分享了他们基于业务架构开展项目规划的案例。 当时，FedEx有一个战略是“提升运输全生命周期的可视化程度”，与之对应的目标是“标准化并优化运输规则的管理和执行”。 首先，他们在价值流层面进行影响分析，发现主要涉及Send Shipment价值流。 然后，他们为每个价值流阶段匹配业务能力，并从中识别对实现战略目标最重要、且差距最大的业务能力。经过分析，他们发现Shipment Information Management下的Shipment State RuleManagement是关键能力。于是，就会规划一个业务解决方案，负责优化这个能力对应的组织、流程、数据、IT等资源。 图5：FedEx案例 3. 当心！对方想要的并不是业务架构，而是一套解决方案10年前曾经追过一部美剧《豪斯医生》，讲的是一个脾气古怪的医生老头，无论什么样的疑难杂症，到他手里总是能找对病因，药到病除。他从不跟病人讨论病情，却总能找到那些连病人自己都忽略的问题；他腿上有旧伤，走路都要拄拐，从不亲自做手术，只做诊断。在他的头脑里，早已构建起“人”这个复杂系统的一整套结构图，他诊断的过程就是不断地把各种症状放在那套结构图上进行影响分析的过程。经过严密的逻辑推理，给出适当的治疗方案。病人并不知道豪斯医生是如何得出治疗方案的，即使他愿意解释，病人也未必听得懂。在这个故事里，豪斯医生就相当于业务架构师，他脑子里的那套人体结构图就相当于业务架构，而他给不同病人开出的治疗方案就是业务解决方案。 大部分情况下，当有人说“请为xx项目设计一套业务架构”时，他需要的可能并不是业务架构，而是一套解决方案。或者，说的更直接一点，他只想知道如何解决自己面临的具体问题！其实，大部分对项目结果负责的人并不需要业务架构，只有那些真正关心战略是否能有效落地的人才需要业务架构。对他们来说，最重要的是找到正确的问题，问题本身比任何解决方案都更重要！业务架构能够帮助他们找到正确的问题。 参考材料：
USPTO案例来源：LeveragingBusiness Architecture for Business Requirements Management https://www./cgi-bin/doc?basig/2015-03-06 |
|
|
