我的产品发布了：CEO数字分身，让CEO分身有术，有意者联系。
此篇文章介绍了公司在评价指标建设过程中会遇到的一些情况，建议收藏
几年前我在B站做总监，突然有一天部门老大开始“抽风”，他要求我们去做一套部门的衡量指标出来，于是整个团队陷入疲于奔命之中。
后续在一家独角兽公司做部门一号位，终于CEO问出了类似问题：产研团队对于公司的意义是什么，如何评价产出。系列问题接踵而至：
产品团队对于公司的意义是什么； 研发团队对于公司的意义又是什么； 如何评价产出； 这里再进一步，各个技术栈团队的产出如何评价；
虽然当时的真实反应是：艹！又要做一堆无效的作业去应付这莫名其妙的疑问。但如果细细思考，这里却触发了本质问题，以难以衡量的技术团队为例：
公司的技术团队与外包团队有何不同，与其他技术团队的差异是什么，如何评价优劣
进一步，公司应该如何将技术部门这个黑盒打开，如何评价各个单元组的产出。
可以主观的定性，却需要客观科学的定量，于是便需要建立数据指标。
然后在具体实施落地的时候，很多同学不容易理解数据指标是什么，认为“数据指标”在瞎折腾，于是内心抵制。这里跟大家强调下，数据指标至少有两个作用：
想不出来数据指标，说明是对这块事（团队要做的事）没有一个清晰的认知； 想得清楚数据指标，却做不出来，说明对整个团队缺少掌控，不能推动落地；
不能建立数据指标，根本没法做数据驱动，看似简单的数据指标把团队是否在裸奔指了出来，是因为惯性还是被动向前跑，一目了然。
所以什么是数据指标：
数据：数据是指对客观事件进行记录并可以鉴别的符号，是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。它是可识别的、抽象的符号。
指标：衡量目标的参数，预期中打算达到的指数、规格、标准，一般用数据表示。
——来源《百度百科》
数据是对事物结果的归纳，指标是衡量目标的方法。
组合一下，数据指标就是可以对结果进行归纳的一种目标衡量方式。
综上，数据指标其实是想真实反应我们的团队是什么状态，我们做的事是什么状态的一个指向标。究其原因，组织执行力、产品健康度需要某种程度的量化，数据指标的作用从更宏观的角度看是这样的：
数据指标提供了航行方向，北极星的作用，这里再来一张图，看看数据指标在全局中的角色：
其中牵引指标就对应我们的业务数据指标，牵引指标不健康的时候可以预警是不是团队方向跟目标走偏了，Leader要考虑调整目标还是修正团队方向。
为什么要建立指标体系？
1. 统一衡量业务好坏的标准
传统企业或者小公司可能不会有数据指标体系的概念，也不会下大工夫来建设数据指标体系，但却并不能完全脱离，或多或少都会涉及数据指标，只是不够全面、不成体系。
一般衡量业务好坏主要看财务指标，例如收入、毛利率、净利率等。对于一些创新类、探索类的业务可能会关注用户量、GMV、转化率等。不管业务处在什么阶段，我们都需要一些数据指标能够对其进行衡量。
没有指标对业务进行系统衡量，我们就无法把控业务发展，无法对业务质量进行衡量，无法看清楚业务发展是否到达阶段性目标。
而且某些复杂的业务，单一数据指标衡量很可能片面化，需要搭建系统的指标体系，才能全面衡量业务发展情况，促进业务有序增长。
当组织有全面、统一数据指标体系时，可以统一度量衡，减少转化、翻译（口径解释）等工作，降低组织内的沟通成本。
2. 指导工作方向
产品的研发和运营其实很依赖数据支持，数据指标不仅仅能帮助大家看到业务发展的结果，还能帮助大家看清产品研发和运营的过程，能够及时调整策略，更万无一失的达到目标。
对于互联网公司，研发和运营等部门是促进公司发展的核心组织，通过完善的数据指标体系和数据分析，来有效聚焦工作目标、指导成员工作。
3. 数据分析的基础
指标体系是数据分析体系的第一步，数据分析本质就是根据数据指标的变化寻找业务问题、预测业务结果，数据分析工作在数据指标体系的指引下才有意义。
数据分析体系的最终目的是帮助组织在内部建设一套可运行的信息反馈机制，能够持续的发现问题、预警风险，帮助决策者能够做到谋定而后动，知止而有得。
举个例子，我们衡量一个公众号前期的运营情况，可以用一个核心指标——昨日新增用户数。
如果昨天新增用户数是1000，这个猛然一看感觉这个公众号运营的还不错。
但是再加个前日新增用户数这个指标呢，如果前日新增用数是2000呢，那么新增用户数直接是下降了50%了。
我们加了一个比较的指标，让我们对这个业务的发展认识就完全不一样了。如果我们加入更多的指标，比如阅读量、打开率等等，还会有更多的认识。
上面我们不断增加指标的过程，也就是在梳理业务指标体系的过程，一个数据指标是没有办法衡量业务的发展，但是一个指标体系就能把问题说的清晰明白。
一个好的指标体系对于组织而言，可以是一把统一沟通语言的尺子，可以是一台统一方向的司南，可以是一个持续发现问题、预警风险的智库
什么阶段建设合适
指标体系的建设和业务发展相辅相成，当数据指标体系比较完善时，业务应该也是比较成熟了。
如果业务才刚刚开始，就要建成完善的指标体系是不切实际的。
因为业务是不断变化的，运营方式也会不断调整，大部分的数据指标都需要从业务结果和业务运营过程中去提炼总结。
只有当业务比较成熟、运营方式比较稳定时，我们的指标体系才能初见成效，才能有效的运转起来。
但并不是业务不成熟时，除了一些可能贯穿整个业务阶段的数据指标外，在业务的各个阶段应该去提炼每个阶段应该关注的数据指标，不断的迭代，随着业务变化而变化。
比如收入、利润率等财务类的指标应该是业务整个发展阶段都应该关注的，除此之外，在业务发展前期我们可能更会关注新增用户量、转化率、拉新成本等。
而在业务发展后期，我们可能更加关注活跃率、留存率、运营效率等指标。
数据指标体系不是一日建成的罗马，需要持续不断的投入，在业务发展的不同阶段有不同的小目标，当业务稳定时，这些小目标就汇聚成了最终的大目标。
所以我们应该在业务一开始的阶段就要投入，不仅是为业务阶段性的目标提供帮助，也是为最终的数据指标体系添砖加瓦。
但真实的情况可能不是这么回事...
建设的困难
最近在推广CEO数字分身的时候，与各个企业的交流过程汇中，有几个词出现频率极高：指标、考核指标、健康参数、业财一致、业财一体...
其实他们都在描述同一个词语：数据指标。
似乎，每个老板对于指标体系的建设都极其重视，但实际看下来又不是那么回事，因为团队数据建设不能说很差，只能说几乎没有...
所以，数据指标跟体检指标一样，我们每个人都很关注自己的身体，我们关注数据指标的前提是：身体出问题了。
同理：在企业出问题之前，其大家都是口头重视数据指标；
而在真的出问题后，又会因为数据建设不是一朝一夕的事情，缓不济急也就指望不上；
最后，团队问题积重难返，越看数据越糟心，反而不想看到数据指标了...
综上，数据指标的作用是真实的反应团队状态，告诉你可能哪里出问题了，暴露问题、引起重视才是数据指标的核心作用。
这也对管理层提出了另一个要求：你必须是一个自省型团队，至少拥有面对真相的勇气，如果看不到问题、或者对问题视而不见、或者隐藏问题，那数据指标是真的毫无用处了...
如果你想要的是一张好看的图表，告诉大家团队事业“蒸蒸日上”了，那数据指标确实不能满足这个要求，多招两个女秘书可能更合适。
当然，这是玩笑话，那么为什么数据指标总是在口头上重要呢？
数据指标难以建立
如果要思考一件事为什么不能成功，一定要从《经济学原理》找答案。
ROI
指标体系建设更像一个“拼图”游戏，投入得越多，能看到的也就越清晰，收益越大也就越大，但只有在最后一块拼图补足的那一刻，他才会爆发出最大的力量。
这意味着，初期的投入很容易打水漂，很多创业团队会因为生存问题，被迫的“急功近利”，他们没有那么多资源用来做指标体系建设。
因为初期来看，ROI确实太低了...
企业需要权衡数据指标建设与其他重要项目的资源分配。
特别是在资源有限的情况下，企业可能优先选择那些短期内能带来直接收益的项目，而不是长期的数据指标建设。
边际效用递减
如前所述，数据体系建设初期看不到效果，中期投入资源可能会带来显著的改进和效益。
然而，随着投入的增加，改进的幅度可能会逐渐减少，这可能导致企业对进一步投入的意愿降低。
并且，一些数据能带来的预警，可能复盘两次也能达到同样的效果，而投入资源做坦诚文化、复盘自省机制建设，似乎比指标体系建设便宜的多。
上下冲突
指标体系建设，还有个天然的困局：不同利益相关者的激励机制不一致，导致行为不协调。
员工和管理层在数据指标建设中的激励机制可能不一致。
例如，员工可能担心数据指标会用于绩效考核，从而影响他们的利益，导致数据的真实度和可靠性受到影响。
而一线员工掌握更多关于实际操作和业务流程的信息，管理层则需要依赖数据来做出决策。
由于信息不对称，数据指标的准确性和完整性可能受到影响。
路径依赖：
因为指标体系建设是一件成本较高，且容易失败的事情，所以管理层很容易形成路径依赖。
如果企业过去没有建立完善的数据指标体系，或者在过去的尝试中失败过，管理层可能会对重新投入数据指标建设持怀疑态度，导致缺乏动力进行长期投入。
总结
综上，可以看到，数据指标体系建设，是一件成本较高又容易失败，并且初期不容易看到效果的项目。
站在管理层角度，他们会有以下考虑：
数据指标不总是问题暴露的唯一手段； 数据指标的建设成本； 过度依赖数据指标的风险； 数据指标可能导致短视行为； 数据的准确性和解读问题；
接下来，我们从宏观到微观，来实际看看指标体系该如何建设。
案例·指标体系全案设计
指标系统建设是一件成本较高的项目；而指标本身也是一件有点晦涩的名词，他就像空气一样：你能真实感受，却不能妥善定义。
难以定义就难以理解，难以理解，建设起来当然就容易胡子眉毛一把抓。
比如，产研团队的指标系统应该是什么样的、HR部门的指标系统又应该是什么样的？
团队指标与项目指标
首先，为一个团队建立指标体系要做合适的拆分，不要将团队指标融入到项目指标，将项目指标错误提升为团队指标，这里乱了指标体系一定会做得稀碎。
以产研团队为例，他们多数的工作是完成项目，所以每个类型的项目应该有自己的考核指标。
指标具体到项目、具体到任务，我们就能清晰知道指标的完成情况。
而每个项目也有所差异，比如：常规项目关注结果、关注数字，创新项目关注过程、关注时间。
一个部门会有很多项目，所以部门不应该以项目维度的考核指标去衡量。
那么应该用什么指标去衡量一个团队呢？核心还是两个大指标：
效率，项目过程中效率是不是高，项目过程中产生了多少项目耗损； 质量，项目产生的过程类缺陷是不是多，线上的事故是不是多；
接下来以技术部门为例，继续探讨。
技术部门
技术与HR部门都属于后台部门，逻辑上就是不断的服务其他团队，他们的部门效率，指标可以有需求承接率。
比如：业务方提出10个需求，承接了几个，进一步也可以优化为平均承接时长，或者响应时长。
在执行上，可以有一个业务需求池，各个业务方直接往里面丢需求即可，研发团队每天对需求池中的需求进行承接，进行处理。
需求承接后，过程量是什么：
开了几次会，每次会议的结论是什么； 最终的结果是什么，产出了什么产品方案，技术方案； 业务方对于整体方案，反馈是什么； 如果反馈没问题，那么就应该进入具体研发阶段；
同样，进入整体实施阶段：
成立项目组； 将一个大的项目分成了若干个重要节点； 将每个节点分成若干任务，将任务分给对应的人； 对应员工的任务实际完成情况；
这里，每个阶段都可以思考耗时是否合理，因为多数资源会投入到任务执行，到这里对一线Leader的要求就出现了：
一线Leader需要对任务进行基本的定价，一个10小时的任务，最终员工到底花了多少小时，是快了还是慢了，快了要不要点赞，慢了要不要校准？
从一个大的项目，正常的流转，到其被分析、被分解、被执行、被监督、最终被完成，所有都是可监控的，所有这一切集中起来，便是整体项目的效率体现，项目累加起来，就是整个部门的效率体现。
而这个效率指标与项目本身要考核的指标可以是没关系的，这种通用的指标，便是部门的指标，部门可以据此优化团队流程、激励机制以提升效率。
质量指标更简单，就是每个需要交接节点的质量判断即可，需求到研发，需求文档的质量，研发到测试，测试到上线的bug数，最终上线产生的事故数。
如果部门效率高质量也好，那么这个部门一定是优秀的，至于什么创新性之类的“另类”指标，不应该作为常规指标，可以事后对项目复盘时候，看哪些项目是创新项目，或者哪些常规项目有一些创新点，记录起来即可。
其次，如果对技术侧自动化、工具化、信息输入有一定要求，也可以以项目方式运行，比如设立一个竞品分析、行业研究指标，要求每周必须产出多少分享，每个分享又有一定评分机制，团队每个周期信息输入必须达到多少积分等
最后，如果公司有对机制执行服从度的要求，比如必须写日报、周报之类的，都可以作为项目运行，而后直接收集为一个大表，事实上整个部门衡量指标，本身就是一个项目。
这里给一个实际执行中用到的表格：
人力部门
人力部门也属于中后台部门，站在部门指标系统层面，从效率指标上也是对各部门的需求响应度执行的如何，特别是招聘的响应度。
但是招聘这个事情参与方太多，HR可以作为监督者去推动业务部门进行面试，所以指标下给他们是对的，比如要求多少HR安排后，必须多少小时内处理，不处理，可以认为团队执行力有问题。
所谓令行禁止，上下游有个工作交接的过程，只要是认可的工作交接，我设置了任务，那么你就得给到结果，给不到结果肯定是执行力有问题，那么就应该被校准、被复盘。
以面试为例，只要安排了任务，就算面试官没时间，那也应该拜托其他人帮他做面试，完成任务，这样团队才能正常的运行下去。
细化过程指标的意义
可以看到，在做部门指标设计的时候，我们是做得很细的：
从团队与团队之间的交接； 到团队内各个动作的执行；
我们会想方设法的将一个整体的，不好评估的项目，拆分成很多小的、可被评估的动作，因为能被评估就能被优化，否则就算你有很多自动化的手段，也不知到底哪里是最大卡点，更别谈从何入手了。
比如，技术侧执行明细表格中，如果发现技术侧经常在测试环节耗时巨大，深入了解发现是测试环境经常发生冲突所致，这个时候投入资源做基建就变得迫在眉睫了；
又比如，HR处理招聘工作时候，在简历导入一块效率极其低下，原来是公司没有简历库（内部招聘系统），需要从各个系统将一些基础信息录入，而这种动作对于技术来说，其实是分分钟的事情...
数据指标在于暴露问题，问题一旦暴露可以很快得到解决。接下来介绍一个常见方法论。
OSM模型
理想的指标体系，其实是比较“性感”的，他希望有一个北极星指标，几个关键一级指标，每个一级指标带几个核心二级指标：
这是一个经典的总分结构，举个销售团队的例子：
二级指标加总，便是一级指标，一级指标通过一个算法，便得到了北极星指标。
当然，这个是比较理想的情况，因为指标之间不会是简单的加总工作，比如通过一级指标之间的关系，得到的算法是很不稳定的。
行业里面也有一些成熟的方法论，最被大家熟知的就是OKR体系，但多数公司用得不是太好。
这里，给大家介绍一个与OKR类似的方法论：OSM（Object，Strategy，Measure）模型。
Object对应着我们的业务或者说项目的目标，要设定正确的目标，需要对业务/项目有足够的熟悉度。
确定项目目标后，便需要在目标基础上进行路径拆解，也就是我们要实现这个目标，需要什么样的策略（Strategy）。
最后，为每个执行策略设定一个可衡量的评价指标（Measure）。
可以看到，OSM与OKR非常类似，可以说完全是一张皮，甚至过程中使用的方法论都会趋同，如：
SWOT分析； SMART原则； MECE模型；
这里以之前人力部门招聘为例给一个案例。
招聘项目
Object（目标）
在3个月内，以最低成本、最高效率满足业务部门的用人需求，缩短招聘周期至30天以内。
Strategy（策略）
需求提出，使用标准化需求表单，明确职位需求和职责。需求审批流程通过系统自动化，确保快速响应。 人才画像，建立标准化的人才画像模板，包含技能、经验、教育背景等信息。定期与业务部门沟通，更新行业和岗位的市场情况。 职位描述（JD），制定JD模板，确保信息完整、准确。由专业文案人员统一撰写JD，确保标准化。 简历筛选，使用智能简历筛选工具，提高筛选效率。建立简历筛选标准和评分系统，确保筛选准确性。 简历推荐，标准化简历推荐流程，确保及时、准确推荐。定期与业务部门沟通，反馈和调整简历筛选标准。 面试流程，制定面试流程标准，确保每个环节高效运作。提供面试培训，提升面试官专业性。 面试反馈，建立面试反馈机制，确保及时反馈。制定反馈标准，确保反馈信息的准确性和完整性。 薪酬谈判，制定薪酬谈判流程和标准，提高谈判成功率。提供谈判培训，提升HR谈判能力。
Measure（衡量指标）
需求响应时间：平均2天以内。 需求准确率：达到95%。 人才画像准确率：达到90%。 人才画像更新频率：每季度一次。 JD撰写时间：平均2天以内。 JD质量评分：业务部门满意度达到90%。 简历筛选时间：每份简历平均1小时以内。 简历筛选准确率：推荐简历的面试通过率达到80%。 简历推荐时间：平均1天以内。 简历推荐成功率：达到80%。 面试安排时间：每轮面试平均2天以内。 面试过程合规率：达到95%。 反馈时间：面试结束后1天以内。 反馈完整性：达到90%。 谈判成功率：达到85%。 谈判时间：平均3天以内。
结语
数据指标体系的建设，就像企业的“健康体检”，其目的在于暴露问题，引起重视。
如前所述，数据指标的核心作用在于真实反映团队状态，帮助管理层及时发现并解决问题。然而，数据指标建设的难度和成本往往令企业望而却步。
我们可以从一些经典案例学习指标系统的重要性：美团骑手。
美团在其初期业务扩展过程中，通过构建精细化的运营数据指标体系，成功实现了平台的高效运营。美团的成功很大程度上归功于对骑手送货效率的重视和监控。
美团通过订单处理时间、骑手配送效率等关键指标，实时监控平台的运营状况。
当某个骑手的配送效率指标出现异常时，管理层能够迅速定位问题，找到原因并采取措施，确保了服务质量的稳定和用户体验的提升。
通过这样的精细化管理，美团不仅提高了配送效率，还增强了客户满意度，进而在竞争激烈的外卖市场中占据了有利位置。
数据指标不仅帮助企业实时了解运营状况，还能预警潜在问题，促使企业及时调整策略，避免更大损失。正是通过对数据的敏锐洞察和快速反应，美团得以持续优化其业务流程，保持市场竞争力。
管理大师彼得·德鲁克曾说：“你无法管理你无法衡量的东西。”
数据指标正是让我们得以衡量和管理的工具。只有那些愿意直面问题、持续改进的企业，才能在激烈的市场竞争中立于不败之地。
