奧推網

選單
歷史

Saas中臺架構以及中臺設計——Saas產品之路(4)

編輯導語:中臺這一概念在前幾年引發了大量企業的關注和投注,然而,什麼樣的中臺才能算是好的中臺?關於這個問題,也許你可以從功能模組、業務形態等多方面進行解讀。本篇文章裡,作者發表了他對中臺設計的看法,一起來看一下。

從18年起,國內一眾大廠都掀起了中臺風暴,而做著做著卻發現——“嘿,中臺也能賺錢!”阿里雲/騰訊雲/火山引擎等都是大廠業務中臺化的產物,演算法中臺/商業中臺/功能中臺等拔地而起,在那個時間點下,無論是為了企業降本增效或者是純粹的模仿,很多網際網路企業紛紛跟風跟進中臺戰略。

大廠做中臺戰略合情合理,即能滿足業務多元性發展的需求,也能降低企業生產成本,最重要的是——透過中臺戰略內部孵化出來的服務能向其他企業提供,

中臺是一門生意。

SaaS產品就是從中臺概念中脫胎出來,透過SaaS接入的形式實現免開發以及快速介入,這裡不妨思考:

SaaS需要怎麼樣型別的一種中臺?SaaS如何透過產品設計快速實現中臺?

在回答上述的問題之前,我們要先下個定義——怎樣才算是好的中臺?

一、什麼是好的中臺?

首先我們把眼光挪到20世紀60年代的美國,隨著汽車工業的計劃以及汽車的普及,當時的汽車製造商所面臨最大問題是——

造車的成本為什麼會這麼高?為什麼我新造一輛車就需要重新設計底盤/動力傳輸這些看不見的東西?

於是通用公司就提出了造車平臺概念,即不同的車型可以用一個平臺上相同的底盤/發動機/變速箱等系統,透過外觀/內飾等設計快速實現產品上新以及差異化,我們可以理解這就是汽車行業的“中臺”,支撐了通用/大眾等汽車廠商旗下眾多產品線的快速發展

我們不妨將眼光擴大,不僅汽車行業,其他的行業是否也有類似的中臺設計?這裡要引入一個傳統制造業的概念,叫

“柔性製造”。

不同於傳統按需生產的剛性生產法(先有需求,再有產品;一條生產線只能生產一種產品),柔性製造最大的區別就是透過組合多個模組化的生產機床以及配置自動運送的生產線搭建,實現單一生產線能生產不同產品,從而實現邊際成本的降低和快速麵對市場的反饋

柔性製造概念中有一套評判生產是否柔性的標準——

機械柔性:支援加工不同零件;

工藝柔性:隨著材料變化能變化對應的工藝流程;

產品柔性:對老產品能相容,能快速生產新產品;

生產能力柔性:生產量變化時,整體系統能快速做出反應;

維護柔性:能快速查詢和定位故障,保證生產執行;

拓展柔性:支援快速擴充套件和增加模組,構成更大的製造系統。

柔性是對生產能力、生產工藝以及對應的產品提出了可拓展、可相容、可變化的需求,是對如何快速麵對市場的變化以及使用者需求的變化,同時在競爭中保持優勢地位,這是企業生存的長期思考命題,“中臺”是長期思考中得到的一個標準解

19世紀80年代營銷大師邁克爾波特提出了營銷三大競爭戰略:成本領先/差異化/集中化戰略,而“中臺”正好契合了競爭戰略內的核心因素——如何降低生產成本/如何提升新品生產週期,所以

“中臺”是一個產業高度工業化和市場化的體現。

基於工業在中臺上的建設經驗結合網際網路生產特性以及商品特性,好的中臺有以下的性質——

模組化:透過業務模組化能降低新業務的投入成本;能快速跟隨業務的變化而變化,支援快速搭建新產品新業務或者進行業務調整;

