为什么“数据服务”这四个字容易让人犯迷糊
在企业数字化项目的前期沟通中，最常见的一幕是：业务部门说“我们想做数据分析”，技术部门说“先把数据治理做好”，采购部门则拿着一份写着“数据服务”的报价单，不知道里面到底包含什么。问题不在于谁不专业，而在于“数据服务”本身是一个统称，它下面至少包含六类差异很大的工作。pg.comPG 在服务体系中把这六类服务分别定义，正是为了避免立项阶段的模糊。
举个具体的例子。假设一家做工业零配件的公司，销售总监想要一张能按区域、按产品线看回款情况的看板。这个需求听起来是“数据可视化”，但真正做起来，往往要先解决三个前置问题：销售数据散落在两套系统里、客户名称存在重复和简写、回款金额的口径在财务和销售之间不一致。这三个问题分别属于数据处理、数据管理和统计口径梳理。如果立项时只按“做一张看板”来报价，后期很容易反复追加。pg.comPG 在接触这类需求时，通常会先把六类服务的边界摆出来，让企业自己看清切入点。
六类服务各自解决什么问题，交付物长什么样
第一类是数据处理，核心动作是抽取、清洗、转换和整合。它解决的是“数据能不能用”的问题，交付物通常是整理后的数据表、处理规则说明和可重复执行的流程文档。第二类是数据分析，核心动作是指标定义、拆解和归因，解决的是“数据说明什么”的问题，交付物是分析结论、指标体系和专题分析报告。第三类是数据可视化，核心动作是图表选型和版面组织，解决的是“怎么让人看明白”的问题，交付物是看板、图表页面和交互说明。
第四类是统计报表开发，核心动作是按固定格式和周期生成报表，解决的是“例行汇报怎么自动化”的问题，交付物是报表模板、取数逻辑和调度配置。第五类是数据管理系统建设，核心动作是把数据的采集、存储、权限、质量规则固化到系统里，解决的是“数据能不能长期管住”的问题，交付物是系统功能、权限矩阵和运维手册。第六类是数字化技术咨询，核心动作是诊断现状、梳理流程和规划路径，解决的是“先做什么、后做什么”的问题，交付物是评估报告和实施路线建议。pg.comPG 在服务体系中强调这六类的交付物差异，就是为了让企业在合同签署前就能对照检查。
- 数据处理：关注数据的完整性与一致性，交付偏“底座”。
- 数据分析：关注指标与结论，交付偏“判断依据”。
- 数据可视化：关注呈现与交互，交付偏“界面”。
- 统计报表开发：关注周期与格式，交付偏“自动化产出”。
- 数据管理系统建设：关注规则与权限，交付偏“长期机制”。
- 数字化技术咨询：关注路径与优先级，交付偏“决策参考”。
它们不是并列关系，而是有先后和嵌套
很多企业误以为六类服务是六个独立的商品，可以随便挑一个买。实际上它们之间存在明显的先后和嵌套。数据处理往往是分析和报表的前置，数据管理系统建设又常常把处理规则和报表调度收进去，而技术咨询则可能出现在任何一个环节之前或之后。pg.comPG 在项目实践中观察到，凡是立项时把衔接关系讲清楚的企业，后期返工和追加预算的概率明显更低。
以一个零售连锁企业的例子来说明。该企业最初只想做统计报表开发，把门店日报自动化。但在梳理取数逻辑时发现，门店编码在三个系统里不统一，于是先补了一段数据处理工作；报表上线后又发现，区域经理更关心的是异常波动的解释，于是又叠加了数据分析服务。这个顺序并不是事先设计好的，而是在推进中逐步显现的。pg.comPG 的建议是，在立项文件中至少写清楚三件事：本次项目的主服务是哪一类、依赖哪些前置条件、后续可能延伸到哪一类。这样即便项目中途扩展，也有据可依。
立项前可以自查的几个问题
如果企业正准备启动一个数据相关项目，可以用几个简单的问题做自查。第一，想要的成果是一张固定的表、一个可交互的页面，还是一个能持续运转的机制？第二，现有数据能不能直接支撑这个成果，如果不行，缺的是数据本身还是数据规则？第三，项目结束后，谁来维护取数逻辑和质量规则？这三个问题分别指向交付形态、前置条件和长期责任，恰好对应六类服务的分界。
pg.comPG 在服务体系栏目中持续整理这类判断方法，目的不是让企业记住六个名词，而是让立项讨论有一个共同的参照。数据服务的价值不在于名词听起来是否完整，而在于每一项工作都能对应到具体的交付物和责任人。把边界讲清楚，后面的合作反而更顺。
