如何构建完整的BI实现路径？数据仓库筑基、数据治理和指标体系攻坚！

谈到 BI，基本上是完整的包括数据仓库、ETL、CUBE、报表的全栈开发。

BI 是以一个整体的产品、技术和解决方案出现的。由于前端报表没有很强的交互能力，因此只能通过前端函数、脚本来控制一些效果； 前端报表的任何细微调整或者改动，几乎都只能由IT人员来完成，BI项目约等于纯 IT项目。由于需要考虑前端的性能问题、需求变更对底层的影响等原因，造成在底层数据仓库设计的时候会非常重视底层架构的搭建、建模方式的选择。早期的BI开发人员底层 ETL 技术能力非常扎实、数据仓库架构的参与程度也相对较深，具备全栈的端到端的技术开发能力。但是任何前端的大小改变，业务部门的参与度几乎为零，几乎都需要IT部门去做，成本非常大；另外，早期的报表的样式并不美观，包括钻取在内的基础的功能无法实现，性能也并不好。

这些传统BI的痛点推动BI开始加速演变：2013年之后，BI开始主打自助分析的概念，解决前端的展现能力问题，这种产品深受大多企业欢迎，尤其是之前被前端无法使用问题所困扰的客户群体。

BI在2013年左右，前端和底层分离，分别开始朝着不同得方向开始演变。前端有可视化展现、交互、自助分析能力的强化，在某些细分领域开始崛起；底层开始往大数据、数据中台方向发展。2013年开始，大数据的发展开始唤醒大家的数据意识，ETL并不能解决底层数据量不断增大和非结构数据处理的问题，而当大数据架构出现以后，这些问题可以被解决了。因此，大家开始采用大数据架构作为数仓的解决方案之一。

因此从根源上来说，企业想要用好BI的关键之一是做好数仓建设，而数据仓库的建设难点并非仅仅在于本身的设计，同样也在于后续随着业务发展而带来的数据治理挑战。当业务规模和复杂度不断增加时，如何有效地监控数据质量、维护数据指标体系同样就成为企业想要用好BI的关键。

本文将深入探讨如何通过数据仓库筑基、数据治理攻坚和智能分析应用，构建完整的BI价值实现路径。

一、数据仓库筑基：构建高价值业务决策支撑体系

1、数据仓库的重要性：数据底层建设的优解

大多数企业不同部门的视角和问题并不太一样，信息部门常处的状态就是加班重、任务重，有大量的需求需要去响应。对于信息化、数字化的建设投入了大量的人力和物力，但时常还会受到业务部门的吐槽，投入产出比较低，价值也没办法去衡量，所以通常信息部门会被企业定义为成本部门或者边缘部门。而业务部门想要数据，想要结果看板，但是可能提流程或者工单需要经过较长的响应周期才会实现，做出来的结果看板常常会遇到加载时间长的，每一次看的数据可能是前天或者昨天的。

因此，数据结果的开发周期、准确性、时效性是业务部门最关心的部分，而企业管理部门最关注的是投入产出比，比如信息化建设的 OA/ERP 等业务系统，成本其实都不低，随着业务信息化的投入，整个资源的应用还会加大，但是业务部业务人员常常会给管理层抱怨信息化建设并未有效地提高业务运营质量。此时，管理者就会对于信息化的投入产出比是否对等产生疑问，同时由于数据存在问题，所以管理者常常没有办法以全局的视角进行管理和决策。

为了解决这些问题，企业需要明确做信息化建设的目的就是支撑业务的发展，帮助提升业务经营质量，为企业带来价值。同理，企业不是为了做数仓而做数仓，要让数据的建设和业务紧密关联，将数据和业务进行强绑定。帆软数据应用研究院在调研客户时，发现很多企业反馈最终想达到的模式是让业务部门和信息部门各司其职，信息部门做好数据准备的工作，业务部门做好分析的工作，让懂业务的人员去分析业务，让懂数据建设的人员去建设数据，两者形成一种新的配合模式。为了实现这些目的，数据仓库的重要性就凸显出来了。

数仓作为信息化建设的后半段成果，以沉淀的业务数据为基础，通过构建良好的数据模型来为业务决策和经营管理做支撑。为什么会强调以建设数仓来解决不同角色的诉求呢？

因为随着市场的快速发展，企业想方设法地提高业务管理质量，需要可靠的数据及时地做出判断决策甚至业务调整，所以往往会选择建设更专业化的信息系统去支撑业务发展。

随着业务的不断扩大，业务系统沉淀的数据也会呈指数级的增长，会有越来越多的数据需要被收集、存储应用。这种情况就会导致数据存在系统孤岛的现象，数据难以整合，不同系统的数据口径不统一、不规范，数据结构也很复杂，导致数据应用的难度也会持续增加，最后会造成业务部门和信息部门跨部门之间的协作效率逐渐降低。企业过去花费大量的精力在数据获取和处理上，但是其实企业真正应该关注的是面向业务的经营分析，这就要求数据底层建设应该变得更便捷快速，其中建设数据仓库是一种性价比极高的方式，能够以较低的成本快速看到效果。

2、数据仓库的本质：面向数据分析应用

