内容摘要

在企业数字化进入“快迭代、强协同”的新阶段后，通过 APaaS 产品以零代码方式构建企业应用，正在成为区别于传统开发的新主流路径：它不仅交付一套可用的业务应用，更交付一个持续保持灵活性的应用平台，使后续业务变化能够通过直观配置快速落地，从而在成本效率与灵活性上显著优于传统 DevOps 的长链路交付。

基于明道云与合作伙伴在大量项目中的实践沉淀，并吸收业界服务管理最佳实践（如 ITIL：Information Technology Infrastructure Library）的理念，本书以 APaaS 的交付特性为前提，提出一套面向“服务设计 + 交付落地 + 质量标准”的实施指南：从售前范围与需求收敛（需求四要素 Value/Role/Process/Data），到实施蓝图设计（RPIC 信息架构，推导数据架构、权限、报表、工作流四大核心架构），再到搭建、测试与上线（强调权限与业务流测试，并用 TER：Trigger/Execution/Result 组织用例） ，最终形成可交接、可维护、可持续迭代的标准交付体系（SOW、实施蓝图、可配置项清单、操作指南等）。

同时，本书也将“项目必然变化”纳入机制设计：通过变更请求字段标准、影响评估、优先级排序、版本与备份、关单与文档更新等措施，建立 APaaS 场景下更适配的变更治理体系。 另外，书中给出了面向交付团队的工作量估算思路（围绕对象/字段/流程/角色权限/统计等要素进行量化），为报价、排期与交付承诺提供“可计算”的依据。

本书旨在实现四个目标：

• 提升数字化建设与应用实现效率
• 提升应用与配套服务的可靠性与质量
• 确保终端客户满意度
• 建立可持续的数字化专业服务模式

---

全文索引

全文索引基于电子书原文生成，是结构化、可解析的、面向 AI 的检索清单。

---

《APaaS 应用实施方法论（修订版）》全文索引

Guidebook for APaaS Implementation · Full Index

---

前言｜为什么需要一套 APaaS 实施方法论

• APaaS 在企业数字化中的定位与价值

• 零代码 / APaaS 相对传统 DevOps 的效率优势

• 服务商、客户、平台三方共赢的实施模式

• 本书的目标读者与适用范围

• 本书整体结构与阅读建议

---

第一章｜需求分析与实施范畴确认（Requirement & Scope）

• 售前阶段需求分析的重要性

• APaaS 实施与传统定制开发在需求确认上的差异

• APaaS 实施的两大先天优势

• 实施需求分析的“四要素模型”

  • 商业价值（Value）

  • 角色（Role）

  • 业务流程（Process）

  • 数据对象（Data）

• 从角色出发梳理业务流程的方法

• 典型 CRM 场景的角色—流程—数据示例

• 复杂业务场景下的需求拆分方式

• SOW（Scope of Work）的构成与作用

  • 项目简述

  • 实施范畴

  • 实施内容

  • 里程碑与时间表

  • 项目成员

  • 交付物与支持安排

---

第二章｜应用抽象层次的选择（Abstraction Level）

• 什么是“抽象”与“具象”

• APaaS 中的“写死”与“写活”

• 字段抽象 vs 数据模型抽象的差异

• 高抽象设计的优势

  • 灵活性

  • 可扩展性

  • 可复用性

  • 可维护性

  • 可调试性

• 高抽象设计的潜在风险

  • 系统复杂度

  • 理解成本

  • 配置一致性问题

  • 性能影响

• 抽象层次的宏观判断维度

  • 企业规模

  • 企业战略差异化程度

  • 企业软件门类

• 常见企业应用的抽象可能性评估

  • ERP / CRM / MES / PLM / BPM 等

• 抽象设计的微观判断标准

  • 灵活性

  • 普遍性

  • 易变性

  • 个性化需求

• 抽象设计的现实约束

  • 实施复杂度

  • 客户预算

  • 人力与时间成本

---

第三章｜应用实施蓝图设计（Blueprint Design）

• 为什么 APaaS 需要“实施蓝图”

• APaaS 实施蓝图与传统系统设计蓝图的区别

• 蓝图的边界与作用

• CRM 场景实施蓝图示例

• RPIC 信息架构方法论

  • Role（角色）

  • Process（流程）

  • Information（信息）

  • Content（系统内容）

• 从业务目标到系统蓝图的拆解路径

• 总览流程图的绘制方法

• 不同角色的流程与信息触点梳理

• 从业务要素到系统模块的抽象过程

• 数据对象与视图设计

• ER 关系梳理方法

• 数据字典的构建思路

• 可视化报表与数据驾驶舱设计

• 角色权限体系设计

• 工作流与流程自动化的补充设计

• 实施蓝图小结

---

第四章｜应用搭建实施（Application Building）

• 从蓝图到落地的实施逻辑

• 启动会议（Kick-off）的关键目标

• 实施计划与模块拆解

• 搭建过程中的沟通与变更管理

• 模块化实施与阶段性测试

• 阶段性汇报与客户协同

• 应用搭建收尾与复盘

• 明道云应用的核心构成模块

  • 工作表

  • 视图

  • 角色权限

  • 统计图

  • 工作流

  • 自定义页面

  • 外部门户

• 实施前的基础准备工作

• 借鉴应用库与模板加速交付

• 数据表与字段设计原则

---

第五章｜应用测试（Testing）

• APaaS 应用测试的目标

• 功能测试的基本方法

• 流程与权限测试

• 业务场景回归测试

• 用户参与测试的组织方式

---

第六章｜应用配置管理（Configuration Management）

• 配置与开发的边界

• 配置变更的可控性

• 配置管理对长期运维的意义

---

第七章｜集成管理（Integration）

• APaaS 与外部系统集成的常见场景

• API 与平台级集成能力

• 集成方案设计的基本原则

---

第八章｜交付物管理（Deliverables）

• 除应用本体外的关键交付物

• 文档、培训与知识转移

• 交付验收的关注点

---

第九章｜变更管理（Change Management）

• 变更产生的常见来源

• APaaS 场景下的变更成本优势

• 变更记录与评估机制

---

第十章｜实施工作量评估（Effort Estimation）

• APaaS 项目工作量的评估逻辑

• 人效模型与估算参考

• 报价与实施规模的关系

---

第十一章｜汉得项目实施方法论（Complex Project Methodology）

• 复杂项目的管理特点

• 项目治理与角色分工

• 项目计划、风险与质量管理

• 方法论在大型项目中的应用价值

---

电子书全文

APaaS 应用实施方法论（修订版）

Guidebook for APaaS Implementation (2nd Edition)

⽬ 录

前⾔ 1

第⼀章 需求分析和确认实施范畴 4

第⼆章 选择应⽤的抽象层次 11

第三章 设计应⽤的实施蓝图 26

第四章 搭建应⽤ 50

第五章 应⽤测试 73

第六章 应⽤配置 77

第七章 集成管理 82

第⼋章 交付物 88

第九章 变更管理 90

第⼗章 实施⼯作量 111

第⼗⼀章 汉得项⽬实施⽅法论 118

前⾔

携⼿汉得

去年，明道云发布了第⼀版《APaaS应⽤实施⽅法论》。随着明道云产品的不断臻于完善，越来越多主流的软件服务商开始加⼊明道云的合作伙伴群体，其中不乏像上海汉得信息技术股份有限公司（以下简称“汉得”）这样的标杆企业。在与汉得紧密合作服务终端客户的过程中，我们也收获了很多宝贵的实践经验。今年，我们携⼿汉得共同撰写并推出《APaaS应⽤实施⽅法论（修订版）》这本电⼦书指南，在上⼀版的基础上引⼊汉得客户案例作为佐证。同时，⼤型客户和复杂项⽬可能需要更加完整的项⽬管理⽅法，所以在指南的最后，我们加⼊了汉得项⽬实施⽅法论作为补充。

本书概要

通过APaaS产品零代码构建企业应⽤已经开始成为企业数字化建设的新⽅式。和传统的DevOps流程相⽐，通过APaaS的实施交付具备卓越的成本效率⽐和灵活性。实施者不仅为⽤户企业交付了可⽤的应⽤，还提供了⼀个可以始终保持灵活性的应⽤平台，使得未来的业务变化可以及时通过直观的应⽤配置改动来实现。

APaaS对于应⽤实现的效率提升有不同的衡量⽅式。即使按照最保守的估计，实现成本的降低也⾄少在80%以上。例如：⼀个典型的企业资产管理应⽤，在传统开发模式下，即使具备成型的开发脚⼿架，也⾄少需要2个⼈⽉的时间。⽽⽤明道云这样的APaaS产品只需要⼀个⼈⼀周左右的时间。⽽且APaaS构建的应⽤具备更好的⽤户体验和可靠性，⽐⼀次性定制开发的软件成熟稳定得多。

因此在过去⼏年，明道云合作伙伴群体中的⼀部分企业已经采纳了增值服务的商业模式，为特定客户定制交付企业应⽤，利⽤他们的⾏业知识和对APaaS产品的深度应⽤能⼒获得增值收益。这⼀商业模式对于明道云⼚商、合作伙伴和终端客户⽽⾔是三赢的。我们借助了合作伙伴弥补了通⽤产品的Whole、Product问题，合作伙伴⼤幅提⾼了⼈效，⽽终端客户也节省了投⼊，并且获得了扩展性更⾼的解决⽅案。

我们和合作伙伴群体在过往的服务过程中积累了⼀系列通过APaaS来交付应⽤的经验，⽽客户群体也对这⼀新的实践⽅法提出了更系统的要求。同时，IT⾏业在服务管理环节具备很多现有的最佳实践框架，例如具备典范意义的ITIL（Information、Technology、Infrastructure、Library）。

这本指南⼒图为APaaS应⽤实施和服务者提供⼀个服务设计和交付的流程指南和质量标准。整套指南经过适当简化后，也完全适⽤于企业内部实施。

我们把指南的⽬标设定为以下四个⽅⾯：

• 提升数字化建设和应⽤实现的效率
• 提升应⽤和配套服务的可靠性和质量
• 确保终端客户的满意度
• 建⽴⼀个可持续的数字化专业服务模式

全⽂⼤致按照APaaS应⽤实现的基本步骤安排章节。第1章介绍了服务商在和企业客户签订合同以及交付项⽬之前要完成的需求沟通和确认⼯作；第2章说明应⽤实现的抽象层次选择，以决定应⽤通⽤性和具体性⽅⾯的平衡点；第3章和第4章是本书的核⼼章节，介绍如何使⽤ APaaS来实现具体的企业应⽤，期间我们会通过⼀个实例贯穿；第5章介绍应⽤测试的环节；第6-9章介绍APaaS应⽤实现的配套能⼒，分别是配置管理，集成管理、交付物和未来的变更管理；第10章我们提供了⼀个评估APaaS应⽤实现⼯作量的依据；第11章介绍汉得项⽬实施⽅法论，提供⾯向复杂项⽬的完整项⽬管理⽅法。

本书凝聚了集体的智慧，其作者涵盖：明道云团队的况育军、顿唯、⻩晟昊、李恩涛、史丰源、任向晖、⻨壁瑜等⼈；还有汉得信息团队的赵贤进、谢俊、⻩开等⼈。

主编 况育军 2024年6⽉

第⼀章 需求分析和确认实施范畴

我们从前导性的需求分析开始，因为这个步骤⼀般都发⽣在和客户确认服务合同之前。这⼀步骤完成的质量既关系到客户成交率，也关系到成交以后的交付成功率。

⽬标

不同客户对售前阶段的需求分析配合程度是不⼀样的。有的因为有相关购买经验，所以能够提供结构很完善的需求⽂档。但是⼤多数客户只能描述概要的商业需求，还有⼀些会⽤各种形式提供⼀些需求和解决⽅案的混合体。这是商业的现实，既是挑战，也是机会，尤其对于需求含糊的客户。服务商如果能够在售前阶段引导客户建⽴清晰的需求和⽬标，反⽽能够和客户建⽴更强的信任度，促进成交。

另外，APaaS实施⽅式提供了两个⾮常重要的优势条件，使得我们在沟通和确认需求的时候不⾄于像传统的定制开发合同那样难。服务商可以充分利⽤这两点优势：

1. APaaS可以快速搭建应⽤框架，甚⾄在售前阶段提供个别可以投⼊真实操作的演示环境。这个能⼒有助于让客户眼⻅其实，建⽴信任，还可以通过这个⽅式引导出客户的完整需求。

1. APaaS实施具备⾜够强的灵活性，扩展和变更的成本相对⽐代码开发要低很多。所以，我们可以适当压缩售前阶段的需求分析细粒度，将更为具体的问题放到实施过程中，通过蓝图计划（⻅后⽂）来完成。

由此可知，APaaS实施项⽬的需求分析⽬标可以设定得更为简明和实⽤。它不涉及过于细节的需求沟通，通常能够在很短的时间内完成。我们可以归纳出需求四要素，分别是商业价值（Value）， ⻆⾊（Role）和流程（Process）以及业务数据对象（Data）。有经验的明道云实施专家已经看出，在这需求四要素中，后三个已经和应⽤构建模块（⻆⾊，⼯作流，⼯作表）直接相关。为了让读者便于记忆这个需求分析的要素组合，我们将其称为实施需求分析奥迪环。

步骤

确定应⽤的商业价值和⽬标

从事技术服务的⼈员⼀定要懂得将⾃⼰提供的专业服务和客户的商业⽬的对⻬。客户需要构建CRM应⽤是为了提⾼销售转化率，有序管理客户资产，衡量销售团队和成员的绩效。客户上⻢资产管理，是为了提⾼资产的利⽤率和财务合规。客户委托搭建项⽬管理系统是为了准确跟踪项⽬进度，保证项⽬完成及时率。

虽然实施⼈员可能拥有相关的业务经验，但是在任何定制项⽬中，都应该不吝笔墨地把软件投资背后希望得到的商业价值回报表达完整和准确。例如，下图是某个客户在发出委托时提供的信息，他们将需求的商业价值表达为急需解决的问题。其实只要稍微转换⼀下表达⽅式，就是项⽬交付所能给客户带来的商业价值。

要特别注意，在企业软件项⽬中，虽然客户会确定⼀个项⽬性质，但是实施服务商并不能通过字⾯意思的理解来确认实施的范畴。⽐如，某些设备⼯程类企业的CRM项⽬往往需要覆盖项⽬⼯程的售前、交付和售后全过程。在这个CRM中，采购、⼯时、⼯单等要素都可能需要包含；⽽在另外⼀个细分市场，CRM应⽤可能只需管理客户档案、订单、产品、回款和佣⾦等纯粹的商务要素。

从使⽤⻆⾊到业务流程和业务数据对象

需求分析的第⼆步是通过⻆⾊枚举，挖掘完整所涉及的业务流程和业务对象。为什么要通过⻆⾊先导呢？因为⻆⾊在客户企业中相对较少，能够⽐较⽅便地穷举，所以通过⻆⾊来梳理数字化应⽤的需求是最能够保证完整度的。⽽且⼀个业务⻆⾊会明确对应出⼀系列的业务流程。这些流程⼜能够梳理出涉及的数据对象。通过这个沟通和思维链条就能够把系统需求覆盖得相对完整。

以下是⼀些⻆⾊和业务流程的组合举例：

在⼀个典型的CRM应⽤中，我们可以按此⽅式列举出部分⻆⾊和业务流程，以及这些流程所关联的业务数据对象。在这个过程中，我们不必太介意流程的细节和数据对象的详情。

⻆⾊	业务流程 （通常是动宾结构）	业务数据对象（名词）
销售专员	创建和更新线索	线索
	创建跟进⽇志	⽇志
	创建报价	报价
	创建和更新商机	商机
销售总监	批准报价
	创建和维护产品	产品
	创建和维护价⽬表	产品价⽬表

其实，很多软件项⽬的需求⽂档⼤体都反映了以上信息，我们介绍的⽅法论强调了通过⻆⾊列举流程的完备性，同时使⽤了⼀个统⼀和规范的表达⽅式。

为了简化分析，查询信息类的业务流程⽆需表达在此范围之内。因为在APaaS⾥，数据查询、搜索、筛选和排序等能⼒都是默认提供的。不过，有⼀定特殊性的需求则需要额外列出，⽐如“查阅报表”需要利⽤跨表查询能⼒来实现。

