主頁 > 軟體設計 > 程式員吞噬零售業,成也中臺敗也中臺 | 零售十年變遷路

程式員吞噬零售業,成也中臺敗也中臺 | 零售十年變遷路

2021-04-23 11:26:48 軟體設計

【CSDN 編者按】《程式員》于 2000 年創刊,其理念為技術改變世界,創新驅動中國,2021 年,全新的《程式員》2.0 重新起航,以專業的內容為立足點,以音視頻、圖文專欄等豐富的多媒體形式為載體,立足當下,放眼未來,為讀者帶來全方位的技術和產業解讀,

本文為《程式員》2.0 第一期內容,繼對話 Unix 命名者Brian W. Kernighan與 Vue.js創造者尤雨溪之后,我們邀請到了合闊智云CTO劉如鴻,暢談了零售行業十年變革與發展背后的動因,

你還記得十年前的零售是什么樣子嗎?大街上滿是主題店、嘉年華店,門店裝修、貨架設備、購物線路等統統圍繞貨物而設計,貨物是這個時代的主角,只要零售商擁有好商品,多渠道分發,商品就能賣得很好,也是在這時,團購模式傳入中國,蘇寧、國美、百聯等傳統零售企業試水網上商城,一方面是追趕潮流,一方面是向區域外拓展資源,隨之而來的便是各個電商企業的誕生與崛起,

電商對傳統零售的沖擊無疑是巨大的,而且隨著互聯網技術的不斷進步,電商企業對于庫存、渠道、供應鏈的管理更智能、更高效,最主要的是利用大資料能為消費者提供更好的服務,這是傳統零售企業無法企及的,在傳統零售尋求轉型之際,“新零售”概念被提出,并迅速火爆全球,此時的傳統零售對于網路電商已經沒有選擇余地,從原來的了解到試水再到不得不面對,

如今,科技、資料和分析能力已經成為新零售行業必不可少的部分,利用線上的互聯網技術和線下的物體店終端,合力為整個商業生態的中心——消費者提供服務升級策略,進而完成電商平臺和物體零售店面在商業維度上的優化升級,

零售行業十年經歷了怎樣的變革?變革動因是什么?未來何去何從?《程式員》邀請了合闊智云CTO劉如鴻,系統地解答了上述問題,

重點速覽:

  • 零售變革動因:流量碎片化和社會消費行為的遷移,使得零售商需要去找到新的流量來實作商業的變現,而這些流量很大程度來自新崛起的平臺;傳統運營成本持續走高(房租、原料和人力成本),迫使企業需要更高的運營效率和更加可控的運營成本,
  • 傳統零售商面臨的困局:其中之一是商業環境的巨大變革讓他們原先引以為豪的精益管理變成了敏捷的反義詞,
  • 新零售如何更“新”:千店千面;全渠道的訂單履約能力;要做到履約,零售還得有精準的供應鏈管理能力,
  • 訂單履約:基本的標準是“按時、可靠地將資訊流轉到門店,組織生產,并通過不同的方式完成服務交付”,
  • 零售業的本質:是為了滿足消費者不斷變化的需求,是供應鏈效率不斷提升的商品經營,
  • 零售業的技術采納:技術的發展催生了新的商業模式,進而帶來整個商業環境的改變,而零售行業的技術采納,正是因為商業環境的巨大變化,
  • 看待零售企業自研系統:百分百自研是最昂貴而回報低下的選擇,
  • 零售商IT團隊建設關鍵角色:業務專家/顧問、專案經理、系統運營,

2011 年,我剛進入零售領域,在一家非常傳統的貿易批發公司,幫助他們組建完整的電子商務團隊,我看到傳統零售都是品牌->總代->區域代理->零售門店逐層批發的體系,面臨的基本挑戰是商業流通,所以他們的底層商業邏輯是“渠道為王”,

