目录
背景
行业概况
纺织是典型的长链条行业。一件衣服要经过纺纱、织布、染整、裁剪、缝制等多道工序，每道工序还可能在不同工厂完成。这几年，行业里有一个结构性矛盾：品牌客户（如快时尚、运动品牌）需要小批量、多批次、快速翻单的柔性供应链，而很多纺织工厂仍然靠纸单、Excel 和口头传达管理生产。
我加入的公司定位是纺织产业互联网平台：一端连着大量纺织工厂，另一端连着品牌客户，通过平台分配订单、管控质量、追踪进度，让品牌在手机上就能看到工厂的生产进度。
产品定位
公司已经拿到早期融资，跑通了几个标杆客户，但支撑业务的系统几乎没有。工厂端靠微信群接单、纸质工单流转（工单就是一张生产任务单）；客户端靠销售手工整理 Excel 周报汇报进度。我在这时加入，担任产品负责人，从零搭建整个产品体系。
产品分为两大块：
- 工厂端 ERP：ERP 即企业资源计划系统，是管采购、库存、生产、销售的一整套软件。工厂端版本覆盖接单、生产排期、工单管理、工艺路线（一件货要经过哪些工序、按什么顺序）、进度报工（工人汇报做了多少活）、质检、发货全流程。
- 客户端门户：给品牌客户看的订单追踪系统，可以查看订单进度、质检报告和发货数据。
团队是一支规模不大的产研团队（产品、后端、前端、测试都有），需要在 12 个月内交付一套能用的系统。
挑战
挑战一：工厂之间差异很大
接入平台的工厂，既有规范化的大厂，也有小型家庭作坊。大厂有基本的 ERP 使用经验，小厂连电脑都不太会用。同一款订单在不同工厂要经过不同工序，不同工厂对"工序""工单""批次"的叫法也完全不同。产品既需要一套统一的标准词表，又要兼容各工厂的实际操作习惯。
挑战二：一线操作员的电脑能力很弱
工厂一线操作员以 40 到 50 岁为主，智能手机勉强会用，电脑操作很吃力。少数工厂甚至没有电脑，只能用手机操作。输入习惯、界面理解、流程遵循，都和互联网产品的标准用户相差很远。系统只要稍微复杂一点，一线工人就会放弃，回到纸质单据。
挑战三：需求变化快，交付压力大
平台处在快速扩张期，几乎每个月都有新品类上线、新工厂接入、新客户入驻。每个新品类可能带来完全不同的工艺路线，每个新工厂可能要求定制字段或流程，每个新客户可能提出独特的报表需求。产品团队每周收到大量需求，排优先级的压力很大。客户和工厂也都在催进度，听得最多的一句话是："下周能不能上线？"
挑战四：从零开始，没有历史数据
没有任何历史数据可以参考。排期算法、产能预估、交期预测都要从空白起步。最开始，连"工厂真实产能是多少""某类订单平均生产周期多长"这样的基础数据都没有。没有数据支撑就去做决策功能，等于空中楼阁。
我的解法
阶段一：MVP，先跑通核心闭环（前 4 个月）
MVP 即最小可用版本。
策略：砍掉一切非核心功能，只解决"订单如何在工厂里流转"这一个问题。
具体动作：
定义最小闭环：我画了一张"订单生命周期图"：客户下单 → 平台分配 → 工厂接单 → 生产 → 质检 → 发货。MVP 只覆盖其中三个节点：工厂接单、生产报工、发货。质检和客户端门户放到第二阶段。
极简的界面：针对操作员电脑能力弱的问题，我主导了"三个大按钮"的设计。工厂端首页只放"待处理工单""今日报工""发货管理"三个入口。每个操作不超过三步，超过三步就拆开。表单默认填好 70% 的字段，操作员只需确认或修改少量信息。
先做手机端，暂不做电脑端：调研后发现，大部分工厂没有专用电脑，但都有手机。第一阶段只做手机网页（H5，即在手机浏览器里直接打开的网页，不用安装 App），确保普通智能手机上能顺畅操作。为照顾低端手机和弱网络，页面体积控制在 200KB 以内，关键操作支持离线提交：先存在手机里，联网后自动上传。
统一基础数据字典：开发前花了两周，和一位从行业招聘来的资深纺织业务骨干一起，梳理了统一的"工序字典""物料类型字典""质量缺陷分类"。字典就是系统里的标准词表。它是整个系统的地基，耗时，但避免了后面各工厂各说各话、数据混乱。
结果：4 个月后，系统在几家试点工厂上线，跑通了"派单 → 报工 → 发货"的完整链路。试点期间，每天的订单处理量从零开始逐步上升。功能很简陋，但证明了这件事是能做成的。
阶段二：功能完善，补齐产品矩阵（第 5–10 个月）
策略：MVP 验证了核心闭环后，按模块逐步补齐，同时建设客户端门户。
具体动作：
工艺路线管理：不同品类的生产工序差异很大。我设计了"工艺模板"机制：平台业务团队预先配好各品类的标准工艺路线，工厂接单后只需微调，不用从头建。工艺路线以"节点加流转条件"的形式表达，不要求每个节点都必须经过，而是根据订单类型动态匹配。
质检模块：质检是纺织行业的核心环节，瑕疵率直接影响成本。我设计了分级质检：首检（面料入场时检查）、中检（生产过程中抽检）、尾检（成品检验）。每个环节支持拍照留档、标记缺陷、打分。质检数据自动进入订单档案，客户端可以看到每批货的质检报告。
进度追踪与预警：我设计了"订单热力图"，以天为单位，用颜色标注每张订单的进度：绿色正常，黄色预警，红色延迟。某道工序的报工时间超过标准工时一定比例时，系统自动通知工厂管理员和平台运营。这个功能技术上不复杂，但大大减少了"订单卡住了，没人知道"的情况。
客户端门户：品牌客户不需要登录工厂端，他们要的是一块"总览看板"。门户的核心理念是"只展示客户关心的信息"：订单进度、质检摘要、发货追踪、结算数据。工厂端的复杂操作一律不对客户开放。门户支持多级权限：品牌总账号可以查看所有订单，门店账号只能看自己的订单。
报表体系：团队人手有限，第一阶段只做三个维度的报表。订单维度：按时交付率、延期原因分布。质量维度：瑕疵率趋势、高频瑕疵类型。产能维度：工厂产能利用率、各工序耗时分布。每个报表配一张简单的趋势图，不追求 BI（商业智能，即数据分析报表）级别的美观。
结果：到第 10 个月，系统在一批工厂和几家品牌客户那里上线，接入的工厂和客户明显增多，订单量也明显增长。客户端门户成了品牌客户每天早上的第一件事："打开看看我的货到哪了。"
阶段三：数据驱动，反哺决策（第 11 个月以后）
策略：有了数据基础，开始用数据反过来指导业务决策。
具体动作：
产能画像：基于历史数据，为每家工厂建立"产能画像"：擅长什么品类、平均交期多少天、质量合格率多高。平台分配订单时，系统会自动推荐最合适的工厂。
交期预测：初期做不到 AI 级别的预测，但可以统计历史数据里"某品类在某工厂的正常停留时间，加上当前排队的订单量"，给出一个较为可靠的预计交期。上线后客户满意度明显提升。客户最在意的不是"能不能更快"，而是"能不能给一个准信"。
质量看板：把质检数据可视化，帮助运营发现哪些工厂、哪些工序频繁出问题，有针对性地做培训和改善。
通用方法提炼
方法一：B 端 ERP 从 0 到 1 的"三圈收敛"框架
B 端指卖给企业的产品，区别于卖给个人的 C 端。
我在这个项目里总结了一套"三圈收敛"的方法，适用于资源有限的 B 端 SaaS（按订阅付费、在线使用的软件）从 0 到 1 阶段：
- 第一圈（MVP）：只做一个核心流程的闭环，砍掉所有非核心功能。判断标准是：没有这个功能，业务能不能跑起来？能，就不做。
- 第二圈（完善）：围绕核心流程补齐周边模块，按模块批量开发、分批上线，每两个月发一个大版本。
- 第三圈（深化）：基于积累的数据做智能化和决策支持。
每一圈都有明确的时间边界：MVP 圈要在 4 个月内上线，完善圈最多 6 个月，第三圈才是差异化的开始。
方法二："低门槛优先"的 B 端设计原则
纺织行业的经验让我认识到一个普遍原则：B 端系统的天花板不是功能多强，而是用户愿不愿意用。
- 默认值策略：表单 70% 的字段预填默认值，用户只需改例外情况。
- 三步限制：任何操作路径不超过三步。
- 手机优先：即使有电脑版，也要保证手机端能完成全部核心操作。
- 离线友好：网络不稳定时，关键操作（如报工）可以先存在本地，联网后自动提交。
这个原则后来我在其他 B 端项目里反复使用，效果稳定。
方法三：先建行业基础字典
很多 B 端产品团队容易犯一个错误：上来就做功能，忽视数据标准。纺织行业的经验告诉我，如果不先统一"工序""物料""缺陷类型"这些基础字典，后面每个功能都会遇到数据混乱。
基础字典建设的要点：
- 由行业专家（而不是产品经理）主导内容。
- 产品经理负责结构设计：分类方式、编码规则、关联关系。
- 预留扩展空间：客户自定义字段、工厂自定义分类。
- 建立变更流程：谁能新增、谁能修改、修改要谁审核。
反思
如果再让我做一次，哪里会不同
1. 应该更早引入用户培训体系
第一阶段我们把精力都放在开发上，以为"系统做好，用户自然会用"。结果试点工厂上线时，操作员根本不愿意用。不是系统不好用，而是他们不习惯"按流程操作"。后来我们被迫在每个试点工厂派驻一名"推广专员"，手把手教操作员，这个角色起到了关键作用。
如果重来，我会在上线前两周就开始准备培训材料，把操作手册做成视频加图解，并安排专人陪跑首批用户。
2. 功能优先级判断需要更坚定
项目中期，面对大量定制需求，我们做了一些不够坚定的判断，为某个大客户的特殊流程做了深度定制。结果这个功能只有一家工厂在用，维护成本却一直占用团队精力。如果一个需求不能抽象成通用功能、服务至少三个客户，就应该果断拒绝。B 端 SaaS 最怕的不是丢客户，而是被客户的需求牵着走，失去产品的通用性。
3. 应该给数据质量留出明确工期
工厂操作员填报数据时常出错：报工时间填错、数量输错、工序跳着填。这些脏数据在后期的报表和分析中造成了很多麻烦。如果重来，我会在系统里加入更多校验，比如报工数量不能超过订单数量、工序时间必须按顺序填写，并在项目计划里留出数据清洗的时间。
4. 不要一开始就追求完美
这个项目最大的教训是：追求完美，是 B 端从 0 到 1 的敌人。第一版质检功能非常简陋，只能在手机上填几个字段、拍一张照片，但它已经解决了"客户能不能看到质检结果"这个核心问题。第二版再慢慢优化。如果一开始就想把质检做到完美再上线，可能现在还在开发中。
适合谁读
- B 端 SaaS 产品经理：特别是正在做或准备做 ERP、供应链、生产制造类产品的人。本文的"三圈收敛"框架和优先级判断思路可以直接复用。
- 创业团队（做 toB 方向）：资源有限的早期团队，如何做产品取舍和节奏把控。
- 产业互联网从业者：纺织、服装等传统行业的数字化实践者，可以看到一个真实案例里踩过的坑和验证过的方法。
- 对 B 端产品感兴趣的设计师和开发者：理解 B 端产品的设计逻辑和产品经理的决策过程。
本文是作者在一家纺织产业互联网公司主导 ERP 项目时的复盘。公司名、客户和经营数据不公开，方法论部分可复用。