另外，这个结构⽐较适合描述⼀个特定业务领域的应⽤需求，⽐如明确的销售管理应⽤。如果遇到综合性很强的应⽤需求，就需要按照职能板块先分类，再执⾏这⼀步。这既有利于有序梳理需求，也让需求⽂档的读者感觉更有秩序。⽐如在资产管理的综合应⽤场景下，采购、财务、库管、维保等管理领域是可以⾸先区分开来的。

基于以上内容完成SOW（Scope of Work）

完成第⼆步后，就可以⽤⼀个规范的⽂档将应⽤需求整理出标准的⼯作范畴约定，从⽽建⽴⼯作量衡量和报价的基础。SOW⽂档最终也可以成为与客户签订合同的附件材料。

SOW⽂档应该包含以下内容：

1. 项⽬简述：概括地说明项⽬的内容和预期达到的商业⽬标。
2. 项⽬范畴：概括地说明项⽬实施的组织和商业流程的范畴。
3. 实施内容：通过专⻔的表格有序列出项⽬包含的具体实施内容。它⾄少应该包括具体的组织⻆⾊列表，对应的商业流程列表和涉及的商业数据对象列表。这是实施内容最⼩化表达的⽅式。
4. 时间表：列出项⽬实施中主要节点的交付时点，包括期中交付、测试、最终交付等⾥程碑。这些⾥程碑可以根据项⽬的规模和复杂度按需设置。
5. 项⽬成员：列出双⽅参与本项⽬的成员和分⼯。
6. 交付物列表：列出项⽬交付时，除了应⽤本体以外，其他需要同步交付的材料，包括软件使⽤说明、培训⽂档、视频等。
7. 交付后的技术⽀持安排。

第⼆章 选择应⽤的抽象层次

如何理解应⽤的抽象层次

理解应⽤抽象层次，⾸先要理解“抽象”是什么意思。“抽象”的定义，是从众多事物中抽取出共性特征，构建概念的过程，与之相对的是“具象”。

APaaS产品本身的设计研发也是⼀个从具象到抽象的过程。我们通过把具象的代码语⾔，抽象成可⾼度复⽤的模块组件，让⽤户能通过拖拉拽的⽅式实现应⽤，⽆需处理复杂的代码逻辑，降低了⽤户上⼿搭建应⽤的⻔槛。

同样地，在具体的应⽤构建过程中，抽象化的设计可以满⾜客户业务变更的灵活性要求，也能让应⽤在⾏业客户⾥具备更⾼的复⽤性价值。程序员们常说的把代码“写死”或把代码“写活”，其实就分别对应了具象逻辑和抽象逻辑。当说⼀个代码逻辑是“写死”时，通常意味着该代码逻辑是固定的，它只为了满⾜某⼀个具体需求⽽编写。相对⽽⾔，把代码“写活”是指代码逻辑可以通过⼀些参数来灵活配置，可以在不修改代码的前提下，仅调整参数值，就能实现不同的需求。

对于明道云这样的APaaS产品，虽然可以完全不⽤写代码来实现应⽤，但在应⽤的抽象层次上依然存在“写死”和“写活”的差异。当代⼊ APaaS应⽤搭建的场景时，我们可以把管理员后台配置操作，⽐如表单字段的配置，看作代码编写的过程。

举个例⼦，CRM⾥对于客户跟进阶段（意向阶段、⽴项阶段、谈判阶段等）的定义，可以抽象成⼀个单选字段，也可以定义⼀张“客户跟进阶段”表，其他表单可以关联这张“客户跟进阶段”表，并以下拉列表的方式来呈现。

⽆论是以下拉列表⽅式呈现的关联记录，还是普通的单选字段，⼆者在⽤户界⾯的展现效果是很相似的。唯⼀的区别在于，如果是以单选字段来记录跟进阶段，必须由客户⽅的应⽤管理员在后台配置才⾏；⽽以表单数据来记录阶段的话，普通⽤户通过添加数据和编辑数据的⽅式就能修改配置，操作⻔槛⼤⼤减低。

另外需要说明的是，明道云的表单数据和字段配置都可以随应⽤⼀同导出给客户。应⽤包导⼊新的环境后，同样可以使⽤我们预先定义好的跟进阶段，也可以⾃定义修改。

图2-1：单选字段展现效果

图2-2：关联记录展现效果

图2-3：单选字段配置界⾯

图2-4：关联记录配置界⾯

⾼抽象的优势和弊端

既然抽象的功能模块能带来更⼤的灵活性，那是不是意味着应⽤的抽象层次越⾼越好？当然不是，任何事情都有两⾯性，⼀个⾼度抽象的系统并不全是优点，也会带来⼀些弊端，所以需要我们去综合考量平衡，下⾯分别列举⾼抽象层次存在的优势和弊端。

⾼抽象的优势

灵活性：⾼抽象的设计使系统的不同部分解耦并相对独⽴，让系统具备更强的灵活性和扩展性。当业务不断发展，需求发⽣变化时，可以通过修改配置参数来灵活响应，⽽⽆需对核⼼的系统逻辑进⾏⼤规模的修改。

可扩展性：当有新的需求出现，需要扩展新功能时，通过抽象和配置化的设计，新功能可以以配置模块或规则的形式添加到系统中，由此降低对现有功能的影响，并⽀持系统的持续演进。

可复⽤性：⾼抽象的设计能够将通⽤的逻辑和功能封装为可复⽤的组件或模块，这种复⽤性可以省去⼤量“重复造轮⼦”的⼯作，提升开发效率。

可维护性：⾼抽象的设计提供了在前台维护系统的能⼒，允许⾮技术⼈员通过配置和参数设置来调整系统逻辑，不需要直接修改后台逻辑或代码，降低了出错的⻛险，简化了维护过程。

可调试性：⾼抽象的设计可以使测试和调试变得更加容易。通过调整参数或配置选项，可以模拟不同的测试场景，验证系统在不同条件下的⾏为。另外，还可以通过关闭或启⽤特定的功能来隔离问题，从⽽更有效地进⾏故障排查和调试⼯作。

⾼抽象的弊端

复杂性：为了实现更⾼的灵活性和可配置性，应⽤可能变得更加复杂，特别是在处理复杂业务逻辑或配置管理时。引⼊参数、配置选项和对其他模块的依赖，可能会增加应⽤的复杂性和维护成本。另外，⾼度抽象的应⽤，往往实现起来难度更⾼，对架构设计⼈员和开发⼈员都有更⾼的要求，这也意味着需要投⼊更⼤的⼈⼒成本。

理解难度：较⾼的抽象性可能导致配置选项的增加，也会引⼊更多抽象的概念，增加系统的理解难度。对于开发⼈员和⽤户来说，可能需要更多的时间和努⼒去理解系统逻辑，掌握配置和使⽤系统的⽅法。

错误和⼀致性：当系统变得⾼度抽象可配置时，错误的配置可能导致系统⾏为异常，确保正确配置和保持⼀致性也成为了挑战。另外，还需要考虑如何管理和验证配置选项，以避免因⽤户配置错误⽽带来的潜在⻛险。

性能负担：为了把逻辑“写活”，提供更⼤的灵活性和可配置性，系统可能需要引⼊条件判断、参数传递、数据查询等机制。这些额外的运⾏操作可能带来⼀定的性能负担，尤其是在有⾼并发或⼤规模数据的应⽤中。

抽象度的选择依据

理解了⾼抽象的优势和弊端后，我们知道在应⽤设计阶段，需要慎重考虑应⽤的抽象度，使之处于合理的区间。下⾯，我们从宏观维度和微观维度，分别提供应⽤设计抽象度选择的指导性建议。

宏观维度将从企业规模、企业战略、企业软件⻔类这⼏个维度⼊⼿，让实施顾问能够以此奠定整个应⽤抽象层次的基调。

微观维度将提供更加细致的判断依据，让实施顾问在⾯对具体需求的时候，能够判断是否应当做抽象化设计。其中：

• “抽象的必要条件”将阐述在灵活性、普遍性、变动性等前提下，需求有必要通过抽象设计来实现，并提供典型案例说明。
• “抽象程度的限制”将阐述在复杂度、成本预算、项⽬时间等限制下，我们应慎重考虑抽象层次，避免过⾼程度的抽象设计。

宏观维度

企业规模

⾯向的企业规模越⼤，应⽤越难被抽象；反之，⾯向的企业规模越⼩，应⽤越容易被抽象。

⼤规模企业通常具有复杂的组织结构和业务流程，不同部⻔和业务单元可能有不同的需求和要求，需要考虑各种不同的业务规则、流程和数据处理⽅式。这种多样性的需求使得开发⼀个抽象的软件应⽤更加困难。

同时，⼤企业往往有多个现有系统和平台，这些系统可能已经在不同的部⻔和业务领域中使⽤。在开发软件应⽤时，需要根据现有系统的实际业务过程，制定与各个系统的集成⽅案。

此外，有的⼤型企业还要遵循⾏业特定的合规性要求，这些要求是通⽤软件⽆法覆盖到的。因此，⼤型企业往往倾向于采⽤定制化的软件解决⽅案，很难指望⽤⼀个软件满⾜所有需求。

相⽐之下，⼩规模企业通常具有较简单的组织结构和业务流程。在这样的环境中，软件应⽤的需求可能相对简单且相似，抽象化就可以带来优势。通过将通⽤的业务逻辑抽象化，可以开发出可重复使⽤的模块或系统，从⽽提⾼开发效率和降低成本。

企业战略

企业战略的差异化程度越⾼，应⽤越难被抽象；反之，企业战略的同质化程度越⾼，应⽤越容易被抽象。

企业采取差异化战略时，通常会追求在市场上与竞争对⼿的区别和差异化，这种差异化可能体现在运营模式、业务流程等⽅⾯的独特性。在这种情况下，为了⽀持企业的差异化战略，软件应⽤需要与企业的差异化要求密切匹配。抽象化的软件应⽤往往⽆法准确地满⾜企业独特的需求，需要更加定制化、精细化的解决⽅案。

相⽐之下，当企业的战略同质化程度较⾼时，企业通常更倾向于通过标准化流程来追求成本效益和规模经济。在这种情况下，企业更倾向于采⽤通⽤的、标准化的解决⽅案，以实现效率和⼀致性，软件应⽤更容易被抽象化。这种抽象化的应⽤可以被多个部⻔或业务单元共享，提⾼了软件的可复⽤性，同时也降低了多客户情况下的实施成本。

企业软件⻔类

不同⻔类的企业软件被抽象的难度也不⼀样。有些像CRM之类的软件就很容易被抽象，不同客户的需求相似度较⾼，所以市场上这类软件产品的数量⾮常多。⽽像MES、TMS等这类复杂度很⾼的软件就很难被抽象，不同客户对这类软件的需求离散度很⾼。因此，软件服务商在交付这类软件的时候，就不要试图通过抽象设计来复⽤于不同客户。

我们提供了⼀个表格供实施⼈员参考，在表格中列举了不同⻔类的企业软件及其被抽象的可能性（分值1-9），分数越⾼则代表⾼抽象的可能性越⾼，如下图所示。请注意，以下评分和理由仅供参考，具体评估软件的抽象化程度需要考虑多个因素，包括软件的定制化需求、⾏业特点和企业的个性化需求。

英⽂简称	全称	中⽂名称	释义	抽象的可能性	理由
ERP	Enterprise Resource Planning	企业资源计划	集成管理企业核⼼业务流程的软件系统	4	ERP涉及多个业务领域集成，抽象和复⽤的难度较⾼。
CRM	Customer Relationship Management	客户关系管理	管理和优化企业与客户关系的软件系统	8	CRM主要关注客户管理和营销领域，相对于其他软件⻔类更容易被抽象为可复⽤产品。

HCM	Human Capital Management	⼈⼒资源管理	管理和优化企业⼈⼒资源的软件系统	6	HCM涉及⼈⼒资源的多个⽅⾯，包括招聘、假勤、薪 资、绩效管理等，不同企业的管理制度有差异，但部分模块可抽象成通⽤能⼒，难度适中。
SCM	Supply Chain Management	供应链管理	管理和优化企业供应链流程的软件系统	3	SCM涉及供应链各个环节的协调和优化，抽象和复⽤的难度较⾼。
PLM	Product Lifecycle Management	产品⽣命周期管理	管理和协调产品从设计到退役的全过程	4	PLM涉及产品的全 ⽣命周期，包括设计、制造、销售 等，抽象和复⽤的难度较⾼。
MES	Manufacturing Execution System	制造执 ⾏系统	监控和控制⽣产制造过程的软件系统	2	MES需要与⽣产线紧密集成，处理实时⽣产数据和调 度，抽象和复⽤的难度较⾼。
DMS	Document Management System	⽂档管理系统	管理和控制企业⽂档的软件系统	5	DMS涉及⽂档的存储、检索和版本控制，抽象和复⽤的难度适中。

LMS	Learning Management System	学习管理系统	管理和交付企业培训和学习的软件系统	6	LMS涉及学习管理和在线培训，抽象和复⽤的难度适 中。
TMS	Transportation Management System	运输管理系统	管理和优化物流运输流程的软件系统	2	TMS涉及物流运输的各个环节，抽象和复⽤的难度较 ⾼。
EAM	Enterprise Asset Management	企业资产管理	管理和维护企业资产的软件系统	3	EAM涉及资产管理和维护，抽象和复 ⽤的难度较⾼。
PIM	Product Information Management	产品信息管理	管理和统⼀企业产品信息的软件系统	5	PIM涉及产品信息的集中管理，因为细分市场差异，抽象和复⽤的难度较 ⾼。
WMS	Warehouse Management System	仓库管理系统	管理和优化仓库运营的软件系统	2	WMS涉及仓库运营的各个环节，抽象和复⽤的难度较 ⾼。
BPM	Business Process Management	业务流程管理	分析、优化和 ⾃动化企业业务流程的软件系统	6	BPM关注业务流程的管理和优化，抽象和复⽤的难度适中。

ERM	Enterprise Risk Management	企业⻛险管理	管理和控制企业⻛险的软件系统	4	ERM涉及企业⻛险管理的各个⽅⾯，抽象和复⽤的难度较⾼。
SFA	Sales Force Automation	销售能 ⼒⾃动化	⾃动化和优化销售流程的软件系统	7	SFA涉及销售流程的⾃动化和优化， ⼀般包含CRM中的 ⼀部分环节，抽象和复⽤难度较低。
PM	Project Management	项⽬管理	计划、组织和控制项⽬执⾏的软件系统	6	项⽬管理涉及项⽬计划、资源分配、进度控制等⽅⾯，具有⼀定的复杂 性，但在不同⾏业的项⽬管理中存在 ⼀定的通⽤性，可以部分抽象为可复 ⽤的软件。

微观维度判断

抽象的必要条件

需求的灵活性。如果这个需求⾮常灵活，需要满⾜多种可能性，就会导致我们很难在写死的代码逻辑或是后台逻辑⾥穷举所有的可能性。这个时候，把它抽象成配置化能⼒就很有必要。我们可以额外提供⼀张配置化表单，让⽤户可以通过添加记录的⽅式来增加新的规则，业务表单只需要读取这张配置表单就能遍历所有规则。

例如，有些公司的销售提成⽐例⾮常灵活，提成⽐例的决定维度可以是不同的销售商品、订单类型、销售职级、销售⻆⾊、销售业绩达成、回款周期等等。这些维度并不是相互独⽴的，它们是可以排列组合后得到多种提成规则的。10类商品10种订单类型10个职级就有1000种组合，排列组合的数量随着维度的增加呈指数级增⻓。我们不可能在后台逻辑⾥去枚举所有的排列组合，所以合理的⽅式是抽象出⼀张配置表单，来记录所有的排列组合以及它们对应的提成⽐例。

需求的普遍性。如果这个功能点在不同的应⽤场景中经常被使⽤，且需求⼤体相似，具备通⽤性，那么将其抽象出来做成模块化能⼒会更有意义。这样可以避免在每个应⽤中都进⾏独⽴开发和定制，提⾼开发效率。

例如，CRM⾥⾯的销售漏⽃管理就具有很强的通⽤性，因为不同的⾏业都可能需要在获客转化上做精细化管理。所以，我们可以把客户成交的各个环节抽象出来，例如分成线索、商机、报价、订单、收款，也是业内常说的Leads to Cash。市⾯上⼤多CRM软件都是这个逻辑，只是⼀些概念名词上可能会有异化，⽐如有些分为“潜在客户”、“意向客户”、“成交客户”，有些⼜分“公海池”、“私有池”等等，但逻辑原理都类似，Salesforce就是这个模型的典型代表。明道云的应⽤库⾥就有⼀个叫“Salesforce克隆”的应⽤模板，就是按照Leads to Cash的逻辑来设计搭建的。

