編輯導讀：2B又稱B2B，也有寫成BTB，是企業(yè)對企業(yè)之間的營銷關系。2B企業(yè)發(fā)展至今，他們的發(fā)展狀況如何呢？上面兩章在宏觀架構和微觀架構上說明了如何構建起時間軸+空間軸的可被積累的框架，下面詳細論證在此架構下如何落到實地，并基于這樣的架構構建起百年2B。

我們再來剖析第三層

基于企業(yè)語言思維架構構建出具體的場景模型，那么現(xiàn)在就需要帶入具體業(yè)務場景：

我們還是以采購訂單場景為例，在第三層，更多的使用者是項目PM或者項目顧問，他們需要基于項目實際的需求，構建出具體的解決方案，例如上面列舉到的9種場景，都是實際業(yè)務會碰到的，而且他們之間的處理方式也確定不同；

構建處理方案時，我們總體分成四大部分：

基礎數(shù)據(jù)、操作部分：

這部分比較簡單，主要是對本方案的基本信息的記錄以及本方案的管理動作必須的行為，比如增刪改查等動作，這里不做過多的解釋。

關聯(lián)處理部分：

這部分比較關鍵，主要分成3種類型的關聯(lián)處理，這三種處理在配置上沒有先后順序之分。我們先來談審批流，在2B中大概率的場景只要是流程都涉及到審批，而相同單據(jù)在各種企業(yè)、或者是相同企業(yè)在不同體量時期、或者不同的管理風格領導下都會呈現(xiàn)不同的樣子，因此這里的審批流將是千變?nèi)f化的，不能固定死；于是最好的策略就是引入可配置化的審批流，而審批流和單據(jù)模型采用的是松耦合關系，只要把審批流賦予該場景或者解決方案，就能使用，而具體是什么樣的審批流，控制層級這些都不用該單據(jù)模型操心，都由具體的審批流配置工具搞定。

比如引入類似于這樣的流程設計工具，這也是一種分層的思想，專門的事交給專門的人去做，我們只管把他這一層產(chǎn)生的成果拿來使用即可。

其次是格式化數(shù)據(jù)呈現(xiàn)（打印的表單等），在企業(yè)中業(yè)務需要在現(xiàn)實中流轉(zhuǎn)，免不了需要打印，或者紙質(zhì)檔文件簽字、存檔的處理，而具體采用何種打印模板進行最終打印的輸出，也是會出現(xiàn)不同企業(yè)、不同流程下輸出的格式完全不一樣。這里我們同樣需要引入類似流程編輯工具的表單打印編輯工具，這樣的工具市面也是不少，我們需要的是通過這些工具，編輯好打印表單的格式，并給到該表單進行引用。

我們采用類似這樣的格式化報表打印工具編輯好打印模板，讓對應的業(yè)務解決方案進行引用。當然實際中，這樣的模板會構建很多很多，隨著時間的推移，將在系統(tǒng)里構建起這樣的打印模板庫，我想這也是一筆不小的解決方案資產(chǎn)積累。

最后一部分，就是對該方案的全局增強，在實際應用中，我們會發(fā)現(xiàn)，我們構建的模型是通用化模型，當應對一些特殊的需求時這種通用化模型是無法解決的，這時我們就需要引入特定解決方案的增強模式，在第二層專門列舉了一個杯子的案例，這里就不在重復；對應的增強相對構建的模型，將是行業(yè)、或者企業(yè)、或者方案的特色，或者叫定制化，這里我以SAP舉例。

這是SAP訂單場景中：ME23N T-CODE下包含的增強點的，我這里只列舉了SAP最傳統(tǒng)的增強技術手段，其實SAP還有很多其他增強的技術手段我這里不一一列舉，但是SAP的增強還是有一定的缺陷，只能在他預留有增強的地方做個性開發(fā)，如果沒有預留的地方我們是無法做的，當然他預留的已經(jīng)足夠多了。

我們點開一個看下：MM06E005：Customer fields in purchasing document

這個板塊的接口向下，我數(shù)了共有13個增強出口，其中10個是代碼層面的增強出口，3個是界面層面的增強出口。

這就是為什么SAP是一套標準品他卻可以適應全球42.5萬家企業(yè)的一大原因：他首先保住了標準品的足夠強大的基礎上，還能讓你在其強大的能力上玩出其他花樣；可以這樣理解，他是一個巨人，并且還給了我們一個梯子讓我們可以很輕松的站在他的肩上看得更遠。

