Sorry, this content is only available in 繁體中文. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

新冠肺炎 (COVID-19) 的後疫情時代,因為社交距離的必要性,使得線下消費都轉往線上,因而加速線上消費的浪潮。許多零售品牌經營者紛紛開始注入資源,想要自己做電子商務,藉此提升業績。但實際上做電商網站背後需要仰賴資訊工程團隊、營運團隊的支撐,這些事情不是一蹴可幾,需要長期的經營與管理。針對這類常見的問題,本文整理以下的分析:

  1. 電商要做的事有哪些?
  2. 資源應該擺在哪裡?
  3. 零售業是否要自己做電商網站?

1. 電商要做的事有哪些?

需求以及管理兩個面向來討論,需求分成核心需求、進階需求,管理則分成工程管理、營運管理,組成了四個象限,如下圖所示:

電商系統維運的核心需求、進階需求、工程管理、營運管理

這些面向大概要做哪些事情,以下分別作說明。

註:篇幅關係,四象限的需求僅列出四個關鍵項目。

1.1 營運管理:核心需求

做電商的入門功課是:

商品秀出去,讓客戶瀏覽,進而下單、付款、出貨,完成交易。

這樣的主要需求,背後代表著幾個核心功能:

a. 商品管理

如何透過系統把商品資訊上架,消費者可以瀏覽商品資訊。零售業的商品都有很多商品分類 (Catalog),同一個商品會有不同的規格、顏色、款式,像是賣服裝,就會有 L / M / S 的 Size 規格,這種規格稱為 SKU (Stock Keeping Unit,存貨單位)。商品管理需要這些最基本的功能,稍微進階一點就會搜尋、推薦、活動、搜尋條件 … 等。

b. 訂單管理

要完成一筆訂單,金流、物流是必備條件。金流就是消費者如何把錢交給店家,從最原始的現金交易、ATM 轉帳、線上刷卡,到超商取貨付款、貨到付款、線上支付 (LINE Pay、Apple Pay) … 等,這些都是屬於金流的範疇。

除了讓客戶可以付款,對於店家來講就是怎麼收款?乃至於之後的發票、稅務等問題需求,都是要處理的。物流就是怎麼把貨交給客戶的過程,最簡單的方式就是賣家去超商宅配給客戶,或者是有些平台商有自己的物流中心可以配送。物流除了把貨交給客戶,而中間衍生的貨運成本、管理成本,也都是要考慮的範圍。

c. 庫存管理

延續物流管理,如果零售業本身有倉庫,例如服裝業會有進貨管理、銷貨管理、儲存管理等。

d. 財務管理

零售買賣還是要從財務角度,掌握從訂單、金流、物流、庫存等各種階段的營運成本,最後結算的才是能知道到底是賺?還是賠?

這些個核心功能才能支撐一筆訂單的成立,但如何在短時間內成立更多訂單呢?如何能持續地讓業績增長呢?除了核心需求,讓電商業績動起來的動能仰賴進階需求。

1.2 營運管理:進階需求

人潮就是錢潮,流量代表著人潮,沒有流量就沒有轉換率。

營收 = 流量 x 轉換率 x 客單價

換言之,要把業務做起來,導流工具是必須的。導流就是讓使用者可以透過一些方式,主動或者被動被導向網站,從而刺激消費。最常見的導流工具就是下廣告,像是 Facebook 買廣告、Google 買關鍵字,其他還有像是 Email 行銷、手機推播訊息、LINE 群組 …. 等方法。

除了導流之外,促購機制也是提升業績的工具,例如常見的買二送一、紅配綠、滿額送百、滿額贈 … 等,這些促購機制讓銷售能夠有彈性,因應各種零售的季節商品、熱點事件、節日活動,可以有不同的操作。

會員機制也是重要的工具,透過累積點數、會員等級、會員活動、推薦機制 … 等機制,讓零售品牌可以經營熟客,提高回購率。

導流、促購、會員、推薦等機制,都是讓電商能夠持續提升業績的工具。而零售品牌經營者怎麼知道自己的業績好還是不好?營運報表則是可以看見全貌,用數據決策的關鍵儀表板。

