編輯導讀：2B又稱B2B，也有寫成BTB，是企業對企業之間的營銷關係。2B企業發展至今，他們的發展狀況如何呢？上面兩章在宏觀架構和微觀架構上說明了如何構建起時間軸+空間軸的可被積累的框架，下面詳細論證在此架構下如何落到實地，並基於這樣的架構構建起百年2B。
再細化下4層模型在實際落地中對應各個角色的運作模式：
第一層是承載技術積累，也是最基礎的部分，這裡是由一行一行程式碼堆積起來的，或由一條一條與技術直接相關的配置資料堆積起來的；一些與控制元件相關的產品技術體系，由研發來主導建立，比如前面提到的搜尋幫助體系、訊息管理體系、多語言體系、模組化函式體系、標準化介面體系、許可權體系等等技術標準的構建+工具的構建+防呆模式的構建等都由研發的角色一行一行的程式碼構建出來，而這些將會考驗一個架構師的能力；
對2B架構師來說不但要考慮海量的資料問題，還要考慮海量功能的問題，如何能在同一套系統架構下搞定兩個海量，就看CTO、架構師們的功力了！
滴滴當年有個案例，當進行補貼大戰時，產品和伺服器架構都搞不定，於是騰訊率領2百人聽說2周就對滴滴從頭到腳翻新了一次，可見從功能應用層面2C是非常簡單的；而相對2B到現在為止為什麼SAP還不敢換他們上世紀80年代的技術平臺和架構？
那是因為沒有任何人敢用其他語言、或技術架構重構一次SAP的程式碼！這又是為什麼了？
做開發的人都知道，寫到系統裡的每一行程式碼都代表著一種業務場景的處理、邏輯判斷、業務控制等情況，你如果搬遷的時候沒有把這行程式碼理解透徹，那麼對應的業務場景就沒有搬遷過來，那麼就等於在搬遷過程中真實地產生了一個BUG或人為地產生了一個功能缺陷、缺失；不管是用其他的開發語言、還是相同的開發語言不同的架構重新開發一次，你也不能確保所有的程式碼是copy過去的，更何況是選擇不同的開發語言，那多年沉澱的2B的解決方案、場景基本上是毀於一旦；這其實既是SAP的優勢，也是SAP不可逾越的巨大劣勢！
也是現在被大家攻擊的痛點，可是為什麼還得使用他，還是因為他一直不換開發平臺，在上面積累沉澱了幾十年，積累下全球45萬家企業的解決方案並沉澱到IT產品裡；各個行業，各個體量的，都固化在他的系統裡或叫程式碼裡了，任何一名員工都是在給他添磚加瓦，員工的流失對這套產品體系沒有任何影響，每一位員工的智慧、聰明才智都固化成程式碼沉澱到SAP的產品裡，變成了看得見摸得著的“固定資產”！
做SAP的人都知道，在製造業對於一個具體的業務SAP一定有他的標準系統解決方案，如果你發現沒有，打算用開發的方式實現，大機率是你自己對SAP研究的還不夠透徹，這也是衡量資深顧問和普通顧問的區別，資深顧問會選擇用SAP已有的功能並說服客戶使用同時說明為什麼，而普通的顧問會選擇按照客戶的需求開發出客戶當時想要的功能，然後在未來的日子裡一直在新開發的功能上打補丁、修BUG；而資深的顧問用SAP標準功能，提出的解決方案，在未來的日子裡無論客戶如何變化，都被SAP囊括其中了，畢竟SAP在其他很多地方都碰到過，他們選擇了最好的幾種解決方案固化到產品裡；到最後你就有種孫悟空再厲害也沒跳出如來佛手掌心的感覺！他們能做到這些那也是被45萬家客戶虐得遍體鱗傷居然不死還能昇華重生之後才獲得的能力，否則他們肯定無法做到如此強悍的適應能力！
反過來想想，你在客戶那裡剛開發的功能，只是剛剛出生的新功能，而人家在45萬家客戶中受虐過，已經是身經百戰的老水手了，什麼樣的都見過了，所以才能囊括住接下來發生的種種情況，而你這新開發的功能才剛剛出生連一個客戶的洗禮都還沒走完，人家卻被45萬客戶洗禮過了。
我對比這個的目的是想告訴大家，定好2B最基礎的產品技術方向，並在最早期就搭架起可被沉澱的技術框架是多麼的重要，他將是2B產品賴以生存百年的基石，如果沒有這樣的技術框架，那麼對SAP來說也就是做了45萬個專案而已，而不是把45萬最終沉澱成“一”，唯一的“一套產品”他們能把海量最後化繁為簡最終被收攏為唯一的一個“一”的產品！這才是真NB的地方，當然他們也能從這一個“一”拆分出45萬！
下面我們來討論另一種基礎型別控制元件：技術的歸技術、業務的歸業務，即存在技術+業務的雙屬性的產品控制元件體系。
還是滴滴有一個很經典的案例，滴滴司機在滴滴平臺需要提現，於是出現了滴滴平臺真沒錢的情況，技術上就是賬戶的餘額小於本次提取的額度，於是滴滴就直接彈出了一個提示“滴滴餘額不足，無法提現！”在技術上，這個訊息沒有錯，他真實的反映了當前的實際展示的技術結果；但是實際卻是“我就提2千元啊！”就這麼一個提示在司機傳開了，反而引起了瘋狂的提現，都是這樣的提示，於是滴滴司機們就“爆炸”了！當然後面程維找馬化騰借到錢化解了這個危機！
於是後面他們在產品層面就做了一個改動，當出現沒錢的時候提示變成了“系統維護，請明天再提現！”這個案例告訴我們其實訊息提醒不是一個IT問題，是一個純粹的業務問題，特別是在2B領域往往一條訊息是指向一個明確的業務問題，而作為一個開發者是肯定不知道如何引導使用者的，所以也絕對不能用“技術語言”展現出來，因此技術只負責呈現該訊息最原始的技術結論，具體的展現和如何處理以及引導等與直接使用者接觸的是需要交給專業人士來做！
我們來看那一個案例：
技術展現：
這裡的訊息提醒是：2021年4月沒開賬！
點開訊息，針對這個訊息有一整套解決方案的指引：
當然這只是一個訊息，我們來看下他建立起來的這套產品體系：
F5這套訊息資料裡有幾百個這樣的訊息，剛爆出這個是第201的訊息：
針對這201的訊息具體的解決辦法是這樣的：
而這個F5-201的訊息，被這麼多地方引用到了：
這條訊息，在9個地方被引用到，而這9個地方可能是巢狀進某些程式小模組的，又將會有多少真正地方引用可想而知了；而在這麼多被引用到的地方，其被爆出的訊息提醒是一模一樣的，對使用者來說，不需要再去適用，只要一次就夠。
引用這條訊息的某個函式，被37個地方引用了：
這裡只是列舉了一條訊息，而像這樣的訊息在訊息產品體系中沉澱下來的有：英文的664，393條訊息，可見其多麼的龐大，當然這麼多資料也不是一朝一夕就做起來了，SAP也是積累了30多年才到這個量，但是最重要的卻是他構建起了這套可被積累沉澱的體系，剩下的就是在時間軸+空間軸上的積累；而這樣的積累也不需要多麼複雜的技術，需要的只是長年累月的堆積，而對於時間長河上的員工都是為這套體系貢獻儲備的一個個的“蟻工”，不管誰都一樣，這才是NB的架構、NB的產品！
因此在第一層需要架構師搭建起可被積累的技術體系，剩下的要麼就是普通的開發人員一行一行的豐富小模組程式碼或資料，要麼是產品經理、或專案經理、或交付顧問、或終端使用者一條一條的豐富這套體系下的技術級的配置資料，最終構築起在時間軸+空間軸不可逾越的2B產品。
總結來說最底層，也是第一層，現在可以劃分4大類：
功能無限強大的控制元件，這類只需要無限提升控制元件本身的強大功能，控制元件迭代後在全域性都能使用上新的功能，而無需逐個升級，如SAP的ALV控制元件。
積累技術類配置資料型，這類技術上相對不需要太強悍的功能，也許可以理解為技術很弱，其強悍的地方是基於這一框架體系下積累起來龐大的資料，如欄位集合。
程式碼模組化，這類最容易理解，相對來說也最多使用，畢竟程式碼塊可以省掉很多重複性的開發動作，如SAP的BAPI體系
技術的歸技術、業務的歸業務，這類首先擁有第二類的所有特性，但是具體在產生資料時絕大部分工作不由開發人員產生資料，而是由產品、顧問、使用者來產生，形成龐大的資料集，如訊息中心、多語言體系等。
第二層PAAS建模：這一層我們需要積累的是具體的業務解決方案模組，具有業務的抽象意義，不具有行業特性。這個維度將考驗產品經理的建模能力，他需要高度概括一種業務場景的公共屬性，或解決方案集合，並基於這些共性構建業務模型。
這一層以我目前的研究，並與實際相結合，目前共總結出兩種方法，一種是直接用程式碼建模，一種用圖形化程式設計建模，當然這裡的建模，都是在第一層體系架構基礎之上的。
對具體的業務抽象成模型、以及抽象出來後進行具體的IT建模，都是對產品經理巨大的考驗，我認為擁有這樣的能力，才是一個2B產品經理真正NB的能力，而不是具體的搞定某個功能（搞定某個功能叫專案經理或專案顧問）；2B產品需要的是構建該種業務場景解決方案的模型，當構建好這個模型後，基本上就做到了在這個小的業務場景，完整意義上的全部搞定，不管類似問題是否已經出現，全可以理解為搞定，因為已經從本質層面提出解決方案模型了。
比如就好像空氣動力學和飛機的關係，只要是飛機就必須遵循空氣動力學的理論模型，對於你來說就是找到了這個業務場景下的“空氣動力學”的模型！至於後面的各種型別飛機，那都是具體的一個一個實際的案例，當然這些實際的案例都無法與“空氣動力學”相比肩！
我這裡以採購訂單舉例，構建一個模型：
這是組成一張採購訂單的4大部分；功能操作部分、訂單頭、訂單行專案、以及訂單行明細，這是第一層大的模型。
我們先對訂單頭進行分析、建模：
我們會發現對於訂單來說，這裡有很多的屬性，每一種屬性也許代表對應某個行業、或某個企業、或某種業務場景的解決方案、或處理邏輯，因此我們需要構建出一個可被承載訂單頭資料的一個模型，這個訂單頭模型，擁有上面說的那些能力，我這裡大概分析了下：
這裡我們分出對應訂單頭，可能會附屬這些業務場景，但是具體在什麼行業、什麼規模、什麼區域、什麼採購業務等情況下，具有這當中的哪些業態，我們是無法確定的，因為在還沒碰到具體的某個行業、具體規模、具體區域、具體場景下，我們都是無法確定的。
如果實在無法理解，比如我們現在做了一個杯子，這個杯子會被用來裝酒、水、咖啡、甚至是湯，杯子裡裝的東西是裝了一小杯、半杯、還是一整杯等等這些事情，對於造杯子的人來說，是完全不可知的，具體這個杯子用來裝什麼？裝多少？都是由具體使用這個杯子的人來決定。如果裝什麼、裝多少都被定義好了，那麼這叫定製化，當然在我這裡他叫“窮舉法”！
當我們梳理出這些模型後，我們需要做到三個層面的建模：
1）定義好各個業務板塊必須的和公共的欄位
是指公共欄位或叫標準欄位，不能刪除，IT處理邏輯是鎖死的，比如訂單編號，必須有、而且是基於順序號自動產生等；至於具體有哪些被列入標準處理邏輯欄位具體業務模型，具體分析。
2）定義好各個模組必須的和公共的業務處理邏輯
定義好對於訂單頭公共的處理邏輯，不會隨著行業或業務形態的變遷會有所不同，比如單頭資料必須要進行儲存的動作，訂單必須要有審批的動作，修改必須要有記錄的動作，這些處理，不因為任何行業、企業的變化而有所不同，因此這些都叫公共處理邏輯。
3）定義模型可被自由新增的欄位
上面第一條定義好各個業務板塊公共欄位、標準欄位後，我們會發現在實際業務中會有各種各樣的特色欄位，比如服裝行業有“網格”，醫藥“含量”等等行業特色欄位。接著上面列舉大家能明白的案例，還是我們造的那個杯子，在一家咖啡店使用，裝咖啡時只能裝到350ML的位置，而杯子上卻沒有350ML的標識，那麼這時我們就在杯子上350ML這個位置畫上一條橫線標上350ML，以後每次都只裝到這個位置就不裝了；雖然這個杯子和其他的杯子是同一批出廠的杯子，但是他們卻已經不同了。
而畫出的這條橫線就叫在具體行業、具體企業、具體場景下的個性化解決方案，我們需要提供的就是他可以在這個杯子上畫這條橫線。那麼回到我們這裡在我們的這個模型裡，需要做到不但有標準欄位，還得有個性化欄位，至於在使用場景中具體可被定義多少個這樣的個性欄位，我們在模型裡不做限制。
其實在實際應用只增加欄位是不夠的，還得需要對這個欄位定義特殊的邏輯。就好比這個杯子為了達到必須是350毫升，我在350毫升這裡不是畫一圈的線，而是打一圈孔，只要超過350毫升，就會自動溢位，從而做到絕對的每一杯都是350毫升。
這個鑽孔的動作，在我們這個模型裡叫“增強”，我們可以對我們新增加的欄位自定義任何的業務處理邏輯，具體是什麼樣的邏輯，由實際業務來決定。這個時候不但標準欄位有業務處理，我們新增的欄位也有特定的處理邏輯，而這個新增的業務處理邏輯就叫行業解決方案、或叫個性化，但是他對我們整個訂單的構架模型卻沒有任何影響。
上面是對訂單頭進行建模的分析和處理過程，對應訂單行、和訂單明細的建模過程也是類似的分析處理方法；
訂單行部分：
訂單行明細部分：
訂單行和訂單明細，這裡就不做強分析論證，大家可以按照分析訂單頭的思維模型，進行建模；
有關資料部分我們已經完成了建模，現在需要的是對邏輯處理部分進行建模。對於採購訂單場景，處理上分成三大塊：
業務的上游轉換成採購訂單（單據流）
本身採購訂單業務的邏輯處理（資料流、邏輯流）
採購的下游流轉產生的業務單據（單據流）
業務上游和業務下游間的資料流、業務流的轉換，是2B業務很常見的處理方式。具體由哪些業務資料和流程實現他們的轉換這是不可控的，在各個企業、各種業務場景上的具體方案都存在或多或少的差異。因此對於產品建模的角度來說，是不能鎖死邏輯的，他們之間的轉換邏輯在產品維度是一種松耦合的組合狀態，只有確定具體企業、場景後才能鎖定具體的資料流、業務流解決方案；
所以在模型上我們需要可以靈活產生各種上、下游轉換的邏輯，和流程鏈路；資料轉換，其實有很多方式可以實現，當然我認為比較“屌”的方式是這樣的：
採用圖形化的方式，對各個欄位間的轉換採用拉線的方式進行匹配轉換，而且對每條線上的轉換若存在特殊的處理還能寫程式碼自定義轉化邏輯，當然實際是否能做到這麼“屌”我不能確定，但是採用稍微LOW一點的是一定可以的，包括每條轉換上都可以寫自定義邏輯。
其二構建業務處理邏輯，具體的處理邏輯按照我們對當前構建的業務模型，囊括下的業務大概有多少種公共處理邏輯，並封裝成一個一個的處理，具體如何處理這裡不做細節的分析，因每種業務模型抽象出來的處理邏輯各不相同，到本採購訂單而言大概如上圖列舉的6種處理，然後就是用程式碼一行一行地實現。
上面闡述了第一種基於程式碼模式的建模，下面概述基於PAAS思想的建模；
我這裡把計算機程式設計進行了4代的劃分：
第一代：面向機器（組合語言…）
第二代：面向過程（C語言…）
第三代：面向物件（JAVA…）
第四代：面向應用（圖形化程式語言）（低程式碼、無程式碼）
我這裡談的PaaS平臺建模，即基於第四代程式語言，第四代程式語言，將不再是程式設計師的專業，它將是普通大眾都擁有的技能，就好像20年前使用電腦是一個專業行為，但是現在使用電腦是一個大眾行為，而用第四代語言程式設計產生功能應用將是一個大眾行為。
我認為的大眾行為不是那種隨便在街上拉一個阿貓、阿狗就行的，還是需要有一定專業底蘊的。比如上面提到的企業語言，將是針對企業這個群體的特定的程式語言，只要是從事2B領域的不管是誰，都可以用企業語言進行程式設計，產生屬於自己的應用，只是他們產生的應用基本是侷限在自己所屬的業務細分板塊，比如干財務的，肯定無法產生一個好的生產管理板塊的應用；採用這裡程式語言產生應用的前提還是基於自己的專業基礎底蘊的。
這樣的功能應用產生平臺可以長得像這個樣子的：
在使用該模式進行業務建模時首先需要，當然還是第一層記錄的小模組足夠的多，就很容易構建起這樣一個應用，如下的流程是我認為企業語言的程式設計平臺的大概操作流程：
具體細到每個框往下細分都可以延伸很多內容，這裡不做過多的闡述，這塊目前我的經驗還不夠充足，我自己大概實現這個圖的50%~60%吧，但是具體到每個框我都找到具體的案例，或實現模型。現在需要把這些整合起來形成一套完整的企業語言開發工具，當然就這一句話，換成實際可操作、落地的東西我估計也要好幾年吧。
在第二層我們需要構建各種這樣的業務模型，當然在產品最初我們可以集中構建一批這樣的模型，然後在時間軸上隨著接觸到實際業務的增加、積累出更多的各種各樣的業務模型，覆蓋更多的解決方案，最終達到構建出2B這個領域的所有業務模型。我認為即使2B很繁多，但是在這個層級抽象出的業務模型，應該不超過1千個業務模型吧，至少我分析了SAP最經典的5大模組解決方案，按這樣的思維結構對幾大板塊抽象出來的業務模型不超過100個！
本文由 @汪仔5908 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議