• 并不是一款产品，而是一种具有数据架构的数据集合，按照企业的特性进行个性化的搭建，目的就是为了给业务决策提供数据支撑。
• 仍然是一个数据库，而且是将业务系统的数据组织形式转变成面向分析型应用的形式。业务系统的数据库和BI数据库（数仓）有根本的区别，业务系统的数据库更多是是描述业务过程，支撑业务流程；而BI的特点是跨越组织，跨业务流程，是一个面，而不是线，因此BI数据库（数仓）是面向数据分析应用的。这两种形式的转化是不容易的，因此数仓就是通过ETL和建模来完成，ETL来控制表数据如何计算，完成输出到另外一张表，而模型控制的是表格结构。

3、数据仓库的特点：集成、时效、持久

• 数仓是面向业务主题的，这意味着数仓为关心的业务主题提供准确全面的数据，让大家能够深入地了解业务的现状和历史发展的趋势。
• 数仓是集成的，数仓整合了多个业务系统的数据，保证了数据的完整性、一致性，能够支撑复杂的查询和分析。
• 数仓是时效的，意味着数仓会定期或者实时地从业务库同步新的数据内容，并且会向应用前端提供高时效的数据，能够及时地响应业务变化。
• 数仓是持久且非一时的，这就意味着数仓本身存储的数据长期进行保留，方便对历史的数据进行回顾，对整体的发展趋势进行整体的分析。

可能有企业会问，是不是所有的企业都必须要建设数仓？是不是建设了数仓就高枕无忧了？

其实不一定，企业不同的发展阶段，底层的需求是不一样的。数据建设没有万能的公式，只有最适合企业自身的解决方案，个性化地建设数仓。

企业的信息化建设初期，数据量比较小，逻辑结构也很简单，可以通过直读数据库的方式快速地应用数据。随着系统的数据量变大，业务的扩展，读写频率就会变高，这个时候业务库的压力就会变得越来越大，会影响到业务系统本身的使用。为了解决这个问题，会建立中间数据库，也就常说的中间库，进行读写分离，将数据预处理；或者常规的离线处理，就是ETL，在中间库这个阶段改造成本很小，但是数据应用效率提升却非常明显。大部分的企业会在中间库阶段发展很长一段时间，因为这个阶段已经能满足很多基础的数据应用了。中间库阶段算是数仓的初级阶段，但是随着业务交叉越来越多，需求也越来越多，由于中间库没有进行统一的整合管理，中间库做的一些成果，只能有针对性地应用，不可复用，对中间库的改造也比较困难，造轮子的现象比较严重，此时需要开始建设完整的数仓。

企业通常会以满足业务主题为目的，建设独立的数据集市架构或者集中式架构，这两者都是应用于业务发展。其实它们的区别很简单，独立的数据集市架构就是根据 ERP 系统，或者针对 mess 系统，进行专门的小型数仓的搭建，严格来说称之为数据集市，但是也能够满足业务，但是随着业务系统越建越多，比如有了OA，除了主数据系统以外，还有PPI、ML、PLM，还有WS 等其他系统。此时，业务交叉很频繁，需要通过集中式的架构把所有的业务库的数据集中在一个数仓里边，然后对数据进行分层应用。现在很多企业，多业务系统是很常见的，集中式架构可能更适合大多数的企业，这样将不同的系统进行集成，所有的数据都是一个出口，实现了输出一口，其次统一了不同业务系统的口径标准；并且在整个数据库的搭建过程中，会进行相应的数据治理，比如DW 层/DIM 层，实现建立完善的数据管理体系，让数据成为生产力的发动机。

帆软最希望的模式，是通过建设数仓，帮助企业打好数据底座，改变传统的数据分析模式。以前IT人员需要去搞定数据准备，自己利用数据进行报表开发，业务人员常常就在旁边扮演评委。现在 IT 通过搭建数仓，准备好数据以及宽表，数据利用的角色从IT变成了业务自身，自己去做自助式的分析。让懂业务的分析业务，让懂开发的搞数据开发。而好的数据应用其实最离不开的就是数据基础。

二、数据治理攻坚：打造精准可信的数据应用基石

1、帆软理解的数据治理内涵：是一套管理体系

数据治理（Data Governance – DG）是企业对数据资产管理行使权力和控制的活动集合（包括计划、监督和执行)，它是管理企业数据资源的一种方式、方法，旨在确保数据的质量、安全、合规和有效性。数据治理是企业实现数据战略的基础，是一个管理体系，包括组织、制度、流程和工具。

数据治理是一套复杂的管理体系，它无法通过单一的工具或产品来实现。数据的生命周期包含了源头、处理和消费这三个阶段，数据的问题也可能会出现在这三个环节中。例如在数据源头环节，用户录入数据的规范性存在问题，导致了最终数据消费环节的数据质量低。数据表象问题的根源，可能来自于业务系统用户交互设计，乃至是底层数据库表结构设计上的缺陷。而要想解决这些表象的数据问题，就必须解决深层次的信息化业务系统开发以及数据库表约束设计等问题。例如为了保证用户录入数据的准确性，有三种方式去设计业务系统：其一是设计前端的检验验证，避免用户做出相同的选择；其二是通过程序编写过滤判断的逻辑，筛除掉前端误入的数据，作为第二层验证；其三是通过建立约束条件，例如唯一性约束、检测约束等等来控制数据录入准确性。因此，企业的数据治理远非使用一款单一的工具或产品就可以实现的，它是需要回到源头，对企业的组织、流程制度、业务系统、底层架构等多个方面进行排查和重构的，它是一套复杂的管理体系。

