產品經理B端產品的形態(tài)：ERP、CRM、后臺、中臺、及C端業(yè)務產品APP、小程序

1、在 B 端產品中，我們會經常聽到很多個專業(yè)詞匯，如：ERP、 CRM 、后臺、中臺，及C端業(yè)務產品APP、小程序。不同的行業(yè)有不同的產品形式，也有面向用戶的不同的產品形態(tài)。那么， B 端產品應該如何去明確自己的產品形態(tài)？，我具體針對現在 B 端產品及產業(yè)層次的產品設計整理了幾個問題：并針對第一個問題做了深入的探入分析（詳細請看：）今天開始第二篇，也是第二個問題。在 B 端產品中，我們會經常聽到很多個專業(yè)詞匯，什么 SAAS 呀， PAAS呀，IAAS呀，ERP呀，CRM呀，或是什么后臺，中臺之類的。這些詞中，相信很多人名詞是可以在網上查清楚，但對這些東西怎么使用？在哪階段使用的定義還并不清楚。

2、簡單的說，什么是行業(yè)的產品形式，什么是面向用戶的產品形態(tài)，可能都還是停留在概念比較模糊的狀態(tài)，還不能自如的去運用，這才是根本問題。所以，我們今天就以一切的起點來開始這個問題， B 端產品應該如何去明確自己的產品形態(tài)。讓大伙更加清晰明了這些東西如何在你手中合適的去使用，讓大伙心中有譜！首先，我們先看一個圖，這個圖基本上描述了 B 端的產品與用戶間的關系結構。大量的 B 端用戶與產品的關系是三角形的，付費的人不是使用的人。而 B 端與目前大家認識的 C 端有什么區(qū)別呢？其實，在我看來，如果明確了業(yè)務關系的話是沒區(qū)別的。反正都是為了商業(yè)，建設一個場，然后為了賺錢，有啥區(qū)別？區(qū)別只有簡單的產品與用戶利

3、益關系：那接下來，從這個三角關系（先立個標：為以后同學回顧埋個尸，一但明確了業(yè)務關系，其實后邊發(fā)展與C 端其實也沒區(qū)別）再發(fā)展，就是要不斷證明你的產品體系是有效的，對業(yè)務的推動是有效的。同時，還能更好的節(jié)省或創(chuàng)造價值，讓B 的決策者更愿意繼續(xù)與你的產品合作下去。所以，在發(fā)展上，就會形成以下的結構：簡單說明一下，就是將使用者在使用的過程中產生的相關業(yè)務推進的階段結果成績數據化。然后整理出報表，給上層看。當然，上層本身也是用戶之一，所以，他用這個東西有沒有提高各種方面的效率，本身也是數據采集的一環(huán)?？吹竭@里，相信聰明的人就會產生一個關鍵的問題。怎么知道用了產品之后會比原來好？B端的BOSS關心的效

4、率質量如何體現？（如果你腦子里真的蹦出這樣的問題，那說明你是一個很有潛質的產品經理哦）這時，我們就要先回歸業(yè)務，我先畫個圖：任何一個業(yè)務，其實都可以看成是一段一段的。有業(yè)務開始，有業(yè)務結束。如果是一個大業(yè)務呢？則可能是很多個人完成一個業(yè)務中的不同環(huán)節(jié)。復雜的業(yè)務可能是這樣的： （了解甘特圖的應該秒懂）當然還有更復雜的。但是，我們可以從中看到規(guī)律，就是業(yè)務在執(zhí)行過程中，不同大小的業(yè)務都可以切不同環(huán)節(jié)。每個環(huán)節(jié)都是一段，有開始有結束。有的環(huán)節(jié)間可能很完美的可以銜接，有的可能需要些滯空期，有些可能會在某個時間多道推進。所以，我們可以從業(yè)務的過程中提取以下幾個關鍵點：起點，結束點（包括小段的起點，小段

5、的結束點），中間的過程，及過程中執(zhí)行的情況，時間，效率。而每個項目其實都有計劃時間，預估的或是經驗的。及實際數據跟蹤后，實際提取的。那自然，將這兩者一對比。就能取得當前業(yè)務設計與推進中的情況。超出預計了，則可以幫助找到為什么為超出計劃，是哪個環(huán)節(jié)用時或是用料用成本過多？哪些環(huán)節(jié)是不是可以改進？還是實際上已經沒有改進空間？這些問題自然就能很清晰的呈現出來，并指引下一步的計劃如何安排。而達成了計劃呢？同樣可以看到，哪個環(huán)節(jié)是在實際的節(jié)省，哪些環(huán)節(jié)可控性強，可以標準化，是不是預估的可以更加明確實際的情況？是否可以對下一次預估指出更明確的指引？同時，是不是可以讓整體一個更大的項目或業(yè)務的整體時間縮??？

6、成本降低？或是其它什么地方改進能節(jié)省出更多資源？這些問題自然而然的也能明確起來。而這，就是在 B 端產品中其中一個比較有價值的體現產品價值的地方：讓管理者更清楚的看清楚實際的情況；讓其心里越來越有譜。說到這，有了明確的價值，那要回歸本身問題。如何確定 B 端會采用什么樣的產品形態(tài)才是最合適的呢？這也得在你理解了上邊價值體現的基礎上，才能到這一步的。什么樣的方式，更能帖近或帖著使用者，將這些環(huán)節(jié)的真實情況的數據，采出來。這時，我們就要開始進入下一步的分析：通過上圖，我們可以整理出以下兩步：第一步：使用者分析通過管理人員（也是一類使用人員）的實際工作中的推動情況及付費方的實際要求，采用什么樣的產品