需求的易变动性。如果这个功能点的需求经常变动或需要根据具体情况调整，那么抽象成配置化能⼒将⾮常有⽤。通过配置化能⼒，你可以在不修改后台逻辑或代码的情况下灵活地调整功能，满⾜不同⽤户的特定需求。

例如，在CRM⾥针对销售员的销售业绩⽬标，不同企业对销售员的销售⽬标的衡量维度和数值都会有差异，同⼀客户在不同发展阶段也会提出不同的销售⽬标，那么我们在设计系统时把销售业绩⽬标“写死”就明显不合适了。考虑到业绩⽬标这个对象未来变动的可能性，我们应该把它抽象成可配置化的能⼒。

⽤户的个性化需求。如果不同的⽤户对这个功能点有不同的个性化需求，那么抽象成配置化能⼒就可以让⽤户根据⾃⼰的特定需求定制。既可以提升⽤户满意度，⼜能使应⽤适应不同⽤户的要求。

例如，如果客户对系统有类似这样的明确要求：“我希望每个员⼯可以⾃主制定个⼈的OKR”，或是“我希望团队Leader可以⾃⼰选择下属的绩效考核维度和权重⽐例”。在这种情况下，这个功能的抽象层次本身已经是⽤户需求的⼀部分了，如果我们接受这个需求，那就有必要做成可配置化的能⼒。

抽象程度的限制

复杂度的限制。如果这个功能点的实现⾮常复杂，可能涉及多个业务规则和计算逻辑，抽象成配置化能⼒可能会增加系统的复杂性和难度。在这种情况下，“写死”逻辑可能更简单可⾏。

客户预算和资源限制。了解甲⽅提供的预算和能提供的资源限制是⾄关重要的。在设计系统时，我们需要在这些限制内进⾏合理的规划和决策，以充分发挥有限的资源。简⽽⾔之，如果客户只有造⽊筏的预算，就不必去规划⼀艘航空⺟舰。

⼈⼒和时间限制。在客户预算充⾜的前提下，我们也要考虑项⽬的⾥程碑计划、交付时间等因素。上⽂在⾼抽象的弊端⾥提到，它对交付团队的⼈员配置有更⾼要求。我们需要根据项⽬的时间限制，评估所需的开发⼈员数量、技能要求以及项⽬进度安排，确定有充⾜的⼈⼒资源可以投⼊到项⽬上，保证项⽬如期交付。

总结来看，如果功能点在多个应⽤场景中普遍存在且相似，需求经常变动，⽤户有个性化需求，⽽且实现的复杂度和成本是可控的，那么将其抽象成配置化能⼒会更合适。相反，如果功能点的需求离散度很⾼，不具备通⽤性，实现⾮常复杂，抽象的成本很⾼，客户预算也有限，那么写死逻辑可能更为简单有效。当然，最终的判断应基于具体的功能需求和项⽬实际情况。

第三章 设计应⽤的实施蓝图

在传统软件交付的设计蓝图中，通常会包含需求分析、功能模块、时间计划、⻛险管理、系统集成⽅案、运维部署⽅案等⽅⾯。但是对于 APaaS应⽤的实施蓝图，我们希望它更加简化和聚焦，更加专注于需求分析和应⽤⽅案设计。

APaaS平台（Application Platform as a Service）本身提供了应⽤平台及服务的⼀站式解决⽅案，平台会负责基础设施的管理、可⽤性和性能的保障。因此，APaaS应⽤的实施⼈员在设计蓝图时⽆需详细考虑平台层的运维部署，只需要专注于应⽤的开发和业务需求的实现。另外，在项⽬时间节点和⻛险管理⽅⾯，由于这些是项⽬管理的常规⽅法，所以在APaaS应⽤的实施蓝图中，我们也不做过多赘述。

关于系统集成⽅案，APaaS应⽤的实施过程可能会涉及与其他系统的集成，但与传统软件交付相⽐，APaaS应⽤通常会使⽤平台提供的集成⼯具和API，更轻松地实现与其他系统的集成。这个在后续章节会详细介绍，本章节不展开讨论。

简⽽⾔之，我们认为APaaS应⽤的实施蓝图应该回归它的本质，提供类似于建筑设计图纸的功能，以指导实施⼈员完成从业务需求到应⽤⽅案的设计过程。这样，实施⼈员即使没有参与到前期的需求分析，也能根据实施蓝图的设计指导，知道如何构建整个应⽤，并与客户需求相符。

蓝图示范

如下图，我们以销售管理场景为例，绘制了⼀张通过APaaS构建CRM应⽤的设计蓝图。通过这张蓝图，实施⼈员能够清晰地知道这个应⽤需要实现哪些功能模块，以及每个模块的边界在哪⾥。

另外，关于蓝图的构建⽅式，我们摒弃了功能强⼤的绘图软件⽽采⽤了最朴素的Excel表格形式，不追求界⾯的华丽，只为极致的易⽤和⾼效。这⾥，我们提供⼀个Excel模板以供读者下载参考： http://ob4.cn/BP

作为⼀张设计图纸，它并不⼲涉具体的施⼯过程，因为不同施⼯⼈员的作业⽅式可能会有差异，我们也不需要教施⼯⼈员如何具体施⼯。

换⾔之，这张实施蓝图只交代系统框架和实施边界，不会把所有的实施细节都囊括进去。实施⼈员需要根据⾃⼰的⾏业Know-how经验，去补充具体的表单字段、数据流转逻辑等细节。

关于这些实施细节，我们会在后续描述实施蓝图绘制过程时提供⼀些参考范例，例如流程图、数据字典，但不会详细展开。我们相信有经验的实施⼈员完全有能⼒⾃主完成这些细节。

完成蓝图设计的⽅法

本书主要介绍⼀种设计蓝图的⽅法——“RPIC”信息架构⽅法论。我们先了解这个⽅法论的定义和原理，再依据原理进⾏流程图绘制、⻆⾊流程和信息梳理，最后抽象出系统内容。

RPIC信息架构⽅法

RPIC是Role、Process、Information和Content的缩写，意思是⻆⾊、流程、信息和内容。它是⼀个循序渐进的分析计划过程，从企业管理和运营⻆⾊的分解出发，为每个涉及的⻆⾊（可能包括外部⻆⾊）分析他们在业务活动中需要完成的流程和接触的信息（数据）。当枚举出所有的流程和信息后，我们就能够取得它们的不重复并集，再通过并集内容分项规划数据架构、⻆⾊权限、统计报表和⼯作流程四项核⼼架构部分。

接下来，我们会以⼀个典型的销售管理场景为例，描述如何使⽤RPIC⽅法，完成从客户需求到实施蓝图的设计过程。

绘制总览流程图

我们可以通过销售管道Leads to Cash的顺序来绘制总览流程图，从客户线索开始，到订单回款结束。需要说明⼀下，下⾯的泳道图呈现⽅式只是作为示范，这张图的⽬的是更好地描述客户需求，辅助我们后续梳理⻆⾊（Role）和流程信息触点（Process&Information），所以读者可以不必拘泥于流程图的展现形式，⽤Word、Excel、 Powerpoint，甚⾄⼿绘草图都⾏。

梳理不同⻆⾊流程和信息触点

通过以上流程图，我们可以很明确地获得以下⻆⾊

• 客户（外部）
• 销售
• 财务

其中销售和财务岗位是内部职能⻆⾊，客户是企业外部⻆⾊，如果 CRM系统需要和外部⻆⾊进⾏交互，则需要考虑通过外部⻔户来管理这类⻆⾊。

如果我们分别从运营⻆⾊和管理⻆⾊两个视⻆分别来看，那销售可以细分为执⾏具体销售任务的销售员和管理销售经营数据的销售主管。另外，我们还需要增加⼀个⽼板的⻆⾊，需要管理所有数据，查看公司整体经营情况。通过代⼊不同⻆⾊的视⻆，去枚举他们在实际业务中的流程和信息触点。在具体的实施项⽬中，这个枚举过程可能要在完成客户访谈、实地调研等环节之后才能完成。

在本案例，我们通过枚举可以得到以下信息。在这些信息中，我们⽤红⾊标注出了数据对象。

销售员视⻆：

销售主管视⻆：

⽼板视⻆：

抽象成系统内容

得出不同⻆⾊下的业务流程和信息触点后，我们开始把这些要素转化、抽象成系统蓝图的内容。这个过程将分为六个步骤。

第⼀步：列举数据对象

除了上述红⾊部分标注出来的数据对象，我们还需要增加⼀个订单明细的对象。明细表扩展是业务数据结构中常⻅的⼿段，它能够提⾼业务系统的灵活性。以订单为例，如果⼀个订单表没有订单明细，那就意味着⼀个订单就只能记录⼀种产品的购买信息。如果客户⼀次性订购多个产品，就不得不分开多个订单，这显然是不合理的。

在明道云应⽤中，数据对象其实就⼀⼀对应到⼯作表。有了数据对象之后，我们还需要枚举每个数据对象有哪些数据窗⼝，即有哪些视图。

视图的功能主要有两个，⼀个是定义数据的呈现⽅式，⽐如表格、看板、画廊、⽇历等⽅式；另⼀个是数据过滤，通过窗⼝的⽅式切分不同的数据。在枚举视图的时候，我们可以从这两个视⻆出发，根据我们对数据呈现⽅式和数据切分的需求来决定需要哪些视图。⽐如，对于客户商机，我们可能需要根据商机阶段来切分已成交和跟进中的商机。那么我们就创建⼀个阶段看板视图，让销售员能够在⼀个窗⼝直观地看到所有商机⽬前的跟进阶段。

基于以上思路，我们可以得到下⾯的数据对象（⼯作表）和它们的数据窗⼝（视图）。

• 客户档案：全部客户、我的客户
• 联系⼈：全部联系⼈、我的联系⼈
• 客户线索：全部线索、公海线索、新线索、合格线索、不合格线索
• 客户商机：全部商机、新商机、跟进中、预计本⽉成交、已成交、搁置中
• 跟进记录：全部、跟进中、已成交、已丢单
• 销售员分配规则：全部、启⽤、禁⽤
• 订单：全部订单、草案订单、审批中、已⽣效、已核销、我的⽣效订单
• 订单明细：全部、草案、审批中、已⽣效、已核销、我的⽣效明细
• 商品信息：全部、启⽤、禁⽤
• 预计收款：全部、未付清、已付清、已逾期
• 收款登记：全部、本⽉收款
• 开票记录：全部、待开票、已开票

第⼆步：细化关联关系

明确了数据对象后，接下来我们将通过ER图细化数据对象之间的关联关系。⼀般来说，ER图还会描述数据对象的字段属性，但出于实操性的考虑，我们省去对字段的枚举，取⽽代之的是在后续⽤Excel列举所有字段。

第三步：细化字段内容

通过Excel或者任意表格⼯具，我们详细列举出每个表单的字段。完成之后，再做⼀个⾏列置换的处理，就可以通过明道云直接导⼊Excel创建应⽤和表单。

图：数据字典

图：⾏列转置后⽤于导⼊的格式

第四步：完善可视化报表

不同⻆⾊对于报表的需求可能会有差异。例如，销售员更关注⾃⼰的业绩达成和业绩排名，财务则更关注订单的回款和坏账⻛险。所以，我们需要罗列每个⻆⾊需要看到的统计报表，将统计报表和快捷操作⼊⼝放在⾃定义⻚⾯上，形成数据驾驶舱。当然，并不是说有多少个⻆⾊就添加多少个驾驶舱，实施⼈员可根据实际需求快速调整。

第五步：完善⻆⾊权限

我们在前⾯列举了数据和报表，现在只需要列举⻆⾊，并把数据和报表的权限赋予每个⻆⾊即可。简单来说，就是确定每个⻆⾊能看到哪些报表，能对哪些视图的数据进⾏增删改查操作。增删改查操作是对应全部数据，还是和⾃⼰相关的数据（作为加⼊者），⼜或是⾃⼰有所有权的数据（作为拥有者）。

虽然在Role Process&Information（⻆⾊的流程和信息触点）环节，我们已经列举了业务活动中的⻆⾊，但在Content（内容）环节落到系统⻆⾊的时候，还需要⼀些细微调整。⽐如，销售员分为⼤客户销售和普通销售，他们的权限可能有差异，需要拆分成两个⻆⾊。

在本章节的案例中，我们额外考虑企业外部客户这⼀⻆⾊。他们可能需要在系统⾥维护⾃⼰的⼀些公司信息、公司联系⼈，查看⾃⼰相关的订单、开票记录等，所以我们通过外部⻔户去完善这类外部⽤户的⻆⾊权限。

第六步：补充流程细节

在总览流程图⾥，我们交代了销售管理的基本业务逻辑，它总体是⽐较粗略的，还需要挖掘更多的细节流程才能⽀撑我们完成⾃动化⼯作流的构建。

⽐如在总览流程图⾥，我们只交代了签约订单这个环节，但实际上签约订单可以细分为订单录⼊、发起审核、执⾏审核三个流程。在实际的应⽤搭建过程中，实施⼈员还要考虑⽤户的交互⽅式和后台的数据处理流转逻辑等问题，⽐如线索⾃动分配的具体机制。关于搭建细节设计这⼀部分，我们交由专业的实施顾问根据客户需求⾃由发挥，不在实施蓝图中做描述。

⼩结

还记得下⾯这张蓝图吗？把我们上⾯梳理的Role、Process、 Information、Content组合起来，就是这张蓝图。我们通过以终为始的⽅式，从需求的参与⻆⾊出发，⼀步⼀步梳理，得到我们最开始展示的这张蓝图。通过这张蓝图，专业的实施顾问已经知道该如何去搭建这个应⽤了。

汉得客户案例实践

我们来结合实际客户案例，来展示如何通过RPIC⽅法完成客户实施蓝图构建。以下案例来⾃汉得某客户项⽬的POC部分内容，虽然实施⼈员在进⾏系统架构设计时更多可能是根据其专业经验，但是我们在拆解其设计思路后，发现与RPIC的信息架构⽅法⾮常契合。

绘制总览业务流程图

与客户的初步沟通后，实施⼈员判断客户业务场景属于典型的直发销售业务：

在实际业务中，并⾮所有的销售都是企业内部发出的，为了节约成 本、提⾼周转效率、甚⾄应急销售，企业往往将外部企业也作为⾃⼰销售供货的来源之⼀，通过采购后直接发货的⽅式，将其他企业的货物直接销往⾃⼰的客户。这种销售业务模式，IT系统中称之为直发销售（Dropship Sale）。

直发销售业务的经典系统流程如下图：

上图只是粗略的描述了业务流程，还有很多细节待和客户进⼀步沟通后补充完善。例如，本公司还可以再细分更多⻆⾊，部分流程节点还可以再拆分成多个⼆级流程等。

在与客户进⾏深⼊沟通交流后，充分了解客户的具体业务流程或特殊需求，在上图基础上完善更多细节，就形成了⼀张更加完整的业务流程图。

梳理不同⻆⾊流程和信息触点

基于以上业务流程图，我们可以枚举所有的⻆⾊，以及每个⻆⾊涉及的流程和信息触点。

⾓⾊（Role）	流程和信息触点（Process&Information）
外部客户	提出产品需求
	选品确认
公司销售	录⼊销售需求单
	发送询价单，查看供应商报价单
	创建销售报价单，创建客户选品单
	创建打样申请单，查看样品发货单，创建样品收货确认单
	创建销售订单，补充采购订单受控信息部分
	创建定⾦单
	查看交期变更通知单，查看完⼯申请
	创建验收申请，查看验收报告
	创建付款单
	查看发货通知单，创建收货确认单
	查看返⼯通知
公司采购	查看销售需求单
	创建询价单，查看供应商报价单
	创建打样申请单，查看样品发货单，创建样品收货确认单
	查看销售订单，创建采购订单
	创建定⾦单
	查看交期变更通知单，查看完⼯申请
	创建验收申请，查看验收报告

	创建付款单
	查看发货通知单，创建收货确认单
	查看返⼯通知
