深度|從一個故事說起,談?wù)勂髽I(yè)應(yīng)用架構(gòu)的演變史

41 評論 73754 瀏覽 617 收藏 47 分鐘

本文來自一位九年產(chǎn)品老司機的投稿。作者從一個故事說起,將企業(yè)應(yīng)用架構(gòu)的演變史娓娓道來,全文1.1萬字,小編看完只有一個大寫的“服”,強烈安利各位涉及相關(guān)產(chǎn)品的童鞋收藏,不時拜讀。

企業(yè)應(yīng)用架構(gòu)是指一整套軟件系統(tǒng)的構(gòu)建,通過合理的劃分和設(shè)計組合在一起,支持企業(yè)方方面面的經(jīng)營運作。不論是傳統(tǒng)企業(yè),還是互聯(lián)網(wǎng)公司,發(fā)展到一定階段,都需要一整套體系化的應(yīng)用架構(gòu)來支撐其運轉(zhuǎn)。良好的、合理的應(yīng)用架構(gòu)可以支持企業(yè)高效開展業(yè)務(wù),控制經(jīng)營風險,而混亂的、不合理的應(yīng)用架構(gòu)則會限制企業(yè)的快速發(fā)展,成為企業(yè)增長與變革的瓶頸。

企業(yè)信息化建設(shè)已經(jīng)發(fā)展了幾十年,傳統(tǒng)企業(yè)和成熟互聯(lián)網(wǎng)企業(yè)的應(yīng)用架構(gòu)并沒有本質(zhì)的區(qū)別。本文將通過一個線下小型門店成長為多元化集團的發(fā)展歷程,逐步向讀者展示企業(yè)應(yīng)用架構(gòu)的演變和設(shè)計的理念。

完整的企業(yè)架構(gòu)(EA,Enterprise Architecture)分析構(gòu)建,包括業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、技術(shù)架構(gòu)、數(shù)據(jù)架構(gòu),本文聚焦應(yīng)用架構(gòu),更加關(guān)注軟件系統(tǒng)設(shè)計與公司經(jīng)營管理的關(guān)系。不論是C端產(chǎn)品經(jīng)理或者B端產(chǎn)品經(jīng)理,理解應(yīng)用架構(gòu)的建設(shè)思路,能夠幫助你更輕松的理解公司的業(yè)務(wù)運轉(zhuǎn),以及各個系統(tǒng)存在的目的與你所負責工作在整體團隊中的定位和價值。

一、傳統(tǒng)企業(yè)的應(yīng)用架構(gòu)演變

1、小門店的Excel管理之路

我們將從一個最簡單的案例入手,來展開故事。

假設(shè)你是一名個體經(jīng)營者,在小區(qū)中開了一家小門店,售賣居民常用的生活用品。門店不大,只有十幾平米,平常由你一個人負責經(jīng)營管理,包括采購、擺貨、銷售。為了更準確、科學的打理你的生意,你設(shè)計了一個Excel文件來管理你的商品與銷售數(shù)據(jù)。實際上你只需要做三張表格,第一張表格存儲了你的貨品信息,第二張表格存儲了你的采購記錄,第三張表格存儲了你的銷售記錄,這三張標的結(jié)構(gòu)和關(guān)系如下圖所示。

上圖采用了ER模型來描述三張表的邏輯結(jié)構(gòu),*和1的含義是表和表之間的關(guān)聯(lián)關(guān)系,例如采購記錄和商品信息是多對一關(guān)系,即采購記錄表中的每條數(shù)據(jù)只能對應(yīng)商品信息表中的一條數(shù)據(jù),商品信息表中的一條數(shù)據(jù)可以對應(yīng)采購記錄表中的多條數(shù)據(jù)。

因為你采用了科學的數(shù)據(jù)表格管理,記錄了門店的所有采購入庫和銷售數(shù)據(jù),這讓你的經(jīng)營變得井井有條;通過這些原始數(shù)據(jù),你可以準確的管理庫存、計算利潤、掌握暢銷品和滯銷品,還能通過數(shù)據(jù)透視表制作銷售日報和月報。

實際上你通過以上三張表格管理自己的生意,已經(jīng)是一個管理軟件的雛形了。所有的軟件系統(tǒng)無非都是對數(shù)據(jù)的增刪改查操作;可以說,如果使用得當,Excel也可以做出一套小型的軟件系統(tǒng)。

2、小超市的輕量級ERP之路

因為你善于使用信息技術(shù)來協(xié)助你做生意,你的買賣發(fā)展迅速;很快,你將小門店升級成為一家小型超市,并且雇傭了幾個店員來幫你。作為店長,你興奮的繪制出自己的第一張組織架構(gòu)圖,夢想著事業(yè)會繼續(xù)壯大。

因為經(jīng)營的貨品更加豐富,日交易量成倍增長,并且有好幾名員工需要做數(shù)據(jù)錄入分析工作,這時Excel已經(jīng)難以滿足經(jīng)營管理的需要。因此明智的你在開店之前,就決定采購一套ERP軟件來協(xié)助你管理超市。因為你還處于創(chuàng)業(yè)期,資金有限,通過仔細挑選,你選擇了一套輕量級的ERP,并且只購買了其中的幾個核心模塊,這樣既可以控制成本,又可以讓你經(jīng)營的軟件設(shè)備升級。

現(xiàn)在,我們可以繪制公司的第一張應(yīng)用架構(gòu)圖,公司擁有一套系統(tǒng),包含三個模塊。

3、通過CRM拉近與客戶的距離

為了更加準確的理解、認識你的客戶,同時也為了能夠拉近你和客戶的距離,你打算通過CRM軟件進行更加科學的客戶管理。

你設(shè)計了一套會員積分制度,所有的客戶都能免費辦理會員,這樣你就可以記錄下關(guān)鍵的客戶信息,而且你的小伙伴建議你開通一個微信公眾號,讓客戶能夠通過微信來查詢自己的積分。

這個主意太棒了!你追加購買了幾個ERP的模塊,雖然ERP中也包含了CRM模塊,但是研究后你認為內(nèi)置的CRM模塊功能有限,不支持對接微信,營銷功能也不夠強大,因此你新購買了一套CRM軟件,和ERP進行了一定程度的對接,同時申請了微信公眾號,找外包公司做了一些定制化開發(fā)。這樣上述想法就都實現(xiàn)了!

我們繪制出公司的第二張應(yīng)用架構(gòu)圖。

可以看到,核心的客戶信息資產(chǎn)模塊都在CRM中實現(xiàn),其中內(nèi)置了營銷模塊、消息推送服務(wù)Msg模塊,包括SMS、EDM(Email Direct Marketing)和微信消息推送。

  • CRM主要聚焦客戶資料的管理和營銷服務(wù),主要用戶為店長和運營人員;
  • ERP主要聚焦于超市的進銷存以及財務(wù)業(yè)務(wù),主要用戶為營業(yè)員、出納、采購、庫管和會計。

