指标设计与规范化要解决的问题是：把经营目标组织成相互关联、能够指导行动、且业务含义与实际计算一致的衡量规则。
只有几个总量，往往无法解释变化；收集几百个指标，也未必形成体系。需要同时回答"应该观察什么"和"已有数字究竟代表什么"。
《指标体系与指标平台：方法与实践》第2章将整体思路分为自上而下的指标拆解、自下而上的指标收集，再以全局框架组织。本文沿这一原文结构推导，示例与检查项为教学归纳。
一、自上而下：从经营目标确定观察方向
企业先明确希望实现什么，以及为用户提供什么价值，再选择能够代表成功方向的核心衡量指标。书中以北极星指标承接这一作用，并讨论产品类型、发展阶段和战略目标对选择的影响。
核心指标确定后，还需要拆到更容易理解和执行的业务目标。否则，"提高销售额"只是方向，团队仍不知道应改善哪个环节。
例如，在统计范围一致、支付订单数非零时，支付金额=支付订单数×支付客单价。这种算术拆解帮助区分数量变化和平均金额变化；范围改变或分母不同，等式就可能不成立。
另一类拆解来自业务过程与管理判断，例如从获客、接待、成交寻找可改善环节。它需要来源依据和业务验证，不能把画出的关系自动当成因果证明。
二、从目标走向策略，再设计过程指标
结果变化告诉我们发生了什么，过程指标帮助观察具体措施是否得到执行及是否产生预期信号。
原书区分指标拆解与过程指标设计：前者侧重目标，后者侧重执行，并在过程指标设计中介绍OSM模型。它强调，不能跳过目标细化，直接从遥远的北极星指标给出空泛策略。
例如，目标是减少支付后取消，策略可能是改善缺货告知或缩短等待。需要观察缺货通知、等待时长和取消，而不是只重复统计总销售额。
过程指标应对应可采取的动作，也要检查动作是否伤害其他结果。过程改善与最终收益之间仍可能存在外部因素，不能仅凭趋势同时变化断言措施有效。
三、自下而上：收集已有指标，查清实际含义
自上而下设计完毕，还需要面对现有报表和业务节点。已有指标包含历史经验，也可能包含同名不同义、名称与实现不一致等问题。
原书指出两条收集路径：现有报表，以及业务流程节点监控。对口径不明的历史指标，可以依据业务重新明确标准，也可能需要读代码还原历史逻辑。
读代码用于解释现状，不能单独决定未来业务规则。若业务决定采用新定义，还要处理旧报表、历史结果和使用方迁移，而不是把旧代码直接宣布为统一标准。
这一环节的产物应能对应"名称、业务含义、实际计算和使用者"。解释不清的指标先标记待核实，不直接作为公共标准推广。
四、规范化定义：让名称、含义与实现相互一致
原书列出的定义内容包括指标命名、业务口径信息、技术口径、业务负责人和安全等级。规范化需要处理这些内容之间的一致性。
短例子：某订单支付135元，后续退款45元。支付发生额135元和截至观察日净支付额90元可以同时存在，但应分别命名，并说明对象、事件和时间规则。
对于相同业务口径，应统一名称与技术定义；对于确实服务不同用途、无法合并的口径，书中建议以不同指标区分。统一不等于强迫所有人只看一个数字。
将定义映射到来源字段、状态、关联和计算，再用小样例核对。若定义与SQL对不上，先定位是业务规则缺失、来源不足，还是实现错误。
五、放进全局框架，保留边界和责任
指标逐个定义后，还要按业务关系和领域组织，连接结果与过程，避免部门各自形成无法对齐的清单。
框架应帮助找到同类指标及其差异，也应说明来源、负责人和变更影响。需要多少层级取决于业务复杂度，不能机械复制一棵指标树。
完成标准是：核心目标能找到对应指标；关键行动有可观察信号；同名指标含义与计算可核对；不同口径的关系能够解释。
快速复习
经营目标 → 核心指标与目标拆解 → 策略及过程指标 → 现有指标收集 → 规范化定义 → 全局组织。
关键反例：把支付额和退款后净额都叫"销售额"，即使各自SQL正确，也没有形成共同的衡量规则。
原书入口与边界
《指标体系与指标平台：方法与实践》第2章：2.1---2.3书内53---66页、PDF75---88页；2.4书内67---69页、PDF89---91页；2.6从书内73页、PDF95页起。本文重点核对了设计思路、自上而下流程、过程指标与口径规范。
本文的等式使用条件、短案例、SQL核对与迁移检查属于应用解释，不是原书逐字步骤；指标拆解也不替代因果评估。