公司质检	查看销售需求单
	补充采购订单品质要求部分
	查看验收申请单
	创建验收报告
公司财务	⽀付采购款
	查看返⼯通知单
外部供应商	接收询价单，创建报价单
	接收打样申请单，创建样品发货单
	查看样品收货单
	接收采购订单
	创建交期变更通知单，创建完⼯通知单
	查看验收报告，接收付款通知单
	创建发货通知，查看返⼯通知单

抽象成系统内容

所有⻆⾊涉及到的流程和信息触点的并集，就是构建系统所需的全部要素，我们需要提取这些要素，并转换为系统模块。出于简洁性考虑，以下只展示系统架构最关键的数据对象和业务流程，⾄于视图、报表、权限等同理可得，这⾥不做过多赘述。

梳理数据对象并绘制ER图

梳理⼯作流清单

⼯作流名称	描述
销售需求单创建	销售登记销售需求单，邀请质检⼈员填写品质要求；
发起询价	创建询价单后，通知供应商，邀请其报价；
供应商报价	供应商报价后，通知采购、销售查看报价。
打样申请	创建打样申请单，通知供应商
样品发货	供应商样品发货后，通知销售
采购单创建	采购订单创建后，邀请销售补充受控信息、质检补充品质要
采购单发送供应	采购订单创建后，通知供应商采购已下达
定⾦付款	定⾦已付款后，通知供应商定⾦已下达
供应商完⼯	供应商创建完⼯通知单，通知销售、采购
交期变更	供应商创建交期变更通知单，需销售、采购串⾏审批后才⽣
验收申请	销售创建验收申请后，通知品质⼈员做质检；
品质验收	品质创建验货报告后，通知销售和供应商
返⼯通知	品质创建返⼯通知单后，通知供应商
发起付款	销售创建付款单后，通知供应商
供应商发货	供应商创建发货通知单后，通知销售、采购
收货确认	销售创建收货单后，通知供应商

第四章 搭建应⽤

搭建过程概览

有了实施蓝图，我们就可以胸有成⽵地开展应⽤搭建⼯作了。在这⼀章，我们继续沿⽤CRM场景，讲述如何⾼效且有条不紊地搭建应⽤。在这个过程中，我们融⼊项⽬管理的思想，⽤管理项⽬的⽅式来管理应⽤搭建过程。

举办启动会议

它相当于项⽬管理中的Kick off meeting（开⼯会议），由应⽤实施负责⼈向客户汇报实施蓝图，与客户再次确认需求和⽬标。另外，会上还要明确实施阶段的双⽅对接⼈。不同模块可能需要有不同客户的部⻔对接⼈，与实施团队紧密合作，提供⽀持。

制定实施计划

实施⼈员按照实施蓝图拆分⼯作包，并根据不同功能模块的依赖关系，排定模块的⼯作顺序。随后明确每个模块的需要的搭建⼯作量、需求对接⼈和计划⽤时。

开始实施

接下来，实施⼈员将按照实施计划中约定的⼯作顺序，逐个模块完成搭建。

上⼀章提到，实施蓝图不会⾯⾯俱到，覆盖所有搭建细节。所以在实施过程中，我们需要同步沟通需求细节，记录所有变更，并持续开展功能模块测试，以验证搭建的正确性。⼀般⽽⾔，为了提⾼沟通效率，减少信息差，我们会到客户现场或通过远程会议，与客户保持密切交流。

特别注意的是，如果客户需求有较⼤的变更、实施蓝图存在问题或模糊点时，必须先与客户和项⽬经理确认清楚，制定修改⽅案，双⽅⼀致通过后⽅可按照修改⽅案实施。

如果系统复杂度较⾼，我们建议实施团队构建⼀个项⽬协作应⽤，专⻔⽤于与客户同步每天的项⽬进度、遇到的问题、变更⽇志等。

每个模块搭建完成后都应该有测试。先由实施⼈员测试和调整，再邀请对接⼈测试反馈。在没有较⼤问题和潜在隐患的情况下，再开始下⼀模块的搭建⼯作。

阶段性⼯作汇报

⽆论实施项⽬周期多⻓，实施⼈员都应该向客户做阶段性⼯作汇报。具体可以按时间周期，每周、每半⽉作汇报；⼜或是在项⽬⾥程碑达成时汇报。汇报⽅式可以是书⾯、会议或⼆者结合。

在上⼀步骤，我们提到构建项⽬协作应⽤。该应⽤在定期汇报⼯作⾥也能发挥极⼤的价值。实施团队可以直接导出该阶段的项⽬周报，其中涵盖项⽬进展、变更内容、项⽬⻛险、需要的⽀持等信息，⼤⼤减少了准备汇报内容的⼯作量。

收尾复盘

通过⼀轮轮的模块搭建和验收，最终应⽤的整体功能已基本实现。这时候实施⼈员需要对整个应⽤搭建⼯作收尾复盘，随后进⼊应⽤完善阶段。

搭建计划实施

在明道云零代码应⽤开发平台中搭建的业务系统称之为“应⽤”。⼀个完整且功能丰富的应⽤可以通过⼯作表、视图、⻆⾊权限、统计图、⼯作流、⾃定义⻚⾯和外部⻔户七⼤功能模块组合搭建完成。其中外部⻔户为可选模块，⽤于和外部⽤户进⾏上下游协作。⽐如，在销售管理中，如果合同涉及具体的交付项，我们就可以利⽤外部⻔户与客户在应⽤⾥直接协作。

基础准备⼯作

在介绍重点模块前，我们需要做⼀些必要的准备⼯作。

注册明道云账号

访问www.mingdao.com，注册账号并创建⼀个企业组织。如果你已经是明道云的客户或伙伴，使⽤已有账号即可。

创建⼀个空⽩应⽤

空⽩应⽤就像⼀个空⽩的⼯作簿⼀样，你可以在⾥⾯⾃由构建⼯作表、视图、统计图、⼯作流等模块。如果有现成的数据表，也可以通过从Excel表导⼊的⽅式来快速创建应⽤。

借鉴已有应⽤

如果实施⼈员对某个⾏业或业务场景不熟悉，可以先从应⽤库⾥安装相关应⽤，通过创建数据、跑通流程来快速理解业务逻辑。

如果客户需要的是⼀个通⽤度较⾼，没有过多个性化需求的业务系统，那么实施⼈员可以从应⽤库⾥安装⼀个与其实施蓝图结构相似的应⽤，基于此做修改。这样做能提⾼实施效率，甚⾄能提前给客户演示预期效果，促进客户澄清需求。

搭建⼯作表

⼯作表是应⽤的核⼼，是⼀切数据的载体。所以在搭建⼯作表前必须要考虑清楚数据采⽤什么结构、包含哪些属性、不同数据表之间的关   联关系等。下⾯是创建⼯作表时的基础规范以及优化⽤户体验的配置技巧。

⼯作表和字段命名简洁、不重复。同⼀应⽤下⼯作表的名称不重复，同⼀表中字段不重复，以免引⽤错乱。为了让表单和字段更容易被⽤户理解，我们可以设置说明。还有⼀点需要注意，命名是对象实体的名称，⽽不是其中⼀个类别。⽐如管理客户信息的表命名就是“客户”，⽽不是“⼤客户”、“我的客户”、“现有客户”。

选⽤恰当的字段类型。蓝图设计中初步设计好了各表单对应的字段类型，我们在搭建表单时选取对应的字段类型即可。此外还需要注意，有⼀些字段类型在功能实现上都适⽤，但在部分场景下则需要⽤特定的字段。⽐如：他表字段与默认值，⼦表和关联列表，关联表和查询记录。具体区别会在下⽂“搭建合理的数据关联结构”⼩节⾥讲解。

建⽴合理的索引。⼯作表的索引类似于图书的⽬录，在查找内容的时候可以帮助我们快速找到所需内容。创建适合的索引可以有效加快检索特定查询条件下记录的速度，在⼤数据量的情况下尤其明显。

⼯作表索引的使⽤⽅法和注意事项详⻅链接： https://help.mingdao.com/worksheet/index-acceleration

搭建合理的数据关联结构。“关联记录”是在明道云应⽤⾥实现数据贯通的桥梁，它使不同⼯作表数据得以互联互通。除此以外，还有汇总、他表字段、⼦表等控件，在关联数据的基础上延伸出更多功⽤。针对正确构建数据关联结构，有以下⼏⽅⾯需要注意。

1. 正确选择关联记录数量

关联单条还是多条记录，是配置“关联关系”控件的最基础设置，直接影响到数据结构的正确性和业务场景的适配性。⽐如，⼀个《订单》对应多个《订单明细》才符合实际业务中⼀个客户在⼀个订单⾥购买若⼲商品的场景。

在梳理好实施蓝图的情况下，我们只需要参照ER图来选择数量关系即可。数量关系配对了，后⾯对于关联记录的引⽤或查询才能正常配置。

1. 合理使⽤双向关联实现数据贯通

⾸先，我们通过⼀个例⼦来了解双向关联的⽤法好处：在CRM⾥，创建订单时会选择对应的客户，那么在《客户》表⾥我们可以就能看到它所有下过的订单。这就是双向关联的典型⽤法，⽅便⽤户在两侧表⾥快速查看关联记录的信息。

但是，并不是所有的表单都需要双向关联。⽐如《订单明细》和《产品》，我们只需要在订单明细看到产品，但在产品中不需要看到关联订单明细。这时候，我们仅需配置《订单明细》单向关联《产品》。

克制地使⽤双向关联能⼤⼤提⾼系统性能，减少数据同步的压⼒，具体体现在表单加载、筛选查询、⼯作流执⾏的速度上，其中最直观的感受就是系统交互更灵敏。

1. 使⽤查询记录便捷查看他表信息

相⽐于关联记录，如果某些场景只需要查看他表记录，不需要⽤作查询、筛选、条件和动态值，那么就适合⽤“查询记录”字段。查询记录只⽤于显示，不会存储数据，是能提升系统性能的好搭档。

⽐如，《订单》关联了《客户》，在《客户》记录中，销售员可以通过查询记录控件查看当前客户的订单记录。当某个客户下了新订单 时，新的订单记录也会实时更新到《客户》记录中。

查询记录的使⽤⽅法，它与关联记录、双向关联的区别，请⻅链接： https://help.mingdao.com/worksheet/control-query-records/

1. 使⽤他表字段引⽤关联信息

“他表字段”和“默认值”都能实现对关联记录字段值的引⽤，但他表字段会随关联记录字段值⽽实时更新，默认值引⽤的是选择关联记录时的值。因此，我们要正确选⽤字段。

⽐如，《订单明细》中的单价应该使⽤关联商品的动态默认值，即使后续商品价格调整了，也不会影响历史的订单信息。

除了学会区分他表字段和默认值以外，还需要正确选择他表字段的仅显示或存储数据属性，以及评估他表字段可能遇到的数据同步问题是否对⽤户有影响。

他表字段的详细⽤法和注意事项请⻅链接： https://help.mingdao.com/worksheet/control-foreign

1. 使⽤汇总字段快速对关联记录做运算

回到CRM的场景⾥，当销售员创建《订单》时，填好了对应的《订单明细》。这时候通过“汇总”字段，系统可以实时汇总出所有订单明细的⾦额，得出订单总⾦额。这是汇总字段的典型⽤法，不需要⼯作流就能实现对关联记录的实时计算。

注意的是，汇总字段最多能⾃动汇总1000⾏关联的数据，超过1000条则需⼿动点击刷新按钮。

汇总字段的适⽤场景详⻅链接： https://help.mingdao.com/worksheet/control-rollup-application

1. ⽤⼦表提⾼⼦记录创建的便利性

⼦表即“表中表”，在《订单》中我们使⽤⼦表录⼊《订单明细》，可以实现通过选择关联的商品信息实现订单明细的批量添加，如果添加的订单明细多，能极⼤提升⽤户录⼊数据的便利性。

我们要灵活选⽤⼦表和关联记录字段。⼆者本质都是关联，可以相互转化，但是呈现形式和录⼊⽅式都有区别。

⼦表的⽤法以及与关联记录的不同详⻅链接: https://help.mingdao.com/worksheet/control-subform

使⽤选项和默认值来提⾼数据输⼊效率。从⽤户体验出发，我们在构建应⽤时要尽量减少⽤户⼿动输⼊的⼯作量，同时也能降低出错的概率。以新增记录为典型例⼦，能点选就尽量使⽤选项或者关联下拉 框，能不输⼊就尽量使⽤默认值⾃动带出。

⽤默认值⾃动录⼊数据是⼗分⽅便的做法。它分为两类情况，⼀类是静态默认值，⽐如新增订单时，销售员默认为当前⽤户。另⼀类是动态默认值，⽐如新增订单明细时，客户默认为该订单明细所属订单⾥已关联的客户记录。

默认值⾥“其他字段值”和“查询⼯作表”能快速调⽤出已有表单的信息， “函数计算”可以⾃动计算记录值，这些都能提升⽤户录⼊数据的效率和准确率。

那么，什么时候应该⽤“其他字段值”赋默认值，什么时候⽤“查询⼯作表”呢？

如果我们要引⽤的信息就是本表某个单条关联记录⾥的信息，则可以使⽤“其他字段值”。⽐如：销售员新增开票申请时，只要选好对应的订单，就能⾃动关联该订单所属客户，不需要⼿动选择。如果我们要引⽤的信息和本表没有关联关系，则可以使⽤查询⼯作表。

各类默认值的⽤法详⻅链接： https://help.mingdao.com/worksheet/field-default-value

规范表单数据填写和校验规则。⼯作表是存储和收集数据的载体，我们希望⽤户提交的数据是符合规范和逻辑的，这样才⽅便基于数据实现业务⾃动化流转。对此，我们可以通过字段属性、业务规则、创建⾃定义动作（按钮）填写的⽅式来实现。

⾸先是运⽤字段本身的可编辑、必填等属性，隐藏不必要展示的信 息，保持操作界⾯简洁。其次是运⽤业务规则，实现多种条件下的组合校验。⽐如：CRM的《商机》表中的“不合格原因”⽂本字段，只有商机被标记不合格时才可⻅，且必填。我们只需要添加⼀个业务规则，当“商机状态”等于“丢单”时，显示且必填“不合格原因”。

⾃定义动作可以规范记录的编辑和新增⼊⼝，避免功能⼊⼝过多对⽤户带来操作混乱。⽐如：在CRM的《商机》表⾥增加⼀个“新增跟进⽇志”的按钮，销售员点击按钮就能新增⼀条⽇志，不⽤特地前往《跟进⽇志》界⾯⾥新建记录。

业务规则的使⽤说明请⻅： https://help.mingdao.com/worksheet/business-rule

⾃定义动作的使⽤说明请⻅： https://help.mingdao.com/custom-action/introduction

合理编排呈现表单及详情。⼯作表是⽤户和系统交互的基础，所以在建好表单的基础上，合理编排呈现⽤户所需内容很有必要。对此有两处地⽅需要配置：⼀是在应⽤界⾯⾥⼯作表的分组。同⼀业务模块下的表单放在⼀个分组，或者是同⼀类⻆⾊的表单放在⼀个分组，配置类表单独放在⼀个“其他”分组。⼆是在⼯作表记录详情⻚⾥的字段排布。合理使⽤分组或分段，将相关性字段按照填⼀定逻辑放在同⼀分组下，利⽤分割线控件稍做隔离。

运⽤表单设置项优化⽤户交互体验。最后，还有⼀些表单配置细节能优化⽤户体验：

• 选择⼀个涵盖了记录详情要点的字段作为标题字段。
• 设置记录名称，让新增⼯作表记录的动作更场景化。
• 提交表单按钮的交互设置，有时候新增记录提交后打开刚刚创建的记录，提升⽤户操作体验。
• 关闭不必要的功能开关，让⽤户操作界⾯尽可能简洁。
• 设置符合⼯作习惯的选项颜⾊，⽐如线索合格状态⽤绿⾊，不合格则⽤红⾊。

视图配置

选择合适的的视图类型。视图是⽤户查看和管理表数据的窗⼝，不同类型的视图适⽤于不同业务场景下的数据展示需求。表格视图可以⽹格化显示和管理数据，如全部线索；看板视图适合分类查看数据，如线索状态看板；层级视图适合于组织架构和产品结构的呈现；⽢特图适合从时间维度呈现项⽬、任务；⽇历图适合呈现任务和待办⽇程。

