編輯導讀：To B產品因為面向的客户是企業，其業務多且複雜，對產品的定製化需求較高。但是作為一個標準化的產品，定製化越多，整合融入的系統、功能越多、系統也越來繁雍笨重。那麼，如何在滿足用户定製化的需求下，避免產品變得笨重呢？本文作者對此給出了一些建議，與你分享。
ToB 的全稱是“To Business”，即面向企業。企業往往擁有比較複雜的業務，且個性化很強，通常需要他們自掏腰包來解決自己的困難。這就會要求所購買的產品必須能夠滿足自己的全部需求，產品價格要跟產品價值（滿足需求）相匹配。當 B 端客户需要你的某個功能時，你可以編各種各樣的理由來搪塞他或者説正在開發中，但不可以説你沒有，否則會給人一種很不專業的感覺（側面反映產品不成熟、積累案例少、不能快速響應信息化建設。所以對於大部分 ToB 產品，不存在直接拿 MVP 去賣的情況。因為客户需要你能給出對某一項業務完整的解決方案（思路），哪怕是低保真產品原型或 PPT ，都比一個沒做好的 MVP 更具説服力。
問題：定製化越多、功能越繁雍笨重
ToB的產品目前最流行的模式是高度靈活、自由可配置；公司設計研發出一套所謂能夠涵蓋行業80%標準化的系統流程，在用户購買之後採用根據客户不同需求做配置，滿足用户需求。這是一個理想狀態，現實中，每個企業、學校、機構的實際業務不同，使用者關心的業務和流程不盡相同，就出現很多的需求無法通過配置滿足的現實需求狀況。由此定製化開發的模式就被各廠商放到了桌面。
定製化開發過程中會有新的流程、功能被挖掘，這些確實能解決現實行業中的出現的一些個性化、特殊化的實際問題；但是如果不加辨別，認為只要能夠解決行業問題的方案就應該納入系統，進而考慮把每個客户需求進行整合，彌補現有系統的不足，設計研發出“大而全”的系統，對於想做平台或者壟斷行業利潤的廠商，具有巨大的誘惑力。
這樣一來，定製化越多，整合融入的系統、功能越多、系統也越來繁雍笨重；造成系統萬能，卻又沒有什麼賣點，對內公司人員怨聲載道，對外給人系統拼拼湊湊的印象，在市場沒有什麼競爭力，什麼都有，什麼都不強，又冗餘難用；儘管付出這麼大的代價，事實上這樣的系統依然無法覆蓋用户所有需求，因為你永遠不知道下一個客户需要什麼？
二、系統臃腫問題實質與避免建議系統臃腫問題實質：
- 多模塊多頁面信息存在大量重複（即有些字段信息沒必要每個地方都顯示，具體看需求）；
- 功能點堆砌，即可能存在需求但是沒有場景化。即有些功能點應該是連貫性和，應該是一步接一步的（如買火車票：提交完訂單後，下一步當然是付款， 你總不能讓這兩個功能分開放吧？）
- 存在部分“低需求功能點”，有些功能點現在基本沒怎麼用還留在系統中。
- 系統業務組織架構、功能權限、數據權限等模型不能支撐現在的業務發展（這是最蛋疼的，基本是最大系統的問題），導致每次增加新功能點時只能在邏輯上寫死，沒有任何邏輯和程序上的擴展性。
解決問題建議：
先梳理下現在的公司業務流程和組織架構（找公司各部門負責人多問問）；
根據上面四點對系統現在的業務流程、組織架構、功能模塊、功能點進行梳理，找出存在問題的地方，分別列出問題表單和問題點；
拿着問題表單和問題點去調研各個部門的負責人和使用者，看看反饋結果；並順便調研現在的業務需求和流程場景細節（多問問未來可能存在的業務需求-有助於考慮邏輯擴展性和全面性）；
然後根據調研考慮3套方案：
- 不動系統組織架構、功能權限、數據權限的基礎上，對各個功能模塊考慮解決方案（即如何解決系統現在存在的問題？），然後列出優缺點。
- 重做系統組織架構、功能權限、數據權限的基礎上，對各個功能模塊考慮解決方案（即如何解決系統現在存在的問題？），然後列出優缺點。（基本上動這個可以考慮重新設計了）
- 考慮重新設計的方案：從組織架構、功能權限、數據權限、業務流程、各個功能模塊等全方位考慮，以及特殊事件處理方案。（列出優缺點）
大體方案方向出來後找研發和項目評估下大概的難度和工期，不用估計太準，只要個大概就行。然後評估下現在的時間、資源等是否允許？ROI是否值得？
最後找各部門負責人+老闆+項目+研發開會説下事情（最後讓老闆老大們決定，你絕對不要做決定，你只給方案不做決定，讓他們選）
PS1：原則就是：看見表象（臃腫和邏輯混亂）—-去調研+梳理+分析出本質原因—-給出多個解決方案並評估優缺點—-讓大佬選擇方案。
PS2：要是你自己決定重新做，我敢保證你一定踩無數坑+背無數鍋，每天過得跟孫子似的；我們產品應該是功能要做好，鍋要少接。
本文由 @浩銘~~ 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議