EPM选型第一步：先做诊断，再决定买哪个

图：（贝则科技）

直接回答：EPM 选型真正要定的不是产品，是范围。诊断的作用就是把范围定下来：哪些问题系统能解、哪些流程改一改就行、哪些压根不该在这一期做。没有诊断直接比产品，比的往往是功能条目多少，而不是谁更贴合你的约束。诊断通常两到四周，产出八到十二页结论，包含现状、约束、范围建议和风险项。有了这份东西再去谈供应商，报价才具备可比性。下面把诊断怎么做、谁来做、产出什么讲清楚。

一、诊断和需求调研不是一回事

很多项目把诊断做成了需求调研：挨个部门访谈，把每家的诉求记下来，汇总成一份长清单。这种做法收集的是愿望，不是约束。愿望没有上限，清单只会越写越长，最后还是得靠拍板砍。

诊断的落点在结论。它要回答三个问题：现状的瓶颈具体在哪个环节、这个瓶颈能不能用系统解决、解决它的最小范围是什么。三个问题都有明确答案，诊断才算完成。只交访谈纪要、不交范围建议的，属于调研，不是诊断。

两者还有一个差别在对象。调研的对象是人，诊断的对象是流程和数据。人的诉求会随岗位和考核变化，流程和数据的约束相对稳定，后者更适合作为选型依据。

2026 年不少集团的立项流程已经把诊断列为独立阶段，与采购分离。这样做的好处是诊断方不必考虑后续中标，结论更敢写。

二、诊断按六步走，顺序不宜跳

六步的顺序有依赖关系，跳步会导致后一步的判断失去依据。

1. 看战略：目标决定颗粒度。集团未来三年的扩张方式、管控强度、考核口径，决定了模型要细分到什么程度。战略不清楚时，颗粒度只能取中间值，后期再补。
2. 看组织：谁填、谁审、谁用要一次理清。填报主体数量、审批层级、使用者的岗位分布，直接决定工作流设计和培训量。
3. 看口径：法定口径、管理口径、考核口径要分开写。三套混用是多数项目返工的起点，诊断阶段必须把它们各自的用途和差异写成文字。
4. 看数据：脏在哪里、能不能修、要多久。科目映射、往来单位主数据、历史余额的完整性，这三项决定迁移工时。
5. 定范围：首期只做能赢的部分。把问题按「必须解决、可以缓一步、暂不处理」分成三档，首期范围控制在能在一到两个报告周期内跑通的量级。
6. 写结论：八到十二页讲清取舍。结论要能被非财务背景的管理者读懂，也要能被技术人员当作蓝图输入。

这六步里，最容易跳过的是第三步和第四步。前者因为口径讨论容易变成部门争论而被搁置，后者因为数据摸底费时费力而被简化。两处跳过的代价，都会在蓝图阶段以返工形式出现。

三、把问题分成三类，范围自然收敛

诊断的核心动作是分类。同一个现象，可能来自系统能力不足，也可能来自流程设计缺陷，还可能只是执行不到位。三类问题的解法完全不同，混在一起谈，结论必然是「都要上系统」。

问题类型	典型表现	合理解法
系统能解	多主体数据汇总靠手工、口径无法版本管理	纳入首期范围，作为核心需求
流程能解	报表反复返工源于节点不清、审批顺序错	先改流程，系统按新流程配置
人能解	填报质量差源于责任未落地、无校验反馈	先立规则与考核，再谈工具
暂不处理	发生率低、影响面小、无管理诉求	列入观察清单，不进首期

分类的判断标准可以简化成一句问话：把系统拿掉，这个问题还存不存在。如果依然存在，说明根因不在系统。这个问法听起来简单，实际讨论时能挡掉相当一部分伪需求。

四、诊断要交出五样东西

交付物的形态决定了诊断能不能被后续环节使用。内容再对，形态不对也用不起来。

交付物	内容要点	给谁用
现状描述	主体数量、层级、报告周期、人力投入	立项材料、管理层汇报
约束清单	硬性约束与可谈约束分开列	招标文件、供应商答疑
范围建议	首期做什么、缓做什么、不做什么	采购预算、合同范围
风险项	数据、规则、组织三类风险及应对	项目管理、验收标准
初步排期	阶段划分与关键里程碑	供应商工期核对

这五样里，约束清单的用处常被低估。它既是招标文件的附件，也是后续变更谈判的依据。约束写清楚了，供应商在报价时就必须按同一套前提算量，横向比较才有意义。

五、谁来做诊断更合适

三种角色都能做，各有适配场景。

内部团队做，优势是最了解实际情况，成本最低；难点是难以跳出既有立场，部门之间的口径分歧往往在内部无法定论。适合范围清晰、分歧不大的项目。

