嘉氏堂化妆品 OEM 全流程系统 · 13 类工单 + 1000 存储过程

24 个月首版 + 8 年迭代 里我们做了这些

背景

嘉氏堂是化妆品代工集团，22 个外资品牌客户（含 4 个欧美品牌 + 8 个日韩品牌 + 10 个国内品牌）。代工业务比单品牌研发复杂得多——客户提需求 → 工厂 13 个流程节点 → 跨研发 / QC / 采购 / 包装 / 制作 5 个部门 → 最终交付。每单都要走完。 2017 年立项时客户用的是手工纸单 + Excel + 微信群混合协作。22 个品牌客户的代工要求差异极大（欧美客户要求 EU CPSR 报告 / 日韩客户要求 PMDA 申报 / 国内客户要求 NMPA 备案），员工经常因为流程分支太多记错。2017 年发生过一起重大事故：一个出口欧盟的订单因为没及时做 CPSR 报告，整批货到欧盟海关被扣，赔了客户 ¥18 万。这件事推动客户全面数字化。

我们做了什么

总工期 24 个月首版（2017-2019），后续 8 年持续迭代。 2017 H2｜架构设计 + BSE 基础数据。基于 Vue 3 + Ant Design + Oracle 19c 架构。后端逻辑用 Oracle 存储过程承载（最终累计 1,000+ 个），原因是客户 IT 团队熟悉 Oracle 不熟悉 Java/Python，存储过程方案让客户能自己维护。建立基础数据模块（数据字典 / 模块级权限 / 多租户 / 用户组织架构），同期上 Oracle Forms 兼容前端（兼容老用户使用习惯）。 2018 H1｜BD 代工业务模块（核心）。这是项目最复杂的部分。13 类工单：① 研发打样单；② 签样单；③ 送检单；④ 报价单；⑤ 包装设计单；⑥ 测试单；⑦ 备案单（NMPA / EU / PMDA 三套子流程）；⑧ 设计制作单；⑨ 条码申请单；⑩ UDI 单；⑪ 量产订单；⑫ 出货单；⑬ 退货单。每类工单含完整的状态机（平均 8-12 个状态节点）+ 跨部门审批流 + 自动派单逻辑。前端做卡片式业务全景仪表板，按状态 / 进度 / 客户 / 紧急度集中展示，下游流程自动触发（配方确认 → 签样 → 送检 → 包装 → 测试 → 备案 → 量产）。 2018 H2｜FML 配方与 BOM 模块。配方版本管理（每个配方支持多版本）+ 物料编号体系 + 品类管理 + 生产商资质管理。和 BD 模块联动——客户提需求时可以从配方库选已有配方做迭代，而不是每次从零开始。 2019｜质检 + 生产 + 报表 + 上线。 2020-2025 持续迭代｜跟随客户业务发展加了：① 多工厂支持（2021 年）；② 跨境申报模块（2022 年）；③ AI 配方推荐模块（2024 年）；④ 移动端审批（2025 年）。

数据结果

截至 2026 Q1（运行 8 年）： · 22 个品牌客户的代工订单全部数字化 · 研发员从 Excel + 微信变成一个仪表板看 13 类工单状态 · 新品交接（研发 → 生产）从 5 天压到 1 天 · 类似 2017 年的"漏报事故"再无发生（系统强制流程闭环） · 客户成长为华南区前 10 大化妆品 OEM 集团 · 累计 8 年技术支持合同金额 ¥620 万

复盘 · 哪里做得不够

1000+ 存储过程在 2018 年是合理选择——客户 IT 团队熟 Oracle，自己能维护。但 8 年后维护开始吃力：① Oracle 19c license 每年 ¥40 万，成本占比上升；② 存储过程的版本管理弱，多人协作冲突频繁；③ 新员工不懂 Oracle 上手成本高；④ 性能瓶颈在并发场景下越来越明显。 2025 年开始 INCILABSV2 项目就是这个系统的 PG + FastAPI 重构版本，预计 2027 年完成迁移。教训是技术栈选择要看 5-10 年长期，不能只看当下团队能力——客户当时没意识到 Oracle 在 SaaS 时代的成本曲线，CosDev 也没强势建议换栈。下次类似项目我们会先和客户讨论"5 年后这个栈还合适吗"。 OEM 代工业务的复杂度远超品牌方研发——13 类工单跨 5 部门 + 22 个客户的差异化要求，每一类都是一个独立子系统。这是这个项目最大的认知收获，后来用在所有 OEM 客户咨询里。