2、帆软数据治理策略：拉式策略与推式策略

考虑到数据治理工程的复杂性，我们提出了两种目的性不同的数据治理策略：拉式策略（Pull Strategy）和推式策略（Push Strategy）。

拉式策略

面向数据应用，是以提升数据应用过程中的数据准确性为目标的数据治理建设策略。它强调在数据应用的过程中定位和解决问题，以数据应用项目为建设周期。具体而言，拉式策略有三个特点：

自上而下：拉式策略通常以指标体系为起点，进行金字塔式自上而下的规划与建设，通过“数据流、业务流、信息流”的过程反向推动数据质量提升；

数据整合：它包括多系统的数据整合、拉通、清洗、处理，以及数据仓库建设和ETL 开发过程；

数据应用：拉式策略面向数据应用。根据实际业务情况，主要解决数据指标定义标准不清晰、指标计算口径不统一、指标计算口径版本变更、数据不准确、数据上报与数据审核等数据应用场景出现的问题。

推式策略

面向数据全生命周期的管理与控制，是一种体系化的数据治理建设策略。它强调体系化的计划、监督、预防与执行，包括多年计划的数据策略建设周期。具体而言，推式策略有三个特点：

体系化、系统化：推式策略不针对某个单一的、具体的数据应用场景，而是一个全面体系化的治理过程；

全生命周期：它贯穿数据全生命周期的管理，例如数据采集、数据质量、数据应用、数据安全、数据分享等多个环节；

立体策略：推式策略从数据治理策略（目标、范围、方法和组织 ）开始，通过专业的数据治理团队进行数据治理的规划、实施和监督，通过制定数据管理流程规范从源头业务系统的构建到数据的分发、流转，包括数据安全策略与控制，最终贯穿数据资产管理、分析和挖掘的全生命周期过程。

两种策略比较

拉式策略以数据应用需求为起点，推式策略以标准规划为起点，两种策略在多个方面有差异：

根据多数企业的实践经验，以数据应用需求为起点的拉式策略有着更短的实施周期和更低的投入成本，是一种更加灵活、更加敏捷的数据治理策略，我们将在下文中着重介绍这种数据治理策略。

3、适合多数企业的数据治理更优解：拉式策略

以提升数据应用过程中数据准确性为目标的拉式数据治理建设策略主要包括3个流程：

（1）基于指标体系的数据问题洞察：基于数据指标体系，以“数据流、信息流、业务流”的基本逻辑框架，在限定的范围内及时洞察数据质量问题的根源，并逆向推动业务信息化和业务管理的改善和提升；

（2）稳健的数据架构设计：通过数据仓库建模、合理的分层设计、ETL 过程开发等，保障数据模型及架构的稳健性和可扩展性，提高数据使用的准确性；

（3）数据应用审核管控机制：建立面向高层管理的数据指标管控及审核机制，确保数据应用过程中（上报、可视化分析）关键数据必须经过有效审核，提升数据使用质量及数据准确性。

基于指标体系的数据问题洞察

数据问题洞察流程

数据问题的洞察过程可以分为5个步骤：第一步是企业内部的资料收集和需求调研；第二步是指标体系梳理；第三步是确认可视化原型设计方案；第四步是“数据流-信息流-业务流”的问题识别过程；第五步是暴露问题，形成数据质量提高待办。这些步骤中最为重要的是第二步指标体系的梳理和第四步“数据流-信息流-业务流”的问题识别过程。数据问题洞察，本质上就是基于数据指标体系，以“数据流、信息流、业务流”的基本逻辑框架，在限定的范围内及时洞察数据质量问题的根源，并逆向推动业务信息化和业务管理的改善和提升。

• 数据流层面：企业数据问题的洞察始于数据流层面的对指标体系的梳理。指标体系里包含指标和维度，指标即是目标，维度是数据的视角。在确定指标体系后，就需要标准化指标的定义与计算口径、计算逻辑，包括对不同计算口径的版本管理。在计算口径确认后，就需要顺着计算逻辑逐层向下追踪，查看数据能否被获取到。
• 信息流层面：如果在数据流层面出现了问题，比方说数据不能被获取到，那么问题很有可能出在信息流层面，例如信息系统建设存在问题导致数据没有被收集。在这种情况下，可以通过手动填报的方式补录数据，也可以在后续的阶段中完善信息系统的建设。这一过程体现了从数据流到信息流的分析，企业能够更深层次地洞察数据问题的本质，通过数据流暴露的问题来逆向推动未来信息流建设的完善，进而支撑更全面的指标体系。
• 业务流层面：数据流层面出现问题，排除信息流层面存在的信息系统建设问题，还有可能是业务流层面的管理问题导致的。例如同一个指标有不同的计算口径，这就不是信息系统的问题，而是管理自身的问题，是由于部门间的冲突而导致的。从数据流到业务流的分析，企业可以通过表层的数据问题洞察到自身业务流程上存在的弊端，从而逆向完善业务管理流程和管理边界。

