业务盘点表
Business process inventory
列出业务中的任务、负责人、输入输出和状态。
工作负担不清楚，需要按活动、频次、工时和责任盘点时使用。说明统计的是人员投入、等待还是经过时间。
活动清单、统计窗口、频次、工时记录、责任和必要控制要求。
工作负担汇总、记录缺口和进一步调查候选。
先理解，再动手
使用步骤
先按统一周期盘点实际业务，记录负责人、频率、输入输出、耗时和问题。明确单次耗时或周期总耗时，避免混算；再识别重复、低价值和无人负责项。
- 01
列出当前业务任务
- 02
记录负责人、频率、输入、输出、工具和耗时
- 03
标注问题、重复和瓶颈
- 04
筛选优先改善对象
盘点不直接给出可节省工时。列出的活动可能只是部分工作；多人投入与等待不能重复累加，低频不代表可以取消。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
业务盘点表 · 空白提纲 什么时候用：工作负担不清楚，需要按活动、频次、工时和责任盘点时使用。说明统计的是人员投入、等待还是经过时间。 需要准备：活动清单、统计窗口、频次、工时记录、责任和必要控制要求。 预期产出：工作负担汇总、记录缺口和进一步调查候选。 使用边界：盘点不直接给出可节省工时。列出的活动可能只是部分工作；多人投入与等待不能重复累加，低频不代表可以取消。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：业务边界、统计周期、耗时单位和口径。 1. 盘点范围与口径： 填写说明：每行：业务 | 负责人 | 频率 | 输入 | 输出 | 耗时 | 问题。 2. 业务明细： 填写说明：优先处理哪些任务及依据？ 3. 改善候选： 检查清单 □ 盘点覆盖主要业务活动。 □ 责任、输入、输出和状态清楚。 □ 能识别低效、重复或缺口。 考虑下一个框架 ECRS: 盘点已有步骤记录和必须保留的控制条件时，用 ECRS 提出取消、合并、重排或简化候选，写出验证要求。 https://bizthinkframe.com/zh/frameworks/ecrs BizThinkFrame · https://bizthinkframe.com/zh/frameworks/business-inventory-sheet
跟着案例走一遍
虚构教学案例找出服务组真正花时间的地方
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
星港服务组有五名成员，管理者觉得每天很忙但交付缓慢。
岗位说明书无法反映临时沟通与重复工作。
手头有哪些材料
- 连续一周记录实际任务和耗时
- 每人按同一口径区分处理、等待与返工
如何使用这个框架
- 先记录实际工作，不急着评价谁效率低。
- 合并同类任务，检查等待是否误记为操作工时。
- 将高耗时且重复的环节标为改善候选。
明确需求分流和材料核对是优先观察的两类业务。
列出的 18、22、10 小时合计 50 人员工时，只覆盖这些活动，不代表五人的全部容量或可节省量。等待与多人投入分别记录。
解释忙碌之前，先检查三种盘点边界
盘点是让实际工作可讨论：什么触发、谁投入、需要什么产出、投入记在哪里。把跟进与返工算进来，不只抄岗位职责。先定团队、期间和单位，再比较条目。这是本站整理单格式，不是行业认证或员工排名工具。
三种情况先停：把每周人小时、每单分钟和等待历时混在一起；同一份投入进入两行却没有分摊规则；把部分清单当成全部容量。边界没清楚，不能说谁闲着或某项可以删。
保留原单位，换算说明理由。独立单位例子：两人一起投入30分钟，合计60人分钟，即1人小时，会议本身可能只经过30分钟。这不是星港台账的新增投入，不得加进其合计。
描述工作、追流程与提改变分别准备
盘点指出值得检查的工作，本身不定位最早缺失输入，也不算可释放时间。下一问题需要更细证据时，再换视图。
| 方法 | 输入 | 产出 |
|---|---|---|
| 业务盘点表 | 有限范围、同单位工作记录 | 注明完整或部分范围的工作清单 |
| 业务流程图 | 触发、步骤、判断与交接 | 可检查等待与异常的路径 |
| ECRS | 当前工作及必须保留的产出或控制 | 待测试的重设计候选 |
| PDCA | 约定试验及执行记录 | 核对与拟下一步 |
完整案例：算列出投入，不编团队容量
继续使用星港5人服务团队虚构案例。期间只给一周，具体日期未提供；三项时间均为该任务一周总人小时，不是历时或每人小时。清单明确只覆盖部分工作，没有完整日历、请假记录和全量盘点。
三行分别是多渠道分流、提交检查和周报，算术合计18+22+10=50人小时。检查22/50=44%，分流36%，周报20%，都只占列出投入，不是5人全部一周或可用容量。不能把人数乘假定40小时，再把差值说成闲置时间。
症状支持提问，不支持责备。重复录入可能与渠道设计或必要控制有关，反复追问也可能在审核者收表单前就已埋下。资料没给原始工作项日志，先查分配和重复计数，才能将摘要视为核实台账。角色名称也不能确定谁造成延迟。
| 工作 / 角色 | 输入 → 产出 | 人小时 / 列出占比 | 暴露的问题 |
|---|---|---|---|
| 分流 / 值班人员 | 多渠道请求 → 任务清单 | 18 / 36% | 在哪里重复录入？ |
| 检查 / 审核者 | 提交表单 → 完整提交 | 22 / 44% | 信息最早在哪里缺失？ |
| 周报 / 负责人 | 工作记录 → 周报 | 10 / 20% | 哪些抄录确实必要？ |
| 列出合计 | 只有这三项 | 50 / 100% | 其他工作与全部容量未知 |
找到第一处缺项，再复查整体产出
拟优先统一提交字段，再观察检查投入。这不是已批准实施，也不承诺释放22小时。盘点在检查处看见跟进，所以值得沿提交路径查；最初缺项可能来自别处。选重设计前，与相关角色走一条有权使用的实际记录。
下一记录期先约定日期、人小时口径和唯一工作项ID。每份贡献只记一次，包括转给其他角色的工作、异常处理与准备。等待用起止时间另记。会议若服务多项工作，写明一次性分摊规则，不把全部历时给每行各算一遍。未完整记录保留，范围变化说明。
复查请产出用户确认必要字段和控制，再确认谁能批准试验。若提出ECRS候选，设置、维护和验证投入与经常投入一起列。检查总量下降可能来自提交减少、工作转移或漏控制，不必然是改善。口径兼容、期间完整、产出要求相同时再谈节省。保留原部分盘点，追加真实发现；全容量与可释放时间等有独立证据再说。
检查你的思考
再问自己几个问题
- 当前有哪些任务无人负责或多人重复负责？
- 哪些任务耗时高但价值低？
- 哪些输出没有被下游有效使用？
完成前的检查清单
- 盘点覆盖主要业务活动。
- 责任、输入、输出和状态清楚。
- 能识别低效、重复或缺口。