成本怎么做？跨部门团队效率提升：成本管理从0到1

跨部门项目里，最容易被忽略的成本，往往不是采购单上的金额，而是需求反复确认、等待审批、重复录入、临时返工和责任不清造成的时间损耗。一个项目看起来只超支了几万元，背后可能是十几个人每周各花半天追进度。成本管理从0到1，真正要做的不是先砍预算，而是先让团队看见钱、时间和返工分别消耗在哪里，再用可验证的规则减少浪费。

一、先讲核心结论：成本管理不是“少花钱”，而是让资源花得有依据

1. 成本管理的起点，是建立可追溯的资源账

我判断一套成本管理机制是否有效，通常不先看它有没有复杂的预算表，而是先问三个问题：一笔费用对应哪个目标？由谁提出、谁批准、谁验收？发生偏差后，团队能不能在几天内找到原因？如果这三个问题答不上来，再精细的表格也只是把不可见的浪费记录得更整齐。

从0到1的成本管理，至少要建立四类信息：预算与实际支出、投入工时、交付结果、偏差原因。前两类告诉团队用了多少资源，后两类解释资源换来了什么，以及为什么和原计划不同。只看金额不看产出，会把合理投入误判为浪费；只看产出不看资源，则容易把长期透支包装成高效率。

2. 先优化决策链路，再讨论压缩预算

跨部门成本常常不是某个部门单独造成的。业务提出需求，产品拆解范围，研发评估工期，采购询价，财务审核，交付团队验收。每个环节都可能合理，但接口处容易产生等待、重复确认和信息丢失。成本管理必须把整条链路作为分析对象，而不是只盯着最后付款的部门。

我的经验判断是，先找出资源消耗最大的三类过程，再决定是否削减费用。多数团队优先要检查的是：需求变化引起的返工、跨部门等待造成的闲置，以及同一信息在多个系统或表格中的重复维护。它们通常比单笔办公用品支出更值得关注，因为会持续发生，并且影响多个岗位。

3. 任何成本改善，都要同时观察质量与交付

如果项目预算下降了，但延期率上升、缺陷变多或客户验收时间拉长，这并不能简单称为成本优化。成本管理不是把某一项指标做低，而是找出投入、交付、质量之间的合理平衡。削减测试、减少关键评审、压缩培训，可能短期减少费用，却把成本推迟到上线后以故障、投诉和返工的形式出现。

我建议把成本目标改写成带有边界条件的表达，例如“在不增加重大缺陷和延期风险的前提下，减少重复确认和低价值等待”。这种目标比“全年节约10%”更能指导团队采取行动，也更容易在复盘时判断改善是否真实。

二、背景和真实场景：成本为什么会在部门交界处失控

1. 一个常见项目：每个环节都在工作，整体却没有向前走

以一个中型企业的内部业务系统改造为例，业务部门希望缩短客户处理时长，产品团队负责梳理流程，研发团队负责接口和功能，财务负责预算审核，运营团队负责上线后的使用培训。每个团队都有自己的任务清单，但项目没有统一记录需求变更、等待时间和实际投入。

项目进行到中段，业务部门通过会议提出几项新要求，产品在文档中更新，研发只收到其中一部分；财务仍按旧范围审批采购；运营开始准备培训材料时才发现操作流程又变了。单看每个部门，都能找到“已经完成”的事项；站在项目视角，却出现了重复开发、材料重做、审批退回和上线时间后移。

这类场景里，成本不是突然出现的，而是被分散在不同人的日历、工时表、邮件、即时消息和版本文档中。只要组织没有把这些信息关联起来，管理者看到的通常是财务系统中的付款金额，看不到“为了同一件事，团队解释了几次、改了几轮、等了多久”。

2. 先把成本拆成四本账，避免只看财务支出

为了让成本讨论有共同语言，我通常把跨部门项目拆成四本账。它们不一定都要精确到每分钟，但口径应当稳定，能用于比较同类项目或同一个项目的前后变化。

• 现金账：外包、采购、云资源、差旅、培训和其他直接支出。
• 工时账：各岗位投入的工作时间，重点记录关键角色，而不是要求全员进行高负担的逐分钟填报。
• 等待账：事项提交到获得明确答复之间的时间，包括审批、依赖交付、权限开通和需求澄清。
• 返工账：因需求变化、信息错误、验收标准缺失或交接遗漏产生的重复工作。