可擴充套件:隨著業務的發展,中臺能容納更多的能力,為業務承擔更多的基建壓力或者供應壓力;業務方在中臺能力的基礎上實現自定義能力建設;

標準化:標準化的中臺產品能降低業務接入成本,常見的標準化形態包含——h5外掛/jssdk/sdk/介面/SaaS等;

可相容:能相容以及支援多類不同業務,實現多類業務的並行使用。

所以,工業化給出了兩個解決方案——

“汽車平臺式的中臺”——大中臺;

“模組化的中臺拼接”——小中臺。

二、SaaS產品“大小中臺”策略

而這兩類中臺策略分別使用於哪種型別的產品,我們需要從SaaS產品的架構以及商業模式進行分析。

目前市面上看到的SaaS通常會有以下3類:

業務型SaaS:為客戶的賺錢業務提供工具以及服務的SaaS,直面的是使用者的生意,例如有贊微盟等電商SaaS以及銷售CRM工具,為B2B2C企業;

效率型SaaS:為客戶效率提升工具的SaaS,如專案管理工具、Zoom等會議工具,提升辦公或者生產效率,為B2B企業;

混合型SaaS:即兼顧企業業務和效率效用SaaS,例如近幾年在私域流量上大做文章的企業微信,其本身就是一個辦公協同工具,但為企業提供了一整套的私域管理能力,實現業務的提升,同時也支援第三方服務。

1. 業務型SaaS的架構以及商業模式

縱觀業務SaaS產品的發展方向,在產品的成長期階段,為了擴充業務規模和體量,業務SaaS產品會拓展為“多場景+多行業”的產品模式,為不同行業或者不同場景提供適應的解決方案,例如做電商獨立站的有贊,後期發展為“商城、零售、美業、教育”多行業的解決方案進行售賣。

我們縱觀有讚的產品結構,都是以商城為核心,相容不同行業的產品需求所構築而成,像商品體系、計費體系、店鋪裝修、人員管理、營銷功能等通用性強的產品模組對有贊而言就是一個個打包好的積木,在積木的基礎上拼接新的積木就能得到新業務新解決方案。

例如教育需要的線上內容模組、美業需要的線下會員管理方案等等,業務的SaaS更像積木,透過一塊一塊中臺的拼接就可以實現新產品的開發,屬於“樂高式”的中臺模式。

所以業務性的中臺更加適用於“小中臺”模式,透過模組組合加速業務發展。

2. 效率型SaaS的架構以及商業模式

效率SaaS從企業需求來說是“對症下藥”型別,不同於業務型的SaaS,效率SaaS思考得更多的是企業記憶體在一個大共性的效率的問題,不同的企業對於CRM銷售系統的需求是不一樣的,但都需要一個協同辦公的產品來提升協作效率。對於效率類SaaS來說,從哪來到哪去是非常清晰的,就是要解決最佳化或者解決一個流程上的問題。

所以此類初創期的關注點在於產品流程的閉合,產品體驗的完善,往往不關注細分行業在相同功能上的差異性,例如針對網際網路公司的專案管理軟體的SaaS工具,在軟體設計前期是不會涉及到交付型別公司以及toC公司的專案管理差異。

而成長期,會在基礎產品上增加不同功能以滿足不同使用者的需求,像知名的設計協作軟體藍湖,就在本身產品的基礎上針對教育行業、網際網路、金融行業的客戶輸出了不同的解決方案,不同於業務型SaaS,效率SaaS在中臺設計更底層和基礎,底子打造完成,換上不同的衣服就考驗滿足不同使用者的需求,屬於“換殼式”的中臺模式。

效率型的SaaS更加適用於“大中臺”模式,透過拼接不同的套件,實現多個行業的切入。

3. 混合SaaS

混合SaaS是業務和效率SaaS的結合體,負責企業業務以及企業管理流程的某類場景上的降本增效;因混合SaaS核心業務的使用場景是清晰且通用的,非核心業務是近似於錦上添花的存在,所以在中臺產品架構上更接近為“1+X”組合方式——即1個核心業務+X個非核心功能,兩者在產品層級上是屬於同一層級的。

