公司的组织架构如何设计（企业架构设计图）

“架构（Architectture）”一词最初源于建筑，从石器时代开始，建筑设计就一直沿用至今。经过漫长的演变，架构设计已经成为现实生活中必不可少的活动。比如，建筑设计、服装设计、软件设计和汽车设计等，都需要进行很多的架构设计工作。

架构是一个很广泛的话题，涉及到方方面面，即是一种理念，也是一种实践产物。当架构与企业管理融合时，企业架构的理念和实践就诞生了 ；当架构与业务融合时，业务架构就出来了；当架构与IT融合时，IT架构就诞生了；······

那么，面对这么多架构，企业架构，业务架构，IT架构，甚至还有应用架构和数据架构等等，它们之间是如何定义和理解？，以及如何区分呢？

本文从业务架构出发，阐述什么是业务架构、为什么要业务架构、业务架构与其他架构的关系，以及如何设计和落地业务架构。通过对业务架构案例的剖析，掌握业务架构的设计方法，把业务与信息技术进行深度的融合，实现企业战略目标。

01

业务架构认知

1、什么是业务架构

业务架构是为实现企业战略目标，通过分析自身优劣势和外部环境的机遇和挑战，利用自身资源和特点进行业务过程规划以及业务能力整体布局。它既可以为单条业务线或产品线分析，也可以为多条业务线或产品线进行跨领域分析。

业务架构主要包括战略目标、组织架构、业务能力、业务流程和数据能力等。其目的也是要降低复杂度，实现业务和技术的深度融合，更好的规划和实现系统。

2、常见架构设计理论

业务架构在很多书籍当中鲜有提及，目前市面上也少有书籍进行详细的论述，很多人对业务架构也是似懂非懂，搞不清它究竟在软件设计中发挥的作用。但是在业务架构的发展历程中，也有几个相关的架构设计理论。

（1）Zachman模型

1987年Zachman提出企业架构模型，该模型按照“5W1H”,也就是What（数据），Where（网格），Who（角色），When（时间），Why（动机），How（功能）6个方面来综合考虑企业架构和需求。业务架构最初属于企业架构内，该模型主要还是解决系统建设问题，虽然未提及业务架构，但其包含了业务架构关注的业务流程，数据等内容，算是业务架构的开始。

（2）TOGAF框架

TOGAF框架是由欧洲共同体的IT协会The Open Group开发的一个企业架构框架理论。它由企业的业务架构，信息架构，应用架构和技术架构共同组成。倡导从企业业务战略导入，实现企业业务架构，信息架构，应用架构和技术架构的渐进演化，对业务架构进行了定义。

（3）其他框架

FEA（联邦企业架构）和DODAF（美国国防部体系架构框架），这两个模型都着眼于跨部门提高效率，解决重复建设和信息孤岛的问题等。

3、为什么要业务架构

业务架构是打通业务和技术的桥梁。在“数字化”中，业务架构能够很好的将企业业务、技术深度融合，帮助企业高效的“数字化”转型。主要有以下几点好处

• 对业务人员能够帮助其从业务和技术视角进行整体化，结构化思考；对科技人员能够理解和归纳业务的目标；
• 业务和技术的深度融合，彼此向对方领域多迈一步；
• 整体规划，减少产品、模块之间的信息孤岛；
• 减少重复建设和资源浪费；

4、业务架构和其他架构的关系

TOGAF框架将架构拆分为业务架构、信息架构、应用架构和技术架构等。这里结合企业战略，将架构之间的关系进行简单的描述，如下图所示：

企业架构是一种对企业多角度的综合描述，反映了企业的人、流程、技术的组织和安排。企业战略决定企业架构，企业架构包括业务架构和IT架构。

业务架构从企业战略出发，按照企业战略设计业务过程，业务过程需要业务能力支撑，从战略到业务再到业务能力的需要，就形成了支持企业战略实现的能力布局，这种布局就是业务架构。

IT架构是根据业务架构的需要，来设计对应的IT能力支撑，包括应用架构、技术架构、数据架构和安全架构等。其中，应用架构与业务架构紧密相联，包括一系列为支撑业务运营的产品功能，这些功能组合在一起就构成了不同产品边界范围。

• 应用架构：关注功能布局，描述了产品之间的布局；
• 技术架构：关注分层结构和技术架构选型；
• 数据架构：关注数据模型，这些数据是业务架构所需要的；
• 安全架构：关注信息安全性加强，安全架构设计符合业务需要；

02

业务架构设计

