数据中台花了几百万,业务还是只会拉Excel.Palantir那套本体论,到底能救什么?

一、从 Palantir Ontology 的思路出发，看企业如何让数据真正理解业务

企业建设数据中台，通常会经历数据接入、数据建模、指标管理和报表分析等阶段。

数据逐渐汇集起来，经营指标也越来越丰富，但一个现实问题依然存在：

管理者看到了订单数量，却不一定知道哪些订单需要优先处理；看到了客户信息，却不一定能判断不同联系人是否属于同一次购买需求；看到了交付数据，却未必能结合客户的真实诉求判断交付风险。

这说明，数据汇集和报表建设并不意味着企业已经真正理解了业务。

数据记录了业务发生的事实，而业务决策还需要进一步理解：这些数据描述的是谁、彼此之间有什么关系、当前处于什么状态，以及什么情况下需要采取行动。

这也是企业本体（Ontology）受到关注的原因之一。

以 Palantir 的 Ontology 思路为例，它强调围绕真实业务对象组织数据，将对象关系、业务规则与实际操作联系起来。

对于已经开展数据中台建设的企业而言，这一思路也带来一个值得思考的问题：如何把业务人员理解的业务语义，转化为数据团队能够建模、计算和分析的数据？

二、数据并不少，真正缺少的是对业务的统一理解

在企业内部，客户、订单、产品、设备等信息通常分散在不同业务系统中。

各系统按照自身业务需要记录数据，字段定义、状态划分和统计口径也可能有所不同。

例如，销售部门关注客户是否下订，交付部门关注车辆是否完成交付，管理层则希望了解订单规模和交付进度。

每个部门都有自己的数据，但当这些数据需要放在一起回答一个具体业务问题时，差异就可能显现出来。

Palantir 提出的 Ontology（本体）可以为理解这类问题提供一种思路。

它并不是简单地把不同系统的数据放到一起，而是尝试以企业真实业务为基础，将系统中的数据组织成有明确含义的业务对象，并描述对象之间的关系、业务规则以及可以关联的操作。

从概念上看，可以从四个方面理解企业本体：

• 对象与属性：企业中有哪些业务主体？例如客户、订单、车辆、设备等，它们分别具有什么属性和状态？
• 关系：不同业务对象之间存在怎样的联系？例如客户与订单、订单与车辆之间是什么关系？
• 规则：业务按照什么条件判断？例如什么情况下算作有效订单，什么情况下需要优先跟进？
• 行动：形成业务判断后，可以采取什么操作？例如联系客户、核实交付时间或更新业务记录。

这四个方面共同构成了从业务信息到业务判断的理解框架。

因此，企业本体关注的不只是数据之间能否关联，更重要的是这些关联是否符合真实业务，以及能否支撑后续分析和决策。

三、用汽车销售场景理解：数据为什么有时回答不了业务问题？

以一家汽车销售企业为例。

企业已经建设了客户管理系统、订单系统，也能够通过销售报表查看新增客户数、订单数量和交付情况。

日常经营数据看起来并不缺少，但销售主管提出一个具体问题时，仍然可能需要多个部门反复核对：

目前有哪些已经下订、尚未交车的订单需要优先跟进？涉及多少金额？下一步应该联系谁？

这并不是一个简单的订单筛选问题。要得到可信的结果，至少需要处理三个方面的信息。

1. 同一笔业务，可能存在不同的统计口径

销售团队可能按照定金到账统计成交，交付团队则按照车辆完成交付统计业绩。

两种统计方式对应不同的业务阶段。如果没有明确区分，同一笔交易在不同部门的报表中就可能出现不同结果。

因此，在分析订单之前，需要先明确企业所说的“成交”“下订”和“交付”分别代表什么，以及每个状态对应哪些业务条件。

2. 联系人不等于购买机会

再看一个更容易被忽略的情况。

