项目型组织的绩效难题，不是结果指标不够多，而是结果无法解释贡献、过程无法进入评价。本文面向HRD、CHRO、项目管理负责人和HR数字化负责人，讨论项目绩效如何评价，并进一步分析eHR系统如何支撑过程数据采集、双维规则配置、绩效看板预警与人才管理闭环。

项目型组织正在成为越来越多行业的主流组织形态。建筑工程、IT服务、咨询交付、研发创新、共享服务等领域，都在用项目承接客户、资源、周期和价值责任。与职能型组织相比，项目型组织的复杂性在于：员工的工作成果常常不是单一岗位职责的线性产出，而是在跨部门、跨周期、跨角色协作中形成的阶段性贡献。

从公开研究与行业实践看，项目交付失败往往并非只发生在结项时，而是早已埋在需求变更、风险响应、资源协调、质量评审和客户沟通等过程节点中。PMI、德勤、麦肯锡等机构关于项目管理成熟度、组织绩效与数字化管理的相关研究，也反复提示一个方向：项目成功率与组织是否具备清晰的目标管理、过程跟踪、风险反馈和复盘机制高度相关。对于中国企业而言，2025—2026年建筑、咨询、IT服务、工程总包、研发型企业继续推进项目精细化管理，项目绩效评价也从后台人事动作，逐渐转向前台业务治理工具。

但现实中的绩效体系往往仍停留在年度评分逻辑中。一个典型场景是：某项目延期交付，项目团队在过程中多次发生范围蔓延、资源调配滞后和客户反馈延迟，但由于最终完成验收，相关人员年度绩效仍然达标；另一个相反场景是：团队在高不确定性研发项目中持续完成风险识别、知识沉淀和关键验证，但由于商业化结果尚未体现，评价结果反而偏低。两种情况都指向同一个问题：项目型组织绩效管理长期存在项目目标与个人绩效脱节、过程行为与结果评价脱节、职能线与项目线评价脱节。

本文要回答的问题是：项目绩效如何评价，才能既守住交付结果，又不忽视过程贡献？答案不是简单增加几张评分表，而是构建过程+结果双维评价体系，并通过eHR系统把指标、数据、流程、校准和人才应用串联起来。

一、项目型组织绩效管理的结构性困境：为什么只看结果行不通

项目型组织的组织特性决定了单维结果评价容易失真。结果当然重要，但如果绩效体系只在项目结束或年度末给出分数，管理者就很难知道结果是如何形成的，也难以及时纠偏。

1.双线汇报困境：项目贡献为什么容易被稀释

项目型组织常见的管理结构包括矩阵式、项目制、事业部制与强项目制混合形态。员工一方面归属于职能部门，接受职能主管管理；另一方面被派入项目团队，接受项目经理的任务分配和交付要求。这种结构的优势是资源可以灵活调配，专业能力可以跨项目复用，但绩效管理的矛盾也由此产生：责任发生在项目线，评价权却往往集中在职能线。

当项目经理对员工实际投入、协同质量、风险响应、客户沟通有直接观察，却缺乏正式评价权时，绩效信息就会在传递中损耗。职能主管可能更熟悉员工的岗位能力和长期发展，却未必掌握其在每个项目中的真实贡献。最终，项目评价容易变成项目经理的口头反馈，职能评价则继续依据年度目标和主观印象。

这种信息不对称会带来两个副作用。其一，贡献较高但不善于向职能线表达的员工容易被低估；其二，项目中承担复杂协调工作的成员，由于成果不一定体现在最终交付物上，也容易被评价体系忽视。更深层的问题在于，员工会根据评价权的归属调整行为。如果绩效主要由职能主管决定，员工自然会优先回应职能线任务，而项目经理对项目进度和质量的管理抓手会减弱。

双线汇报并不是项目型组织的缺陷，而是其资源配置方式的结果。问题在于，如果评价机制没有同步设计项目线与职能线的分工，组织就会出现责任和权力不匹配。项目经理负责交付却不能评价，职能主管负责打分却缺少过程数据，绩效结果就很难真实反映项目贡献。

2.评价时点错配：年度绩效为什么捕捉不到项目过程

传统绩效管理通常以年度、半年度或季度为周期，而项目周期并不一定服从这个节奏。外部交付项目可能跨年，咨询项目可能只有数月，研发探索项目可能经历多个不确定阶段，内部流程优化项目则可能在短周期内完成关键价值释放。评价周期与项目生命周期错配，是项目绩效失真的第二个来源。

