喻旭：业务架构数字化转型的方向盘

  在前面喻旭文章中，有人私信反对我“数转是业务牵头”的观点。因为他们公司数转就是IT牵头，业务人员在打酱油或者找“变革麻烦”！我懒得去争。

  我观点很明确，就是业务牵头，但观点适用于传统企业的数转。但不包括那些个技术驱动型公司（如：IT公司、网络公司、大数据公司、甚至部分信息密集型公司，如：银行、运营商）。

  这篇文章，我主要想回答，业务牵头的数字化转型，其抓手是什么？喻旭认为是“业务架构”，也就是EA(企业架构）里的BA(业务架构）。我在数转项目里或课程里，也重点推广BA，我觉得BA(业务架构）是数字时代的业务管理人员必备的知识能力。

  在喻旭前面文章《麻烦你！数字转型前，先明确数字化的价值主张/模式》里直接阐述了，企业数字化转型，要从两个方面切入：

  一是，企业侧，先做“价值主张、商业模式、流程变革”的创新，二是，用户侧，先研究用户旅程（痛点与期望），做“体验创新”再做数字化，说得直白就是“先人性化，再数字化”。

  在我另一篇文章里《数字化转型不能延续信息化的做法》强调数字化要以流程变革为核心，搭建面向客户价值的、端到端的、自适应流程。

  IT人员一直和业务人员沟通困难，大家用的不是同一种思维、事物定义、语言。

  如果业务牵头数字化转型，双方如何统一思维、定义、语言。业务架构（BA）便是抓手。

  先做个简单比方：下图中有3个关键对象。其中：1是现实世界、2是镜子中的虚拟世界，3是虚拟映射现实的这面“镜子”。

  那么，在真实的生活中，什么扮演这个“镜子”呢？我引入“架构”的概念，扮演“镜子”。

  我们做一个房屋前，是不是要先设计一个“房屋架构”呢？我们在做一辆车前，是不是要先画一张图纸，设计车的架构呢？我们做城市规划的时候，是不是要先做城市架构呢？

  所以，架构能够在一定程度上帮助我们抽象出真实世界，在我们改造真实世界的时候，先用架构模拟演练一把，识别成功条件、规避各种风险，这样在我们塑造真实世界的时候就能更加准确有效。

  其实，“架构（architecture）”一词最初来源于建筑，其核心是通过一系列构件的组合来承载上层传递的压力。

  经过漫长的演变，架构设计慢慢的变成了真实的生活中必不可少的活动。比如，要建一栋房子，就有必要进行很多的架构设计工作。首先要进行外部架构的效果设计，在客户满意之后，再进一步设计内部结构，以及配套的线路、上下水管道等各方面的设计。

  所以，一句话来定义架构：架构是系统的组成部件及其之间的相互关系，通过明确这种关系，使得架构之间联系更加科学合理，系统更加稳定。

  同样，1是线是虚拟世界的企业运作（IT系统）；3是连接虚拟与现实的“镜子”。我们用下面这张图来比喻——企业架构便是这面镜子。

  企业架构，是对真实世界企业的业务流程和IT设施的抽象描述；它是包括企业战略、组织、职能、业务流程、IT系统、数据、网络部署等的完整、一体化描述；

  企业架构反映了企业业务的状况，并体现了业务与IT的映射关系，能明确各类IT设施对业务的支撑关系。

  业务架构：是把企业的业务战略转化为日常运作的通道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织架构、地域分布等内容

  IT 架构：指导 IT 投资和设计决策的 IT 框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。

  架构之间的关系如下图所示，业务架构对齐业务战略，IT架构对齐IT战略。IT战略又支撑并影响业务战略。

  因为，业务架构（BA）是这面“镜子”的入口。在上图中：BA对上承接战略，对下输出为一个个业务流程的优化/变革的项目；同时，业务架构（BA）向右是从现实到虚拟的衔接，就感觉是“空间穿越”的入口，它作为IT架构中“DA(数据架构）、AA(应用架构）、TA（技术架构）”的输入。

  这里我只是开个头，对大家说企业架构的作用，尤其业务架构应该成为管理人员的利器，用来承接并驱动业务战略、价值主张、使用者真实的体验，落实“面向客户、端到端流程”落地，那么，业务架构必然是关键抓手。

  目前，我国对企业架构的使用其实是在IT层面，业务人员还没有开始利用这个工具进行业务运营模式的设计和规划。

  在这里，喻旭呼吁：在数字化的企业里，企业的业务部门和管理部门应该大力推广企业架构方法，以推动企业战略和IT战略目标的实现。通过企业架构，把高端的企业战略和操作层面的业务管理和运营结合起来。