一个家庭共同购买汽车，成员 A 负责联系门店并签订订单，成员 B 是主要用车人，两个人还一起参加了试驾。

客户管理系统可能记录了两位联系人，但实际业务中，他们参与的是同一次购车需求。

如果直接按照联系人数量统计购买需求，就可能把一次购车机会计算成两次。

而且，家庭成员可能几年后再次购车，即使参与者相同，新的购车需求也应当作为一次独立机会记录，不能简单地与历史交易合并。

这说明，企业不仅要知道系统里有哪些客户，还要理解客户、家庭、购买方、联系人、用车人和购车机会之间的业务关系。

3. 判断是否需要跟进，不能只看订单状态

订单系统记录了车辆预计交付日期，但客户真正期望的提车时间，可能只存在于销售人员的沟通记录中。

例如，某位客户希望在月底前提车，而系统中的预计交付日期已经排到了下个月，即使订单状态仍然正常，这笔业务也可能需要销售人员提前沟通。

反过来，如果客户期望提车时间还没有核实，就不能直接将其判断为交付风险。

因此，要回答“哪些订单需要优先跟进”，除了订单状态，还需要结合客户诉求、信息来源和当前有效性进行判断。

4. 先统一业务对象，再明确业务规则

针对上述场景，可以先将“购车机会”定义为一次独立购买需求的核心业务对象。

个人是具体的自然人，家庭用于描述已经确认的成员关系；联系人、购买方、用车人等，则是个人在某次购车机会中承担的不同角色。

例如，成员 A 和成员 B 可以共同参与一次购车机会，也可能在几年后再次发起新的购买需求。

两次需求应当分别记录，通过不同的购车机会标识进行区分。

围绕购车机会，还需要关联参与人员、试驾活动、订单及沟通记录。

这样才能判断哪些信息属于同一次购买需求，减少多人参与、重复签单等情况带来的统计混淆。

业务对象明确之后，还需要进一步定义购车过程中的关键节点。

以本案例为例：

• 试驾：区分预约试驾与实际完成试驾。
• 下订：约定为订单确认且定金到账。
• 交车：约定为车辆完成正式交付。
• 取消：作为独立的状态变更记录，并保留发生时间。

在这些定义的基础上，就可以筛选出已下订、未交车且未取消的有效订单，再结合预计交付日期和客户期望提车时间进行判断。

例如，当预计交期晚于客户已经确认的期望时间时，可以将对应购车机会标记为高优先级，提醒销售人员及时沟通；如果客户期望时间尚未核实，则先标记为待核实，而不是直接认定存在交付风险。

至此，业务对象、业务事件和判断规则之间形成了明确联系：

对象说明业务主体，事件记录业务事实，规则帮助识别当前状态，最终为后续行动提供依据。

四、让业务定义落到数据中：从业务规划到数据模型

明确业务语义只是第一步。对于企业而言，还需要解决一个实际问题：业务人员理解的“购车机会”，如何在不同系统的数据中得到准确表达？

企业原有的客户表、订单表和销售指标已经包含大量业务信息，但不同系统的字段命名、数据来源、关联方式和统计条件可能并不一致。

业务人员理解的一个业务对象，也不一定直接对应数据库中的某张表。

这就需要将业务定义进一步落实到数据模型、指标口径和数据资产管理中。

qData 数据中台可以通过业务规划、规范建模、指标管理和数据资产管理等能力，帮助企业把业务定义逐步落实为可管理、可计算、可追溯的数据。

1. 业务规划与规范建模：让业务对象在数据中有明确对应

在 qData 数据中台中，业务规划可以通过业务对象与业务活动描述企业的实际业务。

其中，业务对象主要描述参与业务的人和事物，例如客户、车辆；业务活动则用于描述发生在某个时间点的事件，或持续一段时间的业务流程。

回到汽车销售场景：

• 客户、车辆可以作为业务对象；
• 试驾完成、定金到账可以作为业务事件；
• 订单从成立到交付或取消，可以作为业务流程进行描述。