請注意:這里已經(jīng)產(chǎn)生了應(yīng)用架構(gòu)設(shè)計的概念。公共號、ERP和CRM每個系統(tǒng)都為了解決某一大類的業(yè)務(wù)問題而存在,有各自清晰地定位、分工和目標用戶,每個系統(tǒng)相對獨立又互有關(guān)聯(lián),內(nèi)置若干模塊,每個模塊都是為了解決某一大類業(yè)務(wù)問題下的某一小類問題而設(shè)計。

在這張圖中我們使用了分層描述,靠近C端用戶的微信公眾號在最上層,支持業(yè)務(wù)運轉(zhuǎn)的ERP放在中間層,偏底層的客戶信息集成CRM放在最下層,這樣可以清晰地看出幾個系統(tǒng)的層次關(guān)系,同時也在一定程度反映了系統(tǒng)和業(yè)務(wù)之間的邏輯對應(yīng)關(guān)系。

4、中型連鎖超市的架構(gòu)之路

業(yè)務(wù)進展很順利,你已經(jīng)開了五家中型連鎖超市了,員工數(shù)量達到了幾百人。公司走上了正軌,標準化的管理分工已經(jīng)成型,不同職能單元各司其職。為了有效管理團隊,并且讓內(nèi)部流程更加順暢,你邀請專業(yè)的IT咨詢公司幫你重新梳理了公司的業(yè)務(wù)目標、組織架構(gòu)、運營流程,通過引入OA、HRM以及重構(gòu)ERP等手段,對不合理的制度,低效的流程進行了改造。公司成立了信息技術(shù)部,其中項目部配合咨詢公司以及軟件外包公司進行系統(tǒng)改造或?qū)嵤┬孪到y(tǒng),運維部負責保證服務(wù)器、網(wǎng)絡(luò)的穩(wěn)定。

你理解數(shù)據(jù)對公司發(fā)展的重要性,所有的管理決策都應(yīng)該基于對數(shù)據(jù)的分析和判斷,因此你邀請咨詢公司幫你強化公司的數(shù)據(jù)分析能力。

咨詢顧問建議你實施數(shù)據(jù)倉庫(Data Warehouse)和BI(Business Intelligence)項目,原因有幾點:

  1. ERP系統(tǒng)和CRM系統(tǒng)都有報表模塊,但兩個系統(tǒng)的數(shù)據(jù)相互孤立,不利于整合分析。
  2. 業(yè)務(wù)系統(tǒng)的底層數(shù)據(jù)結(jié)構(gòu)并不適合做復(fù)雜的數(shù)據(jù)分析,常見的多維分析更需要一套數(shù)據(jù)倉庫常用的星形數(shù)據(jù)結(jié)構(gòu)和雪花型數(shù)據(jù)結(jié)構(gòu)。
  3. 成熟的BI軟件套件可以讓你的報表分析與多維數(shù)據(jù)探查更輕松,其中的儀表盤更能夠讓你輕松掌控公司全局的核心指標變化。
  4. 企業(yè)經(jīng)營中很常見的一個問題,就是經(jīng)營分析指標統(tǒng)計口徑太多,造成管理混亂和溝通障礙,除了在管理上規(guī)范公司級指標的定義,也需要一套底層數(shù)據(jù)架構(gòu),消除上游各個異構(gòu)系統(tǒng)的孤島和屏障,統(tǒng)一管理匯總數(shù)據(jù)和指標計算。

咨詢顧問建議,雖然目前公司的業(yè)務(wù)系統(tǒng)還沒有到非常復(fù)雜的階段,但數(shù)據(jù)倉庫可以幫助企業(yè)更快速高效準確的理解、捕獲、使用數(shù)據(jù),做好基礎(chǔ)建設(shè)工作,培養(yǎng)員工的數(shù)據(jù)分析意識和方法,通過數(shù)據(jù)來進行決策。隨著業(yè)務(wù)的拓展和系統(tǒng)復(fù)雜性的提升,數(shù)據(jù)倉庫的存在價值將越來越明顯。

在數(shù)據(jù)倉庫項目中,同時構(gòu)建了數(shù)據(jù)集市(Data Mart)。數(shù)據(jù)集市介于BI展現(xiàn)層和DW數(shù)據(jù)底層之間,是數(shù)據(jù)倉庫的數(shù)據(jù)子集。數(shù)據(jù)倉庫的服務(wù)對象通常為全公司或全集團,但是不同部門可能有自己的數(shù)據(jù)分析訴求與指標管理訴求,這時候通過統(tǒng)一的數(shù)據(jù)底層,封裝出針對某個部門使用的小型數(shù)據(jù)集市,可以保證數(shù)據(jù)流的合理性、可追溯性,同時研發(fā)部門可以完全復(fù)用DW和BI的技術(shù)能力,輕松地設(shè)計實施DM。

如果希望數(shù)據(jù)倉庫在企業(yè)中真正發(fā)揮作用,不僅僅是軟件系統(tǒng)實施問題,更重要的是公司層面的經(jīng)營分析思路體系化,指標管理規(guī)范化,以及數(shù)據(jù)部門組織架構(gòu)、與業(yè)務(wù)部門合作流程設(shè)計問題,同時還需要提升全員數(shù)據(jù)化管理運營的概念和意識。軟件本身并不能解決企業(yè)的問題,只有配套的架構(gòu)、流程、制度與意識,才能發(fā)揮軟件的功效。

5、應(yīng)用架構(gòu)跟隨業(yè)務(wù)而變

由于公司經(jīng)營良好,很多商品可以從供應(yīng)商處拿到很好的價格,經(jīng)過供應(yīng)商授權(quán),公司決定開展2B業(yè)務(wù),成立了大客戶銷售部,公司將作為供應(yīng)商的B端渠道,挖掘企業(yè)客戶。為了讓銷售工作高效展開,對銷售人員進行嚴格的過程管理,同時也為了保留客戶資料,避免銷售獨占客戶資源,根據(jù)CTO建議,公司決定實施操作型OCRM(Operating CRM)項目。同時由于各部門經(jīng)常出現(xiàn)個性化的軟件開發(fā)訴求,軟件外包維護的成本高,效率低,公司決定招聘研發(fā)團隊,用自己的隊伍進行軟件的二次開發(fā)。

在設(shè)計OCRM系統(tǒng)時。CTO面臨兩個選擇:

方案一:新做一套獨立于現(xiàn)有CRM的OCRM

  • 優(yōu)點:OCRM系統(tǒng)已有成熟的軟件可以選擇,無需從頭開發(fā);兩個系統(tǒng)邊界清晰,分工明確,便于未來各自的發(fā)展與演變。
  • 缺點:應(yīng)用架構(gòu)會略有復(fù)雜,需要將原有的CRM和OCRM做數(shù)據(jù)打通,對原有的客戶模型做升級。

