组织发展与人才平台的商业论证：推销的是决策，不是软件

大多数组织发展与人才软件的商业论证，都输在会议的前十分钟，而且原因相同。它们描述的是软件：功能、模块、集成、每位管理者节省的工时。高层领导听到的是一笔新成本，收益听起来虚，而且来得晚。获批的论证则反其道而行之。它们从领导层已经感受到的一个高代价、反复出现的组织问题出发，说明这个问题的代价，并把平台呈现为停止为它付费的最便宜、最可信的方式。而且，它们在要预算之前先要一次试点。

这场对话的两边我们都坐过：帮助人力资源与战略负责人写论证，也坐在做决定的领导团队对面。有一条令人不太舒服的建议，我们每次都会给：如果你说不出这个平台将改变哪个决策，就不该买它。买我们的也一样。

「你告诉了我它能做什么，没告诉我什么会改变」

沙特阿拉伯一家约三百名员工的公司的人力资源总监花了几周时间，为一个人才与组织发展平台准备商业论证。它长达三十页幻灯片：四家供应商的功能对比、在绩效评估和报表上预计节省的工时，以及根据供应商数据算出的投资回报率。

首席财务官大约用了十分钟就否决了它。让这位人力资源总监记住的是理由：「你告诉了我它能做什么。你没有告诉我什么会改变，也没有告诉我由谁来改变。」

第二次尝试只有一页。几个月前的领导层务虚会上，首席执行官抱怨过当年的三项战略举措停滞了，而且没人说得清由谁负责。新的论证点名了这个问题，估算了其中仅一项举措所延误的收入，提出一个九十天的试点，让领导团队用这个平台为这三项举措指定负责人并跟踪进展，并且只在试点达到事先商定的衡量标准时才申请资金。它在同一次会议上获批。

单一决策商业论证

第二次尝试背后的结构有五个部分，几乎适用于任何组织层面的投资，而不只是软件。

1. 问题。 一个点名的、反复出现的、高代价的组织问题，领导层已经感受到，最好用他们自己的话来表述。停滞的举措、不清晰的决策权、关键团队中令人惋惜的人才流失、一次没有落地的重组。如果领导层并不相信这个问题存在，任何商业论证都说服不了他们；那就先从这里入手。
2. 什么都不做的代价。 以区间估算这个问题如果持续下去的代价，用领导层已经在用的语言来表达：延误的收入、丢失的合同、替换成本、管理者花在问题升级上的时间。保守而可信，胜过庞大而有争议。
3. 改变。 哪个决策或行为会不同，由谁以不同的方式去做。这是大多数论证遗漏的部分，也正是故事中那位首席财务官所追问的部分。软件本身什么都不会改变；人们用它做出不同的决定，才会带来改变。
4. 证明。 一次针对真实问题、有时间限定的简短试点，由那些决策本应改变的人参与，并在开始前商定衡量标准。
5. 请求。 与试点结果挂钩的分阶段投入，列明包括内部时间在内的全部成本，并给出一条在不奏效时可以叫停的清晰路径。

这样构建的论证往往不到一页。这不是弱点；正是这一点，让一个当月还有另外四十个决定要做的领导团队读得下去。

这里有个反直觉之处

不要以投资回报率百分比开场。 它是软件商业论证中领导层最不信任的部分，因为他们知道它来自供应商，而且它会把讨论引向数字背后的假设，而不是问题本身。对领导层已经相信的一项成本做一个适度的估算，远比一个需要他们凭信念接受的巨大回报更有说服力。

要得比你需要的少。 带试点的分阶段投入比一份庞大的年度合同更容易获批，而且它把领导层要回答的问题从「这值不值这笔钱？」变成了「这值不值九十天？」如果试点奏效，第二次审批会比当初的第一次容易得多。

自己把隐性成本写进去。 许可费很少是组织平台最大的成本。领导层的时间才是，其次是准备结构与角色现状数据的工作，以及让人们真正用起来所需的变革。漏掉这些的商业论证并不会更有说服力。领导层反正会想到它们，而遗漏会让作者失去信誉。

它为何有效

其中的道理在决策研究中已有充分记载。Samuelson 与 Zeckhauser 在 1980 年代末描述了现状偏差：当人们在维持现状与做出改变之间选择时，他们对现状的偏好超出了其本身价值所能支撑的程度。因此，商业论证必须让现状显现为一个有其自身代价的选择，而不是一个中性的默认项。「什么都不做的代价」这一部分做的正是这件事。

Kahneman 与 Tversky 的前景理论解释了为什么表述方式与内容同样重要。损失比同等的收益显得更重，因此领导层已经在为之付费的问题，比他们可能获得的收益分量更重。John Kotter 在 Leading Change 中从组织角度提出了同样的观点：任何变革的第一步都是建立紧迫感，而一份必须从零开始制造紧迫感的商业论证，是在逆水行舟。

最后，这与我们在那些从此类平台中获得价值的组织里看到的情况相符。价值几乎从来不只来自软件本身；它来自一个做出不同决定的领导团队，因为他们所需要的结构、归属与衡量指标终于在同一个地方可见了。我们关于战略执行为何失败和决策漂移的文章，描述了让这种可见性值得付费的那些问题。

一份实用清单

• 用领导层自己的话找到问题：务虚会记录、董事会讨论、首席执行官反复提起的那句抱怨。
• 估算这个问题一次发生的代价，保守地、以区间估算，用业务语言而不是人力资源语言。
• 用一句话写明什么会以不同方式被决定、由谁决定。 如果写不出来，就停下来重新考虑这次采购。
• 围绕真实问题设计试点，限定时间，让决策者参与，并事先商定衡量标准。
• 列出全部成本，包括领导层时间、数据准备、配置、培训和变革支持。
• 申请与试点结果挂钩的分阶段投入，并写明你将如何叫停。
• 在推介之前诚实地检验适配度。 我们关于 Green Apple 为谁而建以及它与其他平台如何比较的指南，既是为了帮你把我们选进来，也是为了帮你把我们排除在外。

问问自己

• 今年我们的领导层已经不止一次抱怨过哪个组织问题？
• 那个问题上一次发生时，大致让我们付出了多少代价，用首席财务官认得出的语言来说？
• 如果有了这个平台，谁会以不同的方式做出哪个决定？我们问过他们吗？
• 九十天试点出现什么结果会让我们决定扩大，出现什么结果会让我们决定叫停？
• 我们买它是为了解决一个问题，还是因为和我们类似的公司都买了一个？

要点

高层领导不为软件出资。他们为终结一个自己已经在为之付费的问题出资。用领导层自己的话点名这个问题，诚实地估算它的代价，说明谁将以不同的方式做决定，用一次以商定结果为衡量的简短试点来证明，然后申请分阶段投入。如果你说不出这个平台将改变哪个决策，最可信的商业论证就是你不去提交的那一份。