完成业务规划后，还需要将业务定义落实到具体的数据模型中。

例如，可以通过维度逻辑表组织客户、车辆等对象的属性，通过事实逻辑表记录订单、试驾、交付等业务事实，并配置数据来源和关联关系。

在这个过程中，“购车机会”是否具备可靠的唯一标识非常关键。

只有能够识别一次独立的购车需求，才能将相关参与者、订单和业务活动准确关联到同一次业务中。

如果原有业务系统没有直接提供购车机会标识，就需要结合已有业务记录建立映射规则，并对无法确定归属的信息进行核实，而不能简单地按照联系人或订单数量推断。

2. 指标管理：让不同部门按照统一口径理解业务

当企业能够识别需要跟进的购车机会后，销售主管通常还会进一步关心：涉及多少次购车机会、多少张订单、多少金额？

这几个指标看似相近，实际统计口径并不相同。

购车机会数需要按照购车机会标识去重；订单数量需要按照有效订单编号统计；金额则需要明确具体取值范围和计算方式。

例如，在本案例中，可以采用当前有效订单的约定总额作为金额统计口径，排除已经取消的订单，同时避免多人参与、重复签单或订单变更导致金额重复计算。

如果这些定义没有提前统一，即使各部门使用同一份数据，也可能因为统计条件不同而得出不同结果。

qData 的指标管理能力，可以通过原子指标定义基础计算逻辑，再结合业务限定和统计周期构建派生指标，帮助企业统一指标定义和统计口径。

这样，业务人员看到的不只是一个数字，还能够进一步明确这个数字统计的是什么、按照什么条件计算，以及是否符合当前业务分析的需要。

3. 数据资产与血缘：让分析结论能够追溯来源

当不同部门对分析结果产生疑问时，企业还需要能够回答：

这个字段来自哪里？经过了哪些加工？为什么采用这样的过滤条件？

qData 的数据资产与血缘能力，可以帮助用户查看字段说明、数据来源以及上下游加工关系，进一步核对 SQL 中的过滤条件、关联关系和去重方式。

不过，订单数据并不能解释全部业务情况。

客户的交车诉求、车型偏好和特殊要求，可能保存在销售人员的沟通纪要或其他文档中。

例如，家庭成员 B 曾提出希望提前提车。只有确认这条记录属于当前购车机会，并且客户的要求依然有效，才能将其与订单预计交付日期进行比较。

对于结构化信息，可以通过数据集成和建模建立关联；对于文档中的业务信息，则需要结合文档处理、信息提取和必要的人工核实，将有效信息关联到对应业务对象。

因此，企业在组织业务知识时，不能只关注信息是否汇集起来，还需要明确每条信息的业务归属、来源依据和适用范围。

否则，即使数据越来越多，也可能因为关联错误或使用了过期信息而影响判断。

五、从智能问数到业务跟进：让数据分析参与实际业务

经过业务规划、数据建模和指标管理，企业已经能够按照相对统一的口径理解客户、订单和购车机会，并形成可用于分析的数据基础。

但对于销售主管来说，最终目标并不是完成一套数据模型，而是找到当前需要优先跟进的业务机会，并获得相应的判断依据。

在相关数据已经准备好的前提下，qData 智能问数可以进一步帮助业务人员通过自然语言查询业务数据。

1. 用自然语言提出具体业务问题

例如，销售主管希望找出当前已经下订、尚未交车且需要优先关注的购车机会，可以直接提出：

查询当前已下订、未交车且未取消的购车机会，找出预计交期晚于客户期望时间的记录，并展示对应订单金额。

需要说明的是，自然语言查询并不意味着可以跳过数据准备工作。

要得到可信结果，企业需要提前准备好相关事实表、关联维表和必要的数据关系，并确保订单状态、预计交期以及经过核实的客户期望时间等信息已经整理为可查询的数据。

2. 从查询结果中找到需要关注的业务机会