在这样金字塔式的数据问题洞察方法下，通过阶段性、有限的指标体系框定了取数的来源范围，因此不会盲目地扩大数据治理的范围和目标。通过在限定的系统范围内洞察存在问题的数据，可以形成有针对性的数据治理策略，让问题聚焦。最后通过阶段性的识别问题、解决问题，可以由点到面、由浅及深，暴露的问题逐步解决，保障阶段性的建设成果。

数据问题洞察案例

案例一：通过“数据流”和“业务流”定位到“信息流”层面的建设问题

表象问题：某集团内部分包导致项目产值及二级单位业绩划分不明确

根因分析：在数据流层面上，发现各部门项目产值不一致，数据的准确性存在问题。基于这个问题，进一步去挖掘信息流层面和业务流层面的根因。在业务流层面上，集团有明确的业务管理标准和规章制度，需要各部门在项目成立时就明确产值，并在缴纳管理费时才需要上报产值，因此业务流层面不存在严重问题。在信息流层面上，项目组织建立时存在同一个项目在信息系统中有两个层级项目的情况，因此NC中项目组织存在“多对一”的情况，导致系统中取自NC的项目组织的数据存在问题。至此，我们通过“数据流”和“业务流”的分析，将数据问题定位到了“信息流”层面的系统设计问题。

解决路径：从信息侧的角度，在NC中建立项目组织时，需要划分项目组织层级，总承包项目部由总承包申请建立，内部分包项目部建立时需要选择对应的总承包项目部；从数据侧的角度，进行产值统计时，项目总产值仅统计一级组织的产值数据。核算各公司产值时，按照对应组织核算自施部分产值，并抵扣内部分包的产值。

治理成果：最终，通过完善业务系统中项目分级管理的机制，实现项目产值的精准核算，完成了从数据问题洞察到数据治理的过程。

案例二：通过“数据流”和“信息流”定位到“业务流”层面的管理问题

表象问题：某集团在建项目、完工项目数量各部门数据不一致

根因分析：数据流层面上，发现在进行数据分析时，从各业务系统中获取的数据不一致，并且项管部仍存在线下统计数据的现象。进一步分析，发现信息流层面不同的业务系统，对项目状态的定义模糊、不一致，例如项管部以项目部发文为开工，商务部以获取开工报告为开工。至此，我们已经可以明确问题的根源在于业务流层面，集团内部缺乏统一的制度、流程来明确项目各节点的划分标准，也没有明确以固定的流程节点划分项目状态。因此，要想治理各部门项目数量的数据问题，就必须在集团管理流程和标准上做出改善。

解决路径：从业务侧的角度，开展跨部门的沟通交流，统一项管部、人力部、商务部的项目状态定义标准；从信息侧的角度，完善项目状态各阶段划分流程，在OA系统中完善、改造流程节点；从数据侧的角度，根据现有流程优化取数逻辑，实现数据的来源一致和跨部门应用。

治理成果：最终，实现了跨部门项目数据的统一，规范了项目全生命周期的管理流程，完成了从数据问题洞察到数据治理的过程。

稳健的数据架构设计

在洞察到数据问题所在并进行了数据侧、信息侧或者业务侧的改善后，进行稳健的数据架构设计是拉式策略的第二个流程。这里主要涉及通过数据仓库建模、合理的分层设计、ETL 过程开发等，保障数据模型及架构的稳健性和可扩展性，从而提高数据使用的准确性。值得强调的是思考数据架构有三个出发点：稳健性、可扩展性和效率。数据仓库架构的稳健性需要通过数据仓库分层来解决；数据仓库的可扩展性要通过数仓建模、维度一致性等方式来解决；效率问题需要通过多系统数据集中、处理，从流程型数据架构转变到分析型数据架构来解决。

数据应用审核管控机制

我们数据治理策略的最后一个流程是建立一个企业内部，面向高层管理者的数据指标管控及审核机制，确保数据应用过程中（上报、可视化分析）的关键数据必须经过有效审核，提升数据使用质量及数据准确性。

以某集团的经营分析会数据审核流程为例，集团总部的填报用户保存、提交数据后，数据会被锁定并流转至集团总部的审核用户处。如果数据审核通过，它会被定版并做会前使用准备；如果数据审核不通过，它则会被退回填报用户处，并且系统会自动推送审核失败原因给填报用户，后台同步更新审核记录和状态。

子产业集团的填报用户提交数据后，流程情况与集团总部的填报用户类似，只是需要额外经过一轮子产业集团审核用户的审核。如果在子产业层面审核通过，数据将会做会前准备定版，流转至集团总部审核用户处。如果集团总部数据审核不通过，数据将会被直接退回子产业数据保存中心，并推送原因给子产业填报用户。总之，双重审核流程保障了子产业集团数据上报的准确性，进而提高了集团总部高层使用数据的质量。

归根结底，企业表层数据问题的产生往往有深层次的业务系统设计、流程制度管理方面的原因。因此要想通过数据治理提升企业数据的质量，就不能仅仅依靠一个工具或产品解决表象的问题。帆软提出了企业数据治理的拉式策略（Pull Strategy）和推式策略（Push Strategy）来满足不同的数据治理需求。考虑到当今企业面临的复杂环境，实施周期更短、治理成本更低的拉式治理策略更能及时满足企业数据消费的需求，是一种更灵活、更敏捷的数据治理方式。在该策略下，基于指标体系的“数据流-信息流-业务流”分析逻辑能够帮助企业发现、洞察、追踪数据问题产生的根源；稳健的数据架构设计能够帮助企业解决数据质量的问题；数据应用审核管控机制的建立能够帮助企业解决错误数据被使用的问题。经过系统化的数据治理，企业数据质量将更能满足消费的需求，基于数据的决策也将更加精准。