在年度评价模式下，很多关键行为发生时没有被记录，等到年底再回忆，评价就会依赖印象而不是事实。例如，项目中某成员在早期识别出重大风险，推动项目调整了技术方案，避免了后续返工；但如果这类行为没有在里程碑节点进入评价记录，年终时它很可能被最终交付结果覆盖。相反，某些项目早期过程管理薄弱，后期通过大量加班和资源追加完成交付，最终分数却可能看起来不错。

评价时点错配还会削弱绩效反馈的管理价值。绩效不是只为了分配奖金，更重要的是让组织看到偏差、理解原因并改进行为。如果问题在项目进行中已经出现，但评价必须等到结项甚至年度末才发生，管理者失去了最有价值的干预窗口。项目型组织的绩效管理应当靠近里程碑，而不是只靠近财务结算或年度考核。

这并不意味着所有项目都要高频打分。过度频繁的过程评价可能增加管理负担，甚至让员工产生被监控感。更合理的做法是把评价嵌入关键节点：项目启动设定目标，里程碑阶段评价过程，项目结项评价结果，异常情况触发复核。评价时点应服务于管理决策，而不是机械追求记录密度。

3.结果导向的幸存者偏差：好结果不一定代表好过程

结果导向有其必要性。项目型组织必须对交付物、成本、利润、客户满意度、回款和战略价值负责。如果绩效体系不重视结果，项目管理就可能滑向只讲努力、不看价值的另一种失真。但问题在于，只看结果会制造幸存者偏差：成功交付的项目被认为过程正确，失败项目则被简单归因于团队能力不足。

在项目实践中，好结果可能来自不可复制的偶然条件。例如客户临时降低要求、外部环境利好、关键专家临时救火、后期资源大幅追加，都可能让项目结果看起来达标。但如果过程中的范围控制、风险预警、需求澄清、质量复核并未做好，这样的成功并不能成为组织能力。绩效体系如果只奖励最终达标，就可能鼓励团队隐瞒风险、延迟暴露问题，甚至通过短期透支换取表面成功。

反过来，结果不理想也不一定意味着过程没有价值。探索型研发项目、新市场试点项目、组织变革项目本身具有较高不确定性，结果可能受技术成熟度、市场窗口、客户环境等因素影响。如果评价体系只看最终商业结果，就会压低团队承担创新任务的意愿。久而久之，组织会更偏好低风险、可交付、易评分的项目，而不愿投入不确定但具有战略意义的探索任务。

项目型组织绩效管理的核心矛盾不是结果不重要，而是仅看结果不足以指导改进。过程评价的引入不是替代结果，而是形成双维校验：过程解释结果，结果验证过程。只有同时看到行为路径和交付价值，绩效评价才有可能从事后打分转向过程纠偏。

二、过程+结果双维评价体系如何设计

双维评价不是把过程指标和结果指标简单相加，而是基于项目全生命周期建立结构化指标、动态权重和校准机制。它要解决的不是多打一次分，而是让项目绩效如何评价这件事变得可解释、可追溯、可改进。

1.过程维度指标设计：让关键行为进入评价

过程维度关注项目推进过程中可观察、可记录、可反馈的关键行为与阶段成果。对于项目型组织而言，过程指标不应泛化为态度、努力、配合度等抽象评价，而应围绕项目里程碑、协同机制和风险控制进行设计。常见指标包括进度偏差率、质量评审通过率、风险预警响应时效、跨部门协同评价、需求变更响应时效、知识沉淀贡献度等。

过程指标需要区分硬指标与软指标。硬指标可以通过系统自动采集，例如里程碑是否按期完成、工时投入是否异常、变更记录是否及时、质量评审是否通过、风险日志是否闭环。软指标则更依赖行为评价，例如跨部门协同质量、客户沟通专业度、问题解决主动性、知识分享贡献等。软指标并非不能评价，关键是要通过行为描述、评价人权限和证据要求降低主观性。

过程评价的设计边界也很重要。不是所有过程动作都应该进入绩效，否则绩效体系会变成操作监控。更合理的原则是：只评价对项目结果具有解释力、对组织能力具有沉淀价值、对风险控制具有前置意义的过程行为。例如，会议出勤本身不一定值得评价，但会议后问题项是否闭环、关键决策是否记录、风险是否升级处理，则可能成为有效过程指标。