1.3 工程管理:核心需求

談過業務的核心與進階需求而衍伸的功能,但如果要自行營運電商平台系統,在工程管理方面又要做哪一些事情呢?同樣的分成核心需求與進階需求兩個段落分析。首先看看工程管理的核心需求有哪些?

a. 資訊安全

電商牽涉到金流、個資、交易等議題,所以資訊安全是系統工程與軟體架構最重要的議題。線上的交易系統是暴露在公開的廣域網路 (WAN),換言之,是隨時有機會遭受外部各式各樣惡意與無意義的攻擊。惡意的攻擊就是竊取個資販賣、盜用信用卡資料、甚至是針對性地分散式阻斷式服務攻擊 (DDoS, Distributed Denial-of-Service)。

b. 可維運

維運包含系統維運系統維護兩大部分。維運的起點是系統監控,監控是能夠即時從系統各個層面(基礎層、應用層、業務層)掌握狀況、自動預警、異常告警 … 等。如同氣象局的衛星雲圖,掌握氣壓、溫濕度等資訊,出預測與判斷。

維運的回饋則是事件管理、異常處理、分析、持續改善。而系統維護則包羅萬象,像是常規性的更版部署、作業系統資安更新、資料備份與還原,到大型任務像是企業營運持續管理計畫 (BCP, Business Continuity Plan)、災難還原演練計畫 (DRP, Disaster Recovery Plan)、系統效能、可靠性工程、基礎架構、服務治理 … 等。

c. 效能與可靠

屬於系統架構議題,簡單講,效能是系統單位時間內能做的反應速度,像是平均的延遲時間在 100ms 以下屬於效能可以接受的範圍。

效能牽涉到系統架構的層次 (Layer) 以及依賴性,換言之,系統架構的層次越多寡、依賴性強弱,會影響系統整體的效能。可靠度工程談的包含彈性 (Elasticy)、韌性 (Resilience)、可擴展 (Scalability) 的架構特性,用目的來講,就是當系統運算單元發生故障時,能夠故障移轉 (Failover)、甚至容錯 (Fault tolerance),這些都是屬於很重要的基礎系統工程。

d. 持續交付

系統經常需要因需求而有所改動,所以系統版本的異動也會是頻繁的。但系統是在線上處理使用者的流量,同時又要頻繁的發佈部署,所以可靠、穩定的持續交付是工程團隊必須要具備的核心能力。

上述的需求雖然放在核心需求,但是實務上,不代表很容易或者很快就可以完成,這些往往都需要具備一定的工程能力、技術管理、技術駕馭等能力,才能逐步完成。

工程方面的核心需求看起來就沒有很容易,那進階需求呢?讓我們繼續看下去。

1.4 工程管理:進階需求

前面談工程的核心需求,目的是讓電商網站可以持續且穩定的發展下去,但是接下開始會遇到一些更大的挑戰,像是搶購、或者是累積了數百 TiB 、數個 PiB 的資料需要分析 … 然後就是如何更高效的擴展業務 … 以下聊聊這幾個需求:

a. 可擴展架構

擴展是日常的流量自然增長狀況下,為了讓系統可以逐漸接收更多的流量、成立更多的訂單、完成更多的交易,像是每秒可以完成 100 個交易 (TPS, Transacation Per Second),或者是每秒 1,000,000 個請求 (RPS, Request Per Second)。

理想的狀況是,系統資源透過線性成長,倍增業務乘載量,也就是系統的容量 (Capacity),這樣的架構稱為可擴展架構。可擴展架構牽涉到分散式架構議題、擴展架構設計。自然增長的流量可以透過擴展架構設計滿足線性增長,但是面對極端的搶購時的順間巨量就不適用於此。

b. 瞬間巨量

搶購是電商最喜歡玩的業務手段,但是對工程來講卻是很大的挑戰。瞬間巨量代表著在一秒之內,瞬間的請求量 (RPS) 會到極端值,衝進系統要完成交易量 (TPS) 也會是個極端值。