这四本账的价值不在于把每个员工都计价，而在于避免两种误判：一是把非现金投入当成免费资源；二是把等待与返工都归为“团队效率不高”，却找不到产生它们的具体环节。

3. 组织规模不同，成本问题的表现也不同

小团队的问题常常是“事情都靠人记”。负责人知道预算大概花在哪里，也能直接找到同事确认，但数据难以长期复用。规模扩大后，真正的难点会转为口径不一：研发按人天估算，采购按合同金额统计，财务按付款节点入账，业务按功能上线判断完成。

对于100人以上、部门边界较多的组织，成本管理更像是建立一个协作机制，而不只是增加一张审批表。可以用PingCode一类项目管理平台承载需求、任务、责任人、计划和变更记录，再把预算及付款等财务数据与项目台账建立关联。平台的作用是让工作过程更容易追踪，不能替代预算制度、财务核算或管理者的取舍判断。

对于较小团队，如果每月只有少数项目，先用共享表格统一项目编号、预算、实际投入和偏差原因，也可能比马上引入复杂工具更合适。工具选择应服从流程成熟度，而不是先买软件再反向寻找使用场景。

三、常见误区：看似在控成本，实际可能把成本藏起来

1. 把预算压低，当作成本管理的全部

预算上限是约束，不是管理机制。如果团队只收到“少花钱”的指令，却没有明确优先级、范围边界和变更规则，最容易发生的不是效率提升，而是各部门分别压缩自己容易控制的部分：减少评审、推迟维护、缩短测试、把工作转交给其他团队。

最终，项目表面上没有超出某个部门预算，整体却增加了延期损失、返工成本和沟通成本。尤其要留意“成本转移”：费用从外包预算转为内部加班，从开发阶段转为运维阶段，从本季度延后到下一季度。账面支出下降，不等于组织总成本下降。

2. 把所有人都要求精确填工时

精细记录有价值，但记录本身也有成本。如果一个团队要求每个人每天拆分到多个项目、反复修正小时数，而这些数据没有用于资源决策，那么填报只是新增行政负担。它甚至可能让员工为了让数字看起来合理而调整记录，降低数据可信度。

更实用的做法是分层采集。项目负责人记录关键里程碑和总体投入，核心岗位按任务或每周投入比例记录，只有高成本、强审计或合同计费场景才要求更细粒度的工时。数据颗粒度应由决策需要决定，而不是由表格能拆多细决定。

3. 只把部门作为成本责任单位

部门预算能回答“钱从哪个成本中心支出”，却不一定能回答“这笔钱为什么花、支持了哪个结果”。如果成本只按部门归属，跨部门项目就容易出现责任空档：提出需求的团队不承担返工成本，实际投入的团队也没有权力控制需求变化。

因此，部门账与项目账要并行。部门账用于预算控制和资源规划，项目账用于把投入与交付关联起来。遇到共同投入时，可以采用明确的分摊规则，例如按实际人天、使用量或受益比例分配，但不要每次项目结束后临时协商口径。

4. 把工具上线当作问题解决

平台能统一入口、保留过程记录、减少信息散落，却无法自动消除模糊需求、反复变更或没有决策人的问题。如果团队把旧的混乱流程原样搬到新工具里，最后通常只是多了一层录入工作。

选型前应先明确要改善的具体行为：是需求变更不可追踪，还是审批周期太长？是项目投入无法汇总，还是跨部门依赖没有负责人？只有能说清楚问题和验证指标，才知道工具是否适用，也才能避免把“功能多”误认为“效率高”。

5. 把节省金额当作唯一成效

有些优化不会立即减少现金支出，却能释放关键人员的容量。例如，把需求评审从反复补材料改为一次提交完整信息，可能减少多个部门的等待时间；即使员工薪资没有变化，团队也能把时间投入到更重要的交付上。

这类改善要区分“成本减少”和“容量释放”。成本减少通常表现为付款、外包或加班费用下降；容量释放则是同样的人能完成更多高价值工作。两者都重要，但不能把释放的工时直接宣称为现金节省，除非它确实减少了加班、外包或新增招聘需求。

四、专业判断逻辑：先确定口径，再定位损耗，最后做取舍

1. 先定义成本口径，避免不同部门各算各的