三、数据指标：企业监控与贯彻战略的抓手

大多数企业数字化转型已经取得初步成果，战略方向上基本明确，组织架构上有足够支撑，系统工具上基本完成建设。不过实际的转型效果依然参差不齐，不少机构仍然存在战略与执行脱节，取数难用数难，指标口径不统一，同名不同义等痛点。

究其原因，大多数的问题都在指标上，因为指标是监控与贯彻战略的抓手，取数、用数自然也是为了计算指标，口径不一等指标的痛点，自然也影响业务监测，进而导致战略与执行脱节。

因此，数据指标能否用得好，成为数字化转型的关键，本节将介绍数据指标在行业中的应用，重点围绕下面三点展开：

• 如何建体系？
• 如何建底层？
• 如何用指标？

1、如何建体系：自上而下&自下而上相结合

首先来介绍如何构建指标体系。

指标体系设计框架已较为成熟，主要来源于企业战略自上而下的演绎，以及一线业务实操自下而上的归纳。基于这种设计方法，再加上底层应用和管理体系的支撑，共同构成了一个整体的经营分析的指标库。

整体的目标制定是基于公司的发展战略，如十四五战略规划、数字化转型规划等，分析战略实现的决定性因素，梳理指示实现价值的可测量数据，进而形成一级指标，或称北极星指标。

指标体系是按照自上而下演绎、自下而上归纳两个方法结合，多维多层指标框架是对整个业务板块指标的梳理，在每一个板块里面横向展开指标业务的维度，纵向基于整个指标的层级，从战略指标展开至经营管理指标、业务执行指标。指标体系梳理完毕，应用包括可视化、流程、用户交互等。指标的管理体系，需要基于管理制度、管理流程、组织职责。

2、自上而下的方法：基于企业自身业务战略

基于公司业务发展战略，通过企业价值数分解，梳理企业核心关键KPI，形成指标库

战略衔接需要通过核心指标拆解成为各个部门的承接指标，但是这些指标中的维度和口径之间会有区别，这些区别是整个指标体系设计里面需要重点关注的各项标准。这里需要引入“价值数”的概念，可以理解为战略分解的关键影响因素，可以拆分为不同层次的价值流，比如绿色工厂里面可能会分解为相应的供应链，供应链里面又可以分解成为不同的价值流，包括每个环节的响应效率、每个环节执行的质量健康度、基于时效和质量产生的对应成本等。其次，这些价值流在不同业务板块都有不同的呈现方式，需要根据价值驱动因素优先级进行排列，比如目前哪些部门里面的哪些对应的价值流是需要核心先关注的。

自上而下的演绎包括制定北极星指标、建立价值树和价值驱动因素优先级，逐步拆解形成指标。例如，提升客户活跃和留存的北极星指标，可以拆成增加客户留存、提升产品销售能力和提升审批效率等二级指标，再向下可以拆成增加客户留存、提升客户粘性、提升客户忠诚度、促进交易量等子指标。

这种自上而下演绎的方法论和传统指标体系建设方式存在一定差异，传统指标体系通常是拆解到维度，而这里则注重指标上下级之间的关联。在大指标出现异常的时候，会对其下的子指标进行分析，寻找原因，而不是单纯的只看大指标的维度。

有了自上而下演绎得到的指标，为什么还要做自下而上的归纳呢？因为演绎过程中，可能为了追踪新的战略目标，而设置一些新指标，这些指标对一线业务来说是比较陌生的，因此还需要收集一线常用的指标并将其体系化，进行自下而上的归纳。两个方向相结合，形成最终的指标库。

3、自下而上的方法：基于企业现有指标体系

通过指标的收集、解析、整合和归类，形成指标库。

也叫做归纳法，通过梳理企业现有的经营指标去归纳总结，形成相应的指标互补，最终形成一个多维、多层级、全场景覆盖的指标树。比如提升渠道能力，可能涉及很多指标，我们把各个渠道的，比如网银的、客户经理产能的指标都细分出来，归纳到体系中，形成一个结合业务维度和技术维度的全场景的指标体系框架。指标在收集的过程中，一方面需要对一线的业务系统做收集，一方面要对当前日常汇报材料进行归纳汇总，包括定期复盘会、各级管理会议相应的资料，这些资料可以帮助去做整合归类，而整合中又会用到目前指标的业务维度、技术维度等。但是自下而上梳理的过程中，也存在不同部门之间可能会有重合指标的情况，而这些重合的指标甚至可能也会在对应口径上有出入。为了解决这种问题，最好的解决方式之一是设定业务的指标owner，不同业务的指标owner会帮助整个指标梳理的过程形成更好的聚合。

案例1：供应链环节

具体的指标盘点主要包括七大步骤，即通过调研访谈梳理业务条线、场景，以及业务流程和过程，覆盖所有业务条线和场景、流程，形成原子指标，进而形成衍生指标。

