商业智能（BI）与数据可视化

人工智能与数据
├── 数据工程侧
│   ├── 大数据开发工程师
│   ├── 数据治理与数据质量
│   └── 商业智能（BI）与数据可视化 ← 本篇
├── 数据洞察侧（数据分析师）
└── 模型与策略侧（算法／MLOps／AI 应用／推荐搜索）

定位一句话：BI 岗位让数据"出现在该出现的人眼前"——把散落在系统里的数字做成能一眼看懂、能钻取、能定时送达的看板，减少每次开会都靠临时取数的消耗。

为什么它归在"数据工程侧"而非"数据洞察侧"：它交付的是可复用的工具与体系（看板、语义层、自助查询能力），而不是针对某个问题的结论；产出会被反复使用，因此工程属性更强。

一句话定义：商业智能（BI）与数据可视化岗位负责企业报表与看板体系的设计与实现，包括分析场景与指标层级的规划、语义层与指标模型的建设、可视化呈现与交互设计、自助分析能力的推广赋能，以及报表性能、权限与使用情况的持续优化。

职责边界（五类日常）

一、报表体系规划

梳理各层级使用者的决策场景，设计从总览到明细的看板层级与刷新频率，控制报表数量。

• 先问"看完这个要做什么决定"：能对应到动作的报表才有价值。回答不了这个问题的需求，通常可以合并或不做。
• 分层设计：管理层看趋势与异常，中层看结构与对比，执行层看明细与清单。三层混在一张看板里，谁都看不舒服。
• 宁可少而准：报表数量膨胀是这类岗位的常见困境，且维护成本会随时间累积。

二、语义层与指标模型

把物理表结构加工成业务可理解的字段与指标，统一口径并集中维护。

• 指标定义要写下来：名称、口径、计算逻辑、责任人、更新时间。口径靠口头约定的团队，注定会反复出现"两个部门数字不一样"。
• 集中维护的核心价值：同一个口径改一次即可全局生效，不必在每个报表里单独改。
• 与数据治理的分工：语义层是"呈现与计算口径"的统一层，底层数据质量与主数据归治理侧，两者要共享同一份指标白名单。

三、可视化设计

选择合适的图表类型与信息层次，处理配色、标注与移动端适配。

• 几条够用的规则：比较大小用条形图；看趋势用折线图；看构成用堆叠或占比；看分布用直方图或箱线图。分类过多时不要用饼图。
• 避免误导：双轴图容易制造虚假关联；纵轴不从零开始会放大差异；颜色数量超过五到六种就难以区分。
• 结论前置：把关键数字与结论放在最上方，让使用者三秒内知道"今天要不要细看"。

四、自助分析赋能

培训业务人员使用自助查询工具，处理求助与排障，把高频需求逐步转化为可自助的模板。

• 推不动的常见原因：口径没统一（业务不敢信）、工具太复杂（学习成本超过收益）、没有现成模板（每次从零开始）、缺少答疑人（出错就放弃）。
• 有效的做法：先为三五个高频场景做好模板，再培训，能显著提高留存。

五、优化与治理

优化查询性能与刷新计划，管理行级权限与数据敏感度，统计报表使用情况并定期下线无人使用的资产。

• 性能与成本：大宽表全量刷新、无索引的明细查询都会拖垮仓库，需要靠预聚合与增量刷新控制。
• 权限分级：按组织与角色控制可见范围，敏感字段单独处理；权限设计通常是上线前最容易遗漏、事后最难补的部分。
• 下线机制：统计访问情况，把长期无人使用的看板归档。只增不减的报表体系，会持续消耗维护与计算资源。

指标体系怎么分层

1. 一个北极星层——衡量整体结果的核心指标，通常只有一个到三个；
2. 一级指标层——能解释北极星变化的少数关键因子（规模、转化、客单、成本等）；
3. 二级与过程指标层——各环节的可干预动作指标，供执行层使用。

分层的意义在于归因路径清晰：北极星掉了，能顺着层级往下找到具体环节，而不是把几十张报表一起翻。缺少这套结构的团队，最典型的表现是"问题一来，全员临时取数"。

一个看板从需求到上线要经过什么

1. 确认使用场景与决策动作——谁看、多久看一次、看完做什么；
2. 核对指标口径——是否已有定义，若没有则先定口径（与治理侧同步）；
3. 确定数据来源与刷新频率——时效要求决定是实时、准实时还是 T+1；
4. 设计版式与图表——先画草图与业务确认，再动手做；
5. 上线后跟踪使用情况——访问量、反馈与修正需求，据此迭代。

第 2 步常被简化，却最容易返工：口径没定就先做图，最后往往推倒重来。

需求排山倒海时怎么排序

一、先给需求分类