1）深化、傳承、繁衍

當我們依據(jù)這套模型構建起幾百種解決方案后，我們?nèi)绾巫屵@樣的解決方案成為真正可被其他項目，以及之后新開的項目引用、參考，那么就需要當時產(chǎn)生這個方案的人，記錄下足夠多或者完善的信息，將會至關重要，深化、傳承部分，共分成2部分。

2）方案講解和再現(xiàn)

這部分主要基于三種手法，PPT文檔承載方案、Word文檔描述細節(jié)邏輯和操作手冊、視頻文件重現(xiàn)方案的各種細節(jié)，盡量做到全方位立體地呈現(xiàn)該方案第一手的感覺，而不是被人重復地以訛傳訛，需要真實地重現(xiàn)當時的情況。當我們采用這樣的辦法，記錄成百上千、甚至幾萬個方案時，某一個人或者幾個人是完全無法掌握這么龐大的解決方案的。

這樣積累下來的方案，才是有價值的、可被傳承的，就好像你給唐朝的人一臺電腦，對他們來說就是垃圾，不會使用也不能給他帶來價值，再好的東西對他都是無價值的東西，和垃圾沒有區(qū)別。為了讓當時產(chǎn)生方案的人，能把第一手最新鮮最原汁原味的解決方案沉淀下來以供后面的人參考引用，就得做好這些知識傳承資料；這樣的傳承、積累體系，才不會隨著時間流逝、員工的離開等等因素而消失，他將變成這一體系的養(yǎng)分、變成鑄就競爭高墻的一磚一瓦，變得牢不可破、不可撼動！

3）構建“方案”生命周期繁衍生態(tài)系統(tǒng)

在方案的生命周期中，被錄入到這套體系的那一刻開始，代表這一方案的生命周期的開始，當然我們需要構建的這一體系，肯定是不希望她開始的一天也就是她結束的一天，我們希望這個方案在往后的歲月里不斷地迭代、成長、追求這個方案在該細分領域成長為最完善的解決方案；

基于這樣的思維理念我們就需要給予這個方案在生命周期中擁有可供迭代升級的環(huán)境或場景，于是我們?yōu)槊恳粋€方案開辟了獨屬于自己方案的討論主題板塊。當使用該方案時有任何問題、疑問，或者使用過程中有更新的想法時，都可以在這里討論，大家在基于實際的情況、基于碰到的實際項目，進行方案迭代，或者干脆基于本方案衍生出其他全新的方案！

同時我們也構建起一套基于該方案的支持、服務體系，如果有即將要使用該方案的人了解PPT、Word、視頻資料后，還可以去論壇看看，已經(jīng)使用該方案的人對該方案的評價、或者建議、或者踏過的坑、以及該方案歷程、也許最終發(fā)現(xiàn)基于該方案的衍生方案才是最適合自己項目本次需求的；重點是我們需要構建一套讓方案基于實際的被引用和項目構建起一套自我循環(huán)迭代的機制，讓每個人、每個項目都成為方案的養(yǎng)分，最終隨著在時間軸上的持續(xù)積累，空間軸上的持續(xù)復制、擴張構建起不可撼動的方案倉庫，而該方案庫隨著時間+空間的發(fā)展，已經(jīng)存下了全球所有的解決方案，這樣的一套體系，還有誰能撼動！

4）明細解決方案構建

方案明細板塊，對解決方案進行最細微顆粒度的定義：

方案明細部門分成三板塊：

1）數(shù)據(jù)字段板塊

數(shù)據(jù)板塊大致分為三部分，單頭、單身、附加數(shù)據(jù)，單頭總體定義該種數(shù)據(jù)綜合屬性、或者公共屬性項，如單據(jù)編碼、日期、創(chuàng)建者等字段；單身主要定義業(yè)務具體明細數(shù)據(jù)，比如物料號、金額、數(shù)量等；單頭，或者單頭的附帶屬性數(shù)據(jù)；當然每種數(shù)據(jù)都有屬于單據(jù)本身系統(tǒng)默認字段，是不允許定義，是標準字段；這些標準字段在建模的時候都已經(jīng)定義好，并且也已經(jīng)固定邏輯，直接可以使用

數(shù)據(jù)板塊總體分成三大部分：

基本信息定義：