如何讓搶購這件事情可以順利過關,系統不會當機、消費者使用體驗不會太糟,從工程角度來看,同時涵蓋前端架構、後端應用架構、網路架構、資料庫、分層快取、分散式交易、排隊演算法、限流機制、橫向擴容、熔斷與降級、即時監控 … 等方方面面的考量。

瞬間巨量另外一個問題則是網路頻寬問題,這在雲服務 (Cloud Services) 已經不是問題,但是傳統地端機房則是非常巨大的成本與挑戰。現在大多的資訊系統已經在雲端服務化,換言之,外部衝入資料中心的頻寬大多不是問題,而內部的頻寬則依賴機器數決定。但是地端自建機房,不管是對外頻寬、還是內部頻寬都是要自己處理的,特別是對外頻寬的吞吐量、可靠性、成本都是要考量的。

c. 海量資料

一千萬筆的資料放在關連式資料庫 (RDBMS) 不是什麼新聞,但是當一億筆資料,甚至十億筆、百億筆的時候,就已經不是關連式資料庫的範疇。或者是資料的量體是從 100GiB,變成是 10TiB、100TiB、1PiB、10PiB 的時候,就是屬於大數據範疇,這些海量級的資料,都要面對同樣的過程,從搜集、儲存、處理(分析)到呈現等四個階段,每個階段在工程上都是極具挑戰的。特別是往往這些需求都要即時性的時候,那更是難上加難!

d. Cloud Native

雲計算已經普遍被接受,但是如何有效的運用雲端技術,讓系統能夠更快速、可靠的反應,則是新一代的工程團隊要面對的,同時也是考驗技術管理團隊的智慧。像是容器化技術 (Containerize) 需要具備應用程式的無狀態設計,使用容器編排技術 (像 K8s),則需要做入口 (Ingress) 流量分流、資安、限流 … 等規劃與設計。

隨著系統服務化的複雜,微服務架構 (Microservices) 是常見的分散式架構,但是微服務架構必須仰賴服務治理、持續交付、容器化、維運自動化 … 等基礎工程能力,雖然帶來高擴展、高彈性的系統能力,但工程管理的挑戰也是倍增的。

上述工程管理的需求,不管是核心還是進階,其實都只是九牛一毛,本文僅列出其中較為重要的課題,每一個可以展開成獨立的課題深入探討。

大約知道電商要做哪一些事情,接下來來看看如果真的要做,那麼資源應該怎麼擺?

2. 資源該擺在哪裡?

下圖是《HBR 哈佛商業評論》的企業組織發展階段,每階段代表企業發展的重點,也點出了發展過程資源該擺在哪裡。

《HBR 哈佛商業評論》的企業組織發展階段

圖片來源:《哈佛商業評論

用上一段提及的那些事,搭配企業發展的階段,以此為主軸,我們試著回答:『資源應該擺在哪裏?』

(註:分階段不代表該階段其他事都不用做,只是比例原則而已。)

階段一:招生意、做生意

以零售業來說,起步第一階段就是先把生意招進來、把生意做起來,這個階段還在摸索方向,找尋目標客戶,探索市場。找到對的客戶,讓貨出的去,錢進的來,降低資金消耗率 (Burn Rate) 是剛開始的重點。有哪些事要做?如下圖:

品牌電商營運第一步:商品管理

所以這個階段資源該擺在如何把商品管理做到位,怎樣的商品是客戶要的?好的商品有哪一些特點?

哪些客戶容易下單?這些族群是哪些人?成立訂單的循環是什麼?中間有哪一些卡點?支付的問題?金流的問題?物流的問題?每張訂單的成本結構是什麼?貨怎麼出?客戶退貨怎麼辦?

這個階段工程管理重要嗎?圖中的比例並不高,系統只要堪用即可,網路上有很多類似堪用的系統,都可以自己 DIY,像是 WordPress、OpenCart、Magento、osCommerce 都是可以自行快速建置的系統,甚至使用一些集中式平台也可以。

讓生意進的來,貨出的去