在数据来源上，过程指标应尽量减少人工补录。项目管理系统可以提供任务状态、里程碑完成情况和风险日志；ERP或财务系统可以提供成本、预算和资源消耗；CRM可以提供客户反馈与商机信息；工时或考勤系统可以提供投入结构。eHR系统需要把这些数据转化为绩效评价可用的数据口径，而不是要求员工在绩效周期末重新填写一遍项目经历。

2.结果维度指标设计：守住项目交付价值底线

结果维度关注项目最终交付物与商业价值。不同于过程指标强调行为路径，结果指标回答的是项目是否创造了预期价值。常见结果指标包括项目利润率、成本偏差、客户满意度、交付准时率、变更控制率、项目回款达成率、创新成果转化率、内部客户满意度、流程优化贡献等。

结果指标的关键不是越多越好，而是与项目类型匹配。交付型项目更重视成本、质量、客户满意度和交付准时率；探索型项目更重视阶段性验证、知识产权、技术路径沉淀和战略价值；内部支撑型项目则更关注服务SLA、流程效率、内部客户体验和成本节约。用同一套结果指标衡量所有项目，会导致指标看似统一，实际失焦。

例如，建筑工程或工程总包项目通常具备明确的预算、周期、客户验收和质量标准，结果评价可以更强调利润率、交付准时率、质量缺陷和客户满意度。研发项目在早期可能并不适合用利润率衡量，因为项目价值更多体现在技术可行性、原型验证和知识沉淀上。内部IT运维项目则不能简单按外部客户交付逻辑评价，而应关注服务响应、系统稳定性、业务满意度和流程改善。

结果指标还需要处理归因问题。一个项目结果可能受市场、客户、预算、资源配置、供应商、政策环境等多因素影响，不能将项目结果机械归因到个人。个人绩效中的结果维度，应当依据角色责任进行拆分：项目经理对整体交付结果承担更高权重，关键技术负责人对技术质量和风险控制承担责任，客户经理对客户沟通和回款协同承担责任，职能支持人员则对专业交付质量和响应效率承担责任。

3.双维融合的权重与校准机制：避免双重打分

双维评价的难点不在于列出指标，而在于如何融合。过程与结果如果只是分别评分再简单平均，就会退化为双重打分：过程好、结果差时不知道如何处理；结果好、过程差时也无法判断是否应高分。真正有效的双维评价，需要根据项目类型、阶段和战略重要性动态配置权重，并建立校准规则。

权重配置应服从项目属性。交付型项目通常结果权重更高，因为客户验收、成本控制和利润目标是基本要求；探索型项目过程权重可以更高，因为其价值往往体现在试错质量、知识沉淀和风险发现；内部支撑型项目则适合相对均衡，以兼顾服务过程和业务改善结果。权重不是为了平衡各方情绪，而是为了体现组织对不同项目价值逻辑的判断。

表格1：不同项目类型的双维评价指标与权重配置建议

权重之外，还要有校准机制。一个值得警惕的情况是过程高分、结果低分。如果是探索型项目，结果低分可能来自外部不确定性，过程高分仍然说明团队形成了有效经验；但如果是成熟交付项目，过程高分却结果失败，就需要复核过程指标是否遗漏关键风险。另一种情况是过程低分、结果高分。此时不能简单给高绩效，而应判断结果是否依赖偶然因素、资源透支或不可复制的个人救火。

校准会议的价值在于让项目经理、职能主管、HRBP和必要的业务负责人共同讨论异常组合。校准不是为了平均分数，而是为了识别原因：指标是否合理，数据是否完整，责任边界是否清晰，项目类型是否适配当前权重。对于异常项目，应设置异常标记与复核规则，避免绩效结果在系统中被机械固化。

图表1：项目全生命周期中的双维评价闭环

双维评价的本质是让过程可评价、让结果可解释。权重动态化与校准机制，是防止双维评价退化为多填表、多打分的关键。

三、eHR系统如何支撑双维评价落地

eHR系统是双维评价从制度文本走向管理现实的关键基础设施。它的价值不只是把线下表单搬到线上，而是让项目过程数据能够被自动采集、评价规则能够被灵活配置、绩效结果能够被追溯分析，并进一步联动薪酬、人才和发展。

