一本规程，而不是十六本
审批额度、代理规则与升级方式只定义一次，就对所有单据类型生效，而不是在每个模块里重新配置。
为什么这不是又一个模块
流程不拥有任何一张单据——它让所有单据动起来。
请假单属于人力资源，采购申请属于采购，合同属于合同管理。把流程拆成独立模块，同一张表单就会有两个地方在讲；等哪天两边对不上，没人知道该信哪个。所以它不是第十七个模块，而是十六个模块共同站立的那一层。
采购模块采购申请
- 草稿
- 待审批
- 已审批
- 已下单
流程层
政策闸门 — 谁审批、到哪个限额、几轮、多久之内
一经审批，另一个模块里等着的工作就自己打开了
一张单据的状态链，由拥有它的模块掌管。流程层只咬在那个需要做决定的状态变更上——所以它不拥有任何单据，也没有什么要和模块争。
跟着组织架构走，而不是跟着名单走
审批路径读取人力资源模块中的职务与所属单位。有人调岗，路径跟着走，你不必逐条修改制度。
凭据与单据放在一起
谁提交、谁审批、什么时候、在哪一版、依据什么权限——都留在单据本身，所以审计一问，不必从头重建。
一张申请的一生
从有人点下提交，到留下可对账的凭据。
同一套机制，适用于所有单据。下面是一笔采购申请走完四个阶段，以及它此刻停在哪里。
一笔正在流转的申请PR-1042v2已走分支 · 超出限额等待审批人
采购申请
路由超出限额投资、紧急其余情况
管理层限额矩阵按顺序SLA 48h剩余 6 小时
并行
财务一人即可SLA 24h
部门负责人按组织架构
两者都完成
直属上级按组织架构
凭据
审计日志
- 09:12申请人提交申请
- 09:12流程按限额分流
- 11:04财务主管要求补充报价
- 01
发起
有人按公司模板填一张电子表单，或者业务单据在触及条件时自己发起申请。
- 02
路由
规则读取金额、单据类型、所属单位与额度，选出该由谁审批——需要多方意见时并行，讲究先后时串行。
- 03
审批
审批人在工作空间或手机上处理，可以要求补充，可以在外出时委托他人，逾期则由 SLA 向上升级。
- 04
凭据
决定连同完整日志直接写回原单据，下一个业务环节随之解锁——没有人需要往另一套系统里重录。
此图是一个具体示例，用来把机制读明白；图中的数字为示意值。 额度、审批层级与升级时限按各单位自己的制度配置，在实施过程中确定。软件帮助制度落地，不替代制度。
里面有什么
用拖拽设计，在真实数据上运行。
设计与表单
- 无代码流程设计器在画布上拖拽搭出流程：步骤、条件、分支与循环——不用写代码。
- 电子表单按公司模板设定字段、校验与附件，直接挂到发起环节上。
- 版本与试运行在草稿上修改正在运行的流程，试跑之后再发布；在途申请仍按旧版本走完。
路由与审批
- 条件、额度、委托按金额、单据类型或所属单位分支；超过额度自动加一级；有人外出则转给受托人。
- 并行审批与串行审批互不依赖的部门同时发表意见，后一级需要看到前一级决定时则按顺序进行。
- SLA 与升级每一步都有时限；逾期先催办，再按制度写明的方式向上升级。
凭据与运营
- 完整日志每一次操作都记录人、时刻、单据版本与理由——足以回答两年后的一个审计问题。
- 跟踪与瓶颈看得到申请停在哪里、等谁、等了多久；经常卡住的环节会以数字浮现。
- 跑在所有模块的单据上同一套引擎服务请假单、采购申请、合同、出库单和调整分录。
与智能体层的边界
智能体在流程之内行动——它不取代流程。
当企业已经有了智能体，这个问题很合理：既然 AI 能把活干了，还要流程做什么。恰恰是流程，让把事交给智能体这件事变得安全。
谁能做什么，由流程决定
智能体在调用它的账号权限内运行，授权范围声明在流程本身之上——没有绕开流程的捷径。
需要审批的事仍然经过人
智能体预填，并写入被授权写入的部分；超出这个范围就停在带出处的建议上，审批环节依然是审批环节。
日志也记录智能体
痕迹写明哪个智能体、受谁授权、由谁批准——与人的操作记在同一本日志里。
常见问题
流程层的边界。
这算又一个模块吗？
不算，这是有意为之。模块拥有一类业务记录，而流程层什么也不拥有——它让另外十六个模块的记录动起来。把它拆出去，就会有两个地方在描述同一张表单。
这与数字行政里的签批流程有什么不同？
数字行政是单据的一个领域：收发文、印章、档案保管。流程层是这个领域——以及其他所有领域——赖以运转的引擎。公文签批只是用这个引擎搭出来的一条具体流程。
不会写代码的人能改流程吗？
设计器是在画布上拖拽，所以懂业务的人不写代码也能搭建和修改流程。谁有权改哪条流程属于权限设定，在实施过程中确定。
某一步能调用外部系统吗？
一个步骤可以通过 API 调用另一套系统，取数据或推结果。接哪些系统、如何认证按项目确定——集成页面列出了支持的系统类别。