目錄
背景
行業概況
紡織是典型的長鏈條行業。一件衣服要經過紡紗、織布、染整、裁剪、縫製等多道工序，每道工序還可能在不同工廠完成。這幾年，行業裡有一個結構性矛盾：品牌客戶（如快時尚、運動品牌）需要小批次、多批次、快速翻單的柔性供應鏈，而很多紡織工廠仍然靠紙單、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 專案時的覆盤。公司名、客戶和經營資料不公開，方法論部分可複用。