AI与业务流程架构：统一、经过审定的真实依据
AI可以起草、阅读和分析您的架构，但事实仍由人来确定：建立统一、经过审定的信息来源，管理已批准的版本，并通过MCP连接各类助手。
助手可以在几秒钟内概述一般的订单到收款流程，却无法解释为什么您的财务团队批准某个例外、升级处理另一个例外，也不知道仓库为何不按安全库存规则执行。这些知识存在于您的业务流程架构中，前提是您已将其记录下来。
问题不在于AI是否会改变架构工作，因为改变已经发生。真正需要明确的是，哪些工作仍由您掌握：定义、优先事项、权衡和审批。我们的立场很简单：我们支持AI，但更重视人。AI应该减少判断前后的事务性工作，而不是取代判断本身。
为什么AI与业务流程架构相辅相成
没有AI的架构依赖人工维护，往往在两次审核之间就会过时。没有架构的AI，则只是一个反应迅速、言之凿凿的通才。
如果所有信息都要靠人手收集、绘制、描述和检查，维护业务流程架构的成本就很高。AI降低了起草初版和梳理整个流程全貌的成本。与此同时，助手并不缺少推理能力，缺的是对您流程的了解。给它原始表格，它就得自行推断工作流；给它经过审定的架构，它就能依据模型、文档、角色和实际测量结果作答。
两者结合的价值就在于此：一方扩大覆盖范围，另一方提供事实依据。这不只是AI加一张流程图，而是AI加上一个记录组织共识的信息空间。
这就是将助手连接到数据与连接到流程知识之间的区别。MCP流程上下文解决的是连接本身。更难的问题，也是本文关注的问题，是助手连接后能看到什么。数字孪生也有同样的前提：只有将模型和数据与测量结果及决策联系起来，它们才真正有用。
统一事实来源应包含哪些内容
业务流程架构是描述工作如何开展的关联结构。它涵盖价值流、流程、子流程和活动，负责这些工作的角色、支撑工作的系统、描述工作的文档和资料，以及每项内容的状态与版本。它是一个信息空间，而不是一个文件。
层级便于员工浏览，关联关系则便于助手查找。流程图文件夹可以显示某个流程的位置，却无法回答“哪些内容依赖它？”“谁负责？”或“哪个版本已获批准？”这些问题需要的是关系网络，而不是文件柜。
集中维护的内容
人们有时会把它称为BPM架构、企业流程架构或业务流程管理架构。名称并不重要，关键在于建立关联：每项事实都有唯一入口，并能明确回答“哪个版本才是有效版本？”
APQC等框架可以为层级提供一套通用术语，但不会替您定义流程、负责人或例外情况。这些内容需要由您决定并记录。
未建立关联的模型仍可用于研讨会。建立关联后，员工可以从价值流逐级下钻到活动，助手也可以沿着相同路径查找并作答。这正是值得持续维护架构的原因。
AI能加快架构工作，但不应替人决策
当任务有可核对的答案，或能先由AI起草、再由人修正时，AI最能发挥作用。架构工作中，这类任务很多。
AI does the work around the decision
- Drafts a first model or a first architecture from a description and your own documents
- Reads the whole landscape and summarizes a process, a value stream or a gap
- Finds inconsistencies, missing labels, unconnected elements and undocumented activities
- Proposes documentation sections and RACI assignments from what is already known
- Analyzes event data and proposes improvements worth testing
- Builds simulation parameters and compares as-is with to-be
People make the decision
- What the process should be, and which exceptions are legitimate
- Who owns, approves and is accountable for each activity
- Which trade-off is acceptable: speed, cost, risk or customer promise
- What aligns with the culture, the goals and the promises you make
- What gets approved, published, retired or archived
- What the organization is willing to defend to a customer, an auditor or a regulator
两类工作的界限不在于AI能做什么，而在于谁有决策权。AI即使比人更擅长起草模型，也无权决定您的公司应该如何运作。
实际操作中，可以让AI处理有审核环节的工作，把需要责任人作出决定的事项留给人。模型初稿、流程概述、缺失文档清单和改进建议都可以审核；调整审批门槛、更换负责人或停用控制措施则不行。这些都是对既有约定的修改，必须由相关方共同决定。
文化与目标为何不能交由AI决定
流程架构记录的是组织如何运作的选择，而这些选择源于战略和文化，不是数据本身。
两家公司可以用同一套ERP运行相同的订单到收款流程，处理相同业务量，却仍需要不同的架构。一家公司愿意承担成本以保障交付承诺，另一家公司则优先维护利润并重新协商。一家公司信任本地经理审批例外，另一家公司则将审批权集中管理。模型看起来相似，正确的决策却不同。
目标决定要优化什么：速度、成本、韧性、合规，还是客户付出的精力。文化决定如何作出决策、需要咨询谁、何时可以接受例外，以及组织坚决不会做什么。这些信息不在事件日志中，很多时候也不会写进文档，而是存在于实际负责流程的人心中。
助手可以学习您写下的内容，却无法为背后的选择负责。这不是扩大模型规模就能解决的问题。责任必须由能够说明理由的人承担。
我们支持AI，但更重视人。AI在流程工作中的价值，不是取代判断，而是减少判断前后的信息收集、起草和检查工作，让流程负责人能把时间用在决策上。我们不希望助手替您的公司决定如何运作，而希望它让您的决策清晰可见、便于验证并能持续更新。
如何同时为人和AI编写文档？
先面向员工编写。让同事看得明白的内容，助手也能理解；另建一套只供机器读取的文档，最终会与原有内容脱节。
员工打开一个流程时，想了解它的作用、存在的原因、负责人、例外情况以及后续该做什么。助手读取同一流程，也需要这些信息，并且要能按结构查找。模型说明步骤和关联，文档解释含义，资料提供依据，角色明确权限。
因此，“少写一些，但要说明原因”比套用更长的模板更有效。记录审批原因的说明，对新同事和询问能否取消审批的助手都有帮助。重复流程图内容的说明则对两者都没有帮助。
| 读者 | 使用界面 | 可获取内容 | 边界 |
|---|---|---|---|
| 员工 | 流程门户 | 已发布的目录、模型、文档和导出文件 | 只读；草稿和审核中的流程不会显示 |
| AI助手 | MCP Server | 流程、模型、文档、角色和RACI、统计数据及分析工具 | 使用限定范围API密钥；提交建议，写入前需确认 |
| 脚本 | REST API | 用于集成的流程、数据和模拟功能 | 权限相同，审计日志也相同 |
三个使用入口，同一个信息来源。流程门户面向实际执行工作的员工。MCP Server面向任何兼容的助手；MCP是一项开放标准，因此同一个连接可供不同客户端使用。REST API则供传输数据或运行模拟的脚本和集成使用。这些入口都不会各自保存一份架构副本。
这就是完整的工作流架构：一个经过审定的信息来源、三种读取方式，不产生第二套事实。流程门户无需发布草稿，助手也不应读取草稿。
信息缺口会让AI开始自行补全
未记录的规则并非毫无影响。它留下的信息空白，会被模型用看似合理的内容填补。
未标注的网关会变成由助手替您命名的决策。未分配的角色会变成“团队”。未记录的例外会被当作正常路径。没有说明的流程，助手只能概述流程结构，无法解释其目的。助手很少会说“不知道”，而是给出最可能的答案。但这个答案通常依据的是其他组织的流程。
这就是控制的实际意义：明确已知内容。留白之处，AI会替您作出判断，而且会说得煞有介事。
模型质量可以揭示这些缺口。画布上的质量徽章会显示百分比评分，以及评分依据的检查项：未连接的元素、缺失的标签、未平衡的网关，以及缺少的文档或角色。管理员可以为各架构层级设置检查项，因此100%表示已满足该层级的全部要求。
请把评分视为待补充的知识清单，而不是成绩。未通过的检查项，意味着某项决定尚未作出，或某个事实尚未记录。最值得关注的通常不是绘图错误，而是缺失的文档和角色，因为它们关系到意图和责任归属，也正是助手最缺乏依据、最容易自行补全的地方。模型质量与其说是建模者的成绩单，不如说是组织尚未作出决定的事项清单。
检查AI就绪架构完整度的五项标准
- The objectives: what the process is for and which outcome it protects
- The operating model: which value stream it belongs to, who owns it and which systems carry it
- The meaning: what each event, status and exception actually means
- The normal pattern: what good looks like, and which variants are legitimate
- The constraints: the rules, thresholds and approvals an assistant must not cross
版本管理让您始终掌握主动权
没有变更记录的架构不是事实来源，而只是当前的一种看法。
每个流程都有状态：草稿、审核中、已批准、已停用或已归档。发布时会生成版本快照，门户用户看到的就是该已发布版本。审核人可以在同一步骤中批准并填写版本名称、发布版本；目录会显示当前版本、待审核内容和过期内容。企业架构治理中的审核，在流程架构中会应用于每次变更。如果您已有架构审核委员会流程，这里采用的是同样的机制，只是周期更短。
版本历史在AI参与时尤为重要。您可以为快照命名、与草稿比较、审核变更组、批准或拒绝变更组、恢复先前状态，以及发布指定版本。审核决定会关联到作出决定时对应的快照，因此后续编辑不会悄然继承旧审批。
这也是我们管理AI的原则：助手应依据已批准或已发布的版本工作，而不是读取审核人尚未查看的草稿。AI提出的内容应作为待审核的变更提交，而不能因为方便就直接生效。版本是作出决定的人与读取内容的系统之间的约定。关于责任归属、审核周期和变更审批等更广泛的运营机制，请参阅流程治理。
架构获批后，AI可以做什么
有了经过审定并获批的架构，助手就不再只提供泛泛建议，而是可以执行可供核查的工作。
- 分析流程并提出值得测试的改进建议，同时提供相关依据。
- 起草活动文档，依据模型、资料和相关流程生成初稿。
- 提出RACI分工建议，使用您已定义的角色，并由员工修正。
- **跨流程全貌回答问题：**哪些流程没有负责人、哪些文档缺失、与上一个已批准版本相比有哪些变化。
- 生成初版模型，或根据您的文档生成初版架构，再逐个流程审核。
- 设置模拟参数，并将拟议变更与当前流程进行比较。
这些工作都不需要把决策权交给助手，只需让助手遵循架构和审批要求。
MCP Server可以让任何兼容的助手访问这些内容。在企业版方案中，限定范围的API密钥可开放流程和BPMN模型、文档、角色和RACI、人员与组织元数据、流程统计数据，以及ProcessMind的分析工具。如果密钥拥有写入权限，也可以使用写入工具，但工具只会返回建议，并须先预览模拟执行结果，再由人员确认。每次调用都会关联到对应的密钥，并记录在审计日志中。数据集上传、数据映射和模拟仍通过REST API进行，因为这些属于操作，而不是决策。
AI助手也适用于此场景。它可以回答流程问题，引用相关仪表板和模型，并以差异对比的形式呈现修改建议，供您审核。助手之所以有用，正是因为它受到约束。
智能体也正在进入运营模式。能够操作流程的助手需要明确的负责人、权限范围和架构定位，就像系统或角色一样。如果智能体可以提出变更，架构就应记录由谁负责接受变更。无需另建一套框架也能治理AI智能体：只需将其纳入架构描述的对象中。
如何从小处着手，而不是一开始就面面俱到？
无需先把整个组织纳入架构，AI才能发挥作用。您只需要一个与实际决策相关联的流程片段。
-
选择一个价值流和几个流程
选择一项经常引发讨论、有人负责且结果可衡量的工作。只需一个审批、交接或返工环节，就能验证这一做法。 -
先明确负责人和审核人
在引入助手前，先明确角色和RACI分工。必须先有明确权限，助手才能读取；审核人也应是架构中明确的责任人。 -
按实际需要的深度记录文档
为每项活动补充说明、角色和清晰的边界。跳过无人会用的内容；架构即使完整，若无人阅读，也不过是另一堆流程图。 -
达到质量要求
修正缺少标签、未连接和未记录的元素，再将剩余问题列入改进议程，而不是当作缺陷清单。 -
发布一个版本并连接一个助手
提出一个您已知答案的问题，并将回答与工作空间中的内容进行比较。答案正确，说明信息来源经过维护；答案错误，则说明存在缺口。 -
定期安排审核
检查模型质量、上个版本以来的变更，以及AI提出的改进建议。逐项批准、拒绝或暂缓，并记录原因。
第一个流程片段用于验证方法，第二个会更快。架构应随决策逐步扩展，而不是靠一次文档整理项目铺开。
架构就是各方约定
AI让文档更有价值，而不是更无关紧要。过去只在研讨会上派得上用场的模型，如今会影响公司里的每个助手如何描述实际工作。
能从AI中获益的组织，不会是智能体最多的组织，而是知识明确、责任清晰、及时更新并经过批准的组织；员工有途径查阅，助手也能访问。
这就是我们认同的分工：AI负责阅读、起草和检查，人来决定事实。架构是两者之间的约定。
Where to Go From Here
您可以将流程全貌清晰呈现，也可以让助手利用这些信息。不妨从一个相互关联的流程片段、一份已批准的版本，以及一个可验证的问题入手。
