国货新锐品牌 80 SKU PLM 6 周上线

6 周 里我们做了这些

背景

客户是 D2C 美妆品牌，主打抖音 / 小红书渠道，年销 8000 万。2024 年底立 2025 年 1.5 亿目标后，老板做了内部诊断：发现研发是瓶颈。80 SKU 共用 1 个 Excel 主文件 + 1 个研发微信群，每周冲突 2-3 次（A 改完保存覆盖 B 的版本）。新品研发周期平均 5 个月，竞品同款 3 个月就上市。 这其实是化妆品中小品牌的普遍困境——行业调研显示，依赖 Excel 管配方导致 **>40% 重复实验**、检测数据人工录入误差 **>8%**、新员工经验断代后上手周期 **6+ 个月**。客户 CEO 看完调研后说"我们正中靶心"。 客户找到 CosDev 时已经看过 3 家方案：① Coptis 报价 €15 万 + 周期 6 个月，太贵太慢；② 某国产 PLM 6 万一年，但功能偏向化工不懂化妆品；③ 自己招 1 个研发负责人主导自建，周期 4 个月起。客户 CEO 直接说"6 周做出能用版本，预算 38 万"，CosDev 接单。

我们做了什么

总工期 6 周（计划 6 周，实际 6 周达成）。 第 1 周｜需求访谈 + 数据建模。访谈 4 位研发员（每人 1.5 小时）+ 1 位老板。意外发现 4 个研发员对"配方版本"定义都不一样：A 认为版本号代表 "公开发售配方迭代"，B 认为 "送检配方版本"，C 认为 "实验室小样调整版本"。统一术语开了 5 个会议，最后定 3 级版本树（实验版 v0.x / 内测版 v1.x / 正式版 v2.x）。 第 2 周｜INCILABSV2 内核裁剪 + 单租户部署。客户只有自己用，不需要多租户，去掉租户路由 + 去掉海外 PIF 模块，保留配方库 / 物料 / 项目流程 / 合规校验。容器化部署到客户阿里云。 第 3 周｜配方库 + 物料管理上线。配方版本锁（防多人同时改一份）+ 物料主数据导入 380 个原料 + 各种关系（替代 / 升级 / 弃用）。 第 4 周｜R&D 项目阶段化看板。我们参考了客户已有的研发工作流，做了 6 阶段看板（立项 / 配方实验 / 小试样 / 中试样 / 送检 / 量产）。每阶段有自己的"必填字段 + 必上传文件"规则，未达标不能进下一阶段。这是这个项目最受研发员欢迎的功能。 第 5 周｜合规校验接入 + 培训。FORMULAW 标准品 NMPA 引擎接入，每个配方提交时自动跑校验。培训分 3 场（4 个研发员 + 1 个 QA + 老板），每场 1 小时。 第 6 周｜灰度上线 + bug 修复 + 数据迁移（80 SKU 从 Excel 全部迁入）。

数据结果

上线 4 个月： · 新品研发周期从 5 个月 → 2.9 个月（-42%） · 配方版本冲突 0（之前每周 2-3 次） · 研发员每周节省 8 小时"找上下文"时间 · 80 SKU 全部数字化，含历史送检报告 / 实验记录 / 物料替代追溯 · 老板每周看一次 dashboard 即可了解所有研发项目状态（之前要召集 4 人开会） · 客户预订年度运维（¥6 万/年）+ 第二期（彩妆品类二开 + 法规扩展到 EU）

复盘 · 哪里做得不够

前 2 周的需求访谈花了比预期多一倍时间，因为统一术语本身就是一个深度活儿。我们后来在所有"中小品牌 PLM"项目都把第 1 周写成"术语对齐周"，明确告诉客户这一周要花在统一概念上，不是浪费。 做了才知道 80% 是把 4 个研发员的工作流统一掉，剩下 20% 才是给配方建表。后续再做品牌 PLM 都是这个原则——别上来就建表，先看人怎么协作。