而在那時,電商已經高歌猛進,大家都在討論要不要發力電商業務,要不要改變傳統的業務體系,而發展電子商務,根本出發點無非兩個,要么是消化庫存,要么是拓展新的銷售渠道,零售商是把電商業務當著“新物種”來看待的,他們更在意的是多渠道的庫存管理和區域價格管控體系,

轉眼十年過去,我們可以親身感受到這些變化:

  • 線上線下的邊界在模糊,位置決定一切的傳統零售思維也早已模糊,
  • 隨著移動紅利的結束,流量再也沒有洼地,所有零售商被迫從區域競爭和區域競爭轉向全面競爭,
  • 全渠道不僅僅是多了渠道,真正的挑戰在于整合這些渠道并為自己的零售生態賦能,
  • 新興的電商平臺和自媒體平臺進一步模糊了商業邊界,看似無處不在的商業流量變現,實則對零售企業提出了更高的挑戰,全渠道零售的下一個命題是真正的服務履約能力,

這十年間發生了什么?

短短十年間,零售行業為何巨變?

談到10年零售變遷,有幾個關鍵的名字不能不提,那就是美團、餓了么、大眾點評、京東、抖音,還有阿里體系的天貓、聚劃算,正是他們重新定義了團購、新零售、O2O及外賣,也正是因為他們在商業模式中的創新,讓久居中國的外國人在離開中國后反而覺得無所適從,中國這十年來在商業創新和商業變革領先全球,我們可以看幾個關鍵的時間點:

  • 2013年,美團從千團大戰一騎絕塵勝出,無數資本砸出來的團購網站一地雞毛,橫尸遍野,而美團則因為營銷投入克制和農村包圍城市策略,得以笑到最后,與此同時他們啟動了外賣業務,和已經在這個賽道奔跑五年的餓了么競爭高下,
  • 2014年是O2O瘋狂的一年,得到阿里資源強勢傾斜的聚劃算在2年前就已經滅掉了所有的實物團,而團購原本就是電商的領地,市場上再也沒有玩家能夠與之抗衡,傳統零售商曾擔心電商會顛覆一切,但這樣的場景并沒有到來,線上線下達成了攻守平衡,這時候O2O應運而出,至于是Online to Offline還是Offline to Online,不得而知,線上線下的商業融合在此時變成了最熱的主題,不管是電商玩家還是傳統零售,無不期望從護城河之外的流量中分一杯羹,服務如何在線化成為了非常重要的商業主題,
  • 2015年,美團在彈盡糧絕之前憑借資本的助力,吞下了老對手大眾點評,市場上只剩下唯一的對手餓了么,同年,美團發力酒店業務,資源整合之后,美團外賣于2016年超過餓了么,并在2017年占據了酒店業務全網第一,在非實物電商領域,美團已經沒有了真正的對手,
  • 2016年,阿里發布新零售白皮書,隨著移動用戶的普及,零售行業線上線下的壁壘不復存在,這時候“Omini-Channel”又成為了熱門的話題,只是不再局限于Marketing,而是“Omni-Channel Retailing(全渠道零售)”,當時對于傳統零售商而言,O2O和電商兩個話題還是有些割裂的,與此同時,王興提出“互聯網進入下半場”,剛剛開始的“下半場”更多標志著傳統零售洗牌的真正開始——從原來的了解到試水再到不得不面對,
  • 2018年,拼多多經過了3年奪命狂奔后上市,我們突然發現,本以為大局已定再無波瀾的在線電商,在下沉市場擁有著巨大的想象力和可能性,我們還發現了諸如抖音、快手這樣的新興物種,正在一發不可收拾地消磨掉年輕人的時間,
  • 2019年抖音崛起,短視頻迅速成為年輕人的生活方式,傳統社交與內容傳播的邊界在模糊,短視頻KOL紛紛試水直播賣貨,
  • 2020年至今,一場席卷全球的新冠肺炎,以一種戛然而止的方式改變我們生活和消費行為,乃至重塑了全球的經濟、政治格局,一家零售企業是否具備數字化的能力,基本上決定了它在后疫情時代的競爭力,數字化建設不再是需要與否,而是生與死,此時邊界進一步模糊,零售、電商、O2O、社交不再是各自的主題,例如一個KOL在抖音下單了零售連鎖門店的蛋糕,通過門店的外賣騎手送貨,你說這是電商還是餐飲,是社交還是O2O?我們無法說清,這就是當下零售企業需要面臨的挑戰,多元化的消費渠道、無邊界的訂單履約、始終 “在線”的消費者,迫使他們需要用更加開放、敏捷的方式去服務消費者,提供無差異的消費體驗,

