华为数据之道

三个要点”是指数字化运营中的“发育、激励、分享

两个基础”是指数字化运营中的“数据服务和IT平台

实现“客户交互式”的转变，用数字化手段做厚，做深客户界面，实现与客户做生意更简单、更高效、更安全提升客户 体验满意度，帮助客户解决问题

实现“作战模式”的转变，围绕两大主业务流，以项目为中心，对准一线精兵团队作战，率先实现基于ROADS的体验，达到领先于行业的运营效率。

实现“平台能力”提供方式的转变，实现关键业务对象的数字化并不断汇聚数据，实现流程数字化和能力服务化，支撑一线作战人员和客户的全联接。

实现“运营模式”的转变，基于统一数据底座，实现数字化运营与决策，简化管理，加大对一线人员的授权。

云化、服务化的IT基础设施和IT应用，统一公司IT平台，同时构建智能服务。

基于统一的数据管理规则，确保数据源头质量以及数据入湖，形成清洁、完整、一致的数据湖，这是华为数字化转型的基础。

业务与数据双驱动，加强数据联接建设，并能够以数据服务方式，灵活满足业务自助式的数据消费诉求。

针对汇聚的海量内外部数据，能够确保数据安全合规。

不断完善业务对象、过程与规则数字化，提升数据自动采集能力，减少人工录入。

持续提升数据质量，减少纠错成本：通过数据质量度量与持续改进，确保数据真实反映业务，降低运营风险。

数据全流程贯通，提升业务运作效率：通过业务数字化，标准化，借助IT技术实现业务上下游信息快速传递、共享

业务可视，能够快速、准确决策：通过数据汇聚，实现业务状态透明可视，提供基于“事实”的决策支撑依据

人工智能，实现业务自动化：通过业务规则数字化、算法化，嵌入业务流，逐步替代人工判断

数据创新，成为差异化竞争优势：基于数据的用户洞察，发现新的市场机会点，

建立企业级信息架构，统一数据语言。

所有变革项目须遵从数据管控要求。对于不遵从管控要求的变革项目，数据管控组织拥有一票否决权。

应用系统设计和开发应遵从企业级信息架构。关键应用系统必须通过应用系统认证。

数据规划对齐业务战略，业务战略规划必须包含关键数据举措及其路标规划。

公司数据Owner拥有公司数据管理的最高决策权，依托ESC（变革指导委员会）决策平台议事。各数据Owner承担数据工作路标、信息架构、数据责任机制和数据质量的管理责任。

关键数据须定义单一数据源，一点录入，多点调用。数据质量问题应在源头解决。

谁产生数据，谁对数据质量负责。数据Owner负责基于使用要求制定数据质量标准，且须征得关键使用部门的同意。

数据应在满足信息安全的前提下充分共享，数据产生部门不得拒绝跨领域的、合理的数据共享需求。

信息披露、数据安全管理、数据保管和个人数据隐私保护等必须遵守法律法规和道德规范的要求。公司保护员工、客户、商业伙伴和其他可识别个体的数据。

各数据Owner应建立数据问题回溯和奖惩机制。对不遵从信息架构或存在严重数据质量问题的责任人进行问责。

公司数据Owner负责批准企业级信息架构，裁决重大信息架构问题和争议。

各数据Owner负责其所辖数据的信息架构建设和维护，承接及落实公司的数据规划要求。

司的数据管理专业组织作为公司数据工作的支撑组织，负责组织信息架构的建设、维护、落地及遵从管控，负责协调跨领域的信息架构冲突。各领域各事业群（BG）数据管理专业组织协助完成本领域信息架构建设和维护工作。

数据管控组织作为信息架构专业评审机构，确保信息架构的质量和集成。

关键数据应被识别、分类、定义及标准化，数据的定义在公司范围内应唯一，数据标准制定要考虑跨流程要求。

数据资产目录必须承接公司各业务环节的使用需求和报告分析最小粒度的要求。

信息架构驱动应用架构设计，合理规划数据分布。

应用系统数据库的设计和开发要遵循信息架构，减少数据冗余，实现接口标准化。

