做系统集成的老手大概都经历过这种场面项目例会上负责人问“现在花了多少钱、活干到哪了”项目经理翻出采购单说花了五十多万翻出施工日志说大概干了一半紧接着追问“那到底是快了还是慢了、钱是省了还是超了”会议室瞬间安静。这种时候挣值管理Earned Value ManagementEVM就是那套能把“感觉”翻译成“数字”的工具。它真正要用的核心量只有七个PV、EV、AC、SV、CV、SPI、CPI三个基础量加四个衍生指标构成一套极简但极稳的度量体系。这套东西是系统集成项目管理工程师考试里的高频计算大题也是实际带集成项目时做周报、月报、向甲方汇报进度的硬通货。不管你是正在备考、被公式绕晕的考生还是手上同时压着三五个在建项目、需要一张表讲清楚状况的从业者把这七个量吃透收益都很直接。1. 挣值管理要回答的三个问题1.1 为什么“花了多少钱”和“干了多少活”必须分开看项目管理里最原始的度量方式是单维度的看预算还剩多少或者看时间过了多少。单维度度量有个致命缺陷——它无法区分“省钱”和“省事”。一个项目预算80万时间过半花了35万听起来控制得不错但如果实际只完成了30%的工作量那这35万就是超支而不是节约。反过来预算80万时间过半花了45万看着吓人但实际完成了65%那多花的钱买到了超额进度属于良性投入。挣值管理的本质是把成本维度和进度维度强行拆开用同一把尺子——货币——去度量两件完全不同的事。PV衡量“按计划此刻应该值多少钱”EV衡量“实际干出来的活值多少钱”AC衡量“为这些活实际付了多少钱”。三者都是金额单位放在同一个坐标系里谁高谁低一目了然。这个设计的巧妙之处在于它绕开了“进度百分比”这种无法横向比较的模糊表述。你说“完成了60%”甲方会问按什么算的你说“挣了48万”对方立刻能跟你预算表上的数字对上。我在实际带项目时最深的体会是能用钱说清楚的事尽量不要用百分比说。百分比是主观的金额是客观的而挣值管理强迫你在项目开始时就为每个工作包赋予金额权重这个动作本身就是一次极好的范围澄清。很多项目后期扯皮根源就在于前期没做这件事导致“做完了”和“做到位了”之间没有统一的判定标准。1.2 七个参数其实是一张三维坐标系把七个量画在一张图上你会看到它们并不是七个孤立的名词。PV、EV、AC是三个基础坐标分别对应“计划—实际产出—实际投入”三个维度SV和CV是两个差值衡量产出与计划、产出与投入之间的偏离SPI和CPI是两个比值衡量偏离的相对程度。这就像一个三维空间里的三个点衍生出来的四个指标描述的是点与点之间的相对位置关系。理解这个结构非常关键因为考试里大量题目不是直接问“SV是什么”而是给你一堆条件让你推导或者在题干里只给部分数据让你先补全三个基础量。实际工作里也一样很多项目经理拿到的数据是残缺的财务只给你支出总额工程部只给你完成情况计划部只给你基线。你必须知道这七个量之间的代数关系才能把缺口补上。提示PV、EV、AC三者的顺序不要记反。PV是基于计划的EV是基于实际完成的AC是基于实际花费的。一个记忆法是P代表PlanE代表Earned挣到的A代表Actual。挣值这个名字本身就点明了EV的性质——它是“挣到手的工作价值”。1.3 哪些人必须吃透这套东西第一类是备考系统集成项目管理工程师的人。这门考试的计算题里挣值分析的出镜率极高通常会给出一个项目背景表让你算SV、CV、SPI、CPI再判断项目状态最后算EAC和ETC。分值不低而且步骤之间有依赖关系前面算错一个数后面全崩。第二类是实际负责集成项目的项目经理。系统集成项目的特点是硬件、软件、实施、服务混在一起成本结构复杂甲方又特别在意进度。挣值管理能让你在月度汇报时拿出“截至本月末项目进度偏差为负X万成本偏差为正Y万综合判断建议采取以下措施”这样的结论而不是“目前进展顺利”这种空话。第三类是项目办的管控人员。多项目并行时你需要一个跨项目可比的指标。CPI和SPI天然具备这个能力一个CPI 0.85的项目和一个CPI 1.05的项目放在一起资源该往哪倾斜数据自己会说话。2. 三个基础量PV、EV、AC 的准确含义与常见误区2.1 PV基线里的那个“应该值多少”PVPlanned Value计划值有些老教材里叫BCWSBudgeted Cost of Work Scheduled计划工作的预算成本。定义是截至某个检查点按计划应该完成的工作按照批准的项目预算折算出来的金额。注意这里有两个限定词很关键“按计划应该完成”和“批准的项目预算”。前者决定了PV是随时间推移线性或阶梯式增长的后者决定了PV永远以基线为锚不因执行过程中的变更而随意调整除非变更走了正式审批流程并更新了基线。算PV最常见的方法是先做WBS分解把总预算BAC分摊到每个工作包再根据每个工作包的进度计划算出每个检查点上的累计计划价值。比如一个工作包预算12万计划4个月完成按均速推进那么第2个月末它的PV就是6万。如果这个工作包是按里程碑付款的那就按里程碑节点分摊第一个里程碑占40%就对应4.8万。这里有个坑要提醒PV不等于“计划支出”。很多新手会拿资金使用计划表直接当PV用这是错的。资金使用计划反映的是现金流可能因为付款条件比如验收后一次性付款、预付30%而与工作进度严重错位。一台服务器采购预算20万合同约定到货验收后付90%那么在第1个月末即使这台服务器还没到货资金计划上可能一分钱没花但按工作量计划如果采购工作已经计划完成50%PV就该是10万。PV看的是工作进度不是付款进度。2.2 EV整套体系中最容易注水的一个数EVEarned Value挣值也叫BCWPBudgeted Cost of Work Performed已完成工作的预算成本。定义是截至检查点实际完成的工作按照批准预算折算出来的金额。注意它的计价基准仍然是预算不是实际花费。这一点是很多人绕不过弯的地方。举个具体例子。某工作包预算10万计划第3个月末完成60%实际完成了50%。那么PV 10 × 60% 6万EV 10 × 50% 5万EV为什么重要因为它是整个体系的枢纽。SV是用EV减PVCV是用EV减ACSPI是EV除以PVCPI是EV除以AC。四个衍生指标里EV出现了四次。一旦EV失真四个指标全部失效而且失真的方向往往是“看起来更好”这就是为什么实际项目里EV造假最普遍。EV的计算有三种主流规则选哪种直接决定了数据的敏感度测量规则适用工作包优点缺点0/100法交付物边界清晰、不可分割的工作客观、无法注水进度跳跃式变化中期看不出真实状态50/50法工期短、价值分布均匀的工作平滑、简单高估前期进度容易产生“50%永远完不成”现象百分比完成法工期长、可细分的工作精细、连续主观性强依赖执行人的诚信与判断我在实际项目里通常采用混合策略硬件到货类工作用0/100法到货就是100%没到货就是0中间没有模糊地带软件开发类用百分比完成法但百分比不由开发人员自己报而是由可交付功能点或者通过的测试用例数来折算。比如一个模块有40个功能点通过测试30个完成度就是75%。这样就把主观判断压缩到了最小空间。注意EV只认“完成”不认“开始”。开工了但没产出EV是零。这一点在汇报时容易引起误解甲方看到你的人在现场忙了两个月EV却很低会觉得你在磨洋工。解决办法是在WBS里把“准备工作”“环境搭建”这类前置工作单独拆成工作包并赋予权重让前期投入也能体现为价值。2.3 AC财务视角和项目视角的差异ACActual Cost实际成本也叫ACWPActual Cost of Work Performed。定义看起来最简单截至检查点为完成实际工作所实际发生的全部成本。但在落地时这个词的边界会变得非常模糊。财务部门理解的AC是已经入账、有发票、走完付款流程的支出。项目部门理解的AC是已经发生、但可能还没结算的支出包括供应商已供货未开票、外包人员已投入未结算、内部人力已投入但走的是人力成本分摊。这两种理解差异可能高达项目总预算的20%以上。我的处理方式是在项目启动时就把AC的口径写进项目管理计划并且明确规定“应计成本”Accrued Cost的处理方法。凡是已经发生但尚未结算的成本按合同金额或内部计价标准预估后计入AC同时在报表里单独标注避免事后调整导致指标剧烈波动。还有一个问题内部人力成本算不算AC在纯外包型集成项目里这不成问题成本就是付出去的钱。但在自有团队实施的项目里如果只算外购支出AC会严重低估CPI会虚高到1.3以上完全失去参考价值。我一般建议把内部人力按标准人天费率折算计入AC虽然这会让数字变大、CPI变难看但它是真实的资源消耗藏着掖着只会让后期决策失误。举个直观的对比。某集成项目第4个月末外购支出38万内部投入按人天折算6.5万。如果只报38万AC偏低如果全算AC为44.5万。前者算出来的CPI可能漂亮得多但掩盖了团队已经被这个项目吃掉了大量人力的事实。2.4 三个基础量的关系速记把三个量放在一起可以用一句话概括它们各自的立场PV是“计划说的话”代表承诺。EV是“事实说的话”代表产出。AC是“钱袋子说的话”代表投入。对应到实际角色PV是计划部门给你的EV是工程执行部门确认的AC是财务和采购确认的。三份数据往往来自三个不同的口子口径不一致是常态。所以我带项目时有个习惯每月做挣值分析前先花半天时间做三份数据的一致性核对把PV的版本确认到最新基线把EV的确认记录落到具体交付物上把AC的口径对齐到同一时间截点。这半天省不得省了后面全是返工。3. 四个衍生指标偏差和指数怎么读3.1 SV和CV负数到底意味着什么SVSchedule Variance进度偏差 EV − PV。 CVCost Variance成本偏差 EV − AC。两个公式结构完全对称都是“实际产出减去参照物”。SV的参照物是计划值CV的参照物是实际花费。结果的符号含义要死死记住SV 0进度提前实际产出超过计划。SV 0进度符合计划。SV 0进度落后实际产出不达计划。CV 0成本节约产出价值高于投入。CV 0成本符合预算。CV 0成本超支投入高于产出价值。这里最容易混淆的是CV。很多人下意识觉得“花的钱比预算多就是超支”但挣值管理里的CV判断基准不是预算而是已完成工作的价值。一个项目花了60万预算总额80万看起来还剩20万空间但如果实际只完成了50%的工作EV 40万那CV 40 − 60 −20万是严重超支。反过来花了60万但完成了85%EV 68万CV 8万是节约。CV问的不是“我花了多少”而是“我花的钱买到的价值值不值”。SV还有个天生的局限它是金额单位不能直接告诉你“落后几天”。SV −4.6万落后多少时间不知道。要换算成时间得结合项目的成本分布曲线。这个局限在实际汇报时经常被甲方追问我的应对办法是同时给出SPI和关键路径上的浮动时间分析用两个维度互相印证。3.2 SPI和CPI指数比偏差更好用的地方SPISchedule Performance Index进度绩效指数 EV / PV。 CPICost Performance Index成本绩效指数 EV / AC。指数是偏差的标准化版本好处是跨项目可比。SV −5万这个数字放在一个80万的项目里是灾难放在一个8000万的项目里几乎可以忽略。但SPI 0.85放在任何项目里含义都是一样的进度只达到了计划的85%。这也是为什么多项目管控时我更倾向于看指数而不是偏差。判断标准很简单指标大于1等于1小于1SPI进度提前进度符合计划进度落后CPI成本节约成本符合预算成本超支需要特别提醒的是SPI和CPI的“好坏”不能孤立判断。CPI大于1有时反而是坏消息——如果是因为该花的钱没花、该做的质量工作被砍掉了那这个CPI是透支未来换来的。我见过一个项目CPI长期维持在1.15看着很漂亮结果验收阶段集中爆出一堆缺陷返工成本直接把CPI砸到0.9以下。CPI高要看高在哪是效率提升还是投入不足这两者的性质完全不同。还有一个技术细节SPI的计算在项目末期会失真。因为当项目接近完工时PV和EV都趋近于BACSPI会自然回归到1即使前面一直落后。这叫“末期收敛效应”。所以项目最后20%的时间里SPI的参考价值会下降得配合完工尚需绩效指数TCPI来看。3.3 八个象限指标组合起来的判读逻辑单个指标只能说明一个维度两个指标组合起来才是完整的诊断。SPI和CPI各有大于1和小于1两种状态组合起来是四种典型局面加上临界情况可以扩展成更细的判断组合状态描述典型成因建议动作SPI1, CPI1又快又省效率高或预算留有余量核查数据真实性警惕后期反弹SPI1, CPI1快但费钱赶工、加班、加人、加急采购评估超支是否可承受控制赶工烈度SPI1, CPI1慢但省钱资源投入不足、采购延后加快资源到位防止进度进一步恶化SPI1, CPI1又慢又费范围蔓延、返工、管理失控立即干预重排计划必要时走变更我在实际项目里遇到过最棘手的是第三种SPI 0.88、CPI 1.09。表面看成本控制得很好实际上是关键设备采购拖了两个月钱没花出去活也没干出来。这种“假节约”如果不及时识别等到后期集中采购、集中施工成本和进度会同时爆炸。识别方法很简单看AC的增长曲线是不是平滑的。正常的项目AC应该随时间稳定上升如果某几个月AC几乎不动要么是付款条件特殊要么就是工作真的停了。提示指标组合判读时一定要结合项目阶段。前期SPI低于1比较常见因为启动和规划阶段的工作量容易低估后期SPI低于1则非常危险因为可压缩的空间已经很小了。4. 实操从WBS到一张能用的挣值报表4.1 测量规则的选择决定了数据的敏感度前面提过三种测量规则这里展开讲怎么选。选择的核心依据是工作包的可分割程度和工期的长短。工期在两周以内、交付物单一的工作包用0/100法最干净。比如“机房UPS安装调试”要么装完调通要么没装完没有中间状态。这种规则的好处是杜绝了主观操作空间坏处是如果这个工作包跨了一个月末检查点那个月的EV就是0可能造成指标剧烈波动。工期在一个月左右、过程连续的工作包用50/50法比较省事。开工即记50%完工记100%。这种方法在建筑行业用得很广但在系统集成项目里要慎用因为集成工作的“开工”往往只是进场距离真正产出还有很长距离50%容易高估。工期超过一个月、可以细分成多个可验证成果的工作包用百分比完成法。关键是百分比的计算依据必须提前定义清楚。常见依据有完成的子任务数占比、通过的测试用例数占比、已交付的功能点占比、已完成的工时占比。我最推荐功能点和测试用例这两种因为它们有客观记录不依赖个人判断。这里必须强调一个实操要点测量规则一旦确定整个项目周期内不要随意更改。我见过一个项目中途把软件开发的测量规则从50/50改成百分比完成法结果SPI从0.95直接跳到0.72不是因为项目恶化了纯粹是口径变了。这种数据断层会让历史对比完全失效也会让甲方对你的数据能力产生怀疑。4.2 检查点设置与数据采集的落地流程挣值分析不是月末拍脑袋算出来的它需要一套固定的采集节奏。我通常的做法是确定检查周期。集成项目一般按月工期紧张的核心阶段可以缩到双周。周期太短数据采集成本高且噪声大周期太长问题发现不及时。固定数据截点。每月最后一个工作日18:00为截点之后的支出和完成情况计入下月。这个规则必须写进项目管理计划并且让财务、采购、工程三方都认。三份数据分头采集。PV从项目管理软件或计划表里取EV由各工作包负责人提交完成情况并附证明材料AC由财务和采购提交支出明细加应计成本。一致性核对。重点核对三件事EV确认的交付物是否有验收记录AC里的支出是否对应本项目PV的基线是否是当前生效版本。计算与出表。按WBS逐层汇总先算工作包层级再汇总到控制账户最后到项目层级。这套流程走下来一个中等规模项目20到30个工作包大概需要半天到一天。我知道很多项目经理嫌麻烦想直接让财务给个数、让工程部报个百分比就完事但我实打实告诉你省下的一天后期要用一周去补。数据口径不清导致的返工、扯皮、汇报被打回成本远高于前期投入。数据采集还有一个容易被忽略的点EV的证明材料要归档。不是让你搞形式主义而是当甲方或者审计质疑“这个80%是怎么来的”时你能立刻拿出测试报告、验收单、现场照片。没有证据支撑的EV在争议场合等于零。4.3 一个完整案例从原始数据到偏差分析光看公式没感觉走一遍完整计算就清楚了。下面这个案例是我按照常见集成项目的结构虚构的数据做了简化处理但计算逻辑和真实项目一致。项目背景某单位机房及云平台集成项目总预算BAC 80万元计划工期8个月。WBS分解为五个工作包工作包预算万元计划完成时间1.1 机房环境改造12第2月末1.2 服务器与存储采购28第3月末1.3 网络与安全设备部署16第5月末1.4 云平台软件部署14第6月末1.5 联调测试与培训10第8月末合计80—第4个月末的检查数据计划完成情况1.1完成100%1.2完成100%1.3计划完成80%1.4计划完成50%1.5尚未开始。实际完成情况1.1完成100%1.2完成100%1.3完成60%1.4完成40%1.5未开始。实际支出1.1支出13万1.2支出27万1.3支出9万1.4支出6万合计55万。第一步算PVPV 12×100% 28×100% 16×80% 14×50% 10×0% 12 28 12.8 7 0 59.8 万元第二步算EVEV 12×100% 28×100% 16×60% 14×40% 10×0% 12 28 9.6 5.6 0 55.2 万元第三步算SV和CVSV EV − PV 55.2 − 59.8 −4.6 万元 CV EV − AC 55.2 − 55.0 0.2 万元第四步算SPI和CPISPI EV / PV 55.2 / 59.8 ≈ 0.923 CPI EV / AC 55.2 / 55.0 ≈ 1.004结论判读SPI约0.92进度落后约8%CPI约1.00成本基本持平、略有节约。属于“慢但不费钱”的组合。进一步看明细会发现进度落后的主因是1.3网络设备部署只完成了60%计划80%差距2.4万的EV1.4软件部署完成40%计划50%差距1.4万。而成本方面1.1机房改造超支1万1.2采购节约1万两者相抵所以总体CPI看起来平稳。这种明细分析才是挣值管理的价值所在。如果只看总体的CPI 1.004你会以为一切正常拆到工作包才知道机房改造已经在超支只是被采购节约掩盖了。汇总数据会骗人明细不会。4.4 完工预测EAC的四种算法与TCPI算出当前状态只是第一步管理层更关心的是“照这样下去最后要花多少钱、还要多久”。这就要求完工估算EACEstimate At Completion。EAC有几种算法适用场景不同不能混用算法一EAC BAC / CPI假设剩余工作按当前成本效率继续EAC 80 / 1.004 ≈ 79.7 万元这是最常用的一种逻辑是“目前每花1元产出1.004元价值这个效率会保持到项目结束”。适合偏差已经稳定、后续工作性质与前期相似的项目。算法二EAC AC (BAC − EV)假设剩余工作按预算效率完成EAC 55 (80 − 55.2) 55 24.8 79.8 万元这种算法认为前期偏差是偶发的后续会恢复正常。适合偏差由一次性事件导致、且已消除的情况比如某批设备临时涨价。算法三EAC AC (BAC − EV) / (CPI × SPI)同时考虑成本和进度双重偏差EAC 55 24.8 / (1.004 × 0.923) 55 24.8 / 0.927 55 26.75 ≈ 81.75 万元这种算法最保守认为进度落后会迫使后期赶工赶工必然带来额外成本。适合进度偏差较大、且剩余工期没有缓冲余地的项目。我一般在这种情况才用它因为它的预测往往偏悲观。算法四EAC AC 自下而上重新估算的ETC。当项目发生重大变更、原有预算基础不再成立时只能重新估算剩余工作。这种方法最准但也最费时通常一个项目整个周期只用一两次。再算TCPITo-Complete Performance Index完工尚需绩效指数衡量剩余工作必须达到多高的成本效率才能守住预算TCPI (BAC − EV) / (BAC − AC) (80 − 55.2) / (80 − 55) 24.8 / 25 0.992TCPI小于1说明剩余工作只要维持当前效率甚至略微放松就能在预算内完工压力不大。如果TCPI大于1.1就意味着必须显著提升效率通常需要采取实质性的成本控制措施光靠喊口号没用。这个案例里CPI大于1所以TCPI小于1逻辑是自洽的。反过来如果CPI是0.85TCPI就会大于1两个数会形成一对“当前效率”和“未来要求”的对照这个对照在向管理层要资源时特别有说服力。注意四种EAC算法算出来的结果可能相差很大选哪种要在报告里明确标注假设条件。我见过汇报时只甩一个EAC数字被甲方追问算法后答不上来的情况非常被动。给数字必须给口径这是专业度的底线。5. 常见问题与避坑实录5.1 指标互相矛盾时的判断顺序实操中最常见的困惑是SPI说落后CPI说节约到底该信哪个或者SV为负但SPI接近1是不是不用管我的判断顺序是这样的第一先看绝对值量级。SV −0.3万、SPI 0.98这种偏差在统计噪声范围内不值得投入管理精力去纠正观察即可。SV −15万、SPI 0.7那就是实质性落后必须干预。指数负责定性偏差负责定量两者要一起看。第二看偏差集中在哪个工作包。整体指标是加权结果可能掩盖局部严重问题。用WBS逐层下钻找出贡献最大的三个工作包八成的问题就在这三处。第三看偏差的方向是否可持续。CPI大于1如果是靠压缩必要投入换来的那就是不可持续的假象要主动打折。判断方法是看AC的增长结构和质量投入占比质量相关的支出明显偏低就是个危险信号。第四看关键路径。进度偏差如果发生在非关键路径上且有浮动时间可能不影响最终工期如果发生在关键路径上哪怕只有几天也要立刻处理。挣值管理本身不区分关键路径和非关键路径这个判断得靠网络图补充。5.2 EV注水的四种典型手法和识别方法EV是整套体系的枢纽也是最容易做手脚的地方。我把见过的套路归成四类附上识别方法手法一提前确认完成度。工作包实际完成70%报成90%。识别方法要求提供交付物清单和验收记录逐个核对。如果报90%但只能拿出70%的交付物问题就暴露了。手法二把“开工”算成“完成”。用50/50法时工作包刚启动就记50%。识别方法结合工期判断一个计划两个月的包启动第三天就报50%明显不合理。手法三拆分工作包稀释偏差。把一个落后严重的大包拆成几个小包让每个小包的偏差看起来都不大。识别方法看WBS版本的变更历史非变更流程驱动的WBS调整都要打问号。手法四把返工排除在EV之外。返工消耗了资源但没产生新价值如果返工成本没计入ACCPI会虚高。识别方法对比质量记录和AC的增长返工多的月份AC应该同步上升。提示抵御EV注水最有效的办法不是审计而是让EV和里程碑付款挂钩。当EV确认直接影响到能不能开票收款时各方对数据的认真程度会立刻提升一个档次。5.3 常见问题速查表现象可能原因排查动作处理方向SPI正常但SV为负且绝对值大项目规模大小比例偏差对应大金额换算成天数看实际落后程度结合关键路径判断是否需干预CPI持续大于1.1AC口径漏算如未计内部人力核对AC的成本构成完整性补全口径后重新计算SPI突然大幅下降测量规则变更或检查点数据错误核对规则版本和数据截点修正数据恢复一致性EV增长但AC几乎不动应计成本未入账检查供应商已供货未结算部分按合同预估计入ACEAC远大于BAC但CPI尚可进度落后导致赶工成本用算法三交叉验证评估赶工方案的经济性项目末期SPI回归1末期收敛效应属于统计特性非真实改善改用TCPI评估剩余压力各工作包指标都正常但总体异常汇总口径或权重错误逐层核对汇总过程修正WBS权重分配除了表里的这些我再补两条纯经验性的第一条不要在项目第一个月就急着下结论。刚开始时PV很小EV的微小波动会造成SPI剧烈跳动一个SPI 0.5看起来像灾难实际上可能只是某个工作包晚启动了三天。我一般建议从第二个月末开始正式用挣值判断趋势前两个月只看数据积累是否规范。第二条指标恶化时先查数据再查执行。经验告诉我大约三成的“指标异常”其实是数据问题而不是执行问题。口径变了、截点错了、某个工作包漏统计了这些都会造成假警报。先花半小时核对数据比直接冲去问责团队要高效得多也更不伤士气。6. 考试视角和实战视角的差异6.1 考试里常见的三种考法系统集成项目管理工程师的考试里挣值相关的题目基本跑不出三类。第一类是直接计算。给一张表列出各工作包的预算、计划完成比例、实际完成比例、实际支出让你算PV、EV、AC、SV、CV、SPI、CPI然后判断状态。这类题的关键是先把三个基础量算对再套公式顺序不能乱。容易出错的地方是PV和EV的比例用反或者把实际支出当成EV。第二类是完工预测。在算出CPI的基础上让你算EAC、ETC、VAC、TCPI。这里要注意题目指定用哪种算法如果没指定默认用EAC BAC / CPI。ETC EAC − ACVAC BAC − EAC这三个公式要能瞬间反应。第三类是情景判断。给一段项目描述让你分析问题出在哪、该采取什么措施。这类题没有标准公式可套靠的是对指标组合的理解。比如“项目SPI为0.85CPI为1.1问项目经理应该怎么做”合理的答案方向是进度落后但成本有节约空间可以考虑增加资源投入来追赶进度因为成本上有缓冲。如果反过来SPI 1.1、CPI 0.85那就该控制成本避免继续赶工加剧超支。考试和实战最大的差异在于考试给的数据是干净的、口径统一的、答案唯一的实战的数据是脏的、口径是打架的、答案往往有多个。所以备考时要把公式练到条件反射实战时要把口径核对养成习惯两者不能互相替代。6.2 小项目怎么用最轻的方式落地很多同行跟我说挣值管理是好东西但自己手上的项目就三五个人、预算几十万搞一套完整的WBS加权、月度采集、多层汇总成本比收益还高。这个顾虑是合理的我给出一个简化方案二十分钟就能搭起来。简化方案的核心是只做工作包层级不做更细的分解用Excel一张表搞定。具体做法把项目拆成8到15个工作包每个给一个预算金额加起来等于总预算。这一步在项目启动会上跟团队一起做顺便统一认知。每个工作包指定一个完成度计算依据写在表里。硬件类用0/100软件类用功能点或测试用例数。每月末填三列数据计划完成度、实际完成度、实际支出。表里预置公式PV、EV、SV、CV、SPI、CPI自动算出来。只重点看三个数SPI、CPI、偏差最大的两个工作包。这套东西的采集成本大概是每人每月十分钟项目经理汇总半小时。它算不出精确到小数点后两位的结论但足以回答“项目现在是快了还是慢了、钱是省了还是超了”这两个核心问题。等项目管理成熟度上来了、项目规模大了再往上加控制账户、加EAC多算法对比循序渐进。我用这套简化表带过好几个中小型集成项目最大的体会是挣值管理的门槛不在工具在于愿不愿意在项目开始时把预算拆细。拆细了这个动作本身就已经解决了一半的项目管控问题。很多人卡在“懒得拆”然后用一整年的糊涂账来偿还这几个小时的懒惰。最后分享一个我在实际使用中养成的小习惯每次算完挣值不要只看数字一定要在工作包明细里挑出偏差最大的那个去现场或者找负责人聊十分钟问清楚到底发生了什么。数字告诉你哪里有问题但只有人能告诉你为什么有问题。这两件事合起来才叫真正把挣值管理用起来了。
做系统集成的老手大概都经历过这种场面项目例会上负责人问“现在花了多少钱、活干到哪了”项目经理翻出采购单说花了五十多万翻出施工日志说大概干了一半紧接着追问“那到底是快了还是慢了、钱是省了还是超了”会议室瞬间安静。这种时候挣值管理Earned Value ManagementEVM就是那套能把“感觉”翻译成“数字”的工具。它真正要用的核心量只有七个PV、EV、AC、SV、CV、SPI、CPI三个基础量加四个衍生指标构成一套极简但极稳的度量体系。这套东西是系统集成项目管理工程师考试里的高频计算大题也是实际带集成项目时做周报、月报、向甲方汇报进度的硬通货。不管你是正在备考、被公式绕晕的考生还是手上同时压着三五个在建项目、需要一张表讲清楚状况的从业者把这七个量吃透收益都很直接。1. 挣值管理要回答的三个问题1.1 为什么“花了多少钱”和“干了多少活”必须分开看项目管理里最原始的度量方式是单维度的看预算还剩多少或者看时间过了多少。单维度度量有个致命缺陷——它无法区分“省钱”和“省事”。一个项目预算80万时间过半花了35万听起来控制得不错但如果实际只完成了30%的工作量那这35万就是超支而不是节约。反过来预算80万时间过半花了45万看着吓人但实际完成了65%那多花的钱买到了超额进度属于良性投入。挣值管理的本质是把成本维度和进度维度强行拆开用同一把尺子——货币——去度量两件完全不同的事。PV衡量“按计划此刻应该值多少钱”EV衡量“实际干出来的活值多少钱”AC衡量“为这些活实际付了多少钱”。三者都是金额单位放在同一个坐标系里谁高谁低一目了然。这个设计的巧妙之处在于它绕开了“进度百分比”这种无法横向比较的模糊表述。你说“完成了60%”甲方会问按什么算的你说“挣了48万”对方立刻能跟你预算表上的数字对上。我在实际带项目时最深的体会是能用钱说清楚的事尽量不要用百分比说。百分比是主观的金额是客观的而挣值管理强迫你在项目开始时就为每个工作包赋予金额权重这个动作本身就是一次极好的范围澄清。很多项目后期扯皮根源就在于前期没做这件事导致“做完了”和“做到位了”之间没有统一的判定标准。1.2 七个参数其实是一张三维坐标系把七个量画在一张图上你会看到它们并不是七个孤立的名词。PV、EV、AC是三个基础坐标分别对应“计划—实际产出—实际投入”三个维度SV和CV是两个差值衡量产出与计划、产出与投入之间的偏离SPI和CPI是两个比值衡量偏离的相对程度。这就像一个三维空间里的三个点衍生出来的四个指标描述的是点与点之间的相对位置关系。理解这个结构非常关键因为考试里大量题目不是直接问“SV是什么”而是给你一堆条件让你推导或者在题干里只给部分数据让你先补全三个基础量。实际工作里也一样很多项目经理拿到的数据是残缺的财务只给你支出总额工程部只给你完成情况计划部只给你基线。你必须知道这七个量之间的代数关系才能把缺口补上。提示PV、EV、AC三者的顺序不要记反。PV是基于计划的EV是基于实际完成的AC是基于实际花费的。一个记忆法是P代表PlanE代表Earned挣到的A代表Actual。挣值这个名字本身就点明了EV的性质——它是“挣到手的工作价值”。1.3 哪些人必须吃透这套东西第一类是备考系统集成项目管理工程师的人。这门考试的计算题里挣值分析的出镜率极高通常会给出一个项目背景表让你算SV、CV、SPI、CPI再判断项目状态最后算EAC和ETC。分值不低而且步骤之间有依赖关系前面算错一个数后面全崩。第二类是实际负责集成项目的项目经理。系统集成项目的特点是硬件、软件、实施、服务混在一起成本结构复杂甲方又特别在意进度。挣值管理能让你在月度汇报时拿出“截至本月末项目进度偏差为负X万成本偏差为正Y万综合判断建议采取以下措施”这样的结论而不是“目前进展顺利”这种空话。第三类是项目办的管控人员。多项目并行时你需要一个跨项目可比的指标。CPI和SPI天然具备这个能力一个CPI 0.85的项目和一个CPI 1.05的项目放在一起资源该往哪倾斜数据自己会说话。2. 三个基础量PV、EV、AC 的准确含义与常见误区2.1 PV基线里的那个“应该值多少”PVPlanned Value计划值有些老教材里叫BCWSBudgeted Cost of Work Scheduled计划工作的预算成本。定义是截至某个检查点按计划应该完成的工作按照批准的项目预算折算出来的金额。注意这里有两个限定词很关键“按计划应该完成”和“批准的项目预算”。前者决定了PV是随时间推移线性或阶梯式增长的后者决定了PV永远以基线为锚不因执行过程中的变更而随意调整除非变更走了正式审批流程并更新了基线。算PV最常见的方法是先做WBS分解把总预算BAC分摊到每个工作包再根据每个工作包的进度计划算出每个检查点上的累计计划价值。比如一个工作包预算12万计划4个月完成按均速推进那么第2个月末它的PV就是6万。如果这个工作包是按里程碑付款的那就按里程碑节点分摊第一个里程碑占40%就对应4.8万。这里有个坑要提醒PV不等于“计划支出”。很多新手会拿资金使用计划表直接当PV用这是错的。资金使用计划反映的是现金流可能因为付款条件比如验收后一次性付款、预付30%而与工作进度严重错位。一台服务器采购预算20万合同约定到货验收后付90%那么在第1个月末即使这台服务器还没到货资金计划上可能一分钱没花但按工作量计划如果采购工作已经计划完成50%PV就该是10万。PV看的是工作进度不是付款进度。2.2 EV整套体系中最容易注水的一个数EVEarned Value挣值也叫BCWPBudgeted Cost of Work Performed已完成工作的预算成本。定义是截至检查点实际完成的工作按照批准预算折算出来的金额。注意它的计价基准仍然是预算不是实际花费。这一点是很多人绕不过弯的地方。举个具体例子。某工作包预算10万计划第3个月末完成60%实际完成了50%。那么PV 10 × 60% 6万EV 10 × 50% 5万EV为什么重要因为它是整个体系的枢纽。SV是用EV减PVCV是用EV减ACSPI是EV除以PVCPI是EV除以AC。四个衍生指标里EV出现了四次。一旦EV失真四个指标全部失效而且失真的方向往往是“看起来更好”这就是为什么实际项目里EV造假最普遍。EV的计算有三种主流规则选哪种直接决定了数据的敏感度测量规则适用工作包优点缺点0/100法交付物边界清晰、不可分割的工作客观、无法注水进度跳跃式变化中期看不出真实状态50/50法工期短、价值分布均匀的工作平滑、简单高估前期进度容易产生“50%永远完不成”现象百分比完成法工期长、可细分的工作精细、连续主观性强依赖执行人的诚信与判断我在实际项目里通常采用混合策略硬件到货类工作用0/100法到货就是100%没到货就是0中间没有模糊地带软件开发类用百分比完成法但百分比不由开发人员自己报而是由可交付功能点或者通过的测试用例数来折算。比如一个模块有40个功能点通过测试30个完成度就是75%。这样就把主观判断压缩到了最小空间。注意EV只认“完成”不认“开始”。开工了但没产出EV是零。这一点在汇报时容易引起误解甲方看到你的人在现场忙了两个月EV却很低会觉得你在磨洋工。解决办法是在WBS里把“准备工作”“环境搭建”这类前置工作单独拆成工作包并赋予权重让前期投入也能体现为价值。2.3 AC财务视角和项目视角的差异ACActual Cost实际成本也叫ACWPActual Cost of Work Performed。定义看起来最简单截至检查点为完成实际工作所实际发生的全部成本。但在落地时这个词的边界会变得非常模糊。财务部门理解的AC是已经入账、有发票、走完付款流程的支出。项目部门理解的AC是已经发生、但可能还没结算的支出包括供应商已供货未开票、外包人员已投入未结算、内部人力已投入但走的是人力成本分摊。这两种理解差异可能高达项目总预算的20%以上。我的处理方式是在项目启动时就把AC的口径写进项目管理计划并且明确规定“应计成本”Accrued Cost的处理方法。凡是已经发生但尚未结算的成本按合同金额或内部计价标准预估后计入AC同时在报表里单独标注避免事后调整导致指标剧烈波动。还有一个问题内部人力成本算不算AC在纯外包型集成项目里这不成问题成本就是付出去的钱。但在自有团队实施的项目里如果只算外购支出AC会严重低估CPI会虚高到1.3以上完全失去参考价值。我一般建议把内部人力按标准人天费率折算计入AC虽然这会让数字变大、CPI变难看但它是真实的资源消耗藏着掖着只会让后期决策失误。举个直观的对比。某集成项目第4个月末外购支出38万内部投入按人天折算6.5万。如果只报38万AC偏低如果全算AC为44.5万。前者算出来的CPI可能漂亮得多但掩盖了团队已经被这个项目吃掉了大量人力的事实。2.4 三个基础量的关系速记把三个量放在一起可以用一句话概括它们各自的立场PV是“计划说的话”代表承诺。EV是“事实说的话”代表产出。AC是“钱袋子说的话”代表投入。对应到实际角色PV是计划部门给你的EV是工程执行部门确认的AC是财务和采购确认的。三份数据往往来自三个不同的口子口径不一致是常态。所以我带项目时有个习惯每月做挣值分析前先花半天时间做三份数据的一致性核对把PV的版本确认到最新基线把EV的确认记录落到具体交付物上把AC的口径对齐到同一时间截点。这半天省不得省了后面全是返工。3. 四个衍生指标偏差和指数怎么读3.1 SV和CV负数到底意味着什么SVSchedule Variance进度偏差 EV − PV。 CVCost Variance成本偏差 EV − AC。两个公式结构完全对称都是“实际产出减去参照物”。SV的参照物是计划值CV的参照物是实际花费。结果的符号含义要死死记住SV 0进度提前实际产出超过计划。SV 0进度符合计划。SV 0进度落后实际产出不达计划。CV 0成本节约产出价值高于投入。CV 0成本符合预算。CV 0成本超支投入高于产出价值。这里最容易混淆的是CV。很多人下意识觉得“花的钱比预算多就是超支”但挣值管理里的CV判断基准不是预算而是已完成工作的价值。一个项目花了60万预算总额80万看起来还剩20万空间但如果实际只完成了50%的工作EV 40万那CV 40 − 60 −20万是严重超支。反过来花了60万但完成了85%EV 68万CV 8万是节约。CV问的不是“我花了多少”而是“我花的钱买到的价值值不值”。SV还有个天生的局限它是金额单位不能直接告诉你“落后几天”。SV −4.6万落后多少时间不知道。要换算成时间得结合项目的成本分布曲线。这个局限在实际汇报时经常被甲方追问我的应对办法是同时给出SPI和关键路径上的浮动时间分析用两个维度互相印证。3.2 SPI和CPI指数比偏差更好用的地方SPISchedule Performance Index进度绩效指数 EV / PV。 CPICost Performance Index成本绩效指数 EV / AC。指数是偏差的标准化版本好处是跨项目可比。SV −5万这个数字放在一个80万的项目里是灾难放在一个8000万的项目里几乎可以忽略。但SPI 0.85放在任何项目里含义都是一样的进度只达到了计划的85%。这也是为什么多项目管控时我更倾向于看指数而不是偏差。判断标准很简单指标大于1等于1小于1SPI进度提前进度符合计划进度落后CPI成本节约成本符合预算成本超支需要特别提醒的是SPI和CPI的“好坏”不能孤立判断。CPI大于1有时反而是坏消息——如果是因为该花的钱没花、该做的质量工作被砍掉了那这个CPI是透支未来换来的。我见过一个项目CPI长期维持在1.15看着很漂亮结果验收阶段集中爆出一堆缺陷返工成本直接把CPI砸到0.9以下。CPI高要看高在哪是效率提升还是投入不足这两者的性质完全不同。还有一个技术细节SPI的计算在项目末期会失真。因为当项目接近完工时PV和EV都趋近于BACSPI会自然回归到1即使前面一直落后。这叫“末期收敛效应”。所以项目最后20%的时间里SPI的参考价值会下降得配合完工尚需绩效指数TCPI来看。3.3 八个象限指标组合起来的判读逻辑单个指标只能说明一个维度两个指标组合起来才是完整的诊断。SPI和CPI各有大于1和小于1两种状态组合起来是四种典型局面加上临界情况可以扩展成更细的判断组合状态描述典型成因建议动作SPI1, CPI1又快又省效率高或预算留有余量核查数据真实性警惕后期反弹SPI1, CPI1快但费钱赶工、加班、加人、加急采购评估超支是否可承受控制赶工烈度SPI1, CPI1慢但省钱资源投入不足、采购延后加快资源到位防止进度进一步恶化SPI1, CPI1又慢又费范围蔓延、返工、管理失控立即干预重排计划必要时走变更我在实际项目里遇到过最棘手的是第三种SPI 0.88、CPI 1.09。表面看成本控制得很好实际上是关键设备采购拖了两个月钱没花出去活也没干出来。这种“假节约”如果不及时识别等到后期集中采购、集中施工成本和进度会同时爆炸。识别方法很简单看AC的增长曲线是不是平滑的。正常的项目AC应该随时间稳定上升如果某几个月AC几乎不动要么是付款条件特殊要么就是工作真的停了。提示指标组合判读时一定要结合项目阶段。前期SPI低于1比较常见因为启动和规划阶段的工作量容易低估后期SPI低于1则非常危险因为可压缩的空间已经很小了。4. 实操从WBS到一张能用的挣值报表4.1 测量规则的选择决定了数据的敏感度前面提过三种测量规则这里展开讲怎么选。选择的核心依据是工作包的可分割程度和工期的长短。工期在两周以内、交付物单一的工作包用0/100法最干净。比如“机房UPS安装调试”要么装完调通要么没装完没有中间状态。这种规则的好处是杜绝了主观操作空间坏处是如果这个工作包跨了一个月末检查点那个月的EV就是0可能造成指标剧烈波动。工期在一个月左右、过程连续的工作包用50/50法比较省事。开工即记50%完工记100%。这种方法在建筑行业用得很广但在系统集成项目里要慎用因为集成工作的“开工”往往只是进场距离真正产出还有很长距离50%容易高估。工期超过一个月、可以细分成多个可验证成果的工作包用百分比完成法。关键是百分比的计算依据必须提前定义清楚。常见依据有完成的子任务数占比、通过的测试用例数占比、已交付的功能点占比、已完成的工时占比。我最推荐功能点和测试用例这两种因为它们有客观记录不依赖个人判断。这里必须强调一个实操要点测量规则一旦确定整个项目周期内不要随意更改。我见过一个项目中途把软件开发的测量规则从50/50改成百分比完成法结果SPI从0.95直接跳到0.72不是因为项目恶化了纯粹是口径变了。这种数据断层会让历史对比完全失效也会让甲方对你的数据能力产生怀疑。4.2 检查点设置与数据采集的落地流程挣值分析不是月末拍脑袋算出来的它需要一套固定的采集节奏。我通常的做法是确定检查周期。集成项目一般按月工期紧张的核心阶段可以缩到双周。周期太短数据采集成本高且噪声大周期太长问题发现不及时。固定数据截点。每月最后一个工作日18:00为截点之后的支出和完成情况计入下月。这个规则必须写进项目管理计划并且让财务、采购、工程三方都认。三份数据分头采集。PV从项目管理软件或计划表里取EV由各工作包负责人提交完成情况并附证明材料AC由财务和采购提交支出明细加应计成本。一致性核对。重点核对三件事EV确认的交付物是否有验收记录AC里的支出是否对应本项目PV的基线是否是当前生效版本。计算与出表。按WBS逐层汇总先算工作包层级再汇总到控制账户最后到项目层级。这套流程走下来一个中等规模项目20到30个工作包大概需要半天到一天。我知道很多项目经理嫌麻烦想直接让财务给个数、让工程部报个百分比就完事但我实打实告诉你省下的一天后期要用一周去补。数据口径不清导致的返工、扯皮、汇报被打回成本远高于前期投入。数据采集还有一个容易被忽略的点EV的证明材料要归档。不是让你搞形式主义而是当甲方或者审计质疑“这个80%是怎么来的”时你能立刻拿出测试报告、验收单、现场照片。没有证据支撑的EV在争议场合等于零。4.3 一个完整案例从原始数据到偏差分析光看公式没感觉走一遍完整计算就清楚了。下面这个案例是我按照常见集成项目的结构虚构的数据做了简化处理但计算逻辑和真实项目一致。项目背景某单位机房及云平台集成项目总预算BAC 80万元计划工期8个月。WBS分解为五个工作包工作包预算万元计划完成时间1.1 机房环境改造12第2月末1.2 服务器与存储采购28第3月末1.3 网络与安全设备部署16第5月末1.4 云平台软件部署14第6月末1.5 联调测试与培训10第8月末合计80—第4个月末的检查数据计划完成情况1.1完成100%1.2完成100%1.3计划完成80%1.4计划完成50%1.5尚未开始。实际完成情况1.1完成100%1.2完成100%1.3完成60%1.4完成40%1.5未开始。实际支出1.1支出13万1.2支出27万1.3支出9万1.4支出6万合计55万。第一步算PVPV 12×100% 28×100% 16×80% 14×50% 10×0% 12 28 12.8 7 0 59.8 万元第二步算EVEV 12×100% 28×100% 16×60% 14×40% 10×0% 12 28 9.6 5.6 0 55.2 万元第三步算SV和CVSV EV − PV 55.2 − 59.8 −4.6 万元 CV EV − AC 55.2 − 55.0 0.2 万元第四步算SPI和CPISPI EV / PV 55.2 / 59.8 ≈ 0.923 CPI EV / AC 55.2 / 55.0 ≈ 1.004结论判读SPI约0.92进度落后约8%CPI约1.00成本基本持平、略有节约。属于“慢但不费钱”的组合。进一步看明细会发现进度落后的主因是1.3网络设备部署只完成了60%计划80%差距2.4万的EV1.4软件部署完成40%计划50%差距1.4万。而成本方面1.1机房改造超支1万1.2采购节约1万两者相抵所以总体CPI看起来平稳。这种明细分析才是挣值管理的价值所在。如果只看总体的CPI 1.004你会以为一切正常拆到工作包才知道机房改造已经在超支只是被采购节约掩盖了。汇总数据会骗人明细不会。4.4 完工预测EAC的四种算法与TCPI算出当前状态只是第一步管理层更关心的是“照这样下去最后要花多少钱、还要多久”。这就要求完工估算EACEstimate At Completion。EAC有几种算法适用场景不同不能混用算法一EAC BAC / CPI假设剩余工作按当前成本效率继续EAC 80 / 1.004 ≈ 79.7 万元这是最常用的一种逻辑是“目前每花1元产出1.004元价值这个效率会保持到项目结束”。适合偏差已经稳定、后续工作性质与前期相似的项目。算法二EAC AC (BAC − EV)假设剩余工作按预算效率完成EAC 55 (80 − 55.2) 55 24.8 79.8 万元这种算法认为前期偏差是偶发的后续会恢复正常。适合偏差由一次性事件导致、且已消除的情况比如某批设备临时涨价。算法三EAC AC (BAC − EV) / (CPI × SPI)同时考虑成本和进度双重偏差EAC 55 24.8 / (1.004 × 0.923) 55 24.8 / 0.927 55 26.75 ≈ 81.75 万元这种算法最保守认为进度落后会迫使后期赶工赶工必然带来额外成本。适合进度偏差较大、且剩余工期没有缓冲余地的项目。我一般在这种情况才用它因为它的预测往往偏悲观。算法四EAC AC 自下而上重新估算的ETC。当项目发生重大变更、原有预算基础不再成立时只能重新估算剩余工作。这种方法最准但也最费时通常一个项目整个周期只用一两次。再算TCPITo-Complete Performance Index完工尚需绩效指数衡量剩余工作必须达到多高的成本效率才能守住预算TCPI (BAC − EV) / (BAC − AC) (80 − 55.2) / (80 − 55) 24.8 / 25 0.992TCPI小于1说明剩余工作只要维持当前效率甚至略微放松就能在预算内完工压力不大。如果TCPI大于1.1就意味着必须显著提升效率通常需要采取实质性的成本控制措施光靠喊口号没用。这个案例里CPI大于1所以TCPI小于1逻辑是自洽的。反过来如果CPI是0.85TCPI就会大于1两个数会形成一对“当前效率”和“未来要求”的对照这个对照在向管理层要资源时特别有说服力。注意四种EAC算法算出来的结果可能相差很大选哪种要在报告里明确标注假设条件。我见过汇报时只甩一个EAC数字被甲方追问算法后答不上来的情况非常被动。给数字必须给口径这是专业度的底线。5. 常见问题与避坑实录5.1 指标互相矛盾时的判断顺序实操中最常见的困惑是SPI说落后CPI说节约到底该信哪个或者SV为负但SPI接近1是不是不用管我的判断顺序是这样的第一先看绝对值量级。SV −0.3万、SPI 0.98这种偏差在统计噪声范围内不值得投入管理精力去纠正观察即可。SV −15万、SPI 0.7那就是实质性落后必须干预。指数负责定性偏差负责定量两者要一起看。第二看偏差集中在哪个工作包。整体指标是加权结果可能掩盖局部严重问题。用WBS逐层下钻找出贡献最大的三个工作包八成的问题就在这三处。第三看偏差的方向是否可持续。CPI大于1如果是靠压缩必要投入换来的那就是不可持续的假象要主动打折。判断方法是看AC的增长结构和质量投入占比质量相关的支出明显偏低就是个危险信号。第四看关键路径。进度偏差如果发生在非关键路径上且有浮动时间可能不影响最终工期如果发生在关键路径上哪怕只有几天也要立刻处理。挣值管理本身不区分关键路径和非关键路径这个判断得靠网络图补充。5.2 EV注水的四种典型手法和识别方法EV是整套体系的枢纽也是最容易做手脚的地方。我把见过的套路归成四类附上识别方法手法一提前确认完成度。工作包实际完成70%报成90%。识别方法要求提供交付物清单和验收记录逐个核对。如果报90%但只能拿出70%的交付物问题就暴露了。手法二把“开工”算成“完成”。用50/50法时工作包刚启动就记50%。识别方法结合工期判断一个计划两个月的包启动第三天就报50%明显不合理。手法三拆分工作包稀释偏差。把一个落后严重的大包拆成几个小包让每个小包的偏差看起来都不大。识别方法看WBS版本的变更历史非变更流程驱动的WBS调整都要打问号。手法四把返工排除在EV之外。返工消耗了资源但没产生新价值如果返工成本没计入ACCPI会虚高。识别方法对比质量记录和AC的增长返工多的月份AC应该同步上升。提示抵御EV注水最有效的办法不是审计而是让EV和里程碑付款挂钩。当EV确认直接影响到能不能开票收款时各方对数据的认真程度会立刻提升一个档次。5.3 常见问题速查表现象可能原因排查动作处理方向SPI正常但SV为负且绝对值大项目规模大小比例偏差对应大金额换算成天数看实际落后程度结合关键路径判断是否需干预CPI持续大于1.1AC口径漏算如未计内部人力核对AC的成本构成完整性补全口径后重新计算SPI突然大幅下降测量规则变更或检查点数据错误核对规则版本和数据截点修正数据恢复一致性EV增长但AC几乎不动应计成本未入账检查供应商已供货未结算部分按合同预估计入ACEAC远大于BAC但CPI尚可进度落后导致赶工成本用算法三交叉验证评估赶工方案的经济性项目末期SPI回归1末期收敛效应属于统计特性非真实改善改用TCPI评估剩余压力各工作包指标都正常但总体异常汇总口径或权重错误逐层核对汇总过程修正WBS权重分配除了表里的这些我再补两条纯经验性的第一条不要在项目第一个月就急着下结论。刚开始时PV很小EV的微小波动会造成SPI剧烈跳动一个SPI 0.5看起来像灾难实际上可能只是某个工作包晚启动了三天。我一般建议从第二个月末开始正式用挣值判断趋势前两个月只看数据积累是否规范。第二条指标恶化时先查数据再查执行。经验告诉我大约三成的“指标异常”其实是数据问题而不是执行问题。口径变了、截点错了、某个工作包漏统计了这些都会造成假警报。先花半小时核对数据比直接冲去问责团队要高效得多也更不伤士气。6. 考试视角和实战视角的差异6.1 考试里常见的三种考法系统集成项目管理工程师的考试里挣值相关的题目基本跑不出三类。第一类是直接计算。给一张表列出各工作包的预算、计划完成比例、实际完成比例、实际支出让你算PV、EV、AC、SV、CV、SPI、CPI然后判断状态。这类题的关键是先把三个基础量算对再套公式顺序不能乱。容易出错的地方是PV和EV的比例用反或者把实际支出当成EV。第二类是完工预测。在算出CPI的基础上让你算EAC、ETC、VAC、TCPI。这里要注意题目指定用哪种算法如果没指定默认用EAC BAC / CPI。ETC EAC − ACVAC BAC − EAC这三个公式要能瞬间反应。第三类是情景判断。给一段项目描述让你分析问题出在哪、该采取什么措施。这类题没有标准公式可套靠的是对指标组合的理解。比如“项目SPI为0.85CPI为1.1问项目经理应该怎么做”合理的答案方向是进度落后但成本有节约空间可以考虑增加资源投入来追赶进度因为成本上有缓冲。如果反过来SPI 1.1、CPI 0.85那就该控制成本避免继续赶工加剧超支。考试和实战最大的差异在于考试给的数据是干净的、口径统一的、答案唯一的实战的数据是脏的、口径是打架的、答案往往有多个。所以备考时要把公式练到条件反射实战时要把口径核对养成习惯两者不能互相替代。6.2 小项目怎么用最轻的方式落地很多同行跟我说挣值管理是好东西但自己手上的项目就三五个人、预算几十万搞一套完整的WBS加权、月度采集、多层汇总成本比收益还高。这个顾虑是合理的我给出一个简化方案二十分钟就能搭起来。简化方案的核心是只做工作包层级不做更细的分解用Excel一张表搞定。具体做法把项目拆成8到15个工作包每个给一个预算金额加起来等于总预算。这一步在项目启动会上跟团队一起做顺便统一认知。每个工作包指定一个完成度计算依据写在表里。硬件类用0/100软件类用功能点或测试用例数。每月末填三列数据计划完成度、实际完成度、实际支出。表里预置公式PV、EV、SV、CV、SPI、CPI自动算出来。只重点看三个数SPI、CPI、偏差最大的两个工作包。这套东西的采集成本大概是每人每月十分钟项目经理汇总半小时。它算不出精确到小数点后两位的结论但足以回答“项目现在是快了还是慢了、钱是省了还是超了”这两个核心问题。等项目管理成熟度上来了、项目规模大了再往上加控制账户、加EAC多算法对比循序渐进。我用这套简化表带过好几个中小型集成项目最大的体会是挣值管理的门槛不在工具在于愿不愿意在项目开始时把预算拆细。拆细了这个动作本身就已经解决了一半的项目管控问题。很多人卡在“懒得拆”然后用一整年的糊涂账来偿还这几个小时的懒惰。最后分享一个我在实际使用中养成的小习惯每次算完挣值不要只看数字一定要在工作包明细里挑出偏差最大的那个去现场或者找负责人聊十分钟问清楚到底发生了什么。数字告诉你哪里有问题但只有人能告诉你为什么有问题。这两件事合起来才叫真正把挣值管理用起来了。