所以非核心業務在混合SaaS的商業化中是比較邊緣的存在,首先企業難以花費太多精力研究非核心業務,其次是通用的核心業務客群寬泛而非核心業務的客群狹窄,研發成本高昂,所以很多混合SaaS平臺均採用開放平臺的形式,接入第三方的功能服務,無需自行開發,作為中間商實現盈利變現。

所以從產品架構上而言,混合SaaS與業務SaaS接近,中臺結構更貼近業務的形式。

為了實現大小中臺的架構,我們在產品設計如何透過中臺化來實現中臺目標?

三、功能中臺化

人活這一世,能耐還在其次。有的成了面子,有的成了裡子,都是時勢使然。

——宮寶森《一代宗師》

在電影《一代宗師》中,王家衛借劇中人物宮寶森之口,用裡子和麵子等討論了拳術、社會和門派的表裡關係。

在網際網路語境內,面子就是使用者所能接觸的前端(表現層與框架層),而裡子是支撐起這些表皮的後臺(架構層和範圍層)。

對於SaaS工具而言,中臺不僅包含每個業務模組,更重要的是如何透過產品設計實現業務模組的中臺化,所以在產品層面會有兩個重點的思考方向。

降本——針對新場景/新客群的新產品建設;

增效——一個功能如何制定中臺策略。

針對這2個思考方向,我們可以得出如下的設計原則。

1. 元件化設計

元件化是對功能進行封裝以及介面建設,對於主要服務於中臺有2個意義:快速接入以及重複呼叫。

例如使用者能在抖音消費到圖文、影片和直播等內容,而抖音的內容創作平臺是覆蓋了從內容生產→內容呈現→內容分發(演算法)→內容變現(支付&廣告)→粉絲管理→結算等流程。

元件化在流程中扮演什麼角色呢,透過對內容分發以及內容變現模組的元件化,抖音就只需投入成本在內容的生產以及呈現模組上,像內容分發、內容變現等功能透過一個介面或者頁面呼叫就可以快速接入,從而實現新業務新產品的快速建設。

2. 業務性對功能設計的影響

在設計中臺產品時,需要對功能的業務性進行評估。

產品的業務性是指某個產品是否可以獨立存在,例如一個紅包功能,表面上是一個獨立的功能模組,但紅包在實際的使用中非常依賴前端的場景建設以及支付體驗,例如微信紅包是社交場景,而支付寶的紅包是商家服務的場景,所以紅包的業務性比較低。

那像紅包此類的業務性低的產品如何進行中臺設計?

不封裝前端內容:實現前端自定義互動以及頁面,更加通用;

做介面呼叫以及資料儲存:支援不同業務不同終端對功能的需求,更加相容。

而對於業務性很強的產品,如一個專案管理功能,可以單獨使用也可以與其他場景進行結合,例如搭配工單缺陷系統,就能組成一個面向網際網路行業的新產品。所以在業務性很強的業務內,如何實現核心業務對於其他能力的快速支援以及資料流轉——

為流程上下游的功能模組提供通用的呼叫以及建立規則:如一個導航功能——生成最優路線以及計算時間,本身業務性可以與地圖功能很好的連結,但其他場景也充斥著大量的導航場景,如打車場景、外賣場景、運動場景等,但導航的演算法永遠只有一個,所以在導航功能的中臺設計上是提供一個建立以及資料同步介面,實現演算法最佳化以及資料沉澱。

業務功能與業務功能之間應該相互獨立,不耦合:不同業務的資料儘可能透過介面實現,在產品設計上儘量不耦合。

以上就是關於中臺產品的設計思考,希望大家可以在評論區留言討論,謝謝指教。

本文由 @朋克Penk 原創釋出於人人都是產品經理。未經許可,禁止轉載。

題圖來自Pexels,基於CC0協議。