业务架构设计既可以对单一业务领域，也可以对企业级业务领域，前者设计效果大不如后者。设计过程一般是迭代式的，设计-实现两个阶段不断的交替螺旋上升。这就要求我们要不断的审视和具有迭代思维。

在设计上，我们要抛弃以前的“业务主导技术”，业务提需求，技术实现的思维弊端，而应当时刻保持“技术引领业务”的理念。所谓的“技术引领业务”不是随意引入新技术，而是要业务和技术先融合，基于企业战略搭建业务架构，继而引发业务变革，利用技术手段实现。

1、设计三点原则

业务架构设计仁者见仁智者见智，虽然有统一的标准，实际应用过程中还是的因地制宜，但有几个基本原则可以把握。

• 整体性原则：业务领域一定要通盘考虑，先有整体再有局部。比如，ERP系统，SKU编码在采购、生产、销售，财务都需要应用到，如果不通盘考虑，就会出现不同业务领域各自定义SKU。
• 方向性原则：把握好业务发展的大方向和战略；
• 可执行原则：切记好高骛远，设计的业务架构无法落地；

2、设计五步法

业务架构设计整体逻辑包括战略分析、价值链分析、组织分析、领域分析和能力分析五个要素。从下往上看，基于架构设计理论，把握设计的原则，通过对企业或产品战略分析、价值链分析、组织分析、领域内流程和数据分析，构建了业务的能力模型，也就是整个企业或产品对外的能力项。业务架构设计模型如下图：

（1）第一步：战略分析

一个企业或产品的生存和发展很大程度上依赖于能否选择和实施一个好战略。设计业务架构之前必须对企业或产品的战略进行分析，通过分析，我们能够知道企业或产品的商业模式、运营模式、外部环境和内部能力等。

战略分析一般从愿景、使命入手，向下分解出可衡量的目标，三者描述的是企业或产品为自身发展所设定的目标和成功标准，目标必须可衡量，不可衡量的目标只能是口号。

愿景、使命和目标必须认真对待，不能出现偏差，务必同管理人员和参与人沟通清楚，保证所有人都达成一致的共识。

接下来围绕企业的收入、成本和利润三角关系分析企业或产品的商业模式和运营模式，同时对外部环境和内部能力进行识别和分析。

• 商业模式分析：明确企业或产品的对外提供的主要服务、收入和支出；
• 运营模式分析：为达到目标，组织架构和采取的运营方式是什么样的；
• 外部环境分析：洞察外部环境中存在的或潜在的机会和威胁；
• 内部能力分析：通过分析企业资源和能力，找准自身优势和弱点；

这种分析是对战略的一次推演，帮助衡量战略的合理性和梳理共同的战略目标，能够有效避免无效的工作。

战略分析过程中，一般采用前人的一些模型会更好，我们常用的战略分析工具包括九宫格画布、PEST分析、波特五力模型、竞争态势矩阵、价值链分析和竞争优势分析等，有兴趣可翻阅相关资料。

（2）第二步：价值链分析

价值链主要描述的企业价值的创造过程，包括供应商供给-制造商/服务商-经销商流通-最终用户消费等。典型的价值链分析最开始由迈克尔·波特提出，如下图示所示：

它包括基本活动和支持型性活动。基本活动主要是指生产过程，支持活动主要是辅助性作用。这个模型更偏重于制造业。对于服务型企业在基本活动方面需要进行相应的变化，但其核心底层的逻辑没有变，均是设计产品-客户营销-售后服务。

（3）第三步：组织分析

组织分析主要是对企业组织结构和组织文化的分析，不管的是企业或产品的业务架构规划，都不可避免的牵扯到各个不同的部门，以及当前所在的组织氛围。维护和处理好组织之间的关系，突破壁垒，形成合力，是我们想看到的结果。

“康威定律”告诉我们，任意一个软件都能反映出制作它的团队的组织结构。这句话可以解释为产品团队的组织结构优缺点都不可避免的反映在他们制作的产品上，同时，业务团队的组织结构优缺点一样映射到业务架构上。

组织文化是由组织成员共同的经验沉淀而成，这些组织文化反映着员工的价值观、行为规范等，它对业务架构目标的实现有较大的影响。组织结构的本质是组织中权力分配，这种权力是资源的分配。

这就要求，在设计业务架构时，拿出来的方案是以一种有效的方式满足相关方的需求。而部门利益是天然的边界，跨越这个障碍才是最大的挑战。倘若一个组织内部是高度的部门化，是很难建成一个企业级的业务架构，我们在做业务架构规划时，需要提前识别和考虑这一点，不然方案在落地的时候可能会困难重重，面目全非。

（4）第四步：领域分析

