- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2022-04-01來源:熊妹妹瀏覽數:581次
01
益豐的數字化轉型實踐
蘇衡(廣州市CIO協會秘書長):益豐大藥房對數字化轉型做了哪些思考和實踐?是什么契機下促使益豐做出了向中臺化轉變?孫浩(益豐大藥房CIO):益豐是從2017年底開始想做中臺,跟很多供應商做了交流,也做了很多企業實際案例的考察和溝通。在過程中,我們形成對整個中臺,以及整個數字化的轉型和對整個數字化技術團隊組織的認知和實踐。只有整個企業的數字化水平、企業的人才結構以及企業的業務需求達到一定的階段以后,才需要去考慮往中臺化進行發展,這是我的第一個觀點。對于傳統的信息化來講,并不是每個企業都要做中臺。在企業規模不大,數據量不大,業務變化不太快,整個數字化人員并不多的時候,中臺其實并不適合這一類的企業。因為中臺是需要有很多的服務中心,它需要以自研的體系為主,而不是以商業套件的供應商體系為主。如果為了中臺而中臺,就象是大炮打蚊子,其實會帶來一系列后期維護的難度,還有很多資源的無謂消耗。對于傳統的信息中心來講,普通制造型企業或者是規模不夠大的零售、快消,他們信息化體系很簡單,自研需求不多,IT人員也不多,有些項目也可以用套件商品或者定制開發完成。我覺得這種團隊并不適合往中臺化這方面發展,因為公司的體量、業務需求以及人員儲備,都不適合他們去為了做中臺而做中臺。益豐也是從一個規模相對不大的公司發展而來,最初只有三五個IT人員,最早用一些ERP的財務體系、門店管理的系統就可以支撐。但是外購的門店管理系統是單體結構的,只支持單店,多店的話就很難去進行管理。因為連鎖化以后,對多店模式開始產生了一些要求。這個情況下我們就有四、五個開發人員做了一系列開發,基于以前單體化結構上讓它能夠連鎖化,當時它的數據傳輸都不是實時傳輸的。接下來我們發現,零售要非常貼合它的業務,對系統的要求會很高。我們開始做整個零售營運這一塊的內容,以前的軟件已經沒辦法支持了。我們在考慮,是繼續找一套能夠滿足需求的商業軟件,還是我們開始走自研的路?我們也看了很多的產品,后面發現這些產品都不可能完全滿足我們,而且它的貼合度也不會特別高。如果選商業套件,就需要大量的二開,并且我們也做了一些案例企業的調研,發現他們在選用商業套件以后,它的迭代速度是很慢的,它可能一年才迭代幾次,而且供應商這邊的成本也會很高,它的響應效率是很低的。在2012年,我們研究了一些產品后,發現益豐整個的門店營銷跟核心經營相關的系統,不應該依賴于外部,應該走自研的這套體系。我們當時才十一二個人,我們還是決定要把這套體系自研出來,加上供應商做了一個項目外包,花了8個月的時間把這套系統做出來。隨之以后那套系統在整個公司的經營過程中起到了非常大的作用,因為我們是完全量身定制的,可以非??焖俚仨憫獦I務需求,每周進行迭代。在這個基礎上面,整個研發團隊就越來越壯大。到現在已經不是基于那一套系統了,我們把整個公司已經演變成了一個與業務緊密結合的數字化研發體系。目前來講,益豐自主研發的人員已經有一百多人,包括產品人員有二十多個,開發測試有一百多個人,還有運維、套件類、外包的人員,加起外包人員已經超過兩百個人了。所以規模及業務復雜度到了一定程度,就必須要考慮中臺化。因為中臺化一定是把現有業務的復用性抽象出來,而不是單個單個的商業套件。商業套件為主的這種已經很難中臺化了。如果你的核心系統、核心經營相關的系統都是商業套件,即使在中間再做一層,難度也是相當巨大,相當于多了一套系統。而益豐中臺化了以后,會通過中臺的能力,來接管以前那些老系統的業務。所以我覺得必須要企業的業務、團隊的能力、公司的業務需求達到一定的層面,大家彼此產生共振才有這種中臺化的需求。02
企業內要同頻共振
蘇衡:共振這個詞非常好。在過程中是有什么契機讓產生企業內部產生共振的呢?孫浩:其實在決定自研開始的時期,內部有很多不同的意見,擔心自研的風險。后面我用了很簡單的幾個原因去說服老板:1、目前套件迭代的速度太慢,企業不能忍受一個月迭代一次;2、套件是按終端收費,每開一家連鎖店都要兩三千的高額成本;3、套件包括開發和后續運維二開,自研的起始成本是比較高的,但是后續的開發成本比供應商低。后面我們就把整個系統全搞定,包括會員、門店收銀到后臺的管理。現在回想起來都覺得特別值。當時才500多家店,我做這套體系的時候,跟老板拍胸脯說,我保證你可以支持3000家店;現在這套系統已經支持了5000家店了。雖然我們在這上面有很多的不停的迭代,不停的性能優化,但是用的還是以前的基礎,而且現在新架構在慢慢的小步迭代的過程當中,老架構還要支持到8000家店。從500家到8000家,這是一個很夸張的數量級的變化,我們現在一年的數據量比前面四五年的數據量都要多。還有財務方面,財務我們會分為很多方面,ERP有財務體系,資金管理系統都是成熟的套件,我們就不會做自研。但是門店有很多的支付方式,我們有一百多種支付方式,有醫保、現金、第三方支付等等收入要匯到總部。我們發現銷售和收入的對賬體系是沒有套件能夠解決的,像我們現在對接銀行應該有六十幾家,有些店可能在鄉鎮,基本就是農商行。而農商行的信息化系統可能還不完善,對接的成本很高。我們現在的做法就全部用RPA,匹配數據到我們的系統里面后再進行對賬。銀行相對結構化還更好一點,但是其實還有另外一塊會更麻煩的,是醫保。每個地方的醫保政策都不太一樣,系統也不太一樣,有的是有接口的,有的是沒有接口的,有的是不可能給你做接口,有些可能還限制了,比如醫保系統只能在某一臺機器上面,并且綁定醫保的專線。以前在這種情況下,需要通過門店拍照上傳,然后我們通過人眼去確認數值,并跟后臺的結賬數據進行匹配,這消耗我們大量的人力,以前是二十五家店,對應的一個財務人員,而且只能一個月對賬兩次甚至一次,這個勞動效率是非常低的。我們現在已經在做RPA了,醫保的數據已經全部匹配到我們的系統做自動對賬。自動對賬以后,差異額大的部分做人工重點審查。這樣對公司財務人員的人力節約,是非??捎^的,財務可以去完成更多的工作。這些都是數字化所帶來的一些優勢。整個疫情是對于零售行業的影響是比較大的,但是藥店是作為零售行業里面,在疫情期間既有正影響,又有負影響的一個行業。這種情況下技術需要快速響應業務的需求,才能在這期間轉“?!睘椤皺C”。 蘇衡:有沒有哪些典型事件是讓高層也產生共振的決心的?孫浩:首先第一個,去年遇到大促的時候,技術在支持業務的時候,應該是流水上傳的時候,業務量太大了,導致可能延時了一兩個小時,然后才能同步。當看不到及時的銷售數據時,老板就會容易失去目標感,就會思考現有系統怎么樣能夠快速的解決類似數據壓力的問題。第二個,公司上市以后,老舊的組織體系已經變成制約著我們快速發展,老板也找很多的外部公司專門做這方面進行溝通交流。了解到美團它是一個中臺部門,它這個中臺部門里面就包含了企劃的、營運的、人力的、信息的,能夠及時的去響應前臺的需求,當它需要的時候再來去調集團的炮火。老板也意識到了我們的組織要中臺化,我們正好在前面在推我們的技術中臺化,他也明確知道我們還在快速發展,要支持未來更長遠的業務的發展,因為未來我們可能幾萬家店,所以你技術體系一定要迭代。組織中臺化就很觸動老板,我們數字化中心就是第一個往這方面要走的部門,接下去很多的部門都會往這方面走。03
做中臺,組織需要中臺化
蘇衡:有哪些構成我們這個中臺建設的成功要素?孫浩:中臺成功的要素,是我們做完了一些案例調研以后總結出來的。首先你要做好一個中臺的話,你的高層領導一定要認識到這個問題,它不是一個項目,更不是一個IT部門主導的項目,需要企業進行長期的資源整合,隨著業務變化,部門的組織都會產生變化,所以像我們在做中臺的時候,我們當時組織了所有集團高管參加了很多場中臺的培訓,跟他們講清楚中臺會對他們產生什么樣的影響。組織也是要變革的,就像我們現在的組織體系,因為要做中臺,組織就需要中臺化。我們合并集團內的線上線下分離的研發團隊成立數字化中心,中心內有一塊做共享服務的團隊,有共享的產品經理和研發。當我們發現這個能力能夠沉淀和復用,是用這個團隊來承接的,而不是在之前的業務研發團隊,所以他們會有一些可以復用的能力。組織沒有到位,項目式的推進,中臺很容易就走歪了,我們也總結了像一把手的工程、長期運作、組織的變革、容錯率等等經驗,其中容錯率是因為變革過程中一定會有陣痛的,所以企業要容許這種創新過程當中的錯誤,只要不是責任心導致的錯誤就可以了。蘇衡:因為中臺最后是業務價值的體現,決定我們技術的價值,這個風險上你覺得是怎么樣?或怎么控制它?孫浩:風險其實最核心的第一個,一定是領導要深度的去參與,業務部門才會配合協作。我們會設計一些東西,跟業務去探討,這個過程中業務要跟技術部門真的是同頻共振,大家一起形成一個最終的設計思路,然后把原型做出來,大家一起確認,而不是一味等著技術部門自己搞,然后全盤否定,甚至我們在全程中會不斷地約業務的老大一起復查,如果沒有一起確認的溝通結論,我們是不會進入研發的。產品設計評審采用會議方式,包括業務副總裁、業務部門負責人等,每次發會議紀要,記錄每人意見。這樣減少不認賬,也保證了核心管理者對產品的邏輯思考和確認。蘇衡:只有占有時間,才能占有思想。04
中臺技術團隊的人才培養
蘇衡:在數字化這種轉型的情況下,是否對團隊的要求就開始不一樣了?孫浩:是的,對于整個數字化轉型,我認為要從項目管理型轉變成為產品研發型的團隊。它的側重點是完全不一樣,項目管理型的對業務和技術的把控能力都是不夠的,會變成是借助不同的乙方利用各自的技術體系,打造成一個個煙囪,而且可能會被供應商綁架。產品研發型的團隊,自己會掌控整個技術底層,并讓技術底層是通用的,不要變成一個個不同的技術棧,導致資源無序的消耗。產品研發型的團隊會比較掌控自己的產品跟業務緊密結合,從而創造價值,并且能夠持續不斷地迭代。也許1.0的版本,能夠簡單的滿足業務的需求,并不特別好用。當能做到持續快速迭代的時候,每兩周迭代一次,也許產品迭代一個五到十次以后,你會發現這個產品對業務來講已經離不開它了,對于項目管理型來說,這段時間也許還沒有找到合適的供應商,合同都還沒簽,立項都還沒到,所以這是最大的問題。像我們現在自己掌握了技術,自己掌握了產品,自己有研發團隊的時候,當業務有需求,我們很快可以滿足他們。包括像疫情期間,門店做口罩預約,用了三天我們就把整個口罩預約的系統做出來了,導致很多政府部門就找我們支持。后面變成了益豐的系統是在給整個城市來做預約的服務的,包括口罩領取核銷系統也是一樣的。我認為我們這樣數字化的團隊,已經必須要互聯網化了,因為互聯網公司的迭代非常迅速。蘇衡:那項目增多了,延伸而來的就是交付周期的問題,特別是遇到一些大型項目的時候,益豐是怎么解決這塊的?孫浩:對于交付周期來說,有兩種方式,一種方式是前期考慮充分,產品設計完了以后做一個充分的評審,再進入研發,這樣研發速度會很快,產品消耗的時間會比較長,但是做出來的產品會比較完善。第二種方式是業務需求比較緊張,那就不能想太多,先在做一個MVP的版本。先跑起來,中間會發現有很多不完善或前期遺漏的細節;這個時候就開始做產品的迭代,迭代的過程會發現產品在不斷優化。利用你以前的舊版本當時積累的這種經驗和能力,很快地把新版本做出來,再去把舊版本給替換掉。這個過程當中雖然會浪費掉一部分研發成本,就是舊版本的一些研發成本,但是首先很好的滿足了業務的一個及時性的訴求。并且在這個過程中,其實我們用一個比較小的成本在試錯,最終做了一個更好的產品,更好地滿足整個業務的需求。我覺得這個是跟以前是不一樣的,以前傳統的我們也是項目制,供應商只要交付了需求范圍之內的產品,驗收通過了,供應商撤場了。最初你可能這樣想的,但是到了交付完的時候,也許這個產品就必須得束之高閣,因為它已經跟當前情況完全不太一樣了,它已經滿足不了你現狀需求了?,F在我們做這些東西,就要跟業務綁在一起來干。 蘇衡:益豐的數字化技術團隊是怎么培養的?孫浩:數字化轉型團隊更重視的是業務架構的設計、需求的分析、產品的設計、UI、UX、對用戶的美觀體驗,已經從以前滿足功能,到變成對產品外觀,交互體驗的需求上。一開始我們是沒有產品經理的概念,我們只有一個需求分析的概念。實際上就是我們自己對業務比較了解,IT人員里面就去負責需求分析的;我們其實連架構人員也沒有,開發人員也是Delphi,就會找外包一起探討,溝通我們的思路,確定了需求,然后開發落地外包。在過程當中,就可以培養內部的人。我們從一個JAVA都沒有,到項目做完了以后可能就有十個JAVA了;再把他們留一段時間,然后慢慢的我的團隊有二十幾個JAVA了;供應商就可以不用了,就自己可以持續不斷的迭代。這個時候會發現,不同企業的選擇不太一樣的時候,后續的發展是完全不一樣的。05
中臺技術團隊的組織管理
蘇衡:現在益豐是怎么做數字化技術團隊的管理呢?孫浩:從管理上來講,我們做了幾次迭代。剛開始集團是管理信息化的部門,后面因為互聯網的發展,又成立了線上的團隊。但是兩個團隊的互聯互通、協同,效率是存在一定的問題,會造成更多的煙囪,所以我們按照團隊的能力把它合并,做成了不同的團隊。運作了半年以后,我們發現這個也有問題,會發現業務的一個需求會經常跨產品線,業務就不知道找誰了,然后會有很多的灰色地帶。我們發現必須要以業務為導向來做整個團隊的這種組織結構的設置,所以現在整個的組織體系都是按照BU去建設,數字化中心的實體組織還是跟著我們的能力去建設的,實體組織不變。舉例子,線上新零售的虛擬組織,會有產品團隊和研發團隊;營運和商品是我們的核心業務,面向于營運的、營商的產品團隊和技術團隊,也是分開的;會有面向職能的,比如像人力、行政、財務,這些后臺部門的產品團隊和研發團隊。資源是在自己的BU里面是來講是相對獨立的,獨享的。這樣的話,業務跟我們的技術相當于是緊密結合的關系。我們的產品經理都已經放到了業務部門一起辦公,業務的老大可以隨時跟產品經理進行交流,然后產品經理也受業務老大的指揮。我們產品經理的能力會比較強,整個素質會比一些管理人員的素質還要高;例如讓產品經理去店里面去考察調研,當他在看到問題的時候,會給出很多的解決方案;業務的老大就能夠通過這些解決方案的建議,很快知道怎么樣去解決這個問題。其實我們可能都已經想好了,我只要讓他做選擇題就可以了,你不要讓他去做這種思考題。蘇衡:這個可能已經不是傳統的矩陣式的管理了,特別是產品經理,會面臨著虛擬組織、業務部門、IT崗位職能的角度等等三個維度的評價。孫浩:是的。我們現在的考核體系變成了一個矩陣式考核體系。我們以前就是傳統的KPI。現在有OKR。對于IT團隊這種非標的工作,考核其實有一定的難度。傳統的 KPI或者新的OKR,都會涉及到考核人是以上級對下級考核評價為主,在這個評價過程當中,就沒有標準可以支持評定。所以我們現在矩陣制考核就是上級對下級有一個考核權重,主要以內部協同、整個數字化中心對個人技術質量的考核、對應的業務線負責人的考核。這樣業務人員的目標和IT的目標就很容易對齊,響應也會更加及時。蘇衡:那是否業務部門掌握著一票否決權?孫浩:也不完全,我們有權重。我們不同的業務導向是不太一樣,像我們新零售不停在創新,它跟技術是強關聯的,這些創新都是依賴于跟我們的技術要緊密結合的,都要靠技術落地的;這個時候,可能業務這項的指標會給六成的考核權重。而像營商這種線,就沒有必要要這么多的考核權重;因為技術部門還是以服務為主,跟他們的結合度會稍微弱一點點,不會那么像新零售那邊的緊密度,所以這邊就是倒過來,數字化中心占六成,整個業務占四成。你所對應業務線的財務指標,比如營運做得好,銷售完成率很高,毛利和完成率很高,但營運的指標就會跟著高。新零售做得很好,新零售財務指標好,我們也會跟著好,大家都是共贏的。所以IT部門也背了一定的業務指標,通過績效差也調動了部門的積極性。我們當時是定了一個指標,叫做業務部門對IT的綜合評價,通過用戶思維、業務思維、團隊協作解決問題和及時響應等等相關的內容,然后進行打分,最終得到標準分值,在一定的范圍內進行強制排名。蘇衡:那其實對于團隊的領導者來講還是很辛苦的,你有一大半的時間要放在人的角度去考慮問題了,就不再是技術架構這些或者去處理技術上這些問題了。孫浩:是的,但其實還好了,這些一個季度做一次,占用的時間不會特別長,有系統來協助管理。但其實跟績效考核相比,我認為一個數字化中心的管理者,花一半的時間在人的身上,這是一個好事。因為有好的人,你才能創造好的成果和好的業績,所有做的不好的地方,大部分是因為你人沒有用對,所以像我現在一半的時間,我要調整人員,要跟人談話,要激活人。另外一半的時間就是我要過產品的設計,去解決日常過程的協同,團隊優秀了,他們已經可以把問題消滅在萌芽狀態。06
小步迭代建中臺
蘇衡:益豐大藥房在中臺未來建設的思路是怎樣的?孫浩:其實我們之前想說找外部供應商,我們把整個中臺切分一二三期,一起去共建,雙方各出一半人,大家共同來設計研發,最終落地。以前想的是在現有體系上面跑,從0-1搭一套整個中臺,包括前端的業務,再把老的廢掉,全部切到新的體系里面來。這個動作太大了,風險也很高,時間也很長,也沒有這么多空余資源投入。我們現在邏輯就改變了,我們叫做小步迭代,去實現我們整個的中臺。今年可能就做幾個中心,我把這幾個東西抽象出來,再去把我前端和中心接管過來;這樣一個個中心去做。如果我的資源不夠,我就找外部供應商去協同一些資源,核心的資源就可以了。那就不會導致說需要很長時間才能見到一個效果。也許我做了一個中心,像我剛才講的促銷中心,我們現在已經在研發過程當中了,7月份就會做完,然后把整個前端切掉,那從業務上他就有感了,他會發現說我們以前整個的促銷是不完善的,有很多的問題在新的版本里面都解決掉了。那這個中心其實我已經能夠對外提供能力了,就會把以前需要用到促銷的所有能力替換掉。07
中臺失敗三原因
蘇衡:每個企業都必須選擇一個符合自己的自身定位和自身環境的一個路徑,盡可能降低失敗的概率。孫浩:我也看過那些文章,那些人為什么他會失???我認為幾個點。第一個他的項目化的運作方式。然后第二個他自身的能力儲備沒有達到,想依賴于供應商幫你去建設一個中臺,我認為這個東西真的是叫做還沒有理解中臺的真正的含義。第三塊就是很多的中臺供應商,他還是只是在給你提供產品,然后再按照你的思路進行二開。所以從我的角度上來講,我們有一個觀點,就是說我一定不會用供應商之間的已有的東西,我一定是基于現有的業務和現有公司的情況,以及我未來的想法,然后重新從產品層面做抽象,然后在抽象的過程當中,我可以借鑒供應商的模塊思路,最終從0-1做代碼的研發。就是從產品到整個的設計到落地,都是應該為我量身定制的,中臺真的一定是每個企業不太一樣的。我認為中臺是一個企業發展到一定階段,你的人員、外部環境、內部環境都準備好的時候,水到渠成的一個東西,它并不是一個項目。也不要想著說因為做了中臺,整個公司的數字化水平有一個天翻地覆的變化。當你沒有準備好的時候,其實這個東西對你來講一點用都沒有,只會變成你的負擔。采訪結語
蘇衡:中臺是一個自我革命,是全體組織成員從內心到外在、都向數字化生存轉變的自我革命,不是別人給我的革命,那樣的中臺只能流于項目。
受訪嘉賓:孫浩
現任益豐大藥房CIO,20年的IT行業工作經驗,具備埃森哲、柯萊特等乙方知名咨詢公司的工作經歷,以及聯想和益豐的甲方工作經歷,雙重經歷雙重視角,精通業務與技術,選擇正確的數字化發展路線,用最小成本推動了企業數字化建設。