qData 智能问数可以根据自然语言问题生成 SQL，并通过智能洞察、数据明细和可视化图表等方式呈现查询结果。

销售主管可以据此查看需要关注的购车机会、对应订单金额、预计交付时间及客户期望时间，了解当前业务中值得进一步核实和处理的部分。

如果对查询结果存在疑问，还可以结合 Text2SQL 与明细数据核对查询条件，并通过数据资产和血缘信息追溯相关字段来源。

这样，业务人员看到的就不只是汇总数字，而是能够围绕具体业务问题查看对应记录，理解分析结果的依据。

3. 分析结果还需要进入实际业务流程

识别出需要关注的购车机会之后，销售人员可以根据分析结果制定后续跟进计划。

例如，对于预计交期晚于客户期望时间的订单，销售人员可以先联系交付团队核实车辆状态，再与客户确认是否接受新的交付安排。

如果客户需求已经发生变化，则需要及时更新业务记录，避免后续继续使用过期信息。

这里需要明确 qData 与业务执行环节之间的边界：qData 提供数据依据和分析结果，实际的客户联系、跟进任务及处理反馈，仍然由销售人员或业务系统完成。

如果企业进一步通过数据服务将分析结果提供给销售系统，并结合销售系统已有的任务和流程机制，就可以逐步形成从问题识别、人工确认、业务跟进到结果反馈的闭环。

这也是企业本体思路值得关注的地方：数据不再只是用于事后统计，而是围绕具体业务对象和业务规则，为实际业务判断提供支持。

六、企业本体建设，不妨从一个具体业务问题开始

企业本体听起来涉及业务对象、关系、规则和行动等多个方面，但这并不意味着企业必须从零开始重构全部数据架构，也不需要一次性梳理所有业务对象。

更可行的方式，是从一个边界清晰、能够产生实际业务价值的问题开始，在真实业务中逐步验证。

可以参考以下五个步骤：

• 第一步：明确业务问题。

先确定希望解决的具体问题。例如，找出哪些已下订但尚未交车的购车机会需要优先跟进，并明确需要哪些数据、判断依据和处理动作。

• 第二步：统一业务语义。

由业务团队明确购车机会、下订、交车等概念的定义；数据团队则核实相关字段来源、关联关系和统计口径，确保双方对业务含义有一致理解。

• 第三步：通过小样本验证。

选择少量真实业务记录进行验证，重点检查多人参与是否导致重复统计、已取消订单是否被错误纳入，以及历史沟通内容是否被误用于当前购车机会。

• 第四步：应用到实际业务。

将分析结果提供给销售团队，观察判断是否准确、数据依据是否可信，以及是否真正帮助销售人员完成后续跟进。

• 第五步：沉淀并逐步复用。

当核心业务对象、流程节点和指标口径经过验证后，再逐步扩展到试驾跟进、车型推荐、订单交付和售后服务等场景。

写在最后

从 Palantir Ontology 的思路可以看到，企业本体的价值并不只是建立一套业务对象关系模型，而是让分散的数据、业务规则与实际行动围绕统一的业务语义组织起来。

对于已经开展数据中台建设的企业而言，这并不意味着必须推翻原有的数据架构。

更重要的是从真实业务问题出发，逐步统一业务对象、关系、事件和指标口径，再将这些定义落实到可计算、可追溯的数据中。

qData 数据中台可以在这一过程中提供业务规划、规范建模、指标管理、数据资产管理和智能问数等数据建设与分析能力，为企业理解业务状态、识别需要关注的事项提供数据依据。

当然，从分析结果到实际业务行动，还需要业务人员的判断、核实和执行，也需要结合企业现有业务系统的流程机制。

当业务语义能够被准确描述，数据关系能够被合理组织，分析结果能够为业务判断提供依据，数据中台的价值也就不再局限于数据汇集和报表展示，而是进一步延伸到业务理解与决策支持。