7、形態(tài)，方便他進行管理，同時，他本身是不是業(yè)務環(huán)節(jié)中的一段？是不是也要參與環(huán)節(jié)的執(zhí)行？那他的工作場景是一個端還是幾個端？合適幾類或是幾種等級權限的管理者？C 端產品只是少幾個角色？但性質及環(huán)節(jié)一個都不會少， B 端產品與 C 端產品只要明確了業(yè)務，除了業(yè)務的嚴謹性的標準要求，其實沒有什么本質區(qū)別。當然現在越來越多 C 端的產品標準，要求也在向 B 端靠齊。第二步：以上的數據采集，保真性，現階段什么樣的技術最合適？那自然而然的就可以明確，應該做成APP?還是小程序？或是一個網站？或是一個本地執(zhí)行程序？還是一個什么？這個軟件要求跨平臺么？還是需要兼容跨平臺？是本地布私有環(huán)境還是可以有遠程外網環(huán)境等，

8、自然可以通過這個推導得出。如果付錢的BOSS直接要求了，就不需要思考了么？同樣，還是要負責任的思考一下，如果意見不合理的，可以給出相應的更合適的建議。比方：現在很多已經不做APP 了， APP 還有發(fā)行等很多不完全可控問題。小程序是否可以替代？總之，在不影響B(tài) 端業(yè)務的情況下，選擇你可以搞定并可以有效推進下去的產品形態(tài)方案是你的必須要深入體會的一個環(huán)節(jié)，這樣做產品才能更全面，才能為你下一步的具體設計給出一定的規(guī)則邊界。所以，面向使用的用戶，我們會定義出：而使用者不同的工作性質，或是用戶有必要形成有價值的用戶體系或，則會產生相應的 CRM ，用于用戶業(yè)務數據積累，同時本身 CRM 也可以成為用戶

9、推進業(yè)務的工具之一。（以上兩者是不是有很多的共同點？如果你注意到這點，很好，請記住，之后用得著）而對于管理者，自己企業(yè)或各種業(yè)務中資源的監(jiān)督與管理，調配，自然就形成了所畏的ERP。綜合以上產品的類型形態(tài)及終端的形式，這即是SAAS 的意義，軟件即服務。軟件就是為了服務而產生的。設計好了，針對使用場景及情況布署好就用吧。（就這么簡單粗暴?。┻壿嬌险f， SAAS、 PAAS、 IAAS ，以前我就有過解釋，網上也有一大堆的名詞說明，所以這里就不再浪費時間。但運用這些東西還是需要個直白的理念，心里要有點基礎的認知。而一線業(yè)績的產生的數據，首先先是要有個地方存，是機器吧，你還得時刻監(jiān)督管理這些機器，那

10、這個自然是IAAS 的事。而如果這個業(yè)務可以更好的擴展給更多的 B 端商家使用。那自然會產生相應的 PAAS 層，產生相應的技術接口或是合作開發(fā)的開放功能。也就是說，你可以開放這個體系給更多用戶用啦或是合作用戶用啦。而對于 B 端的管理者或公司，他們要有自己的后臺。同樣，做為服務的提供者，產品開發(fā)方，可能方便業(yè)務的推進，一樣也會有自己的后臺。后臺就是一般前端用戶不需要看見的業(yè)務功能部分。時刻控制著前端業(yè)務的推進，或是給相關的人權限或是開放什么功能這樣子。有時后端也可以是一個ERP或是就是一個ERP,因為人力及權限及功能其實本身就是資源計劃的一部分當一個后臺，對接前端的用戶多了，為了節(jié)省一些反復

11、或重復的前后端高占資源的一些信息交流情況，這時就會產生一個中間部分的概念，他可以直接處理一部分的后臺業(yè)務，也可以很好的支撐前端的業(yè)務。同時能為后臺減少相應巨大的負擔。所以，中臺這東西，并不是什么特別神的東西，特別是那個馬云搞亂市場的 “中臺 “言論，真是把一個本來就有的東西搞得市場鬼哭神驚。當一個業(yè)務對接非常多的客戶端時，不同的錯時交互中為了達成更的資源信息交換，本身就會需要一個中間部分集中的處理協(xié)調好各種部分的對接，這本身就是自然而然的事。搞得這么大驚小怪。所以，以我對多家公司及很大行業(yè)內人員的了解看來。包括所謂大廠阿里系出來的，其實都對這個問題沒有充分的想過，思考過，更多的只是因為自己是大廠的，好像見到的就是唯一的。所以，感覺好像是拿著所謂標準答案就不再去思考這個問題了。同樣TX 系的也有差不多同樣的情況，那些招 B 端產品或是招總監(jiān)的，也是如此的無知者占多數。說到這里，你是否具體的知道 SAAS ， PAAS， IAAS ，與ERP， CRM ，后臺，中臺，小程序，APP,網頁工具如何在產品人手里自由的運用了呢？不過