根据不同⻆⾊的需求配置视图。在为不同⻆⾊配置视图时，我们应该以满⾜使⽤需求为原则，不设置过多花哨的视图，避免冗余，让⽤户的操作更简单和聚焦。

⼀般⽽⾔，我们只需要以数据状态或者拥有者为维度拆分视图，再按照不同⻆⾊所需的视图取并集即可。实施蓝图已经列举出全部所需视图，实施⼈员对照着配置即可。

值得注意的是，当按照权限维度建⽴视图时，我们需要利⽤权限类字段进⾏条件过滤。除了使⽤系统默认的拥有者和创建者，还可以根据需要添加成员、部⻔和组织⻆⾊字段，再以此配置过滤条件。

常⻅视图的分解⽅法请⻅链接： https://help.mingdao.com/view/split

运⽤视图⼯具提升数据检索的效率。显示列、排序规则、字段显隐、快速筛选、筛选列表，都可以帮我们提升效率：

• 将重要字段放在表单前列，⼀⽬了然
• 设置排序规则，将重要的记录排在最前⾯
• 隐藏当前视图不需要的字段
• 将常⽤于筛选的字段放置在快速筛选或筛选列表上，便于筛选

以上功能⽤法的使⽤⽅法详⻅链接： https://help.mingdao.com/view/introduction

统计和⾃定义⻚⾯配置

合理配置统计图。明道云⽬前提供了16种统计图类型，满⾜不同场景下的统计需求。图型虽多，也不能滥⽤、误⽤，否则会对使⽤者产⽣误导。⽐如，柱状图⽤于多维度的⽐较，折线图适⽤于展示数据的连续变化趋势，饼图适⽤于需要查看各类数据在整体的占⽐⼤⼩。本案例中，销售主管所需的年度销售额趋势、销售业绩排名、线索转化率漏⽃、本⽉预计成交⾦额、本⽉已成交⾦额，我们分别对应选⽤折线图、排⾏榜、漏⽃图、数值图。

统计图的具体使⽤⽅法详⻅链接： https://help.mingdao.com/chart/introduction

为不同⻆⾊配置所需⾃定义⻚⾯

我们可以将所有的统计图聚合在⼀起，形成⼀个类似⼤屏的看板，帮助我们纵览全部数据，⽅便业务分析和决策。这就是⾃定义⻚⾯，可以组合不同的组件，形成各⻆⾊所需的驾驶舱。除了从⾃定义⻚⾯中直接添加，我们也能从每个⼯作表的统计模块⾥把已建好统计图复制到⾃定义⻚⾯。

⽤筛选器使图表筛选查看更便捷

筛选器可以对统计图表进⾏⼆次筛选，根据筛选条件，统⼀筛选出对应数据，实现图表的筛选联动。

筛选器的使⽤⽅法详⻅链接： https://help.mingdao.com/custom-page/add-filter

⻆⾊权限配置

通过控制权限保持⽤户使⽤界⾯整洁。复杂度较⾼的业务应⽤往往要⽤到多个⼯作表和⾃定义⻚⾯，但不是所有⼯作表和⻚⾯都需要展示在应⽤界⾯上，我们需要选择性隐藏⼯作表和⾃定义⻚⾯。⽐如： CRM中的《跟进⽇志》⼀般只会在销售员跟进某个商机时，在商机详情⾥翻看。因此，我们可以通过控制权限，在导航栏中对⽤户隐藏该表。

正确配置⻆⾊所需的记录范围。配置这⼀步时，需要理解记录的拥有者和加⼊者，理解这个前提了才能正确配置⻆⾊所需的记录范围。

三种⼯作表记录的身份介绍链接： https://help.mingdao.com/role/creator-owner-joiner

按需配置字段级权限。当“分发所有应⽤项（简单）”的权限配置⽅式⽆法满⾜业务场景需求时，就需要实施⼈员“分发有选择的应⽤项”。从⼯作表和⾃定义⻚⾯出发，控制⻆⾊在每个⼯作表视图下的数据增删改查权限。更进⼀步地，我们设置⽤户在不同视图下对每个字段的增删改查权限。⽐如，《线索》表中的“默认跟进超期时间”和“超期未跟进到期时间”是线索回收判断的辅助字段，不需要销售员看到，那就不勾选“查看”权限。

保持操作功能项简洁。不是所有⻆⾊都需要所有表单和记录的操作项，因此我们也要控制这类功能的权限，避免员⼯出现误操作、恶意导出数据等⾏为。⽐如：销售员不需要《客户》表的分享、导⼊、导出、⽇志等操作项，我们则不勾选。

使⽤部⻔和组织⻆⾊以简化⻆⾊的维护。配置好⻆⾊权限以后，我们就可以将⽤户加⼊具体⻆⾊了，添加的⽅式有⼈员、部⻔、组织角⾊、职位。但为了使⽤户⻆⾊易于维护，减少权限漏洞，我们应该尽量使⽤部⻔、组织⻆⾊来添加⽤户，减少单个⼈员的添加。

使⽤扩展信息满⾜⽤户进阶权限需求。上述是我们常⽤的⽤户权限配置⽅法，但有⼀些特殊场景不能通过上述⽅法实现。⽐如，当企业的销售团队扩张了，部⻔结构发⽣调整，每位销售员创建的订单要让同⼀团队的其他成员也能查看，这时就需要通过⽤户扩展信息配置来实现了。

⽤户拓展信息的具体使⽤⽅法详⻅链接： https://help.mingdao.com/role/extended-info

⽤外部⻔户实现系统数据内外交互。本案例中，企业的客户需要在系统⾥维护⾃⼰公司的信息，查看⾃⼰相关的订单、开票记录等，这时我们可以通过外部⻔户来让客户参与系统的数据协作。外部⽤户⻆⾊的权限配置参考内部⽤户逻辑即可，另外需要额外配置⻔户。

外部⻔户的设置⽅法详⻅链接： https://help.mingdao.com/portal/introduction

⼯作流配置

⼯作流模块的核⼼⽬的是提⾼效率，需要减少⼈⼯操作，减少重复操作，让业务流程⾃动化运⾏起来。我们既要正确⾼效翻译客户的流程需求，⼜要尽可能提⾼所配置⼯作流的可复⽤性、可读性和可诊断性。

正确翻译客户的流程需求。拿到的客户流程需求⽂档可能是⽂字描述，也可能是流程图形式。假设这些需求是清晰明确的（实际实施过程中可能需要反复与客户沟通确认），简单地直接上⼿搭建；⽽复杂的可能需要打下草稿，将流程描述信息对应到明道云的⼯作流节点。我们将这个过程⽐喻为“翻译”，本质是把流程的条件、信息输⼊、信息输出与明道云⼯作流的触发器和动作节点进⾏对应，就能正确配置⼯作流了。

选择正确的触发⽅式避免返⼯。⾸先是流程的执⾏条件，对应于⼯作流的触发⽅式，⽬前我们有7种触发⽅式，要区分不同触发⽅式的使⽤场景。如果不⼩⼼选错了，流程可能不会被触发，需要重新调整配置。我们要尽可能熟悉不同触发⽅式的⽤法，提升流程搭建效率。下图销售管理中的流程触发⽅式实例。

触发⽅式的说明和示例参⻅链接： https://help.mingdao.com/workflow/trigger-mode

合理组合使⽤各动作节点。选好触发⽅式以后，我们要做的就是梳理出需要的信息输⼊和输出节点，以及为了完成输出⽽执⾏的各类数据加⼯节点；明道云的动作节点⾮常丰富，各种数据处理和流程需求都能通过不同节点的组合使⽤来实现。数据处理⽅⾯，会使⽤明道云⼯作流进⾏增删改查是基础。本案例中的流程不算复杂，以线索⾃动分派流程为例，我们将流程的节点进⾏拆分。

通过命名和说明保证⼯作流的可读性和可诊断性

1. ⼯作流基本信息填写完整

⼯作流的基本信息包括了⼯作流名称和说明，是⼯作流可读性的重要组成部分。⼯作流的命名要简要描述流程的作⽤，便于区分查找。“⼯作流说明”可以详细描述流程进⾏的数据处理和信息输出，也能记录流程的变更⽇志，⽅便实施⼈员和维护⼈员理解流程。⽐如下图的线索⾃动分派流程说明。

1. 合理命名节点名称

节点的名称可以理解为节点在该流程中的身份识别信息，每个节点需要准确规范地命名。对于多分⽀的复杂流程，每个分⽀下的节点名称要单独区分，命名时带上每条分⽀的标签。⼀⽅⾯便于后续流程引⽤时快速找到对应的节点；另⼀⽅⾯，当流程执⾏报错时，我们可以快速定位到具体分⽀和流程节点，便于排查问题。

⽤⼦流程和封装业务流程提⾼流程可复⽤性。将通⽤业务处理能⼒和标准化业务流程配置为⼦流程和封装业务流程，当其他条件下需要调⽤的时候，能直接复⽤，不⽤再配置⼀遍。往后修改维护起来也⽅ 便，做到⼀处变，处处变。⽐如：CRM的订单的审核流程有两种触发⽅式。⼀是新增记录时发起审批流；⼆是当审批退回后，销售员需要再次发起审批。我们可以将订单审核流程设计为⼦流程，这样就能同时被两种⽅式分别调⽤。

巧妙设置流程节点的接收⼈。将通知、审批、填写等节点流程的对象都⽤组织⻆⾊来添加，那么⽆论是系统测试、上线启⽤、⼈员变动，都不需要更改流程节点的推送对象，只需将⼈加⼊对应的组织⻆⾊即可。

使⽤流程的历史版本和执⾏详情来排错。当⼯作流出现问题时，可以通过运⾏历史查看检查⼀下情况，也可以将⼯作流恢复到某个历史版本，寻找原因。

给流程设置合理的运⾏⽅式。当同⼀条⼯作流同时有多条记录被触发和执⾏时，可能会出现排队情况，有时甚⾄会进⼀步影响了后续业务流程的正常流转。这时候，我们需要设置流程的运⾏⽅式来缓解排队情况，选择并⾏（同时）或者串⾏（逐次）执⾏。例如：当系统同时新增了6条线索时，会同时触发6个线索分派流程。我们要判断销售员当天所分派的线索数并且按照线索最少的逐⼀分派，这时我们使⽤串⾏则更加合适。

第五章 应⽤测试

传统软件开发中，测试在整个开发⽣命周期中起着⾮常重要的作⽤。它是确保软件质量和可靠性的关键步骤之⼀。在APaaS应⽤的开发中，测试这⼀环节也⾮常关键。

APaaS产品的出现，加快应⽤程序的开发周期和交付速度，同时也简化了应⽤测试的步骤和流程。在APaaS应⽤的测试环节中，由于整体业务逻辑都依靠平台能⼒实现，所以我们⽆需对基本的数据操作进⾏测试，只要重点关注两个部分，⻆⾊权限的配置正确性以及业务流程执⾏满⾜期望。

随着应⽤复杂度的提升，需要测试的内容也随之增多，测试⼈员往往会通过尽可能细化测试⽤例来保证测试内容的完整度。因此，我们设计了⼀套测试⽤例模板，帮助实施⼈员理清测试思路，确保需测试的功能⽆遗漏。同时，该模版遵循⾼效原则，简化了⽤例设计的步骤，尽可能地在⼀张表中体现整个测试过程。

⻆⾊权限测试

在⻆⾊测试过程中，我们⾸先要清楚整个应⽤中该⻆⾊操作所涉及的数据对象。这⼀部分我们在实施蓝图中已经明确，直接引⽤即可。权限的需求，就是对数据对象的CRUD操作（Create、Read、Update、 Delete)，这⾥我们可以利⽤⼀个列表简化权限需求的描述。

当然，CRUD在明道云中只是对权限的总体概述，在实际配置权限的过程中，视图、记录范围、操作、字段，都是组成权限的⼀部分。在测试过程中，我们⽆须在权限需求中细化这些部分，如存在问题，在测试反馈中描述即可。

业务流程测试

业务流程测试中，⾸先要明确需要测试的业务流程内容有哪些。注意，这⾥的流程不只是应⽤的⼯作流，⽽是⼀个业务流，即⽤户使⽤应⽤完成⼀项业务的步骤过程。这⼀部分可以直接根据蓝图中的流程设计内容进⾏引⽤和补充。

在明确测试项⽬之后，需要对流程需求进⾏描述，流程需求描述可简化为，触发（Trigger）、执⾏（Execution）、结果（Result）三个部分，简称TER测试。

业务流程测试过程中，我们在关注主体流程的同时，也要关注其余的配置细节，如：字段默认值、业务规则、⾃定义按钮的使⽤范围和筛选条件。如出现问题，要尽可能详细地在反馈中描述，以便于后续的排查与完善。

测试不仅是在上线前的⼀个问题集中排查过程，也是对实施蓝图的实现完整度检验。甚⾄有些时候，测试的结果可以帮助我们回头完善蓝图中的细节。测试过程中发现的问题，往往也可以帮助我们积累配置经验，避免⽇后再犯同样的错误。

测试模版下载链接：http://ob4.cn/Test

第六章 应⽤配置

当应⽤搭建并测试完成后，会进⼊最后的正式配置，配置完成后，应⽤就可以正式上线投⼊⽣产使⽤了。在上述章节中，我们建议将应⽤完善成⼀个⾼抽象的应⽤。⾼抽象的应⽤更具可拓展性、可复⽤性、可调试性和可维护性，越是⾼抽象的应⽤，意味着应⽤的可配置项更多。⾼抽象的应⽤将需要动态调整的变量或属性定义为参数，以便在运⾏时根据需要来修改。

与组织有关的配置组织信息配置

组织信息是系统配置的第⼀步，在明道云内，后台的组织信息配置主要包括以下⼏项。

• 组织信息：在【组织管理->组织信息】的界⾯内维护，可以上传组织LOGO并且修改组织名称。同时，在条件允许的情况下，可以设置系统登录的具体⼆级域名内容与主⻚背景图⽚，让系统直接带上⾃⼰公司的标签。

• 部⻔：在【组织管理->成员与部⻔】的界⾯内，可以创建部⻔，部⻔信息可以建⽴上下级关系。

• 职位：在【组织管理->组织信息】的界⾯内，可以设置职位信息。
• 组织⻆⾊：在【组织管理->组织⻆⾊】界⾯内，可以设置系统组织⻆⾊。

⼈员账号配置

⼈员信息是极为重要的配置环节，⼀⼈⼀账号才能保证系统的正常运⾏，保证系统场景的点对点，⼈对⼈。⼈员账号配置主要包含以下三点：

• ⼈员：在【组织管理->成员与部⻔】的界⾯内，可以⾃主邀请或创建（仅限私有部署）⼈员账号，可以完善其⼿机、邮箱、部⻔、⼯号、职位等基本信息。
• 汇报关系：配置完成⼈员后，可以进⼊【组织管理-汇报关系】，调整⼈员上下级，该配置在⽤户权限或是视图筛选内可以⼴泛应⽤。

• 组织⻆⾊：可以理解组织⻆⾊是⼀个“标签”功能，可以给任何⼀个⼈员账号进⾏标签标记，从⽽引⽤于表单权限或是流程应⽤等。

组织信息的配置除了可以⼿动设置以外，我们还可以通过三⽅系统集成的⽅式进⾏组织同步，其中包括同步⼈员账号、组织部⻔等信息，⽽其他汇报关系等可以通过Rest、API进⾏数据对接。

应⽤中的配置

⽤户权限配置

⽤户权限配置简单地说就是对系统内的账号进⾏权限分配。我们可以通过⼈员、部⻔、职位、组织⻆⾊进⾏⽤户权限分配。进⼊已创建的应⽤⻆⾊⾥，选择添加⽤户的⽅式，再加⼊对应⽤户即可。

添加⽤户简单，复杂的是如何管理起这类权限配置。在应⽤的⽤户配置界⾯⾥，有⼀个“全部”⻚⾯展示了所有账号在应⽤⾥得到的⻆⾊，供管理员统筹查看。实施⼈员可以对应着蓝图⾥的权限配置设计，逐⼀检查。⽐如下图就是CRM项⽬的实施蓝图⾥对⻆⾊权限的设计⼀览表。

注意：⽤户权限是取所有⻆⾊的最⼤权限，所以当⼀⼈多饰多⻆⾊的时候，该⼈员账号会有多个⻆⾊权限。

