文章目录前言一、为什么说搞懂业务系统是 BI 的第一步二、企业核心业务系统ERP/OA/MOM核心逻辑与数据特点1. ERP企业的 “核心经营数据库”进销存 / 财务数据的核心载体2. OA企业的 “流程 / 组织数据库”支撑数据的维度补充与权限管控3. MOM制造业的 “生产现场数据库”生产型数据的核心载体三、业务系统与 BI 的底层关联数据对接的核心原则1. 先梳理业务流程再确定取数口径2. 统一基础档案实现跨系统数据关联3. 按 “业务系统 - ODS 层 - DW 层 - DM 层” 分层取数保留原始数据四、业务系统是数据治理的 “第一战场”五、从业务系统出发打好数据基础前言系列文章完整串联业务系统 数据集成 数据仓库 BI 落地全链路。业务系统第一步搞懂企业核心业务系统从 ERP/OA/MOM 到业务数据逻辑很多刚入门的朋友甚至一些做了几年的同行都会陷入一个误区一头扎进技术里死磕 SQL、ETL、可视化工具却忽略了业务系统是所有数据的源头。不懂业务系统的逻辑就摸不清数据的来龙去脉做出来的报表要么口径出错要么脱离业务实际更别说后续的数据分析和数据治理了。其实 BI 的核心是“用数据服务业务”而业务系统就是数据的 “根”。从 ERP 的进销存、财务数据到 OA 的流程、审批、组织数据再到 MOM 的仓库、生产、质量以及现场管理数据每一类业务系统都对应着企业核心的业务环节其数据逻辑直接决定了后续数仓搭建、数据抽取和分析的有效性。结合多年对接 ERP/OA/MOM 系统的实战经验聊一聊企业核心业务系统的核心逻辑、数据特点以及业务系统与 BI、数据治理的底层关联帮大家从源头搞懂数据打好 BI 入门的基础。一、为什么说搞懂业务系统是 BI 的第一步做 BI 的全流程本质是从业务系统取数数据集成 ETL— 数仓加工数据 (数据建模) — 可视化呈现数据报表可视化— 数据分析反哺业务业务系统作为数据的第一源头直接决定了后续所有工作的起点。我在过往多家企业做 BI 项目时接手过不少“烂尾” 的核心数据统计需求其中企业绩效考核分析表的搭建是最典型的痛点案例。企业原本希望通过 BI 系统实现绩效考核数据的自动化统计、可视化分析让绩效考评更精准、高效但落地过程中却问题百出最终这个需求迟迟无法落地沦为 “烂尾项”。核心问题集中在三点基础数据支撑严重不足业务系统中能直接提取的绩效考核相关基础数据不足两成绝大多数核心数据都需要人工线下填报导入不仅耗时耗力还极易出现人工录入的误差。绩效考评流程与指标定义不规范绩效指标不仅有大量通用规则还存在诸多排除项和特色场景规定 —— 比如因财务结算周期导致的物料入库不及时、因产线设备突发故障造成的产能不达标等情况均需在统计中单独剔除且这些特殊规定无统一标准全靠业务人员主观判断。绩效指标的多变性企业每年都会进行一次绩效体系改版上一年的考核指标刚完成开发、上线使用下一年的指标口径、统计维度、考核规则就迎来大幅调整开发工作陷入 “刚收尾就重启” 的循环。这些问题叠加直接导致了连锁反应绩效指标统计结果与实际考评情况相差甚远各类无法标准化、系统化的排除因素让数据在人工调整中进一步失真失去了分析的参考价值而每年一次的改版让系统的可维护性极差开发成果无法复用。最终不仅没能实现绩效考核的数字化反而让数据统计工作陷入低效、混乱的困境这个数据分析需求也因此直接烂尾。还有一次对接集团 OA 系统做企业流程审批时效性分析时我也曾踩过“重技术取数、轻业务逻辑”的坑。最初为了快速出结果直接从 OA 系统中提取了所有流程的全量节点数据简单通过下一节点到达时间 − 上一节点审批完成时间计算节点审批时长仓促完成报表开发并发布。但报表上线后立刻收到各环节节点人员的大量反馈统计数据完全失真不少在工作时间内正常审批的流程被统计为 “超时时长”抄送、知会这类无需人工审批的节点也被纳入考核统计部分流程因节点回退、重新提交出现审批时长重复统计这份报表完全失去了参考价值。后续沉下心梳理 OA 系统的业务流程逻辑才找到数据失真的核心原因对流程审批的数据业务流完全不了解仅用技术逻辑生搬硬套计算规则。针对问题逐一优化后才做出贴合实际的流程时效性分析修正时长计算逻辑以节点审批完成时间 − 节点到达时间计算做节点筛选剔除抄送、知会、传阅等非审批节点增加时间校准自动排除法定节假日、休息日及非工作时段也正是这次踩坑让我更深刻意识到脱离业务逻辑的技术取数做出来的报表再精致也毫无意义懂业务、摸透数据背后的业务流才是 BI 工作的核心前提。这些问题的核心归根结底都是对业务系统的底层业务逻辑、数据结构认知不足更未与业务方做好需求的深度对齐与实操确认仅靠技术思维生搬硬套取数、统计逻辑最终导致数据信息与业务实际严重脱节失去了数据分析的核心价值。而对于数据治理而言业务系统本身的标准化程度更是决定了数治工作的根基牢固与否如果业务系统从源头就存在编码不统一、字段定义模糊、数据录入无规范的问题那么后续即便投入大量精力做数据清洗、制定数据标准也只能是治标不治本最终陷入事倍功半的低效困境。多年 BI 实战总结下来懂技术的 BI 工程师能做好报表懂业务系统 技术的 BI 工程师才能做对、做深报表更是向数据治理进阶的关键二、企业核心业务系统ERP/OA/MOM核心逻辑与数据特点结合我实操过的 ERP集团进销存 / 财务、OA泛微 / 致远、MOM含 MES/QMS/WMS三大核心系统拆解其核心业务逻辑、关键数据维度以及对接 BI 时的核心要点这些都是我在实际项目中踩坑后总结的干货新手直接套用就能避坑。1. ERP企业的 “核心经营数据库”进销存 / 财务数据的核心载体ERP 是企业最基础、最核心的业务系统覆盖采购、销售、库存、生产、财务等核心经营环节也是 BI 数仓中最核心的数据来源。我曾在集团企业做数据仓库搭建时核心就是对接 ERP 系统的进销存数据通过 Kettle、Datax、Kafka、Flink 等离线实时工具跨库整合搭建起集团全业务条线的数仓基础这一经验在后续汽车流通行业的项目中也发挥了核心作用。核心业务逻辑围绕企业 “人、财、物、产、供、销” 形成闭环所有操作都以 “单据” 为核心采购单、销售单、入库单、出库单、财务凭证等单据的状态流转草稿 / 审核 / 作废 / 完成直接决定数据的有效性。关键数据维度基础档案客户、供应商、物料、产品、组织架构业务单据采购 / 销售 / 库存单据财务数据应收 / 应付 / 成本 / 利润库存数据结存、调拨、盘点BI 对接核心要点① 重点关注单据的审核状态未审核的单据不纳入正式分析② 统一基础档案编码如物料编码、产品编码这是后续数据整合和数据治理的基础在汽车流通行业的进销存数据梳理中编码统一更是解决数据孤岛的关键③ 区分 “实际发生数” 和 “计划数”避免混为一谈2. OA企业的 “流程 / 组织数据库”支撑数据的维度补充与权限管控OA 系统主要覆盖企业的行政办公、流程审批、组织管理、人员管理等环节看似不是核心业务数据载体但却是 BI 分析中重要的维度补充也是数据治理中 “主数据组织 / 人员” 的核心来源。我曾参与 OA 项目建设主要负责需求蓝图调研、报表开发和权限管理深刻体会到 OA 数据对 BI 的重要性无论是汽车流通行业还是航空制造业组织与人员数据的标准化都是跨系统数据整合的前提。核心业务逻辑以 “流程审批” 为核心覆盖请假、报销、采购审批、合同审批等全流程同时存储企业核心的组织主数据、人员主数据部门、岗位、员工信息、汇报关系。关键数据维度组织数据部门编码 / 名称、层级人员数据员工编号 / 姓名 / 岗位 / 所属部门流程数据流程编号、审批节点、审批状态、处理时长行政数据办公用品、会议、考勤BI 对接核心要点① OA 的组织 / 人员数据是 BI 分析的核心维度如按部门分析业绩、按岗位分析产能必须保证与 ERP/MOM 系统的组织编码统一这一要求在航空制造业的生产数据梳理中尤为严格② 流程数据可用于做 “运营效率分析”审批时长、流程通过率反哺企业管理优化③ 人员 / 组织数据是数据治理中主数据管理的重要组成部分其标准化程度直接影响跨系统数据整合的效率3. MOM制造业的 “生产现场数据库”生产型数据的核心载体MOM制造运营管理系统是制造业的核心业务系统整合了 MES生产执行、QMS质量管理、WMS仓储管理等子系统覆盖生产计划、车间执行、质量检验、仓储物流等全生产环节。我曾主导 BI 系统建设核心工作之一就是对接 MOM 系统开发现场管理看板、生产绩效报表和部门驾驶舱在航空制造业的项目中更是深度体会到生产型数据的精细化与复杂性要求。核心业务逻辑以 “生产工单” 为核心从生产计划下达、工单开工、工序执行、质量检验到成品入库形成闭环全程记录生产现场的每一个环节数据强调实时性、精细化这也是航空制造业对生产数据的核心要求。关键数据维度生产计划数据工单编号、产品型号、计划产量、计划工期车间执行数据工序编号、实际产量、工时、设备状态质量数据检验批次、不合格品数、合格率、不合格原因仓储数据原料入库、成品出库、库位状态BI 对接核心要点① MOM 数据实时性要求高需结合 Kafka/Flink 做实时数据同步我在项目中用 Kafka 做数据变更抓取Flink 做实时计算测试满足现场看板的实时展示需求② 生产数据维度多、粒度细需按 “工厂 - 车间 - 产线 - 工序” 做分层梳理适配不同层级的分析需求航空制造业的精密生产环节对数据粒度的要求更是达到工序级③ 质量数据是制造业 BI 分析的核心需与生产工单、物料数据做关联实现 “质量问题溯源分析”这是航空制造业质量管控的关键环节三、业务系统与 BI 的底层关联数据对接的核心原则懂了业务系统的核心逻辑接下来就是把业务系统的数据对接至 BI 系统这是 BI 建设的第一步也是我在多个 0-1 BI 项目中反复验证的核心环节。结合 ERP/OA/MOM 的对接经验以及汽车流通行业、航空制造业的项目实操总结 3 个核心原则新手按这个原则做能避开 80% 的坑。1. 先梳理业务流程再确定取数口径不要直接从业务系统抽字段先跟业务人员确认业务流程。比如做汽车流通行业的门店销售业绩分析先问清楚“销售业绩” 的定义是订单金额还是实际回款金额统计维度按门店 / 按销售顾问统计周期自然月还是结算月再比如做航空制造业的产能分析明确 “产能” 是按计划工时还是实际产出再从对应系统中找到字段和数据逻辑避免 “技术自嗨”。2. 统一基础档案实现跨系统数据关联ERP 的物料 / 产品数据、OA 的组织 / 人员数据、MOM 的产线 / 工序数据这些基础档案是跨系统数据整合的 “桥梁”。我在搭建企业级数仓时第一步就是做基础档案的标准化统一编码规则统一字段定义统一数据格式比如让 ERP 和 MOM 的物料编码保持一致OA 和 ERP 的部门编码保持一致。在汽车流通行业统一车型、配件的编码规则让进销存数据与财务数据无缝关联在航空制造业统一零部件、产线编码实现生产数据与质量数据的溯源分析这都是跨系统整合的核心前提。3. 按 “业务系统 - ODS 层 - DW 层 - DM 层” 分层取数保留原始数据对接业务系统数据时不要直接加工后存入数仓而是先在 ODS源数据层全量同步业务系统的原始数据再在数仓的二次处理层、主题分析层做清洗、转换、整合。这样做的好处是一旦后续数据出现问题可追溯至原始数据方便排查满足不同的分析需求避免因前期加工导致数据丢失这也是我在所有 BI 项目中坚持的原则ODS 层绝对保留原始数据所有加工都在后续层级完成这也是数据治理中 “数据溯源” 的基础要求无论是汽车流通行业的进销存数据还是航空制造业的生产数据数据溯源都是保障数据准确性的关键。四、业务系统是数据治理的 “第一战场”很多朋友问我从 BI 向数据治理进阶该从哪里入手我的答案是从业务系统入手。多年 BI 实战我无数次遇到数据治理的痛点数据孤岛、编码不统一、字段定义混乱、数据质量差……而这些问题的根源大多都在业务系统层面跨系统数据孤岛本质是 ERP、OA、MOM 各自为战基础档案编码不统一数据质量差本质是业务系统录入不规范如物料编码重复、客户名称简写 / 全称混用我在做汽车流通业进销存数据梳理、航空制造业生产数据治理时第一步都是梳理业务系统的现状检查基础档案的标准化程度梳理业务单据的流转逻辑规范数据录入规则比如在航空制造业数据治理中先统一 MOM 系统的零部件编码和生产工单编号规则再做后续的数据清洗和数仓整合效率直接提升了 60%在汽车流通业项目中先规范 ERP 系统的客户 / 供应商编码解决了跨部门数据协同难的问题这也是数据治理的核心逻辑数据治理不是从数仓开始而是从数据的源头 —— 业务系统开始。做好业务系统的标准化基础档案、编码规则、字段定义才能为后续的数仓建设、数据分析、数据资产化打下坚实的基础这也是我从 BI 实战转向数据治理后最深刻的体会之一。五、从业务系统出发打好数据基础做 BI 多年从最初的数据库工程师到数仓搭建、BI 架构设计再到数据治理深耕我最深的感悟是技术是工具业务是核心而业务系统是连接技术和业务的桥梁。对于刚入门的 BI 朋友不要急于死磕技术先花时间去了解企业的业务系统走进业务部门跟业务人员聊流程打开 ERP/OA/MOM 系统梳理数据结构和单据流转搞懂每一个字段的含义每一个数据的来源当你真正懂了业务系统再结合技术做数仓、做报表、做分析会发现一切都顺理成章无论是汽车流通行业的商贸数据还是航空制造业的生产数据底层逻辑都是如此。而对于想从 BI 向数据治理进阶的同行业务系统的实操经验更是我们的核心优势我们懂数据的源头懂业务的逻辑懂 BI 的全流程能让数据治理落地到业务实际而不是空中楼阁的理论。本文的引用仅限自我学习如有侵权请联系作者删除。参考知识BI 入门第一步搞懂企业核心业务系统从 ERP/OA/MOM 到业务数据逻辑
