如何衡量工具的采纳度:为什么“活跃用户数”这个指标在撒谎

内部系统的上线报告几乎总是从活跃用户数开始讲起。这个数字在第一个月讨喜地攀升,第二个月趋于稳定,随后成为证明项目成功的主要论据。可它从未回答过项目上线本该回答的那个问题。

登录系统不等于在系统里工作。一个人可以每天打开界面,扫一眼任务列表,然后继续用邮件把真正的工作做完。在报告里,他是一名活跃用户;在实际流程里,他根本不存在。

为什么常用指标会夸大工具采纳度

每一个流行的采纳度指标都有自己夸大数字的机制,而且方向完全一致。

活跃用户数。这个数字靠好奇心和行政要求就能上涨。它区分不了在系统里干了一整天活的人,和只是登录看看有没有新东西的人。

创建记录数。这个数字靠重复录入就能上涨:员工为了应付汇报而新建一条记录,实际工作仍按老办法进行。这条记录确实存在,却不反映任何一个决策。

满意度调查。它测量的是态度,不是行为。人们的回答通常很客气,尤其是在调查不匿名的情况下,而且他们说的是意愿,不是事实。

工单数量。无论上线是成功了还是被放弃了,工单数量都会下降。没有第二项指标做对照,根本分不清是哪一种情况。

第三列就是你需要的全部指标集。三项指标取代四项,而且这三项在员工绕开系统时都会下降——这是那些惯用指标全都做不到的。

为什么不能直接问员工是否在用系统

用调查代替测量的诱惑很大:调查比系统日志(system logs)便宜,也不需要做任何系统集成。但这个问题在方法论上早就有定论。

这里需要坦诚说明一点:论文全文被付费墙锁住,我读到的是带摘要的元数据页面,而不是论文本身,所以我没有引用精确的相关系数。我采纳的是一个定性结论,并且在实践中得到过印证:一个人在调查里给出的数字,和系统实际显示的数字,是两个不同的量,不能把它们混为一谈。

什么才算已完成的流程实例

已完成流程实例(completed scenario)这个概念,借用自界面可用性测试的实践,在那里它被规范为核心指标。

这是一份面向四到五人小样本实验室测试的方法论指南,而不是面向大规模生产环境的采纳度测量;把这个概念套用到生产数据上,是我做的一个类比,我在这里明确说明这一点。它的价值在于定义本身:一个流程实例要么完成,要么没完成,不存在中间状态。正是这种二元性,让这项指标不容易被各种解释扭曲。

闲置软件到底要花多少钱

这个问题的经济账要单独测量,而且数字还在往上走。

这份报告由一家IT资产管理工具供应商赞助——把问题描述得越严重,对赞助方就越有利,这种商业动机是存在的;完整的计算方法被锁在一份需要填表才能查看的文件后面,公开页面上并未披露闲置许可证(unused licences)的具体占比,只披露了支出的变化趋势。我把它当作一个方向性指标来用:许可证的名义覆盖率增长得比实际使用快,而且差距还在拉大。对预算决策来说,这已经够用了:差距拉大本身就是一个足够的预警信号,提示该重新谈判合同条款了,哪怕拿不到浪费的精确数字。

如何搭建一套采纳度测量体系

在讨论第三项指标之前,有必要先说说第一项:它的定义是一项管理决策,而不是一项技术设置。“处理工单”这个流程实例,既可以在工单于系统中关闭的那一刻算作完成,也可以在客户收到答复并且这一点被记录下来时才算作完成。第一种定义给出的是一幅好看的图景,第二种定义给出的是一幅有用的图景。这个选择只做一次,却决定了未来一年里每一次例会上大家会讨论什么。

第二项指标——必填字段填写完整的记录占比——是防止指标被偷换概念的一道保险。没有它,很容易靠形式化创建记录就拿到很高的已完成流程实例占比:状态变更了,内容却还是空的。这两项指标合在一起,能抵御这种偷换概念的做法,因为形式上关闭一个流程实例很容易,而把必填字段填上有实际意义的内容,则要难得多。

第三项指标最不方便计算,却也最有价值。它不是在工具内部统计出来的,而是靠绕行留下的痕迹算出来的:有多少文档是在系统外创建的,有多少决策是在邮件往来里做出的,有多少任务出现在了别的地方。精确数值很难拿到,但趋势是可以拿到的,而趋势就够用了。

第一项指标应该在上线之前就定义好,连同“什么算作已完成的流程实例”这个定义一起。事后再来定义,这个定义总会不知不觉地迁就已有的数据——关于流程可观测性和上线前基线测量,我另外写过一篇文章。

写出一份诚实上线报告的四个步骤

关于采纳度测量最常见的问题