业务架构强调的是整体性，需要有全局思维通观企业的整个运营过程和价值增值过程，这样才能将企业或产品需要的业务能力进行分类汇集，更好的设计业务架构。

领域分析主要包括业务领域划分、业务流程分析和数据模型分析。

①业务领域划分

业务领域划分取决于企业或产品价值定位，也就是提供什么类型的服务或产品。划分业务领域有以下两种方法：

• 组织架构法：根据企业组织架构区分不同业务领域，组织架构本身也是一组岗位职责类似的集合。比如，企业人资部门对应人资领域、财务部门对应财务领域、销售部门对应销售领域、采购部门对应采购领域和仓储部门对应仓储领域；
• 产品服务法：根据产品线划分业务领域，比如，快递、重货、冷运、人资、财务和采购等。

在划分领域的时候，我们会遇到一些公共的领域，其他各业务领域都需要使用的部分，这时可以建立一个通用的领域，包括主数据，权限和工作流

②业务流程分析

对某一个领域内的所有业务处理过程按照端到端的业务闭环拆分到一个或多个业务流程，并分析业务流程的每个活动、输入、输出、判断和异常。

业务流程中的活动可能会有不同角色参与，具体哪些角色参与涉及到组织结构和岗位分工，每个活动对应到角色的职责，这些活动是要能够满足战略能力需求，有力的支持战略的实现，有效的服务客户和应对行业竞争。

业务流程的具体设计可用VISIO工具参照BPM相关的设计规范。可参考《摆脱需求搬运工：史上最全To B产品需求分析全景图（2）：如何转化需求？》流程设计部分。

③数据实体分析

整个业务过程其实是行为和数据的流转，反映出来的就是业务流程和数据流向，映射到系统上就是功能和数据承载。

数据实体对于业务架构来说至关重要，构建统一的数据模型，规范数据标准和口径，是整个业务架构成功的保障。否则，各自为政，就会出现架构失灵、崩溃的现象。

数据模型是有一组数据实体组成，其表示方式很多是呈现为E-R图，E-R图是实体关系图，是关系型数据库设计的基础，描述实体间的关系，从而指导程序设计和数据库设计。

通过对业务领域的业务流程分析，识别业务流程中的输入，输出数据（实体），活动会直接处理数据，包括增、删、改、查四类操作。这些数据就是数据模型构建的基础，也是将来系统搭建的实体对象。

（5）第五步：能力分析

业务领域、业务流程和数据模型描述了特定领域业务的整个处理过程和处理对象。将三者组合起来，可以清楚的描述，在特定领域，什么样的事件或条件触发了一组业务活动，业务活动需要输入哪些，业务流程的处理规则是什么，经过业务流程的处理，输出哪些。

一个业务领域由一系列业务流程组成，这些业务流程执行了不同的业务活动，业务活动处理了 不同业务对象。

那么，如何划分能力模型？

这里推荐两种方法：

第一种：按业务领域划分，将不同领域作为不同的能力项。比如，人资领域，采购领域，销售领域分别提供人资管理能力、采购能力和销售能力。这种划分方法，未免有些“偷懒”，对于复杂的业务来说，内聚性一般较差；

第二种：按数据实体关系远近聚合在一起，一般是关系较近的数据实体聚合。比如，订单和合同，订单作为一个能力项，合同作为一个能力项。

对于通用领域的能力模型，建立统一的标准和规范，统一对外提供服务，支持不同领域不同活动对能力项的复用。这些通用能力项主要包括人员数据，主数据、权限、日志和工作流等。

通过能力模型的建立，可以很好的将整个企业或产品涉及的领域清晰的对外提供能力服务。

小结：
业务架构设计是迭代前进，对业务活动长期打磨，增强能力模型的内聚性，职责更集约，从而更好的封闭变化，开放调用，避免过去竖井式开发，互通互联才是业务架构的价值。

3、设计难点

业务架构的设计离不开标准化过程，因为其涉及多个部门，多个业务领域，追求灵活响应和减少重复开发，而这又是很难的一件事。最大的难点就是标准化。

这个标准化，主要涉及两部分，一部分是管理制度和流程标准化，另外一部分是数据标准统一化。

管理制度和流程标准化：这个标准化，意味着管理制度、职责、奖惩、业务流程和业务活动清晰化和标准化，势必会带来企业管理成本和人员素质要求提升。这是非常难的一件事，在没有下定决心和恒心之前，还是不要标准化的。

数据标准化：要保证数据实体和属性的唯一性，不产生重复概念，数据标准的统一化就尤其重要，这就要求大家共用一个“通用语言”，在不同领域，在语义层面逐一澄清。