方案二:在原有的CRM基礎(chǔ)上開發(fā)新模塊

  • 優(yōu)點:新開發(fā)的模塊完全基于公司業(yè)務(wù)流程和模式設(shè)計,適配程度高。
  • 缺點:新開發(fā)模塊成本高速度慢,系統(tǒng)邊界模糊,導(dǎo)致以后維護升級時模塊管理的混亂。

綜合評估兩套方案實現(xiàn)的成本和速度,考慮到對未來業(yè)務(wù)變化的靈活支持,同時為了避免影響核心CRM業(yè)務(wù)的穩(wěn)定性,CTO決定采用方案一,讓兩個系統(tǒng)各自聚焦,互相獨立,邊界清晰,雖然無形中增加了公司應(yīng)用架構(gòu)的復(fù)雜性,但可以快速實施支持當前的緊迫業(yè)務(wù),并靈活應(yīng)對未來公司的銷售業(yè)務(wù)變化。

一般來講:B端客戶的數(shù)據(jù)模型和C端客戶差異非常大,B端客戶模型關(guān)注組織架構(gòu)和人員角色的描述,C端客戶模型關(guān)注客戶本身個人信息的描述,即便應(yīng)用系統(tǒng)中將客戶模型和操作型系統(tǒng)分開建設(shè),客戶模型一定會做成兩套以支持不同的上下游業(yè)務(wù)系統(tǒng)。

上圖為了簡化表述,只繪制了一個模塊“客戶信息”,但讀者應(yīng)該認識到:該模塊應(yīng)該包含B端、C端兩套客戶模型。實際上有的公司會明確將兩套客戶模型在應(yīng)用架構(gòu)中分開設(shè)計并且分別建設(shè),以便更加準確的體現(xiàn)應(yīng)用架構(gòu)中的業(yè)務(wù)概念。

廣義上來講,CRM代表一種企業(yè)對待核心客戶資源的管理理念和運營方法,CRM是一種概念而非某一個獨立的應(yīng)用系統(tǒng)。

大型的企業(yè)涉及多條業(yè)務(wù)線,不同的業(yè)務(wù)線有不同的客戶群。企業(yè)需要有統(tǒng)一的客戶視圖和管理理念,以及強大的IT系統(tǒng)支持,來實現(xiàn)準確的客戶接觸點管理,充分挖掘客戶群體實現(xiàn)精準銷售,積極有效的維護企業(yè)和客戶的關(guān)系。

CRM體系化的系統(tǒng)建設(shè)中包含了客戶建模、會員積分管理、營銷中心、銷售線索和過程管理、小型數(shù)據(jù)倉庫或數(shù)據(jù)集市、統(tǒng)一客戶視圖、客戶畫像和數(shù)據(jù)挖掘、電話銷售中心等等。不同的企業(yè)對系統(tǒng)的劃分和團隊的管理各不相同,但所有CTO都應(yīng)該明白CRM是一套應(yīng)用體系,而不僅僅是某個單一的獨立應(yīng)用系統(tǒng)。

至此,我們已經(jīng)繪制出一套一般企業(yè)的簡化版應(yīng)用架構(gòu)圖,以及一張常見的組織架構(gòu)圖。可以看到,應(yīng)用系統(tǒng)的建設(shè),是根據(jù)業(yè)務(wù)的發(fā)展變化逐步完成的,每個系統(tǒng)都有獨立存在的意義和價值。

二、多元化業(yè)務(wù)帶來的應(yīng)用架構(gòu)演變

1、在線商城業(yè)務(wù)帶來了互聯(lián)網(wǎng)化管理

公司的零售業(yè)務(wù)發(fā)展進入了瓶頸期,CEO需要尋找新的增長點。

經(jīng)過評估,決定開展電商業(yè)務(wù),新成立了電商部,從市場上聘來了某電商平臺VP作為部門負責人,直接給CEO匯報。為了學習互聯(lián)網(wǎng)公司,以技術(shù)力量推動業(yè)務(wù)創(chuàng)新,電商部組織結(jié)構(gòu)參考了一般互聯(lián)網(wǎng)公司組織結(jié)構(gòu),有自己獨立的研發(fā)團隊,設(shè)置了產(chǎn)品崗位,產(chǎn)品技術(shù)總監(jiān)給電商部負責人匯報。電商部受到CEO極度重視,給與極高自治權(quán)和最高資源支持,同時CEO還將之前線下的客服團隊升級為公司一級部門,直接給CEO匯報,統(tǒng)一處理線上線下的客服與售后業(yè)務(wù)。

新業(yè)務(wù)開展,大家干勁十足,因為電商部產(chǎn)品技術(shù)總監(jiān)和公司CTO之間不存在匯報關(guān)系,產(chǎn)品技術(shù)總監(jiān)為了快速推進項目,所有決策基本只是告知CTO。產(chǎn)品技術(shù)總監(jiān)作為純互聯(lián)網(wǎng)背景專家,認為購買現(xiàn)成軟件套件不利于系統(tǒng)的二次開發(fā)和自主維護,長遠來看會限制公司業(yè)務(wù)發(fā)展,希望整套系統(tǒng)實現(xiàn)自主研發(fā)。雖然CTO極力反對,但經(jīng)過電商部負責人和產(chǎn)品技術(shù)總監(jiān)的游說,CEO聽取了總監(jiān)的建議,并且總監(jiān)承諾自己的研發(fā)團隊效率極高,一定會在承諾之日交付系統(tǒng)。

產(chǎn)品技術(shù)總監(jiān)設(shè)計的應(yīng)用架構(gòu)體系,包括PC和移動版的前端應(yīng)用,以及完整的后端系統(tǒng),包括訂單、售后、客戶信息、會員、營銷、賬號、CMS。此外,倉儲、財務(wù)系統(tǒng)會接入現(xiàn)有ERP的服務(wù),配送模塊直接與第三方配送服務(wù)商系統(tǒng)對接。對于這個架構(gòu)設(shè)計,CTO比較不滿,認為客戶信息和賬號管理不應(yīng)該重復(fù)建設(shè),而應(yīng)該統(tǒng)一規(guī)劃管理,但產(chǎn)品技術(shù)總監(jiān)一心快速推進實施,對于信息技術(shù)部開發(fā)效率低的情況他早有耳聞,他可不希望被一些不可控力影響導(dǎo)致自己的項目延期,因此CTO的抗議他不予理會。