以供应链的采购执行为例，采购执行可以分为对整个物料需求的拆解，到需求的下单，再到供应商的对接。采购执行环节包含了不同的流程，整个信息流里面会包含单据，所以这些流程和单据帮助企业构成了一个业务环节，这个业务环节所对应的原子指标同时也可以明确出其分析维度，比如供应商的维度、对应产品线的维度、不同财务科目的维度等，这些维度可以帮助企业去拆解出来KPI。基于这样的KPI，就可以明确出计算逻辑，最终通过平台落地。

最终形成一个图谱，涵盖所有的环节，可以看到每个环节中有多少指标。如果某个环节没有指标，就说明存在遗漏，需要针对性地去补充指标；而如果某个环节指标偏多，则可能是KPI导向或者存在重复指标。这样梳理出的图谱就会比较完整，并且是基于统一价值链的。

• 需要特别注意“补数据”动作，不同的业务板块里面可以拆解出来相应的业务环节，以及对业务环节拆解出应的原子指标，但是同时企业也需要去注意采取主动或者被动的方式去补充相应的数据指标。比如供应链里面供应商的管理，需要去根据现在的系统做一个比照，包括供应商的降本、供应商的配额等，这样就可以帮助企业查看哪些数据已经覆盖，哪些数据还没有覆盖。

案例2：LTC环节

由上至下可以分成三层，决策层、管理层和执行层

决策层关注的人均产值、销售收入、净利润、资金周转、销售订单的情况，再往下拆解就对应到业务环节里面，包括销售拜访、订单签订流程、发货出运的流程等等。这些流程构成管理层想要的核心指标，并拆解成具体的维度，比如产品、订单、销售业务、财务等。继续往下看，这些维度会涉及到执行层里面详细的一些指标的战略体系，基于指标体系在价值流的过程中可以梳理出多维的价值动因分析，再去对相应的问题进行拆解指标，解决问题。

举一个场景的案例，比如要对目前某个期间内订单下滑明显的行业，以及对应的客户进行定位，就先要对客户的类型、当前合同类型、延期提货、以及订单状态等生命状态去做相应的监控。要注意去观察是否在某个期间内有客户的价格是明显低于红线价的，依照LTC环节，分解出一个一个价值的动因。通过这样的方式，最终可以解决在业务环节中国指标体系的完整性和业务问题。

4、形成指标库

指标定义，应包括业务属性、技术属性和管理属性，特别是属主部门非常关键，需要明确由哪个部门对该指标的定义负责，当指标数值出现偏差时谁负责修正，指标管理中的很多痛点都是源于属主部门没有定义清楚。

指标库分成三个视角去看，业务属性、技术属性以及管理属性。业务属性包括指标含义、指标业务口径、计算规则、统计区间以及相应的统计频率；技术属性包括系统的字段名称、指标数值类型、指标的技术口径等；管理属性包括指标分类和属主部门(指标的owner)。

5、指标全生命周期管理

指标体系建好之后，还要管理好。首先，需求收集流程要明确，即需求谁来提、谁来处理。指标的拆分创建流程，也要定义好各部门的职责。接下来，指标的审批、发布，后期的监控和失效归档，都需要建立相应的机制。譬如，某股份制银行的数据资产平台中存在6-7个AUM指标，无法明确该用哪个，所以只好再增加一个，如此下去就可能导致指标的无限增长，因此需要一套完善的体系对指标的使用进行监控、分析和管理。

指标管理角色的定义，分为指标的owner、指标落地的开发者，指标管理的维护者，指标的消费者。这些不同的管理角色可以对应到端到端的指标分解的流程（指标需求收集-指标拆分创建-指标发布应用-指标归档失效）中，以及管理制度中。

指标管理的第一步是进行指标需求的收集，需要对齐业务口径，数据初探以及梳理分歧/冗余指标。在整个指标全生命周期管理的过程中，需要每一个业务部门的高层牵头去做业务指标的定期优化改进，比如可以通过定期的复盘会的形式。

以经销商的运营分析体系为例：

将战略指标进行拆解，对于经销商的覆盖率会下沉到对每一个三-六线城市进行分析；对于库存是要考虑每一个工厂、每一个基地，每一个城市的分仓/中心仓等等。对于这些维度进行运营动作的分析拆解，比如考虑城市内的门店覆盖率，必备单品的品规数，相应门店活动的投资金额、品牌的覆盖等等。以大区负责人的视角为例，本月预估是可以4个大区达成75%，但是其中的东区整体目标达成只有70%。在这种情况下，需要去关注这些变化来分析东区。同时，可以通过看中心仓/分仓，以及不同的区域和经销商来看目前必备单品/新品库存。畅销品库存的情况等。这些库存的情况一方面可以帮助企业指导经销商大力去推广哪些品类，另外一方面可以帮企业通过经销商的视角去预测。

6、如何建底层：贴源-明细-汇总-应用

指标来自于数据仓库和数据集市，接下来看一下底层数仓/集市是如何搭建的。

数仓的标准结构包括ODS层、DWD层、DWS层、ADS层。目前很多企业在使用BI等数据应用的时候，数据直接由ODS对接到数据应用，缺少了中间各层的数据加工。应用层直接读取原始数据，由于明细数据量很大，会导致应用层很慢，不同的分析师从ODS从头按自己的理解加工，也会带来指标口径不一致的问题。因此企业一定要建数仓、建集市，一层一层地建设，最后通过ADS层来服务各类数据应用。

