审批管理指南：实施团队如何做好工时表，最佳实践全流程

实施团队做工时表，最常见的失败不是员工忘了填，而是团队把工时表做成了“月底补数字”的报表：项目经理拿不到及时的成本信号，财务无法解释偏差，员工却要反复填报和修改。我的判断是，工时表的价值不在记录每个人忙了多久，而在于把工作、预算、审批和后续决策连成一条可追溯的链路。本文以实施项目常见流程为基础，拆解工时表从设计、填报、审批到分析的完整做法；涉及的数字案例均为情景模拟，用来展示测算逻辑，不代表行业统计或任何企业的真实结果。

一、核心结论：工时表不是考勤表，而是项目决策的输入

1. 先把“为什么记工时”说清楚

工时表记录的是员工在某段时间内，把多少工作投入到哪个项目、任务或内部活动。它可以支持项目成本核算、预算预测、合同结算、资源安排和复盘，但不能单独证明一个人工作得好或不好。把这几个目的混在一起，往往会让员工猜测数据将如何被使用，填报行为也随之变形。

我建议在上线之前先确定工时数据的第一用途，并明确哪些用途不在本轮范围内。例如，第一阶段用于项目预算与成本预测，就不要同时把小时数直接作为绩效排名依据。数据用途越清楚，员工越容易判断该填什么；用途越模糊，越容易出现补填、虚填和防御性审批。

2. 建立一条短而完整的控制链

一套可执行的流程至少需要五个环节：工作对象定义、员工及时填报、负责人核验、异常处理、数据进入项目分析。链条中任何一个环节缺位，工时表就可能只剩下“有人填、有人批”，却没有人拿数据做决策。

1. 先定义对象：明确项目、阶段、任务、支持活动和非项目工作的编码规则。
2. 再规定节奏：员工按日或按周记录，避免月底依赖记忆重建。
3. 让审批有边界：审批人核验归属、合理性和例外，不替员工重写工作事实。
4. 用异常驱动复核：重点关注超预算、跨项目冲突、缺失和集中补录。
5. 把结果带回计划：将实际工时与剩余工作量、预算和交付状态一起复盘。

3. 用决策问题验收工时表

上线验收不应只看“多少人填了”，而应看数据能不能回答管理问题。项目负责人至少应能判断：当前阶段实际投入是否超出计划；偏差来自范围变化、返工、等待还是估算错误；剩余预算能否覆盖未完成工作；哪些任务需要重新排期或升级处理。

如果系统只能导出一张按员工汇总的小时数表，却不能回到具体项目和任务，管理者得到的往往是总量而不是原因。我会把“能否解释偏差”作为流程验收标准，而不是把填报完成率当成唯一成功指标。

二、实施团队的真实场景：为什么月底总会出现一堆“补填”

1. 项目工作不是单一任务流

实施团队通常同时面对项目交付、需求澄清、客户培训、上线支持、内部协调、售前协助和质量返工。一个人可能上午处理客户现场问题，下午参加项目评审，晚上还要整理上线清单。如果工时表只有“项目工作”和“其他”两个选项，员工很难准确归类，审批人也无法判断“其他”究竟是必要支持，还是项目范围正在失控。

这类场景中，填报难点常常不在输入小时数，而在判断应该记到哪里。项目编号、阶段、任务和活动类别如果不一致，数据就会在汇总时被拆散；如果选项太多、命名含糊，员工则会反复询问，最后选择最熟悉的类别应付。

2. 多项目并行会放大归属冲突

实施顾问同时支持几个客户时，实际工作会在项目间切换。某次会议可能同时讨论公共产品问题和某客户的配置方案；一次线上故障处理也可能暴露出产品缺陷。若没有归属判断规则，员工容易把整段时间记到最熟悉的项目，或者把公共问题全部摊到某一个客户项目。

我建议规定“可验证的直接工作优先归属，跨项目公共工作按明确规则分摊”。例如，针对单一客户环境的配置和问题排查记入该客户项目；涉及多个项目的共性方案评审，记入共享支持类别，必要时再按受益项目分配。不要要求员工在没有依据时做精确到分钟的成本分摊，精细不等于可信。

3. 记忆回填会制造精确的错觉

月底补填常见的表象是数字很整齐：每天刚好八小时，任务时长也常以整数结尾。它看上去完整，实际上可能是根据日历和印象估算。回忆误差不只影响员工个人，还会让项目负责人误以为某类工作投入稳定，进而错误调整估算和资源计划。

