先定义运营结果，再讨论工具
明确期望结果、责任人以及证明改善的证据。这个边界可以避免项目变成没有优先级的功能清单。
在研讨会之前，还要明确哪些内容不在范围内。清晰边界可以保护团队不被相邻需求牵引，并让不同方案围绕同一业务结果比较，而不是比较功能数量。
观察包含例外情况的真实工作
与实际执行人员一起跟踪多个完整案例。邮件、表格、非正式审批和人工补救通常会揭示真正的依赖关系。
请参与者展示最近发生的真实案例，而不是描述理想的一天。正式流程与实际做法之间的差异，会暴露时间、权限、数据质量和沟通方式上的真实限制。
绘制决策、数据和交接
记录每个步骤接收的信息、作出的决策、产生的输出以及接手的角色，同时包含等待、返工和外部系统。
流程图应让部门外的人也能理解。使用明确的动作词，标注负责的系统或角色，并指出哪些节点会因人工判断而改变路径或需要重新处理。
衡量摩擦，而不是依赖印象
记录等待时间、重复录入、错误、中断和例外数量。少量可靠指标可以区分表面不便与值得投资的问题。
为问题估算成本，例如浪费的工时、延迟的请求、返工、合规风险或用户不满。数字不必完全精确，但必须能够支持优先级和现实的投入判断。
区分适合与不适合自动化的环节
优先选择重复、稳定且可验证的步骤。当语境模糊、影响重大或规则频繁变化时，应保留人工审核。
高频步骤不一定适合自动化。如果输入不一致，或者规则依赖隐性经验，应先改善数据、政策或交互设计，再决定是否构建自动化。
将审计转化为决策简报
总结当前流程、风险、可用数据、选项、建议的首个范围和成功标准，为产品、运营和技术团队建立共同依据。
决策简报还要记录未解决问题、验证负责人和缺失证据。可信的审计不会假装消除所有不确定性，而是把风险降低到可以选择一个有限、可验证的下一步。