升級后的客服部門,新建了20人坐席的電銷中心,以支持主要來自于線上的電話客服訴求。新成立的客服團隊需要CallCenter系統(tǒng)開展業(yè)務(wù),雖然CallCenter的主要服務(wù)群體是線上業(yè)務(wù)的客服話務(wù)員,但CEO為了在一定程度上安撫CTO的不滿情緒,將CallCenter項目安排給CTO負責。CTO采購了一套成熟CallCenter來支持400熱線業(yè)務(wù),對此安排電商部的產(chǎn)品技術(shù)總監(jiān)沒有什么異議,但在CallCenter的實施中卻出現(xiàn)了問題。因為CallCenter系統(tǒng)只負責電話作業(yè),其中的客戶資料一般由上游系統(tǒng)提供。但是公司現(xiàn)有兩套客戶資料,一套是保存在CRM的線下業(yè)務(wù)客戶資料庫,一套是在線商城的客戶資料庫。為此只能在CallCenter中新增一套客戶庫,將另外兩套客戶庫數(shù)據(jù)同步過來,這樣客服人員才能在CallCenter中查到公司級別的完整客戶信息。

2、信息孤島與主數(shù)據(jù)管理

電商系統(tǒng)如期上線,業(yè)務(wù)發(fā)展迅速,電商團隊的運營和產(chǎn)品人員年輕,聰明,充滿活力,思維活躍,玩法眾多,電商技術(shù)團隊響應(yīng)迅速,產(chǎn)品經(jīng)理和技術(shù)團隊的無縫配合,讓技術(shù)力量真正推動了業(yè)務(wù)的增長。公司賺錢了,老板很開心。但很多問題也同時暴露了出來。我們先來看看之前的應(yīng)用架構(gòu)。

之前為了快速上線,有一些應(yīng)用架構(gòu)遺留問題沒有解決。現(xiàn)在公司有三套客戶資料庫,線下客戶通過微信公共號訪問CRM系統(tǒng)中的客戶信息,在線商城的客戶通過線上商城訪問e-Store系統(tǒng)的客戶信息。當客戶致電400時,電銷業(yè)務(wù)員(TSR)訪問的是從e-Store和CRM同步過來的客戶信息。

線上客戶關(guān)注公共號后,查不到自己的資料,這讓客戶感覺很詭異。

線下客戶想在線上商城下單,發(fā)現(xiàn)之前登記的賬號不能使用,需要重新注冊完善資料,客戶很煩躁。

數(shù)據(jù)同步30分鐘一次,有時候客戶剛修改完資料再致電400,客服查到的客戶信息不是最新的,讓客戶很生氣,客服很苦惱。

有的客戶喜歡打電話讓客服改資料,因為客戶資料是單向同步,客服無法協(xié)助客戶修改資料,客戶很氣憤,為什么你們連這點服務(wù)都做不好!

很多客戶在線上線下都消費,但由于在數(shù)據(jù)倉庫中冗余出了兩個客戶對象,不論是線上團隊還是線下團隊,都無法做更準確的客戶畫像和跨渠道消費行為分析。

CEO很生氣,找到CTO和電商產(chǎn)品技術(shù)總監(jiān),質(zhì)問怎么回事。CTO回答,我們遇到了嚴重的信息孤島問題!由于CRM和商城后臺數(shù)據(jù)互相孤立,導(dǎo)致核心客戶資源不同步,不統(tǒng)一,讓公司無法得到一個完整準確的客戶視圖。如果要解決這個問題,必須對應(yīng)用架構(gòu)進行改造,并且改造比較耗時。CEO很郁悶,沒想到應(yīng)用架構(gòu)不合理會影響到業(yè)務(wù)發(fā)展,也沒有想到組織架構(gòu)的設(shè)計會導(dǎo)致應(yīng)用架構(gòu)出問題。為此,CEO做了一些調(diào)整,產(chǎn)品技術(shù)總監(jiān)實線向電商部經(jīng)理匯報,虛線向CTO匯報;總體來講產(chǎn)品技術(shù)總監(jiān)對電商業(yè)務(wù)銷售端負責,CTO對全公司IT架構(gòu)管理和其他所有系統(tǒng)負責。經(jīng)過善意的溝通,CTO和產(chǎn)品技術(shù)總監(jiān)的矛盾消除了,大家決定合力解決問題。

解決數(shù)據(jù)信息孤島的方法很簡單,那就是只保留一份客戶信息庫,這份客戶信息庫保存最核心的,與業(yè)務(wù)單元無關(guān)的客戶屬性和資料。至于積分、會員等擴展屬性依然由各個應(yīng)用系統(tǒng)維護管理。調(diào)整后的應(yīng)用架構(gòu)圖如下:

將客戶信息庫獨立,商城、CallCenter、CRM和微信公共號通過統(tǒng)一接口調(diào)用Customer Profile存儲的核心客戶檔案,不論客戶或業(yè)務(wù)員從哪個端口查看或修改信息,變化對其他端口都是透明、實時的。實際上這就是客戶主數(shù)據(jù)管理MDM(Master Data Management)的設(shè)計理念。

在企業(yè)應(yīng)用系統(tǒng)建設(shè)中,不可避免的會遇到信息孤島問題,信息孤島是指因為各種原因,每個應(yīng)用系統(tǒng)獨立建設(shè)時,沒有和外界系統(tǒng)做良好的打通,導(dǎo)致應(yīng)用系統(tǒng)之間存在流程或數(shù)據(jù)的孤立性,最終給業(yè)務(wù)帶來嚴重影響。解決數(shù)據(jù)信息孤島的經(jīng)典方法就是主數(shù)據(jù)管理(MDM)的思想,主數(shù)據(jù)管理通過應(yīng)用架構(gòu)的拓撲設(shè)計,配合相應(yīng)的管理手段,幫助企業(yè)存儲、識別唯一的關(guān)鍵數(shù)據(jù),避免企業(yè)內(nèi)部關(guān)鍵數(shù)據(jù)的冗余和不一致問題。常見的主數(shù)據(jù)有客戶主數(shù)據(jù),商品主數(shù)據(jù)等。

主數(shù)據(jù)管理的設(shè)計理念應(yīng)該自始至終貫穿企業(yè)應(yīng)用架構(gòu)的設(shè)計過程,需要注意的是,企業(yè)應(yīng)該在合適的階段實施主數(shù)據(jù)管理和治理。主數(shù)據(jù)將應(yīng)用架構(gòu)變得更復(fù)雜,在初期階段實施時需要投入更多時間和資源,而在企業(yè)發(fā)展的某些階段,快速迭代上線意味著對商機的捕獲和市場變化的迅速跟進,一個合格的架構(gòu)師應(yīng)該在應(yīng)用架構(gòu)設(shè)計和公司業(yè)務(wù)發(fā)展之間做出合理權(quán)衡,要根據(jù)現(xiàn)實的情況和資源,敢于在應(yīng)用架構(gòu)的和理性上做出妥協(xié)和讓步。

