围绕业务决定设计流程,而不是围绕邮件收件人
每次状态转换都应说明发生了什么、下一步由谁负责,以及需要哪些凭证。
- 触发
收到提交或修订
通过表单、导入、业务事件或集成创建记录,同时保留已批准文件的位置和当前版本。
- 检查
确认已具备审核条件
审核开始前,要求填写文档类型、背景、负责人、版本、支持文件及适用的条件性凭证。
- 审核
由合适的人作出决定
根据文档类型、风险、金额、地区、地点或业务单元安排所需的审核环节。
- 恢复
退回和延误始终可见
在记录中保留退回原因、修订负责人、升级处理方式和截止日期的变更历史。
- 结束
结果到达应去的位置
更新状态、通知相关人员、创建后续任务,并把最终凭证保存在文档申请记录中。
只有负责人和失败处理路径明确时,才自动执行交接
可靠的工作流会把人工决定、记录更新、通知和系统集成连接起来,同时让错误保持可见。
指派审核人
负责人随文档类型、风险、地区或部门而变化
审核人不在岗,或规则没有匹配到任何人
退回修改
文档不完整或不符合要求
作者重新提交时没有解决明确指出的问题
发送提醒
到期事项仍未处理
重复提醒只会增加干扰,却没有升级处理
调用其他系统
源文件或业务对象存放在其他系统中
身份验证、字段映射、超时、重复或冲突错误
让每个角色都能看到自己下一项需要作出的决定
一个庞大的文档列表并不等于工作流。角色视图应按职责和状态筛选同一组记录。
提交人
草稿、缺失信息、退回修订和已完成申请,并显示每种状态的原因。
审核人
我的待审任务、受托任务、所需凭证、并行审核进度和历史决定。
流程负责人
按流程查看未指派、已逾期、反复退回、集成失败和长期未结事项。
管理者
查看工作量、周期阶段、异常构成和瓶颈,并能下钻到具体记录,而不是只看装饰性图表。
运行那些工作流演示通常会避开的情况
只跑通顺利批准的路径,几乎不能说明流程可靠。正式使用前应载入有代表性的异常情况。
提交内容不完整
审核无法开始,或应带着具体原因退回
校验结果、退回决定、负责人和重新提交轨迹
并行审核意见不一致
流程按预先定义的决定规则继续
个人决定、意见、最终结果和审计记录
审核人不在岗
转交或升级处理时仍能明确责任
原负责人、新负责人、变更原因和时间
集成失败
记录进入可以恢复处理的异常状态
请求数据引用、错误信息、重试决定和最终结果
自动记录决定过程,而不只是自动发送通知
文件、元数据、流程状态和下一步操作应始终关联在一起。
什么是文档工作流?
文档工作流是由触发、检查、指派、审核、决定、更新和交接组成的过程,让文档相关记录从提交走向明确结果。
文档工作流可以包含并行审批吗?
可以。需要明确谁并行审核、怎样才算完成、意见冲突如何解决、何时升级处理,以及保留哪些凭证。
文件必须存放在 Jodoo 中吗?
如果符合要求,可以直接作为附件保存。若文件存放在 SharePoint、Google Drive、Box、Dropbox 或其他资料库中,Jodoo 可以记录已批准文件的位置,并管理相关申请、决定和后续事项。
谁可以修改工作流?
经过培训的 Jodoo 业务管理员可以调整字段、选项、审核环节、权限、角色视图和仪表板。流程如需正式审批规则、提醒或系统集成,则应在配置后充分测试。
建立收件箱难以应对的流程
选择一份经常资料不全、被退回或逾期的文档,确认其详情、决定、负责人和恢复路径始终清晰可见。