独立顾问或独立实施商做，优势是没有产品利益，敢写「这块不用上系统」；难点是需要更长的访谈时间建立对业务的理解。适合正在多个产品间比较、需要中立判断的项目。

原厂做，优势是对自家产品边界最清楚；难点是结论天然倾向于把问题定义成产品能覆盖的形态。适合已定产品、只需确认配置路径的项目。

实践中较稳的做法是内部团队主导、外部角色补位。贝则科技在项目前期常以这种方式参与，输出约束清单和范围建议，具体立项仍由客户内部拍板。这类合作方式对双方的要求都更高：客户要有人能接得住结论，外部团队要能接受自己的建议被删改。

六、周期与投入的合理预期

诊断周期通常两到四周，取决于三个变量：主体数量、口径分歧程度、数据可获取性。主体在五十家以内、口径基本统一的项目，两周可以出结论；主体过百、涉及多套准则并行、历史数据分散在多个系统的，四周以上更现实。

投入上，主要成本是访谈和数据核对的人工，不涉及软件许可。把它看成一次决策前的尽调，投入产出比通常好于在实施阶段做范围变更。

需要防的一个倾向是把诊断做成了实施。诊断只出结论和范围，不出配置和模型。一旦开始画表样、写取数逻辑，边界就模糊了，周期会失控。

七、结论怎么写才不容易被推翻

诊断结论常被推翻，原因多是没写清前提。同一句「建议首期覆盖全级次合并」，在主体稳定和主体每年变动二十家的两种前提下，结论正好相反。

写法上，每个结论都带上前提和反例。前提交代适用条件，反例交代在什么情况下这个结论不成立。这样即使后续情况变化，也能顺着前提判断是否要调整，而不是整份推翻重来。

另一个技巧是把结论写成可验证的表述。「合并周期缩短」不可验证，「月度合并报表在次月第五个工作日前出具，连续三个月无需手工调整」可验证。诊断阶段就写成可验证形态，验收标准可以几乎原样沿用。

八、从诊断到采购：边界要划清

诊断结束后有两条路：继续由诊断方参与实施，或另行招标。两条路都可行，但要提前说清，避免出现既是裁判又是运动员的安排。

如果诊断方后续参与实施，建议在诊断阶段就约定结论的独立性条款，明确范围建议不受商务因素影响。如果另行招标，则诊断方应回避评标或仅提供技术答疑。

边界划清之后，诊断的价值才能真正释放：它让采购从比功能变成比适配，让实施从摸索变成按图施工。这个顺序在 2026 年的集团项目里越来越常见，原因不复杂——先想清楚再花钱，比先花钱再想清楚便宜。贝则在这类项目中的角色通常止于诊断与落地实施两段，中间的选型决策始终交回客户。

常见问题

Q：诊断能不能由供应商免费做？

A：可以做，但要看清免费诊断的边界。免费诊断通常以产品演示和方案建议为主，结论倾向于把问题定义成产品能覆盖的形态，且深度受商务进度约束。如果预算允许，建议用一份小额付费诊断换取可独立使用的结论，尤其在多个产品间比较时更有价值。

Q：诊断周期能不能压到一周？

A：主体少、口径统一、数据集中在一个系统里的项目，一周可以出初步判断，但通常只能覆盖范围和风险，来不及做数据摸底。压缩周期的代价是把数据风险留到实施阶段暴露。如果一定要压，建议至少保留数据核对环节，其余环节并行推进。

Q：已经有咨询公司做过流程梳理，还要做诊断吗？

A：要看那份梳理是否包含系统落地的约束。流程梳理回答的是应该怎么管，诊断回答的是哪些能落进系统、落到什么颗粒度。两者不重复但也不互相替代。若原报告已有主体清单、口径定义和数据现状，可以在其上补充约束清单，不必重做。

Q：诊断结论和内部既定方案不一致怎么办？

A：先区分分歧的性质。如果分歧在事实层面，比如主体数量、数据完整性，用数据核对解决；如果在判断层面，比如首期范围大小，则把两种方案的前提和代价并列写出来，交管理层决策。诊断的作用是让取舍可见，不是替管理层做决定。

Q：多套准则并行的集团，诊断要额外看什么？

A：额外看三处：准则差异是否已形成书面的转换规则、差异调整是在合并层做还是在单体层做、历史期间是否需要追溯。这三处决定模型复杂度，也决定后续维护成本。差异规则没有书面化的，建议把规则梳理列为诊断的独立子项。

先诊断后选型，多花的是两三周，省下的是几个月的返工。这笔账在项目开始时算一遍，比在验收时算一遍轻松得多。