短短十年間,零售行業發生了如此翻天覆地的變化,你有何感想?是否想過變化背后的原因呢?其實在我看來,所有零售的變革無外乎幾個動因:

  • 流量碎片化和社會消費行為的遷移,使得零售商需要去找到新的流量來實作商業的變現,而這些流量很大程度來自新崛起的平臺,
  • 傳統運營成本持續走高(房租、原料和人力成本),迫使企業需要更高的運營效率和更加可控的運營成本,

所以,“新零售”出現了,很多概念也隨著“新零售”的提出應運而生,比如“全渠道”、“智慧門店”、“數字化”等等

零售行業巨變背后的IT技術發展

新零售“新”在哪?和舊零售有什么區別?

對于這個問題,眾說紛紜,阿里說新零售是“人、貨、場”的重構;京東說零售的改變是零售基礎設施的重構;亞馬遜創始人貝佐斯認為在未來的10年、20年、30年乃至50年,零售有三點東西是不會變化的:顧客永遠喜歡低價的東西,永遠希望盡快收到貨,永遠希望有更多的選擇,

而新零售的本質并不改變這三個基礎要素,只是更多的渠道和數字化創新讓這三個要素更加緊密,為消費者提供了更好的體驗,

那么新零售如何讓零售的基本要素更“新”呢?主要體現為以下幾個方面:

  • 千店千面:總是致力于為不同消費者提供更好的消費體驗,
  • 全渠道的訂單履約能力:收到消費者訂單不代表大功告成,恰恰相反,這是服務的開始,消費者不管哪個渠道下單,商家都應該無差異地進行履約,這就涉及渠道能力、履約能力,
  • 要做到履約,零售還得有精準的供應鏈管理能力,不然拿到錢只能退款,消費體驗也無從談起,

你看,零售業的本質,就是為了滿足消費者不斷變化的需求,是供應鏈效率不斷提升的商品經營,

而在滿足消費者需求與提升供應鏈效率的同時,變革如影隨形,

比如我們熟知的IT技術,零售行業在十年變革中,對IT技術的采納與使用方式也發生了巨大的變化,一個繞不開的關鍵詞就是“中臺”,所謂成也中臺敗也中臺,零售行業的技術采納有幾個變化:

  • 從以ERP為核心的管理投資逐漸轉向應對快速變化的運營管理,這也是從ERP到中臺的變遷故事,根本目的是應對多變的消費者需求和支撐靈活多變的市場運營,
  • 從渠道建設轉向數字化能力構建,自建官網、App、H5網站等血本無歸之后,企業IT采納不再著眼于某一個渠道的建設,而是構建數字化中臺的能力,進而驅動零售企業的全渠道訂單履約和敏捷供應鏈協同的能力,
  • SaaS的興起讓很多企業能夠以更快、更低的啟動成本完成數字化轉型,傳統的IT投資(如軟體采購、自建機房等)占比逐漸降低,越來越多的企業IT投資變得愈加“敏捷”,那就是首先嘗試使用SaaS來加快企業自身的數字化建設,這樣做一方面使得初期成本更低,另一方面也加速了IT采納,帶來的好處就是業務試錯成本的降低,
  • 移動辦公成為繼移動消費之后的主流選擇,企業應用體驗逐漸對齊消費體驗,越來越多的企業將自己的IT采納放在了移動場景上,