• 探索性需求——业务自己也没想清要看什么，这类需求更适合先用临时取数或分析支持，不建议直接做看板；
• 监控性需求——定期看核心指标是否正常，适合做固定看板，重点在稳定与及时；
• 决策性需求——服务于特定决策场景（复盘、预算、考核），这类需求价值最高，也最需要与业务一起设计。

二、判断优先级的四个问题

1. 谁用——是决策者、管理者还是执行者；
2. 多久看一次——每天看还是每季度看一次；
3. 看完做什么动作——能落到动作的最优先；
4. 不做会怎样——影响面越大越靠前。

三、把重复需求变成产品能力

同一个取数需求被提三次以上，就说明它具备产品化价值：做成模板、自助查询能力或固定的看板模块。判断这项工作的成效，看的不是交付了多少张报表，而是临时取数需求是否在减少。

四、主动管理预期

体系建设期最容易被临时需求挤空。可行的做法是把固定比例的工时留给体系建设，并让业务方知道排期规则——不是拒绝需求，而是让需求有可预期的节奏。

常见误区：把看板当成绩展示

一种很常见的失败模式是——看板做得很漂亮，会议上被夸了几次，之后就没人打开。原因通常有两个：一是信息太多，使用者需要自己找结论；二是没有和任何决策动作绑定。

可用的判断标准很朴素：打开这张看板的人，能不能在三秒内知道"今天要不要细看"。若做不到，就该删掉一半内容、把关键数字前置，或者干脆合并到别的看板里。

报表体系的价值不在于数量，而在于"需要的时候它正好在"。

再补一条判断：看板的可用寿命通常比预期短。业务调整之后，一批指标会失去意义，继续展示只会干扰判断。因此定期做一次清理很有必要——下线无人查看的看板、合并内容重复的看板、把口径已过时的部分明确标注，让整个体系保持在可维护的状态。

相邻岗位辨析

三组最容易混的场景：

• BI vs 数据分析师：都要面对"业务问数据"。分界是产出形态——一次性结论归分析师，可复用的看板与工具归 BI。现实中两个岗位常在同一个人身上，判断自己算哪种，看"我的交付里，有多少会被别人再打开一次"。
• BI vs 数据工程：都要处理表与口径。分界是加工深度——把原始数据整理成可用的表归数据工程，把表变成业务可理解的指标与图表归 BI。指标口径这类"中间地带"必须有归属约定，否则会出现两套定义并存。
• BI vs 数据产品经理：都要规划"做哪些数据能力"。分界是是否定义方向与优先级：产品定做什么、为什么做；BI 定怎么做、怎么让它被用起来。

判断口诀：做看板与报表体系、管语义层与自助工具 → BI；回答某个业务问题 → 分析师；管数据加工 → 数据工程；定数据产品规划 → 数据产品经理。

不同企业类型下的差异

• 电商与零售：指标多、节奏快，重心在实时看板与大促期间的稳定性。
• SaaS 与互联网产品：看行为与留存漏斗，事件埋点的可信度是关键前提。
• 制造与供应链：看产能、交期与库存，数据源系统多，跨系统口径统一是主难点。
• 金融与合规敏感行业：权限、留痕与口径审计要求高，报表变更流程更重。
• 集团型企业：多主体、多层级，重心在合并口径与向下钻取的一致性。

入行与转出（公开口径）

• 背景：统计、信息管理、计算机、经济学、管理类背景均可见；常见来源是数据分析师、数据开发、业务运营转岗，也有大量从业务侧"取数取出来的"人转正。
• 前置知识：SQL 熟练（必备）＋ 一款主流 BI 工具的实际项目经验 ＋ 数据建模与指标设计基础 ＋ 可视化与信息设计常识；对业务指标体系的理解是关键差异点。
• 面试通常怎么考察：常给一个业务场景要求现场设计看板（画什么图、分几层、口径如何、怎么权限控制），也会追问画图工具的具体实现与性能问题。作品集里如果能展示"改造前后的使用率变化"，说服力最高。
• 常见入口：① 企业的数据分析或 BI 团队；② 从业务部门的数据专员转专业岗；③ 从数据仓库实施、系统集成商转甲方；④ 从财务、运营分析岗转 BI。
• 适配画像：对"别人看不看得懂"极其在意——交付标准是使用者能自助看懂；耐心处理大量细节与临时需求；善于与业务对话，能分辨"他想要的图"与"他真正需要的信息"。
• 两个常见认知误区：① 以为 BI 就是"画图"，技术含量低——指标口径与语义层设计才是门槛；② 以为看懂板的人自然会用——推广与答疑占实际工作量很大一部分。
• 职业特点：这是企业数字化的基础配置岗，行业横跨度大、需求稳定；风险在于长期停在"做报表"层级会被自助工具与自动化替代，向上要走指标治理、数据产品化或业务分析。另需注意：临时取数需求容易挤压体系建设时间，需要主动管理预期。
• 转出方向：转数据分析与经营分析、转数据产品经理、转数据治理与指标管理、转业务部门的分析与运营岗。