为全公司的数据定好负责人和管理方式

## 确定公司管理数据的目的和范围 将数据视为需要管理的业务资产，而不是系统的副产品。首先说明组织为什么管理数据、哪些成果至关重要，以及职责范围从何处开始、到何处结束。 - 明确运营模型必须支持的决策、服务、风险和义务。 - 定义范围内的数据域、业务部门、平台和生命周期阶段。 - 区分战略治理、交付工作和日常运营，使问责关系清晰可见。 - 记录假设、排除项、依赖关系和未解决的问题。 - 对能力、活动、角色、交付物、控制措施和指标使用一致的术语。 - 当证据仅限于某个团队、系统或样本时，不得声称覆盖整个企业。 ## 为每类数据指定决策人和日常负责人 明确共同责任。业务代表继续对数据含义、可接受用途和优先级负责，而技术专业人员继续对可靠实施和妥善保管负责。 - 指定一名高层发起人，负责授权、资金和跨职能升级。 - 为数据域、政策、服务和主要控制措施指定问责所有者。 - 明确业务管护职责，包括定义、质量期望和问题决策。 - 明确技术管护职责，包括架构、访问、运营、血缘和实施。 - 记录由谁提出、审查、批准、实施、监控，以及需要通知谁。 - 提供解决责任空缺、政策冲突和风险接受问题的途径。 - 当组织重组、平台、法规或关键用途发生变化时，重新审查职责分配。 ## 列出公司需要覆盖的全部数据工作 在选择项目或工具之前创建能力图。根据长期责任组织工作，而不是依据当前组织结构图或供应商的产品边界。 - 涵盖战略与治理、架构、解决方案交付和数据运营。 - 包括安全、隐私、连续性、保留和适当访问。 - 包括共享参考数据、主数据、元数据、定义和血缘。 - 包括分析数据交付、报告支持、文档、记录和内容。 - 包括数据质量定义、衡量、问题管理和改进。 - 显示各项能力之间的依赖关系和服务提供关系。 - 保留重要的重叠部分，但为每项决策指定一名问责所有者。 ## 用同一组问题描述每项数据工作 使用相同的描述维度说明每项能力，以便比较缺口和依赖关系，同时不强迫所有能力采用完全相同的流程。 - 成果与原则：所追求的价值，以及指导决策的规则。 - 活动：日常工作、项目工作、控制措施和决策点。 - 交付物：必需的记录、模型、政策、服务、数据集和证据。 - 角色与责任：承担问责、负责执行、接受咨询和需要知情的各方。 - 实践与程序：批准的方法、约定、例外和升级路径。 - 技术与标准：所需的工具类别、协议、互操作性和选择标准。 - 组织与文化：技能、激励、资金、权限、协作和变革准备度。 - 只有在说明理由后才能将某个维度标为不适用；不得默默省略。 ## 依据实际记录而不是口碑给现状打分 使用可验证的证据评估当前能力，而不能依据声誉或工具所有权。对整个能力组合应用一套有记录的量表，并将缺少证据与表现薄弱区分开来。 - 审查政策、责任记录、模型、目录、工作流、控制措施和服务记录。 - 抽取运营证据样本，例如事件、访问审查、质量结果、血缘和变更历史。 - 访谈业务和技术参与者，以检验有记录的实践是否真正得到采用。 - 分别评估能力、采用程度、控制有效性和成果表现。 - 记录每项发现的证据、置信度、范围、例外和日期。 - 识别根本原因和依赖关系，而不是把症状列为彼此独立的缺口。 - 不得根据购买的平台、单个成功项目或未形成记录的说法推断成熟度。 ## 按价值和风险排列改进事项，先打好基础 根据业务价值、风险降低程度、依赖关系和交付准备度，将发现转化为有顺序的改进组合。一长串互不关联的举措并不构成战略。 - 将每项举措关联到有记录的发现、问责成果和可衡量的收益。 - 根据影响、紧迫性、风险暴露、工作量、依赖关系和证据置信度对工作排序。 - 在依赖这些基础的自动化、分析或规模扩展工作之前，先建立支撑性基础。 - 定义范围、负责人、决策关卡、资源、里程碑和验收指标。 - 识别能够快速完成的改进，但不能让它们挤占关键基础工作。 - 将政策、责任、资金或风险接受方面的变更升级给问责机构。 - 未经明确批准且没有回滚计划，不得开始不可逆或影响生产环境的工作。 ## 制定数据从产生到销毁的管控规则 从获取和创建开始，经过使用、共享、保留、归档，直至处置，全程实施控制。协调项目交付与运营责任，确保控制措施在部署后仍然有效。 - 在设计之前获取信息需求、定义、分类和质量规则。 - 在发布之前审查模型、接口、访问路径、保留需求和恢复要求。 - 安全使用具有代表性的测试数据，并验证迁移、转换和对账。 - 对数据模型、模式、规则、映射和控制证据进行版本管理，并保留可追踪的批准记录。 - 监控可用性、性能、访问行为、变更结果和恢复准备度。 - 生产环境访问、破坏性变更、保留例外和处置必须经过授权决策。 - 在高影响变更之前保留审计证据，并测试回滚或恢复路径。 ## 统一共用术语的含义和正式的数据来源 将权威定义、参考值、主数据实体、元数据、分类体系和血缘作为相互关联的服务进行管理，以减少歧义。 - 为共享术语、标识符、代码集和层级结构指定所有者与批准规则。 - 识别权威数据源，并记录允许使用副本或派生值的位置。 - 记录从源头经过转换直至重要用途和报告的数据血缘。 - 将业务定义与技术模式、控制措施和问责所有者关联起来。 - 在各平台间整合元数据，同时保留来源信息和更新责任。 - 通过分类、索引、访问、保留和检索控制来管理文档与记录。 - 在责任归属、质量、更新和冲突规则尚未明确之前，不得将某个数据源标为权威。 ## 按报表和决策的用途检查数据质量 根据已声明的用途管理质量和分析支持能力。数据集可能在技术上有效，却不适合某项决策、报告、模型或运营流程。 - 根据需要，为准确性、完整性、一致性、及时性、有效性和唯一性定义可衡量的规则。 - 与对业务用途负责的人员共同设置阈值和服务水平。 - 在依赖数据之前对其进行剖析和测试，然后监控漂移和反复出现的缺陷。 - 将缺陷追溯到源流程、控制措施、转换或不明确的责任归属。 - 提供经过整理的分析数据、报告服务和有记录的语义定义。 - 将可靠分析数据的责任与解释业务结果的责任区分开来。 - 对关键输出进行对账，并传达限制、新鲜度和已知质量风险。 ## 定期检查各项指标，确认修好后再关闭问题 将该模型作为持续管理循环来运行。审查应促成决策、整改和优先级更新，而不能沦为报告仪式。 - 维护一小组衡量价值、风险、质量、服务、采用、成本和控制有效性的指标。 - 按规定周期审查能力健康状况、事件、例外、逾期决策和举措成果。 - 为每个问题指定负责人、严重程度、到期日、升级路径和关闭证据。 - 在关闭一项发现之前，验证整改确实改变了被衡量的状况。 - 向受影响的各方传达决策、理由、依赖关系和剩余风险。 - 当证据或情境发生变化时，更新政策、能力描述、路线图和责任归属。 - 定期重新评估运营模型是否仍与业务需求和风险相称。