填报周期应根据工作节奏设置。任务变化快、项目切换多的团队，适合每天记录；工作内容稳定、项目数量少的团队，可以每周集中核对，但仍应在工作发生后及时留下任务线索。合理目标不是“时时刻刻计时”，而是把补填窗口控制在记忆仍可靠的范围内。

4. 审批慢会把管理风险推迟到结算之后

如果审批人每周只在月底集中处理，项目预算超支可能已经发生，客户变更也可能已经交付，团队无法再及时澄清投入原因。审批晚还会让员工误以为记录不重要，下一周期继续拖延，形成“越拖越难审、越难审越拖”的循环。

审批时限要与管理动作匹配。日常记录可以按周核验；涉及客户结算或预算红线的项目，则应设置更短的异常提醒和升级路径。审批不必把每条记录都变成调查，但要能快速识别值得进一步追问的记录。

三、常见误区：看似严格，实际会降低数据可信度

1. 误区：要求所有人精确到十五分钟

精度要求越细，未必越准确。若员工需要频繁切换计时、补录碎片任务，记录成本会上升，注意力也会从交付转向维护表格。对于以阶段性工作为主的实施项目，按小时或半小时记录往往足以支持成本复盘；只有在合同明确按短时段结算、或工作高度碎片化且必须核算时，才有理由进一步细化。

精度应由决策需要决定，而不是由系统能输入多少位小数决定。若管理者无法据此采取不同动作，增加精度只是制造操作负担。

2. 误区：工时越多，绩效越好

工时表示投入，不等于产出，也不直接代表效率。有人记录时间较长，可能是负责复杂问题、承担客户现场支持或处理返工；有人记录较少，也可能是任务估算不足、漏填，或者把工作记到了别的类别。把小时数直接用于个人排名，会诱发延长记录、拆分任务和争夺可计费工作的行为。

若要讨论绩效，应结合交付质量、客户结果、任务复杂度、责任范围和协作贡献，不能把工时表变成唯一评价口径。工时数据适合解释工作结构，不适合独立判定人的价值。

3. 误区：审批越多层，数据越可靠

多层审批有时只是把责任向上推。每增加一层，如果没有不同的核验职责，就会延长周期，却不一定发现更多问题。更有效的设计是让员工对记录真实性负责，直属负责人确认项目和任务归属，项目负责人关注预算与范围，财务或运营角色抽查编码和结算规则。

不同角色应审不同问题。审批链条越长，越要说明每一层的输入、时限和退回条件；否则员工只会看到等待，而看不到控制价值。

4. 误区：所有非客户工作都算“管理时间”

团队内部支持往往包含项目必需的交接、方案复核、培训准备和质量控制。如果全部归到笼统的内部管理类别，项目真实成本会被低估，团队也无法判断哪些支持活动正在吞噬交付能力。

我更倾向于把非客户工作分成少数可行动的类别，例如内部协作、产品或技术支持、培训与能力建设、售前支持、行政事务。分类的目的不是给每分钟贴标签，而是让组织能看清资源被什么类型的工作占用。

5. 误区：只追求填报完成率

完成率高不等于内容可信。若员工为赶截止时间一次性补满，或审批人不看内容直接批量通过，系统会呈现漂亮的覆盖率，却不能支持预算预测。管理者应同时看及时率、退回率、异常关闭时长和数据可解释率。

例如，一条记录有项目、任务、日期、时长和合理说明，才具备基本解释能力。若这些字段齐全但内容仍模糊，抽样复核还要看记录是否能与任务状态、会议纪要或变更单相互印证。

四、专业判断逻辑：如何设计字段、规则和审批边界

1. 先按管理用途设计字段

字段越多，维护成本越高；字段越少，后续分析越容易失去解释力。我的做法是从管理问题倒推字段：要分析项目成本，就需要项目、任务或阶段、日期、时长；要区分客户工作和内部投入，就需要活动类别；要解释异常，就需要简短说明或关联变更记录。

每个字段都应回答一个明确问题。如果字段既没有用于审批，也不会进入报表或决策，就应认真考虑是否保留。尤其要避免把同一个信息分别放在多个自由文本字段中，让员工反复录入、让分析人员事后清洗。

2. 把审批规则分成常规和例外