成本分析开始前，先定义时间范围、组织边界、费用类别和折算方法。例如，人力成本是按工资全成本折算，还是只计算项目工时？等待成本是否纳入，若纳入，是否按等待人数和时长估算？供应商费用按合同签订、验收还是付款确认？这些问题没有唯一答案，但必须在同一分析中保持一致。

我建议把成本分成“实付成本”和“估算成本”。实付成本包括发票、合同和付款记录，可由财务数据核验；估算成本包括等待、返工和内部工时，需要标注折算假设。两者可以放在同一张分析表里，但不能混成一个看似精确的总数。

（1）人力投入的折算方式

若需要把工时折算为金额，可用“项目投入工时 × 岗位小时成本”作为估算。岗位小时成本可以用年度综合用工成本除以可工作小时数得到。综合用工成本是否包含福利、办公、设备及管理分摊，要由组织明确。若无法可靠取得薪酬数据，可先用人天记录做容量分析，不必急着折算金额。

（2）等待成本的估算边界

等待并不等于每一分钟都损失了工资。员工在等待期间可能处理其他任务，因此直接用“等待天数 × 所有参与人员成本”往往会夸大损失。更稳健的方式是先区分阻塞等待与可并行等待，再记录是否导致关键路径延后、人员空置或额外加班。只有能够说明影响机制，估算才有管理意义。

2. 用成本偏差定位问题，而不是先归责

可以把项目实际消耗与基准计划进行对比，并把差异归入范围变化、估算偏差、效率损耗、外部价格变化和风险事件。偏差分类的目的不是给人贴标签，而是判断下一步应改变什么：需求确认方式、估算方法、供应商策略、审批链路，还是资源配置。

当偏差出现时，先问“哪个决策或输入变化导致它发生”，再问“下次怎样提前发现”。如果复盘只留下“加强沟通”“提高意识”这样的结论，下一次项目很可能再次遇到同样的问题，因为没有新增规则、信号或责任人。

3. 建立成本指标的因果链

成本指标需要与过程指标相连。比如，外包费用增加可能不是采购价格问题，而是需求范围持续变化；交付延期也不一定是执行速度慢，可能是审批节点等待过久。若只看结果指标，团队通常只能在项目结束后发现问题；过程指标则能帮助项目中途调整。

• 投入类：项目预算使用率、关键岗位投入人天、外部服务费用。
• 过程类：需求变更次数、审批中位时长、阻塞事项平均处理时长。
• 质量类：返工工时占比、验收一次通过率、上线后缺陷数量。
• 结果类：计划与实际交付周期差异、预算偏差、交付目标达成情况。

指标不宜一次铺太多。第一阶段可以选三到五个能触发行动的指标。比如审批中位时长连续两周超过约定阈值，就由流程负责人检查卡点；返工工时占比升高，就回看需求变更和验收标准。指标必须对应明确动作，否则只是仪表盘上的装饰。

4. 以“可控、可验证、可逆”筛选改进动作

成本改善方案可以用三个问题筛选：团队是否能控制？效果是否能验证？如果判断错了，能不能撤回？例如，减少重复录入通常可控、容易验证且可逆；削减关键测试资源可能短期节省明显，却难以控制风险，也可能在上线后造成高额损失。

我会优先推进低风险、高复用的改进，再处理需要组织授权的结构性问题。对高风险动作采用小范围试点，设定停止条件，例如缺陷率明显升高、关键节点延期或用户投诉增加时暂停扩展。这样做不是追求保守，而是减少一次性大规模决策的不可逆成本。

五、具体案例与数据观察：用一个试点项目跑通从记录到复盘

1. 案例设定：先选问题足够集中、又不至于失控的项目

以下案例为方法演示，数据属于情景模拟，不代表某家企业的真实经营结果。假设一家拥有多个业务部门的企业，需要在12周内完成客户服务流程改造，项目涉及业务、产品、研发、运营和财务。团队先不追求全公司推广，而是选一个业务链路相对清晰的项目试点。

项目启动时，团队采用一个统一项目编号，把预算、需求、任务、变更、审批和验收记录关联起来。若已有PingCode一类项目管理平台，可以在其中维护需求、任务、负责人、计划日期与变更记录；付款凭证和财务科目仍以财务系统为准，通过项目编号进行对照。若暂时没有平台，也可以先用规范的共享表格和固定周会跑通口径。