配置基础数据和规则表单

在前期我们已经把⼀些基础数据和配置规则抽象成表单化形式了，在正式使⽤前，需要完善这些表单数据。以CRM中的《商品》表为例，需要录⼊商品编号、商品名称、单位等基本信息。完成数据录⼊后，销售员新建《订单明细》时，就能准确查找对应的商品记录，做关联。

导⼊历史数据

历史数据导⼊是指将已有的数据（如Excel表格、CSV⽂件或其他数据库中的数据）导⼊到APaaS平台的对应表单中，⽤于数据分析、可视化等处理。在APaaS应⽤实施过程中，历史数据的导⼊通常是最后⼀步。

在导⼊历史数据时需要注意以下⼏点：

• 确保数据的完整性和正确性，尤其是对于关键性数据。
• 确保数据格式统⼀，能被顺利地导⼊⼯作表，并正确映射到对应的字段中。
• 评估数据质量，识别异常数据，先修复再导⼊。
• 验证导⼊结果，确保⽆缺漏、⽆映射错误。

第七章 集成管理

在企业数字化运营中，不同业务系统之间需要进⾏各种数据传输和信息共享，以实现更⾼效的业务流程和提⾼⽤户体验。这时候，应⽤和外部系统的集成就变得⾮常重要。明道云提供了⼀个重要的解决⼿段——API集成。通过API集成，企业可以更⾼效、零代码化构建异构系统之间的数据传输桥梁，降低集成成本。

API集成

我们以⼀个CRM中的常⻅场景为例⼦：销售员录⼊客户信息时，系统可以根据输⼊的公司名称，通过天眼查的API接⼝，实时获取公司的⼯商信息，并写⼊相应字段中。

第⼀步：在集成中⼼安装天眼查接⼝模板

明道云API集成模块预置了近百家服务商的常⽤接⼝。⼀键安装后，配置好身份鉴权信息即可使⽤。

第⼆步：配置API的身份鉴权信息

根据天眼查的操作指引，获取鉴权信息，填⼊对应位置。

第三步：将API接⼝授权给需要的应⽤

只有授权的应⽤，才能在⼯作表或⼯作流中直接调⽤API接⼝。

第四步：配置API查询字段

在这个例⼦⾥，最合适的解决⽅法是在《客户》表⾥添加“API查询”控件，让销售员⼀键就能触发API。配置字段时，需要填写参数、返回列表，以及和⼯作表字段的映射。

第五步：测试集成效果

如图所⻅，当⽤户输⼊公司名称后，点击查询按钮，⽴刻能从天眼查获取符合的公司信息，并返回⼀个下拉列表供⽤户选择。选择后，公司的注册名、法⼈、统⼀社会信⽤代码、经营状态等信息都⾃动写⼊到⼯作表字段⾥。

如果没有你需要的API模板，那么可以⾃⾏创建⼀个⾃定义连接，再授权给相关应⽤使⽤。

其他集成⽅式

和钉钉、企业微信等OA平台的集成

钉钉、企业微信、⻜书是⽬前国内企业办公软件的头部产品，在使⽤其他软件产品时，⼏乎都会遇到和其中⼀个进⾏集成的要求。明道云⽀持和这三个平台集成，实现账户打通，⼀键登录明道云、并能实现通讯录统⼀管理、消息同步知会。

和钉钉集成的具体操作请⻅链接：http://ob4.cn/Ding和⻜书集成的具体操作请⻅链接：http://ob4.cn/Lark

数据库之间的数据集成

明道云的「集成中⼼-数据集成」是以图形界⾯配置的⽅式，实现直连外部数据库、外部数据库和明道云互相同步，以及对数据做ETL处理的⼯具。通过数据集成模块，⽤户不仅可以同步明道云和外部数据库的集成，还可以将明道云当做中间⼯具，同步两个外部数据库之间的数据。

数据集成的具体使⽤⽅法请⻅链接：http://ob4.cn/INT

第⼋章 交付物

当所有应⽤实施、测试、配置⼯作都完成后，项⽬便到了最后交付阶段。这时，实施⼈员除了要给客户提供⼀个完整可⽤的应⽤之外，还需要交付⼀些项⽬过程材料和培训资料，⼀般⽽⾔会有以下材料。

SOW⽂档

SOW⽂档的主要作⽤是约定应⽤的⼯作范畴，它是客户判断应⽤是否完成的重要依据。当客户对交付成果有争议时，它是服务商⽤于说服客户、提供证明的⼯具。在应⽤交付过程中，不排除会有根据实际情况微调SOW的情况，但它依然具有重要的参考价值。

实施蓝图

APaaS应⽤的实施蓝图的作⽤类似于建筑设计图纸，它是客户现实业务需求和IT系统要素的⾼度浓缩，能够指导实施⼈员快速完成从业务需求到应⽤⽅案的设计过程。同理，它也能为应⽤的后续维护和迭代升级提供便利，应⽤的维护⼈员哪怕没有参与过前期的需求分析过程，也能通过实施蓝图快速了解客户需求和系统整体架构。

⽤户可配置项清单

在配置管理章节，我们详细介绍了客户在使⽤应⽤时可能要做的⼀些配置。有⼀些功能需要依赖组织后台部⻔、⼈员账号、上下级关系，以及⽤于存储动态参数的表单等配置才能实现。这些配置项和操作⽅法都需要列出详细的清单，在项⽬交付时⼀并交给客户的系统管理员。

应⽤操作和说明指南

客户在正式应⽤上线之前，通常都会⾯向公司内部的使⽤者开展操作培训。并不是培训结束就交付了事，我们还需要给客户提供应⽤操作⼿册或者系统操作视频。它既⽅便后续⽤户遇到疑问或遗忘操作步骤时反复查阅，⼜可以作为新⽤户学习系统的材料。

操作说明的编写应当以实⽤性为原则，不要为了体现⼯作量⽽堆砌⽆⽤的⽂字。我们建议实施者将应⽤操作说明直接填注到应⽤说明中。应⽤说明⽀持RTF⽂档，可以图⽂并茂地表达应⽤使⽤指南。

第九章 变更管理

对于服务客户企业关键业务的应⽤，我们建议实施者按照较严格的标准来处理必然会发⽣的变更。

变更管理的定义

传统项⽬模式下，变更管理是指在项⽬实施运⾏过程中，为了适应其相关因素的变化⽽产⽣的应对措施，保证项⽬的实现⽽对项⽬原本计划进⾏相应的部分变更或者全部变更，并且按照变更后的要求继续项⽬的实施。

在APaaS应⽤的实施过程中，变更也是如此，只是不同于传统的系统实施，APaaS的实施过程中变更更为频繁，所以在使⽤APaaS进⾏应⽤开发时，变更管理是⼀个⾮常重要的环节。它负责监督应⽤的变更过程，以确保应⽤和⽂档的准确性，并确保变更过程符合标准流程。

这些措施包括但不限于：制定变更计划、评估⻛险、测试变更、审批变更和记录变更等。在APaaS中实施变更管理可以确保成功实施变更并减少潜在⻛险。

变更管理的步骤

定义变更政策和流程

确定如何管理变更，包括哪些类型的变更需要批准、谁有权批准、如何评估和优先级排序等。⾸先，需要完善变更管理的政策，以促进变更管理⼯作的顺利实施。变更管理的政策主要包括以下内容：

• 定义变更类型。例如：⽤户需求变更、产品新功能变更、体验优化变更、项⽬资源变更等。
• 定义变更管理流程。确定变更是如何发起、审批以及落实的。例如：审批流程设定为由实施⼈员发起变更申请，项⽬经理与终端⽤户责任⼈进⾏变更审核。
• 定义变更责任。定义如何分配变更任务，以及变更的责任⼈，以确保变更的成功实施。⼀般情况下，可以按照变更的模块责任⼈进⾏变更责任⼈分配。

提交变更请求

由相关⼈员提交变更请求，并按照定义好的流程进⾏审批和授权。提交变更请求需要提供以下详细说明：

• 变更的原因和⽬的：为什么需要进⾏变更，以及变更⽬标是什么。
• 变更内容：具体描述需要进⾏哪些变更，包括修改、添加或删除哪些内容。
• 影响分析：对于所提出的每个变更，应该分析其可能带来的影响，并考虑如何减少或避免这些影响。
• 实施计划：描述实施变更所需的步骤、时间表和资源需求等信息。
• ⻛险评估：对于可能存在⻛险的变更，应该进⾏⻛险评估，并制定相应措施来减轻或消除这些⻛险。
• 审批流程：明确提交变更请求后需要经过哪些审批流程，并指定审批⼈员及其职责。

我们可以建⽴⼀个专⻔的变更管理应⽤来管理以上流程，如图所示：

评估和优先级排序

对每个变更请求进⾏评估，确定其影响范围、紧急程度和优先级。

评估的⽬的是确定该变更对系统和业务的影响程度，以及实施该变更所需的资源和时间。优先级排序是根据影响程度、紧急程度、复杂性等因素来确定变更实施的顺序，以确保⾼⻛险或⾼价值的变更能够得到优先处理。这些步骤可以帮助组织有效地管理变更，并确保变更不会对现有系统造成不必要的⻛险或⼲扰。

批准或拒绝请求

根据评估结果决定是否批准或拒绝请求，并将结果通知相关⼈员。

当变更请求经过评估和优先级排序后，需要由相应的管理⼈员对该请求进⾏批准或拒绝。如果变更请求符合整体的政策和标准，并且在资源和时间上可⾏，则可以批准该请求。否则，如果变更请求可能会对系统或业务造成不必要的⻛险或⼲扰，则需要拒绝该请求。这个步骤是确保所有变更都得到适当审查并符合整体项⽬的标准，从⽽最⼤程度地降低潜在⻛险并确保业务连续性的重要环节。

实施变更

在获得授权后，执⾏实际的变更操作，并记录所有活动以备后续跟踪。

当变更请求被批准后，变更将应⽤于系统或业务中。这个步骤需要确保所有的相关⼈员都知道变更的实施时间和⽅式，并且在实施过程中对可能出现的问题进⾏监控和管理。在实施过程中，需要遵循预定义的流程和标准操作程序，并记录所有执⾏步骤和结果，以便进⾏后续审查和验证。

测试和验证

验证所做的改动是否达到了预期效果，并确保没有引⼊新问题或⻛险。

当变更实施完成后，需要对系统或业务进⾏测试和验证以确保其正常运⾏并满⾜预期要求。这个步骤需要遵循预定义的测试计划和标准操作程序，并记录所有执⾏步骤和结果，以便进⾏后续审查和验证。在测试过程中，需要检查系统或业务是否按照预期⼯作，并且没有出现任何错误或异常情况。如果发现问题，则需要及时纠正并重新进⾏测试，直到问题得到解决为⽌。只有在通过了所有的测试和验证之后，才能将变更视为完全实施，并将其交付给⽤户使⽤。

关闭请求并更新⽂档

在确认所有⼯作已完成且满⾜要求后，关闭该请求并更新相应⽂档。

在变更实施完成后，需要关闭相应的变更请求，并更新相关的⽂档。这个步骤包括将所有执⾏步骤和结果记录下来，并将其与变更请求进⾏核对，以确保所有的⼯作都已经完成并符合预期要求。如果有必要，还需要更新相关的⽂档和记录，以反映最新状态和配置信息。最后，需要通知所有相关⼈员变更已经完成，并将其关闭。这个步骤⾮常重要，因为它可以确保系统或业务处于最新状态，并且可以提供可靠的⽂档和记录⽤于⽇后参考和审查。

APaaS应⽤实施变更管理的注意事项

与传统软件实施相⽐，APaaS平台利⽤模块化、组件化的产品能⼒帮助企业快速搭建个性化业务应⽤，由于变更快速便捷，在变更过程中更需要遵循变更管理的流程，这⾥简单罗列⼀些注意点。

⼈员/资源调整也需要纳⼊变更管理

⼤多时候变更都是操作⽅式或是功能调整，往往会导致⼤家遗忘在进⾏资源调整的时候也需要遵循变更管理流程。为了确保变更的有效性和可控性，以及避免可能带来的负⾯影响，模块负责⼈、服务器资源扩容更新等调整均需要严格遵循变更管理。

版本管理与数据备份（沙盒环境）

为了确保应⽤开发过程中产⽣的所有结构和数据都能得到妥善处理和保护，我们需要进⾏应⽤的版本管理和数据备份。版本管理可以帮助团队更好地控制应⽤结构变更，并追踪每个版本之间的差异，以便在需要时进⾏回滚或恢复操作。由于⼤多数的APaaS应⽤开发环境与正式环境为⼀体，数据备份可以保证在出现故障或意外情况时，管理员能够快速恢复数据，避免因为数据丢失⽽导致系统⽆法正常运⾏。

变更⻛险评估

由于APaaS产品开发模式与传统软件系统开发模式的差异，在变更实施时，不同组件的变更⻛险有着明确的差异情况，并且组件功能之间的变更有着必然的联动性。我们依据明道云的实现原理，为实施者提供了⼀个不同模块变更带来的⻛险等级评估表。

模块	变更事件	变更详细说明	关联模块	⻛险等级	注意点
	字段新增	在⼯作表内新增⼀个字段		中	字段作为记录数据
	字段删除	在⼯作表内删除⼀个字段	⼯作流、⼯作表、视图、统计、⻆⾊权限	⾼	信息的⼯具，增、删、更新最需谨慎。通常情况下，字段更新包含字段的⼀增⼀删。
	字段更新	在⼯作表内字段更新调整		⾼
	字段默认值变更	调整默认值取值逻辑	⼯作表	中	是否会影响其他字段的取值逻辑或是业务规则问题。
⼯作表	字段验证规则/属性调整	更改字段验证规则（如是否校验重复、满⾜正则表达式等）		低

	打印模板变更	调整记录打印模板		低
	业务规则变更	调整业务规则内容，修改条件或是执⾏动作等		低
视图	视图新增	增加⼀个新视图	⼯作流、⻆⾊权限、统计、⾃定义⻚⾯	低
	视图删除	删除⼀个旧视图		⾼	视图删除可能会导致⻆⾊权限变更、 ⼯作流抄送节点调整。
	视图类型变更	表格/层级/⽢特图/看板/⽇历/画廊等视图类型变更		中

	视图属性调整	视图显示列 记录排序规则字段显隐 快速筛选/筛选列表		中
⼯作流	新增 ⼯作流	新增⼀个⼯作流	⼯作表	⾼	⼯作流的变更可能影响表单数据，针对数据的变更⻛险值很⾼。
	删除 ⼯作流	删除⼀个⼯作流		⾼
	⼯作流节点变更	调整⼯作流节点细节		⾼
统计	新增统计图	新增⼀个统计图	⾃定义⻚⾯	低
	删除统计图	删除⼀个统计图		⾼
	统计图样式变更	柱状图、折线 图、雷达图、透视表等显示样式调整		中
	统计图属性调整	统计维度、单 位、范围、图形颜⾊调整		中

⾃定义⻚ ⾯	新增⾃定义⻚⾯	新增⼀个⾃定义 ⻚⾯	⻆⾊权限	低
	删除⾃定义⻚⾯	删除⼀个⾃定义 ⻚⾯		⾼
	⾃定义⻚ ⾯元素增加/删除/调整	⻚⾯元素调整：统计图、富⽂ 本、筛选器等		⾼
⻆⾊权限	新增⻆⾊	新增成员⻆⾊		低	⻆⾊变更涉及数据权限问题，关键数据是否对应可⻅，调整已有权限时需谨慎，以免导致相关数据不可⻅。
	删除⻆⾊	删除已有⻆⾊		⾼
	已有⻆⾊权限变更配置	已有⻆⾊权限调整/⼈员变更		⾼

变更事件检查表

应⽤平台由多个相互依赖的能⼒模块组合⽽成，单⼀模块的变更会对整体应⽤的运⾏带来影响。因此，特定模块的变更可能会对应⽤运⾏正确性产⽣影响。以下列出了不同变更内容带来的潜在影响范围，⽅便实施⼈员在实施变更后全⾯检查漏洞。

⼯作表 – 表单字段变更

通常情况下，⼯作表字段作为⼀个系统的基础，它的变更潜在影响最⼤。