常规记录应尽量轻量：项目和任务有效、时长在合理范围、日期符合规则，就由负责人快速核验。例外记录才进入更深检查，例如超出任务预算、同一时段重复登记、跨项目分配明显异常、提交时间过晚或项目已关闭仍有投入。

设置例外规则时，要给“为什么触发”和“谁处理”各一个明确答案。只设置红色警告但没有负责人、期限和关闭方式，会产生更多提示，却不会减少风险。

• 缺失记录：提醒员工补充，并区分休假、非项目工作和漏填。
• 时长异常：核对当天是否存在重复记录、跨时段冲突或特殊现场安排。
• 预算偏差：项目负责人结合剩余工作量、变更和返工判断是否需要重估。
• 迟交记录：保留补录原因，用于改进流程，而不是默认认定为不实。
• 项目关闭后仍有工时：确认是否为保修支持、收尾工作或项目状态未及时更新。

3. 让审批人审“可解释性”，不是审个人态度

审批人的核心问题应是：这项工作是否属于该项目；记录时长是否与任务规模和上下文大致匹配；若偏离计划，是否有可核验的原因；是否需要调整预算或排期。审批不是判断员工“够不够努力”，也不是要求每一小时都写成可供辩护的说明。

对常规记录快速通过，对异常记录要求补充上下文，是比所有记录逐条深审更合理的分层方式。它既保留了管理控制，也减少了审批人把大量时间耗在低风险事项上。

4. 设定迟交、退回和更正规则

流程要明确每周截止时间、审批时限、退回理由和修改留痕。迟交记录可以补录，但应保留原发生日期和提交日期；被退回的记录要说明具体问题，不能只写“请修改”。已审批记录若需更正，应留下修改人、时间和理由，避免事后覆盖原始数据。

规则还应覆盖离职、休假、跨团队借调、项目转阶段和项目关闭等边界情况。越是容易被忽略的情形，越可能在月底集中变成例外工单。

五、实施流程：从试点到稳定运行的完整步骤

1. 盘点现有工作对象和编码

不要一开始就配置审批流。先盘点项目类型、阶段、任务结构、共享支持和非项目活动，找出哪些对象需要在工时表中出现。项目编码应有维护责任人和生命周期规则，避免同一项目同时存在简称、客户名和内部代号三套写法。

实施团队可以从最近一个季度的项目清单中抽样，检查同类工作是否被不同人员记在不同类别。若同一活动的归属口径都说不清，先统一分类再谈报表，否则系统只会更快地产生不一致数据。

2. 先写一页规则，再配置系统

把填报对象、记录粒度、截止时间、审批角色、异常情形、补录和更正要求写成简明规范。员工要能在几分钟内找到答案：某类工作记到哪里、项目已关闭怎么办、客户培训是否属于项目投入、多个项目共享会议如何处理。

工具配置应服务于规则，而不是让规则迁就复杂的表单。字段名称、选项说明和默认值都应尽量贴近团队语言。若团队使用 PingCode 管理项目和任务，可先核对任务结构、成员权限及工时相关流程是否匹配，再决定如何配置或补充流程；这类平台更适合中大型企业和百人以上组织评估，但具体能力、版本范围和适配方式应以当前产品信息及实际验证为准。

3. 选择代表性项目做试点

试点不要只选流程最简单、负责人最配合的项目。至少覆盖一个多项目并行团队、一个客户现场支持较多的项目，以及一个存在较强变更或结算要求的项目。这样更容易提前暴露项目归属、共享工作和异常审批中的问题。

试点周期可以按团队节奏设定，例如运行四到六周后复盘。这个时间不是通用的行业标准，而是便于观察从首次填报、第一次审批到阶段性分析的示意安排。试点应验证员工是否看得懂规则、审批人能否按时处理、项目负责人是否能根据数据采取动作。

4. 用并行核对发现结构问题

试点初期可以把新流程与现有项目台账、排期和会议记录做有限度的并行核对，不是为了逐条监督员工，而是为了发现分类映射和项目编码问题。例如，一个项目周报显示完成了客户培训，工时表却没有对应投入，可能是遗漏，也可能是培训被记在共享支持类别，必须先弄清楚原因再作判断。

并行核对要设停止条件。若字段和规则稳定、异常原因可解释，就不必长期维护两套记录。重复登记会增加负担，也会让团队不知道哪个数据源才是最终口径。