试点有四条规则：新需求必须说明目标和影响范围；影响预算或关键路径的变更要由项目负责人确认；阻塞事项必须有责任人和下一步动作；每周复盘只讨论偏差最大的三项，不把会议变成逐条读表。

2. 先量化基线，避免把“感觉变快了”当成果

试点前四周，团队记录预算、关键岗位投入、审批时长、需求变更和返工工时。数据不是为了考核个人，而是建立比较基线。比如审批时长按“事项提交到首次明确结论”的自然日计算，返工按因已确认内容被推翻而重复完成的工时计算，不把正常迭代改进算作返工。

基线建立后，管理者可以看到问题集中在哪里。若审批等待长但没有造成关键路径延迟，优先级可能不高；若某类需求变更反复触发设计和开发返工，即使金额不大，也值得优先干预。成本管理的关键不是找出最大的数字，而是识别最有机会改变的成本来源。

3. 试点中的一项改动：把需求变更从消息变成可评估事件

过去，变更可能出现在会议纪要、即时消息或口头沟通中。试点后，每条变更都需要记录提出原因、影响模块、涉及团队、预计投入、是否影响关键路径和批准人。这样做增加了少量记录工作，却减少了团队对“谁说过什么”的争论。

每周由项目负责人汇总变更，不要求所有人重复填表。对于低影响、可在现有预算内消化的调整，团队可以快速处理；对于会改变范围或交付日期的变更，则由业务负责人和项目负责人一起决定接受、延期还是替换原需求。变更管理的价值不是阻止变化，而是让变化的代价可见。

4. 情景模拟结果：改进目标要同时看成本和交付

以下数据用于展示一种可能的试点评估方式，均为情景模拟。若团队在试点前后比较，应保持项目范围、统计周期和指标口径尽量一致；如果项目中途发生重大外部变化，应单独标注，不能把所有变化都归因于某项工具或流程。

这组模拟数据想表达的不是“平台上线后一定节约多少”，而是评估应同时包含过程、投入与质量。审批变快、返工减少是正向信号；重大缺陷没有变化，只能说明暂时没有出现明显质量恶化，不能推导出缺陷风险已经降低。

5. 用投入产出框架检查是否值得继续

试点结束后，可以把实施成本也记入账本：项目负责人维护规则的时间、团队培训时间、平台配置或表格维护时间，以及数据清理工作。若试点减少的重复投入无法覆盖这些成本，不一定要立刻判定失败，可能是项目周期太短、流程设计过重，或试点选错了业务场景。

假设试点每月减少32人时返工，但新增维护和协调工作为12人时，那么净释放约20人时。这个结果尚不能直接等同于现金节省，却可以帮助团队判断是否值得继续：如果释放的是稀缺岗位时间，并能转投关键交付，价值可能较高；如果释放的时间没有形成可用容量，或者只是转移到别的报表上，改善就很有限。

六、从0到1的行动方案：用90天建立最小可用机制

1. 第1至2周：选场景、定边界、统一词汇

第一阶段不要先做全公司制度。找一个跨部门、持续时间足够、又有明确交付目标的项目作为试点。项目不能小到没有协作复杂度，也不要大到一旦失败就影响核心经营。优先选择需求变化明显、部门交接较多或预算偏差反复发生的场景。

• 明确试点项目的起止日期、负责人和参与部门。
• 确定成本类别：现金、工时、等待、返工是否都纳入。
• 统一项目编号、需求编号和变更记录的关联方式。
• 约定数据责任人和复盘时间，避免最终只有财务负责收集。

这一步的产出不应是几十页制度，而是一页口径说明和一张字段清单。若团队不能用两分钟解释每个字段的含义，字段就可能过多或定义不清。

2. 第3至4周：建立基线，先记录而不急着追责

至少用两到四周观察现状，记录项目预算、关键岗位投入、变更、等待和返工。对于等待事件，建议同时写明阻塞对象、开始时间、结束时间、是否影响关键路径；对于返工事件，写明触发原因和涉及工作，不要只写“沟通问题”。

基线期要特别避免把数据收集变成考核。若员工担心工时记录会被用于个人排名，就可能倾向于少报、合并或修饰数据。此阶段的目标是发现流程规律，不是寻找“谁最慢”。管理者要明确说明数据用途，并限制访问范围。

3. 第5至8周：选择一个高影响原因做小范围干预