這是從偏微觀的角度分析,如果我們把分析角度放到整個商業環境,你就會發現,技術的發展催生了新的商業模式,進而帶來整個商業環境的改變,而零售行業的技術采納,正是因為商業環境的巨大變化,具體可以體現為五個方面,

第一,移動互聯網到來,

移動互聯網的興起給零售企業帶來的最大改變在于線上流量從PC到移動設備的轉移,從而引發新一輪的流量競爭,2015年零售行業的頭部客戶進行了不同方面的業務探索,包括自建商城、自有專屬App、微信公共賬號運營、H5微網站,這些探索的商業考慮基本圍繞著流量拓展和營銷拓展,幾乎沒有在商業上真正成功的案例,

從技術角度來說,這個階段是把線下的零售模式搬到線上,基本上沒有做到和已有系統(ERP)的真正打通,這也是零售行業第一階段的技術探索,

第二,移動支付全民普及,

支付寶、微信支付通過幾個關鍵的流量入口戰爭(打車、搶紅包)基本完成了全民市場教育,“無現金支付”已經成為大勢所趨,對于傳統零售行業而言,有一個非常重要的模塊叫現金管理,但隨著移動支付的普及,我們突然發現不再需要這個業務,因為消費者不再通過現金購買商品和服務,轉而使用移動支付,

這時候零售企業在兩個方面加大了技術的投入:一是購買門店端使用的移動支付設備,讓自己的企業具備支持移動支付收款的能力;二是隨著大量的現金收入轉成在線支付而帶來的結算復雜性,因此很多頭部客戶在聚合支付和支付對賬方面做了大投資,目的只有一個——更好地管理他們的資金,

第三,O2O(外賣)半壁江山,

我們可以簡單把零售行業分為兩種型別:觸手可及的實物零售最容易被電商化;非實物或者需要服務的零售業務(典型是餐飲)則可以歸結為O2O,這兩種零售業務都是美團業務看中的,

對于零售企業而言,最大的改變在于從交易服務一體化變成了交易在線化服務本地化,零售服務有一個顯著的特點是LBS(Location Based Service),不同于電商的是,零售門店有清晰的服務半徑,而O2O將原本的到店服務拆成了兩個環節:訂單交易與服務履約,如果說移動互聯網和移動支付為消費者帶來了生活方式的改變,那么O2O的成熟則重塑了零售行業側重服務的整個商業基因,

零售企業可以慢一點擁抱移動互聯網,移動支付也可以不夠便捷,但在當下,如果零售企業不具備一個強大的全渠道訂單履約中臺,來幫助自己通過數字化的手段去服務越來越挑剔的、個性化的消費者,那就無異于自斷商機,

數字化中臺建設在最近5年內成為了零售企業最大的IT投資,一個零售企業是否具備強大的數字化“中臺”能力,基本決定了它的競爭能力,

第四,云計算興起,

傳統零售頭部客戶在早期都是選擇自建 IT 基礎設施、自建 IT 團隊來實作資訊化——因為10年前的他們沒有其他選擇,而十年間云計算技術的飛速發展,讓IT基礎架構建設對于零售企業的門檻大幅度降低,與此同時也加快了相關的技術采納,比如移動互聯網、移動支付和O2O,使得他們能夠以更低的啟動成本和更快的市場回應速度來進行商業的試錯與探索,

第五,零售SaaS的崛起,

相對于過去建設一個系統,當下的挑戰在于生態的整合,因為涉及更多的業務、更多的技術,零售企業的核心能力還是零售,而非技術,因此在不同的垂直領域誕生了很多SaaS公司,他們承擔了專業解決技術實作的作業,使得零售企業在業務起步階段只需要專注于商業模式的創新與探索,

