筆者結合自己做B端產品以來踩過的坑，從勞動分工理論開始去思考B端產品的本質。

筆者結合自己做B端產品以來踩過的坑，從勞動分工理論開始去思考B端產品的本質。

入職以后負責設計的兩個系統都屬于公司內部業務支持性產品，即所謂的B端產品。

在做第一個系統由于經驗不足，犯了很多錯踩了很多坑，總結教訓后，在做第二個時便得心應手了很多。期間也對B端產品有了些零散的領悟，希望通過寫文章的方式將自己的思考提煉總結與大家分享。

文章內容可能更偏上層理論和思維方法，個人認為這比產品設計細節更為重要。正如吳軍在《數學之美》中提到的，有正確設計思想方法的技術未必成功，但沒有正確設計思想方法的技術一定失敗，無一例外。

什么是業務？

在工作中，我們常常道聽途說一些意義模糊的詞，我們只知道它大概的意思和用法，但如果真的要求解釋，就沒用起來那么簡單了——“業務”就是這樣的詞。我們常聽說，c端產品服務于用戶，b端產品服務于業務，在做b端產品設計之前也常常需要先進行業務分析,熟悉業務是做好b端產品的關鍵等等。

類似的詞還有“企業”，這個詞的經濟學定義直到1937年才被科斯解釋清楚。在建立一種理論時，首先應該考察其賴以成立的基礎，同樣如果我們甚至不能明確什么是業務，又怎么能在此基礎上進行分析？

究竟什么是業務？這要從勞動分工說起。

自亞當·斯密提出分工理論以來，勞動分工被視為高效組織的必要條件。亞當·斯密在《國富論》以扣針制造為例解釋到，由于分工能夠充分運用工人在勞動時所表現的熟練技巧和判斷力，因此能夠最大程度上提高勞動生產率。在此基礎上，以泰勒為代表的的科學管理學派開始將流程管理思想作為正式的管理理論進行研究，將基于經驗的隱性知識抽象為顯性知識用于劃分流程，同時代福特基于此創造了第一條流水線作業模式。

20世紀以來，隨著機械化大生產的發展和企業規模的擴大，組織內部均按照分工理論，將價值產生過程分解為簡單基本的動作和對應的科學明確的管理規程。有了分工之后，不同的人，不同的部門，不同的企業都有自己為達到某個特定目的而進行的工作（而職業和行業，就是指跨組織的人和企業的相似的工作內容）。

我們所說的業務，就是這些企業層面、部門層面和個人層面的特定工作任務的集合。同一層面上的各項業務或環環相扣，或相互輔助，最終將價值片段編織為價值鏈，完成由輸入到輸出的轉化，為顧客提供有價值的產品和服務。因此，勞動分工決定了各種各樣的業務目標和業務結構，“流程抽象”“區分層級”“組合結構”“特定目標”“價值增值”就是描述一個業務的關鍵要點。

在理解了什么是業務之后，我們在就能把握業務分析時的重點，事實上，整個業務分析的方法論就是建立在這樣的基礎之上，具體方式方法很多書都有介紹，就不在此詳述了。

B端產品在業務中扮演的角色

各項業務在進行過程中，會產生事物的流轉，包括信息流、物流、資金流等等，價值增值正是在這些流轉過程中產生。

在信息化產品出現之前，信息是如何在業務進行過程中流轉的呢？

勞動分工使組織達到某一目標需要經歷多個活動，各項活動間的關系包括中介和合作。中介程度高的流程包含較多輸入輸出的有序步驟，而合作程度高的流程意味著需要隨時交換信息。在這些流程中，大量的精力被耗費在了信息內容的同步工作以及解決同步工作的延誤與差錯之上，并沒有勞動力、知識的轉化帶來的直接的價值增值。

與此同時，分工理論將工作劃分為細小的單元并定義好各單元輸入輸出接口的做法，造成了信息在各個流程主體認知中的割裂，使每個流程主體僅對自己處理的部分的輸入和輸出負責，缺乏對于總體流程的認識，對業務的最終結果也缺乏責任感和工作積極性。

從解決傳統分工理論帶來的信息問題的角度出發，B端產品要幫助企業解決的首要問題，就是信息的記錄、傳遞和共享問題。包括CRM（客戶關系管理）系統、SCM（供應鏈管理）系統、ERP（企業資源計劃管理）系統等，其核心都是為了幫助某個業務單元解決以上的三種問題。

他們通過建立共享數據庫，使不同人員更新數據狀態都能同步合作者或是流程中的下一環節，消除了業務中的非增值環節，極大節省了達成同一項業務目標需要付出的成本。同時由于不設限的情況下，所有人都能查看業務流程中的所有信息，并將其用來輔助自身，做出真正產生價值增值的工作。

而至于B端產品的其他功能，與解決勞動分工帶來信息問題關系不大，并非系統的核心訴求。如自動化數據處理和計算，是通過利用計算機的計算能力，獲取局部的效率優勢，而包括數據分析、報表、監控在內的功能，都是B端產品在解決這些基本問題基礎之上，通過數據的積累而產生的附加價值。

B端產品設計

以上感悟對于具體的產品設計工作至少有以下幾點指導作用。

1. 重構業務流程

將已有業務流程簡單復制，是產品設計的誤區之一。企業的舊業務流程一般建立在過時的假設和規則下，新的規則需要與信息技術相適應，某一些不必要的任務和人員都可以進行清除、簡化和整合。

例如在信息化產品出現之前，由于管理層掌握了更多信息，決策只能由管理層作出，這種層層向上的決策體質嚴重業務的進度和對外界的響應速度，而在開放數據庫和建模工具的支持下，較低層的員工也能獲取充分的信息來做出決策，我們在設計核心業務流程時，就可以考慮清除或簡化這些不必要的流程。

2. 挖掘流程之外的隱性需求

我在兩次系統功能設計時都犯過一個錯誤，就是僅僅將眼光放在信息的記錄和傳遞之上，而忽略了B端產品另一個重要功能，即知識共享。這是對信息化產品的應用本質的理解不足導致的。

基于過去割裂式的工作經驗，業務方自己也無法認識到業務流程之外的信息需求，這需要產品經理在理解信息化產品的應用本質的基礎上，識別能夠使業務能夠更充分利用信息價值的產品功能，例如全局的基于對象（而非基于流程）的檢索功能、數據看板功能等。

3. 評估功能優先級

我們在確定功能的優先級時，有一些簡單粗暴的原則，例如：凡是手工可以處理的問題，都暫時不做系統支持。但如果按照這個原則，什么不是手工能夠操作的呢？

如上所訴，既作為信息化產品，要幫助組織解決的首要問題，就是完成某一業務目標過程中與信息流轉相關的問題，包括信息的記錄、傳遞和共享。而其他與之無關的功能都非系統建設的核心，除非老板強制要求，就可以往后放一放了。以此來評估功能優先級，有了理論的支持，就不怕懟不過誰了。

本文由 @ 文琪 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。