软件外包业务设计与绩效口径对齐：研讨会上通常先争哪一栏

常被交付经理问到的一句是：软件外包做这轮梳理，到底先动表还是先动会。我们的答案多半偏后者。

BLM模型由IBM与哈佛商学院在2003年合作研发，讨论时把战略、执行、价值观和领导力四件事放在一张图里看。放到软件外包的场景里：需求变更与人天核算绑在验收节点上。把这些摆清楚之后，再谈表上写几行，才不会来回返工。

先画清钱和活怎么走

业务设计变了，考核表常还按老路子取数。我们把客户、交付、回款这几段画在纸上，再逐段问：现在这张表量的是哪一段。

白板拍完照不算数，要有人把内容誊成可传阅的版本。

软件外包的人天常按班次结，总部按周汇，两个节奏并存时，附注里写清各自覆盖哪段。

栏目怎么排才不返工

• 业务段落
• 该段现有指标
• 交界处双口径说明
• 口径切换日
• 备注栏

再看现有表卡在哪

软件外包里需求变更归业务线、人天归职能线，两段交界处常出双口径。对齐时先定谁出数，再定谁复核。

研讨会不追求当场定稿，留一轮给一线核对口径。

问答：两个绕不开的疑问

问：这张表要不要当场填满？

先空着待确认栏更稳。软件外包的需求变更取数常要等一线回，当场补个大概数，下季度还得改。

问：交付经理不认口径怎么办？

把争议写进附注，别在会上争到定稿；带着实际数据下轮回来看，比当场拍板省事。

改口径比改数值省事

多数情况下不用重做整套表，把交界处的口径附注改一遍就够；大改反而会让历史数断掉，趋势没法看。

取数口径换人时，把旧口径和切换日一起记进附注。

我们更倾向先把口径摆平，权重往后放；顺序反了，会开两轮还在争同一栏。

行隆咨询2008年注册以来一直做绩效管理咨询，遇到软件外包这类场景，我们更倾向先把口径统一，再谈权重。

订单波动大的年份，这套口径要留复核口，别一次定死。这不是方法不灵，而是软件外包这类业务本来就有自己的节奏。

交付经理拿到表之后，先和岗位说明书对一遍，再往下发。

到这一步先停，下一轮再谈权重怎么分。