1.项目过程数据的自动采集与归集

双维评价首先需要数据基础。没有稳定的数据来源，过程评价很容易变成主观描述；没有统一的数据口径，不同项目之间也难以比较。eHR系统要支撑项目绩效评价，第一步不是设计更复杂的评分规则，而是打通项目管理、ERP、CRM、工时考勤等业务系统，建立能够服务绩效评价的数据链路。

项目管理系统可以提供任务进度、里程碑状态、风险日志、问题闭环记录；ERP或财务系统可以提供预算、成本、采购、利润和回款信息；CRM可以提供客户反馈、客户满意度、需求变更和服务记录；工时或考勤系统可以提供人员投入、项目占用和资源负荷。eHR系统通过数据中台或接口管理，将这些数据归集到绩效评价场景中，形成项目、组织、个人之间的映射关系。

这里的难点不是技术接口本身，而是数据治理。比如，不同系统对项目编号、人员角色、成本中心、客户名称的定义不一致，会直接影响绩效数据的准确性。一个员工可能同时参与多个项目，如果没有明确投入比例和角色责任，绩效归因就会出现偏差。因此，eHR系统落地双维评价前，应先明确项目主数据、人员主数据、角色字典、指标口径和数据更新频率。

自动采集并不意味着完全取消人工判断。部分过程行为仍需要项目经理、职能主管或客户代表进行评价，例如协同质量、问题解决能力、知识沉淀贡献等。但系统应要求评价有证据、有节点、有责任人，而不是允许周期末凭印象打分。数据自动归集的意义，是把管理者从重复填报中释放出来，把注意力放在偏差解释和改进行动上。

2.双维评价规则的灵活配置与流程引擎支撑

项目型组织的绩效规则不能只有一套模板。不同项目类型、不同阶段、不同岗位角色的评价指标和权重应当可配置，否则系统会倒逼组织迁就工具。eHR系统的绩效模块需要支持指标库管理、权重模板配置、项目阶段配置、评价人权限配置和校准规则设置，让双维评价能够适配真实业务。

例如，交付型项目可以配置更高的结果权重，并将交付准时率、客户满意度、成本偏差纳入核心指标；探索型项目可以配置更高的过程权重，并将里程碑验证、风险响应、知识沉淀纳入评价；内部支撑型项目可以围绕服务SLA、需求响应、内部客户反馈设计指标。对于同一项目中的不同角色，也应设置不同评价重点。项目经理更关注整体结果和过程管理，专业成员更关注专业交付与协同贡献，支持岗位更关注响应效率和服务质量。

流程引擎是双维评价落地的另一项关键能力。理想的线上流程应覆盖目标设定、过程跟踪、里程碑评估、结果评价、双维校准、绩效面谈和改进计划。项目启动时，系统引导项目经理和职能主管共同确认双维目标；里程碑节点到达时，系统自动触发过程评价或提醒补充证据；项目结项后，系统汇总结果指标并生成初步评价；异常组合进入校准流程；最终结果进入面谈和应用环节。

在这个过程中，权限配置尤其重要。项目经理应拥有对项目过程贡献的评价权，职能主管应保留对专业能力与长期发展的评价权，HRBP负责流程监督、异常识别和校准组织，HR COE负责指标体系与规则维护。只有把责任、权限和流程固化在系统中，双线评价才不会停留在协商层面。

需要注意的是，系统配置越灵活，治理要求越高。如果每个项目都随意设置指标和权重，绩效体系会失去可比性；如果所有项目都使用固定模板，又会失去适配性。较可行的方式是建立项目类型模板库，在模板边界内允许有限调整，并通过HR COE定期复盘指标有效性。

3.绩效数据的可视化与穿透式分析

双维评价只有进入可视化和分析层，才能从评价动作升级为管理工具。项目型组织的管理者不仅需要知道某个人得了多少分，更需要知道某类项目为什么持续延期、某些团队为什么过程评价高但结果不稳定、哪些项目经理具备稳定交付能力、哪些人才在多个项目中形成了可复用贡献。

绩效数据看板应支持从组织到项目、再到个人的穿透式下钻。组织层面可以观察项目组合绩效、项目类型分布、整体过程偏差、结果达成情况和人才投入结构；项目层面可以查看里程碑达成、风险响应、成本偏差、客户反馈和团队贡献；个人层面则可以呈现参与项目、角色责任、过程评价、结果贡献和能力标签。这样的数据链路能够帮助管理层识别组织能力，而不是只处理个体绩效。