基本信息定義主要字段名稱、多語言、排序等，重點是添加的字段必須經(jīng)過管控，不能隨意添加，集中從字段庫中添加，如果字段庫沒有，需要在第一層添加字段，然后再進行引用。

操作類似屬性定義：

字段定義出來后在操作部分，將定義出具體操作屬性，比如操作習慣下拉框、篩選框等，業(yè)務界面的呈現(xiàn)，比如該模型中，有新增、刪除、修改三個業(yè)務場景，那么該字段需要在哪些業(yè)務場景出現(xiàn)，如只在新增界面出現(xiàn)，其他界面都是不出現(xiàn)；顯示、必輸校驗、輸入校驗、防呆校驗等，以及權限校驗的定義，具體涉及的對該字段的操作的都在這里定義。

增強類定義：

上面的定義，都是基于該模型自帶的邏輯進行定義，因此從大方向來說不存在企業(yè)級別的個性化，也許存在行業(yè)級別的個性化（行業(yè)級個性化可以開一個全新的模型）；當然定義完這些后，還是存在字段級企業(yè)級的個性化時，我們就需要進行增強開發(fā)了，總體自定義開發(fā)分成4種類型：

1. 界面增強：這類增強需要在標準模型的界面基礎上新增界面，或者在標準模型基礎上對標準模型界面進行修改、調(diào)整等。
2. 進入增強：在打開該界面時需要處理的邏輯，在標準模型的邏輯上增減一部分的邏輯處理。
3. 檢查增強：在標準模型校驗基礎上，對依然不足以滿足需求還需要進行檢驗，在這里進行增強。
4. 保存增強：當觸發(fā)保存類按鈕時，不但執(zhí)行標準模型的處理邏輯，還需要處理增強類的邏輯。

在第一大類板塊需要配置出來的將是類似的板塊。

2）數(shù)據(jù)邏輯處理板塊

我們在第一部分講解了字段，在實際操作業(yè)務時，單據(jù)的產(chǎn)生基本都由上游數(shù)據(jù)轉(zhuǎn)換過來的，然后再附加上其他維度數(shù)據(jù)，當然也有全新產(chǎn)生一張單據(jù)數(shù)據(jù)的，最終經(jīng)過各種數(shù)據(jù)組合成一張新的業(yè)務單據(jù)：

如采購訂單模型中，產(chǎn)生采購訂單，可以有8種模業(yè)務單據(jù)源。

如果我們以采購申請為例，那么產(chǎn)生采購訂單需要組合多少數(shù)據(jù)？在采購申請基礎上+價格數(shù)據(jù)+供應商數(shù)據(jù)最基本的三種數(shù)據(jù)最終才能成為采購訂單；而在實際業(yè)務中我們是不可能每個字段都手工輸入的，我們更多需要的是輸入某個主要字段系統(tǒng)將自動帶入相應的數(shù)據(jù)。如本場景中，確定了采購申請?zhí)柡螅渌麛?shù)據(jù)自動帶入，確定價格單號后，其他數(shù)據(jù)自動帶入，輸入供應商號后其他數(shù)據(jù)自動帶入；那么是如何做到自動帶入的了？這里我們就需通過配置匹配相應的字段了。

當然這也得轉(zhuǎn)換配置，最屌的配置模式，我覺得是這樣的：

這種配置有多屌我這里不詳細論述，前面的章節(jié)有講到。

本單據(jù)中的數(shù)字字段，除模型本身擁有的處理邏輯外，跟隨業(yè)務附加的計算邏輯：

在實際業(yè)務中，字段間存在各種邏輯處理，比如一個總金額字段，在行項目上，有數(shù)量、單價，那么總金額就能自動計算出來，但是在設計是無法知道是否一定需要總金額字段，那么類似這樣基于現(xiàn)有字段，進行數(shù)學公式級別的計算需要進行配置，當然如果計算很復雜，也可以直接采用寫增強算法的形式，得到結果。

3）單據(jù)流轉(zhuǎn)轉(zhuǎn)換板塊

單據(jù)依據(jù)操作，改變自己的狀態(tài)，而且各種狀態(tài)間相互形成處理閉環(huán)，在構建模型時無法預知在各種場景下，狀態(tài)的多少，以及狀態(tài)間的流轉(zhuǎn)的邏輯處理，當然模型本身可以默認一個狀態(tài)流轉(zhuǎn)，當需要優(yōu)化或者修改時，可以將該模型進行修改、替換。