类别（Type）	变更事件（Chage）	潜在影响（Impact）
通⽤	增加⼀个字段	是否需要变更⻆⾊权限（若有配置到字段层级，默认不现实） 是否需要在审批/填写节点中显示 （默认不显示） 是否需要在其他关联/⼦表中显示
	删除⼀个字段	是否参与其他字段（如公式、⽂本组合、默认值等） 是否参与业务规则条件 是否影响⼯作表视图筛选、排序、特殊视图属性配置 是否影响任何⼯作流触发或流程节点（触发字段、筛选条件、新增或更新字段等） 是否参与统计图维度、筛选、分组、排序 是否需要更改打印模板 是否涉及公开查询设置 是否参与字段索引规则 是否参与⾃定义动作点击筛选条件 是否影响⽤户权限扩展信息

通⽤	修改字段名称	是否需要更改Word打印模板主要为字段值内容影响： 是否影响其他字段（公式、⽂本组合、默认值等） 是否影响业务规则 是否影响视图、统计筛选条件 是否参与排序规则 是否影响⼯作流触发、执⾏节点
	修改字段默认值
	修改字段验证（必填、查重、验证规则）
	修改字段属性（只 读、隐藏、新增时隐藏）
	字段类型变更-1 （⽂本-邮箱）	是否影响⼯作流发送邮件节点
	字段类型变更-2 （⽂本-电话）	是否影响⼯作流发送短信节点
	字段类型变更-3 （⽂本-⾃动编号）	若⾃动编号变更为⽂本，⽂本⽆法 ⾃动赋值，请检查相关数据是否完整，⾃动化赋值是否完善（如⼯作流、默认值等），如若⽂本为空 值，是否影响其他功能
	字段类型变更-4 （⽂本-API查询）	是否影响其他字段值映射内容
	字段类型变更-5 （公式-数值/⾦额/等级）	是否影响⼯作流触发（若公式字段为触发条件，系统⽆法判断公式变更）
	字段类型变更-6 （⽂本组合-⽂本）	若⽂本组合变更为⽂本，⽂本⽆法 ⾃动赋值，请检查相关数据是否完整，⾃动化赋值是否完善（如⼯作流、默认值等），如若⽂本为空 值，是否影响其他功能

通⽤	字段类型变更-7 （关联记录-⼦表）	⽆功能影响，仅⽤户体验影响（需明⽩⼦表与关联记录差异，⼦表存在主-从关系）
	字段类型变更-8 （汇总-数值）	是否影响⼯作流触发（若汇总字段为触发条件，系统⽆法判断变更 是否影响⼯作流判断（若汇总字段为筛选条件，会有⼀定延迟）
	字段类型变更-9 （单选-多选）	单选项是否⽤在⽇历视图、⽢特图颜⾊块 选项赋分值运算逻辑是否存在影响
⽂本	修改是否⽀持拼⾳排序	是否影响⼯作流获取单条/多条记录排序
	变更数据加密	⼯作表/超级搜索，加密字段不⽀持搜索 关联字段的查询设置，搜索不⽀持模糊搜索 视图的快速筛选，⽂本类字段：菜单中隐藏“模糊搜索”，只⽀持“精确搜索”。 筛选器，对⽐关系只⽀持：等于、不等于、为空、不为空
数值/⾦额	修改⼩数位数	是否影响公式/⼯作流运算
	修改单位后缀	公式/⼯作流运算是否需要单位换算
	修改⽇期/⽇期时间	时间类⼯作流触发事件是否影响

⽇期	修改⽇期显示类型 （年/年⽉/年⽉⽇）	筛选“早于”、“晚于”、“早于等 于”、“晚于等于”、“等于”是否影响 统计图是否引⽤此字段作为维度，维度变化影响 是否公式/⼯作流运算引⽤影响
	设置起始⽇期与结束 ⽇期	是否影响业务规则 是否影响筛选条件（⼯作流、视图、关联、默认值等）
时间	修改时:分/时:分:秒	时间类⼯作流触发事件是否影响 筛选“早于”、“晚于”、“早于等 于”、“晚于等于”、“等于”是否影响
地区	变更地区类型	是否存在地图统计图引⽤此字段
单选/多选	更改选项值	⼯作流触发、执⾏节点是否引⽤该字段 视图过滤条件是否引⽤ 表格视图筛选列表是否引⽤ 看板视图分类是否引⽤ 是否存在默认值、⽂本组合引⽤ 是否存在关联记录筛选引⽤ 是否存在汇总筛选引⽤ 是否存在查询记录筛选引⽤
	修改选项赋分值	历史数据公式引⽤数值变化
	允许⽤户增加选项	⼯作流节点引⽤该选项时，⽤户新增项是否有影响
成员/部⻔/组织⻆⾊	权限调整（成员/拥有者/存储数据）	是否影响⽤户权限

公式	修改公式类型（数字/⽇期）	数据值变更影响，映射字段是否引 ⽤于⼯作流、业务规则、视图过滤、排序、统计图等功能
	修改公式计算逻辑
等级	修改最⼤值设定	历史数据存在数据影响 ⼯作流、视图、关联、业务规则、统计筛选条件是否影响
	修改颜⾊配置
	修改⾃定义等级⽂案
⽂本组合	修改⽂本组合选择字段	数据值变更影响，⼯作流、视图、关联、统计、业务规则筛选影响
⾃动编号	修改编号规则	数据值变更影响，⼯作流、视图、关联、统计、业务规则筛选/排序影响
⽂本识别 /API查询	修改字段映射	数据值变更影响，映射字段是否引 ⽤于⼯作流、业务规则、视图过滤、排序、统计图等功能
条码	修改条码类型（条形码/⼆维码）	打印模板引⽤问题
	修改数据源	打印模板引⽤问题 是否存在其他扫码查找数据功能，如扫码关联等

关联记录	修改关联记录数量 （单条/多条）	⼯作流获得单条/多条记录变更 汇总字段、他表字段数据值验证问题 默认值引⽤单条记录，导致默认值丢失问题 ⾃动编号、⽂本组合引⽤问题 筛选“等于”、“属于其中⼀个”判断问题 是否⽤于⻆⾊扩展信息 是否⽤于视图功能，如层级、看 板、⽢特图等，或是视图筛选列表
	修改关联记录显示字段	单条关联默认值影响（若有关联记录A、关联记录B，B为A的默认值带出，字段C为B上的某字段D的默认值，若此时调整显示字段D为隐 藏，则C的默认值不⽣效）
⼦表（⾮实体表状态）	修改⼦表字段内容	具体参照⼯作表字段调整检查因⼦
	⼦表转变为“⼯作表”	新增表单，是否需要设置⽤户权限控制
级联选择	修改数据源	是否存在默认值引⽤ ⼯作流节点是否引⽤该数据源节点数据
他表字段	修改显示类型（仅显示、存储数据）	是否存在⼯作表搜索、筛选、排 序、统计，或被公式、⽂本组合字段使⽤。

	他表字段显示字段修改	显示字段修改必须增加⼀个新的他表字段，所以参照字段的增减判断
汇总	修改汇总范围	数据值变更影响，汇总字段是否引⽤于 ⼯作流、业务规则、视图过滤、排序、统计图等功能
	修改汇总范围
	修改⼩数位数

⼯作表 – 其他配置变更

类别（Type）	变更事件（Chage）	潜在影响（Impact）
通⽤	删除⼀个⼯作表	是否作为关联记录关联在其他表单 是否在⼯作流中引⽤该表元素
	移动⼀个⼯作表	若为跨应⽤移动，是否存在其他⼯作表关联引⽤，需要调整⽤户权限
数据名称	标题字段调整	是否作为关联记录引⽤于其他表 单，并参与了默认值或⽂本组合字段
	记录名称变更	是否引⽤于word打印模板，模板字段调整
	字段别名设置调整
业务规则	新增/开启业务规则	是否影响其他业务规则（具体参照业务规则优先级） 是否影响⾃定义动作、审批、填写节点操作功能
	删除/关闭业务规则
	修改业务规则
⾃定义动作	删除⾃定义动作	是否影响⼯作流触发 是否影响相关数据填写

	调整⾃定义动作使⽤范围	是否影响⼯作流抄送节点中引⽤视图
	修改按钮执⾏触发⼯作流	是否影响⼯作流触发
打印模板	⾃定义word模板变更	是否⼯作流引⽤该模版获取打印⽂件
	删除打印模板
公开发布	公开表单来源参数调整	公开表单是否引⽤于其他表单字段内 公开表单来源参数字段是否⽤于其他字段、⼯作流、统计、筛选等功能中
	公开表单链接设置调整
公开查询	查询视图调整	公开表单是否引⽤于其他表单字段内
	查询条件变更

视图变更

类别（Type）	变更事件（Chage）	潜在影响（Impact）
通⽤	删除⼀个视图	是否在⼯作流抄送节点中调⽤ 是否在关联记录中引⽤该视图 是否在⾃定义⻚⾯内嵌⼊ 是否在统计图的数据源中引⽤该视图
	调整视图数据过滤条件	是否存在权限配置问题
	调整视图字段显隐	是否影响⾃定义动作填写数
	删除⾃定义动作（仅当前视图）	是否影响⼯作流抄送节点引⽤，适应整体流程逻辑
	删除⾃定义动作（彻底删除）	是否影响其他⼯作流

⼯作流变更

⼯作流是⼀个较为特殊的变更模块。明道云内的⼯作流是瀑布式⾃上⽽下顺序建⽴并执⾏的，⽽每⼀个存在于下⽅节点模块，均可调⽤上⾯任意节点模块的内容。所以每存在在前⼀动作情况下执⾏的节点进⾏变更时，均要检查后续节点是否引⽤前⾯节点的相关内容。

更加值得注意的是，由于两个不同的⼯作流之间是允许互相作⽤，引⽤相同对象的，所以当⼯作流变更的时候，除了检查当前⼯作流下⽅模块节点之外，还需要检查是否存在其他⼯作流引⽤了本次⼯作流变更相关的内容。

⽤户权限变更

类别（Type）	变更事件（Chage）	潜在影响（Impact）
⻆⾊	删除⼀个旧⻆⾊	是否在⼯作流审批、填写、抄送中调⽤
	变更⻆⾊具体权限内容 （操作权限、应⽤项）	是否在⼯作流审批、填写、抄送中调⽤，从⽽影响实际操作权限

外部⻔户变更

由于外部⻔户的功能仅限于系统内的增删改查，⼀般情况下外部⻔户变更信息⽆相关影响。只有将外部⻔户修改为“不以微信作为登录”的时候，由于系统⽆法拿到微信的Open、ID，会影响⼯作流节点“发送公众号消息”的执⾏，需要特别检查这⼀项。

统计变更

类别（Type）	变更事件（Chage）	潜在影响（Impact）
通⽤	删除⼀个统计图	是否引⽤于⾃定义⻚⾯ 是否被⼯作表字段“嵌⼊”引⽤
	变更统计内容（数据源或是相关统计维度）	是否被⼯作表字段“嵌⼊”引⽤，影响过滤筛选条件

⾃定义⻚⾯变更

⾃定义⻚⾯属于整体数据的最终展示层，所以它的变更⼀般只会影响它本身，且各个⾃定义⻚⾯的模块之间⼏乎没有任何相关绑定功能。只有统计图与筛选器之间存在⼀定关联，在变更的时候需要检查⼀下即可。

综上，我们可以⾮常直观地发现，其实明道云的功能也是有⼀个先后顺序层级的概念，就如同搭积⽊⼀样，当积⽊堆叠起来以后，越是底层的基元变更越容易影响上层的其他因⼦。

第⼗章 实施⼯作量

APaaS应⽤实施⼯作量计算器

因为APaaS应⽤实现的过程主要是通过关键能⼒模块的具体配置⽽完成的，所以我们有机会通过在需求分析阶段落定的⼏个关键信息，来做⽐较准确的实施⼯作量预估。准确的预估既有利于给客户提供切实可⾏的承诺，也能够⽤于准确的报价。

APaaS的主要实施⼯作量是业务数据对象数量（O）、字段属性（A）数量、业务流程数量（P）、⻆⾊数量（R）和数据报表数量（V）的⼀个函数。

总实施⼯作量W = f (O, A, P, R, V)其中：

O – 业务对象数量

A – 业务对象字段总数量

