中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

我們?cè)賮砥饰龅谌龑?/p>

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

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

構(gòu)建處理方案時(shí)，我們總體分成四大部分：

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

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

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

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

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

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

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

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

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

我們點(diǎn)開一個(gè)看下：MM06E005：Customer fields in purchasing document

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

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

1）深化、傳承、繁衍

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

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

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

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

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

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

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

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

4）明細(xì)解決方案構(gòu)建

方案明細(xì)板塊，對(duì)解決方案進(jìn)行最細(xì)微顆粒度的定義：

方案明細(xì)部門分成三板塊：

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

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

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

基本信息定義：

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

操作類似屬性定義：

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

增強(qiáng)類定義：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果是從上往下看，發(fā)現(xiàn)往下的每一層，都是配置的模塊，都是基礎(chǔ)的構(gòu)成部件；第四層為什么能產(chǎn)生那么多有業(yè)務(wù)含義的數(shù)據(jù)，因?yàn)橛械谌龑訉?duì)應(yīng)的方案配置；為什么會(huì)有第三層的方案，那是因?yàn)橛械诙拥哪Ｐ蜆?gòu)建；而為什么有第二層的業(yè)務(wù)模型，那是有第一層各種技術(shù)組件、技術(shù)數(shù)據(jù)，堆砌起來的業(yè)務(wù)模型。

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

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

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

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

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

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