是這階段的重點,資源應該擺在招生意、做好生意,活下去!

這是個 0 到 1 的階段,員工數約 <= 30 人。

階段二:保客戶

經過第一階段,招生意、做生意不斷的嘗試、修正與探索,看起來方向是對了,但怎麼把客戶留下來,或者以同樣模式找到對的新客戶,讓營收持續成長?這個階段的重點就是保客戶。有哪些事要做?如下圖的『保客戶』:

品牌電商第二步:保客戶 以同樣模式找到對的新客戶,讓營收持續成長

好的產品才會有人用,好東西大家會互相分享。但是好東西不會讓使用者感覺到,就像空氣一樣,存在,但是需要。這主產品有種可靠且安心的感覺。而讓客戶留下來,有可靠的感覺,背後仰賴工程團隊持續地把加強系統的核心需求,同時也開始要面對進階需求。

生意跑進來,客戶留下來

這個階段的資源要擺在強化工程的核心需求,讓客戶安心使用。

這階段是從 1 – 10 的階段,員工數約 <= 80 人。

階段三:管公司

方向確立了、客戶也留下來了,核心的基礎工程持續做了,但是會有更多的客戶加入,更多的需求與挑戰,如何讓系統能夠持續成長,維持新進的客戶擁有同樣好的體驗,這時候有更多的工程挑戰要面對了!同樣的,有哪些事要做?如下圖的『管公司』區塊:

這個階段,公司的業務量大增,所以工程的問題會逐漸浮現,很多過往沒有做好的技術債、效能、可靠性、維運、新舊技術的汰換、人員訓練、技術決策、技術架構 …. 等問題都會是內部要面對的挑戰。

做好內部的技術管理、協作效率化、流程改善、人員培養、工程能力提升 … 等,都是這個階段需要面對的課題,這是屬於管公司的問題。安內了,才能攘外,持續推進業績,才能夠讓業績真的反映到整體營收。而不是業績談到了,但卻吃不下,反而早成商譽的損失。

團隊動起來,業績衝進來

這個階段是公司的轉變期,開始要面對工程管理的挑戰,資源要投注在工程的進階需求。

這是 10 – 50 的階段,員工數約 <= 200 人。

階段四:管產品

經過一段時間,總算可以管公司了,工程團隊上軌道了,進入新的階段。這階段開始有機會獲利,而獲利的成長幅度,依賴怎麼『管產品』,範圍如下:

品牌發展階段四:管產品

電商幫零售業在線上做生意,讓營收動起來,精準的導流、有效的促購、折扣機制、點數 ⋯ 等工具,更重要的是營運趨勢報表協助決策支援,讓業務可以回到精準導流、促購、折扣 … 等。這些都仰賴營運進階需求,有效提昇業務動能。這些機制需要在這階段完善,同時因爲已經具備更好的工程管理能力,會更有能力快速完善進階營運需求。

產品出的去,營收看得到

這個階段,要挹注資源在完善營運管理的進階需求。

這是 50 – 90 分的階段,員工數約 <= 500 人。

階段五:擴生意

如果公司能夠走到這裡,已經是獲利了,公司的現金流有彈性操作更多事情,接下來的發展會是兩種:1) 規模化、2) 集團化。

規模化是延續同一個主題,持續做大,並且擴展業務的面積,甚至衍伸出額外的產品,最有名的就是電商 Amazon,其核心業務已電商為主,後來衍伸出雲服務 AWS、Kindle。集團化則是發展不同屬性的產品,最著名的是 YAMAHA,從最早做鋼琴,然後二戰衍伸飛機引擎、機車、汽車引擎、合成樂器、船舶、合成纖維 … 等。

不管是集團化還是規模化,都是複製前面的經營過程,讓產品可以擴展、或者探索新的業務方向,如下圖紅色區塊:

品牌發展階段五:擴生意

這時候的資源該擺在哪裡?這時候的問題已經不是這樣問了,這時候是資源開怎麼有效運用的問題了。

這是個 80-90 ,同時也是 0-1 快速往 10-50 的階段,員工數約 > 500 人。