DWD层主要做清洗和落标的工作，对于垃圾数据、脏数据、空数据、不符合码值的数据会统一在这层做清洗，统一标准。同时在该层做一些维度退化，把表适度做宽。最后是做数据脱敏的工作。

DWS层，即汇总层，将数据汇总成服务于某一主题的宽表，不面向特定应用。

汇总层的表需要满足通用性，原则上不跨主题域，并且要标明统计周期，因为不同域的时效性不一样，还要避免将不同层级的数据放在一起。

如果直接从底层数据取数，那么指标的逻辑会写在SQL中。例如授信余额这一指标，业务含义是在授信额度上减掉已用额度所剩下的额度，如果没有提前在汇总层中把授信余额计算好，每个人对指标含义的理解可能不同，就会导致不同系统算出来的授信余额不一样，可能带来超额授信等风险。出现指标差异，要去查底层逻辑也会非常耗时耗力。如果把授信余额口径提前在汇总层加工好，在指做指标时只需要筛选客户类型，然后选中授信余额，就可以出指标，这样业务部门就有了自己分析指标的基础，因此数仓的良好构建非常必要。

7、如何用指标： BI分析为主，多层次应用

构建好底层数仓和指标体系后，接下来看一下如何应用指标。

BI分析是指标应用的主要场景，主要包括4种类型：

• 第一种是统计型，即基于现在的数据做统计分析，了解现在的数据呈现怎样的特征，这是大多数客户使用BI的场景。
• 第二种是归因型，即了解为什么数据会呈现某种统计结果，是由哪些原因导致的，可以通过指标的维度分布查看，也可以通过下钻查看关联指标和子指标的情况。
• 第三种是预测型，即根据现有的数据去预测未来的趋势。现在通常的做法是通过一个项目来做，例如在金融行业里预测下个周期的不良率，或某个客户的投诉概率，在风险领域的建模，就是这样一个过程，很少能通过BI直接完成这个建模和预测的过程。当然目前有拖拉拽式的自助式建模分析平台，这是另一条技术路线。
• 第四种是决策型，现在能做到这一步的非常少，或者说这不是BI的定位。决策型是指当发现某业务的趋势后，直接通过接口把需要修正的业务通过API发送给业务系统进行修正，例如改一个开关功能、改限额、改属性等，整体是把BI的边界做得很大，这是不是BI的职责目前还没有定论。但这确实是指标分析的终极目标，即能够完成从分析、归因到改进的闭环，并且能够监控改进后的结果。

目前绝大多数BI都属于统计型，包括报表和大屏一类的可视化应用。

随着人工智能技术近两年突飞猛进的发展，AI for BI这个赛道最近又热了起来，AI在统计型BI中，能帮用户做些什么呢？

利用大模型的能力，可以通过问答的形式，给到一些原因的提示，如果输入的内容其他人已经输入过，或者在库里能够匹配到这些度量或者维度，系统会做一些提示，也可以帮助引导分析思路。分析出来后，产品会把整个的意图和分析过程展示出来，由用户确认分析路径是不是有问题，用户也可以在上面直接去改维度和分析的度量。这就是目前FineBI在尝试的问答BI产品。

统计型BI更多的还是为你展示数据是什么样的，但不能告诉你为什么。基于这一问题， FineBI提供了数据解释的功能，可以初步完成归因和下钻。

比上图所示，可以看到2016年利润突然上涨很多，一般在传统BI中需要把该指标提出来，再去数仓中做分析。FineBI的数据解释功能，可以自动将利润指标所涉及的维度全查出来，这样就可以看到哪个维度占比最大，比如A产品的利润占88%，是主要的贡献者，可以继续下钻查看A产品在不同地区的销量，又发现华北的A产品销量贡献最大。这样就得到了初步的归因，但这还是基于维度的，有时维度差异不大，再往下钻维度差异也不大，就说明可能不是这些维度的影响，可能是底层其他子指标的影响，因此需要进一步的归因分析。

在完成初步的分析以后，还可以进行深度归因，这是基于指标体系构建时不同指标之间上下级的关系。

例如信用卡的透支余额指标，可能受卡数量和户均余额影响，这就是指标体系构建时，将北极星指标拆解到两个子指标，还可以继续下拆，比如卡数量可能受申请总量和通过率影响，申请总量又可以看不同的渠道，到底是线上还是线下渠道的申请总量变动比较多。

类似的拆分逻辑是基于业务知识的沉淀，通过大模型以及问答BI，学习业务人员的分析思路，最终体现在产品中，给出一些提示和建议。

比如在问答时自动弹出一些推荐，提示是否要看一些关联指标。这是AI在指标管理和BI领域中的一个非常好的应用场景。

预测型BI相对比较困难，目前大多是通过项目来实现。通常会涉及一些逻辑回归等模型，需要对大量的历史数据做处理，之后形成对未来的洞察。例如预测投诉，客户多次访问页面并在与客服通话中多次表达不满，这些都是客户投诉的前期表现，有了这样的数据积累后，就可以预测客户在哪些日期存在较大概率会投诉。如果通过BI或指标来分析比较困难，首先这其中涉及非常多的非结构化数据以及非数值数据，需要进行WOE或onehot变换，其次到底是哪些因素影响的Y变量，很难判断，需要非常多的数据积累，反复的调参以及业务人员的经验，因此通常通过项目来实现。

