開店能有多複雜?談零售業的八大系統

基礎零售四大系統:ERP、POS、CRM、BI。電商時代新四大系統:eCOM、app、OMS、CDP。零售業在面對新時代,有效整合這零售業的八大系統,是品牌競爭的關鍵。
評論
Shutterstock/達志影像
評論

本文作者李昆謀(Happy  Lee),在網路產業混了 20 年,曾經以為是文青的工程師,發行過沒人看的雜誌,組了沒紅過的樂團,創過沒賺錢的公司,中年時在零售科技業似乎找到了人生的一點價值。聽說現在是 91APP 產品長。

原文刊登於零售的科學,INSIDE 經授權轉載。

開一家店賣東西,在現在這個時代,到底可以有多複雜?

身為消費者,我們都知道怎麼買東西,但你知道在這些店的背後,為了要讓生意做得順利,帳算得對、庫存不要亂掉,零售業者需要多少的資訊系統,讓這一切運作變得有效率嗎?

現在零售品牌競爭是激烈的,除了進貨與人事成本,一堆資訊系統的投資,也是零售業者很重的一塊成本。而且,好的系統讓你上天堂,不好的系統讓你住套房。錢投資有效就算了,最怕的是錢投資了沒有得到要有的效益,還造成現場工作同仁的更多問題。

現在複雜的零售環境,也讓零售業者不是單買一套系統就可以解決所有的問題。嚴格的來說,從零售到新零售,共有 4+4 套系統需要思考,以下就分別介紹零售業的八大系統。

零售業的八大系統。Credit: 91APP

基本零售 4 大系統

  • ERP:零售簡單來說就是貨的買賣,一買一賣之間來賺取價差,所以要紀錄用多少錢買了多少貨、賣了多少貨、還有多少的貨放在倉庫裡,然後算賺了多少錢等,這些貨的管理發展成了零售業基礎的 IT 系統:ERP。
     
  • POS:銷售的發生,傳統來說就是在門市展示商品,透過門市店員的介紹與服務,最後讓消費者在櫃檯結帳。POS 就成為門市貴談常見的系統,主要處理結帳、紀錄每一筆交易、並結算門市的營收。
     
  • CRM:零售業為了經營品牌,重點就在於經營會員,透過會員的優惠設計,吸引來店的客人加入會員,留下資料,並透過會員制度設計,像是消費累積升等、點數累積等等,來吸引會員回購。而背後就需要一套 CRM 來管理會員資料、運算會員權益、並管理會員溝通等會員經營的機制。
     
  • BI:而通常品牌生意越做越大,品牌會很難搞清楚目前經營的全貌,不能單純只靠銷售報表打天下,因此把會員、銷售、商品等數據整理到 BI,然後透過 BI 拉出各種維度的分析報表,了解品牌經營的潛在問題或機會,然後透過 BI 設計會員分群活動,來提高溝通成效;或用 BI 進行商品的分析,找到最高效的進貨策略。

從基本的零售需求出發,ERP 通常就是內部的主幹,POS 創造銷售效率,而 CRM 與 BI 就是提升毛利率的關鍵。

而這四大系統,就是延伸自零售業四大本質,所需的管理系統。

電商發展帶來的新 4 大系統

