流程治理：让流程文档始终保持最新

流程治理明确流程由谁负责、谁有权修改流程模型、批准版本存放在哪里，以及何时复审。这些安排能让流程文档在项目结束后，依然与实际工作保持一致。

这是通用定义，而且没有错。本文补充了许多流程治理文章忽略的一点：每项决策具体落实在哪里。在ProcessMind中，负责人、审批、已发布版本和审核队列都是平台功能，而非政策文件中的条款。

人员、系统和职责不断变化，工作方式也随之改变。流程图只能记录某个时点的情况，专业知识往往留在人们脑中。如果没有明确的负责人和审核机制，文档就会逐渐偏离实际。

流程治理是什么意思？

流程治理由一系列决策和角色构成，目的是让流程文档与实际运行方式保持一致。它需要回答四个实际问题：

• **负责人：**由哪位具体人员对流程负责？
• **变更：**谁可以编辑模型，谁负责审批变更？
• **发布：**批准后的版本存放在哪里？
• **审核：**何时检查模型是否仍符合实际工作？

项目治理关注按约定范围交付。IT治理关注技术风险。流程治理针对流程本身，在引入流程的项目结束后仍会持续。

如果您能为最重要的流程回答这四个问题，就打下了可行的基础。如果不能，团队就会反复记录相同的流程，每次都从头开始。流程架构可以为这些重复工作提供统一的归档位置。

流程治理框架应明确哪四项决策？

可用下表准备首次治理会议。针对每个流程，记录决策内容、负责人，以及证明决策已落实的依据。

治理规则应与实际需要相称。在ProcessMind中，流程负责人就是审批人，因此每项变更都有明确的决策人和可见结果，无需经过冗长的签字流程。确保已批准的模型易于查找，并根据流程变更频率和相关风险制定审核计划。治理与发布的运作方式逐步介绍了整个工作流。

治理框架最常遗漏的是第四列。只写在文档中的决策只是意向；落实在平台中的决策才有约束力。当负责人信息成为字段、审核成为队列事项、查看者只能看到已发布版本时，即使制定规则的人已经离开，规则仍能持续生效。

流程文档为何会过时？

文档失效往往始于一个看似合理的例外。审批环节造成积压，于是经理同意某些案例可以跳过审批。积压消除了，但没人正式取消例外。新的工作方式逐渐成为常态，模型却仍显示旧的审批步骤。

人们一旦不再信任文档，就不会再查阅。这样一来，下次变更更难被发现，差距也会不断扩大。实际中，例外很少被记录下来，因此问题通常是在审计时发现，而不是在审核时发现。根本原因在于模型不是正式记录，所以工作发生变化时，没有机制要求作出决策。将模型放在受治理的平台中，变更就有了明确的处理位置：版本、审批后使其生效的负责人、发布状态和审核日期。治理不再只是提醒，而成为工作流中的一个步骤。

流程治理需要哪些角色和职责？

实用的流程治理模式从三种角色开始。在小型组织中，一人可以承担多个角色，但各项职责仍需明确。

流程负责人的职责很明确：判断拟议变更是否准确反映实际工作，并有权推动决定落实；这项决定就是有效审批。负责人不必亲自编辑模型或维护文档。在ProcessMind中，负责人也不必追踪进度：流程发起审核后，负责人会在审核队列中看到请求，审批后版本即可发布。流程架构师负责维护整个流程目录的一致性。只有控制要求第二个签字时，才增加合规审批人，因此通常只需一位审批人。流程负责人机制只有在角色清晰可区分时才有效，所以应将角色记录下来，而不是默认其存在。

使用RACI矩阵分配职责；如果是首次设置，可从RACI模板开始。将角色库集中管理，让不同模型重复使用相同角色，而不是由各团队分别定义。

明确角色职责的同时，也要制定审核周期。相关变更发生时进行审核，并按计划定期审核活跃流程。

应优先治理哪些流程？

先从最重要的流程入手，不必覆盖组织中的所有流程。优先呈现能带来收入、受到监管关注、涉及多次交接，或过去一年频繁变更的流程。