基线出来后，按发生频率、影响范围、可控程度和改进成本排序。选择一个原因深入处理，例如需求缺少验收标准、审批材料反复补齐，或者共享信息没有唯一来源。一次只改一两个关键环节，便于判断改善是否来自这项变化。

如果问题是审批等待，可以设定服务时限、明确替代审批人、建立缺件退回模板；如果问题是需求反复，可以增加变更影响评估和业务确认；如果问题是重复录入，可以确定唯一事实来源和自动同步原则。不要同时改十项流程，否则即使结果变好，也很难知道哪项措施真正有效。

4. 第9至12周：复盘、调整、决定推广还是停止

复盘时比较基线与试点期数据，先确认统计口径和项目范围是否一致，再解释变化原因。除了平均值，还要看中位数和极端情况，避免少数特别顺利或特别困难的事项扭曲结论。必要时抽样检查原始记录，验证分类是否一致。

试点后可以作出三种决定：效果明确且负担可接受，继续扩展；方向有效但流程过重，简化后再试；改善不明显或风险上升，停止当前方案并复查假设。停止某项试验不等于管理失败，明知无效仍扩大才会造成更大的成本。

5. 工具、表格与平台如何配合

初始阶段，工具的核心任务是让信息可关联，而不是追求功能齐全。若团队采用共享表格，至少应设置固定字段、变更记录和权限；若跨部门事项多、需求与任务关系复杂，使用项目管理平台可能更方便统一查看状态、责任人、依赖关系和历史记录。

对于100人以上的组织，平台选择要重点验证权限模型、项目组合视图、流程适配、数据导出、审计能力和跨团队协作体验。PingCode一类平台可以承载项目过程与协作信息，但预算审批、财务入账、人力成本核算仍应与相应业务系统明确边界。选型演示时，应让真实项目负责人完成一条从需求到验收的流程，而不是只看产品介绍页。

对小团队，如果现有工具已经能清楚记录负责人、状态、截止时间、变更和复盘，没必要为了“数字化”重复采购。先把字段、责任和会议节奏跑顺，再根据协作复杂度决定是否升级工具。

七、不同情况下的行动建议：同一套方法不必套在所有组织上

1. 预算已经超支，但项目仍在进行

先暂停新增的非关键范围，建立滚动预测，而不是简单冻结所有支出。将剩余预算、已承诺费用、尚未付款费用和预估完工成本分开列出，优先识别会改变关键路径或造成不可逆损失的项目。随后由业务负责人确认哪些目标必须保留，哪些可以延期或替代。

此时要把“已花的钱”与“继续投入是否划算”分开。已经支付的费用不能成为继续追加资源的唯一理由；同时也不能因为已经超支就立刻停掉关键工作。决策应比较剩余投入与未来收益、风险和替代方案，而不是被沉没成本牵着走。

2. 实际支出不高，但团队总是加班和延期

这通常意味着财务账没有覆盖全部成本，或者项目估算只看外部支出。先梳理关键岗位投入、阻塞等待、返工和计划外工作，再判断是否存在资源冲突、需求过载或决策权缺失。加班可能是容量问题，也可能是变更和等待造成的峰值问题，不能一概归因于员工执行力。

建议把加班时段与需求变更、审批延迟、缺陷修复等事件对应起来。如果加班集中在项目末端，优先检查验收标准和集成测试安排；如果持续发生在同一关键岗位，则需要看资源配置与优先级，而不只是要求提高效率。

3. 预算数据完整，但很难解释投入产出

这时应把项目或业务目标作为连接点，为每笔主要投入标记对应的交付物、服务对象或风险控制结果。不是每一笔投入都能直接产生收入，但至少需要解释其目的：合规、可靠性、效率、客户体验或能力建设。

对于探索性项目，不要用短期收入回报作为唯一评价标准。可以设置阶段性证据，例如假设是否验证、用户是否完成关键动作、技术风险是否降低、后续投资决策是否更清楚。探索项目需要明确停止条件，否则“长期价值”容易成为无法复盘的理由。

4. 跨部门经常争论成本该由谁承担

先确认争论的是责任、预算归属，还是资源优先级。三者不是同一个问题。费用可按受益部门或成本中心分摊，但流程改善往往需要由项目负责人承担协调责任；若仅为分摊比例争论数周，协调成本可能已经超过争议金额。

