“数据度量”能力的薄弱，反映的是企业对精细化管理能力的需要。
正如前文所言，传统企业经营模式是基于会计方法的“成本收益”模型；在生存线上挣扎的小型企业，其现金流的流转速率决定了盈利和生死，投入产出的逻辑也极其简单；而组织越强，其投资的“回报时间跨度”与“收益间接路径”也就会越来越长，也就是企业的投资策略（所以投资策略也是根据企业的发展阶段作调整的）。
随着投资策略复杂度的上升，相应的成本核算、追踪调整等行为的复杂度也上升，这就是传统企业做大后，管理复杂度上升的根本来源。
求诸于“数据度量体系”，其诱因可能比较多样，比如小型企业步入快速发展的高速路，以前的KPI考核方式不足以覆盖所有角色的工作内容了；又或者传统企业做产品制改革，需要一个管理抓手来统一衡量和评价不同产品团队的工作质量。
但它们在解决的问题上都有着本质的共性，那就是“明确的人力成本，与不确定性的产出结果之间的矛盾”。
这就导致企业在设计和使用“度量体系”时，很容易陷入“用看似符合逻辑的指标驱动团队间竞争”的误区。这种传统赛马式管理思维并不能说完全被历史淘汰，但它的使用场景确实也是越来越局限的：对已经非常标准化、体系化、产业化的业务来说这种管理方式是适合的。
但从前面讨论到企业本身真正要解决的问题角度看，这种思路明显是本末倒置的。不仅对企业来说，没有帮助让产出结果的价值更清晰；对团队成员来说，内卷式的工作氛围也非常不友好，南辕北辙的指标更是会极大地降低工作效率；更有甚者，去设定和执行评价标准的人，会凭空获得与其岗位设置不对等的权利，容易滋生腐败和大企业病。
所以企业更需要的是，“目标导向的迭代滚动式指标体系”。目标自上而下从企业战略拆解出来，并基于此指导管理方向和方式，但实际指标的选择，则是自下而上的，基于数字化业务模式、用户行为路径、关键标准化可采集数据从团队中试错、迭代而来的。
目前市面上需求比较旺盛的指标体系有：“研发效能指标体系”、“用户体验/服务体验度量指标体系”、“运营增长指标体系”等等。它们分别反映了企业战略中典型的“研发效能”、“用户/客户满意度”、“业务增长”等管理目标。
指标体系并非一蹴而就，且如本书第一章中“数据是新型货币”所讨论到的，指标体系也远非终极目标，数字型企业还需要将之与自身的财务结算体系对接起来。
所以本着不要好高骛远的落地原则，可以把上述诸多庞大的体系作为愿景，从“数据度量初始化”开始，从一线团队的实际工作中逐渐积累被验证的指标和使用方式。
接下来就用最为常见的业务运营增长作为案例，演示如何进行初始化，并将指标管理沉淀到团队运作中去：
案例背景：
H企业是国内一家综合性保险金融服务公司，近两年随着互联网保险等行业数字能力提升，面临着来自竞争对手、供应商对接上越来越大的压力。
为了扭转这个局势，企业领导希望从逐步构建企业内部的专业化产品经理开始，其中包括对现有业务人员、技术需求分析师等产品经理能力培训，以达到专业产品经理的要求。
希望通过产品能力的培养，逐步完善产品工作的体系和机制（如OKR、360评价、管理体系等）。并最终通过对产品经理、运营等角色责权利的明确，补上企业在数字能力上布局的缺失、保证已存在优势的数字化业务的进一步发展、让团队能够自运作起来。
初始化走查：
H企业在过去有一项2B业务一直是其优势所在，业绩表现亮眼，但随着竞争对手的出现，且产品疏于维护和响应，导致不少的存量客户转移。
站在业务团队的视角看，业务本身没有变化，存量客户的流失明显是产品体验没跟上，这属于技术团队的职责范畴。
站在技术团队的视角看，客户拜访、反馈意见收集、满意度提升都是业务团队的职责，数字产品只是业务中的一小部分，且缺乏业务团队明确的需求传递，技术团队很难根据客户需要对产品进行有针对性地优化。
很多人首先想到的解决方案就是“组织架构调整”，然而首先该企业的国企背景使得组织架构调整的难度很大，其次不同角色的归属和绩效评定等问题不经过一段时间的磨合，还是难以避免上述问题的出现。
H企业希望能找到一个短期就见效的方法，预防其它数字产品团队也发生类似的问题。所以该方法不仅要帮业务和技术团队更好地沟通需求，还要能识别客户的异常动向，给团队进行响应的空间和时间窗口。
虽然存在如此多的约束和要求，但好在H企业数字基础设施还算较为齐备，很多维度的数据都能被找到；且由于行业供应链特点，业务本身数字化程度也较高；
同时，企业内部也有专门通过数据核算负责考核的PA部门，有人、有数据也有技术支撑，所以该企业打算通过建立更完善的数据度量机制，来牵引团队协作和完成工作方法的转变。
然而难点在于，用纯粹的业务/财务数据核算，更多的压力自然而然地会作用在业务团队身上，这也是过去一直难以克服的问题。
所以，“作用在技术团队身上的数据是什么？如何将这些数据与业务数据进行关联？又应该用什么样的方式进行管理才能驱动改变发生？”这些问题的答案就成了决定该转型成败的关键。
案例分析：
H企业打算用“数据度量”的方式解决问题，确实是见效快且更有针对性的策略，但需要赋能传统PA部门，以数字化思维来设计新的考核办法：
从传统PA部门进行的业务数据分析上看，主要考核的数据依次为：“资料登记完成比例”、“开户比例”和“产品购买比例”，因为从业务逻辑出发，这三个数据分别代表着业务完成的三个阶段“资料登记”、“开户”和“完成购买”。
结合这样的逻辑，表现在数字产品上也有类似的阶段，有些一致，有些也会发生变化，比如“开户”，在数字化业务上由“App端外开户数”和“App端内开户数两者组成”。
当然，除此之外，还需要融入使用数字产品进行业务必要的关键操作，如“下载App”、“打开App”、“注册App”、“登陆账户”等其它关键数据。
以上数据就构成了一个基本的漏斗模型（由于需要对案例脱敏，这里只作为案例展示，实际上漏斗的层级会更多）。
完成这些漏斗阶段的设计，就是将业务团队与技术团队目标聚拢的主要方式之一。
通过对漏斗阶段的精细化设计，团队不是为某一项或几项数据负责，而是为“客户进行业务完整的流程和体验”负责，虽然不同角色在流程中的不同环节发挥作用，但已经一定程度地实现将各角色的目光从其负责的“特定环节”上转移到了“整体服务”。
紧接着，还需要找到客户属性和行为的相关数据，如“年龄”、“地区”（自然属性数据）和“访问频次”、“停留时常”（行为数据），与漏斗阶段的相关性，并对之设立假设。
比如从数据上发现：“三线城市”地区里“30-35岁”中“杂货店老板”，会在“工作日”某时间段完成“端外开户”的数量比较多。
于是，“市场同事”在端外投放广告时，会针对性地形成投放策略。
又比如，在“下载App”后并“完成注册”的“30天”内，“打开App”频率超过“20次“的用户群体，完成“产品购买”的人数最多。
那么，“运营”和“产品经理”在App活动引导、操作路径优化时，就会根据此假设设计策略。
不同角色共同以“提升各漏斗阶段转化率”为目标，根据不同维度“用户数据”对比表现出的差异性提出“优化假设”，最终通过活动或产品功能设计对假设进行验证并获得数据反馈，进行和逐步迭代完成数据度量体系的设计。
通过提出假设，针对用户行为数据改变进行业务策略调整（无论是活动还是产品功能变化），可以看作是完成一个业务上的“预测环”；之后对漏斗阶段结果数据的收集，并据此验证之前所提出假设是否为真，可以看作是对预测行为作出的“反馈环”。
“预测环”的周期取决于产品/运营迭代速度，“反馈环”的周期取决于企业数据采集和价值结算能力。
在这个过程里，不但可以通过数据异常提前发现客户的变化，更关键的是不同角色通过对用户数据表现的探讨，对他们的工作内容和要求进行了趋同。（用数据产生对话，识别并追踪数据表现的差异性。）
所以对应的管理方法，也不仅仅是对不同“漏斗阶段”转化率的考核，还需要在日常的工作审视、汇报里考察团队：根据“什么样的数据表现”进行了“什么假设”，以及最终的“验证结果”导致了“漏斗转化率”什么样的变化。
只有管理办法有了对应的转变，才能保证团队持续地维持在前文描述的工作状态中；那么数字化有没有办法矫正“管理方式”呢？答案无疑是肯定的，不过这部分内容我们在本章“持续建设的数字平台”部分再详细讨论。
初始化的成功标准和影响：
完成“数据度量初始化”，不仅需要“迭代完成度量体系”的协作方法，也同样需要牵引、保证协作方式的管理办法。
度量指标的数据变化反映客户实时动态，促使业务与技术之间频繁发生有效沟通；业务提的需求，技术实现的结果，最终表现为指标数据结果上的变化；企业管理者不仅要对指标提出要求，更需要懂得用什么方式协调矫正团队协作过程，才能保证度量初始化的有效实现。
“业务数字初始化”的目标是通过改变人和人之间的协作方式强化业务优势和能力，“数据采集初始化”则是更合理的工作方式结合数字能力产生的结果，那么“数据度量初始化”则是为团队成员和管理者提供优化和矫正团队运作的工具。
结合所“能采集到的数据”、“业务逻辑”、“数字产品操作路径”构成企业每个业务自身的“迭代完成的度量体系”；随着这种模式的深入人心，各团队可以逐渐摆脱管理者监督的需要，具备自组织的能力。
而不同业务完成“度量体系”对数据能力要求的共性（如埋点能力、快速报表生成能力）、反映客户体验要求的相似指标（如任务完成成功率、页面响应速度），又共同构成了对企业整体数字化能力的要求；企业在这些数字能力上的演进，又进一步降低了团队自组织的门槛，这就形成了向数字型企业做转型的良性循环，这点笔者会在本章后续内容中进一步展开讨论。