以上這五個方面是零售行業應對商業環境改變所采用的五個關鍵技術,但是,改革是個艱難的程序,尤其對于那些曾經取得成功的傳統零售商,原因無外乎幾點:

  • 在傳統的零售生態里已經建立起強大的運營體系,而這樣的體系是支撐他們過去成功的關鍵,過去的二十年已經進行了大量的資源投入和人才儲備,改變非一朝一夕之功,
  • 他們自上而下設計了整套完整的管理體系,基本上是以財務管控為中心(典型為ERP),所有的業務模式都是建立在這個管控體系下,但隨著電商、O2O、新零售這些浪潮的到來,整個組織都無法做到快速改變,
  • 商業環境的巨大變革讓他們原先引以為豪的精益管理變成了敏捷的反義詞,

零售商進行數字化升級和改造,基本的思維方式是“開源節流”,

首先是開源,任何改造目的,都是更加親近日益挑剔的消費者,為他們提供更好的消費體驗,外賣和支付是切入點,但他們的數字化平臺處理全渠道的訂單能力不足,與此同時,即便更多的訂單產生,他們的門店網路無法做到高質量的訂單履約,反倒引發更多的客訴,

其次是效率與成本,隨著規模的增長,低下的供應鏈協同效率和羸弱的成本掌控能力吃掉了零售商所有的利潤,因而他們希望加快供應鏈的敏捷協同能力,

實際在轉型程序中,最大的阻力和挑戰是在一個技術陳舊、業務復雜、財務管控導向的ERP系統上做技術改造,困難在以下幾個方面:

  • 老舊的技術架構無法支撐新的業務需求改造
  • 原有的組織架構、管理流程、團隊能力都無法滿足“輕快”的需求
  • 計劃型(定時任務、批處理)的IT系統無法滿足實際計算的要求
  • 與彈性計算、分布式計算的絕緣,在業務爆炸性增長的階段,即便用錢砸,可能都無法砸出來他們想要的效果

那么,該怎么解決這些困難呢?下面我們從業務方案和技術方案兩方面來分析,

IT技術如何助力零售行業轉型?

不同企業的零售業務不同,目標、關注點和切入點都不相同,但他們都繞不開“零售”的基本邏輯,以我所服務的餐飲行業為例,那就是:

  • 提供無差異的到家和到店服務體驗
  • 全渠道訂單的實時處理能力
  • 實時的門店現場服務履約能力
  • 為消費者提供千人千面的消費體驗
  • 更加敏捷的供應鏈協同能力
  • 企業系統生態共建能力

這些詞聽起來似乎有點兒抽象,如果用幾個關鍵詞來總結,那就是“交易、訂單、會員、促銷、供應鏈和供應商”,我們把這些因素歸結到需要升級和改造的場景,大致以下幾個方面:

第一,主資料管理,

這是一切業務的基石,而零售行業的主資料一開始是為了財務管控而設計的,比如茶飲,會有杯型、溫度、甜度、還有加料等給消費者提供個性化選擇的屬性,不同的終端如門店POS、小程式、外賣平臺需要的資料是不一樣的,那么我們又該如何設定?

從ERP里匯出來的主資料內容寥寥可數,但前端業務又需要大量的資料支持,這是一個不容忽視的矛盾點,起初,簡單的做法就是通過編碼和名字,人工操作在不同的平臺進行編碼映射,各自平臺所需要的資訊在各個平臺維護,如果資訊維護錯了,就會導致各個系統之間的割裂,比如小程式的商品在門店沒有維護,很可能出現小票打不出來,無法制作等問題,再比如報表無法識別某一個渠道的商品,就會導致最終的統計資料不準確,而這一切的根本問題在于沒有一個統一的主資料管理工具來規劃各個平臺的資料差異性,我們一直在說集成,可對于餐飲企業,最基礎的是要集成好商品、門店、渠道這些最為基礎的資料,

第二,全渠道訂單管理,