对共同项目，可在启动时约定分摊规则和变更处理方式。遇到规则未覆盖的情况，按统一原则暂时处理并记录例外，不要每次重新谈判。项目结束后再修订规则，避免临时决定变成长期惯例。

5. 组织没有成熟数据基础

先从少量、稳定、易核验的数据开始，例如合同金额、项目状态、关键变更和主要里程碑。不要因为数据不完整就完全不做管理，也不要用未经验证的估算冒充精确财务数据。初始阶段的目标是建立共同观察点，逐步提高数据质量。

可以在报表上标注数据等级：财务系统确认、人工复核、估算值。管理者看到数字时就知道它的可信程度，团队也更容易识别下一步需要补齐的字段。

八、不同情况下的取舍：优化成本时，哪些不能省、哪些可以试

1. 省现金还是保交付，要看受影响的关键能力

如果成本项直接关系到合规、安全、核心稳定性或客户承诺，短期削减应格外谨慎。可以先检查采购方式、使用率、合同范围和重复资源，再决定是否压缩投入。直接砍掉关键控制环节，可能把可预测的预算支出换成不可预测的事故损失。

若某项支出利用率低、可替代性高、对关键路径影响小，则更适合做试验性削减。设置观察周期和恢复条件，例如服务质量下降、处理时长变长或故障数量增加时及时恢复。成本优化最好允许回滚。

2. 精确核算还是快速决策，要看决策后果

如果一项预算决策涉及大额投入、长期合同或法规要求，应提高核算精度并保留审计依据。如果只是决定某个小范围流程是否值得继续，过度追求精确分摊可能耗费更多时间。管理数据不是越多越好，而是要足以改变选择。

可以使用“重要性门槛”：低于某个金额或影响范围的事项，采用简化记录；超过门槛后，要求补充成本、风险和替代方案。门槛应根据组织风险承受能力设定，而不是照搬其他公司的数字。

3. 统一流程还是保留灵活性，要区分共性与例外

统一项目编号、变更留痕、责任人和验收标准，通常有助于跨部门协作；但不同业务的审批链、风险要求和交付节奏未必相同。试图把所有项目塞进完全一致的流程，可能让低风险事项也承担过重手续。

更合理的方式是“统一底座、分级执行”：所有项目遵循最小公共规则，高风险、大预算或强依赖项目增加控制点，小型探索项目采用轻量流程。例外必须有理由、负责人和复核时间，避免灵活性演变为无规则。

4. 立即推广还是继续试点，要看证据强度

单个项目改善只能说明方案有可能有效，不能证明所有部门都适用。推广前至少要检查：改善是否来自流程变化而非项目难度较低？团队是否额外投入了大量维护时间？质量和风险有没有同步变化？不同部门是否具备同样的数据基础？

如果方案涉及权限、财务口径或组织职责，建议先在相邻团队复验，再逐步扩展。相反，若改动是低风险的记录规范，例如统一项目编号，可以较快推广，但仍要保留反馈渠道。推广速度应与风险和可逆性匹配。

九、结语：从“花了多少”走向“为什么花、是否值得、如何改进”

1. 成本管理的独特价值，是让隐性消耗进入决策

我不把成本管理理解为财务部门对支出的事后检查，而把它看作跨部门共同维护的一套决策语言。现金支出、内部工时、等待、返工和质量风险，需要被放在同一条业务链路里讨论。只有这样，组织才能分清哪些投入创造结果，哪些损耗可以改变，哪些节省只是把问题推到了别处。

从0到1不需要先建一套庞大的成本体系。先选一个项目，统一口径，建立基线，找出一个高影响原因，再通过小范围试点验证。做到每次偏差都能解释、每项改进都有负责人、每个节省都不以质量和风险为代价，成本管理才真正开始运转。

2. 下一步可以从一张项目成本卡开始

今天就可以为一个正在进行的跨部门项目建立成本卡，至少记录项目目标、预算与已承诺支出、关键岗位投入、需求变更、阻塞事项、返工原因、验收结果和下一步决策。先连续记录四周，不急着做个人排名，也不急着宣布节省目标。

四周后，选出最值得处理的一项损耗，提出一个能在一个月内验证的动作，并同时观察成本、交付和质量。成本管理真正从0到1的标志，不是表格填满了，而是团队开始依据同一组事实，决定哪些事继续做、哪些事应该改变、哪些事不值得再投入。