而電子商務時代來臨,零售品牌又得面對線上購物的場景,導入一些面對電子商務需求的新系統:

  • eCom:支援購物車、整合線上金流,可成立訂單,服務消費者做線上銷售的品牌官網。
     
  • app:品牌 app,讓消費者可以下載在隨身的手機上,除了可以購物,也是隨身的會員卡,通常會整合 CRM,讓會員可以隨時查詢自己的會員權益、點數、有沒有會員禮可以使用等等。app 也方便會員在門市出示使用,並與 POS 可以互動,可以辨認會員、折抵或累積點數、甚或有些品牌會在 app 整合自己的品牌支付(例如 XXPay)。
     
  • OMS :全名為 Order Management System(訂單管理系統),主要用於線上購物產生的訂單處理。因為線上購物不同於門市購物是銀貨兩訖,消費者付了錢拿了東西走,交易已經結束了。線上購物的消費場景,是消費者在線上買了東西,只是「下訂」成立「訂單」,這個交易還沒有完成。所以 OMS 是處理訂單「履約」的動作,就是真的讓這個訂單「完成」,變成一筆真正的銷售。所以 OMS 會處理訂單的撿貨、包裝、出貨,消費者透過各種物流收到貨後,過了鑑賞期,這筆訂單才算真正的「完成」。
    通常 OMS 還會處理商品的上架(到各電商系統)、各賣場配庫存的策略、並在後端串接 ERP 來同步商品與庫存。通常上架的電商平台越多,訂單數越大,越需要 OMS 來效率化工作。
     
  • CDP :全名為 Customer Data Platform,這是近期越來越流行的系統,主要用於收集並處理零售業的大數據,並應用這些數據,更高效率的帶動人流回流。以往的零售數據,僅收集會員、交易等相關數據,現在隨著數位科技的發展,還可以收集會員的各種行為數據,像是會員在網站上看了哪些商品、加入了什麽進購物車,還有搜尋了什麼、在社群網站上按讚、回覆了什麼,這些會員的資訊,都可以用 CDP 收集起來,因此可以更認識會員,可以針對會員進行個別化的溝通、商品建議,也可以串連數位廣告工具做更精準的再行銷。 目的都是讓品牌自己的數據自己掌握、讓數據變成品牌的「流量池」,累積越久越有價值。

零售業系統整合的難題

零售業系統整合的難題。Credit: 91APP

上面這八大系統,通常不會各自獨立運作,而是需要互相串接整合。

通常品牌經營全通路,所以會希望線上跟門市的會員是要整合的,也都是希望 POS、 eCom、 app、跟 CRM 做串接。而所有的商品資訊也希望很整合,所以 POS、 OMS、 eCom、 app 要能串在一起。

但麻煩的是,通常這些系統,背後都是由不同的廠商所提供,所以當不同系統之間要互相整合的時候,往往就會需要協 ( ) 調 ( )。而人之常情就是,各個資訊廠商,通常都會以自己的利益考量,而不是以品牌的利益考量建議整合的方法,也就是資訊廠商都會站在自己最省力(或最賺錢)的方式來建議整合方式,而不是站在品牌最好的方式來建議。

異質系統越多,彼此整合起來的線頭越糾結,就算接起來了,最後還會產生很多資料正確性、即時性的問題。BI 算出來的月業績,為什麼跟 ERP 結出來的帳不一樣?會員打電話來客訴說,她 app 上的點數不對,一查跟 CRM 的點數還對不上?

這些系統整合之後,維運的困難度才是挑戰,系統一有出錯,都是別人的錯,A 廠商怪 B 廠商,然後其實是 C 廠商弄壞的。

零售業的核心系統

零售大中台。Credit: 91APP

所以到底一個零售品牌的核心系統是什麼?POS?CRM?CDP?因為當時各別系統的設計,都是為了特定目的而設計的,而不是為了整合而設計的。而隨著零售業環境的改變,整合變得越來越關鍵,整合的好壞決定了效率化的好壞,而在零售業本質不變的情況下,企業決勝的關鍵就在於整合的有效性了。

所以一個可以協助系統之間整合的系統,變成了很重要的一個關鍵系統,因此有所謂的零售大中台、零售業的 Middelware 等等的發展,主要就是為了解決上面所提到複雜的系統整合問題,所有的系統都對著大中台整合,讓整合的形狀變單純,降低系統整合的複雜度,因此逐漸成為零售業轉型重要的關鍵與核心系統。

責任編輯:Mia
核稿編輯:李柏鋒

延伸閱讀:



蛻變敏捷開發組織並不難! AWS Amplify幫前端工程師從雲端快速建立REACT程式

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。
評論
shutterstock_1451794139.jpg
評論

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

透過 AWS 增加雲端技能 在組織發揮你的影響力

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

填寫表單 找到適合你的快速上雲服務與工具!

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

打造第一個你在 AWS 上的應用程式

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

了解更多:AWS 開發者系列