5. 培训时用真实任务演示例外

单讲字段定义不够。培训时应演示几个高频情境：客户会议跨越两个项目怎么办；同一问题从客户支持转为产品缺陷怎么记；计划外返工要不要写说明；休假或培训怎样处理；审批退回后如何修改。场景越接近日常，员工越容易形成一致口径。

还应告诉员工数据的用途、访问范围和保留方式。若这些问题没有被回答，员工很可能把工时填报理解为隐性的监控，进而选择最安全、最模糊的类别。

6. 复盘流程，不只复盘数字

首次复盘要同时看数据与流程：记录是否及时、审批是否积压、哪些类别经常被误选、哪些异常规则过于敏感、项目经理是否读懂了偏差。若出现大量退回，不一定说明员工不认真，也可能是类别难懂、任务结构不完整或审批人要求不一致。

建议把问题按“规则问题、配置问题、培训问题、项目管理问题”分类，再决定由谁修复。若只是不断提醒员工，却不检查表单设计和项目编码，流程效果往往难以改善。

六、案例与数据观察：从工时偏差找到真正的管理动作

1. 一个四周试点的情景案例

假设某实施团队共有二十四名成员，同时负责六个客户项目。团队过去以月末汇总为主，项目负责人能看到总投入，却难以分辨客户变更、内部等待和返工各占多少。新流程试点后，团队按周登记，并将工作分成直接交付、客户支持、内部协作、返工和培训五类。

以下数字是情景模拟，用于说明分析方法，不是实际企业案例或行业均值。假设试点前每月整理工时和核对项目记录需要十六小时，试点稳定后降至八小时；及时填报率从百分之六十五升至百分之八十八；这并不自动说明交付效率提高，但说明数据更快进入了管理视野。

进一步分析发现，一个项目在配置任务上超出计划约百分之三十。单看超时，很容易要求团队加快进度；结合变更记录后发现，客户新增了两轮权限方案确认，且部分配置因需求口径变化返工。管理动作因此从“催进度”转为确认变更范围、更新预算并重新约定交付节点。

另一个项目的客户支持投入显著增加，但交付任务工时没有同步增加。团队复核后发现，多个问题都源于同一类环境准备缺失。于是项目负责人把环境核验前置到上线准备清单，并在后续项目中观察重复问题是否下降。工时表在这里的价值不是抓出谁花了太多时间，而是把重复成本定位到可以改进的环节。

2. 先看指标组合，再解释单项变化

若只看及时填报率，团队可能误以为流程已经成熟。更合理的判断应至少结合及时率、退回率、审批耗时、异常关闭时间和偏差解释率。一个指标改善、另一个指标变差，可能意味着流程正在把工作从员工端转移到审批端，或规则过严导致大量退回。

下面的数值是模拟试点数据。它展示了如何用一组指标观察流程变化，不应直接作为所有组织的目标线。不同项目的结算方式、人员分布和工作节奏不同，适宜基准应由团队用自身基线逐步确定。

3. 将成本偏差拆成原因，而不是只展示超支百分比

项目实际投入超过计划时，至少要区分五类原因：范围变化、估算不足、返工、等待或依赖阻塞、资源中断。它们需要不同的管理动作。范围变化需要变更管理；估算不足需要修正模型；返工要追根因；等待可能需要客户或其他团队配合；资源中断则可能需要调整排期。

一个实用的复盘格式是：计划投入、实际投入、偏差、原因证据、剩余工作量、下一步动作和责任人。只有“偏差百分比”而没有后续计划的报告，通常只能制造焦虑，不能帮助项目恢复。

4. 以工作结构趋势识别系统性成本

工时数据积累后，适合观察类别变化，而不是立即比较个人。若多个项目的返工占比持续上升，可能意味着需求澄清、测试或交接存在系统问题；若内部协调投入在项目后期明显增加，可能说明前期方案和责任边界不清；若客户支持投入集中在上线后，则应检查培训、知识转移和上线准备。

趋势分析必须控制项目阶段和类型。一个刚上线的项目与一个进入稳定运维的项目，工作结构天然不同。把不同阶段的项目简单平均，可能掩盖真实变化。

七、不同组织情况下的行动建议与取舍

1. 小团队或项目数量较少：先用轻流程验证口径

如果团队人数不多、项目结构简单、成员互相熟悉，先用轻量表单和固定分类验证规则可能更合适。重点是统一项目编码、及时记录和每周复核，不必马上配置复杂的多级审批与成本分摊模型。

