把管理问题
转化为可交接的业务输入

如何使用这份教材

教材提供完整学习路径；投影课件负责引导，教材负责解释、举例、记录与复盘。请带着本组的一条业务链阅读，而不是把所有管理对象一口气塞进一套系统。

贯穿示例的“事实标签”

不要在个人练习文本框录入客户的涉密资料、真实姓名、账号或内部敏感记录。浏览器本地保存便于复盘，但不等于企业合规存储。

一条推进路径，一套完整性检查

五步法回答“先分析什么、后分析什么”；系统蓝图八要素回答“业务输入是否说清楚”。它们不是两套并行课程，更不是十三张必须填满的表。

这五步可以往回走：要求实时查当前责任，却没有交接记录，先回数据流找来源；没有人负责交付确认，则进一步回业务流；管理对象究竟按单件还是按批量追踪说不清，则回业务需求理解。先发现不自洽再修正，比把不确定性隐藏在“系统自动处理”中更有效。

八要素怎样嵌入五步

业务部门与技术团队的分工

技术团队可以追问、揭示冲突、评估可行性，但不能代替业务负责人规定审批条件、责任转移时点或损坏处置制度。业务侧也不应在课堂上指定数据库表、接口协议或备份工具。

看已有系统：反向寻找业务规则

样板的教学价值不在于参观全部功能，而在于沿一笔真实事务观察页面、记录、状态和责任的关系。课堂必须使用客户允许展示的脱敏资料。

按一笔事务进行五次观察

1. 找起点和终点：哪件事触发了办理？由谁认定业务完成？截图之外是否有纸面或口头动作？
2. 看参与者：谁发起、审批、执行、确认、查看？一个账号能操作不等于该岗位有制度授权。
3. 看记录：每次动作留什么字段、时间、人员、附件或签名？能否从当前值追到源事务？
4. 看状态：某个状态何时变化？是提交申请、批准、实物交付还是接收确认触发？不要凭页面标题推断生效时点。
5. 看异常：被退回、实物与记录不符、账号转岗、系统中断时如何处置？资料未展示就标“待核实”。

检查标准：你能用真实可见证据解释一笔事务，不靠“我觉得系统应该如此”补全缺失的历史或规则。

“想做系统”不是需求的起点。一项可讨论的业务需求，至少包含真实事件及证据、主问题、管理对象、业务边界、参与角色、可观察目标和未决规则归属。

五个分析动作

教学模拟：从“要扫码”追到业务问题

工具取舍：不要为了“方法论”堆方法

问题分散才使用简化亲和图；角色表只需写角色、关注点、责任及决策权。Kano 更适合在具体候选能力出现、用户期望需要优先级判断时使用，不能在问题和场景未定之前先给想象功能分类。

进入第二步的门槛：另一组能复述对象、起止、主问题、角色、目标和谁应决定未决规则。规则不必在课堂全部解决。

把现有纸单照搬成线上流程，往往只是把等待与重复抄录数字化。应先看规定如何写，再沿一笔真实事务看现场如何走，最后有依据地提出未来业务流。

三图各自回答的问题

三图要使用相同业务边界、角色泳道和节点编号；不必为了视觉精美重画三张完全不相干的长图。文件与现场不一致，可能因为文件过时、制度留白、适用范围不符、实际偏离或证据不足，必须区分。

问题卡连接差异与优化

ECRS：有理由地改动作

VSM／价值流图只有在等待和处理时间有可信数据时才适合量化使用。本课程默认用问题卡加ECRS整理局部业务流，不画没有数据支撑的“漂亮价值流”。

图C成形后：用5W2H追问关键节点

进入第三步的门槛：拟议业务流可复述，关键交接有角色、触发与异常去向；无法说明管理对象或责任归属时退回第一步。

系统不会自动知道现场发生了什么。业务侧要定义在哪个节点、由谁、根据什么事实形成记录；技术团队再评估实现方式。

先看现状数据如何走，再推未来数据如何走

现状线：沿图B找纸单、Excel、系统等载体，记录谁填写、什么时候补录、哪份是准数、谁用这些信息行动以及数据如何保存。纸单有记录但月底才录Excel时，不能把“交付当刻实时可查”写成已成立的能力。

目标线：沿图C逐项定义业务事件发生的条件、需要引用或新采集的信息、确认责任人、形成的事务记录、当前状态／责任变化、历史追溯和下一岗位的使用。所谓“动态台账”不是月底再做汇总，而是可靠业务动作触发可信现况更新。

四类业务信息要分开理解

上述是业务信息概念，不暗示物理数据库一定建四张表。数据库结构与接口设计由开发人员评估。

讲师示范：动作—记录—状态／责任

字段定义要包含业务口径：名称、用途、从哪里产生、谁填写和核对、格式或取值范围、何时必须存在、谁使用、错了怎么纠正。只列“工具编号、借用人、日期”三个词，不足以交接给技术对接人。

数据版5W2H：问的是信息本身

