來，給你聊下後臺
網際網路產品領域，可以籠統地分為前臺產品和後臺產品。
前臺產品即是C端的產品，後臺產品可以籠統地概括為各種管理系統；BAT等大公司還會把後臺產品細分為兩個部分：
- 純後端部分，指的是業務流程、邏輯規則、資料結構部分，不涉及到介面；
- 中臺部分，即提供內容展示、功能操作的視覺化系統介面。
我們一般所說的後臺產品，根據面向使用者群體的不同還可以分為兩類：
一類是針對大企業內部，作為內部各個業務線的支援系統。常見的比如電商行業的商品管理系統、訂單系統、供應鏈系統等，我把它概括為後端支援系統。
通常以交易或者實體業務為核心的網際網路公司，比如電商、O2O、金融等方向，都會自己開發完整的後臺系統用於支援業務。
還有一類就是我們常說的To B 的saas系統。面向各行業的企業使用者，通過某種商務合作，提供B端或者小B端產品給他們使用。
比如現在各種行業中給線下機構、門店提供的管理系統，為大企業內部提供的ERP、OA系統，以及專門為特定企業定製化開發的系統，均屬於此類。
本文以企業內部的後端支援系統為主。
我們常說的使用者端產品價值在於滿足使用者需求、提升使用者體驗，後端產品完全不同。
第一要義是對業務的支援和提升——通過業務操作和資料的線上化，來標準化業務管理流程、提升業務運轉效率，以及發掘資料的價值，進而在各環節影響到公司的成本和收入。
這對於主營業務為電商、O2O等任何形式交易的公司來說尤為重要。
四五年前，當網際網路還處於線上產品為主的階段，業內會說有很多公司不注重後臺。
但現在網際網路各行業各類線下服務早已層出不窮——都9102年了，如果還有認為後臺產品的價值小於前端產品的公司，可以倒閉了。
我本人在小公司做了一段時間的公司內部支援系統，總結出了一部分關於後臺產品的個人經驗。
本文並沒有什麼深度，適合小公司的產品經理或者沒接觸過後臺的產品經理看看，也歡迎大公司的產品經理來批評指正。
一、後臺產品的作用
1. 使用者需求的悖論
從我做產品開始一直到現在，我都能在各個不同地方聽到這句話：產品經理的核心價值在於滿足使用者需求。
我們接手一款產品後，首先發現目標使用者，然後通過種種手段挖掘使用者的需求，通過功能介面等方式實現，滿足使用者需求。
剛做後臺產品的時候，我也照著這句話，把我從後臺產品的“使用者”處收集到的需求一一實現。
一段時間後，我產生了疑問：
後臺產品和使用者端一樣也有目標使用者，而且使用者是固定的；對於企業內部的後臺系統來說，使用者就是公司內部某個部門的人；他們的需求比廣義上使用者的需求明確的多，通常他們的需求就是公司實際業務上的事情。
但這意味著：他們說什麼，我們做什麼嗎？
如果是這樣，那產品經理在挖掘需求這方面的價值，不就很少了嗎？
這裡就遇到使用者需求的悖論了： 後臺產品的目標到底是不是滿足使用者需求？
經過一段時間的產品經歷下來，對這個問題，我自己做出了兩點解釋：
首先，所謂的“使用者”不同。
使用者端產品是服務於C端個人使用者的，滿足使用者需求是永恆的真理；而後臺產品通常是面向B端，服務於公司的，因此後臺產品第一要滿足的是“公司”這個使用者的需求，也就是業務需求，而不是狹義上使用產品的那些人的需求。
換句話說：公司層面的需求大於使用者自身的需求。
其中，面向B端企業的產品，服務物件是所處行業中的各個客戶，企業內部的後臺產品，服務物件就是自己公司。
舉個最簡單的例子：
釘釘的“釘”功能，站在使用者立場上被頻繁騷擾很不爽，但站在企業客戶的角度看，“釘”這個功能能提升企業員工間溝通的效率，有助於公司的管理，所以它解決了公司的需求，很多公司會為這個功能買單。
我做供應鏈系統的時候，經常遇到這樣的問題，有些功能對公司的管理有作用，但對使用人來說，反而會加重他們的使用成本，讓他們很不爽。但顯然這樣的功能不得不做，因為這些功能會為公司帶來更大的價值。
比如我們要做的一物一碼溯源體系，站在公司的角度能規範化管理和資料追蹤，站在直接使用者的角度，大大加大了他們的人力和工作量，但結論是這肯定得做。
這就是我針對使用者需求悖論的第二點解釋：後臺產品的價值和使用者端產品不完全相同，“滿足使用者需求”只是其中一個目標，後臺產品還有更大的作用。
2. 後臺產品的三大價值體現
我做後臺產品的時候，一開始我只是接收一些具體要做的事情，比如我們要補全某某業務流程，比如要上線某某模組，然後開始做，中途不斷和業務方撕逼後，做出來上線。
後來我想，做這些功能流程的目的是什麼，尤其是有些東西業務方並不喜歡，我們為什麼還要這麼做。之後在產品過程中加了一個步驟，做每個需求之前，都必須和大家明確，這個事情的目標和價值在哪裡。
一段時間後我發現：這麼些需求的目標和價值，基本可以歸納為以下3個大方向：
1. 提升業務運轉的效率，進而節省時間和成本
一般說起來做一個後臺產品，就是將一項發生線上下的業務，搬到線上完成的這麼一個事情。
對比線下手工導資料、微信釘釘私下溝通的麻煩，一項業務通過系統，在各個角色之間快速流轉，通過各環節的進度和資料的實時同步，提升溝通和操作的效率，同時通過生成、匯出各類表單、統計表等功能，減少業務方手工的工作量，進而對整個業務本身的效率提升。
這一點是作為中颱部分的核心價值，以效率為導向，在滿足“使用者需求”這個方向上的作用。
2. 通過標準流程，實現公司管理方式的標準化，並保證業務資料的準確性
將一項業務從線下搬到線上的基礎是流程本身的標準化
將標準化的業務流程和規則在線上實現後，能讓所有人都按照這一套統一的規則去做業務，實現平臺化管理，避免各種“人治”的人工管理。
在此過程中，保證流程涵蓋所有的業務，能支援意外情況的處理，並且做到流程中所有的業務資料準確，包括財務資料、訂單資料、庫存資料等。
這一點以平臺化管理為導向，體現在後端流程方面。一般規模較大的網際網路公司都會實現平臺化管理，後臺系統的流程會作為管理的基礎。
但要做到涵蓋所有業務、業務資料百分百準確，並不是一項簡單的事情——只要業務流程沒有完全閉環，留下了人工操作的入口，就可能造成資料的不準確。
發掘資料的價值，反過來對做到業務的驅動和提升
在做到基礎流程的支援和效率的提升之後，後臺產品真正能為業務帶來實質性提升的地方，在於資料的挖掘和分析。
這裡的資料分析不是簡單的資料統計展示，而是在決策環節，結合各項業務資料進行智慧計算、自動化調配，提升業務決策的準確度並加快時效，最終對業務本身帶來提升。
在決策性的環節，演算法的準確度一定是比人腦要高的。
這一點是以資料為導向，需要各環節的業務資料作為基礎。資料演算法有一定高度後就屬於策略領域，會有專門的產品經理做策略演算法。
不過普通的後臺產品，在很多環節中同樣少不了資料的挖掘和分析，而且這一點的價值能夠直接通過業務的發展資料來體現。
以我接觸過的電商供應鏈系統的採購模組為例，看下這三大價值具體體現在哪些地方：
我剛接手採購模組的時候，我們的系統只有一個採購入庫單的頁面和入庫操作，只能實現人工把庫存資料入準確這一個事情。
開始做這塊之後，我根據以上思路開始思考上線系統後對業務有哪些實質上的提升。
首先， 通過將整個採購流程在線上實現，可以節省採購人員、倉管、供應商、質檢等多個角色之間的進度同步和效率提升。
比如說供應商發貨後倉庫能及時收到發貨資訊的同步，再比如採購能在倉庫清點完貨後第一時間看到收貨的情況，然後找供應商要剩餘未發的貨等等。
——這樣比之前只能通過線下溝通到最後才錄一個入庫單要效率高得多。
然後， 在實現了採購主流程、採購價格管理規則、質檢流程後，可以保證每個貨品的採購成本資料和庫存資料準確。
不再像之前一樣只靠人工輸入數字，一旦輸錯了會直接影響到計算訂單成本的財務資料，和一系列出入庫的庫存資料。
當系統運轉起來，到第二個階段，我們可以通過積累的各項過程資料對供應商進行評估。
比如在制定採購計劃的操作中，根據採購資料計算出供應商良品率、供應商發貨滿足率，根據訂單資料計算庫存預計消耗量，智慧計算出推薦的採購數量和供應商的選擇方案，最終提升採購的滿足率和時效性。
每個不同領域的後臺產品的核心和方向都不一樣，但總體而言，除了我們常說的使用者需求，後臺產品的價值都可以從這三個方向引申出去。
二、不同公司會有哪些後臺產品
對於電商、O2O等交易型的網際網路公司來說，後臺系統是支撐業務運營的核心產品。
以我所在的一家自營模式的O2O公司為例：
我們的業務模式，是使用者下單後，系統指派給上門服務人員，相應的人員領取倉庫的商品，上門到使用者家裡完成服務，在各個城市有門店作為上門服務人員的排程中心和庫存的中轉站。
我們的產品後臺體系，需要提供整個訂單流轉的流程支援、庫存進銷存業務、人員的指派排程上門、以及線上線下運營推廣規則的支援。
後臺產品架構大致如下：
1. 訂單系統
彙總各種型別、來自不同平臺的使用者訂單，處理訂單從下單到完結正向流程，以及售後退款的逆向流程。
訂單系統是整個對使用者服務體系最基本的支援.
訂單系統屬於後端的業務邏輯，作為中颱、客服工單、上門服務人員的終端等其他產品做訂單各類操作的底層支援。
比如我所在公司，一個訂單的基本流程為：
使用者下單
▼
系統指派
▼
客服聯絡使用者
▼
上門人員接單並上門服務
▼
使用者付款完結訂單
在這個流程中，多個角色在各個環節中的各項基本操作和延伸服務，都需要通過訂單的邏輯進行。
2. 供應鏈系統
所有商品進銷存的業務，處理一個庫存從採購入庫、倉庫間調撥、物流配送，直到使用者手上的整個生命週期，以及倉庫的週轉、盤點、售後等各項庫存管理服務；供應鏈系統以庫存和資金的流轉為中心，是公司成本管控的核心。
我在現在的公司做過供應鏈系統，供應鏈直接涉及到公司的重資產，因此庫存和財務資料的準確性通常會作為系統的第一目標，而非使用者需求。
而且供應鏈涉及到採購、倉管、質檢、物流等多個環節，業務流程比較複雜，梳理清楚並不容易。
3. 商品系統
作為平臺商品結構的體系，使用者下單時選類目、選SKU、選規格尺寸，就是來自於商品系統的支援。商品系統本身的東西不多，不過也是底層邏輯的一部分。
4. 運營系統
用於平臺日常線上的運營，包含折扣、促銷、線上活動、拼團、分銷等各類優惠的支援，和針對C端使用者的會員管理體系。
每個網際網路公司都有產品運營，運營承擔著網際網路公司直接獲取使用者和訂單的作用，是直接背KPI的，所以運營系統的好壞直接影響平臺使用者量、訂單量和交易額。
5. 線下網點的中臺系統
很多O2O/新零售領域或者自建物流的電商公司，都會線上下設定幾個網點，作為作為一片區域內人員和物流排程中心。
——這個概念不一定看得懂，如果我說門店就比較好理解了。
我所在的公司有自己的上門服務團隊，由每個線下網點獨立管理自己區域內的訂單、上門服務人員和庫存；因此我們做了一箇中臺系統，用於上門人員的指派排程和工作統計，訂單的各類操作、使用者到店訂單、售後等業務的處理，庫存配送的中樞。
這個系統屬於操作層面的，核心在於兩點，提高訂單的完成效率和服務質量，以及實現對人員和業務的標準化管理機制。
6. 客服工單系統
作為客服處理客戶諮詢、投訴、售後、回訪等業務的系統支援。
客服工單和中臺都是屬於系統的操作層面，以訂單系統為基礎，針對客服的各項日常業務，通過工單流轉規則提升客服的工作效率，繼而提升面向使用者服務的效率。
7. 統計系統
提供所有業務資料的統一計算口徑和出口，包括訂單資料、庫存資料、成本收入資料、頁面轉化資料等。
——具體每個系統的業務流程和功能模組就不在這裡贅述了。
可以看到，以上後臺產品對公司業務的作用，不僅作為基本的資料業務支援，還對實際的業務效率有著不少的提升。
當然，以上的這些只是電商或者O2O行業中比較常見的後臺產品，還有些其他常見的後臺產品。
比如面向B端客戶服務的CRM系統，面向財務人員的財務系統，供應鏈的一部分、電商行業配送方向的物流系統等。
具體的後臺產品定位和架構，在不同行業、不同公司也會不一樣。
原創： 潘帕斯雄鷹