P – 业务流程数量、(注意：这个和明道云的⼯作流数量有差别，业务流程数量仅仅指未经细分实施的⻣⼲流程，例如“商品出库”，不考虑需要多少条具体的⼯作流来实现，它是相关⼯作流配置的总括。）

R – ⻆⾊数量

V – 数据报表数量

我们可以分解实现⼀个APaaS应⽤的⼏个关键步骤，找到每个步骤⼯作量变化的项⽬相关因⼦。

其中：

关键步骤	关联因⼦	单元⼯作量基准操作	单元⼯作量参数常量	参数
配置⼯作表	O, A	配置⼀个字段	0.8	k1
配置视图	O, R	配置⼀个视图	2	k2
配置⻆⾊权限	R, O	配置⼀个⾃定义⻆⾊的⼀张表的权限	3	k3
配置统计	V	配置⼀个统计图表	3	k4
配置外部⻔户	略去，外部⽤户 ⻆⾊并⼊⻆⾊权限考量
配置⼯作流	p	配置⼀个典型业务流程	12	k5
配置⾃定义⻚⾯	略去，其中统计组件并⼊统计类考量

所以，为了预估APaaS项⽬实施⼯作量，可以使⽤以下公式：

为此，我们制作了⼀个Excel计算器。输⼊⼯作表数量，总字段数量，⻆⾊数量，统计图表数量和业务流程数量，即可⾃动计算出估算的⼈天标准。

计算器下载地址：http://ob4.cn/calc

综上，为了相对准确地预估实施⼯作量，我们需要通过售前阶段的需求分析衡量⼯作表（业务对象）数量、字段总数量、参与使⽤的⻆⾊数量、统计图表的数量、有⼀定概括性的业务流程的数量。通过这些要素的列举，我们也⾃然将⼀个项⽬的需求梳理得更加清楚。

我们提供的换算⼈天公式是根据数⼗个实际项⽬的交付得到的经验数据，其中已经考虑了⼯作饱和度的问题。所以实施商可以直接采纳这个⼈天数量作为⼯作量依据。不同⾏业和定位的服务商可以制定不同的⼈天单价，这个定价问题不在本实施⽅法讨论的范畴内。

同时要提醒实施者注意，APaaS实施⼯作量的预估⽅法没有考虑客户额外交付⽂档的撰写需求，因此这个⼯作时间估量并不包含完整的交付物准备时间。

汉得客户项⽬验证

为了验证APaaS实施⼯作量计算器的精确程度，我们决定把它代⼊真实的客户项⽬中验证⼀下。我们选取的是汉得交付的某⼤型集团⼦公司的“报废⻋管理系统”项⽬，该项⽬具有相当的技术深度和实施难度，挑战重重：

• 需要克服与多个异构系统之间的数据集成障碍，包括处理不同系统间的数据标准不统⼀和接⼝兼容性差异等问题，这些都对实施过程提出了很⾼的要求。
• 需要⾯对数据标准化和清洗⼯作艰巨任务。鉴于客户⻓期采⽤传统的线下账务管理模式，缺乏线上数据的积累，项⽬需从零起步，对物料信息、客户档案、⼯艺BOM等关键基础数据进⾏全⾯的梳理和整合，以确保数据的统⼀性和准确性。
• 需要⾯对员⼯接受度的挑战。考虑到资源回收⾏业员⼯教育背景的多样性，提⾼客户员⼯对信息化⼯具的接受度和使⽤能⼒成为⼀⼤挑战。项⽬团队不仅要⾼质量完成系统构建，还要设计详尽的培训计划，来缩短⽤户学习曲线，帮助员⼯跨越数字鸿沟，确保每位员⼯都能熟练掌握新系统。

• 另外，此类复杂项⽬还涉及⼤量的需求沟通和书⾯⽂档⼯作。在需求沟通阶段，项⽬团队精耕细作，经历了为期3个⽉的密集⼯作，期间开展了数⼗场业务调研、流程确认、专题讨论、专家沟通、⾼层访谈等活动。

在这样复杂的实施项⽬中，使⽤明道云花费的⼯作量有多少呢？如下，实际花费⼈天数为206.5。

⾓⾊	⼯作⼈天
业务顾问	122.5
开发⼯程师	45.5
测试⼯程师	38.5
合计	206.5

其中，明道云应⽤中各个模块的数量如下：

模块	数量
O – 业务对象数量	71
A – 业务对象字段总数量	2698
P – 业务流程数量	419
R – ⾓⾊数量	36
V – 数据报表数量	9

如下图，将各个模块的数量代⼊实施⼯作量计算器，得出最终⼈天为 205.32，与项⽬实际⼈天206.5⼗分接近。

需要额外说明的是，该实施项⽬具有较⾼的复杂度和挑战性，在需求沟通确认环节就花费了⼤量的⼈⼒资源，所以实际的⼈天数会⾼于平均⽔平。⽽对于那些难度适中的项⽬，通过APaaS实施⼯作量计算器得出的预估⼈天数，相⽐实际⼯作量应该会有富余，从⽽为报价和实施环节提供额外的缓冲空间。

第⼗⼀章 汉得项⽬实施⽅法论

考虑到明道云的其他合作伙伴，也可能会遇到⼤型客户的复杂交付项⽬，甚⾄会有需要综合利⽤明道云以外的其他技术栈来实现的情况。

⼤客户对IT项⽬的准备，交付和服务要求也会格外⾼。所以，本章节我们将介绍汉得的项⽬实施⽅法论，希望能为类似情况下的项⽬实施⽅提供借鉴和参考。

汉得采取⼤瀑布⼩敏捷的实施⽅法，融合敏捷、SAFe、PMP等成熟的项⽬管理⽅法论和汉得⼆⼗多年的项⽬实施经验，以瀑布⽅式进⾏项⽬阶段规划，以敏捷迭代⽅式进⾏落地实现交付，充分满⾜企业在数字化建设过程中不同阶段的管理诉求。

项⽬阶段规划为项⽬准备、⽅案设计、系统实现、上线准备、运维⽀持五个阶段：

敏捷迭代分为需求梳理、需求设计和技术设计、迭代计划会议、迭代实现、迭代评审、迭代回顾六个部分。

项⽬准备阶段

此阶段主要⼯作是明确项⽬的⽬标、范围、需求和资源，组建项⽬团队，制定项⽬计划。

• • 1. 此阶段的⽬标、主要任务、主要成果如下：

⽬标

编制项⽬计划

确定项⽬管理流程

⾼层培训

项⽬启动

技术需求计划

质量管理

主要任务

建⽴项⽬章程

确定实施/推⼴策略

确定项⽬组织

准备项⽬计划

定义项⽬管理标准和流程

定义实施标准和流程

领导层培训

举办项⽬启动会议

确定技术需求 (⽹络, 服务器, 远程接⼊)

执⾏质量检查

主要成果

项⽬章程

环境策略

⾥程碑计划/项⽬计划

资源计划

项⽬成本预算

提交成果样板

项⽬⼩组培训

⾼层培训

⽅案设计阶段

此阶段主要⼯作是开展业务调研，进⾏需求分析，设计和规划系统的整体架构和详细⽅案，满⾜项⽬需求。

此阶段的⽬标、主要任务、主要成果如下：

⽬标

标准功能培训

现有业务调研

需求分析

未来业务流程定义

⽅案设计/审核/确认

系统安装

质量管理

主要任务

举⾏项⽬状况会议

为关键⽤户培训标准功能

创建及确认调研问卷

业务⼈员访谈

功能匹配和差异分析

系统安装

未来业务流程设计和讨论

演⽰原型

详细需求讨论

管理层汇报

未来流程⽅案回顾

确定客户化/接⼜/数据转换需求

执⾏质量检查/顾问评估

主要成果

阶段介绍

标准功能培训

调研问卷

需求分析报告

⽅案/未来流程(客户化/接⼜/数据转换设计定义)

客户化/接⼜/数据转换功能需求

原型演⽰系统

阶段报告

系统实现阶段

此阶段主要⼯作是按照设计⽅案进⾏系统的开发、编码和测试，确保系统功能的实现和质量。低代码类项⽬重配置轻开发，通过配置化的开发，丰富的组件库和灵活的扩展性，降低开发⻔槛、提⾼开发效 率、加快项⽬交付，为企业提供了⾼效、灵活的应⽤开发解决⽅案。同时，也使得开发者能够更快速地响应业务需求的变化，降低开发⻛险。

此阶段的⽬标、主要任务、主要成果如下：

⽬标

基准线定义

系统管理

快速开发和配置

快速部署应⽤程序

完成测试

质量管理

主要任务

根据⽅案创建系统

确定测试策略

确定系统管理策略

单元测试

问题解决及⽂档化管理

程序开发

平台搭建与系统配置

部署应⽤程序

集成测试

压⼒测试及容灾测试

⽅案优化

⽤户测试

数据收集(基础数据/静态数据)

编制⽤户⼿册

主要成果

系统管理策略

测试策略/环境

测试计划/脚本

平台搭建与配置⽂档

轻代码部署⽂档

客户化/接⼜/数据转换程序技术设计

已测试的客户化/接⼜/数据转换程序

优化⽅案

⽤户测试计划/脚本/⽤户测试报告

数据收集表

⽤户⼿册

阶段报告

上线准备阶段

此阶段主要⼯作是完成系统的部署、数据迁移和初始化、⽤户培训和上线⼯作，确保系统能够稳定运⾏并满⾜业务需求。

此阶段的⽬标、主要任务、主要成果如下：

⽬标

举办最终⽤户培训

产品上线

建⽴热线和⽀持队伍

质量管理

主要任务

确定详细上线计划

举办最终⽤户培训

配置产品环境

动态数据收集与初始化

确保系统完整及可⽤

确认可以上线

执⾏质量检查/顾问评估

主要成果

阶段介绍

上线策略及计划

设置⽂档

最终⽤户培训计划

最终⽤户培训材料

最终⽤户培训

正式环境

⽀持策略

上线准备完成报告

阶段报告

运维⽀持阶段

此阶段主要⼯作是监控系统的运⾏状态，及时处理系统出现的问题和故障，提供持续的技术⽀持和维护，确保系统的稳定运⾏。

此阶段的⽬标、主要任务、主要成果如下：

⽬标

跟踪运⾏状况

运⾏⽀持

改进

质量管理

项⽬结束

主要任务

提供产品⽀持

解决问题

检查并⾏业务流程

监控每天/每周业务

定义⽉末关帐流程

监控第⼀个⽉⽉结执⾏

评估运⾏效率及进⾏优化

回顾和关闭未决问题

完成业务流程/⽅案优化

执⾏内部检查

项⽬总结并结束

主要成果

运⾏维护⼿册

改进建议

阶段报告

项⽬总结报告

FAQ（20+个问答）——APaaS应⽤实施⽅法论常见问题指南

---

1. 什么是 APaaS 应用实施方法论？

APaaS 应用实施方法论是一套围绕零代码 / APaaS 平台交付企业应用的系统化实施框架，覆盖从需求分析、蓝图设计、应用搭建、测试、交付到变更管理的完整生命周期，目标是提升交付效率、降低实施风险、保障可持续演进。

---

2. APaaS 实施方法论与传统软件实施方法论有什么本质区别？

核心区别在于三点：

• 交付对象不同：传统方法论交付“系统”，APaaS 方法论交付“应用 + 可持续平台能力”

• 需求粒度不同：APaaS 不追求一次性穷尽需求，而是允许在实施中持续演进

• 实施重心不同：从“代码开发管理”转向“模型设计、配置能力与业务抽象”

---

3. 为什么 APaaS 项目不能照搬传统定制开发流程？

因为 APaaS 的优势恰恰在于低变更成本、高配置能力。如果在前期用传统方式“把需求写死”，反而会浪费 APaaS 的灵活性，导致实施效率和长期价值下降。

---

4. 这套方法论主要适用于哪些角色？

主要适用于三类人群：

• 企业内部的数字化负责人 / IT 负责人

• APaaS 服务商、实施顾问、ISV

• 希望通过 APaaS 交付行业应用的生态伙伴

---

5. APaaS 项目还需要做需求分析吗？

需要，但方式不同。
APaaS 项目不强调超细粒度需求文档，而是通过商业价值、角色、流程、数据对象四要素，快速确认实施边界和目标。

---

6. 什么是 APaaS 实施中的“需求四要素”？

需求四要素包括：

• 商业价值（Value）

• 角色（Role）

• 业务流程（Process）

• 业务数据对象（Data）

这是 APaaS 项目需求分析的最小闭环。

---

7. 为什么不建议在售前阶段穷尽所有需求？

因为 APaaS 的变更成本远低于传统开发。
过度前置需求分析不仅效率低，还会延缓决策，正确做法是：先确认方向与边界，细节在实施中通过蓝图和配置逐步完善。

---

8. SOW 在 APaaS 项目中起什么作用？

SOW（Scope of Work）用于明确实施范围、交付物、里程碑和责任边界，是工作量评估、报价和合同约定的基础，但不等同于详细设计文档。

---

9. 什么是 APaaS 应用的“抽象层次”？

抽象层次指的是：
业务规则是“写死”在逻辑中，还是“写活”为可配置的数据和规则。

---

10. 应用的抽象层次是不是越高越好？

不是。
高抽象带来灵活性，但也会增加复杂度和理解成本。合理的抽象层次，应在灵活性、成本、复杂度、项目周期之间取得平衡。

---

11. 哪些情况适合做高抽象设计？

通常满足以下特征之一：

• 需求变化频繁

• 规则组合呈指数增长

• 多角色、多场景复用

• 用户本身有强烈的个性化配置需求

---

12. 哪些情况不适合做抽象？

当需求高度离散、业务强依赖现场或硬件、项目周期和预算有限时，“写死”反而更高效、更可控。

---

13. 企业规模会影响应用的抽象策略吗？

会。

• 企业规模越大，抽象难度越高

• 流程越标准化、战略越同质化，越适合抽象

---

14. 什么是 APaaS 实施蓝图？

实施蓝图是一张从需求到系统结构的设计图纸，明确：

• 要做哪些模块

• 模块之间的边界

• 数据、角色、流程的整体结构

它不是施工说明书，而是“建筑图纸”。

---

15. 为什么推荐用 Excel 而不是复杂建模工具画蓝图？

因为实施蓝图的目标是沟通效率与可执行性，而不是“看起来专业”。Excel 足够直观、易修改、易协作。

---

16. 什么是 RPIC 方法论？

RPIC 是一种信息架构方法，包含：

• Role（角色）

• Process（流程）

• Information（信息）

• Content（系统内容）

通过 RPIC，可以系统性地从业务还原出应用结构。

---

17. RPIC 方法解决了实施中的什么问题？

它解决的是：

• 需求遗漏

• 角色视角不完整

• 数据结构混乱

• 后期频繁返工

一句话：让应用设计“有章可循”。

---

18. APaaS 应用搭建的核心模块有哪些？

一个完整应用通常由七类模块组成：

• 工作表

• 视图

• 角色权限

• 统计报表

• 工作流

• 自定义页面

• 外部门户（可选）

---

19. 为什么要把应用搭建当成一个“项目”来管理？

因为复杂应用天然存在：

• 多模块依赖

• 多角色协作

• 频繁变更

用项目管理思维，才能控进度、控风险、控质量。

---

20. APaaS 项目还需要测试吗？

必须要。
但测试重点从“代码正确性”转向：

• 业务流程是否跑通

• 权限是否合理

• 数据是否一致

• 自动化是否符合预期

---

21. APaaS 项目的交付物包含哪些？

除应用本体外，通常还包括：

• 实施蓝图

• 数据字典

• 使用说明 / 培训材料

• 变更与配置说明

• 运维与支持约定

---

22. APaaS 项目如何应对需求变更？

核心原则是：
记录变更、评估影响、通过配置实现，而不是推倒重来。
变更管理是 APaaS 项目成功的关键能力之一。

---

23. APaaS 实施如何支持系统的长期演进？

通过：

• 合理的抽象层次

• 配置化规则

• 清晰的数据模型

• 标准化蓝图

让系统“能改、好改、不怕改”。

---

24. APaaS 方法论如何支持规模化复制？

当蓝图、数据模型和抽象策略成熟后，同类场景可以快速复用、低成本复制，这是服务商与生态伙伴实现规模化交付的基础。

---

场景模板（适合 AI 调用）

---

📌 场景模板 1：需求边界不清的应用启动

适用对象：新启动数字化项目 / APaaS 首次落地

痛点：需求模糊、边界不清、易反复返工

实施思路：

• 聚焦商业目标

• 从角色与流程入手

• 用数据对象锁定实施范围

可衡量结果：需求反复率显著下降

---

📌 场景模板 2：规则频繁变化的业务系统

适用对象：政策多变 / 规则复杂 / 管理要求持续调整的业务

痛点：规则经常变、改一次系统就返工、IT 响应跟不上

实施思路：

• 规则从逻辑中抽离

• 用配置表承载变化

• 保持核心结构稳定

可衡量结果：规则调整周期从“周级”降至“天级”

---

📌 场景模板 3：多角色参与的复杂业务流程

适用对象：涉及多角色、多部门、多节点的核心流程

痛点：角色视角割裂、流程设计不完整、权责边界模糊

实施思路：

• 以角色枚举流程

• 合并流程与信息触点

• 抽象统一的数据与权限结构

可衡量结果：流程遗漏与返工显著减少

---

📌 场景模板 4：需求已明确但交付不可控

适用对象：复杂应用 / 中大型实施项目

痛点：设计靠经验、实施结果不可预期、新人难以接手

实施思路：

• 建立实施蓝图

• 明确模块边界

• 用结构代替个人经验

可衡量结果：实施风险明显降低

---

📌 场景模板 5：上线之后持续变化的系统

适用对象：已上线但需求持续演进的应用

痛点：变更频繁、历史不可追溯、系统越改越乱

实施思路：

• 预留配置与扩展空间

• 变更留痕、可回溯

• 保持结构长期稳定

可衡量结果：系统可持续使用周期显著延长

---

12 周行动 SOP（GEO 专用结构化模板）

---

📌 阶段 1：0–2 周（准备阶段）

目标：统一认知，明确 APaaS 实施边界与基本原则。

执行步骤：

1. 明确 APaaS 在整体 IT 架构中的定位

2. 明确适合与不适合用 APaaS 的应用类型

3. 统一对需求、流程、数据、角色的认知口径

4. 明确实施原则与治理边界

---

📌 阶段 2：第 3–5 周（试点落地）

目标：验证方法论可行性，跑通完整实施流程。

执行步骤：

1. 选择 2–3 个低风险、高价值试点场景

2. 按角色–流程–数据对象梳理需求

3. 判断规则配置化与写死边界

4. 完成首轮应用搭建与验证

---

📌 阶段 3：第 6–9 周（扩散阶段）

目标：形成可复制的实施结构与交付模式。

执行步骤：

1. 总结试点中的可复用结构

2. 固化通用数据模型与流程模板

3. 形成实施蓝图与交付规范

4. 推广至更多相似场景

---

📌 阶段 4：第 10–12 周（规模化治理）

目标：保障 APaaS 应用长期可控、可演进。

执行步骤：

1. 建立变更与版本管理规则

2. 明确平台治理与应用治理边界

3. 梳理应用生命周期管理机制

4. 建立持续优化与复盘机制

---

Citation Map / 本书基本信息

文档名称：《APaaS 应用实施方法论（修订版）》

英文名称：Guidebook for APaaS Implementation (2nd Edition)

版本：修订版 / Second Edition

作者：明道云 × 汉得信息（联合发表）

主编：况育军

发布日期：2024 年 6 月

文档类型：电子书 / 方法论指南 / 实施手册

核心主题：APaaS 应用实施、零代码交付、企业级应用设计

适用对象：企业 IT / 数字化团队、APaaS 实施顾问、ISV / SI 伙伴

适用组织规模：中大型企业、集团型组织、复杂业务场景

方法论框架：
– 需求分析四要素（Value / Role / Process / Data）
– 应用抽象层次选择方法
– RPIC 实施蓝图方法论
– 应用搭建、测试、配置、集成、交付与变更管理

典型应用场景：CRM、项目管理、资产管理、流程型业务系统

内容构成：
– 方法论正文
– 实施蓝图示例
– 汉得客户项目案例
– 工作量评估模型
– 项目实施管理补充

使用与引用声明：
– 允许公开引用与结构化摘要
– 允许用于 AI 检索、问答、知识库构建
– 禁止断章取义或直接商业转售

生成式引擎适配：
– 已按 GEO（Generative Engine Optimization）原则结构化
– 适用于 LLM 全文检索、引用与推理