實際業(yè)務中狀態(tài)流是很復雜的，類似于審批流一樣的機制，狀態(tài)流描述單據(jù)在業(yè)務流程中的位置、狀態(tài)、以及接下來需要處理的動作。

在時間軸+空間軸構筑產(chǎn)品的細節(jié)，這里我就寫到這里，當然還有很多細節(jié)，有興趣在繼續(xù)探討；產(chǎn)品這個維度我做一個簡單的總結：

在這套架構下，采用什么樣的開發(fā)語言、以及對應語言的開發(fā)框架，都是無所謂的最重要的是選擇了最基礎的開發(fā)底層后，就不能換，否則又是從0開始，其實我們構筑的是一個飛輪效應的產(chǎn)品架構。

我們會發(fā)現(xiàn)，如果從下往上看，往上的每一層都是數(shù)據(jù)，只要數(shù)據(jù)積累得越多就越是強悍，比如對開發(fā)平臺來說，第一層是無數(shù)的程序模塊、無數(shù)的字段集合、無數(shù)的消息、無數(shù)控件等；第二層是無數(shù)的業(yè)務模型建模；第三層是無數(shù)業(yè)務解決方案；第四層是無數(shù)的業(yè)務交易數(shù)據(jù)；

如果是從上往下看，發(fā)現(xiàn)往下的每一層，都是配置的模塊，都是基礎的構成部件；第四層為什么能產(chǎn)生那么多有業(yè)務含義的數(shù)據(jù)，因為有第三層對應的方案配置；為什么會有第三層的方案，那是因為有第二層的模型構建；而為什么有第二層的業(yè)務模型，那是有第一層各種技術組件、技術數(shù)據(jù)，堆砌起來的業(yè)務模型。

在《規(guī)模》書中有一段說城市基礎設施加油站、煤氣管道等這些基礎設施當增長到一定程度后，不再隨著城市的變大、人口的增多變成線下增長；反而是越大的城市，這些設施反而平均擁有成本越低。因此我們會發(fā)現(xiàn)當一個對象是組成一個龐大系統(tǒng)的最小顆粒度元素時，當該最小顆粒度元素在該系統(tǒng)中增長到一定數(shù)量后，將不再隨著該系統(tǒng)的增長而增長，相對來說既是規(guī)模越大，重復利用這種最小顆粒度元素的頻次越高，即對于這個系統(tǒng)來說成本也就越低；回到我們本章節(jié)的產(chǎn)品，當我們產(chǎn)品積累得足夠多的代碼塊、業(yè)務模型、解決方案后，后面交付的項目花費的時間、交付的成本反而是降低的，就像現(xiàn)在的SAP一樣，交付再多的新項目，對產(chǎn)品本身的改動卻很小，那是因為對于SAP產(chǎn)品來說就是一座城市，組成這座城市最小顆粒度元素類似加油站的基礎設施已經(jīng)構建得足夠的豐富了，增加再多項目都不會對產(chǎn)品有什么改動；

《規(guī)?！愤@本書還闡述了另一個概念“升維”，表現(xiàn)形式是，當這種最小顆粒度足夠多時，他們?nèi)繀R集在一起將涌現(xiàn)出區(qū)別于原來性質(zhì)的新的屬性，比如一滴水，和無窮多的水這是完全兩個不同的事物；

我們不能用認知一滴水的方法，去認知無窮多的水，當他們完全變化了，就上圖那可是載重12萬噸的鐵疙瘩啊，但是縮小后還是一滴水！

所以這套架構其實就是在各層里通過時間軸+空間軸，通過人+項目來積累各層的數(shù)據(jù)，當積累下這些數(shù)據(jù)后，無論是人員的流動、還是時間的流逝，產(chǎn)品本身都沒有影響，這些在時間軸+空間軸積累下來的數(shù)據(jù)，最終都成為這條萬里長城的一磚一瓦，最終在產(chǎn)品這個維度隨著時間軸+空間軸的延續(xù)，成長成一款無可撼動的強大產(chǎn)品！當然積累起這么多龐大、各層級的數(shù)據(jù)，最終升維后會涌現(xiàn)出什么樣的新特性，其實我也不知道，就好像古人在看到一滴水的時候，肯定無法想象到這滴水可以承載起12萬噸的鐵疙瘩，我只希望盡快看到這天的到來！

本文由 @汪仔5908 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議