主數(shù)據(jù)經(jīng)常作為底層數(shù)據(jù)應(yīng)用來管理,因此在架構(gòu)圖中我們將它和DW并列畫在最底層。

3、抽離共性模塊全面服務(wù)化建設(shè)

公司業(yè)務(wù)發(fā)展穩(wěn)定,各個系統(tǒng)底層做過幾次技術(shù)重構(gòu),性能更強健。為了讓各個應(yīng)用系統(tǒng)更加聚焦,提升穩(wěn)定性,節(jié)約開發(fā)成本,避免重復(fù)勞動,CTO和產(chǎn)品技術(shù)總監(jiān)討論后決定對一些公有服務(wù)從各自應(yīng)用系統(tǒng)中剝離,統(tǒng)一進行服務(wù)化改造升級,為以后公司新業(yè)務(wù)的開展打好基礎(chǔ)。例如,將CRM和商城后臺的消息模塊功能合并,將商城支付模塊單獨剝離,設(shè)計實施了集成化的權(quán)限管理系統(tǒng)Auth,給全公司多個應(yīng)用提供統(tǒng)一的權(quán)限管理服務(wù),控制公司運營風險。

CTO和產(chǎn)品技術(shù)總監(jiān)合作加強了數(shù)據(jù)團隊建設(shè),設(shè)立了數(shù)據(jù)挖掘團隊,豐富了客戶畫像,加強了經(jīng)營分析能力,產(chǎn)生了更多的策略輸出。數(shù)據(jù)策略輸出不僅給在線商城提供了更強勁的推薦策略,也為CRM,運營人員提供了更豐富的策略運營、精準定向活動推送支持。

4、強健的底層架構(gòu)快速支持新業(yè)務(wù)開展

公司在尋找新的增長點,計劃開展個人理財業(yè)務(wù)。公司的組織架構(gòu)有了新的調(diào)整,管理模式也有了新的提升,形成了集團化治理模式,成立了財務(wù)共享中心,人力資源共享中心。新設(shè)立的理財事業(yè)部,和零售事業(yè)部、電商事業(yè)部一起,調(diào)整為獨立核算事業(yè)部編制,事業(yè)部聚焦經(jīng)營和銷售,集團層面給事業(yè)部提供基礎(chǔ)運作支持。信息技術(shù)部也與時俱進,將之前的需求管理部調(diào)整為產(chǎn)品部,信息技術(shù)部主要負責CRM、CallCenter、ERP、OA、HRM、DW、BI等應(yīng)用系統(tǒng),保證集團職能部門運作,為事業(yè)部的應(yīng)用系統(tǒng)提供基礎(chǔ)架構(gòu)和底層服務(wù)支持。

因為集團IT應(yīng)用架構(gòu)已經(jīng)非常強健,理財業(yè)務(wù)的系統(tǒng)構(gòu)建可以迅速展開,CTO和理財事業(yè)部的產(chǎn)品總監(jiān)溝通后繪制了集團應(yīng)用架構(gòu)圖,理財業(yè)務(wù)只需要建設(shè)一套C端APP和一套基本的管理后臺,而類似于客戶數(shù)據(jù)、支付、Push服務(wù)、DW和BI都直接使用集團現(xiàn)有系統(tǒng),無需重新開發(fā)。

CTO和產(chǎn)品總監(jiān)討論后,認為上述架構(gòu)圖還存在一點問題,賬號管理不應(yīng)該單獨創(chuàng)建,集團已經(jīng)有著很成熟的統(tǒng)一客戶管理理念,多套賬號管理模塊會再次造成信息孤島問題。因此決定將現(xiàn)有的賬號管理模塊也進行平臺化、服務(wù)化升級,給理財業(yè)務(wù)提供支持。集團層面的Passport系統(tǒng)誕生了。更新后的架構(gòu)圖如下。

這里順便解釋一下:為什么本文對所有軟件系統(tǒng)都稱為系統(tǒng),而互聯(lián)網(wǎng)公司則習慣稱其為產(chǎn)品。

互聯(lián)網(wǎng)的發(fā)展催生了產(chǎn)品經(jīng)理的崗位。產(chǎn)品經(jīng)理常分為C端產(chǎn)品經(jīng)理,B端產(chǎn)品經(jīng)理(包括商家端和運營管理中后臺)等。

B端產(chǎn)品線中,有CRM產(chǎn)品經(jīng)理、供應(yīng)鏈產(chǎn)品經(jīng)理等。在互聯(lián)網(wǎng)公司似乎不太在意區(qū)分產(chǎn)品和系統(tǒng)的叫法,到底兩者有何區(qū)別?

實際上,所謂產(chǎn)品是指企業(yè)提供的商品或服務(wù),給企業(yè)帶來利潤。早期的互聯(lián)網(wǎng)公司多為虛擬經(jīng)濟形態(tài),面向用戶的軟件系統(tǒng)就是公司給消費者提供的商品或服務(wù),因此聚焦軟件功能設(shè)計的人員被稱為產(chǎn)品經(jīng)理。而互聯(lián)網(wǎng)公司是一類高度依賴信息技術(shù)能力驅(qū)動業(yè)務(wù)的公司,對各類軟件系統(tǒng)都傾向于自主建設(shè),因此不論是面向客戶的系統(tǒng),或面向企業(yè)內(nèi)部的系統(tǒng),軟件設(shè)計人員都統(tǒng)一叫做產(chǎn)品經(jīng)理,其職責定位就是負責軟件的設(shè)計和實現(xiàn),軟件系統(tǒng)習慣被稱為產(chǎn)品;而在傳統(tǒng)企業(yè),負責軟件設(shè)計的人員一般都叫做需求分析師或系統(tǒng)分析員,軟件系統(tǒng)習慣被稱為系統(tǒng)。

其實怎么稱呼都無所謂,本文統(tǒng)一叫做系統(tǒng)。

三、企業(yè)通用應(yīng)用架構(gòu)設(shè)計

1、通用企業(yè)應(yīng)用架構(gòu)圖

對上文的應(yīng)用架構(gòu)圖做一些簡化和調(diào)整,以便更加準確的體現(xiàn)應(yīng)用架構(gòu)的共性以及與業(yè)務(wù)的對應(yīng)關(guān)系,得到一張更加清晰簡潔的企業(yè)級應(yīng)用架構(gòu)圖。

第一層是對外系統(tǒng)。所有給企業(yè)外部客戶使用的系統(tǒng)都在這一層,包括官網(wǎng),普通用戶或客戶使用的C端。如果是類似于美團,天貓這種平臺性質(zhì)的業(yè)務(wù),還會包括給商家使用的商家端。這類系統(tǒng)站在與客戶接觸的最前線,是公司實現(xiàn)商業(yè)模式的橋頭堡。