目前没有很好的方法能够完全实现标准化，只能是实践的过程中，凭借专业人士和团队经验共同努力，将业务和技术进行深度融合。

4、案例

实际的业务架构建模过程并没有一个可量化的标准判断架构好坏，本节通过一个案例来讲解一下前面所介绍业务架构设计方法。

案例：集团型企业采购业务架构设计

背景：某集团公司A是一家上市公司，采用多元化发展战略，横跨多个业务产品线，主要面向C端或B端客户，为其提供一揽子解决方案和服务。

（1）战略分析

随着A集团业务的快速发展，不同产品线的收益节节高升，A集团未来期望成为一家综合数字化解决方案公司、持续的为行业、为客户带来价值。随着集团的多元化快速发展，要求各组织、职能部门、业务线均需保持良好协同和赋能业务。

其中A集团的采购业务线散落在各个业务线、BU或组织中，为构建统一的管控标准、建设集中的采购平台，A集团准备立项拉通各中心、BU、组织和职能部门，共同梳理和建设企业级采购业务架构，并有计划未来2-3年为外部客户持续提供一揽子采购服务解决方案。

（2）价值链分析

A集团采购业务线在整个企业的价值链图谱中主要是支持性活动，辅助其他业务产品线快速交付客户，达到支持整个企业战略目标。

采购业务线的价值链为产品线提供从需求管理、招投标管理、合同管理、订单管理和结算管理等一揽子服务。其内容如下：

• 需求管理：主要包括汇总需求，预测需求和转化需求等；
• 招投标管理：主要包括采购的招标管理和供应商的投标管理；
• 合同管理：主要包括合同拟制、合同变更、合同终止和合同审批；
• 订单管理：主要包括订单管理、ASN管理、备货管理和验收管理等；
• 结算管理：主要包括结算对账、发票管理等

（3）组织分析

A集团有集团的采购中心，同时其他业态、BU或孵化组织也有自身的采购团队。集团采购中心负责集团统管的物资、服务、人力、商品等，其他组织负责授权范围内的物资采购，还有组织本身就不归集团管辖。这是集团统采+其他组织分采+自采的模式。如下图：

这个模式的现状问题是集团的并没有统一的标准管控所有的采购环节、各自的数据、系统相对独立，也就造成了无法全局掌控采购以及过程风险挂空，数据口径的不统一，也无法进行集团的数据分析。整个集团的采购是一盘沙，这对一家采购额上千亿的公司来说，无疑是一场噩耗。

另外，公司发展几十年，部门林立，大集团病也不少，官僚风气也存在，想解决这个问题，如何打破部门之间壁垒，做到权力和利益重新分配，是需要铁腕的手段和超强的执行力。

（4）领域分析

采购是为企业购置所需的物品，在整个企业的价值链来说，它是单独的领域，称为采购领域，不同于人资领域、财务领域和销售领域。这个案例主要介绍企业级采购业务架构，聚焦在采购领域的企业级架构。

采购的服务过程也就是价值链的过程，包括需求管理、招投标管理、合同管理、订单管理和结算管理5个过程。这5个过程构成了企业采购从需求到结算的闭环过程。

业务领域如何划分？前面提到按组织架构或按产品服务法。组织架构的划分前提是组织架构的职责清晰，这里显然不合适。按产品服务法，将需求、招投标、合同、订单和结算分别划分为5个业务领域。

每个业务领域服务于不同组织、中心、BU、孵化组织的不用业务线，比如，重货、冷运、金融等；每条业务线会包括不同的服务类别，包括实物、服务、资产等。业务领域的划分如下图：

为了理清业务架构设计的核心逻辑，这里就仅做了简化分析，从宏观上进行了设计。

①业务流程分析

采购的业务过程划分为5个业务领域，每个业务领域都有业务流程，将5个领域的业务流程拼接起来，就是整个采购端到端的流程图。

不同的业务线在5个领域的流程图可能是不同的，按照企业级采购流程图的规划，必须进行标准化，标准化业务流程其实是最难的点。针对采购全过程流程图，我们将不同业务线的流程图汇总梳理并优化，最后得出标准的业务流程图，如下图所示：

②数据模型分析

采购业务流程标准化后，我们需要识别出谁（角色）在流程里做了什么事（活动），他输入和输出了什么数据（数据）。我们将采购全过程的标准业务流程进行了识别和分析，结果如下图所示：

每个领域涉及的活动和数据实体简要描述如下：

