pos機大咖, 008特步CIO唐坤軍分享

新聞資訊 | 2023-05-17 10:33 | 投稿人：pos機之家

網上有很多關于pos機大咖, 008特步CIO唐坤軍分享的知識，也有很多人為大家解答關于pos機大咖的問題，今天pos機之家(www.www690aa.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機大咖

pos機大咖

關注并標星?華東時尚行業CIO聯盟

時尚行業信息化大事都不錯過

第8期“大咖駕到”微享會我們邀請特步CIO唐坤軍為大家分享，分享主題“特步上中臺的那些事”。

大咖介紹

分享嘉賓：特步CIO唐坤軍

大家好我是特步CIO唐坤軍，今天簡單分享下特步全渠道中臺的一點感受，希望對大家有幫助。特步全渠道中臺是2016年9月開始啟動的，我們當時啟動中臺是迫不得已，已經被逼上梁山逼得沒辦法了。

當時我們用的是用友的分銷零售系統，用了整整十年，當時公司總共是7500家店。用友整個系統慢的不得了，很多功能也支持不了，還有用友當時整個團隊都全部已經解散。所以我們是在這樣沒辦法的情況下，和國內幾家廠商進行了溝通交流，發現都不合適我們。因為體育用品跟純粹的服裝不一樣，體育用品有鞋有服裝，還有我們整個數據量超級大非常大，所以我們那時候考慮了很久還是把它放棄了，準備上SAP的Retail。也曾經想過還不如SAP的，還不如自己去開發，這些都已經想過了，都已經開始在準備了，但是后來波司登這邊在跟阿里在合作，波司登在用阿里的中間件，然后在做分銷零售。我們就派人去看，看著覺得挺有意思的，阿里數據庫也有，中間件也有，我們可不可以跟他們合作一下。

后來我們這邊就派了18個人，技術人員、業務人員，外部還請了幾個顧問跟阿里交流，交流完了之后我們覺得是可行的。為什么？當時我基于兩個方面的判斷，我覺得是可以完全是可以的。第一，阿里一年上萬億的生意額都能支撐，特步目前肯定是可以支持的；第二，當時阿里的雙11，那么大的數據量它都能撐得住，特步怎么會不行。基于兩點，我覺得我們是可以做的，這個技術上面我覺得是沒問題的。還有覺得古謙、平安他們這些人都是很專業的，也是很真誠的，有他們來支撐，而且還有波司登走在前面，我覺得這對我們來說風險會小很多。

所以說基于這些判斷，我們開始給公司寫報告，我們自己開發。說實話，當時真的也是迫于無奈，買吧，沒有合適的。我們隔壁的安踏也很痛苦，他們也是用了兩三套系統，用了為濤、SP的Retail，還有另外一套系統。李寧當時也是兩套，宏志和道訊，大家都搞得很痛苦。老板也沒辦法，老板覺得我們也可以去嘗試一下，只是說在這個預算內不突破，同意我們去搞。當時我們這個項目在啟動的時候，開發人員還不夠，我們才12個開發人員，這個開發量還是很大的，所以說我們把整個開發外包給大連華信。整個系統架構的設計是阿里的古謙、平安和白哲來負責支撐的，還有我們內部的幾個業務專家，這樣的話，我們組成一個團隊，我們能做原型設計。在這塊我們花了差不多一半的時間做這個事情，這個事情我們當時是以為做的很好，其實事后還是有很多問題，待會我會分享給大家。

我們花了十個月時間把整個分銷系統、零售系統、POS系統，還有O2O中臺全部開發完，在2017年5月30號在我們福建分公司正式上線。其實我們上一季的時候無數的問題就跑出來了，bug不用說了，肯定是存在的。還有發現我們很多的業務需求我們自己認為搞得很細致，其實我們在做中臺的服務中心的時候，這塊是個最大的教訓，就是我們服務中心根本還沒有梳理清楚，導致我們后面極大的返工量。服務中心一定要把我們所有業務流程切片切到最細，就是最簡單的一個標準的業務流程，我們要把它梳理出來。如果說我們在開發的時候，我們有能力的話，我們做成一個微服務，最后再進行分裝，這是最好的。

我們當時在做原型設計的時候，把很多業務流程設計的很大，做的相對比較復雜。首先服務中心，共享服務中心它一定是最緊急的業務流程，就跟SP里面說的業務的事就是最簡單的，標準化的。我們有能力我們能做的出來，但是沒有能力的話，我們就會把很多的業務連皮帶肉會搞在一起，搞得很復雜。這變成我們是穿新鞋走老路，用的是中臺，用的是最新的分布式部署，用的是微服務架構，但是我們做的時候還是過去傳統大而全的東西。這個是做中臺的時候最忌諱的、最大的弊端，最大的失誤，這會導致后面一系列的，當我們有新的需求的時候，有很多問題的時候，我們就涉及到要修改底層架構，中臺的服務中心跟我們過去傳統一樣的時候，一旦我們要進行修改，就要動無數的地方。這是我們在做中臺時候給大家一個借鑒，中臺的服務中心一定是最簡單的一個業務流程，就是把N個最簡單的業務流程，我們都給它做成微服務，做成可配置化的、可分裝的，這是最好的。

所以說我們當時在設計業務的時候，設計服務中心的時候，一定要請我們業務專家。IT其實做不到，根本做不到，只有業務工作者更懂業務，IT是好像懂，其實不是很透徹的懂，結果導致我們在設計服務中心的時候就會出現很多的問題，我想大部分做中臺這些單位，這些設計部門在做原型設計的時候，都會出現這個問題的。

打個比方，我們做庫存管理的時候，所有跟庫存相關的業務，到底有多少個業務流程是跟庫存相關的，我們都把數據列出來。退貨誰跟庫存相關的，盤點哪些是跟庫存相關的，報廢跟庫存相關的，我們把這些業務流程全部梳理出來，并且把它變成最緊急的、標準化的業務流程，這樣我們開發出來變成一個微服務，可以做成可配置化東西，變成一個共享服務中心，這就是我們所謂的庫存管理中心，或者叫庫存共享中心這樣的服務中心。我們把所有影響庫存的因素都把它統統列出來，ABCDEFG的全部調出來，把每個業務流程最簡單化，最簡潔化。然后把跟這些業務流程相關的、個性化的東西，拆到應用中心去，變成應用端。這樣應用端是個性化的，應用端可以是隨心所欲的，但是我們的服務中心一定是標準化的，可以被各個應用端、可以被各種業務可調用的。這可能是我們在做中臺時候最大的注意點，否則的話我們中臺做起來之后，變成是用新技術走老路，確實還是傳統的那種玩意兒，那就完蛋了，到時候我們再進行系統調整的時候會有無數的返工。

另外其實中臺還是分兩層意義來講，一個是業務中臺，還有一個是技術中臺，首先搞清楚我們要做中臺，我們的業務包含哪些，不包含哪些東西，我們的業務中臺一定盡可能是成熟的、標準化的那些業務，比方說我們很多，尤其是在供應鏈方面的計劃這些東西，是很復雜的，一直到現在都沒有人能把它做成很完整的一個很好的案例的東西，我們就不要去想這些東西了，這東西的話我們可以按照傳統的東西去做，不要把這些個性化太強的成為開發的阻礙。尤其是我們在做微服務架構的時候，我建議所有的我們這個應用單位，我們這些IT人員，我們要多去研究一下SAP的這些微服務，SAP是全球最經典的微服務，研究出來之后我們照抄就好了，我們不要自己去想太多的東西。

這是我給大家提了一個醒，還有一個建議，就是關于我們做中臺服務中心的時候，我們一些教訓跟一些建議。

我們用阿里這個東西的好處是什么呢，也跟大家分享一下，好處是這種分布式部署架構還有服務中心，它最大的好處就是把我們一些業務的應用，把它標準化之后就把它做成服務中心，然后個性化東西變成應用端。所以個性化東西，你再更新的話，在應用端只占了20%，最多30%，你在面對著百分之二十三十的應用端的時候，也是很輕松的，也是非常簡單的。那就是絕大部分，大概80%都可以共享變成服務中心，是不動的，是穩態的。

比如說我們特步有45家分公司，我就可以把45家分公司的應用端都變成個性化的，一家分公司一個獨立的應用。比如說我應用端有十個的話，那我就十個是個性化都可以，我們可以完全開放給分公司的人員，他們自己去開發，自己去折騰，因為比較簡單，都比較小，就服務中心在一塊由總部集中來控制來管控。這樣我把最簡單的那些東西都給放出去，復雜的這東西有總部直接來管理，就是中臺服務中心這一塊。這樣相對的也避免了過去45家分公司只要一提需求的時候，一動起來就要動45家分公司，連皮帶肉帶筋去撬動。現在每家分公司有個性化需求，只到應用端就好了，那把問題就變得簡單了，把范圍也收縮了。

第二個，如果說分公司沒有能力來做應用的開發也沒關系，分公司可以外包給當地的開發商來進行開發，實在沒有能力總部來承接也行，也很方便。個性化的應用只需要分公司在應用端變更一下，把系統重新打開變更一下就OK了，不影響任何其他分公司的業務操作業務連續性。這種部署是我們一家分公司一個獨立的數據庫，是不影響別人的，這個相當于防火墻，有隔離墻，比較方便。

另外是我們在期初的時候，差不多是每周迭代一次，一個月迭代四次。當時迭代得比較頻繁，因為問題比較多。我們現在全國45家分公司，大概是6500家店，現在我們全部都有上上去了，現在每個月差不多迭代兩次，集中收集需求處理問題。每半個月迭代一次，這樣可以把需求控制的很好，不至于很多需求提過來之后，我們盲目地給它去迭代。現在我們的系統除了國內這4500家門店，四十幾家分公司，現在我們印度的分公司，我們印度的店，還有越南的分公司，越南的店，還有阿聯酋的，大概是在十月份泰國、印度跟越南的分公司我們都已經上線了，所以它在應用方面還是比較方便的。

到目前為止我們總共做了十個服務中心，我們的商品中心、訂單中心、庫存管理中心、營銷中心，營銷中心最主要就是我們整個促銷活動，零售跟分銷這兩大模塊、大中心，還有會員中心、渠道管理中心、工程管理中心、結算中心、還有物流中心，我們現在很多分公司都有獨立的物流倉庫，還有OTO中心，主要是把現場跟線下的商品、訂單，還有結算進行整合。

現在以線下門店為單位，如果說你愿意跟線上玩，就是現在由我們商品中心發起哪些產品庫存比較大，在我們所有分公司發通知，哪些門店的愿意跟線上玩就打勾，那你的商品就自動共享給我們整個線上、共享給我們商品中心。共享之后，然后我們把整個我們結算規則設定清楚，一般我們主要是代銷、利潤分成還有買斷，買斷就是貨權是屬于我，只是暫存在門店，這三種方式。把規則講清楚之后，你愿意參與進來，就打勾，它就自動就把整個貨品共享給我們整個線上。線上接到訂單之后，通過O2O服務中心，它自動匹配到離這個消費者最近的門店。我們的規則其實很簡單，就是先就全后就近，一個門店的貨，第一，需要滿足這個消費者的訂單，盡量不要拆分成兩個訂單；第二，先就全后就近，匹配這個消費者，匹配完了之后，系統就自動把訂單同步給阿里菜鳥，阿里菜鳥再把離門店最近的物流公司匹配給這家門店，把訂單發送給物流公司，物流公司就到這家門店去取貨發貨。這個效率還是蠻高的，另外同城物流也便宜一半，還是比較方便的。消費者體驗來說，時間短。去年我們雙十一，一共22萬個訂單，到第二天下午五點就全部發完了，效率還是蠻高的。

我再來說一下中臺做了這么多好處肯定是有的，我想說幾個大家要注意的事項，第一個是大家都在談中臺，到底企業要不要做中臺，我覺得有兩點建議：第一點是做企業中臺，你一定要搞清楚到底是做哪一塊業務，首先要把業務中臺想清楚，哪一個業務要中臺化，你才能開始去做，比方說我們供應鏈這塊其實很復雜的，你都沒想清楚，盲目去做很容易在設計原型的時候把很多業務搞的顛倒黑白。這樣我們做出來東西是沒用的，最后這個中臺的生命力一定是沒有的，一定是在打折的，甚至是用不下去的。

所以說我們要想清楚業務盡可能是成熟的、成型的，有相當的規范化、標準化的業務。分銷零售業務其實都是很標準化的東西，我們每家分公司都有陳列標準、商品標準、培訓標準、門店裝修標準，這種標準的它都有。整個分銷零售業務是比較成熟的，它是不斷地做精益化管理，不斷精益求精的，我覺得這個最能夠出成效出成果的。另外供應鏈為什么說我覺得很難的，我們吳博總結了一句話，我覺得很經典，就是分銷零售這塊是有很多成熟的標準，如何把它做到更加精益求精。供應鏈是無數不可預知的因素，要實現三個已知的值，就是交期、質量標準、成本。這塊還是比較難搞的，標準化不是很高，成熟的東西不是很多。需要我們去摸索，去探索哪一些比較成熟的已經標準化東西，我們可以把它做成服務中心，用中臺的方式來做。

我們做中臺的時候一定要有準備，我們在做中臺的時候，我們的整個開發跟傳統開發完全不一樣。傳統開發是堆代碼，做中臺的時候，我們一定要把業務場景化，就是開發人員頭腦中一定要有業務場景，代碼盡可能不要重復，不要去堆疊，這樣寫出來的代碼是很差的，一定會返工的，做中臺服務中心的時候，整個微服務整個代碼一定是最簡潔的，不要有冗余的代碼。你在寫某一個微服務的時候，你腦海中的場景肯定是PDCA能夠循環的，整個業務從頭到結束一定要有業務場景，這樣寫出的代碼才是高質量的。第三個我覺得在設計的時候，將整個數據庫的設計用中臺做，用互聯網架構做。我們最理想的目標是為了實現快，就是我們數據的讀要快寫要快。常用的數據話，我們寫的時候跟讀的時候怎樣去分離，怎樣去做整合，做合并，這都是我們要充分考慮的。你在設計數據庫的時候，你不考慮清楚的話，后面很多的優化是會搞的很復雜的。所以我們在設計這些讀寫分離的時候，我們已經開始涉及到效率。

我們人人都想做中臺，但企業沒做過中臺的時候，千萬不要自己去干，在這里面還有很多坑的。阿里的中間件最大的優勢是大并發，這是他們的強項，還有他們底層硬件架構這塊用Upstart做的開源，企業掌握也是挺難的，這塊也是比較復雜的。阿里這個架構現在我們我來總結，它美中不足的是，未來我們在整合數據中心的時候，它的集成整合能力還是比較差的，這個不是它的強項。未來會碰到的一個難題，阿里這塊是完全是要靠高質量的開發人員，來進行快速開發，這塊兒能力是比較差的。這個是各有利弊的，我覺得如果我們還沒做的話，我們要跟已經做過的成熟的這些廠商去合作，這樣少走彎路，否則的話我們搞出來的東西會有一堆的問題，對我們團隊也好，對于企業也好，都是不利的。我們要搞，我們肯定是盡可能搞成功，第一是讓團隊要有成長；第二，對公司有價值；第三是我們要有成就感，否則的話我們都會成為劣史，這個千萬要小心的，就是不要盲目去干，你要跟成功的、干過的企業去干。

最后我想建議，很多企業肯定一下子拿不出那么多錢來做中臺，做中臺的成本是很高的，需要的人都是很貴的。我覺得中臺前面講過，無非是兩大類，一個是數據中臺，一個是業務中臺。我覺得要做的時候優先是考慮數據中臺，把我們過去的業務，如何把它整合到我們的數據中臺上面來，讓業務有連續性，再逐步的把過去的那些應用搬到我們應用中臺上面，這樣能夠起到承前啟后、平穩平滑過渡的作用，這個是最穩妥的。

做數據中臺我實事求是的講，我覺得伯俊做的非常不錯，那可能是因為他們過去有太多的客戶，為了讓客戶不至于用休克療法把過去的系統全部把它干掉，重新再來。就像特步我們就要休克療法，推倒重來。但是可以慢慢試，平滑過渡地把過去的業務，不中斷、連續性地把很多的數據先搬到終端上面整合過來，再逐步地把那些功能進行替換，最后甚至把所有的功能都調動過來，我覺得這是一個比較穩妥的方案。另外來說，我們好多企業上SP的，如果有HANA的，你可以用HANA作為數據中臺進行整合，這是基于你已經有的情況下，沒有的話，我覺得最高性價比還是做數據中臺，這樣是比較合適的。特步之所以能夠把分銷零售，把很多附屬的系統一次性給廢掉，特步應用了十年的HANA這個內存數據，我們前端BI是用BO展現的，我們有條件去整合，去把新的全渠道零售中臺的數據，跟我們很多的系統進行整合。當時我們是有這個條件的，所以說其他企業在做的時候的要充分考慮到這一點。

最后我想再強調一下，我們做數據中臺，一定要強調什么，你把業務中臺想清楚沒有，到底哪些要業務中臺化，你自己把這些想清楚之后，我們再通過技術中臺把它實現。我們如果要做的更穩妥，一定是數據中臺怎么去構建。還有就是你公司如果連架構師都沒有的話，不要搞中臺了，這樣玩的話會把自己玩死，將所有的命運都是掌握在別人手上，這也是不可取的。所以說要做中臺，必須要有自己的架構師，要有一幫人，要有幾個相當資深的、核心的開發人員，這樣的話我們做迭代做優化的時候，你才有辦法去掌控，當你沒辦法去掌控服務中心的時候，整個中臺會倒掉的。

我今天就給大家分享這么多，希望我的建議能夠對你們有幫助，也許大家可能不認同，沒關系我們可以單獨交流，也可以來特步這邊交流都可以的，謝謝大家。

提問環節問題一：唐總，請問大概用了多少預算？唐坤軍：用了1000萬，包含軟件硬件。中臺不是拼誰錢多，如果你的企業規模不大，企業業務模式穩定，就沒必要搞這個，如果企業模式復雜，體量在50億以上，業務個性化多，組織變化頻繁，我們就可以考慮把那塊成熟的穩定的業務中臺化是比較好的。

問題二：唐總，你們的微服務治理采用什么樣的解決方案？唐坤軍：微服務治理就是用的阿里中間件

注：以上內容摘自“大咖駕到”微享會，轉載僅限學習分享；

如產生版權問題，請聯系我們處理；

文章不代表"華東時尚行業CIO聯盟“立場！

精彩回顧：

首期大咖駕到 | 高峻峻分享《零售新科學》-數據智能驅動中國零售創新

大咖駕到002 | 陳霈霖分享“喜茶Go小程序背后的數字化引擎”

大咖駕到003 | 毛葦分享“訂閱經濟-讓你的業務幾何倍數增長的秘密”

大咖駕到004 | 許紹金分享“企業中如何應對勒索病毒”

大咖駕到005 | 諸老大食品CIO侯有站分享“數字化轉型過程中的坎 ”