文/明道云创始人任向晖
本文来自即将出版的《零代码企业应用搭建指南》中的关键章节，指导用户进行相对复杂应用的前期信息架构工作。
零代码平台赋能了业务开发者，让他们可以不写代码就能完成应用实现。但是企业应用设计和开发毕竟是一个复杂过程，对于大多数用户来说，即兴创作是很难的。对于比较复杂的应用搭建需求，它依然需要一个完善的分析和计划的过程。
在企业信息系统建设过程中，开发和实施前都离不开架构设计工作，对于复杂的系统，信息架构所花的工作时间比例更高。而且，信息架构是一个长期过程，它不仅服务于具体业务系统开发和实施的需求，还包括中长期规划和服务于应用的迭代与迁移需求。
本章重点介绍企业信息架构（Enterprise Architect）的一般方法，以及如何简化它们来服务零代码应用搭建的过程。
1.企业信息架构的一般方法
从上世纪七八十年代开始，企业信息架构就开始成为一个专业领域，形成了一整套方法论。这些方法论围绕复杂组织的信息系统建设提供了抽象的思维框架和计划工具，它们虽然大多来自军工、航天和政府需求，但经过整合以后，同样适用于企业领域。
在这些方法中，来自 IBM 的 Zachman 框架和源自美国国防部的 TOGAF 框架是比较典型的信息架构方法论。我们对这两个方法论做一个简单介绍。
1.1 Zachman 框架
Zachman 框架起源于 John Zachman 先生在 1987 年完成的信息系统架构论文“A framework for information systems architecture”，他把信息系统架构设计相关的各种元素归纳到如下表格之中：
从这个复杂的表格可以看出，信息架构是一个多层次和多要素的复杂工作。他服务于组织的不同层面需求，也需要多角色一起参与建设。这是一个在宏微观层面都非常完整的框架。依照这个框架来完成分析和计划工作必然是相当完善的。但因为它的完善，也给企业界的使用带来繁冗的工作。五种参与角色和六大考量要素综合起来就是三十个格子，如果都按照这个标准来做架构设计，企业信息系统的规划成本就太高了。所以，我们往往把 Zachman 框架当作一个分工和思考的检查清单来使用，至少可以帮助我们避免重要的遗漏。
1.2 TOGAF 模型
TOGAF 模型全称 The Open Group Architect Framework，目前由 The Open Group 负责维护，已经发展到 9.x 版本。
TOGAF 框架定义了企业架构内容和实施步骤及交付物，将企业架构划分为业务架构、应用架构、数据架构和技术架构，形成了涵盖企业各方面的架构体系，是一个面向各种不同组织、具有很强通用性的企业架构。对于实际的架构工作，其指导意义高于实践操作的意义。其中，业务架构：定义企业战略、企业治理、组织结构以及关键的业务流程。数据架构：描述组织的逻辑与物理数据资产的结构和组织的数据管理资源。应用架构：提供描述应用系统的部署、交互以及系统与组织核心业务流程之间关系的蓝图。技术架构：描述用于支持业务、数据、应用服务的软件、硬件的能力。这些软、硬件以及逻辑技术部件包括 IT 基础设施、中间件、网络、通信、处理机制、标准等。
附图：TOGAF 架构开发方法
TOGAF 的一大特色在于其独特的架构开发方法 AMD (Architecture Development Method)，它是一个以需求为中心的循环过程。在总体框架和规划原则的前提下，ADM 方法从架构愿景出发，经过业务架构规划，确定信息系统架构和技术架构，然后结合现有的信息化基础，给出企业信息化建设，适应性改造的解决方案。迁移计划针对实施方案中不同项目的优先权，评估各个项目的依赖程度、迁移费用、收益等，并形成具体的实施规划；实施治理制定了各个实施项目的建议，建立架构规约来管理所有实施和部署的过程，以确保实施项目架构与相关项目架构的一致性。架构变更管理关注业务目标、环境和技术等方面的演变和发展，为是否启动和规划新的架构进化周期提供。
TOGAF 目前是企业架构专业领域最知名的框架，它也有完善的培训、认证体系。但它和 Zachman 框架一样，都过于庞杂，缺乏实际项目落地的可用性，更多地演化成为一个职业，而难以被一般企业实践直接所用。
接下来的小节会专门介绍一个简化的信息架构方法。它保留了经典企业信息架构的战略视角，但更多着眼于 IT 项目的落地需求，简化了参与角色和架构实现中的环节，让非专业人员也能够从事信息架构的实质性工作。
2.一个简化的信息架构方法（RPIC）
方法论的介绍很容易陷入晦涩的程序说明，它最好能够结合实例来表达。为此我们专门准备了一个大多数企业用户能够有代入感的案例。但在解析案例之前，还是有必要先简单概述一下这个方法论的核心思想。
RPIC 是 Role，Process，Information 和 Content 的缩写，意思是角色、流程、信息和内容。它是一个循序渐进的分析计划过程，从企业管理和运营角色的分解出发，为每个涉及到的角色（可能包括外部角色）分析他们在业务活动中需要完成的流程和接触的信息（数据），当枚举出所有的流程和信息后，就能够取得它们的不重复并集；通过这个并集内容分项规划数据架构、角色权限、统计报表和工作流程四项核心架构内容。
这四种架构内容是非常具体的 IT 项目落地蓝图，无论是外购系统配置，还是自行开发，包括使用零代码应用平台搭建，都能够通过这个方法获得完善的计划引导，建立有秩序的执行步调和达到预期的结果。
整个过程简洁明快，着眼于具体规划产出。稍有 IT 经验的职场人员经过简单训练就能够掌握。尤其是结合零代码平台，规划人员甚至可以直接上手完成具体的应用搭建。当然，使用者要了解这是一个简化的框架。它不可避免地会忽略一些内容，比如企业战略视角、复杂企业组织的干系人网络、规划的长期视角、应用的迭代和迁移计划。这些被裁剪的内容并非不重要，只是它们不一定出现在每个应用的需求时刻。而且我们也会有其他办法来针对性补充。
接下来的案例，我们会按照这个方法论，一步一步引导大家理解和掌握企业信息架构技巧。
3.结合案例的方法论解析
3.1 案例背景
案例中的企业叫“普渡餐饮”，是一家成长中的企业餐饮服务企业。它为周边企业提供员工送餐和宴会送餐服务，面对的客户对象是企业。因为普渡餐饮重视菜品质量和口味，它的服务获得了一些高福利企业的欢迎。一般企业会为员工常年订购早餐和午餐，遇到有会议用餐需求的时候，也非常乐意继续使用普渡餐饮的服务，因此普渡餐饮的这两种业务有明显的客户交叉现象。
普渡餐饮的产品目录是有独立菜品和套餐组成的综合菜单。员工早午餐可以从数十种套餐中进行选择，宴会则可以选择套餐或者自选的菜品组合。大多数客户会倾向于选择订购套餐。
因为在发展的早期阶段，普渡餐饮目前只有一个生产加工中心。出于成本控制的目的，普渡餐饮除了包装材料以外，几乎不保留任何生鲜原料库存，采购完全根据前一天的订单，在当晚完成采购，次日根据订单加工和派送。菜品加工完全在自营的生产加工中心完成。因为营业规模有限，普渡同一时期只在数家固定的生鲜配送商那里采购，每月结算费用。
普渡餐饮的物流服务是外包的，通过固定合作的物流公司将制作好的菜品和包装快递给本地客户。物流公司每月根据实际的物流费用与普渡餐饮结算。
3.2 案例目标
结合以上的案例背景，我们的目标是为普渡餐饮设计核心业务系统的信息架构，并通过零代码平台来实现整套应用。为了控制篇幅，我们把核心业务系统定义为从普渡餐饮接单开始到餐品交付，并完成收款的全部过程，舍去行政、人事、营销等环节。
我们要获得的产出物具体包括：
- 信息架构中的数据结构定义
- 工作流程定义
- 可用的应用系统
- 配套的使用文档
3.3 架构设计过程
（1）价值创造过程总览
为了梳理清楚一家企业的信息架构需求，我们一般可以先绘制一张流程图。这张流程图可以从宏观的层面将这家企业的价值创造过程表达出来。在流程图中，节点表达的是参与主体，既可能是内部部门，也可能是外部角色。价值创造按照从左往右的方向进行，这样既容易绘制（减少交叉），又能够有条理地遍历所有的参与角色。而角色是 RPIC 方法中的出发点，我们不能遗漏任何参与业务流程的重要角色。
在本例中，客户向普渡餐饮的销售部下订单，销售部据此向内部的加工中心下加工单，加工中心再据加工单向生鲜配送商下采购单。以上是整个业务活动的信息流部分。然后生鲜配送商向加工中心配送食材原料，再被加工成最终产品，并通过物流服务商配送给客户。在这个流程图中，信息流用虚线表达，实物流用实线表达。在后面的信息架构工作中，我们重点要关注的是信息流，以及和信息流相关的角色主体。
通过以上的流程图，我们获得了以下参与角色：
- 销售部
- 加工生产中心
- 客户（外部）
- 生鲜配送商（外部）
- 物流服务商（外部）
在角色定义中，内部用户一般要精确到特定的职能，而外部角色一般不需要细化，因为上下游协作主体一般都有固定的角色来和本企业进行交互。比如在本例中，无论是物流服务商，还是生鲜配送商，都是由客户服务部门来对接的。
所以接下来，我们按照这个分析结果逐项厘清所有的流程参与角色
（2）参与角色盘点
从总览流程图，我们挖掘出了和业务活动有关的角色。在列举具体角色的时候可以分别从管理角色和运营角色这两种类型出发。因为必然存在的科层分工，每个企业组织中都会有不同的岗位层级，他们在业务活动中需要接触不同的数据对象和完成不同的工作内容，因此，分开列举运营用户和管理用户能够帮我们把信息架构设计得更完善。
下表是我们根据主体对象继续开发出来的角色清单。为简化案例，我们只细分了和案例目标有关的两个职能部门和总经理角色。这样我们就有了 RPIC 方法的出发点——角色（Role），后续的架构设计工作将围绕这些角色的工作视角进行。如果你需要通过用户访谈来帮助架构设计，也可以明确地将这些角色用户当作访问对象，观察他们的业务活动，搜集来自他们的工作材料。
（3）梳理不同角色的信息和流程触点
我们以其中三个角色为例，来说明如何梳理不同角色的信息和流程触点。这三个角色是销售专员，厨师长助理和总经理。
销售专员和厨师长助理都是运营用户角色，他们的数据和流程触点往往比较具体，涉及到原始行数据的搜集和录入，也包括发起具体的业务活动。通过分析，我们可以总结销售专员的最重要业务活动就是接受客户的订单和向加工中心发出加工单；进一步分析，如果要处理客户订单，就不可避免地要建立和维护客户档案，以及产品价目表这两个关联数据对象，否则这个订单是无法有效建立的。（不可能在一个客户的多订单中重复录入客户信息，也不应该在订单中不断重复产品具体信息）。这个进一步分析表达在下图的扩展箭头上。这种扩展分析是我们通过角色业务活动整理数据架构的基本方法。在这个分析图中，加粗和红色的字体表达的就是整理出来的业务数据对象，也就是 RPIC 方法中的 I（Information）。
通过如上分析，我们枚举出以下业务数据对象：
- 订单
- 客户
- 产品价目表
- 加工单
- 供应商
- 物料
- 采购订单
- 运单
除了这两个运营用户角色，我们再分析一个管理角色——总经理。
管理角色对于企业信息和流程的运用一般都会基于运营用户已经处理的数据内容，所以如下图所示，总经理希望分析订单和客户变化趋势，分析利润情况，这两者的基础数据支持都已经在以上运营用户管理的数据基础之上，我们已经无需再扩展更多的数据对象。
但是，管理视角可能会提示我们既有数据架构的不足。比如，如果总经理希望考察加工中心的人效数据，则最好能够增加加工中心的出勤信息数据。
额外说明一下，在本例中，之所以订单的成本核算可以根据采购单直接获取，是因为这家餐饮企业在财务会计上使用批次成本法，也就是销货成本可以直接对应到某些批次的进货成本。
这样，通过每个角色的业务活动分析，我们整理出他们各自所需要接触的数据和流程，分析结果如下图所示：
至此，我们已经完成了架构设计的基础工作。接下来，我们需要进一步细化 RPIC 方法中的 Process 和 Information
（4）用 ER 图细化数据模型
第 3 步已经列出信息系统所需要的数据对象。在此基础上，我们继续细化数据的属性，也就是描述每个数据对象的字段。
描述数据的属性可以基于现有工作流程中的材料，比如现有的 IT 系统界面，Excel 文件，纸质表单等。如果设计者本人不直接从事相关业务活动，还可以访谈相关的职能用户。
下面给出本案例需求所涉及到的数据对象列表和他们的属性。在架构设计上，我们一般用实体关系图（ER 图）来表达。ER 图的绘制虽然有一些专业约定，但是它并不难理解，所以建议零代码应用深度使用者学习掌握。概括来说，ER 图绘制的规则包括：
（1）用表格框来表达一个独立的业务对象，对应着关系数据库中的数据表。同一性质的主体必须放到同一个数据表中。比如我们不能有客户表和大客户表，也不能有年度客户表这样的概念，客户就是客户，所有属性的客户都应该在一个独立的客户表中。
（2）在表格框的主体部分罗列描述主体的属性，对应着关系数据库中数据表的字段。在正式的应用开发设计中，还需要定义字段类型、主键和外键，对于应用平台搭建用户来说，这些技术化的环节全部可以省略。
（3）用连接线建立不同数据表之间的关联。关联主要包括一对一、一对多和多对多的类型。比如本例中，客户和订单就是一对多的关系，用表示。而订单明细和产品价目表就是一对一的关系，用表示。有关关联数据库的基础知识可以参考第 3 章中关于工作表关联的类型。
（4）整个 ER 图的布局要注意位置关系，让具有关联关系的对象排列在附近位置，让关联关系更容易被理解。
在上图中，除了之前分析步骤列出的 8 个数据对象外，还增加了 5 个数据对象。分别是产品分类，订单明细，产品价目明细，采购明细和加工明细。这些明细表扩展是业务数据结构中常见的手段，它能够提高业务系统的灵活性。比如如果一个订单表没有订单明细，那么一个订单就只能记录一种产品的购买，如果一次订购多个产品，就不得不分开多个订单。这显然是不合理的。订单产品明细中的记录再和产品价目表项目关联，就建立了一个更加合理的数据结构。
产品分类表的建立则是为了让顾客订购产品的时候能够方便地按照类别进行查找，比如冷菜、热菜、早餐和套餐等。
设计数据结构也并非一定要使用 ER 图。对于简单的数据关联关系，用一般表格加标注来做计划也是可以的。无论用何种方法做计划，分析出来的数据对象列表就会完整对应零代码应用搭建时的工作表对象。
企业软件行业发展数十年，在常规的企业运营活动中已经积累和完善了成熟的数据模型。比如管理销售漏斗的 CRM 数据架构，管理贸易活动的 ERP 数据架构，管理项目绩效的 PSA 数据架构。这些数据架构都反映在成熟的软件产品中。所以，企业自建数字化系统既不能闭门造车，也无需自己重新发明轮子。有时候直接参考成熟软件的数据架构是一个明智的做法。明道云零代码平台在提供销售管理应用模版时，就直接复刻了 Salesforce 和微软 Dynamics CRM 的数据结构。
（5）用流程图绘制业务流程
第 3 步列出各个角色的流程和数据触点，接下来我们详解每一个流程，为具体的应用设计作准备。我们以列出的 5 个流程中的“按加工单采购流程“为例进行具体拆解。
按加工单采购是厨师长助理的业务活动。他接受来自销售部门的加工单，根据加工单内容向生鲜配送商下采购订单。以下是通过标准流程图对这项业务活动的流程解析。厨师长助理根据生产工单内容生成了原料采购单，并根据当前辅料库存的情况决定是否增补辅料。每一项采购流程均已供应商确认而结束。
在流程图的右侧，我们可以在对应的位置上起草一些具体的架构内容。比如，根据多工单生成采购单的节点就对应了加工单的自定义动作（工作流的一类）的创建，它的实质是要根据加工单明细来获取物料明细，并将物料明细组合成计划状态下的采购单。而同样，创建辅料采购单则比较简单，它应该直接依附在物料表记录上，针对特定辅料来创建采购单。
3.4 架构产出物与蓝图完善
通过以上步骤，我们从角色出发，遍历每个角色的流程和信息触点，完成了多项架构内容的产出。这些产出可以直接服务于零代码应用搭建。我们可以小结如下：
（1）数据结构作为工作表来源。在本例中，我们已经罗列出了 13 个数据对象，其中有 4 个明细子表。在应用搭建时，依次创建这些工作表，并建立关联。
（2）根据单据状态，可以创建工作表下的多个视图，例如“草案订单”、“待执行订单”等。
（3）系统所涉及到的所有内外部角色清单，作为应用中的自定义角色依次创建和赋权。
（4）运营角色和管理角色所需要的报表内容，作为自定义页面及其统计组件搭建的蓝图。
（5）每个角色的业务活动及其分析出来的流程作为工作流配置的蓝图。其中有一部分工作流将通过用户的手工触发（自定义动作）执行。
以上这五个部分就是应用平台搭建所需要的基本架构内容。我们从需求命题的参与角色出发，一步一步梳理，得到具体的工作清单。这个过程所需要花的时间取决于项目的规模。一般而言，单个职能部门的小型应用并不需要这么完善的分析过程，但像这家餐饮公司的核心业务系统还是有必要进行这样的架构分析工作的。虽然零代码应用平台的使用不像代码开发工作那么技术化，但我们依然鼓励用户加强文档工作，提高应用系统的质量，至少可以提高一次做对系统的概率。
4、应用实现
4.1 工作表和视图
应用搭建的基本技能我们已经在本书的其他章节详细介绍，本案例章节呈现一个根据蓝图而搭建的应用实现面貌。
在这个明道云实施专家搭建的应用中，将不同业务环节分组（顶部菜单），在每个业务分组下建立对应的工作表。比如，如图产品管理分组下就建立了系列（分类），产品，产品明细和产品配方这四个对象。
生产工单是之前数据架构过程中涉及的数据对象，在实现的应用中，生产工单包含了生产明细的子表。下图是一张生产工单的样例。
4.2 用户角色
架构分析的第一步就是角色列表，可以将这些角色通过应用平台配置为自定义角色，并根据数据接触需要分别给他们赋权。
4.3 工作流
在明道云应用平台中，工作流是由触发器和一系列动作节点构成的。只要触发器满足条件，就会自动执行所有的动作节点。在本案例中，有诸多环节均需要由特定角色触发工作流程，例如生成加工单。这个工作流可以通过一个按钮触发，然后通过数据操作相关的节点，将订单中的数据转移到加工单上。下图是整个系统所配置的工作流。
4.4 自定义页面和统计
围绕管理角色所需要的统计数据，应用平台可以通过自定义页面上插入统计组件，再将页面分发给不同的角色。例如本例中就创建多个“驾驶舱页面”，不同职能角色看到的页面组合可以是不一样的。
5、从架构蓝图探索更多的数字化机会
命题作业已经基本完成，我们可以借助架构工作的价值，进一步探索数字化运营的机会。反过来来说，如果我们抛去架构设计过程，直接根据需求搭建应用，就失去了看清全局的机会。创新不是空中楼阁，只有看到，才有更大的机会想到。架构蓝图的价值就是提供给企业主一个发想和验证的工具。
5.1 延伸到更完整的业务环节
案例只覆盖了普渡餐饮的接单、采购、生产加工和配送环节。对于完整的企业运营来说，还有很多其他环节具备数字化升级价值，比如此例中，普渡餐饮可以把营销拓客，销售转化，客服，人事考核等都加入进来。利用零代码应用平台的一大好处就是各个业务系统实际上是紧密相连的，减少了采用不同技术解决方案带来的数据孤岛问题。比如延伸客服应用时，显然可以直接共享既有的客户和订单数据。明道云的工作表关联可以跨应用实现，所以无论怎样规划应用组合，都是可以实现企业内的数据统一治理。这对企业数字化建设是一个重要价值。
在延伸业务环节的时候，一般可以从核心业务流程，或者说是企业的关键价值创造过程开始。比如本例中，普渡餐饮的价值创造就是为客户加工餐饮订单并配送的过程。在核心业务流程完善后，再向支持性职能扩展。这是我们在企业数字化建设里程碑设计中的常规考量。
在这两种性质的业务环节中，一般只有核心价值创造流程才值得建立差异化竞争优势。比如普渡餐饮有机会利用数字化能力建立零库存且全自动的原材料采购和配送体系，从而建立在企业餐饮服务市场的成本优势。而在支持性业务环节，只需要对标一般竞争者即可。数字化建设的主要精力始终应该聚焦在核心业务流上。
5.2 以顾客为中心的服务延伸
案例中还没有涉及到客户体验相关的环节设计。这个环节对于任何企业来说都应该是有发挥和创造的空间。譬如普渡餐饮可以建立在线菜单，允许顾客直接自助下单，可以为客户建立菜单收藏，提高客户下单体验。客户下单以后，还可以实时跟踪订单处理状态，甚至可以直接跟踪到加工单。需要的时候给厨师长带个话都可以。
数字化建设在顾客体验方面的创新空间是无穷尽的。设计什么样的信息系统，提供什么功能，一切都可以以是否能够给客户带来价值和高体验为标准。相反，我们也可以根据客户现实的痛点逆向思维，想一想我们如何通过数字化能力来解决客户的这些问题。比如客户在宴会用餐的时候，不想花时间来盯着物流，那么我们就可以在进入加工步骤和交付给物流公司的时候主动推送短信通知客户。这些就是我们常说的有温度的 IT。
5.3 自动化
所谓自动化，就是将过去需要人员处理的工作交给程序处理，理论上，只要有可在线的业务数据，通过原生开发，总能够实现想要的自动化场景。只是这个过程比较昂贵。它涉及到业务需求部门和软件研发团队的高密度沟通，需要做很多的调试和验证工作。
零代码应用平台给了业务用户一个机会自助完成这些复杂的自动化特性开发工作。准确得说，这个过程是通过可视化配置完成的，并不需要写代码。在本例中，普渡餐饮通过客户的订单内容，查询订单产品明细所对应的原料数量，即可自动计算出每天所需要进行的原料采购单。通过实验和调优，可以将原料预定数量控制得非常精确，而且不需要花费人工计算。而过去，批量餐饮生产企业都必须依赖主厨的个人经验判断来做决策，既不准确，也不易于内控。这个自动化设计可以成为普渡餐饮运营过程中的亮点，不仅运营效率高，而且节省了很多不必要的人力投入。
像这样自动化的机会还很多。它们一般贯穿在各项业务活动之间，传统上靠人员协作来解决。再比如，生产加工中心给物流公司下配送单也可以是全自动的，它可以根据加工单的状态变化来自动触发，也可以每天定时按照加工单内容批量生成配送单。
5.4 洞察
当业务运营起来以后，我们就会不断积累出商业数据。这些数据会给企业更多的洞察机会。比如普渡餐饮可以通过客户订单结构分析来优选菜品组合，通过价格敏感度测试优化定价，通过订单配送时间需求来优化运营班次，几乎任何商业数据的集合都会带来更好的决策。
只要数据在一起，进行报表分析就不复杂，你甚至不用再投资昂贵的 BI 软件，零代码平台本身就能够制作各种基于数据表的统计组件，这个过程如同制作 Excel 图表一样简单。
5.5 业务扩展
企业投资数字化建设，有一个很重要的动因就是满足未来的规模化成长。当业务规模不大的时候，用简单的工具也许还能对付，例如销售部如果只有几名员工，那么靠 Excel 记录和日常沟通就能够解决销售管理问题。但是当人员扩充到数十后，很难逃避真正意义上的数字化建设。
人员扩充只是业务扩展的一种形式。更复杂的扩展包括引入多个运营实体。例如普渡餐饮很可能需要在一个城市建立多个生产加工中心，以降低配送成本和加快配送速度；它也有可能未来走出一个城市，建立全国性运作。这时候，集中服务的数字化系统就发挥出了更大的效力，单位成本也会得到摊薄。建立多运营实体在 IT 上并不一定很昂贵。基于上文我们分析的普渡餐饮业务数据架构，我们只要增加运营城市、加工中心对象，就能够将现有的应用快速扩展为一个多站点使用的系统。这一切都离不开科学和有前瞻性的架构工作，它就是本章主要介绍的内容。
Photo by Daniel McCullough on Unsplash
点击阅读原文可访问明道云网站
