药企数据工作者的困境与解法，未名企鹅告诉你

先说一个画面。

周二上午，销售总监问："华东区上个月哪些处方药动销下滑超过10%？"

会议室安静三秒。没人能当场回答。

散会后，问题变成邮件发给IT。IT跨三个系统、五张表，写SQL、拼结果、对口径两天后，答案才到总监手里。

这不是任何一个人的问题。是数据组织方式的问题。同一个问题，在一个公司里折磨着四种完全不同的人。

你需要随时了解业务动态，但每次跨系统提问都必须经过IT。提问→等排期→等SQL→等对口径→等报表→拿到答案。

等拿到的时候，问题可能已经不是问题了。

你缺的不是数据量，是数据之间的关系。

解法：把"表中心"换成"实体中心"。系统先搞清楚终端、药品、人员、区域之间的关系网，你问什么它顺着网就能回答，不需要跨表写SQL。管理者应该用数据做决策，而不是等数据。

你的本职是分析，但日常是打开五个Excel，口径不同、字段不同、粒度不同。花半天统一、半天拼表——拼完发现今天结束了。

你花80%时间准备数据，只有20%时间思考。这个比例应该反过来。

问题还是"表中心"。每张表是孤岛，分析师成了人工桥梁。

解法：让知识图谱在数据接入时就自动串联表之间的业务关系。数据自己"长了腿"，分析师的双手才能腾出来。

市场部要终端分级，建一张。销售部要区域达成，建一张。财务部要费用效率，再来一张。三年上百张，建表成本不如维护成本高——但停不下来。

宽表只是止痛药，不是治疗方案。

解法：不针对每个问题建宽表，而是用知识图谱建一套实体关系网。一个图谱，所有问题。IT从"建表工"变回"架构师"。

系统里几十上百张表，字段、口径、维度全不一样。一张一张啃，两周勉强上手。领导突然问个新组合问题——回到原点。

新人能不能快速上手，考验的是数据组织得好不好。

解法：打开系统，直接用自然语言提问——"华东区上个月处方药动销怎么样？"语义建模层自动翻译，系统听懂人话。新人第一周就能创造价值，而不是背字段名。

四个角色，四种痛，同一个问题：你的数据有没有"长在一起"？

管理者在等，因为数据没有关系。分析师在拼，因为数据是孤岛。IT在建，因为底层没有关系网。新人在背，因为系统听不懂人话。

这套解法，我们把它做进了产品里——底层知识图谱串联实体关系，中间层语义建模翻译业务语言，顶层自然语言问答驱动决策闭环。

四种人的困境，是一个架构问题。而架构问题，不应该由人来扛。