变革项目必须遵从已发布的信息架构，变革项目的交付件须包含信息架构内容。对现有架构的遵从是关键评审要素，对于不满足要求的变革项目，数据管控组织拥有一票否决权。

业务流程设计必须遵从已发布的信息架构，在流程说明文件、操作指导书或模板类文件中体现。对于不满足要求的流程，不予发布。

应用系统设计必须遵从已发布的信息架构。在应用架构交付件和应用系统设计交付件中体现。对于不满足要求的应用系统，不予上线。

所有关键数据必须认证数据源。关键数据是指影响公司经营、运营报告的数据，在公司范围内统一发布。

数据管理专业组织为关键数据指定源头，数据源必须遵从信息架构和标准，经信息架构专家委员会认证后成为数据源。

所有关键数据仅能在数据源录入、修改，全流程共享，其他调用系统不能修改。下游环节发现的数据源质量问题，应当在数据源进行修正。

所有应用系统必须从数据源或数据源镜像获取关键数据。

数据Owner确保数据源的数据质量，对不符合数据质量标准的数据源，必须限期整改。

数据源是在信息链上正式发布数据的第一个数据存储系统。

数据源是某项数据唯一的录入点。

数据源必须是数据维护最为及时、正确、完整的数据存储系统。

数据源所在系统的性能和可用性应当满足其他调用系统的数据访问需求。

制定数据管理体系的愿景和路标。

传播数据管理理念，营造数据文化氛围。

建设和优化数据管理体系，包括组织与任命、授权与问责等。

批准公司数据管理的政策和法规。

裁决跨领域的数据及管理争议，解决跨领域的重大数据及管理问题。

数据Owner要负责所辖领域的数据管理体系建设和优化，传播数据管理理念，营造数据文化氛围。

数据Owner要负责所辖领域的信息架构建设和维护，确保关键数据被识别、分类、定义及标准化，数据的定义在公司范围内唯一，数据标准制定要考虑跨流程要求。

数据Owner要负责保障所辖领域的数据质量，承接公司设定的数据质量目标，制定数据质量标准及测评指标，持续度量与改进。

数据Owner要负责所辖领域数据入湖，建设数据服务，满足公司各个部门对本领域数据的需求。

数据Owner要建立数据问题回溯和奖惩机制，对所辖领域的数据问题及争议进行裁决，对不遵从信息架构或存在严重数据质量问题的责任人进行问责。

负责数据管理的战略、规划、政策、规则的制定。

负责数据管理体系建设。

数据架构及核心数据资产管理。

确保公司数据质量水平。

构建数据管理的方法、工具、平台。

负责专业能力的开发和建设，包括数据架构、数据分析、信息管理、数据质量管理。

面向业务，提供数据解决方案，解决业务数据痛点。

支撑业务数据需求。

向业务提供标准化的主数据或基础数据服务

在公司范围建设追求卓越、“谁创建（录入）数据，谁对数据质量负责”的文化。

用数据支撑业务决策的文化。

基础数据

主数据

事务数据

报告数据

观测数据

规则数据

数据消费层包括所有消费数据的IT产品团队，负责提出数据集成需求和集成接口实施。

负责主数据集成解决方案的落地，包括数据服务的IT实施和数据服务的配置管理。

为需要集成主数据的IT产品团队提供咨询和方案服务，负责受理主数据集成需求，制定主数据集成解决方案，维护主数据的通用数据模型。

管控层由信息架构专家组担任，负责主数据规则的制定与发布，以及主数据集成争议或例外的决策

客户主数据治理框架

客户主数据平台架构

用于报表项数据生成的事实表、指标数据、维度

用于报表项统计和计算的统计函数、趋势函数及报告规则。

用于报表和报告展示的序列关系数据。

用于报表项描述的主数据、基础数据、事务数据、观测数据。

用于对报告进行补充说明的非结构化数据

事实表

维度

统计型函数

趋势型函数

报告规则函数

序列关系数据

观测数据是通过观测工具获取的数据，观测对象一般为人、事、物、环境。

相比传统数据，观测数据通常数据量较大且是过程性的，由机器自动采集生成。不同感知方式获取的观测数据，其数据资产管理要素不同

