編輯導讀: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 協議

相關文章