• 需求领域：品类专员提交需求，并转化创建寻源需求，这个过程涉及到两个数据实体，包括需求申请、寻源需求；订单员处理下单需求，涉及到采购申请数据实体；
• 招投标领域：品类专员立项、发标、开标和定标，涉及到项目单、报价单、供应商和定标单等数据实体；供应商主要是投标，涉及到投标单和报价单数据实体；品类专员和供应商可以共用报价单数据实体
• 合同领域：品类专员拟制合同并提交审核、变更合同并提交审核、终止合同并提交审核，由于拟制、变更和审批都存在提交审核，此时可将合同审核单独做一个活动，涉及的合同单、变更单、终止单和审批单数据实体；供应商确认合同，涉及到合同单和变更单数据实体，可以共用数据实体；
• 订单领域：订单员提交申请，转化为订单，涉及到采购申请和采购订单数据实体，由于需求领域也涉及到采购申请，可订单领域采购申请合并数据实体；供应商创建ASN，验收，涉及到ASN单、验收单数据实体等；
• 结算领域：结算专员生成未清结算清单，并生成结算批，再进行对账确认，最后确认发票，涉及到未清结算、结算批和发票数据实体；供应商确认结算批，创建发票，涉及到结算批和发票数据实体，可共用数据实体；

这里只是简单的阐述了不同角色所进行的活动，用到的数据实体，我们发现不同领域或不同角色存在对同一个数据实体的使用。

比如，需求领域和订单领域都用到采购申请单；5个领域都涉及到SKU和供应商；招投标领域品类专员和供应商两个角色都用到了报价单数据实体；合同领域品类专员和供应商都用到了合同数据实体；订单领域订单员用到合同数据实体等等。

这些跨领域、跨角色的使用相同数据实体，如果不考虑企业级，就是竖井式搭建业务模型，竖井式开发，几个领域可分别开发和定义模型，这样就不存在企业级业务架构。

企业级业务架构就需要将这些不同领域的业务模型拉通一起进行分析了，每个领域涉及到的数据实体已经简要介绍过，下面是将这些共同使用的数据实体抽取出标准化来共同使用。

• 不同领域共用数据实体：需求领域和订单领域都用到采购申请单；
• 所有领域共用数据实体：所有领域都用到SKU和供应商数据；
• 不同角色共用数据实体：招投标领域品类专员和供应商两个角色都用到了报价单数据实体，品类专员和订单员都用到了合同数据；

这里就不一 一列举了，核心是识别每个角色的活动，数据实体的使用，保留和抽象共用的数据实体。

（5）能力分析

通过标准化和抽象化数据实体，我们可以将SKU、供应商建立公共的数据实体，与之对应的活动聚合成“SKU管理”、“供应商管理”能力项；将数据实体采购申请单、需求申请单、寻源需求都放在“需求”主题域下，与之对应的提交需求、维护寻源需求、维护下单需求活动，根据数据实体关系远近聚合原则，聚合成“需求管理”能力项；

同理，招投标领域、合同领域、订单领域和结算领域的数据实体可分别放在“招投标”主题域、“合同”主题域、“订单”主题域、“结算”主题域，与它们相对应的活动分别聚合到“招投标管理”、“合同管理”、“订单管理”、“结算管理”能力项。

通过主题域和能力项的归集，企业级采购业务架构初始图如下：

这是一种设计思路，我们也可以把维护下单需求活动放到订单管理能力下，或者把创建备货活动放到需求管理能力下，这个划分没有严格的要求。根据关注点、设计思路的不同，架构设计也会有相应的变化，没有绝对对错。

通过主题域和能力模型设计，最后的设计的结果如下：

• 能力模型：包括需求管理、招投标管理、合同管理、订单管理和结算管理；
• 数据主题域：包括需求管理、招投标管理、合同管理、订单管理、结算管理和主数据。

将上图的能力模型进一步抽象为业务架构图，表示企业级采购业务架构能够提供的服务能力，简化如下图：

（6）总结：

案例选取了企业采购这个领域进行了分析，而并没有覆盖企业所有领域，主要是为了说明分析过程，进行了简化，而实际业务场景要复杂的多，但其分析思路一致。我们从案例可以知道几点：

• 业务架构更关注企业的整体设计，从战略分析到企业整体能力规划；
• 架构设计思路和关注点会影响到设计结果；
• 架构需要反复持续迭代。

但其分析思路一致。我们从案例可以知道几点：

• 业务架构更关注企业的整体设计，从战略分析到企业整体能力规划；
• 架构设计思路和关注点会影响到设计结果；
• 架构需要反复持续迭代。

作者：PMRobin B端产品、技术、数据；企业服务。