使用软件或者各种技术进行数据收集，收集的对象存在于数字世界，通常不依赖于物理设备，一般是自动运行的程序或脚本

利用设备或装置进行数据收集，收集的对象为物理世界中的物理实体，或者是以物理实体为载体的信息，其数据的感知过程是数据从物理世界向数字世界的转化过程。

观测数据通常数据量较大且是过程性的，主要用作监控分析。例如，视频监控器产生的视频数据、操作系统产生的日志记录数据等

观测数据由机器自动采集生成。例如，各种传感器或探针记录观测对象产生的数据

观测数据是观测工具采集回来的原始数据（Raw Data），仅转换结构和格式，不做任何业务规则解析。

观测工具的元数据可以作为数据资产管理：软感知（埋点、日志收集、爬虫）观测工具抽象成业务对象，由IT部门担任数据Owner进行统一管理；硬感知观测工具作为资源类数据，也建议作为业务对象由相应的领域担任数据Owner进行管理。

原则上，观测对象要定义成业务对象进行管理，这是观测数据管理的前提条件。

观测数据需要记录观测工具、观测对象。针对不同感知方式获取的观测数据，其资产管理方案也不尽相同。例如，以用户界面浏览记录为例，如果是对销售机会点的查询访问观测，应当归属到相应业务领域；如果是对页面性能、页面UV、PV的观测，应当归属到IT部门。

规则数据不可实例化；

规则数据包含判断条件和决策结果两部分信息，区别于描述事物分类信息的基础数据；

规则数据的结构在纵向（列）、横向（行）两个维度上相对稳定，变化形式多为内容刷新

规则数据的变更对业务活动的影响是大范围的。

规则数据的管理是为了支撑业务规则的结构化、信息化、数字化，目标是实现规则的可配置、可视化、可追溯。

不同于标准化的信息架构管理，规则数据的管理具有轻量化、分级的特点。重要的、调用量大、变动频繁的业务规则需要通过规则数据管理，使其从代码中解耦，进行资产注册；使用广泛的、有分析需求的规则数据需要通过注册入湖，实现共享和复用。

业务规则在架构层次上与流程中的业务活动相关联，是业务活动的指导和依据，业务活动的结果通过该业务活动的相关业务对象的属性来记录。业务规则通过业务活动对业务事实、业务行为进行限制，业务人员可以根据业务规则判断业务情况，采取具体行动。

业务规则包含规则变量和变量之间的关系，规则数据主要描述规则的变量部分，是支撑业务规则的核心数据

规则数据必须有唯一的数据Owner，其负责开展规则数据的信息架构建设与维护、数据质量的监控与保障、数据服务建设、数据安全授权与定密等工作。相应的数据管家支持数据Owner对所管辖的业务中的规则数据进行治理，包括建设和维护信息架构、确保架构落地遵从、例行监控数据质量等。

规则数据的元数据要记录与业务规则的关系（规则数据定义前应先完成业务规则的识别和定义）。一个业务规则可以包含零个、一个或多个规则数据，一个规则数据在信息架构上对应一个逻辑数据实体，在物理实现上一般对应一个物理表。规则数据要遵从信息架构资产管理要求（包括明确规则数据的Owner、制定数据标准、明确数据源等），按照信息安全要求定密，以方便规则数据的管理、共享和分析。

用户访问数据时了解业务含义的途径，包括资产目录、Owner、数据密级等

实施人员开发系统时使用的数据，包括物理模型的表与字段、ETL规则、集成关系等

数据处理日志及运营情况数据，包括调度频度、访问记录等

元数据能支持企业指标、报表的动态构建。

元数据支持数据服务的统一管理和运营，并实现利用元数据驱动IT敏捷开发

元数据统一管理分析模型，敏捷响应井喷式增长的数据分析需求，支持数据增值、数据变现。

元数据能实现暗数据的透明化，增强数据活性，并能解决数据治理与IT落地脱节的问题

元数据支撑业务管理规则有效落地，保障数据内容合格、合规。

标签体系建设

打标签