目录
导读
第二部分
第二部分为第4～6章，介绍了数据治理工作中的三项重点建设任务：信息架构、数据底座、数据服务。
第4章介绍了信息架构的四个组件，给出了建设原则和核心要素，并引出了业务对象、过程、规则三项数字化的建设方向；
第5章提出了数据底座建设的整体框架，分别介绍了数据湖和数据主题联接两个层次的建设实践；
第6章以自助、高效、复用为数据服务的目的，提出了对数据进行搜索、加工和分析的消费过程管理方案。
第4章 面向“业务交易”的信息架构建设
随着企业数字化转型的推进，华为公司越来越认识到信息架构的价值并不应局限于“支撑IT建设落地”，而是更好地管理企业数据资产，更好地提升整个业务交易链条的效率，甚至基于信息架构重新审视业务边界的划分和整合。
信息架构的四个组件
信息架构的目的就是定义好整个运作过程中涉及的各种人、事、物资源，并实施有效的治理，从而确保各类数据在企业各业务单元间高效、准确地传递，上下游流程快速地执行和运作。
华为在实践中构建了一套对业务运作数据进行有效管理的信息架构方法论，用于指导企业内部各部门的信息架构建设工作，让管理者、专家和员工之间有共同语言。
华为的企业级信息架构（Information Architecture）是指以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范，包括数据资产目录、数据标准、企业级数据模型和数据分布四个组件。
数据资产目录
数据资产目录形成完善的企业资产地图，也在一定程度上为企业数据治理、业务变革提供了指引。基于数据资产目录可以识别数据管理责任，解决数据问题争议，帮助企业更好地对业务变革进行规划设计，避免重复建设。华为数据资产目录分为5层，涵盖公司的所有业务数据资产。
数据标准
数据标准定义公司层面需共同遵守的属性层数据含义和业务规则，是公司层面对某个数据的共同理解，这些理解一旦确定下来，就应作为企业层面的标准在企业内被共同遵守。
华为公司对业务数据标准有严格的限定，每个数据标准应该覆盖以下三方面。
业务视角要求：用于统一业务侧语言和理解，明确定义每个属性所遵从的业务定义和用途、业务规则、同义词，并对名称进行统一定义，避免重复。
技术视角要求：对IT实施形成必要的指引和约束，包括数据类型、长度，如果存在多个允许值，则应对每个允许值进行明确的限定。
管理视角要求：明确各业务部门在贯彻数据标准管理方面应承担的责任，包括业务规则责任主体、数据维护责任主体、数据监控责任主体，因为很多情况下这些责任并不是由同一个业务部门来负责，所以必须在标准制订时就约定清楚。例如，“客户合同”中某些条款的规则制订者可能是财经部门，负责与客户达成约定并在系统中录入的可能是销售业务部门，而对整个客户合同数据质量进行跟踪、监控的可能是数据专业部门。
数据模型
数据模型是从数据视角对现实世界特征的模拟和抽象，根据业务需求抽取信息的主要特征，反映业务信息（对象）之间的关联关系。
数据分布
如果说前三个组件主要是从静态角度对数据、数据关系进行定
义，那么数据分布则定义了数据产生的源头及在各流程和IT系统间的流动情况。数据分布组件的核心是数据源，指业务上首次正式发布某项数据的应用系统，并经过数据管理专业组织认证，作为企业范围内唯一数据源头被周边系统调用。
信息架构原则：建立企业层面的共同行为准则
原则一：数据按对象管理，明确数据Owner
原则二：从企业视角定义信息架构
原则三：遵从公司的数据分类管理框架
原则四：业务对象结构化、数字化
原则五：数据服务化，同源共享
信息架构建设核心要素：基于业务对象进行设计和落地
按业务对象进行架构设计
要完成一个交易， 实现商业价值的兑现，企业内的某个子公司，需要与法人客户签订客户合同，在客户合同中，要明确交易的产品。在这个场景中，子公司、法人客户、客户合同、产品是企业需要管理和控制的核心对象，要作为业务对象进行管理。
在进行信息架构设计时，架构师、业务代表、数据Owner通常会对业务对象的判定存在理解上的偏差，从而产生争议。数据治理部门需要制定一套确定性的规则，通过确定性的规则促进形成稳定的架构。华为通过以下四条原则来判定业务对象。
原则一：业务对象是指企业运作和管理中不可缺少的重要人、事、物
原则二：业务对象有唯一身份标识信息
原则三：业务对象相对独立并有属性描述
原则四：业务对象可实例化
按业务对象进行架构落地
信息架构向IT侧落地的主要交付件是数据模型（概念数据模型、逻辑数据模型、物理数据模型）。
概念数据模型是通过业务对象及业务对象之间的关系，从宏观角度分析和设计的企业核心数据结构。逻辑数据模型是利用逻辑数据实体及实体之间的关系，准确描述业务规则的逻辑实体关系。物理数据模型是按照一定规则和方法，将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，如实转换为数据库软件能识别的物理数据实体关系。
为了确保架构在落地过程中“不走形”，要控制好两个关键点：一个是概念模型与逻辑模型的一致性，主要通过逻辑数据实体的设计管理来实现；另一个是逻辑模型与物理模型的一致性，主要通过一体化建模管理来实现。
传统信息架构向业务数字化扩展：对象、过程、规则
1）大量业务和作业所产生的数据并没有完整地被管理
2）大量业务过程没有形成可视、可管理的数据
3）大量业务规则缺乏管理、无法灵活使用
华为公司在传统信息架构的基础上，提出了面向数字化转型的扩展：对象数字化、过程数字化、规则数字化，并打造与之相应的能力。
1）对象数字化
对象数字化的目标是建立对象本体在数字世界的映射。这种映射不是传统意义上基于流程要求的少量数据的管理，而是管理某个对象的全量数据。
2）过程数字化
过程数字化要实现业务活动线上化，并记录业务活动的执行或操作轨迹，一般通过观测数据来实现轨迹记录。华为公司通过推进业务过程数字化，实现供应链对各类物流状态的实时感知和可视，大幅缩减了发货后反复人工沟通的成本。
3）规则数字化
规则数字化的目的是把复杂场景下的复杂规则用数字化手段进行管理。
第5章 面向“联接共享”的数据底座建设
支撑非数字原生企业数字化转型的数据底座建设框架
1）统一管理结构化、非结构化数据。将数据视为资产，能够追溯数据的产生者、业务源头以及数据的需求方和消费者等。
2）打通数据供应通道，为数据消费提供丰富的数据原材料、半成品以及成品，满足公司自助分析、数字化运营等不同场景的数据消费需求。
3）确保公司数据完整、一致、共享。监控数据全链路下的各个环节的数据情况，从底层数据存储的角度，诊断数据冗余、重复以及“僵尸”问题，降低数据维护和使用成本。
4）保障数据安全可控。基于数据安全管理策略，利用数据权限控制，通过数据服务封装等技术手段，实现对涉密数据和隐私数据的合法、合规地消费。
数据底座的总体架构
数据底座的建设策略
华为数据底座采取“统筹推动、以用促建、急用先行”的建设策略，根据公司数字化运营的需要，由公司数据管理部统一规划，各领域分别建设，以满足本领域和跨领域的数据需求。其中，数据Owner是各领域数据底座建设的第一责任人，各领域数据部负责执行。
数据湖：实现企业数据的“逻辑汇聚”
华为数据湖的3个特点
华为数据湖是逻辑上对内外部的结构化、非结构化的原始数据的逻辑汇聚。数据入湖要遵从6项入湖标准，基于6项标准保证入湖的质量，同时面向不同的消费场景提供两种入湖方式，满足数据消费的要求。
数据入湖的6个标准
（1）明确数据Owner
（2）发布数据标准
（3）认证数据源
（4）定义数据密级
（5）数据质量评估
（6）元数据注册
数据入湖方式
数据入湖的方式主要有物理入湖和虚拟入湖两种，根据数据消费的场景和需求，一个逻辑实体可以有不同的入湖方式。两种入湖方式相互协同，共同满足数据联接和用户数据消费的需求，数据管家有责任根据消费场景的不同，提供相应方式的入湖数据。
物理入湖是指将原始数据复制到数据湖中，包括批量处理、数据复制同步、消息和流集成等方式。虚拟入湖是指原始数据不在数据湖中进行物理存储，而是通过建立对应虚拟表的集成方式实现入湖，实时性强，一般面向小数据量应用，大批量的数据操作可能会影响源系统。
结构化数据入湖
触发结构化数据入湖的场景有两种：第一，企业数据管理组织基于业务需求主动规划和统筹；第二，响应数据消费方的需求。
结构化数据入湖过程包括：数据入湖需求分析及管理、检查数据入湖条件和评估入湖标准、实施数据入湖、注册元数据
非结构化数据入湖
相较于结构化数据，非结构化数据更难以标准化和理解，因而非结构化数据的管理不仅包括文件本身，而且包括对文件的描述属性，也就是非结构化的元数据信息。这些元数据信息包括文件对象的标题、格式、Owner等基本特征，还包括对数据内容的客观理解信息，如标签、相似性检索、相似性连接等。这些元数据信息便于用户对非结构化数据进行搜索和消费。
1）基本特征元数据入湖
2）文件解析内容入湖
3）文件关系入湖
4）原始文件入湖
数据主题联接：将数据转换为“信息”
五类数据主题联接的应用场景
多维模型是面向业务的多视角、多维度的分析，通过明确的业务关系，建立基于事实表、维度表以及相互间联接关系，实现多维数据查询和分析。例如，对订货数据从时间、区域、产品、客户等维度进行多视角、不同粒度的查询和分析。
图模型面向数据间的关联影响分析，通过建立数据对象以及数据实例之间的关系，帮助业务快速定位关联影响。例如，查看某国家原产地的项目的数据具体关联到哪个客户以及合同、订单、产品的详细信息时，可以通过图模型快速分析关联影响，支撑业务决策。
标签是对特定业务范围的圈定。在业务场景的上下文背景中，运用抽象、归纳、推理等算法计算并生成目标对象特征的表示符号，是用户主观观察、认识和描述对象的一个角度。例如，对用户进行画像，识别不同的用户群，为产品设计和营销提供策略支持。
指标是对业务结果、效率和质量的度量。依据明确的业务规则，通过数据计算得到衡量目标总体特征的统计数值，能客观表征企业某一业务活动中业务状况。例如，促销员门店覆盖率指标就是衡量一线销售门店促销员的覆盖程度。
算法模型是面向智能分析的场景，通过数学建模对现实世界进行抽象、模拟和仿真，提供支撑业务判断和决策的高级分析方法。例如，预测未来18个月的销售量，需要数据科学家根据数据湖中的历史订单、发货等数据通过决策树和基因算法进行数据建模，支持业务决策。
多维模型设计
维模型是依据明确的业务关系，建立基于维度、事实表以及相互间连接关系的模型，实现多角度、多层次的数据查询和分析。
（1）确定业务场景
（2）声明粒度
（3）维度设计
（4）事实表设计
图模型设计
图模型由节点和边组成。节点表示实体或概念，边则由属性或关系构成。实体指的是具有可区别性且独立存在的某种事物，如某一个人、某一个城市、某一种植物、某一种商品等，是图模型中的最基本元素；概念是对特征的组合而形成的知识单元，主要指集合、类别、对象类型、事物的种类，例如人物、地理等；属性主要指描述实体或概念的特征或特性，例如人员的国籍、生日等。
第一步：业务场景定义。
第二步：信息收集。
第三步：图建模。
第四步：实体、概念、属性、关系的标注。
第五步：实体和概念的识别。
第六步：属性识别与关系识别。
标签设计
标签是根据业务场景的需求，通过对目标对象（含静态、动态特性）运用抽象、归纳、推理等算法得到的高度精练的特征标识，用于差异化管理与决策。标签由标签和标签值组成，打在目标对象上。标签分为事实标签、规则标签和模型标签。
事实标签是描述实体的客观事实，关注实体的属性特征，如一个部件是采购件还是非采购件，一名员工是男性还是女性等，标签来源于实体的属性，是客观和静态的；
规则标签是对数据加工处理后的标签，是属性与度量结合的统计结果，如货物是否是超重货物，产品是否是热销产品等，标签是通过属性结合一些判断规则生成的，是相对客观和静态的；
模型标签则是洞察业务价值导向的不同特征，是对于实体的评估和预测，如消费者的换机消费潜力是旺盛、普通还是低等，标签是通过属性结合算法生成的，是主观和动态的。
标签管理分为标签体系建设和打标签。
指标设计
指标是衡量目标总体特征的统计数值，是能表征企业某一业务活动中业务状况的数值指示器。指标一般由指标名称和指标数值两部分组成，指标名称及其含义体现了指标在质的规定性和量的规定性两个方面的特点；指标数值反映了指标在具体时间、地点、条件下的数量表现。
根据指标计算逻辑是否含有叠加公式，可以把指标分为原子指标和复合指标两种类型。
算法模型设计
算法是指训练、学习模型的具体计算方法，也就是如何求解全局最优解，并使得这个过程高效且准确，其本质上是求数学问题的最优化解，即算法是利用样本数据生成模型的方法。算法模型是根据业务需求，运用数学方法对数据进行建模，得到业务最优解，主要用于业务智能分析。
第6章 面向“自助消费”的数据服务建设
数据底座建设的目标是更好地支撑数据消费，在完成数据的汇聚、整合、联接之后，还需要在供应侧确保用户更便捷、更安全地获取数据。一方面业务人员希望尽可能快速地获取各种所需的数据，另一方面要确保数据获取过程中满足安全、合规的要求。
数据服务：实现数据自助、高效、复用
什么是数据服务
数据服务是基于数据分发、发布的框架，将数据作为一种服务产品来提供，以满足客户的实时数据需求，它能复用并符合企业和工业标准，兼顾数据共享和安全。
数据服务生命周期管理
完整的数据服务生命周期包括服务识别与定义、服务设计与实现、服务运营三个主要阶段。
服务识别与定义：业务与数据握手，识别服务的业务价值、准入条件与服务类型，减少数据服务的重复建设，提升数据服务的重用度。
服务设计与实现：业务、数据、IT三方协同，使设计、开发、测试与部署快速迭代以实现服务的敏捷交付，缩短数据服务的建设周期。
服务运营：通过统一数据服务中心及服务运营机制，保障服务SLA与持续优化。
1. 数据服务的识别与定义
1）分析数据服务需求：通过数据需求调研与需求交接，判断数据服务类型（面向系统或面向消费）、数据内容（指标/维度/范围/报表项）、数据源与时效性要求。
2）识别可重用性：结合数据需求分析，通过数据服务中心匹配已有的数据服务，判断以哪种方式（新建服务、直接复用、服务变更）满足业务需求。对于已有数据服务，必须使用服务化方式满足需求，减少数据“搬家”。
3）判断准入条件：判断服务设计条件是否已具备，包括数据Owner是否明确、元数据是否定义、业务元数据和技术元数据是否建立联接、数据是否已入湖等。
4）制定迭代计划：根据数据服务需求制定敏捷交付计划，快速满足数据服务需求。
2. 数据服务的设计与实现
在服务设计与实现阶段，要定义服务契约和数据契约，重点明确服务契约所涉及的服务责任主体、处理逻辑，并以数据契约规范服务的数据格式与数据的安全要求。
服务契约：包括服务的基本信息（数据服务提供方、数据服务的类型）、能力要求（服务的时效性、服务的处理逻辑、服务的安全策略、服务的SLA要求）等。
数据契约：包括数据契约描述、输入和输出参数、业务数据资产编码、物理落地资产编码等。
数据服务颗粒度通常应考虑以下原则：
业务特性：将业务相近或相关、数据粒度相同的数据设计为一个数据服务。
消费特性：将高概率同时访问、时效性要求相同的数据设计为一个数据服务。
管理特性：综合考虑企业在数据安全管理策略方面的要求。
能力特性：将单一能力模型设计为一个服务。
基于上述原则，可以形成一些具体的用于指导实际执行的参考规范，如下所示。
同一种提供形式下，一个数据只能设计在一个数据服务中。按主题（业务对象）将相同维度的数据设计为一个数据服务。如果同一个主题下的指标数量过多，则需要考虑按“高概率同时使用、业务关联度紧密”的原则再进行划分。
将同一个逻辑实体的数据设计为一个数据服务。
将单一功能的算法、应用模型设计为一个服务。
3. 数据服务的变更与下架
（1）数据服务变更管理
（2）数据服务的下架管理
数据服务分类与建设规范
数据服务是为了更好地满足用户的数据消费需求而产生的，因此数据消费方的差异是数据服务分类的最关键因素。具体包括两大类：数据集服务和数据API服务。
1. 数据集服务
比较常见的数据消费者有两类：一类是真实的“人”，一类是
“IT系统”。企业越来越强调各业务部门的自我运营，因此产生了大量自助分析消费者，这类消费者就是业务人员，甚至可能是管理者，他们通过各种数据分析工具，直接使用、消费数据。这种情况下，消费者是“访问”某个相对完整的“数据集”，这种消费方式称之为“数据集服务”。
数据集服务最主要的特征是由服务提供方提供相对完整的数据集合，消费方“访问”数据集合，并自行决定接下来的处理逻辑。
数据集服务主要面向自助分析场景提供相对完整的数据集合，因此所提供的数据主要来自数据底座，包括“数据湖”和“主题联接”。
2. 数据API服务定义
数据服务的另外一类消费者是“IT系统”，即面向某个IT系统提供数据事件驱动的“响应”，这种服务的封装方式与前面所提到的数据集不同，称为“数据API服务”。
打造数据供应的“三个1”
数据服务改变了传统的数据集成方式，所有数据都通过服务对外提供，用户不再直接集成数据，而是通过服务获取。因此，数据服务应该拉动数据供应链条的各个节点，以方便用户能准确地获取数据为重要目标。
“三个1”是数据供应的整体目标，起点是需求方提出数据需求，终点为需求方拿到数据并可立即进行消费，具体衡量标准包括如下内容。
1天：对于已发布数据服务的场景，从需求提出到消费者通过服务获取数据，在1天内完成。
1周：对于已进底座但无数据服务的场景，从需求提出到数据服务设计落地、消费者通过服务获取数据，在1周内完成。
1月：对于已结构化但未进底座的场景，从需求提出到汇聚入湖、数据主题联接、数据服务设计落地、消费者通过服务获取数据，在1个月内完成。
数据供应的“三个1”并不是单纯的度量指标，而是一整套瞄准最终数据消费体验的能力体系以及确保数据供应能力的管理机制，还包括组织职责的明确、流程规范的制定与落实、IT平台的建设和管理。
构建以用户体验为核心的数据地图
在解决数据的“可供应性”之后，企业应该帮助业务更便捷、更准确地找到它们所需要的数据，这就需要打造一个能够满足用户体验的“数据地图”。
数据地图的核心价值
数据地图为四类关键用户群体提供服务。
1）业务分析师
2）数据科学家
3）数据管家
4）IT开发人员
数据地图的关键能力
数据地图重点提供数据搜索、排序推荐、样例数据、资产/用户画像等关键能力。
人人都是分析师
数据服务解决了“可供应性”，数据地图解决了“可搜索/可获取性”，当消费方获取数据后，提供“可分析”能力，帮助数据消费者结合自身需要获取想要的分析结果。
从“保姆”模式到“服务+自助”模式
“服务+自助”模式，即公司总部只提供统一的数据服务和分析能力组件服务，各业务部门可以根据业务需要进行灵活的数据分析消费，数据分析的方案和结果由业务自己完成。
打造业务自助分析的关键能力
（1）面向业务分析师，提供自助分析能力，业务人员通过“拖、拉、拽”即可快速产生分析报告。
（2）面向数据科学家，提供高效的数据接入能力和常用的数据分析组件，快速搭建数据探索和分析环境。
（3）面向IT开发人员，提供云端数据开发、计算、分析、应用套件，支撑海量数据的分析与可视化，实现组件重用。
从结果管理到过程管理，从能“看”到能“管”
数据分析和消费本身只是一种手段而不是目标，数据消费要真正产生价值，必须与业务密切结合。业务数字化运营是华为公司数据消费的最重要场景之一。
数据赋能业务运营
业务运营的本质是围绕业务战略“RUN”流程。运营过程中业务沿着流程周而复始地运转，在作业过程中识别并解决问题，应基于PDCA循环（戴明环）进行有质量的运营。
数字化运营旨在利用数字化技术获取、管理和分析数据，从而为企业的战略决策与业务运营提供可量化的、科学的支撑。
数字化运营归根结底是运营，旨在推动运营效率与能力的提升，所以它体现在具体的业务中，而不是一块新的业务，更多是在现有标准流程的基础上改进和完善。数字化运营的核心是数据，以及基于数据的精细化管理和科学决策分析。
业务数字化运营的目的不应只有“察（数字化看板）”，还应该进一步实现“打（业务决策与执行）”，即支撑业务运营作战模式转变，提升运营效率。业务数字化运营要发挥对业务的指挥作用，要能够让上下同步感知业务运行态势，通过分工协作解决业务运作中的问题，提升运作效率。
业务数字化运营要同时具备多个能力，包括战略落地、业务可视化、预测预警、作业指挥、跨领域问题解决和联动指挥等。
数据消费典型场景实践
过去，经营管理多为事后管理，通过每月下任务令进行业务改
进，整个问题从发现到解决周期长，且存在大量人工动作，耗散大量业务精力。
数据滞后，经营过程非实时可视，主要为事后管理。
按月做经营分析，从经营数据产生到下发任务令需0.5～1个月。
缺少集成管理平台，手工做经营分析，线下管理任务令。
通过数字化运营实现事中监控和及时改进，达到经营过程可视化、报告在线分析、实时社交讨论、及时经营改进的目的。
数据在线转变为事中监控，随时可拉通审视规模、盈利、效率全经营指标。
经营管理模式改变，实时分析经营风险，会上聚焦重大风险决策，高效运作。
在统一平台进行监控、预警、协调、任务管理，从战略、执行到经营过程和结果实现闭环。
华为数据驱动数字化运营的历程和经验
1. 华为数字化运营的不同阶段
（1）“从行走到公交”阶段
大部分情况下采取“机关建、业务部门用”的方式。虽然通过数据治理达到了“数据清洁”的目标，也能够实现一定程度的经营和运营数据的可视化，但仍存在机关开发永远满足不了业务部门需求的问题，尤其是不同国家的业务场景各有差异，机关开发无法满足根据业务场景进行灵活运营的目的，机关开发往往疲于奔命，而业务部门满意度仍然不高。
（2）“从公交到自驾”阶段
由于自研和引进了业界先进的分析工具，各区域开始按需以自助的形式生成各种分析报表。在满足各国家、各业务部门特定需求和灵活变化方面，收到了一些效果。但在该阶段，数据从供应到消费的整个过程处于“无序”状态，业务自助分析“野蛮生长”，大量数据是以离线手工获取方式为主，数据的完整性和可靠性存在很大问题，也存在大量的数据安全隐患。
（3）“从无序到有序”阶段
通过数据底座建设实现生态共建、平台共享的效果。随着数据服务的大量建设，逐步覆盖了80%的场景，使得各种数据消费的效率更高、安全性更好，减少了大量重复建设。通过前台统一入口，大大提升了运营分析的性能体验。另外，还打造了从“业务部门回到机关”通道，对各个国家的优秀典型场景进行归纳，业务部门的优秀实践反向纳入数据底座形成公共数据服务和报表卡片，各个国家可以通过自助分析平台实现对优秀实践的快速复制。
（4）“人工到智能”阶段
在原有的数据实时可视化的基础上，逐步增加动态及时预警能力、智能分析和方案推荐能力、任务自动执行能力，支撑业务数字化
运营达到更高层面。业务数字化运营逐步从单一报表可视化，扩展到业务监控、预测、预警、协调、调度、决策、指挥等7个场景的持续打造，最终实现企业数字化运营“平时值班、战时指挥、察打一体”目标。
2. 做好数字化运营的“三个要点、两个基础”
业务数字化运营不是某个能力的单独应用，需要多种能力的联合推动。在初期孵化过程中，尤其应该关注企业数字化运营的“三个要点、两个基础”。
“三个要点”是指数字化运营中的“发育、激励、分享”。
在面向各业务部门的数字化运营能力的“发育”过程中，要做好自助分析能力赋能，识别关键核心人员并通过培训与实战的方式帮助他们掌握自助分析的基本能力，同时机关专家要做好现场支持，帮助各业务分析人员“上马”。在数字化运营实践中要充分激励原创，采取各种方式保护原创，同时鼓励各业务部门充分共享优秀实践。同时，机关要发挥归纳和总结作用，从各地优秀实践中识别真正具有共性的典型场景和典型数据联接模型，不仅可以使自助分析性能更好，还可以推动优秀实践在各个业务部门快速复制，达到“从1到N”的效果。
“两个基础”是指数字化运营中的“数据服务和IT平台”。
数据服务是整个数字化消费的关键，也是业务数字化运营的重要基础。IT平台包括分析平台和数据分析结果呈现前台，其中分析平台承载企业的公共分析能力建设，并重点面向业务分析师提供自助分析能力；数据分析结果呈现前台承载了公共场景的市场能力，支撑典型场景的快速分享。