AI辅助分析可以进一步提升项目绩效管理的前置性。例如，当项目进度偏差超过组织设定阈值、风险日志长期未闭环、成本消耗异常、客户投诉频次上升时，系统可以自动推送预警至项目经理、HRBP或相关负责人。这里的重点不是追求算法复杂度，而是建立清晰的预警规则和责任闭环。预警如果无人处理，只会增加噪音；预警如果能触发复盘、资源协调或目标调整，才具有管理价值。

可视化还可以支持跨项目人员贡献对比。对于同时参与多个项目的员工，系统可以呈现其在不同项目中的角色、投入、过程评价和结果贡献，帮助组织识别真正具备跨项目协作能力的人才。但这类分析必须谨慎处理公平性问题。不同项目难度、资源条件、客户环境差异较大，不能用简单排名替代管理判断。看板应提供事实线索，最终评价仍需结合项目背景校准。

4.绩效结果与人才管理的闭环联动

双维评价的价值不应止步于薪酬激励。项目型组织真正需要的是把项目绩效转化为人才识别、团队配置、能力发展和组织复盘的依据。eHR系统在此处的作用，是把绩效数据与人才盘点、培训发展、项目团队组建、继任计划和绩效改进计划连接起来。

过程评价持续优秀的人，未必总是最终结果最高的人，但他们可能具备稳定的协同能力、风险识别能力、问题闭环能力和知识沉淀能力。这类人员适合进入项目核心人才池，成为关键项目的优先配置对象。结果评价持续优秀的人，则可以进一步分析其成功模式是否可复制：是依赖个人英雄式救火，还是依赖稳定的项目管理方法。如果是前者，组织需要补足团队机制；如果是后者，则可以沉淀为最佳实践。

对于结果评价持续偏低的人员，系统可以触发绩效改进计划。但PIP不应只看低分，而应结合过程数据判断原因。如果过程评价低、结果也低，可能需要能力辅导或岗位调整；如果过程评价高、结果低，则应分析项目难度、资源配置或目标设定是否合理；如果过程评价低但结果高，则要警惕不可持续的交付方式。双维数据让绩效改进从惩罚性动作转向诊断性动作。

图表2：eHR系统支撑双维评价的技术架构

没有系统支撑的双维评价，往往只能停留在制度文本层面。eHR系统的价值不在于替代管理判断，而在于让判断建立在更充分的数据、规则和流程之上，减少信息损耗与主观偏差。

四、从设计到落地的实施路径与关键挑战

双维评价的落地不是一次性切换，而是分阶段演进。企业需要同时处理组织准备度、数据基础和变革管理三类问题，否则即使系统上线，也可能形成新的填报负担。

1.三阶段实施路径：从试点到深化

第一阶段是试点期。企业不宜一开始就覆盖所有项目，而应选择一至两个典型项目类型进行试点，例如一个外部交付项目和一个内部支撑项目。试点的目标不是追求体系完整，而是验证指标是否贴近业务、权重是否合理、数据是否能够采集、评价人是否具备判断能力。在这一阶段，HRBP应深入项目一线，与项目经理、业务负责人和职能主管共同定义指标，避免由HR单独设计一套看似规范但脱离业务的模板。

第二阶段是推广期。企业可以基于试点结果优化指标库和权重模板，形成交付型、探索型、内部支撑型等项目类型的基础配置，并逐步扩展到更多项目。此时系统配置和流程治理变得更加重要，包括指标版本管理、项目类型标签、数据接口、权限规则、校准流程和面谈记录。推广期最容易出现的问题是标准化与灵活性的冲突，HR COE需要建立统一边界，允许项目在规则内调整，而不是完全自由配置。

第三阶段是深化期。随着数据积累，企业可以引入AI辅助分析、项目绩效趋势预测、人员能力画像和过程预警机制，推动绩效管理从事后评价转向过程干预。深化期的重点不再是能不能打分，而是能否通过数据发现项目管理模式、人才配置效率和组织能力短板。对于项目制企业而言，这一阶段也是HR数字化从流程线上化走向绩效运营化的关键节点。

2.关键挑战与应对：组织、数据与变革管理