3. 零售業是否要自己做電商網站?

對於零售業經營者來講,心裡最大的疑惑就是:

  • 我要不要自己弄一個網站來賣東西?
  • 弄一個網站要花多少錢?需要多少人的團隊?
  • 需要買哪些設備?一個月要花多少錢?
  • 網站撐得起流量衝擊?流量費會不會很貴?
  • 如果網站被駭客攻擊怎麼辦?

但是,實際上零售業經營者初期要面對的是:

找客戶!活下去!

也就是階段一的『招生意、做生意』,從訂單數據分析,判斷業務方向是否正確?看看損益表的狀況,資金是否足夠支撐整個業務的執行,方向對了,循環動起來,找到驅動支點了,再往下走。

如果沒有電商系統的狀況,實體的零售商店,單月營收可以讓 20 ~ 30 人以下的公司持續營運,那麼可以嘗試用代管服務,像是 WordPress、OpenCart 等,讓幾個員工去嘗試營運,但原則依舊在維持原本的營收,因為這時候還是在前述的階段一。如果因此可以提升營收,那麼再來考慮是否聘僱專職工程師開始打造自己的系統,或者是找現有的服務商。

進入『保客戶』階段,這是個開始建立工程團隊的時機。因為這時候要思考下一步是要穩扎穩打,還是快速衝刺?不管是穩扎穩打還是快速衝刺,面對市場的變化,電商系統都是可以有效提升營收的武器。所以這步棋決定重點是在先『保客戶』還是直接『管公司』,屆時面對的將是資金問題、管理問題。

保客戶,使用代管服務,很容易無法乘載業務量,這時候需要自己培養工程師協助,或者對外尋求協助。一段時間後,有可能遇到預期或者非預期的搶購。預期的搶購是業務透過導流工具,將流量導入,屬於可以預期的;非預期的則是因為新聞熱點事件、KOL 觸發的熱點事件、駭客攻擊 … 等,這些都是很難預防。

處理這些因為搶購造成的瞬間巨量,非常倚賴專業的工程管理處理,需要有經驗、基本功深厚、運作有效率的工程團隊,這種團隊就像 A Team (天龍特攻隊) 、或者搖滾樂團,不同工程師有不同專業領域,但是卻可以合作無間,處理各式各樣的任務。特別是這種需要經驗累積、不斷修正的搶購系統。

這時候業績來源分配比例,線上電商持續成長,將有機會超越線下實體營收;甚至 OMO (Online Merge Offline) 若做得好,不僅帶動實體成長,更能發展出 OMO新業績那麼擁有自己工程團隊負責維運電商網站就是關鍵時刻了,這時候經營者可以自己問問:

業績能如此持續兩年、五年成長?

如果是,那麼儘早準備擁有自己的電商系統,找到能協助經營工程團隊才是讓業績穩定成長的關鍵!透過電商系統帶動線上業績,驅動線下實體門市讓電商為實體所用帶動 OMO 循環,更是現在零售業發展的一大重點

零售經營者面臨諸多數位轉型挑戰,自建電商是一個方式,但相對投入建置成本高、維運成本也高。與其自建電商,採用擁有千億級電商技術經驗與能量的專業服務商,作為技術支援的後盾,更能專注於電商及組織、營運流程上的佈局,進一步帶動線上電商與線下門市虛實融合 (OMO) 循環,帶動客流,更帶動業績。

結語

回到標題的問題:

電商該把資源投入在哪裡?

零售品牌經營者最在乎的是如何把生意做好、做大,擁有自己的電商網站則可以瞬間跨時間、空間,廣大的線上消費者帶動的收益,會讓業績有翻倍的成長。但是翻倍的成長也代表著系統需要乘載的能力也是翻倍,而背後的技術與工程會是相當可觀的成本。

如果資金夠雄厚,期待自己可以掌握業務的需求,那麼可以考慮經營自己的工程團隊,否則建議先從各個電商平台入手開始。

【免費了解 · 專人諮詢】

網路開店、門市數位轉型,品牌 OMO 虛實融合講座