进入第四步的门槛：关键记录有来源与确认人，下游岗位能解释何时拿到它；不把“需要数据”当作“数据已经自动存在”。

工作台不是页面效果图，而是每个业务角色在什么事件后需要知道什么、处理什么、查证什么，以及怎样判断动作已完成。

从事件生成任务卡

“管理员要一个首页”不足以形成业务任务。较清楚的表述是：“交付条件满足后，保管岗收到待交付任务，核对单件标识与接收人，完成实物交接确认并形成记录；未能交付时按待定的异常规则退回或升级。”这仍是一条教学候选，角色和规则需业务确认。

权限须包含动作和数据范围

用角色 × 动作 × 对象范围核查提出、审批、执行、确认、查看、更正、导出；重点追问申请人能否自批、交付者能否单方解除责任、更正是否覆盖历史、代理授权怎么产生、越权导出是否有风险。这些是业务授权边界，技术配置由技术团队评估并落实。

指标从管理问题推导，不从图表样式推导

用正常与异常两条角色链走查

正常链：提出、核对、交付、使用、归还、接收、关闭，每一步的任务如何传递？异常链可选“实物已还但系统仍显示借出”：谁先发现，依据什么核对实物和历史，谁批准更正、谁执行及复核？若发现无人负责，退回业务流；若找不到可靠记录，退回数据流。

进入第五步的门槛：没有无来源的“实时看板”，也没有无人承接、无完成标志的待办；此时仍不需要画最终 UI 原型。

系统能打开页面，不等于一笔业务能正确闭环；备份存在，也不等于恢复后账物一致。本步从业务验收、纠错责任、系统中断、旧账切换和持续改进五方面闭环。

把前四步变成可观察的验收案例

运维责任：谁判定、谁处理、谁复核

选择少数关键事项写责任表：错账更正、对象分类或主数据变更、账号开通和转岗撤销、异常关闭、指标口径变更。每行应有触发、业务核实者、业务批准／复核者、技术对接人、原记录留痕和关闭证据。不要只填“系统管理员处理”。

中断与恢复：桌面推演一笔正在办理的业务

1. 交付节点系统不可用时，业务应暂停还是可以按授权线下继续？谁作决定？
2. 若启用纸面兜底，临时凭证如何唯一标识、如何防止重复交付或重复入账？
3. 恢复后谁补录，谁拿原始凭证、实物和系统台账逐笔核对？
4. 发现冲突或漏记，谁判断、批准更正、复核关闭？
5. 哪些业务记录不可丢、业务可接受的停用和损失范围是什么？无正式决策或数据时标待业务决策，不填假数值。

上线不是按下开关

本步完成条件：业务接受标准、关键运维责任与恢复后的核账要求有明确归属；课堂不能宣布系统已经通过正式验收或恢复测试。

八要素最终人工核查卡

五步做完后回看同一条业务链。来源从当前填写内容读取；学员手动判定状态、责任角色及下一步，不因栏目有字就自动显示通过。这里是查漏与交接，不是另做八套表。

下方为当前本机学员输入，不含讲师 H 案例。缺来源、证据或决策人时标待核；“有依据可交接”也不等于客户制度已批准或业务验收已执行。

检查完按事实待核、业务待决策、技术待评估分流；如后一步推翻前一步，回原表修改，来源会同步更新，人工结论须重新核对。

八要素查漏，模拟交给技术对接人

练习的最后一关，不是每组汇报“我们做了多少页”，而是互换材料：接收组能否复述业务规则、指出事实和假设、提出待决定问题，并设计一笔可测试的业务案例？

评审时按“可复述—可评估—可测试”追问

结论必须分流，而不是合并成“待技术团队解决”

合格的练习稿：能被另一组质询，能诚实指出未知项，能从验收案例回溯到流程和数据。它不是完整系统蓝图，也不能作为客户批准的开发指令。

工作坊总索引与成果交接

练习嵌在各步骤理论与示例后。每一步的“输入承接”显示上一步及必要的更早步骤已填写成果；各表可按实际角色、节点和事件数量增加／删除行。本步只新增该阶段的分析，不重新定义另一条业务链。修改上游填写内容，下游引用同步更新。

交叉评审与三类待办

1. 与另一组互换草稿，让接收组只依据材料复述边界、流程、数据事件、任务与验收。
2. 接收组按问题编号指出歧义：事实缺口、业务规则冲突、技术可行性问题或需回修的步骤。
3. 归档为：事实待核实、业务负责人待决策、技术团队待评估；有依据的业务结论另列来源与批准状态。

本地草稿未保存。请勿输入涉密或个人信息。

术语、常见误区与结业自检

六个常见误区

1. 先要求扫码、看板或AI，再倒找业务问题。
2. 把文件流程直接当成现场实际，再原样搬到线上。
3. 把字段堆成清单，却不说明采集动作、确认人和使用者。
4. 把“当前状态”当作可随意覆盖的值，没有历史证据。
5. 把“管理员权限”当成所有人可以自批、自改、自导出。
6. 把课堂演练结果称作已批准系统蓝图或已完成上线验收。