之前多次提到,餐廳已經從傳統LBS的到店消費變成很大一部分的到家服務,因此一個統一的訂單管理系統(OMS)就變得尤為重要,這不是一個簡單的訂單串列管理、匯總管理,而是代表整個場景的轉移,原來的重點是餐廳 POS+后臺銷售報表,現在則變成了訂單在線化,OMS成為零售企業的神經中樞,我們需要接入更多的訂單渠道,需要更加有效地組織、管理并推動訂單的履約,而談到履約,基本的標準是“按時、可靠地將資訊流轉到門店,組織生產,并通過不同的方式完成服務交付”,怎么做到按時推送,不漏單、不重單,門店又怎么知道應該如何生產,制作完畢之后又需要如何給客戶(叫號或者外賣),這些都是OMS需要解決的問題,

第三,實時庫存,

餐飲不同于實物電商,大部分商品都是通過門店現場制作,對于時效的要求相對苛刻,那么庫存的準確性就尤為重要,沒有一個想喝芒果奶茶的消費者愿意在下單后等了2小時才被告知芒果沒有了,需要取消訂單,這會極大地損害消費體驗,可是一杯茶并不是一杯可樂,它需要芒果、芝士、茶湯以及其他原料,同時消費者又在不同的渠道下單,如何做到在芒果沒有了的時候將所有渠道里主原料為芒果的水果茶全部下架,如何準確預知什么時候芝士又將“沒有了”(不同的茶飲可能都會用到芝士),這就是在全渠道交易時代零售餐飲企業會遇到的挑戰,我們的探索是通過動態配方對全渠道訂單做實時的配方原料計算和實時庫存扣減,

第四,供應鏈敏捷協同,

既然我們已經掌握了庫存情況,那么門店缺貨了怎么辦,是從倉庫進歡訓是隔壁門店調貨?不同商品的訂貨周期、配送周期都不一樣,更加復雜的是結算規則也不一樣,對于規模化的餐飲,所有門店、倉庫、配送中心、加工中心、供應商本質上是一個網狀的分布式協同,有計劃性的管理,也有突發性業務(比如臨時配送或者緊急召回),在門店規模超過500家時,都會遇到極大挑戰,

這是從業務方面來講,那么從技術方面來看,又該采用什么樣的解決方案,是自研技識訓是采用外部現有的技術方案?

不得不說,瑞幸咖啡是一個值得參考的案例,我們且不說瑞幸咖啡在資本市場的表現如何,就說它在數字化升級與改造方面,開了一個很好的頭,也開了一個很壞的頭,為什么會這么說?

在某種角度上,瑞幸給所有的零售行業指明了一條康莊大道,那就是通過數字化建設作為企業競爭的核心能力,可以極大地加速一家零售連鎖企業的擴張步伐,而我說他開了一個壞頭,是因為它讓所有的零售企業都以為一定要自建技術團隊,百分百自研,然后成為一家真正的科技公司,

事實上,并不是每一個零售企業都有能力和機會做到百分百自研,在升級和改造的程序中會遇到三個挑戰:

  • 自研技術需要有一個深刻理解零售業務的產品團隊,而大多互聯網轉向零售的技術團隊并不能真正理解零售、理解線下業務,互聯網最大的優勢是規模化擴張,而零售無論怎么變,首要是服務,這就要求精細化管理,
  • 新系統上線不是一個技術任務,而是一家公司的業務流程的重構,會牽涉不同的人、不同的作業,包括培訓、溝通,
  • 零售業務涉及的鏈路非常長,一個環節出錯,會影響所有環節,比如一個價格出錯,或者一個規格配置錯誤,將會導致所有的銷售報表、庫存、成本都是錯誤的,

對于零售企業自研系統,我有一個觀點:百分百自研是最昂貴而回報低下的選擇,為什么?

首先,組建一個完整的產品技術團隊需要大量的投資,瑞幸咖啡在研發人員最多時是500多人,試問有多少公司能夠養得起如此龐大的技術團隊?

其次,如果企業商業模式是業內獨一無二的,是企業的核心競爭力,那么可以考慮核心業務系統自研,從而保持市場的領先優勢,但大部分的零售企業的獨特性體現在品牌和營銷,而非商業模式,該賣水還是賣水,該賣茶還是賣茶,談不出來兩家商業模式的區別,

