去年底，我作为信息化负责人参与了一家医院集团多院区食堂的统一数字化改造。这个项目的难点不在单个院区，而在于"集团化"------三个院区、十几个经营点，数据口径各异，总部要的是实时看得见、管得住。今天把我们在数据中台架构和运营日报自动推送上的实践整理出来，供做类似项目的同行参考。
先明确痛点：数据割裂是根因
改造前，各院区食堂的收银、采购、食安系统互不相通，数据结构、字段口径都不一致。总部想出一份全院经营汇总，得靠人工跨系统搬数据，周期长、易出错。所以这个项目的核心目标不是"上个大屏"，而是先解决"数据对齐"这个底座问题。
数据中台的分层设计
我们采用了一套经典的分层架构，好伙狮数字食堂的场景大数据平台大体也遵循这个思路，我把它抽象成四层：
采集层：对接收银、进销存、留样、晨检、AI明厨亮灶等异构数据源，通过统一接口（RESTful + 消息队列）把数据拉进中台。关键是把各源的数据做标准化清洗，统一时间、金额、门店等基础字段。
存储层：经营数据走关系型库，食安视频类告警走对象存储，实时指标进内存缓存。分层存储既保证查询性能，也控制成本。
计算层：对客流、营收等指标做实时聚合，对历史数据做离线统计，生成各院区的经营画像和对比口径。
服务层：对外暴露两类能力------一是供驾驶舱大屏消费的实时数据接口，二是供运营日报消费的定时汇总任务。这一层是"看见"和"预警"的出口。
运营日报的自动推送实现
运营日报是这个系统里"投入小、收益大"的一块。核心是一个定时任务：每天固定时间，聚合前一日的经营、食安、告警数据，生成日报并推送到管理者手机。伪代码示意如下：
# 每日 08:00 触发（cron: 0 8 * * *）
def build_daily_report():
stores = get_all_stores() # 获取所有院区经营点
for s in stores:
s.revenue = agg_revenue(s, yesterday) # 昨日营收
s.flow = agg_flow(s, yesterday) # 昨日客流
s.alerts = get_food_safety_alerts(s) # 食安告警
report = render(summary(stores))
push_to_manager(report) # 推送至手机
log_success()这里有两个工程要点。一是数据必须由系统自动聚合，杜绝人工填报，否则日报就失去了"客观"这个前提。二是异常项要单独标注，让管理者一眼看到"今天哪里不对"，而不是在一堆数字里自己找。
驾驶舱的实时数据链路
驾驶舱大屏对实时性要求高，我们走的是"采集 → 消息队列 → 流式计算 → 推送大屏"的链路。客流、营收这类指标秒级更新，食安告警则在事件发生后即时推送。相比日报的"日级"，驾驶舱解决的是"当下正在发生什么"。
这里有个容易踩的坑：大屏如果直接连多个业务库做联表查询，高峰期会把源库拖垮。正确做法是把大屏的数据需求收敛到中台的实时服务层，由中台统一供给，业务库只做数据源，不做查询面。
食安告警：AI视觉 + 物联网的联动
这套系统里技术含量最高的是食安告警模块。摄像头采集后厨画面，视觉算法实时识别未戴口罩、明火离岗、鼠患等违规行为，识别到即触发告警，同时联动留样、晨检等物联网数据，统一沉淀到中台的食安主题域。这样管理者在一个看板上就能看到全院的食安风险全貌，实现从"事后追责"到"事前预警"。
落地后的几个经验
第一，别贪大求全。先把经营和食安这两个最痛的维度打通，比一上来就"全量数据中台"现实得多。第二，数据质量是生命线，源头不准，上面全是空中楼阁，上线后要有专人盯口径。第三，一线抵触是最大的隐性成本，尽量让数据自动采集，少让一线手工录入，项目才推得动。
小结
医院食堂集团化管控，本质是个"数据对齐 + 可视化 + 预警"的问题。技术上没有特别玄乎的东西，难在把异构数据真正统一起来、把口径真正对齐。底座做扎实了，驾驶舱和日报才有价值。如果你也在做类似项目，这三点建议可以直接拿去用。
你们医院食堂系统目前的数据口径统一了吗？欢迎在评论区交流，聊聊你在多院区数据整合里踩过的坑。