河南九州通医药有限公司 | ERP 支持工程师
任职时间: 2021 年 3 月 - 2023 年 3 月（2 年） 所属部门: IT 应用运维组（5 人团队） 汇报关系: 向技术组长汇报
职位概述
作为 ERP 技术支持团队的核心执行者，为河南公司 150 亿 + 年营收规模的 Oracle ERP 系统（涵盖采购、销售、库存、财务全模块）提供 L2 级技术保障。通过 Oracle PL/SQL 数据分析、BPM 流程引擎维护、ITSM 标准化体系建设，主动解决业务阻塞点，保障核心系统连续性。个人主导的知识库建设项目荣获集团创新嘉奖。
核心技术栈: Oracle PL/SQL · BPM 流程引擎 · ITSM 服务管理 · 业务数据分析 · ERP 供应链逻辑
核心职责
1. 核心业务系统连续性保障
- 负责 Oracle ERP 采购、销售、库存、财务全模块的 L2 级技术支持，解决数据逻辑错误、接口传输故障、系统配置冲突等深层技术问题
- 在月度财务结账与年度库存盘点期间担任技术值守，通过快速数据修正确保财务账实相符，业务不中断
2. 数据分析与敏捷 BI 支持
- 利用 Oracle PL/SQL 直接从数据库提取高维经营数据（如批次药品库龄分析、负毛利销售拦截分析），为中高层管理者（业务部门经理、企业管理部、总经理）提供 T+0 决策数据支持
- 编写数据校验脚本，定期巡检系统脏数据（无主库存、未核销应收），主动消除财务合规风险
3. BPM 流程引擎技术实现
- 负责集团 BPM 流程引擎的技术配置落地，将企业管理部设计的内控审批规则转化为准确的系统节点与触发逻辑
- 解决复杂的审批流 ” 死循环/断链 ” 问题，协助业务部门优化冗余审批节点，提升供应链流转效率
4. 知识工程与标准化体系建设
- 引入 ITSM 标准化问题管理流程（接收→诊断→修复→归档），建立 50+ 场景的 SQL 脚本库与故障处理知识库
- 将个人经验转化为团队可复用资产，显著缩短新员工上手周期
关键项目经历
项目 1: ERP 架构升级（v2→v3）数据清洗与业务验证支持
时间: 2022 年 6 月 - 2022 年 12 月（7 个月） 角色: 应用侧核心执行者（负责数据一致性校验与业务逻辑验证）
项目背景 集团推行 ERP 架构升级，引入多业务实体 (OU) 与库存组织 (IO) 的强财务隔离架构。历史数据中存在大量逻辑脏数据（无主库存、未核销负数等），若直接迁移将导致新系统财务账实不符，构成严重合规风险。
核心任务
- 确保新旧版本财务/库存数据一致性 100%
- 实现升级切换期间业务零停摆，降低一线操作员学习成本
关键行动
- 基于 SQL 的数据清洗工程: 编写复杂 PL/SQL 关联查询脚本，对千万级历史数据进行全量逻辑扫描，精准定位并修正 500+ 条深层脏数据（无成本记录的库存、借贷不平的凭证），消除迁移风险
- 全链路业务穿测: 在沙箱环境中组织业务骨干进行 P2P（采购到付款）和 O2C（订单到收款）全流程测试，重点验证新架构下的权限隔离与自动记账逻辑，输出《v3 版本差异化操作手册》
- 分级响应机制: 设计分级响应通道，切换上线当周实施 7×24 小时现场值守，对架构变更导致的业务阻断实现 15 分钟内响应修复
量化成果
- 实现 ERP v3 平滑上线，升级窗口期无 P0 级重大业务事故
- 编写的《常见报错速查表》与数据校验脚本被集团推广至其他省公司
项目 2: 基于 PL/SQL 的经营数据分析与敏捷 BI 支持
时间: 2021 年 8 月 - 2023 年 3 月（持续性工作） 角色: 数据分析核心执行者
项目背景 医药行业政策多变，业务部门常有突发性、复杂的取数需求。标准报表开发排期长（通常需要 1-2 周），无法满足 T+0 敏捷决策需求。不同部门对 ” 销售额 ” 定义不一致（发货口径 vs 开票口径），导致数据口径冲突。
核心任务
- 将复杂非标取数需求的响应时间从 3-5 小时缩短至 1 小时内
- 建立可复用的参数化 SQL 脚本库，统一数据提取标准
关键行动
- 建立 ” 业务翻译 ” 机制: 充当业务与数据之间的桥梁，在提取数据前强制确认统计维度（含税/不含税、赠品逻辑），消除歧义
- SQL 脚本库建设: 沉淀包含 50+ 常用场景的 PL/SQL 脚本库（覆盖销售排行、库龄分析、高风险应收账款预警等）。通过参数化设计，实现 ” 输入变量，立等可取 ”
- 赋能风险控制: 编写 ” 负毛利销售拦截 ” 与 ” 异常库存变动 ” 监控脚本，每日自动巡检，帮助财务部门在月结前发现并纠正业务误操作
量化成果
- 累计响应 500+ 次复杂数据查询，平均交付时间从 3-5 小时缩短至 1 小时内（效率提升 70%）
- 成功规避多次因业务录入错误导致的潜在财务审计风险
项目 3: BPM 流程引擎维护与业务逻辑优化
时间: 2021 年 8 月 - 2023 年 3 月（持续性工作） 角色: 流程引擎技术实现主要负责人
项目背景 ERP 审批流程配置复杂，常出现 ” 审批人为空 ” 或 ” 逻辑死循环 ” 导致单据卡死。低风险业务审批链条过长（平均流转 5-7 天），业务响应慢。
核心任务
- 实现流程阻塞故障 30 分钟内修复
- 配合企业管理部优化审批逻辑，缩短平均流转时长
关键行动
- 根因诊断与可视化: 深入 BPM 引擎后台，分析 Token Flow（令牌流向），精准定位断链原因（人员离职、逻辑互斥等）
- 逻辑优化与技术落地: 将企业管理部设计的内控规则转化为技术配置。例如：针对低金额标准业务设置 ” 自动审批 “；针对特殊管制药品设置 ” 强制风控 ”
- 预防性维护: 建立 ” 流程变更模拟测试 ” 机制，杜绝直接在生产环境试错
量化成果
- 累计解决 80+ 起流程阻塞故障，恢复数百张业务单据的正常流转
- 常规办公类审批的平均流转时长从 5-7 天缩短至 4-5 天（提升约 20%）
项目 4: ITSM 知识库体系建设（个人创新项目，荣获集团嘉奖）
时间: 2021 年 3 月 - 2023 年 3 月（贯穿全阶段） 角色: 项目发起人与主导者
项目背景 运维团队高度依赖个人经验，相同问题（如打印机配置、客户端报错）反复出现，不同工程师处理方法不一，用户体验割裂。新员工入职缺乏系统性指引，完全上手需要 3-6 个月。
核心任务
- 建立结构化 ITSM 知识库，将个人能力转化为组织能力
- 实现 60% 的常见故障由 L1 客服依据知识库直接闭环，无需升级至 L2
- 将新员工独立上岗周期缩短 50%
关键行动
- 三层知识架构设计:
- L1（自助服务）: 面向最终用户，编写图文并茂的《常见问题 FAQ》，印制成二维码贴在办公区
- L2（一线运维）: 面向 L1 客服，整理 ” 故障现象 - 根因 - 标准处理步骤 ” 的 SOP 矩阵
- L3（专家经验）: 面向技术骨干，沉淀复杂故障（数据库死锁、流程断链）的深度复盘报告与 SQL 脚本库
- 工作流标准化: 确立 ” 接收→诊断→查库→处理→验证→归档 ” 的标准六步法。强制要求每次处理完非常规故障后必须更新知识库，实行 ” 知识库贡献度 ” 积分制
- SQL 脚本库产品化: 将个人编写的零散 SQL 脚本整理为 ” 参数化工具包 “，注明适用场景、输入参数与风险提示，让不懂代码的新同事也能安全进行数据核查
量化成果
- 知识库累计收录 200+ 个典型场景，覆盖 80% 的日常运维需求
- 常见故障平均处理时长（MTTR）从 1 小时缩短至 30 分钟，L1 客服自主解决率从 40% 提升至 60%
- 个人创新成果荣获集团创新嘉奖，成功带动团队从 ” 口口相传 ” 转型为 ” 文档驱动 ” 的专业化团队
职业转型思考：从应用运维到基础设施工程
转型动因 在 ERP 运维后期，我深刻感受到单纯的应用层维护是在 ” 治标不治本 “。集团发布流程不规范、环境配置漂移、缺乏统一的 CI/CD 标准，导致我们每天都在重复处理因部署错误引发的故障。我意识到，要彻底终结这种混乱，必须向下沉淀——去建设标准化的基础设施，去实施自动化运维，去构建平台工程。
转型价值 带着对 ERP 业务痛点的深刻理解，我主动申请内部转岗至基础设施团队，投身于虚拟化、容器化、自动化 (Ansible) 与可观测性 (Zabbix/ELK) 的建设中，致力于打造让应用运维不再 ” 救火 ” 的稳定底座。
技能矩阵
| 领域 | 核心技能栈 |
|---|---|
| 应用系统 | Oracle ERP (P2P/O2C 模块深度理解), BPM Workflow 引擎配置, WMS 逻辑理解 |
| 数据工程 | Oracle PL/SQL (存储过程/复杂查询), Excel (VBA/Pivot), FineReport (基础) |
| 方法论 | ITSM (事件/问题管理), SOP 标准化, 知识库管理 (KMS) |
| 业务领域 | 财务核算逻辑 (AP/AR/GL/月结), 供应链管理 (进销存逻辑), 医药 GSP 合规 |
核心竞争力
- 透视上层应用: 深入理解业务逻辑与数据流向，在做基础设施架构设计时，能更精准评估业务对 IO、并发和一致性的需求
- 数据驱动思维: 两年 SQL 数据分析经验，培养了 ” 用数据说话 ” 的习惯，在监控告警治理、容量规划中沿用这种分析方法
- 流程化基因: 从 BPM 流程治理中习得的标准化与内控思维，转化为推行自动化运维与零信任审计时的制度设计能力