上海東方國際衣架信息化負(fù)責(zé)人邵佳宇：偶然中的必然選擇——中臺
“衣之霓裳，架于棟梁”，誕生于2012年的衣架女裝，是上海東方國際集團旗下的輕奢品牌。其門店主要集中在全國一、二線城市核心商圈，隨著電商的快速發(fā)展及消費者購物方式的轉(zhuǎn)變，2017年衣架開始布局線上線下的全渠道營銷模式，形成了目前直營+全渠道的營銷模式，并實現(xiàn)了線上線下的庫存共享。
基于已有的設(shè)計、開發(fā)、生產(chǎn)、分銷等信息化建設(shè)，衣架結(jié)合企業(yè)需要與第三方系統(tǒng)對接、多渠道數(shù)據(jù)打通、線上線下庫存共享等需求，通過與炎黃盈動的合作，衣架借助AWS PaaS平臺構(gòu)建了企業(yè)中臺，通過“前臺”+“中臺”的方式，實現(xiàn)了衣架最初“大中臺、小前臺”的構(gòu)思。整個中臺的部署，涵蓋了庫存中心、會員中心、訂單中心、店鋪中心、商品中心、分銷中心和倉儲中心，實現(xiàn)了多渠道，多體系的數(shù)據(jù)信息的統(tǒng)一管理。
衣架的信息化需求及挑戰(zhàn)
時間倒轉(zhuǎn)回2016年年底，衣架的CRM選型進入后期方案設(shè)計階段，公司希望在2017年可以完成三個關(guān)鍵的項目，即CRM系統(tǒng)上線，同時打通POS和CRM，形成會員權(quán)益的管理閉環(huán);打通天貓及線下門店的庫存，進行統(tǒng)一管理。
當(dāng)時CRM的選型已接近尾聲，CRM是基于 SaaS 的模式實現(xiàn)的，如何才能把會員數(shù)據(jù)沉淀到企業(yè)自身的數(shù)據(jù)庫中，是邵佳宇團隊首先考慮的問題。其次是如何統(tǒng)一微信、廣告引流、電商、線下門店搜所收集到的會員信息，確保CRM數(shù)據(jù)與企業(yè)自身的平臺數(shù)據(jù)交換能夠及時、完整和安全。
POS面臨全面升級。但在升級POS時，衣架采用的是分批次升級，因此，新舊系統(tǒng)必須可以同時使用。還需要做到底層數(shù)據(jù)庫不變，確保銷售完成后業(yè)務(wù)的數(shù)據(jù)驅(qū)動邏輯必須是一致的。CRM 強調(diào)會員服務(wù)和體驗，升級后POS和CRM系統(tǒng)要形成會員權(quán)益管理閉環(huán)，門店庫存實時更新，所有銷售數(shù)據(jù)實時傳回總部。
對于天貓庫存可以和線下共享這部分，衣架希望在盡可能不改變終端門店的日常操作習(xí)慣的基礎(chǔ)上實現(xiàn)不同渠道支持不同的庫存共享邏輯、不同渠道支持不同訂單的路由邏輯，同時還可以與天貓電商平臺對接。
通過對這幾個項目的研究，衣架女裝內(nèi)部初步判斷未來企業(yè)信息化的發(fā)展趨勢可能會存在需要大量跟第三方系統(tǒng)對接的場景。因此，衣架最初期望通過尋找一家服務(wù)商來搭建企業(yè)的ESB平臺，以實現(xiàn)與微信商城、淘寶等線上購物平臺，以及線下門店等第三方系統(tǒng)的對接;同時所有產(chǎn)生的經(jīng)營數(shù)據(jù)都可以沉淀在企業(yè)數(shù)據(jù)庫中;對所有的信息交互接口進行統(tǒng)一管理的目標(biāo)。
與中臺不期而遇
尋尋覓覓之際，在與行業(yè)內(nèi)的CIO們溝通的偶然機會，邵佳宇接受到了全新的信息化框架，它強調(diào)的是企業(yè)微服務(wù)，對企業(yè)信息化需要也有“積木”化的思想;又通過服務(wù)商的介紹，接觸到了服務(wù)中心的理念，到底是建平臺還是建“煙囪”、服務(wù)復(fù)用等;最后通過實地考察某服裝企業(yè)，了解了傳統(tǒng)信息化向中臺改造的方向和路徑。新思想、新理念以及實地的參觀考察，使得邵佳宇受到啟發(fā)，進而思考中臺是否可以解決衣架信息化建設(shè)的需求。
在推演的過程中，邵佳宇遇到了一個難題——如何處理中臺與現(xiàn)有系統(tǒng)的關(guān)系。“經(jīng)過內(nèi)部討論，我們有兩條思路，一是完全推翻替換所有的系統(tǒng)，好處在于它不需要背負(fù)歷史系統(tǒng)帶來的負(fù)擔(dān)，但經(jīng)評估這種方式存在比較大的風(fēng)險;二是沿用現(xiàn)有系統(tǒng)的數(shù)據(jù)庫主體作為核心數(shù)據(jù)庫，根據(jù)中臺需求進行改造，對現(xiàn)有系統(tǒng)的功能用微服務(wù)的思想進行服務(wù)封裝。好處是整個中臺項目建設(shè)的風(fēng)險比較可控，萬一出現(xiàn)什么問題不會影響到企業(yè)的正常運行，用戶體驗比較好，但問題是整個建設(shè)周期會比較長，數(shù)據(jù)庫架構(gòu)改造無法一步到位。”
如何用中臺實現(xiàn)對業(yè)務(wù)的拆分和抽象，怎么合理地對現(xiàn)有業(yè)務(wù)進行服務(wù)封裝以及復(fù)用?做到數(shù)據(jù)的整體規(guī)劃，從分散到統(tǒng)一，從統(tǒng)一到分散。隨即，衣架結(jié)合自身的情況做了評估，“衣架的分銷系統(tǒng)是由自己團隊開發(fā)的，非常清楚其中的業(yè)務(wù)邏輯以及數(shù)據(jù)庫設(shè)計關(guān)系，同時，對中臺擁有合理的預(yù)期，我們清楚如何對現(xiàn)有系統(tǒng)進行封裝。”
基于中臺的理論基礎(chǔ)及衣架自身的需求，衣架理想中的中臺從技術(shù)層面需要具備五個關(guān)鍵要素：
?容器技術(shù)建立各個業(yè)務(wù)中心，各個業(yè)務(wù)中心相互獨立;
?服務(wù)沉淀在各自業(yè)務(wù)中心內(nèi)，互不干擾;
?業(yè)務(wù)中心之間服務(wù)的相互安全調(diào)用;
?基于流程的服務(wù)組織編排能力;
?前端交互界面敏捷開發(fā)能力。
2017年2月，衣架針對企業(yè)自身的個性化開發(fā)需求，在多個平臺對比中發(fā)現(xiàn)AWS PaaS的容器技術(shù)和ASLP技術(shù)與衣架的需求高度契合，最終選擇了炎黃盈動AWS PaaS平臺。
應(yīng)用容器是AWS PaaS的內(nèi)核，每個應(yīng)用的資源被容器獨立的管理和調(diào)度，基于容器技術(shù)衣架可以在其中建立不同的業(yè)務(wù)中心。在AWS中每個ASLP都擁有一個唯一的訪問地址和自描述元數(shù)據(jù)，便于開發(fā)者識別和使用，同時于ASLP實現(xiàn)衣架的各業(yè)務(wù)中心之間服務(wù)的相互安全調(diào)用。此外，AWS PaaS擁有9種不同的BPM技術(shù)，流程管理及前端開發(fā)是強項，能夠?qū)崿F(xiàn)前端應(yīng)用需求的快速落地，針對不同的權(quán)限構(gòu)建企業(yè)門戶。
AWS PaaS的低代碼構(gòu)建系統(tǒng)能力相對比較成熟，對企業(yè)快速構(gòu)建信息化能力有很好的助力作用，主要表現(xiàn)為以下幾方面價值：
1、提升代碼開發(fā)效率，很多代碼被自動生成，可以降低代碼開發(fā)量，以及系統(tǒng)開發(fā)門檻;
2、幫助企業(yè)構(gòu)建可持續(xù)的自研能力，建立自研標(biāo)準(zhǔn)和方法論。企業(yè)自研系統(tǒng)有一個很大的風(fēng)險就是技術(shù)人員的流動，通過AWS PaaS平臺，企業(yè)可以在平臺之上建立開發(fā)標(biāo)準(zhǔn)，降低開發(fā)難度，提高代碼可讀性?，F(xiàn)在有很多企業(yè)也會自研，但是用的開發(fā)語言比較基礎(chǔ)，也沒有統(tǒng)一，帶來維護成本非常高。低代碼平臺其實可以作為企業(yè)自研平臺的底座去規(guī)劃;
3、快速響應(yīng)企業(yè)個性化業(yè)務(wù)管理需求，低代碼平臺的出現(xiàn)降低了企業(yè)自研的門檻，可以讓CIO在如何快速響應(yīng)企業(yè)個性化需求方面有了更多的手段。
基于這些特點，我們也是成功將企業(yè)的整個產(chǎn)品研發(fā)流程和生產(chǎn)供應(yīng)鏈管理流程搭建在了炎黃的低代碼平臺上面。
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。
