OKR落地常见问题（终）
12. 特区试点
OKR 在具体制订时我们提过方向是由上向下再由下向上的， 也就是先完成公司级 OKR 的梳理，各个部门及负责人再由下向上建立部门级 OKR，个人级 OKR 同理，由下向上承接。然而从整体的实施来看，最理想的 OKR 推行方式应是由上向下的，也就是我们前面所提到的，高层先对OKR的价值有充分的认知，并以身作则， 带领员工推行 OKR。
然而，我们见过一些企业有这样的问题，我们称之为“特区试点”，也就是在实行时并不是由老板主导整个核心管理层参与实施，而是选择某一个部门作为试点先用 OKR，如果这个部门用得不错，那么再逐渐向其他部门推广。
还有一些公司，企业的老板并不了解 OKR，但是下面一些业务单元了解到 OKR，很感兴趣，于是自主地在团队内部开始试用 OKR，有的效果不错有，会反馈到高层，进行大规模的推广，但这种情况在我们接触的几百家企业里少之又少，基本都是各个部门在自己用 OKR 的过程中出现各种问题，各个部门负责人只能通过看很多书或参加很多活动，来找到一些可利用的方法。
“特区试点”这种现象之所以会产生，大多是由于企业老板对 OKR 没有形成充分的价值认知，或者企业的体量太大，选择某一个部门先推行再逐渐向其他业务线扩展，还有企业认为，OKR 只适合特定团队比如研发和市场营销部门等，而传统的人力资源与行政部门等跟 OKR 没什么关系。
特区试点的主要问题在于以下三点。
（1）试点部门目标跑偏。
OKR 的目标设定是由上向下再由下向上的，如果公司级目标没有确定，直接制定部门级目标的话，这个部门级目标缺少更高一层方向的统领，很有可能是跑偏的。很多互联网公司的运营部门经常容易遇到这一问题。
很多互联网公司的老板对于运营部门的管理感到非常头疼，不知道该如何设定他们的部门目标。很多运营部门的目标会设定为“提高产品知名度”，可如果公司今年的目标是“提高顾客满意度”，从父子目标的承接关系上， 我们可以看到这个部门级目标对父目标无法产生有效的贡献，即使这个部门在这个目标的实现上做得很好，对公司来说其实是产生了很大成本的，因为方向完全错误。使不到点上的力气，都是白费力气。
如图 3-13 所示，公司今年是要朝 a 方向走，而某个部门因为不知道要朝这个方向走，以为是要走 d 方向，不仅不能助力实现公司的目标， 反而是在“拖后腿”。选择部门作为试点时，很多公司缺乏更高一级的战略梳理和公司级目标统筹，直接设定目标有可能与公司的整体方向并不契合，造成部门工作只有苦劳，却无法成为功劳。
（2）资源匹配和支持不足。
如在“火急火燎”这一问题中所述，想要成功推行 OKR，CEO 应有充分的价值认知，并在过程中负责引领，对 OKR 予以充分的关注、支持，开始实施前期需要做好 MVS（Mission/ 使命，Vision/ 愿景，Strategy/ 战略）梳理以及引入外部团队的准备，实施方法应当专业且正确，包括各个部门的配合协同，总而言之，需要匹配相当的企业资源，给予充分的支持。 然而仅仅是部门层面实行，老板和核心管理层不参与进来，很难进行资源协调，OKR 便难以顺利推行。
（3）团队协同难以实现。
在 OKR 联结和实施的过程中，团队的协同效果非常明显。一方面，大家会非常清楚各个部门不是孤立的，向上一层的父目标是各个部门共同的努力方向，大家只不过 是根据各自的职能从不同的维度去为这一共同目标的实现作出贡献，或者是在同样的一个目标下参与其所关联的某一个项目或任务， 各司其职，承担不同的工作，但非常清楚彼此之间工作的关联，也知道大家分工协作是为了实现一个共同的目标。
因此彼此之间并不是孤立和对立的，由此对彼此的工作有了更充分的了解，在了解的基础上形成理解，在理解的基础上产生良好的团队协作。在这里分享一个实例，如图 3-14 所示。
Worktile 平台有 IM（Instant Messaging，即时通讯）功能模块， 在这里可以建立不同的群组。有一天公司全员的群组里弹出很多消 息，进去一看，这个群竟然变成了“夸夸群”。这种情形在互联网公司里面想必十分难得。
整件事情其实就是一位销售同事提出的产品需求影响到重要客户的回款，我们的研发总监被催时并没有冷漠拒绝、推脱，而是说会想办法加急处理。因为有 OKR 统领，大家不会认为“这个跟我没关系”，而是看到自己的这一项工作对其他部门的影响以及与公司财务目标之间的联系，所以积极地协同配合。
OKR 让员工看到的不仅仅是自己“一亩三分地”的工作，更多是看到自己这份工作的意义，放到一个团队的全景中，我们与他人是如何分工协作的，我们分工协作要实现的共同目标是什么，它让一个程序员所写的代码与老板今年想要做的那件事之间的关系能够通过由下向上的追溯非常清晰地呈现出来，由此对彼此的工作有了更充分的了解，在了解的基础上形成理解，在理解的基础上产生了良好的团队配合协作。
OKR 如此打破传统的部门壁垒，从此没有“小部门”，只有“大团队”。而如果仅仅在一个部门推行 OKR，一方面其他部门的同事即使想要参与进来但因为对 OKR 不了解，这件事也并不在他们的工作中，从而无法很好地参与协 同；另一方面，其他部门的同事甚至可能会因为这是某一个部门的“任务”，不知道这件事的意义，会说出“这是你们部门的事， 跟我们部门没有关系”这样的话，OKR 在团队协同方面的作用便难以发挥。
另一方面，OKR 的协同来源于 OKR 体系的透明公开。“Those who ask for help gets it.”（得到帮助的人是因为他们主动求助。） 由于 OKR 体系是面向全员透明公开的，任何一个人都可以随时查看公司任何层级、任何人的 OKR，如果他看到某一个他很感兴趣的能够承接的目标，那么就可以自主在下面建立子目标去支持这个目标的实现，或者在这个目标的达成方面提供一些有价值的建议。
在这里也分享一个我们公司的案例。我们公司某一个 OKR 周期的一个公司级 OKR 和财务相关，我们假设这个目标为“达成收支平衡”。有一天，CEO 在他的这个目标下发现了一个非常有意思的子 OKR 如图 3-15 所示。
这个子 OKR 的 O（目标）是“节省不必要的行政支出”，KR（关键结果）是“半瓶水数量为 0”，它的创建人是我们公司负责行政的一位小姑娘。这个小姑娘看到办公室经常会有喝了一半就扔在那儿的矿泉水，从她的职责范围来说，她可以帮忙督促大家改变这种现象，从而降低不必要的行政开支，从这一角度为实现老板的目标作出她的贡献。这一点是我们老板绝对想不到的，并且这一点真的对公司级目标的实现形成了一定的贡献度。这也是协作。
然而，如果看不到公司级目标是什么，这位同事是没有办法为这一目标的实现去思考并制定有意义的子目标的。此外，很多企业的高层管理者 可能认为一些偏传统日常执行类的部门不需要参与 OKR，这也是不对的，如果我们为这些部门保持一个灵活的入口，可能会有一些 意想不到的成果。
大多数企业的部门是以职能进行划分的，员工以职能进行专业分工，而今天组织的绝大部分工作都是需要跨职能部门的团队协作完成的，比如仅仅是产品研发的工作，销售同事能提供非常有价值的客户需求反馈，市场同事能够就市场趋势与竞品现状提出建议， 产品同事负责产品的整体设计，研发同事能够从技术层面为产品的 实现提供支持……
大家的背景与专长不同，能够从不同的角度为目标的实现提供助力。可如果仅在某一个部门实行 OKR，其他部门并不了解，缺乏其他部门的参与，那这个团队其实是在 OKR 的达成上切断了有价值的帮助来源。
综上，由于 OKR“特区试点”缺少更高一级战略目标的统筹， 容易造成试点部门目标的跑偏，在 OKR 实施的资源支持和匹配不足，使 OKR 很难以正确的方式顺利推行，同时由于缺少其他部门的参与协同，无法很好地打破部门壁垒，并通过部门的专业协作产 生更好的工作成果，我们建议在实施时不要采取这样的做法，而是由上向下整体推行。
当然，有一些我们接触到的企业，规模非常大， 并且不同业务线之间的关联度不尽相同，比如我们曾经介入的一家央企集团，下属有十几家分公司，有些分公司之间的业务关联度非常低，那么在实际实施时并不需要共享集团战略，而是有一定的划 分，然而这些都是大方向之下具体实施规划的问题。高层达成一致予以充分的支持，整体向下推行，OKR 实施才能最大程度上取得成功。
以上是我们根据近 200 家企业的服务经验以及与上百家实施 OKR 的企业在接触交流过程中总结出来的 OKR 实施常见问题与解决思路。
OKR 的实施是个大工程，提前认识到陷阱在哪里，做好准备，能够帮助企业减少 OKR 的实施成本，以便顺利地导入、运行 OKR，在 OKR 体系的支持下实现卓越的绩效提升。
想了解其他问题可戳以下链接：
【借助专业工具 Worktile 管理企业OKR
【OKR咨询：