基于归因分析发现了问题根因，然后通过API或者在跳转业务平台的直接操作，完成问题发现、归因到解决的闭环。例如前面的例子，卡量下降8%，经过分析发现线上申请总量下降了9%，那么就要定位到线上渠道去解决问题，如果解决不了可以督办下去，这就涉及到经营分析的一些思路，即通过指标分析和归因识别到问题以后，督办问题负责人予以解决，把问题转给渠道管理来解决。

又比如，笔均交易额突然出现大幅下跌，笔均交易额通常是受交易渠道限额影响，接下来去分析渠道的限额，如果发现确实是交易限额有变化，就可以去修改限额设置，直接在BI里面完成接口修改。

这就是将来指标管理和BI产品的一个可能的方向，即完成统计、归因、预测、决策的闭环，在BI中直接解决问题，这样使数据分析的价值更加显性化。

指标体系都存储在指标库中，可以由专门的指标管理系统来存储，不过不必纠结于工具，比如我们团队的指标库就是基于飞书在线文档实现的，包括业务架构、指标清单、管理要素、指标模型、维度清单等，还包括常用指标展示的驾驶舱和数据应用场景等。例如前面举例的信用卡余额指标，拆解为数量和余额，以及进一步拆分成申请总量和通过率，这些都可以通过父子指标的层级配置实现。北极星指标的拆解关系都配在指标库中，业务人员想要分析时，只要在指标库里面查一下这个指标的下级指标都有哪些、怎样使用，还可以叠加不同的维度，就可以完成指标的下钻和归因分析。

数据项目的最大风险：建完了以后没人用

所有的产品的最终目标是让业务人员可以直接使用。然而目前在很多企业，BI的推广和使用还存在很多问题，比如一些年龄比较大业务人员不会使用或者说抗拒使用，还有些人认为应该由技术人员来做，数据分析的职责不清。

针对这些问题，最关键的是组织架构上，需要有相应的数据分析团队帮业务部门分析，而且数据分析团队最好内置在业务部门，每个业务团队有1-2个数据分析岗，这些人员由业务部门考核，逐步的让业务条线感受到数据的作用，以及数据分析上手不难，这是需要一个过程的。

数据项目的最大风险就是建完了以后没人用，因为数据项目与业务系统不同，通常是非刚需项目，不是雪中送炭，只是锦上添花，即没有这一套产品，业务也能生存下去。所以在做数据类项目时，经常是建完以后业务部门觉得学习或迁移成本太高，没必要用，业务部门还是习惯在原有的逻辑中去完成。甚至有一些业务人员认为数字化对其自身是一种威胁，原来所有的业务经验和知识，包括客户都在脑子里，如通过数字化的手段固化到系统中，那个人的价值在哪？因此要让业务人员充分参与，意识到产品能够减轻工作量而不是增加工作量，需要长期的宣导、培训、竞赛，把企业的数据文化建立起来，这是最核心的工作。

通常的培训都是产品上线后介绍产品操作方法，做起来非常简单，但是绝大多数情况下不起作用。现在帆软有专门的团队通过一套方法论来引导客户，而不是单纯的讲产品功能。整体包括数据人才诊断、培养和评估三个环节：先看整个组织架构有没有问题，包括人才体系建设、职能岗位职责分布；然后去做培训，有线上、线下、集中、分散、点对点、批量等多种方式；之后去做评估，包括FCA和FCP认证。

我们合作的客户中，例如华夏银行，就把指标派到了分行，要求每个分行都有一些工程师能够参与分析，这样就可以比较好地加强业务的积极性。在东亚银行，也做了很多培训和大赛，包括请领导站台、内部宣发、外部宣发等，使整个产品的使用比例有了大幅提升。当习惯用数据做决策后，这套系统就会成为业务人员工作中的必不可少的工具。

四、结语：BI赋能企业数字化转型，FineBI助力数据价值释放

本文系统梳理了BI技术从IT主导到业务赋能的演进历程，深入探讨了企业构建完整BI体系的关键路径。在数据成为核心生产要素的今天，商业智能已从单纯的报表工具进化为驱动企业数字化转型的核心引擎。

作为国内领先的BI解决方案，帆软FineBI凭借其三大核心优势，正成为企业数据价值释放的首选伙伴：强大的数据整合能力，支持从数据仓库建设到数据集成的全流程管理、智能化分析体验，AI驱动的自助分析功能让业务人员轻松获取数据洞察、行业化解决方案，覆盖金融、制造、零售等主要行业的深度应用场景

通过文中多个实践案例可以看到，FineBI不仅帮助企业实现了数据可视化分析，更在客流优化、仓储管理、港口运营等业务场景中创造了实实在在的商业价值。其独特的"IT+业务"协同模式，既确保了数据治理的专业性，又赋予了业务自主分析的能力。

未来，随着AI技术的深度融合，FineBI将持续升级智能化分析能力，包括：自然语言交互的智能问答、自动建模与预测分析、实时决策建议等创新功能

在数字化转型的浪潮中，FineBI愿与企业携手，共同探索数据驱动的无限可能。如需了解更多行业解决方案与实践案例，欢迎访问帆软官网获取最新白皮书与产品资料。

全文查看：帆软商业智能应用白皮书 5.0

数据驱动未来，FineBI与您同行！