第二層是對應(yīng)C端系統(tǒng)的管理后臺。常見的管理后臺都會包含訂單、CMS、商品等模塊。每個C端業(yè)務(wù)形態(tài)都會對應(yīng)一個管理后臺,有些管理后臺的模塊可能會被抽離出來集中維護,例如風控,消息服務(wù),客戶主數(shù)據(jù)。

第三層是業(yè)務(wù)單元支持系統(tǒng)。絕大多數(shù)企業(yè)業(yè)務(wù)的開展,必然不能單純靠線上的運作來實現(xiàn)經(jīng)營,而可能包含電話銷售,客服,地推,倉配等一系列業(yè)務(wù)單元共同運作。業(yè)務(wù)單元的運作需要強大的系統(tǒng)支撐。

第四層是職能單元支持系統(tǒng)。企業(yè)發(fā)展到一定規(guī)模后,必然會有完善的職能單元作為后勤部門支持業(yè)務(wù)單元的運轉(zhuǎn)和企業(yè)的正常運作,例如法務(wù)、財務(wù)、人力、客服,每個部門的正常運轉(zhuǎn)都需要相應(yīng)系統(tǒng)的支持。

第五層是基礎(chǔ)架構(gòu)支持系統(tǒng)。信息化建設(shè)到達一定程度后,企業(yè)有必要將通用功能服務(wù)化,平臺化,以保證應(yīng)用架構(gòu)的合理性,提升服務(wù)效率。這類系統(tǒng)主要給其他應(yīng)用系統(tǒng)提供基礎(chǔ)服務(wù)能力支持。

第六層是數(shù)據(jù)底層,和第五層類似,這一層主要集中在數(shù)據(jù)層面的統(tǒng)一和封裝,對各個下游系統(tǒng)提供數(shù)據(jù)服務(wù)。

以上六層劃分涵蓋了企業(yè)所有的應(yīng)用系統(tǒng)建設(shè),每一個應(yīng)用系統(tǒng)的存在都將定位在六層中的某一層。上圖示例的系統(tǒng)涵蓋了絕大多數(shù)正常企業(yè)經(jīng)營運轉(zhuǎn)常見的應(yīng)用系統(tǒng),在現(xiàn)實世界中,應(yīng)用系統(tǒng)數(shù)量會遠遠多于上圖所示,例如商業(yè)銀行可能會有成百上千個系統(tǒng)存在。但是理解一個常見企業(yè)的組織結(jié)構(gòu),部門定位,以及上述應(yīng)用架構(gòu)圖形成的原因,可以讓你更準確快速的理解、掌握、設(shè)計任意一個應(yīng)用系統(tǒng)。

2、不同類型企業(yè)的應(yīng)用架構(gòu)圖示例

因為一般企業(yè)的組織架構(gòu)設(shè)計,職能單元的設(shè)計基本沒有太大區(qū)別,而以上簡化版的應(yīng)用架構(gòu)圖映射了一個標準化企業(yè)的各個常規(guī)業(yè)務(wù)單元,且涵蓋了絕大多數(shù)企業(yè)中標準的應(yīng)用系統(tǒng),所以我們可以將不同互聯(lián)網(wǎng)企業(yè)的應(yīng)用架構(gòu)圖映射到上圖中。

下面我們用三個例子,向讀者演示不同業(yè)務(wù)形態(tài)、發(fā)展階段的公司,其應(yīng)用架構(gòu)的可能形態(tài)。作者并未在以下公司任職,或與相關(guān)內(nèi)部人員探討過其公司應(yīng)用架構(gòu),以下示意圖均為作者根據(jù)幾個公司的業(yè)務(wù)特點和發(fā)展階段,所做的推測。

首先以美團點評為例。

美團的業(yè)務(wù)模式主要為供需平臺建設(shè),幫助消費者和服務(wù)提供方撮合交易。外部系統(tǒng)包括了C端系統(tǒng)和商家端系統(tǒng),C端系統(tǒng)為消費者常用APP,商家端系統(tǒng)為商家提供商品管理、交易管理、推廣管理、經(jīng)營分析等功能。C端或商家端都對應(yīng)后端管理系統(tǒng),方便企業(yè)內(nèi)部對整個平臺進行管理、營銷、風控等。

平臺需要發(fā)掘更多的商戶資源入駐,因此會有銷售過程管理的OCRM系統(tǒng);平臺需要對C端客戶提供客服與售后支持服務(wù),相信美團點評的業(yè)務(wù)量,一套專業(yè)的CallCenter系統(tǒng)必不可少;美團提供了自營的配送服務(wù),TMS系統(tǒng)必然成為標配(也有可能是SCM中的模塊)。

由于美團業(yè)務(wù)不涉及自營的實物貨物買賣服務(wù),沒有倉儲體系,因此推測沒有WMS系統(tǒng)(或者ERP中包含了WMS模塊但是沒有啟用)。O2O業(yè)務(wù)需要管理大量線下門店,因此GIS(Geography Information System)系統(tǒng)不可或缺,對于實力較強的公司,可能還會開發(fā)獨立的POI(Point of Information)管理系統(tǒng)(也有可能是GIS中的模塊)。至于財務(wù)、OA、Passport、Auth、BI、DW、MDM等,必然都是公司標配。

接下來再以今日頭條為例。

今日頭條構(gòu)建了信息流資訊類C端,吸引網(wǎng)民使用,這類產(chǎn)品最常見的盈利方式為廣告變現(xiàn)。在公司經(jīng)營之初,可能采取了市面上的DSP平臺來完成APP的廣告管理(當然也可能從來沒有采用過),為了更好的設(shè)計廣告產(chǎn)品,相信現(xiàn)在一定有自己的廣告投放管理平臺,因此公司會有給廣告主使用的B端廣告投放管理系統(tǒng)。

(當然也有可能還沒有這類平臺,作者在百度工作時很多商業(yè)變現(xiàn)產(chǎn)品投放管理都是PM和廣告主線下溝通后通過內(nèi)部平臺操作的)。

因為業(yè)務(wù)模式以廣告投放為變現(xiàn)手段,因此后端系統(tǒng)可能沒有交易類后端復(fù)雜,但基本的CMS和風控(反垃圾、反作弊、合法合規(guī))必然是有的。公司需要盈利,就需要售賣產(chǎn)品,售賣產(chǎn)品永遠不可能只在線上運作,必然會有BD團隊支持,因此今日頭條也會有CRM系統(tǒng),管理對象為廣告主而不是網(wǎng)民。

但是WMS、TMS系統(tǒng)這類系統(tǒng)估計就不需要了。至于CallCenter,筆者查詢了官網(wǎng),沒有找到相關(guān)的客服熱線,猜測還沒有建設(shè)。

