项目类型: 业务理解类 | 展示业务 sense 与数据分析能力 所属公司: 河南九州通医药有限公司 项目时间: 2021 年 8 月 - 2023 年 3 月（持续性工作，约 1.5 年） 项目角色: 数据分析核心执行者
一句话项目概述
针对医药企业快速多变的经营分析需求，建立敏捷的数据服务机制，通过 100+ 个参数化 SQL 脚本库，将非标取数需求的响应时间从 3-5 小时缩短至 1 小时内，累计响应 1000+ 次复杂查询，为中高层管理者提供 T+0 决策数据支持。
项目背景 (Situation)
业务痛点
需求堰塞湖：
- 医药行业政策多变（集采、两票制、DRG 等），业务部门常有突发性、复杂的取数需求
- 标准报表开发需要排期，通常需要 1-2 周
- 标准报表无法满足 “T+0” 的敏捷决策需求
数据口径混乱：
- 不同部门对 ” 销售额 ” 定义不一致（发货口径 vs 开票口径）
- 不同人提取的数据结果不一样，导致 ” 数据打架 ”
- 业务会议上经常因为数据口径争论不休
业务场景示例：
- 销售总监：” 今天下午 3 点开会，需要分析上个月各区域的毛利率，按客户等级分类 ”
- 采购经理：” 紧急！需要查出所有库龄超过 6 个月的商品，按供应商汇总 ”
- 财务总监：” 月底了，需要核查所有负毛利销售单据，看是否有录入错误 “
角色定位
作为 ERP 技术支持工程师，我不仅要解决系统故障，还承担起了 ” 业务数据分析师 ” 的角色，成为业务与数据之间的桥梁。
项目目标 (Task)
核心 KPI
- 响应速度: 将复杂非标取数需求的响应时间从3-5 小时缩短至 1 小时内
- 数据准确: 建立统一的数据提取标准，消除 ” 数据打架 ” 现象
- 能力沉淀: 建立可复用的参数化 SQL 脚本库，覆盖 80% 的常见取数场景
- 风险防控: 通过数据监控脚本，主动发现业务误操作和财务风险
个人职责
- 充当 ” 业务翻译 “，将业务需求转化为 SQL 查询逻辑
- 编写高质量的 SQL 脚本，确保数据准确性和性能
- 建立参数化脚本库，实现 ” 输入变量，立等可取 ”
- 赋能业务人员，培训基础 SQL 查询能力
关键行动 (Action)
阶段一：建立 ” 业务翻译 ” 机制
1. 明确业务需求（最关键的一步）
很多业务人员不懂技术，他们的需求往往很模糊。我的工作是把模糊的业务语言转化为精确的技术语言。
典型对话场景：
业务人员："我要看销售额"
我："是发货金额还是开票金额？"
业务人员："开票金额"
我："含税还是不含税？"
业务人员："不含税"
我："包括赠品吗？"
业务人员："不包括赠品"
我："时间范围？"
业务人员："上个月"
我："按什么维度汇总？客户？区域？还是销售员？"
业务人员："按区域"建立需求确认清单：
- 数据范围：时间范围、客户范围、商品范围
- 统计口径：含税/不含税、是否包括赠品、是否包括退货
- 汇总维度：按客户、按区域、按商品、按时间
- 输出格式：Excel、PDF、还是直接屏幕展示
2. 统一数据口径
针对高频的业务指标，制定统一的定义：
- 销售额: 不含税开票金额，不包括赠品和退货
- 毛利率: (销售额 - 成本) / 销售额 × 100%
- 库龄: 当前日期 - 最早入库日期
- 应收账龄: 当前日期 - 发货日期（未收款部分）
制作《数据口径定义手册》，发给各业务部门，提高沟通效率，避免歧义。
阶段二：SQL 脚本库建设（核心技术资产）
沉淀了 100+ 个常用场景的参数化 SQL 脚本库
1. 销售分析类（15 个脚本）
2. 库存分析类（12 个脚本）
3. 财务风险监控类（10 个脚本）
4. 采购分析类（8 个脚本）
5. 其他分析类（5 个脚本）
阶段三：数据服务流程标准化
建立敏捷响应机制
数据服务流程：
1. 接收需求 → 通过企业微信/钉钉
2. 需求澄清 → 确认数据口径（5分钟）
3. 脚本匹配 → 检索脚本库，是否有现成脚本（5分钟）
4. 快速开发 → 如果没有现成脚本，快速编写（30-50分钟）
5. 数据验证 → 抽查数据合理性，确认无误（5-10分钟）
6. 交付结果 → 导出Excel或截图发送（5分钟）
7. 脚本归档 → 如果是新场景，归档到脚本库响应时间承诺：
- 已有脚本的需求：15 分钟内交付
- 需要新开发的需求：1 小时内交付
- 特别复杂的需求：当天交付
阶段四：赋能业务与知识传递
不仅 ” 授人以鱼 “，更 ” 授人以渔 ”
1. 培训业务骨干
- 针对财务、采购等部门的业务骨干，培训基础 SQL 查询
- 教会他们使用脚本库中的参数化脚本
- 让他们能够自助完成简单的数据查询
2. 编写《SQL 自助手册》
- 常见查询场景的 SQL 模板
- 参数替换方法说明
- 风险提示（如不要执行 DELETE、UPDATE）
3. 建立 ” 数据服务群 ”
- 在企业微信建立 ” 数据服务群 ”
- 业务人员在群里提需求
- 也鼓励懂 SQL 的业务人员互相帮助
量化成果 (Result)
核心成果
-
响应速度大幅提升:
- 累计响应500+ 次复杂数据查询
- 平均交付时间从3-5 小时缩短至 1 小时内
- 效率提升约70%
-
数据质量提升:
- 建立统一的数据口径标准
- 消除了 ” 数据打架 ” 现象
- 业务会议上因数据争论的情况明显减少
-
能力资产沉淀:
- 建立包含50+ 个参数化脚本的 SQL 脚本库
- 覆盖80% 的常见取数场景
- 实现 ” 输入变量，立等可取 ”
-
风险主动防控:
- 通过监控脚本，成功规避多次因业务录入错误导致的潜在财务审计风险
- 负毛利销售预警帮助财务部门在月结前发现并纠正问题
-
业务赋能:
- 培训了 10+ 名业务骨干掌握基础 SQL 查询
- 部分简单的取数需求可以由业务人员自助完成
个人价值体现
- 业务理解深度: 能够将复杂的业务需求转化为 SQL 逻辑，证明深入理解医药行业的业务规则
- 数据分析能力: 熟练使用 SQL 进行复杂数据分析，能够快速提取有价值的信息
- 服务意识: “T+0” 响应，为业务决策提供及时的数据支持
- 知识沉淀: 将临时性工作转化为可复用的资产
技术栈清单
| 类别 | 具体技术 |
|---|---|
| 数据库 | Oracle Database 11g, PL/SQL |
| 核心技能 | 复杂 SQL 查询（多表关联、子查询、分析函数、窗口函数）, 数据分析, 参数化查询 |
| 工具 | PL/SQL Developer, Toad for Oracle, Excel (数据透视表、图表) |
| 业务领域 | 医药行业业务规则, 销售/采购/库存/财务业务流程 |
面试准备：常见问题与应对
Q1: 你在这个项目中具体做了什么？
回答要点：
” 我承担了 ’ 业务数据分析师 ’ 的角色，为中高层管理者提供敏捷的数据服务。主要做了三件事：第一，建立 ’ 业务翻译 ’ 机制，把业务人员模糊的需求转化为精确的 SQL 查询；第二，建立包含 50 多个场景的参数化 SQL 脚本库，覆盖 80% 的常见取数需求；第三，通过监控脚本主动发现业务风险。最终将数据响应时间从 3-5 小时缩短到 1 小时内，累计响应 500 多次查询。“
Q2: 你是如何理解业务需求的？
回答要点：
” 理解业务需求是最关键的一步。我的方法是：第一，主动提问，不要想当然。比如业务说 ’ 要销售额 ‘，我会问 ’ 是发货金额还是开票金额？含税还是不含税？包括赠品吗？‘；第二，建立需求确认清单，包括数据范围、统计口径、汇总维度、输出格式；第三，制定《数据口径定义手册》，统一各部门对关键指标的理解。通过这些方法，确保提取的数据准确无误。“
Q3: 给我举个复杂查询的例子
回答要点：
” 举个例子，销售总监要求 ’ 分析上个月各区域的毛利率，按客户等级分类，要看到 A 类客户和 B 类客户的毛利率差异 ‘。这个需求涉及 4 张表的关联：销售订单、客户、区域、成本。我需要理解毛利率的计算公式，理解客户等级的定义，然后用 GROUP BY 按区域和客户等级分组，用 SUM 聚合销售额和成本，最后计算毛利率。整个查询大概 30 行 SQL，但逻辑很清晰。“
Q4: 如何保证 SQL 性能？
回答要点：
” 医药企业的数据量很大，千万级是常态，SQL 性能很重要。我的优化方法：第一，合理使用索引，确保 WHERE 条件的字段有索引；第二，避免 SELECT *，只查询需要的字段；第三，合理使用分析函数（如 ROW_NUMBER），避免多次嵌套查询；第四，对于特别复杂的查询，先创建临时表，分步处理。通过这些方法，大部分查询能在 5 秒内返回结果。“
Q5: 这个项目对你后续工作有什么帮助？
回答要点：
” 这个项目让我深刻理解了 ’ 数据驱动决策 ’ 的价值。后来转岗做基础设施时，我依然沿用这种数据驱动的方法：监控数据分析、容量规划、性能优化，都是基于数据而不是感觉。另外，这段经历让我明白，技术人员不能只懂技术，必须深入理解业务，才能提供真正有价值的服务。“
可能的追问点与应对策略
追问 1: ” 如果业务需求的数据 ERP 里没有怎么办？”
准备答案：
- 先确认是否真的没有：ERP 系统很复杂，可能数据在其他表里
- 如果确实没有：看是否能通过其他系统获取（如 WMS、TMS）
- 如果无法获取：向业务解释清楚，建议调整需求或通过其他方式获取
- 记录这类需求，作为系统改进的输入
追问 2: ” 你编写的 SQL 会不会影响数据库性能？”
准备答案：
- 所有查询都是只读的，不会修改数据
- 避开业务高峰期执行复杂查询（如选择中午或晚上）
- 与 DBA 沟通，了解数据库负载情况
- 对于特别复杂的查询，先在测试环境验证性能
追问 3: ” 如果你提供的数据有错误怎么办？”
准备答案：
- 数据验证机制：交付前抽查数据合理性，如总数是否匹配
- 业务确认：对于重要的数据，请业务人员抽查确认
- 可追溯：保留 SQL 脚本和执行时间，方便事后核查
- 如果发现错误，立即修正并通知相关人员
追问 4: ” 标准报表和你的 SQL 脚本有什么区别？”
准备答案：
- 标准报表：固定格式，开发周期长，但稳定可靠
- SQL 脚本：灵活敏捷，快速响应，但需要技术支持
- 我的定位是**” 补充 ” 而不是 ” 替代 ”**
- 对于高频固定的需求，建议开发成标准报表
- 对于临时性、多变的需求，用 SQL 脚本更合适
项目亮点提炼（电梯演讲版 -30 秒）
” 在 ERP 运维期间，我承担了 ’ 业务数据分析师 ’ 角色。针对医药行业快速多变的取数需求，我建立了包含 50 多个场景的参数化 SQL 脚本库，将数据响应时间从 3-5 小时缩短到 1 小时内。通过监控脚本主动发现风险，帮助财务部门规避了多次潜在的审计问题。这个项目让我深刻理解了医药行业的业务规则，也培养了数据驱动的工作方式。“
适用场景
推荐在以下情况使用此项目：
- ✅ 应聘需要SQL 能力的岗位（数据分析、运维开发、技术支持）
- ✅ 岗位 JD 提到业务理解、数据分析、快速响应
- ✅ 面试官关注服务意识和业务 sense
- ✅ 公司有ERP/SAP 等企业级系统（容易产生共鸣）
- ✅ 想展示技术 + 业务的复合能力
不推荐在以下情况使用：
- ❌ 纯技术深度岗位（可能觉得 SQL 太基础）
- ❌ 强调大数据/机器学习的岗位（技术栈不匹配）
- ❌ 互联网/SaaS 公司（可能觉得 ERP 太传统）
业务理解的体现
这个项目充分展示了对医药行业业务的深度理解：
1. 财务业务:
- 理解毛利率、应收账款、成本核算等财务概念
- 理解含税/不含税、发货/开票的差异
2. 销售业务:
- 理解客户等级（A/B/C 类）、销售区域、销售员绩效
- 理解赠品、促销、退货等特殊业务场景
3. 采购业务:
- 理解供应商管理、采购订单、质量检验
- 理解准时交货率、质量合格率等 KPI
4. 库存业务:
- 理解库龄、滞销品、先进先出 (FIFO)
- 理解批次管理、效期管理（医药行业特有）
面试时可以说：
” 这个项目让我不仅是技术人员，更是业务专家。我深入理解了医药行业的业务流程、管理指标、风险控制点。这种业务理解能力是我的核心竞争力，也是我能够快速适应新环境的基础。”