需求管理工具替换的粗略测算，目标是给预算审批提供一个可复算的区间，而非精确报价。做法是先划定替换范围与观察周期，再把投入拆成软件订阅、实施配置、数据迁移、集成改造、培训切换、并行冗余和内部人力七类，统一币种、席位与工时口径后套用“数量×单价×周期”，最后用低、中、高三档情景加不可预见费形成预算边界。
要点总览（TL;DR）
- 需求管理工具替换的投入可拆成七类：软件订阅、实施配置、数据迁移、集成改造、培训切换、并行期冗余和内部人力，逐项给出计量单位才能避免漏算。
- 粗略测算的通用公式是“数量×单价×周期”，一次性投入与年度运行成本分开汇总，再合并出首年总投入和三年累计投入。
- 预算边界用低、中、高三档情景加不可预见费形成区间，不可预见费建议按一次性投入与首年运行成本之和的10%–20%预留。
- 用户规模与席位口径、历史数据量、集成数量、并行期长短和流程重构幅度是影响总投入最大的敏感因素，应优先核实。
- 厂商单价与折扣必须书面询价确认，内部人天成本和迁移数据量可从工时系统与旧系统导出盘点，示例假设要与真实报价分开标注。
替换范围与测算时间跨度怎么定
测算开始前先回答一个问题：这次替换究竟换掉哪些环节。需求管理覆盖采集、评审、优先级排序、变更控制、追溯等环节，不同环节的替换难度和投入差别很大。只替换需求条目录入与流转，与同时替换评审流程、变更审批和追溯关系，实施工时可能相差数倍。范围写得越具体，后续成本项才越容易对应到人、系统和数据。
用户规模要按角色拆分，而不是只报一个总数。产品经理、研发、测试、项目管理、只读查看者在使用深度和席位计价上往往不同，只读账号是否计费会直接影响订阅费。建议在范围表里分别列出各角色的实际活跃人数，并注明统计口径是账号数还是月活跃人数。
时间跨度建议按“首年总投入＋后续年度运行成本”两段呈现。首年通常包含一次性投入和部分年度费用，后续年度主要是订阅续费、少量维护和内部人力。测算周期取三年比较常见，既能体现多年折扣，也能暴露并行期和迁移的后续影响。
范围表还应写明排除项。例如本次测算只覆盖需求管理工具本身，Jira、Confluence 专属替换场景、与之绑定的知识库迁移不在本文展开；没有旧工具前提的全新选型也不属于替换测算。把这些边界提前写清，可以避免评审时被追问范围外的费用。
| 范围项 | 需填内容 | 示例填写方式 |
|---|---|---|
| 功能范围 | 替换的需求管理环节 | 采集、评审、优先级、变更、追溯 |
| 用户与角色 | 各角色活跃人数、只读账号数 | 产品 8 人、研发 40 人、测试 12 人、只读 20 人 |
| 一次性投入期 | 从签约到切换完成的月份 | 第 1–4 月 |
| 年度运行期 | 续费与维护的年度区间 | 首年后每年 |
| 测算周期 | 首年＋后续年度 | 首年总投入＋第 2–3 年运行成本 |
| 排除项 | 不在本次测算内的场景 | Jira、Confluence 专属替换；全新选型 |
需求管理工具替换的成本和资源项清单
把投入拆成七类，每一类都给出计量单位，才能逐项估算并交叉核对。清单的作用是防止漏项，尤其是内部人力和并行期冗余这两类最容易被忽略的成本。
- 软件订阅或授权费：按席位/年或按账号计费，属于年度重复成本，多年合同可能带折扣。
- 实施与流程配置服务费：按人天或项目包计价，用于工作流、字段、权限、报表的配置，通常是一次性投入。
- 历史需求数据与附件迁移：按需求条数、附件体量（GB）和字段映射复杂度计量，多为一次性。
- 集成改造：与代码仓库、测试管理、发布系统的对接，按接口数量和人天计价，一次性为主，后续可能有维护。
- 培训、文档与切换支持：按场次、人数或人天计量，一次性投入，切换后可能还有少量答疑。
- 新旧系统并行期冗余：并行月份内两套系统的订阅费与人力重复投入，按并行月数计量。
- 内部人力投入：产品、研发、测试、IT 参与配置、迁移、测试、培训的工时，按人天折算，属于隐性但真实的成本。
| 成本类别 | 计量单位 | 计价方式 | 是否一次性 |
|---|---|---|---|
| 软件订阅/授权 | 席位·年 | 单价×席位数×年数 | 否，按年重复 |
| 实施与流程配置 | 人天 | 人天单价×人天数 | 是 |
| 数据与附件迁移 | 条数、GB、人天 | 按量或按人天包干 | 是 |
| 集成改造 | 接口数、人天 | 人天单价×人天数 | 是，维护另计 |
| 培训与切换支持 | 场次、人天 | 按场或按人天 | 是 |
| 并行期冗余 | 并行月数 | 旧系统月费×月数＋重复人力 | 是（阶段性） |
| 内部人力 | 人天 | 内部人天成本×人天数 | 是（按项目发生） |
测算口径与关键假设怎么写
口径不统一，算出来的数字无法比较也无法复算。建议在测算表前单独放一页假设说明，逐条写明假设值、来源和是否待核实。
币种与税费要一次定清：统一用人民币还是外币折算，报价是否含税，含税与不含税不能混在一张表里相加。席位口径要说明按活跃用户、全部账号还是只读账号单独计价，这直接决定订阅费的基数。按年计费与多年折扣的处理方式也要写明，例如三年合同按年均摊还是按实际付款年度列示。
内部人力单价建议用内部人天成本折算，来源可以是工时系统或历史项目记录中同类工作的实际投入。示例假设必须与真实报价分开标注：凡是厂商尚未报价的数字，都标为“示例假设，待询价确认”，避免评审时被当成承诺价。
数据迁移量的估算依据要落到可盘点的对象：旧系统中的需求条数、附件总容量、需要保留的字段和评论数量。这些数字可以从旧系统导出统计，比凭感觉估更可靠。
| 口径项 | 假设值（示例） | 来源 | 状态 |
|---|---|---|---|
| 币种与税费 | 人民币，含税 | 财务口径 | 已确认 |
| 席位口径 | 按活跃账号计费，只读账号单独询价 | 厂商条款 | 待核实 |
| 计费周期 | 按年付费，三年合同 | 商务意向 | 待核实 |
| 内部人天成本 | 按岗位平均人天成本折算 | 工时系统 | 已确认 |
| 迁移数据量 | 需求条数与附件容量 | 旧系统导出 | 待盘点 |
| 厂商单价 | 示例假设值 | 无 | 待询价确认 |
粗略测算的计算模型与预算框架
通用公式是：单项成本＝数量×单价×周期。一次性项目周期取 1，年度项目乘以年数。把所有一次性项加总得到一次性投入合计，把订阅、维护等按年项加总得到年度运行成本，两者分开列示，再合并出首年总投入和三年累计投入。
三档情景的差异体现在参数上，而不是拍一个总数。低档取较少的席位数、较短的并行期、较浅的集成改造；中档取盘点后的实际用户数和常规实施范围；高档在用户规模、集成数量和流程重构幅度上都取偏保守的上限。每一档都用同一套公式计算，评审时可以逐项追问参数来源。
不可预见费建议按一次性投入与首年运行成本之和的 10%–20% 预留，流程重构幅度大、历史数据脏、集成系统多的项目取上限。预算上限的设定有两种做法：按高档情景加不可预见费作为申请上限，或按审批额度倒推可承受的席位与实施范围，再反算各档参数。
| 汇总项 | 低档 | 中档 | 高档 |
|---|---|---|---|
| 计费席位数 | 核心角色 | 盘点后活跃用户 | 全部账号 |
| 实施人天 | 基础配置 | 常规流程配置 | 含流程重构 |
| 集成接口数 | 1–2 个 | 3–4 个 | 5 个以上 |
| 并行期 | 1 个月 | 2 个月 | 3 个月及以上 |
| 一次性投入合计 | 公式计算 | 公式计算 | 公式计算 |
| 年度运行成本 | 公式计算 | 公式计算 | 公式计算 |
| 不可预见费 | 10% | 15% | 20% |
| 首年总投入 | 一次性＋首年运行＋预备费 | 同左 | 同左 |
测算表落地后，需求条目、实施工时和预算执行往往分散在不同表格里。ONES 可以把需求条目、任务工时与项目进度放在同一套工作项中记录，便于在切换过程中对照预算科目跟踪实际发生的人天和费用，评审时直接调取记录而不是重新汇总。
哪些因素会让测算结果明显偏移
粗略测算的误差主要来自少数几个敏感因素。把它们排序，可以决定询价和盘点时先核实什么。
- 用户规模与席位口径：影响方向为正向，席位数翻倍订阅费近似翻倍，只读账号是否计费是首要核实项。
- 历史数据量与迁移复杂度：影响方向为正向，需求条数多、附件大、字段映射乱会显著拉高迁移人天。
- 集成系统数量与改造深度：影响方向为正向，每增加一个需要双向同步的接口，改造和联调工时都会增加。
- 并行期长短：影响方向为正向，并行每月都在重复支付两套系统的费用和人力。
- 流程重构幅度：影响方向为正向，借替换机会重做评审与变更流程，实施人天会明显上升。
- 价格与折扣谈判空间：影响方向为负向，多年合同和批量席位通常有折扣，是压缩预算上限的主要杠杆。
| 敏感因素 | 影响方向 | 优先核实项 |
|---|---|---|
| 用户规模与席位口径 | 正向 | 只读账号计费规则、活跃用户统计 |
| 数据量与迁移复杂度 | 正向 | 需求条数、附件容量、字段映射 |
| 集成数量与深度 | 正向 | 接口清单、同步方向、联调人天 |
| 并行期长短 | 正向 | 旧系统退订时间点 |
| 流程重构幅度 | 正向 | 是否调整评审与变更流程 |
| 价格与折扣 | 负向 | 多年合同折扣、批量席位报价 |
测算数据从哪里取、怎么核实
数据来源分两类：必须询价确认的，和可以用区间估算的。厂商单价、折扣、席位计费规则、迁移服务报价属于必须询价项，没有书面报价前只能标为示例假设。内部人天成本、历史项目工时、需求条数和附件容量属于内部可取数项，可以从工时系统、旧系统导出和项目档案中盘点。
集成改造工作量建议由负责对接的研发或 IT 按接口逐个评估人天，并注明同步方向和联调次数。假设值的复核节奏可以跟随测算阶段推进：范围确认后复核席位与迁移量，询价返回后替换示例单价，评审前统一更新一次三档情景。
| 数据项 | 取数来源 | 核实方式 | 责任角色 |
|---|---|---|---|
| 软件单价与折扣 | 厂商报价单、合同条款 | 书面询价确认 | 采购/IT |
| 内部人天成本 | 工时系统、财务口径 | 与财务核对 | 项目管理 |
| 需求条数与附件量 | 旧系统导出统计 | 抽样核对字段完整性 | 产品/IT |
| 集成改造人天 | 接口清单评估 | 研发负责人复核 | 研发/IT |
| 并行期长度 | 切换计划 | 与项目组确认退订节点 | 项目管理 |
| 培训场次与人数 | 角色分布表 | 按部门确认 | HR/项目管理 |
完成取数与核实后，把三档情景和不可预见费一起提交评审，预算边界就落在“高档情景加预备费”与“低档情景”之间，后续询价结果只需替换对应参数，测算表即可复算更新。
常见问题
粗略测算需要精确到每个席位和每条需求吗？
不需要。粗略测算的目标是给出可复算的区间，而不是逐项精确报价。席位数按角色活跃人数估算即可，迁移量按旧系统导出的需求条数和附件容量取整盘点。关键是每个数字都写明来源和假设，评审时能替换参数重新计算。精确到单条需求或单个账号的测算，留到询价和合同阶段再做。
并行期一般留多长比较合理，对预算影响有多大？
并行期长短取决于数据迁移验证和用户切换的复杂度，常见做法是留1–3个月。并行期内两套系统的订阅费同时发生，内部人力也要重复投入，因此每延长一个月都会直接推高首年总投入。建议在切换计划中明确旧系统退订节点，把并行期作为独立成本项列入测算表，而不是隐含在其他费用里。
内部人力投入要不要折算成钱放进预算？
建议折算。内部人力虽然不产生对外付款，但配置、迁移、测试和培训占用的工时是真实资源消耗，不折算会低估替换的总投入。折算方式可以用工时系统中的岗位人天成本乘以预估人天。如果预算审批只关注现金支出，可以把内部人力单独列示为“资源投入”附在测算表后，供评审参考。
厂商报价还没拿到，测算表怎么先做出来？
先用示例假设值把测算表框架搭起来，所有未询价的单价标注“示例假设，待询价确认”。框架搭好后，席位数、迁移量、集成接口数等内部可盘点的参数先填实际值，等厂商报价返回再替换单价参数，三档情景即可复算更新。这样评审时看到的是结构完整的区间，而不是一个等待报价的空表。
预算上限应该按高档情景申请还是按中档申请？
常见做法是按高档情景加不可预见费作为申请上限，给评审留出谈判和范围调整的空间；如果审批额度本身有限，则按额度倒推可承受的席位与实施范围，再反算各档参数。两种做法都要在测算表中写明依据，避免上限与实际需求脱节。预算边界最终落在高档情景加预备费与低档情景之间，后续询价结果只替换参数即可。
