『』OKR和KPI的本质区别( 二 )


举个简单的例子 , 现在工厂一条流水线是生产口罩的 , 对于怎么生产已知 , 有10个工人但做法不一样 , A生产一个口罩用10分钟 , B用时1个小时 , C用时3个小时 。 通过BPM(Business Process Management , 业务流程管理)中的SOP(Standard Operating Procedure , 标准作业流程)把A怎么做的这个目前的最优实践进行复盘分析 , 形成这个流程的KPI并固化下来让所有人按照这个执行 , 这时候会发现生产效率极大得到提升 , 所有人用10分钟就能完成一个口罩的生产 。 但是 , 改善优化的部分就行不通了 。 按原来KPI的做法结果就是10分钟 , 不可能是5分钟 。 这时候我们可以借助OKR , 比如O是“提升口罩生产效率” , KR是“生产时间从10分钟降低到5分钟” , OKR定完是Task也就是具体的实践过程 , 10个工人去尝试新的生产方法 , 比如D发现他通过某种新的方式能够达成这个OKR , 那么这时候我们形成新的SOP+KPI去管理 , 把生产效率又立马提升到5分钟的水平 。 所以对于劳动密集型业务而言 , 通过SOP+KPI是在已有相对最优实践时提升管理效率的最佳方式 , 改善优化部分通过OKR管理 。
『』OKR和KPI的本质区别
本文插图
图中左边的圆形代表的是知识密集型业务 。 知识密集型业务通过KPI管理效率相对较低 , 如前文所提 , 驱动类KPI为因结果类KPI为果 , KPI定出来意味着对于某个业务流程如何运作达到预期结果是已知的 , 然而知识密集型业务是如何成功运营尚未知的内容 , 用KPI管理自然相悖不科学 。
去年和一家知名互联网企业沟通 , 他们就是这种典型管理悖论的受害者 。 当时他们开展了一项全新的业务 , 每个季度开始都是业务领导和HR来定KPI和行动计划然后让下面去执行(插一句 , 让HR参与定业务KPI在一些情况下很要命 , 中国企业很多的HR是不深入业务端的 , 不少企业打着HRBP的旗号却跟业务人员两壁相峙完全不了解业务运营 , 却要通过KPI指挥业务人员作战并且去评价他们的表现决定之后的奖惩 , 细思极恐 , 确是很多企业的现状 。 当然 , 不是所有企业都是这样 , 在过去几年也见到了很多企业的HR同事非常优秀 , 不仅懂业务 , 并且能够在懂业务的情况下对业务运营提供非常有价值的支持 。 插句题外话 , 更多这里先不展开 。 ) , 季度结束发现他们认为有用的做法没效果 , 又开始拍脑袋定KPI然后又让下面遵照执行······一年过去了 , 这个业务怎么做还没探索出来 。
经常喜欢举SpaceX的例子也是一样 。 当SpaceX还不知道怎么造出可以发射后回收重复利用火箭的时候 , 定KPI的本质就是“你们这些工程师这么做就行了 , 肯定能成功” , 怎么可能?正是因为没有人知道怎么做才去探索这样一个有价值的新业务 。 OKR是这样管理的 , 先明确目标O就是“成功研发可以回收重复利用的火箭” , KR对什么叫做“成功研发”进行标准定义 , 接下来Task层面不做限制 , 给大家充分的空间去探索不同的做法 , 尝试的结果通过OKR的进度进行检验 , 终于在100次尝试后发现OKR达成了 , 我们把这个OKR是怎么达成的做法复盘出来 , 这时候会发现业务性质发生变化了吧?它已经从知识密集型业务转变为劳动密集型业务了 , 那么就能通过SOP+KPI快速复制了 。 回到左边的圆形 , 有一部分叫作流程规范 , 这里更多和任务类KPI相关 。 任务类KPI主要是对于过程实践的知识沉淀与通用标准进行规范 。 比如虽然研发可重复利用火箭这件事是一个知识密集型业务 , 主要通过OKR管理 , 但我们可以设定任务类KPI , 而且任务类KPI往往很关键非常有必要 。 简单举例来说 , 比如在我们Worktile , 所有的活动都是在Teams这个平台上进行管理的 。
『』OKR和KPI的本质区别


推荐阅读