取舍在于：轻流程上线快，但当项目数量、跨团队协作和结算要求增长时，表格维护会越来越依赖少数人。此时应观察是否出现重复项目名、审批积压、月底汇总耗时增加和报表口径不一致，再决定何时升级。

2. 百人以上、多项目并行组织：先治理数据责任

中大型组织的难点往往不是缺少表单，而是项目、任务、角色和权限的责任边界不清。应明确谁维护项目目录、谁管理任务结构、谁处理跨项目支持、谁批准预算例外，并让这些责任与现有项目管理流程对齐。

如果组织考虑使用 PingCode 等项目管理平台，可以把工时管理作为项目流程的一部分评估，而不是单独比较某个填报界面。需要重点验证项目任务与工时记录的关联、角色权限、审批配置、报表口径、历史数据迁移和组织现有流程适配度。产品能力及适用范围应以当前实际版本、合同和试用验证为准。

取舍在于：统一平台有机会减少重复录入、提升项目与工时数据的关联性，但前期需要治理项目目录和规则。若组织尚未统一项目编码，先采购或配置复杂功能，通常只会把旧问题搬进新系统。

3. 固定价格项目：优先看预算消耗和剩余工作

固定价格项目中，工时表主要用于理解内部成本和预测毛利风险。项目负责人不应只看已投入工时，还要结合已完成工作、剩余工作量、变更状态和风险储备。若实际投入接近预算但交付只完成一半，必须尽早重估，而不是等到结项再解释。

取舍在于：成本数据越及时，项目越有机会通过范围控制、资源调整或正式变更止损；但为了提高核算精度而要求过多细节，可能给交付团队带来不成比例的记录负担。应优先保证项目归属和偏差原因可信。

4. 按工时结算项目：强化可核验性和合同映射

按工时结算时，工时记录可能直接关联客户确认、账单和争议处理。需要把合同可计费规则映射到活动类别，明确哪些工作可计费、哪些需要事先批准、哪些属于内部返工或质保支持。记录应能对应到服务日期、工作内容和客户认可的任务范围。

取舍在于：较强的证据链有利于结算和争议管理，但不能为了客户审计而把内部管理数据暴露给不适当的访问对象。应区分内部工时记录与对外提交材料，明确权限、审批和导出规则。

5. 现场支持多、工作切换频繁：减少输入摩擦

现场实施和紧急支持团队常常无法在工作发生时立刻完成完整表单。可以使用简化记录入口，先快速选择项目、活动类别和时长，再在当天结束前补充任务或说明；也可以允许在规定窗口内更正，但保留提交时间和修改记录。

取舍在于：录入步骤少，能提高及时性；但过度简化可能让任务归属和说明缺失。可将“先记下来”和“完成核验”分为两个步骤，并对客户结算、预算红线和跨项目共享活动设置更明确的补充要求。

6. 数据用于绩效讨论的组织：先建立使用边界

若组织确实需要把工时数据用于绩效讨论，必须提前说明其角色：它是上下文证据之一，不是排名公式。还应明确不因合理的项目复杂度、现场支持或必要培训而惩罚员工；对于跨项目工作和公共贡献，设定一致的归属规则。

取舍在于：完全不讨论投入结构，可能看不到资源过载；把投入直接转成绩效分数，则会诱发数据操纵。更稳妥的做法是用工时识别工作分布和风险，再结合交付结果、质量、客户反馈、复杂度和协作责任进行综合判断。

八、审批管理的运营指标：用什么判断流程是否健康

1. 及时率要和补录比例一起看

及时填报率衡量员工是否在规则周期内提交记录，补录比例则反映有多少数据依赖事后回忆。及时率升高而补录比例仍高，可能只是提交动作更快，但实际记录仍集中在周期末；因此需要同时观察发生日期与提交日期之间的间隔。

团队不应照搬统一目标值。可以先用四到六周建立本组织基线，再设定逐步改善目标。目标需要按工作性质分层，例如驻场支持、跨项目顾问和固定项目小组的记录节奏可能不同。

2. 审批时长要拆成排队和处理时间

从提交到审批完成的总时长，不能说明审批人处理慢还是审批队列积压。若系统能够区分等待时间和实际处理时间，就可以判断应调整审批人负载、提醒机制还是记录质量。对于退回记录，还应统计从退回到重新提交的时间。

