300 万次出行的数据如何转化为决策？
一家轨道交通运营企业并不缺数据，而且数据相当充足。真正的问题在于，这些数据要多久才能到达决策时刻。
在一个每天完成约 300 万人次出行的大型轨道交通运营中，出行数据、现场检查、绩效指标和运营记录分别保存在不同的系统中。
企业应用、数据库、分析基础设施、报表工具和现场移动应用各自完成自己的工作。但对运营至关重要的问题，其答案并不集中在一处：
- 哪些线路的绩效在下降？
- 哪些车站存在问题？
- 来自现场的数据如何影响日常运营？
- 哪些指标需要采取行动？
数据是存在的。但将分散在不同系统中的数据汇集起来并加以理解需要时间。因此，问题不在于建立新的数据源，而在于让现有数据能够支撑决策。
在不替换系统的前提下构建共享数据层
解决方案并不是拆除现有系统再重建。企业应用、SAP 基础设施及其数十个模块、各类数据库、报表工具和现场应用都继续运行。
Butterfly 位于这些系统之上，让来自不同数据源的数据汇聚到统一结构中。这样，分布在不同系统中的数据汇集到了同一个决策层。
这一做法的核心在于：不替换现有技术投资，而是把现有系统产生的价值连接起来。最终，组织可以通过统一的运营视图访问分布在不同系统中的数据。
27 页的报告如今每天早上准时就绪
对运营团队而言，日报不只是一份文档，而是决定一天如何开始的核心信息来源。在本项目中，27 页的每日运营报告开始每晚自动生成。
团队不必把早上的时间花在从不同系统收集数据、合并文件和编制报告上，而是可以直接关注得出的结果。也就是说，流程变为：
- 数据收集 → 报告编制 → 审阅
- 数据 → 现成报告 → 评估 → 行动
从 30 分钟到 3 秒
数据汇集到同一结构中，改变的不仅是报表，还有查询速度。以前约需 30 分钟的查询，现在约 3 秒即可得出结果。
这一差异的意义超出了技术性能指标本身。如果得到一个问题的答案需要半小时，这个问题在运营过程中往往会被搁置。如果几秒钟就能得到答案，同一个问题就会自然成为日常决策机制的一部分。数据访问时间越短，决策距离也就越短。
来自现场的 10 万行数据，当天即转化为绩效指标
轨道交通运营持续产生现场数据。车站检查每天向系统录入约 10 万行数据。但仅仅将原始数据录入系统还不够。真正的价值在于将这些数据转化为对运营有意义的指标。
现场数据现在可以在当天反映到以下指标中：
- 线路绩效
- 车站绩效
- 人员绩效
这样，现场发生的情况与管理界面上呈现的结果之间的时间缩短了。现场 → 数据 → 分析 → 决策的链条随之加快。
6,000 条记录 5 秒内完成同步
不同系统协同工作的最大障碍之一，是能否在正确的时间、以正确的形式同步数据。在这一架构中，6,000 条记录约 5 秒即可完成同步。这样，来自不同数据源的信息能够在运营所需的统一视图中及时更新。
这里的思路很重要：目标不是把所有系统变成一个系统，而是让不同系统能够围绕同一项运营进行对话。
用户不再等待 IT 出报表，而是自己搭建界面
数据访问走向普及的另一个领域是报表。运营团队无需编写代码即可创建所需的仪表板。此外，他们还可以用自然语言向数据提问，获取所需信息。
因此，不必为每个新问题都提交新的报表需求或等待技术团队支持。IT 的角色从制作报表，转向提供让组织更有效地利用数据的基础设施。运营团队则可以直接使用所需的信息。
真正的转变不在数据量，而在决策速度
在这个例子中，处理数百万次出行的数据当然重要。但真正的关键不在于数据规模，因为大型组织本来就有数据：
- 在 SAP 里。
- 在数据库里。
- 在现场应用里。
- 在报表系统里。
真正的问题是：这些数据离需要做出决策的时刻有多近？
如果运营报告早上就已就绪，团队便可以从做决策而不是收集数据开始一天的工作。如果 30 分钟的查询 3 秒就能得出结果，被搁置的问题就可以重新提出。如果 10 万行现场数据当天就能转化为绩效指标，运营与管理之间的距离就能缩短。如果不同系统能够彼此对话，就可以在保护组织多年技术投资的同时，建立新的决策层。
因为数字化转型并不总是意味着更换系统。有时，真正的转型是让现有系统已经产生的数据更快、更易获取、更有意义。
结果
在每天完成 300 万人次出行的运营中，数据持续流动。创造价值的并不是数据的流动，而是数据在正确的时间转化为正确的决策。
Butterfly 无需替换现有企业系统，即可将不同数据源汇聚到统一结构中，帮助组织更快地从运营数据中得出结果。
不是更多数据，而是更快决策。