双维评价首先面临组织准备度挑战。项目经理过去可能只负责交付，不习惯承担绩效评价责任；职能主管可能担心评价权被削弱；员工则可能质疑项目评价是否公平。应对方式不是简单发文授权，而是明确项目经理与职能主管的评价分工，并对项目经理开展绩效反馈、证据记录、行为评价和面谈辅导训练。评价权必须配套评价能力，否则权力下放会变成新的主观评分。

第二个挑战是数据基础。很多企业的项目、财务、客户、人力数据分散在不同系统中，字段口径不一致，历史数据缺失，人工维护较多。如果在这种基础上直接上线双维评价，系统只能把混乱的数据搬到绩效流程里。较稳妥的做法是先做最小可用数据治理：统一项目编码、人员角色、项目类型、成本中心、里程碑状态和评价周期，优先打通对绩效解释力最强的数据，而不是追求一次性接入所有系统。

第三个挑战是变革管理。过程评价容易让员工产生被监控感，尤其当企业把过程指标设计成过细的行为检查时，抵触情绪会明显上升。企业需要向员工说明过程评价的目的：不是记录每一次操作，而是识别关键贡献、及时发现偏差、提高项目支持和资源协调效率。规则透明、评价证据可查、反馈及时、结果应用正向，是降低抵触的重要条件。

表格2：双维评价落地的三阶段实施路径与关键挑战

3.HR在双维评价落地中的角色升级

在项目型组织中，HR不能只做绩效流程的组织者。双维评价要求HR同时理解业务项目逻辑、绩效指标逻辑、数据治理逻辑和组织变革逻辑。换句话说，HR的角色需要从流程执行者，升级为项目绩效体系设计者、数据分析师和变革推动者。

HRBP的关键任务是贴近项目一线。只有理解项目目标、客户要求、资源约束、风险结构和交付节奏，HRBP才能判断哪些过程行为值得评价、哪些结果指标具有可比性、哪些异常组合需要校准。对于复杂项目，HRBP还应参与绩效面谈和复盘，帮助项目经理把数据反馈转化为具体改进行动。

HR COE则需要承担体系建设责任，包括指标库设计、项目分类规则、权重模板、校准机制、评价人培训、系统配置要求和数据分析框架。COE不能只发布制度，还要基于试点数据持续迭代规则。例如，某类项目长期出现过程高分但结果低分，可能说明过程指标没有覆盖真正影响结果的关键因素；某类岗位长期被低估，可能说明评价角色和权重设置不合理。

HR数字化团队或HRIS团队则需要把业务规则翻译成系统能力，包括接口、字段、流程、权限、看板和预警机制。三类HR角色协同，才能让双维评价既有业务解释力，又有系统执行力。技术系统是必要条件，组织能力与变革意愿是充分条件，HR的角色升级正是连接两者的关键纽带。

红海云总结

回到开篇的三重脱节，项目型组织绩效管理要解决的不是多一个考核维度，而是让项目目标、过程行为、结果价值和人才发展进入同一个闭环。过程维度解决目标漂移与行为失察，结果维度守住交付价值底线，eHR系统则确保评价可执行、数据可追溯、偏差可干预。

对准备推进项目绩效双维评价的企业，红海云建议优先审视以下几项行动：

• 先定义项目类型，再设计评价指标。 不同项目的价值逻辑不同，交付型、探索型、内部支撑型项目不应使用同一套权重和结果口径。
• 先治理关键数据，再上线复杂流程。 项目编码、人员角色、里程碑、成本与客户反馈等基础数据，是eHR系统支撑项目绩效的前提。
• 把项目经理纳入正式评价机制。 项目经理承担交付责任，也应拥有与责任匹配的过程评价权，但必须配套评价能力训练。
• 用校准机制处理异常组合。 过程高分但结果低分、过程低分但结果高分，都不应被简单平均，而应进入复核与原因分析。
• 让绩效结果连接人才管理。 红海云认为，双维评价的更高价值在于识别项目核心人才、优化团队组建、触发培训发展和绩效改进，而不只是服务奖金分配。

对于HRD和CHRO而言，2026年前后推进HR数字化升级时，项目绩效如何评价应成为优先议题。你的组织当前过程数据占比多少，项目经理的话语权是否匹配其责任，eHR系统是否能实时呈现项目绩效全景，这三个问题基本决定了双维评价的落地起点。