审批时长变短不一定意味着质量更好。若退回率和事后更正率同时上升，可能是审批人过快通过；若审批时长增加但异常关闭质量提高，则可能是团队在处理复杂事项。指标应成组解释，避免单项追责。

3. 异常关闭率要有明确的关闭定义

“已处理”不能只是把提醒标记为完成。异常关闭应记录处理结论，例如确认无误、修改归属、补充说明、调整预算、建立变更或升级风险。只有结论能对应后续动作，组织才能区分系统噪声与真实管理问题。

对持续反复出现的异常，还要判断是否应修规则、改任务结构或培训相关角色。重复提示同一类问题，却不改变流程，说明组织把异常机制当成了通知系统，而不是改进机制。

4. 用数据解释率检查管理价值

我建议增加一个不必过度精细、但很有用的管理指标：偏差解释率。它可以定义为“已记录原因并有责任人或后续动作的重大工时偏差数，占重大偏差总数的比例”。这个指标不评价个人，而是检查项目管理是否真正解释了预算变化。

若偏差解释率长期偏低，问题可能在于项目任务粒度不足、变更没有登记、审批人没有时间复核，或报表只显示结果不显示上下文。解决方案应针对这些结构性原因，而不是简单要求员工写更长的说明。

九、不同方法的取舍：集中填报、分布式填报与自动化辅助

1. 集中填报：管理统一，记忆风险高

集中填报通常由项目助理或负责人月底统一整理，优势是格式一致、维护入口少，适合项目极少且工作记录已有其他可靠来源的团队。缺点是员工本人不直接确认时，记录容易变成推算，后续也很难追溯每项投入的依据。

若使用集中填报，应要求工作负责人确认汇总结果，并标明哪些数据来自任务记录、日历或客户工单，哪些属于估算。集中整理可以减少输入摩擦，但不应替代事实责任。

2. 分布式填报：责任清楚，必须降低使用成本

由实际工作者记录能更接近事实，也更便于关联任务。但如果入口复杂、项目选项混乱或频繁要求填写长说明，分布式填报很快会变成形式负担。团队需要靠清晰分类、默认值和简短培训降低操作成本。

取舍在于：责任越接近工作发生者，数据通常越容易解释；但流程设计必须允许合理的补录、调整和例外，不能假设所有人都能在每项工作完成后立即填表。

3. 自动化辅助：减少重复录入，不替代业务判断

自动化可以从项目任务、日历、工单或排班记录中提供建议值，帮助员工减少重复操作。但自动生成不等于真实工时：会议邀请可能没有实际参加，任务状态也不能证明投入时长，工单时间戳更不能完整代表解决问题所花的精力。

因此，自动化适合做预填、提醒、关联和异常检测，最终记录仍应由责任人核验。尤其涉及客户结算、成本归属或敏感人员数据时，必须明确数据来源、访问权限和更正机制。

十、结尾：先让每一条记录能解释，再追求更复杂的分析

1. 工时表真正解决的是“看不见的偏差”

实施团队做好工时表，不是让每个人看起来都很忙，也不是把每一分钟变成审计对象。它要帮助团队尽早发现工作归属、预算、返工、等待和范围变化之间的联系，让项目负责人有机会在问题变成结项损失之前采取行动。

我的独特判断是：工时表的成熟度，不取决于字段数量或审批层级，而取决于团队能否把异常从“一个数字不对”追到“原因是什么、谁来处理、怎样验证改善”。数据记录得再精细，如果不能触发正确动作，也只是更精细的归档。

2. 下一步按四周节奏启动

1. 第一周：盘点项目和任务编码，确定工时数据的首要用途，删除没有明确决策价值的字段。
2. 第二周：形成一页规则，明确记录粒度、填报时限、审批责任、补录和例外处理方式。
3. 第三周：选择代表性项目试运行，记录员工反馈、审批积压和分类疑问，不急于追求报表完整。
4. 第四周：复核及时率、退回率、异常处理和偏差解释情况，修订规则后再决定扩大范围。

如果团队只能先做一件事，我建议先统一“这项工作应该记到哪里”，并规定在记忆仍可靠时完成记录。随后再完善审批、预算分析和自动化。从可信的记录开始，而不是从复杂的审批开始，工时表才有机会成为项目管理工具，而不是新的月底负担。