明确治理范围。与其建立一个包含大量流程、但没人信任负责人字段的目录，不如先建立较小的目录，为流程指定负责人、审批人和审核日期。其他模型可先作为参考资料，待准备就绪后再纳入治理，并在流程目录中区分两者。流程文档治理始于明确界限：哪些流程受治理，哪些仅作描述。

选择工具前，先明确负责人。目录可以整理模型，却无法决定由谁负责。流程文档将模型、负责人和过程记录在同一条目中。

如何治理AI生成的模型？

AI生成的模型也需要遵循与其他模型相同的责任归属、审批、发布和审核规则，而且执行时应更加严格。AI生成的草稿只是对流程可能如何运作的一种合理描述，并不能证明您的组织实际就是这样运作的。

在指定的流程负责人审核并批准前，请将生成的模型保留为草稿。记录草稿依据的内容，并让负责人将其与现有模型进行比较。批准后，按照其他文档的审核周期进行审核。

治理在这里能发挥双重作用。人们可以阅读同一份受治理的记录，AI助手也能通过API和MCP Server在相同权限下读取。基于已发布并获批准的模型作答，意味着助手依据的是流程本身，而不是粘贴到提示词中的副本。了解MCP Server可以提供哪些内容。

ProcessMind支持AI辅助建模和版本历史。生成的内容应先保留为草稿，经过审核后再单独决定是否发布。有关版本管理的详情，请参阅ProcessMind版本管理文档。

如何判断流程文档仍然准确？五个迹象

治理是否有效，要看证据。以下五项检查是我们的判断依据，而且每一项都能在ProcessMind中实现，而不只是目标。

**1. 您能迅速说出重要流程的负责人。**如果答案是某个部门，或者需要翻旧邮件才能找到姓名，就说明责任归属没有记录。在ProcessMind中，负责人信息直接关联到流程并显示在目录中，搜索一次即可找到。

**2. 每次变更都能查到变更内容和批准人。**仅凭记忆无法构成记录。每个模型都有版本历史，审批则是受权限控制的操作，可将流程从草稿推进至审核中、已批准和已发布。审计日志会保留完整记录。

**3. 每个人都在使用已发布版本。**如果同事们各自保留私有副本，共享模型就难以令人信赖。ProcessMind会向查看者发布唯一版本，无论是在平台内还是流程门户中，都能明确当前版本。

**4. 审核日期没有过期。**无人关注的逾期审核，比没有设置日期更糟。目录中的“等待我审核”队列会列出每位负责人待处理的事项，让审核有明确的负责人，而不只是一个意向。

**5. 您能根据流程记录回答审计问题。**从分散的文件夹中重新整理证据可能要花上数周。在ProcessMind中，负责人、版本、审批和相关文档都集中在一条记录中，您可以直接导出并提供。

这些检查只有反映实际工作情况才有意义。审核日期已完成，并不能证明有人看过模型。因此需要设置角色和审核队列，让每项检查都对应具体人员和时间。

如果流程本来就在平台中管理，这五项检查都不需要新工具。这正是在建模平台内治理流程，而不是在平台之外另行管理的实际优势：证据会在日常工作中自然形成，而不必等到季度末再由某人整理成报告。

如何将流程治理落到实处？

先选一个您已负责的流程，在撰写政策前，先在模型中落实四项决策。

1. 指定负责人

   为流程指定一位负责人，而不是一个部门。两个人共同负责，就可能变成谁都不负责。

2. 明确编辑者和审批者

   将模型修改者与审批者分开。在ProcessMind中，审批者就是流程负责人；只有在控制要求时，才需要另设合规审批人。

3. 发布唯一版本

   将已发布模型作为确认当前版本的唯一依据，并让查看者使用该版本，而不是副本。

4. 设置审核

   设置审核日期并使用审核队列，让逾期检查有明确负责人，而不是只靠自觉。

5. 重新进行五项检查

   一个月后，重新进行上述五项检查。如果任何一项需要搜索不止一次才能回答，就先解决这一项。

ProcessMind将责任归属、审批、版本历史和已发布记录集中在一处，让平台落实治理要求，而不是只靠文档提出要求。有关责任分配，请参阅RACI说明和RACI模板。如果无人对结果负责，请阅读流程挖掘项目为何停滞。