今日頭條的早已度過創(chuàng)業(yè)期,標準的管理軟件應(yīng)該配備齊全,例如OA、HRM;不同的基礎(chǔ)架構(gòu)支持系統(tǒng),在當前階段有可能有,也有可能沒有;例如Auth、Pay、MDM等。作為一個純技術(shù)公司,BI、DW當然是標配。

最后的例子,我們挑一個相對規(guī)模小,產(chǎn)品形態(tài)單一的例子,例如墨跡天氣,萬年歷這類工具類應(yīng)用的公司。

這類公司在創(chuàng)業(yè)初期,不考慮變現(xiàn)的情況下,團隊小,產(chǎn)品簡單,應(yīng)用架構(gòu)圖也會非常簡單,在產(chǎn)品發(fā)布時,只需要實現(xiàn)官網(wǎng)、C端、后臺管理、賬號和會員管理就足夠了。當然隨著公司的發(fā)展,常見的變現(xiàn)手段之一就是廣告投放,可能會繼續(xù)演變到類似于今日頭條的應(yīng)用架構(gòu)。

以上舉了三個例子,讓讀者更好的理解應(yīng)用架構(gòu)演變和公司業(yè)務(wù)模式以及發(fā)展階段的關(guān)系。在實際工作中,應(yīng)用架構(gòu)的建設(shè)與面臨的情況會復(fù)雜得多,只要理解了以上簡化版的例子,可以更容易理解實際工作中的場景。

3、企業(yè)應(yīng)用架構(gòu)設(shè)計的一些建議

最后,我們來談一談如何合理的設(shè)計企業(yè)應(yīng)用架構(gòu)。不論是架構(gòu)師,產(chǎn)品條線負責人,或某個系統(tǒng)的產(chǎn)品負責人,都要有架構(gòu)設(shè)計的理念和知識,尤其是后端產(chǎn)品經(jīng)理,必須充分理解企業(yè)應(yīng)用架構(gòu)的基本概念。這里給出一些應(yīng)用架構(gòu)設(shè)計的建議。

1. 系統(tǒng)定位和邊界要清晰,對應(yīng)的業(yè)務(wù)定位和邊界要清晰

一套應(yīng)用系統(tǒng)的存在,都是為了解決某一類業(yè)務(wù)問題,對應(yīng)某一個業(yè)務(wù)板塊。如果業(yè)務(wù)板塊或業(yè)務(wù)單元定義模糊,也會導(dǎo)致對應(yīng)的應(yīng)用系統(tǒng)定位混亂。

2. 系統(tǒng)要實現(xiàn)松耦合,高內(nèi)聚

系統(tǒng)要對外界透明,簡單,易理解,與外部系統(tǒng)的接口要簡明,扼要,靈活。內(nèi)部模塊高度聚合,粒度越細越不可拆解。

3. 易變的,嘗試中的新業(yè)務(wù)要避免影響現(xiàn)有業(yè)務(wù)的穩(wěn)定性

對新業(yè)務(wù)的支持,可以考慮新建獨立微小型應(yīng)用系統(tǒng),以便避免改造成熟核心系統(tǒng),影響其穩(wěn)定性和健壯性。

4. 系統(tǒng)之間數(shù)據(jù)要實現(xiàn)單向流轉(zhuǎn)

系統(tǒng)之間盡量保證單向數(shù)據(jù)流轉(zhuǎn),確保數(shù)據(jù)流可回溯,數(shù)據(jù)的一致性和可追溯性?;靵y的數(shù)據(jù)流轉(zhuǎn)管理會造成應(yīng)用架構(gòu)管理的災(zāi)難。

5. 架構(gòu)設(shè)計核心目標是支持業(yè)務(wù),有些時候不合理的存在是合理的

應(yīng)用架構(gòu)存在的首要目標是支持業(yè)務(wù),很多成長性企業(yè)或初創(chuàng)公司面對生存的壓力,不能為了保證架構(gòu)的合理性而拖延系統(tǒng)實施速度導(dǎo)致企業(yè)錯過發(fā)展時機。這種情況在互聯(lián)網(wǎng)型企業(yè)更為常見。業(yè)務(wù)還在試錯期,系統(tǒng)需要盡快保證支持業(yè)務(wù)試錯,如果一上來就談?wù)撜w架構(gòu)的合理性,很可能花費巨大成本實現(xiàn)了合理架構(gòu)后,新業(yè)務(wù)已經(jīng)取消或失敗。優(yōu)秀的架構(gòu)師和CTO要懂得在合理架構(gòu)設(shè)計和靈活多變的業(yè)務(wù)發(fā)展之間做出智慧的權(quán)衡取舍。

對于CTO或公司架構(gòu)師,要保證整體企業(yè)應(yīng)用架構(gòu)的合理性,只要大框架合理,局部的偏差可以忽略,修正的成本也比較小,如果大框架有偏差,修正的代價會非常高。對于產(chǎn)品條線負責人,要保證局部框架的合理性,避免出現(xiàn)設(shè)計不合理造成的返工和補救工作。

很多時候架構(gòu)師或條線負責人要做出判斷,是做一套新系統(tǒng),還是修改老系統(tǒng);新系統(tǒng)如何定位,老系統(tǒng)如何調(diào)整定位;數(shù)據(jù)如何流轉(zhuǎn),系統(tǒng)之間如何關(guān)聯(lián),底層數(shù)據(jù)如何打通;是否要復(fù)用其他系統(tǒng)模塊,是否要將某些模塊抽象化,服務(wù)化,平臺化。對于產(chǎn)品經(jīng)理,要在系統(tǒng)級別的粒度做出類似問題的判斷,能夠識別出可能存在的系統(tǒng)演變風險,及時升級控制不了的問題,避免做出錯誤決策。

企業(yè)架構(gòu)是一套龐大復(fù)雜的體系,本文是對其中應(yīng)用架構(gòu)部分,結(jié)合作者實際工作經(jīng)驗的淺薄理解,業(yè)界有著眾多的企業(yè)架構(gòu)建設(shè)規(guī)范和指引,例如Zachman、EAP、TOGAF。這些框架涵蓋了信息技術(shù)和企業(yè)戰(zhàn)略結(jié)合實施的方方面面,感興趣的讀者可以做更深入的學習。

插播一條廣告

大家好,我是《決勝B端》作者楊堃,曾在VIPKID任產(chǎn)品總監(jiān)一職。在工作中,遇見有很多優(yōu)秀的B端產(chǎn)品經(jīng)理,但缺少體系化、針對B端產(chǎn)品的實操訓(xùn)練,在成長中走了許多彎路。

我努力將自己多年做B端產(chǎn)品的經(jīng)驗提煉總結(jié)出來,和起點學院聯(lián)合打造了一門B端產(chǎn)品體系課——《To B產(chǎn)品實戰(zhàn)訓(xùn)練營》希望能給需要的同學一些實質(zhì)性的幫助。