再次,如果某些模塊需要根據自身業務高度定制或者和其他系統進行深度耦合,可以選擇外包,需求自己定義,完全照企業的業務需求去定制,如果你需要的業務模塊是市場標準化的,那么絕對不要自研,盡可能選擇成熟產品,

最后,如果某些業務需要做一些跟進頭部標桿客戶的方案,那么不要自研,優先采購這些頭部零售商成熟的解決方案,至少可以省去非必要的試錯成本,并且頭部客戶成功的探索可以加速你的商業采納,

總之,不論是自研還是采用外部方案,沒有絕對的標準答案,不過,有一個基本的邊界,那就是產品設計,對于外企頭部零售企業,他們的基本原則是所有的業務需求必須百分百為他們的企業業務自身定制,對于創新業務,他們自己負責產品設計,剩下的技術實作會選擇外包,對于國內零售的新銳企業,偏向消費端體驗的產品在有能力的情況下可以選擇自研,數字化轉型的基礎能力可以借助SaaS廠商合作、集成來加快數字化轉型,偏向穩定的業務如財務、倉庫管理可以選擇成熟的商業套件,

另外,自研也好,采用外部技術方案也罷,都會極大地影響到零售商IT團隊建設,但幾個關鍵的角色必須要有:

  • 業務專家/顧問:負責定義零售企業的核心業務需求和流程
  • 專案經理:負責企業數字化升級與建設的落地
  • 系統運營:負責系統的日常運營,包括資料管理、系統配置維護等

一個零售企業需要包括的業務涉及人事、財務、采購、運營、市場、IT、供應鏈等等多個部門,每一個業務部門都需要業務系統,以支撐門店運營最基本的銷售和供應鏈為例,大概需要這些內容:

縱觀過去十年商業零售的不同變化與產生變化的要素,我們可以思考這樣一個問題:到底是技術驅動了商業零售變革,還是商業零售變革推動了技術的發展?和眾多業務與技術關系的話題一樣:從來不存在單邊的技術創新推動了商業零售的升級,而是因為技術的進步比如4G、5G、云計算等推動了大商業環境的變化,而在變化的程序中,把握好機會的商業企業趁勢崛起,同樣也有企業墨守成規失去創新力,慢慢掉隊,

我多次提到“邊界模糊”,這恰恰是商業環境最大的變數,模糊意味著每一個業務、每一個模塊在被重新定義,而變化則意味著,機會無論對于零售企業還是零售SaaS公司,都存在一個巨大的機會,那就是在逐漸模糊的商業邊界里重新定義下一個商業的未來,

數字化轉型和升級是零售企業的必然選擇,每一個企業都應該利用技術的進步來推動企業自身的發展,而無需都成為技術研發公司,尤其是基礎技術的研發,這不是一家商業零售公司的核心價值,但需要成為“最懂”技術的零售公司,那就永遠在合適的時間選擇最合適企業自身的技術,選擇業務創新所需要的產品與技術,這才是零售企業的正確選擇,

從 Unix 開發者 Brian W. Kernighan,到 OpenCV 創始人 Gary Bradski,再到 Vue.js 作者尤雨溪……《程式員》2.0第一期以「開發者的黃金十年」為主題,與多位國內外知名的技術領袖和新銳代表進行了深度對話,希望為中國開發者打開新時代的「機遇之窗」,

除了技術引領,我們也希望透過技術對行業進行深入洞察,因此,《程式員》2.0 第一期也邀請到了來自快手、滴滴、貝殼找房、作業幫等知名企業的技術負責人,用案例實踐為讀者闡述直播、出行、居住、在線教育等多個行業變革背后的技術架構和技術引擎,

掃描下方二維碼,添加小助手,即刻加入《程式員》2.0「讀者群」,搶先一步獲取雜志最新資訊,精彩內容不再錯過,

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/279308.html

標籤:其他

上一篇:django搭建個人博客(一)

下一篇:藍橋杯單片機第十二屆第一場省賽--張三填坑

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more