人力成本归集的成本对象，按“归集目的决定颗粒度”来设定：用于项目核算就以项目为一级对象，用于产品线核算就以产品为一级对象，用于部门考核就以部门或团队为对象；研发阶段、工作包可作为二级对象。人员与费率是计量输入，不作为成本对象本身。本文按对象设定、工时与费率匹配、校验与上线检查的顺序，给出可直接套用的字段、步骤和清单。
要点总览（TL;DR）
- 成本对象按归集目的定颗粒度：项目核算以项目为一级对象，产品线核算以产品为一级对象，部门考核以部门或团队为对象，研发阶段或工作包可作二级对象。
- 人员、岗位、费率、工时是计量输入，成本对象是承载金额的核算单元；层级建议控制在两级以内，减少工时填报负担。
- 成本对象主数据至少包含唯一编码、名称、层级、上级对象、生效与失效日期、负责人；编码采用类型前缀加年份加序号，启用后不随名称变更。
- 工时记录必须携带成本对象编码与工作日期，匹配时按工作日期取当期有效费率，不用最新费率回溯历史工时。
- 出报表前执行完整性、归属唯一性、费率时效性和跨期一致性四类校验，异常按退回补录、挂待分摊池、责任人确认三条路径处理。
先定归集目的，再定成本对象颗粒度
成本对象是人力成本的“落点”，它决定每一笔工时最终被汇总到哪个核算单元。设定之前先回答一个问题：这次归集的结果交给谁、用来判断什么。用途不同，对象的层级和数量差别很大，先建对象再找用途，往往会出现对象过多、工时填不准、汇总口径对不上的情况。
研发人力成本归集常见三类目的，对应的对象层级如下：
| 归集目的 | 一级成本对象 | 二级成本对象（可选） | 典型用途 |
|---|---|---|---|
| 项目核算 | 项目 | 研发阶段或工作包 | 判断单个项目的研发人力投入，支撑项目结算或立项复盘 |
| 产品线核算 | 产品线或产品 | 版本或特性模块 | 比较不同产品线的研发投入结构，支撑产品取舍 |
| 部门与团队考核 | 部门或团队 | 项目（作为交叉维度） | 观察团队人力分布与产出匹配情况 |
需要区分成本对象与分摊依据。人员、岗位、费率、工时都是计量输入，用来把金额算出来并落到对象上；成本对象是承载金额的核算单元。把“某个人”设成成本对象，会导致人员变动后历史口径断裂，也无法按项目或产品汇总。正确做法是人员只出现在工时记录和费率表中，金额最终归到项目、产品或部门。
层级建议控制在两级以内。每增加一级，工时填报时就要多选一次，填报负担上升，选错的概率也随之增加。两级结构通常已能支撑“项目—阶段”或“产品—版本”的分析；如果确实需要更细的视角，优先通过工作项标签或报表维度实现，不把成本对象继续向下拆分。
成本对象的编码与字段设计
成本对象要能被填报、被汇总、被追溯，就需要一套稳定的主数据。字段设计的目标是让每个对象有唯一标识、有明确的上下级关系、有生效区间，避免同名对象或跨期改名造成口径混乱。
| 字段 | 说明 | 是否必填 |
|---|---|---|
| 对象编码 | 全局唯一，设定后不再变更 | 必填 |
| 对象名称 | 面向填报人的可读名称，允许调整 | 必填 |
| 层级 | 一级或二级 | 必填 |
| 上级对象 | 二级对象必须挂到某个一级对象下 | 二级必填 |
| 生效日期 | 对象开始可被工时引用的日期 | 必填 |
| 失效日期 | 对象停止接收新工时的日期 | 选填 |
| 负责人 | 对该对象工时与成本数据负责的人 | 必填 |
| 财务科目映射 | 对应内部核算科目或结算口径，仅作映射 | 选填 |
编码规则推荐“类型前缀＋年份＋序号”，例如项目类对象用 PRJ-2025-001，产品类对象用 PRD-2025-001。前缀区分对象类型，年份标识建立期间，序号保证唯一。编码一旦启用不随名称修改而变化，这样即使项目改名、产品调整定位，历史工时仍能按原编码追溯。
对象状态需要覆盖新增、合并和停用三种情况。新增对象从生效日期起可被引用；合并时保留原对象编码并标记停用，历史工时继续挂在原对象上，新工时引用合并后的对象；停用对象只关闭新工时入口，不改写已有记录。财务科目映射只做到“对象—科目”的对应层，用于把归集结果交给核算环节，账务处理不在本文范围内。
工时与费率的匹配步骤
从工时记录到人力成本金额，核心是按工作日期找到当期有效费率，再乘以工时。匹配规则的关键在于“按发生期取费率”，用最新费率回溯历史工时会让已出过的报表反复变动，跨期数据失去可比性。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 采集工时 | 人员、工作日期、工时数、成本对象编码 | 按日或按周填报，每条记录必须带有效对象编码 | 工时明细 | 当期工时记录全部有对象编码 |
| 2. 维护费率 | 人员或岗位、费率类型、生效区间 | 按时间段登记标准费率与实际费率 | 费率表 | 每位相关人员在当期都有覆盖的费率区间 |
| 3. 匹配费率 | 工时明细、费率表 | 按工作日期落在费率生效区间内取对应费率 | 带费率的工时明细 | 每条工时都匹配到唯一费率 |
| 4. 计算金额 | 带费率的工时明细 | 工时数乘以对应费率 | 单条人力成本金额 | 金额可逐条回溯到工时与费率 |
| 5. 按对象汇总 | 单条金额 | 按成本对象编码汇总工时与金额 | 对象级汇总表 | 汇总结果与明细合计一致 |
费率表建议区分标准费率与实际费率。标准费率用于内部核算和跨团队比较，实际费率反映真实人力投入成本，两者分别维护、分别出数，避免口径混用。费率按人员或岗位维护均可，按岗位维护时需保证同一岗位内人员的归属关系清晰。
项目投入比例可以作为校验参考，例如某成员在项目上填报的工时占比与其投入计划差异过大时提示复核，但投入比例不参与金额计算，金额只由工时与费率决定。汇总输出应至少包含：成本对象编码、对象名称、工时合计、人力成本金额，以及按人员或阶段的明细下钻能力。
当工时记录、对象编码与费率表分散在不同表格中时，匹配环节最容易出错。ONES 的项目与工作项结构可以作为成本对象的承载，工时记录挂在对应工作项上并携带对象编码，使“填报—匹配—汇总”在同一套数据里完成，减少手工对表带来的口径偏差。
归集数据的四类校验规则
归集结果在出报表前应先过校验，判断数据是否可用。四类规则分别覆盖“有没有”“是否唯一”“费率对不对”“跨期是否一致”，每条规则都要有触发时点和处理动作。
| 校验类型 | 规则 | 触发时点 | 处理动作 | 责任人 |
|---|---|---|---|---|
| 完整性 | 每笔工时都有有效成本对象与匹配费率 | 工时提交时、月度汇总前 | 退回填报人补录对象或补维护费率 | 填报人、费率维护人 |
| 归属唯一性 | 同一人员同一时段的工时不得重复归入多个成本对象 | 工时提交时 | 提示重复，由填报人确认后保留一条 | 填报人、项目负责人 |
| 费率时效性 | 费率生效区间覆盖工作日期 | 匹配计算时 | 缺失区间挂待分摊池，补维护后重算 | 费率维护人 |
| 跨期一致性 | 对象停用或合并后，历史工时保持原口径 | 对象状态变更时、跨期汇总时 | 锁定历史数据，仅对新工时应用新对象 | 成本对象维护人 |
异常处理需要明确路径，避免异常数据长期悬置。常见做法有三条：能补录的退回填报人限期补录；暂时无法确定归属的工时挂入待分摊池，在月度归集周期内由指定责任人确认后再分摊；涉及对象合并或停用的，由对象维护人确认历史口径不变。每条异常都应有状态和责任人，月度关账前清零或形成书面说明。
角色分工与各环节交付物
成本对象设定不是一次性动作，它和工时填报、费率维护、校验确认共同构成一个按月循环的机制。把每个环节的责任人和时点定清楚，归集才能稳定运行。
| 角色 | 主要动作 | 交付物 | 月度时点 |
|---|---|---|---|
| 成本对象维护人（如项目管理或财务接口人） | 新增、合并、停用对象，维护编码与映射 | 成本对象主数据表 | 月初完成当期对象清单 |
| 工时填报人 | 按日或按周填报工时并选择对象编码 | 工时明细 | 每周或按团队规定周期提交 |
| 项目负责人 | 确认本项目工时归属与投入合理性 | 工时确认记录 | 月末前完成确认 |
| 费率维护人（如人力或财务） | 按人员或岗位维护费率及生效区间 | 费率表 | 费率调整生效前完成更新 |
| 归集校验人 | 执行四类校验，处理异常，确认汇总结果 | 校验异常清单、对象级汇总表 | 关账前完成校验与确认 |
时点安排上，对象清单和费率表应先于工时填报就绪，工时确认先于校验，校验先于汇总出数。任何一个环节延后，都会把压力集中到关账前。角色可以由同一人兼任，但职责要分开记录，便于出现口径问题时定位到具体环节。
一个研发团队的归集示例
以下为演示情景，用于说明从对象设定到校验通过的完整过程，不代表任何真实企业案例。
某研发团队有 8 名成员，同时参与两个在研项目，管理层希望按项目和研发阶段看人力投入。团队按“项目—阶段”设定两级成本对象：
| 对象编码 | 对象名称 | 层级 | 上级对象 | 生效日期 |
|---|---|---|---|---|
| PRJ-2025-001 | A 项目 | 一级 | — | 2025-01-01 |
| PRJ-2025-001-D | A 项目—设计阶段 | 二级 | PRJ-2025-001 | 2025-01-01 |
| PRJ-2025-001-T | A 项目—测试阶段 | 二级 | PRJ-2025-001 | 2025-03-01 |
| PRJ-2025-002 | B 项目 | 一级 | — | 2025-02-01 |
工时样例：成员甲在 3 月 3 日填报 6 小时，对象为 PRJ-2025-001-D；成员乙在 3 月 5 日填报 8 小时，对象为 PRJ-2025-001-T。费率表显示甲的标准费率为每小时 120 元，生效区间为 2025-01-01 至 2025-06-30；乙的标准费率为每小时 100 元，生效区间为 2025-01-01 至 2025-12-31。按工作日期匹配后，甲该条金额为 720 元，乙为 800 元。
按对象汇总后，A 项目设计阶段当月工时合计 96 小时、金额 11,520 元；A 项目测试阶段当月工时合计 64 小时、金额 6,400 元；B 项目当月工时合计 120 小时、金额 12,000 元。汇总表可下钻到人员与日期，便于复核。
校验中发现两类问题：一是成员丙有 4 小时工时未选对象编码，完整性校验不通过，退回补录后归入 PRJ-2025-002；二是成员丁的费率区间在 3 月中旬到期未续，费率时效性校验提示缺失，先挂待分摊池，费率维护人补录新区间后重算并回填。两类异常在关账前处理完毕，汇总结果确认可用。
上线前的完成检查
在正式用这套机制出数之前，逐项核对以下检查项。每项都要有通过标准和可留存的证据，避免“看起来配好了”但实际跑不通。
| 检查项 | 通过标准 | 证据 | 责任人 |
|---|---|---|---|
| 对象清单覆盖度 | 当前在研项目与产品均有对应对象，无重复编码 | 对象主数据表与项目清单比对记录 | 成本对象维护人 |
| 编码规则稳定性 | 编码不随名称变更，历史对象可追溯 | 编码规则说明与历史对象样例 | 成本对象维护人 |
| 费率覆盖 | 全部相关人员的费率区间覆盖当期工作日 | 费率表与人员清单比对结果 | 费率维护人 |
| 校验规则可用 | 四类校验均已配置，能输出异常清单 | 一次试运行的异常清单 | 归集校验人 |
| 责任人与时点 | 各角色确认职责与月度时点并已通知到人 | 职责确认记录或通知记录 | 归集负责人 |
建议先用一个完整月度做试运行，用真实工时跑通匹配、汇总和校验，再根据异常清单修正对象清单与费率表。试运行通过后，这套对象设定与归集机制即可投入正式使用；后续只需在项目立项、产品调整和人员变动时同步维护对象与费率，保持口径连续。
常见问题
项目中途改名或合并，历史工时数据怎么保持口径一致？
对象编码在启用后保持不变，名称可以调整，历史工时继续挂在原编码上，追溯不受影响。发生合并时，保留原对象编码并标记停用，已有工时记录不改写，新工时引用合并后的对象；跨期汇总时锁定历史数据，只对新工时应用新对象。这样处理的关键是把“编码稳定”和“名称可读”分开管理，避免因改名导致同一对象在报表里出现两个口径。
团队规模较小，能否只设一级成本对象？
可以。层级数量取决于归集用途和分析需要，团队人数少、项目数量有限时，只设项目或产品一级对象通常已够用。二级对象（如研发阶段、工作包）适合需要观察项目内部投入结构的情况；如果只是按项目汇总人力成本，增加二级对象反而会加重填报负担。后续分析需求变化时再补充二级对象，历史工时仍按原对象保留即可。
标准费率和实际费率应该用哪一个来归集？
两者用途不同，建议分别维护、分别出数。标准费率适合内部核算和跨团队比较，口径统一、便于横向对照；实际费率反映真实人力投入成本，适合对外结算或成本还原。归集时先明确本次结果交给谁、用于什么判断，再选定其中一个口径，避免同一张报表混用两种费率。无论选哪种，匹配规则都按工作日期取当期有效费率。
工时填报不完整、对象选错的情况，校验环节怎么处理？
按异常类型走不同路径：缺少对象编码或费率的，退回填报人限期补录；同一时段工时重复归入多个对象的，提示填报人确认后保留一条；费率区间缺失的，先挂待分摊池，由费率维护人补录后重算回填；涉及对象停用或合并的，由对象维护人确认历史口径不变。每条异常都应有状态和责任人，月度关账前清零或形成书面说明，避免异常长期悬置影响汇总结果。
试运行多久可以判断这套归集机制可以正式使用？
建议用一个完整月度做试运行，用真实工时跑通对象引用、费率匹配、金额汇总和四类校验，观察异常清单的数量和类型。试运行通过的标准是：对象清单覆盖当前在研项目且无重复编码，费率区间覆盖全部相关人员，四类校验能稳定输出异常清单，各角色职责与月度时点已确认到人。试运行中暴露的问题优先修正对象清单和费率表，再进入正式使用。