幫助大家構(gòu)建B端產(chǎn)品知識體系脈絡(luò),掌握B端產(chǎn)品建設(shè),從業(yè)務(wù)診斷、需求分析,到抽象建模、設(shè)計落地的全過程的方法思路,最終直接應(yīng)用于工作實踐。

掃碼即可報名,還可為大家爭取到的專屬優(yōu)惠~

立即搶座,報名成功后即可領(lǐng)取詳細課程資料!

作者:楊堃(微信號公眾號:goYangKun),9年互聯(lián)網(wǎng)研發(fā)、產(chǎn)品設(shè)計經(jīng)驗,曾就職于傳統(tǒng)外資保險公司,百度,現(xiàn)就職于vipkid。

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 謝謝作者大大~

    來自上海 回復(fù)
  2. 當了3年產(chǎn)品經(jīng)理,一直在思考產(chǎn)品的邊界和定義在哪里,突破口在哪里,
    而看完您的文章后,真的給了我很大的感悟!
    以后還會繼續(xù)拜讀的,感謝作者的分享!

    來自廣東 回復(fù)
  3. 厲害

    來自江蘇 回復(fù)
  4. 確實是精簡版架構(gòu)

    來自浙江 回復(fù)
  5. 太牛掰了,虧我做了那么多年的產(chǎn)品,野生型缺乏體系化的知識梳理,一看就恍然大悟了……不過也遇到一個問題,從零開始逐步梳理是相對容易的,但是突然空降某個已經(jīng)有點規(guī)模的企業(yè),從中間階段重塑信息化建設(shè),這個會比全新來得更加痛苦,希望有機會可以拜讀更多這些方面的分享呢

    來自廣東 回復(fù)
  6. 太牛了,大神!有沒有企業(yè)應(yīng)用架構(gòu)方面的書籍介紹?想深入進行研究

    來自廣東 回復(fù)
  7. 哪里有更多更詳細的講解

    來自廣東 回復(fù)
    1. 關(guān)注起點學院老師的TO產(chǎn)品實戰(zhàn)訓(xùn)練營,我不會告訴你,要開課了?。?/p>

      來自廣東 回復(fù)
  8. 謝謝分享

    來自上海 回復(fù)
  9. 一看就高潮,一做就陽痿 系列文章,感謝分享

    來自四川 回復(fù)
    1. 哈哈哈哈哈哈哈這酸爽

      來自江蘇 回復(fù)
  10. 這絕壁是個大神

    來自北京 回復(fù)
  11. 碉堡了

    來自浙江 回復(fù)
  12. NB了

    來自廣東 回復(fù)
  13. cms y用戶登陸

    回復(fù)
  14. 厲害,可以轉(zhuǎn)載嗎?楊兄

    來自上海 回復(fù)
  15. 請問MDM的客戶檔案對應(yīng)的后臺一般都有哪幾個功能模塊?

    來自北京 回復(fù)
  16. 頭條賣廣告位一大堆,目測有個非常龐大的call center

    來自浙江 回復(fù)
  17. 作者公眾號是什么

    來自廣東 回復(fù)
  18. 必須手工點贊。最近在嘗試在應(yīng)用架構(gòu)上的思考,無奈終不得法。恰巧看到這篇文檔,思路突然打開。感謝大神 :mrgreen:

    來自江蘇 回復(fù)
  19. 拜讀大作,有豁然開朗,醍醐灌頂之感。感謝分享

    來自河北 回復(fù)
  20. 我有一個疑問:消費者端和商家端對應(yīng)的都是各自的管理后臺?以【美團】為例,團購業(yè)務(wù)中是不是需要2個團隊負責消費者端和商家端?

    來自浙江 回復(fù)
    1. 一個管理后臺統(tǒng)一管理用戶和商戶

      來自安徽 回復(fù)
    2. 產(chǎn)品層面:C端產(chǎn)品和商家端產(chǎn)品,確實是2撥團隊負責;
      數(shù)據(jù)層面:C端消費者和B端商戶,都屬于主數(shù)據(jù),至少在到餐業(yè)務(wù)體系下所有業(yè)務(wù)都是通用的一套。

      來自北京 回復(fù)
  21. 已經(jīng)接觸ERP系統(tǒng)兩年多,做需求半年多,所做的功能涉及到toC端銷售,門店零售和網(wǎng)店零售,還有to B端銷售,雖然功能有相似之處,但是有些細節(jié)為何那么設(shè)計,還沒有想的那么透徹,看了這篇文章很受用,多一些小點豁然開朗?。「兄x作者!

    回復(fù)
  22. 學習到了,讓小子對架構(gòu)有更深一步的認識,不知可否加到作者。

    來自浙江 回復(fù)
    1. 可以加公眾號,也可以直接站內(nèi)留言。

      來自北京 回復(fù)
    2. 已加到公眾號

      回復(fù)
    3. 公眾號貌似沒了

      來自廣東 回復(fù)
  23. 厲害

    來自北京 回復(fù)
  24. 拜讀,寫的很精彩,往往實際當中業(yè)務(wù)多元化的發(fā)展很難實現(xiàn)預(yù)判,系統(tǒng)來配合業(yè)務(wù)進行升級也非朝夕之功,結(jié)合自己工作經(jīng)驗,主數(shù)據(jù)庫的設(shè)計很有必要,一年內(nèi)十幾個業(yè)務(wù)系統(tǒng)上馬,各業(yè)務(wù)部門溝通不當,信息孤島帶來的后果相當嚴重

    來自江西 回復(fù)
    1. 是的,做業(yè)務(wù)系統(tǒng),既需要有全局觀,又需要有短平快的功夫

      來自北京 回復(fù)
  25. 這個也可以反過來應(yīng)用嘍?先預(yù)想為發(fā)展為大企業(yè)所需要的架構(gòu),然后再根據(jù)公司的發(fā)展現(xiàn)狀上線所需要的應(yīng)用系統(tǒng),這樣可避免一些從小到大的過程中出現(xiàn)的兼容問題、孤島問題等。

    來自上海 回復(fù)
    1. 您說的非常對,寫這篇文章的目的,也是讓大家理解理想狀況應(yīng)該是什么樣的,我們當前階段是怎么樣的,如何演化,發(fā)展。

      來自北京 回復(fù)
  26. :mrgreen:

    來自廣東 回復(fù)
  27. 大寫的服

    回復(fù)
  28. 能從業(yè)務(wù)的發(fā)展和組織的變化,來把應(yīng)用架構(gòu)說得如此清晰,又簡單易懂,確實太厲害了 :mrgreen:
    必須收藏!

    來自廣東 回復(fù)
    1. 謝謝支持啦!

      來自北京 回復(fù)
  29. :mrgreen: :mrgreen: :mrgreen:

    來自上海 回復(fù)
  30. 厲害厲害

    來自廣東 回復(fù)