淺談中臺服務地圖的設計

0 評論 346 瀏覽 0 收藏 24 分鐘

“中臺服務之道,地圖引領方向。” 在中臺業務建設中,隨著服務能力的不斷沉淀,如何讓業務方高效接入、讓高層理解其價值成為關鍵。中臺服務地圖應運而生,它如同指南針,為中臺服務的有效開展指明路徑,是實現中臺與業務協同發展的重要工具。

前言

此前寫過一篇《如何做好B端產品的多業務線對接》,當時對這一塊問題的答案是:

1.功能標準化建設。

2.接入服務建設。

3.合理的時間管理。

距今已有一年有余,中間也快寫了20多篇文章,這個過程中沉淀了一些新的想法,在我最近需要思考內部中臺業務建設的時候,發現原本的文章只是從“一線視角”出發去想問題,其中僅僅考慮到“對接的人力效率優化”這個點。但是如果站在更高的視角看待這個問題時,會發現在“中臺沉淀的服務能力很多時”三個未曾被考慮過的點:

1.如果中臺提供的能力服務量遠遠大于接入方的短期接入能力時,要如何安排優先順序接入?

2.業務方如何知道自己要接入什么能力?接入后能起到什么作用?

3.如何讓高層了解到我們公司中臺存在的意義以及價值?

其實這三個問題都導向了一個答案——中臺服務地圖構建。

什么是中臺服務地圖?這是一個面向中臺服務使用者的指引,需要告訴使用者:

1.我們的能力有什么?能做成什么樣?(What)

2.我們的能力能做成什么效果?(Why)

3.我們的能力能在業務的什么節點發揮作用?需要在什么時候接入完成?(When)

4.要如何接入與使用我們的能力?(How)

那么如何做好“中臺服務地圖”的建設呢?下面講講我的想法和思路。

服務內容整理

要想繪制好“中臺服務地圖”,第一步是需要清晰地知道我們的服務內容有什么,其次是知道我們的服務內容能對什么業務起到什么作用,最后才是進行服務內容整理。

第一步:盤點已有的服務內容

當我們中臺能力沉淀得比較多時,我們需要先進行業務能力的盤點,先捋清楚我們中臺部門手頭上有什么服務內容。

首先我們要定義一下中臺的服務內容,這個可以是一個系統、一個API、一個插件、一個工作流程,只要是能夠直接或間接讓中臺成員“賦能”公司業務的內容,都可以稱為“中臺的服務內容”。

大部分中臺部門都有內容wiki文檔進行這部分服務內容的沉淀,如果wiki文檔維護得好且分類清晰,那么第一步能很簡單就完成。

但是如果wiki缺漏較多、內容分散,則需要從頭開始盤起。很多人在這個時候肯定頭很大,因為一個龐大的中臺部門,其橫向和縱向的服務內容量是極其龐大。

1.橫向是指中臺部門服務范圍廣,涉及到的業務面廣,因此相關的功能、系統類別繁多。

2.縱向是指中臺部門建設的時間跨度一定很廣,必定是長達N年部門,這進一步加深盤點業務的難度。同時,由于時間跨度長,這里面會由于各種諸如“人員變動”、“架構調整”等等原因導致的歷史信息斷檔,這導致部分信息無從查起。

(比如我們發現有一個歷史運作至今的系統,但是卻發現負責系統的一線產品、一線技術都離職了,想要盤點這項服務,僅憑負責人是較難回憶起其中的細節的,只能夠通過查閱代碼 或者 進行業務訪談 才能復原其中的細節。這無疑說明其中之“高成本”。)

雖然繁瑣,但是也是有一定辦法的。

1.我們可以先梳理大頭的重點業務。重點業務往往是“最近存在版本迭代”、“業務關注度高”、“價值貢獻突出”、“持續在使用”的服務內容,因此這些內容往往內容沉淀最齊全、相關成員最完整,梳理起來成本相對較低,而且梳理這些內容的性價比往往很高。(如果時間有限,先做這一步也行。)

2.翻閱wiki補齊信息。雖然這種情況下的wiki可信度不高,但是也能從中推理出一定的服務內容,并重新收納和整理起來。

3.讓技術從代碼層面羅列系統服務項目。由于基本上所有的服務內容都會經過技術的開發與部署,因此從代碼層面是能夠對所有的服務內容進行溯源的。不過用此法羅列的服務內容會非常零散,最好能按系統、按業務進行一定程度的歸類。

4.最后,就是讓各個服務模塊負責人查漏補缺了。

第二步:了解你服務的業務

中臺部門是對公司的業務進行服務,并與之進行價值交換。所以我們需要了解我們服務的業務,其中包括業務形態、服務在業務中的價值、業務子模塊及其流程。了解這些內容是為了清晰地進行服務歸類,向業務方呈現我們的服務地圖。

我們可以通過以下方式進行這方面內容的了解:

1)業務訪談:這是一種直接的調研手段,通過與業務各層角色的深入交流來收集信息。進行業務訪談時,準備一份詳細的訪談大綱至關重要,以確保訪談過程中能夠高效地獲取所需信息。

2)輪崗實習:有時業務團隊可能缺乏全局視角。為了更全面地理解業務,輪崗實習成為了一種有效的方法。親自參與到一線工作中,可以幫助我們深入挖掘和理解業務的真實需求。

3)調研問卷:問卷調研能夠快速、廣泛地收集反饋,并在一定程度上量化問題,例如評估對某些功能的需求程度、系統滿意度等。

首先,要對公司的業務形態進行梳理。

這個過程中,我們要了解公司是怎么通過其產品/服務與用戶進行價值交換的,即“公司是怎么賺錢的”。

通過對業務模型的分析,我們可以更好地理解公司的盈利方式。

拿游戲行業舉例:游戲公司開發或者運營一款游戲,為玩家群體提供內容消耗并產生情緒價值。玩家為內容進行付費,公司從中獲取收益并持續運營或者打造新的游戲。

接著,我們要了解中臺的服務內容在公司業務中發揮的價值。

我們需要知道我們在“公司賺錢”這件事上,起到了什么作用,以了解“公司為什么給我們發工作”。

拿游戲行業舉例:按我自己的理解,我將游戲行業的業務拆解成四大模塊,整體鏈路如下。

其中各類中臺系統模塊分別起到以下作用:

1.研發相關中臺功能提效率增效果,使得游戲能快速搶占市場。

2.營銷相關中臺提供精準的玩家導流能力,把經費都花在刀刃上。

3.運營中臺支撐運營業務,滿足用戶、業務、監管方面的需求,實現收益最大化。

4.底層支撐系統,為團隊建設和其他基礎業務賦能。

最后,我們要了解各個業務方的子模塊和業務模塊的流程。

上面僅僅是對業務進行了大類的拆分,比如游戲行業拆分成研發、營銷、運營、基礎支持。但是其中每個業務還可再拆分其中的業務子模塊,比如運營可以拆分為客服、活動、用戶等運營模塊。拆分業務模塊能輔助我們更好地進行服務歸類,更好地在“服務地圖”上進行服務內容的呈現。

業務子模塊的分類方式一定程度和公司內對部門/崗位的劃分相關,一般由某個部門或某幾類崗位負責一個業務子模塊。

但同時,一個業務子模塊也有可能涵蓋非常多的中臺服務內容,因此我們需要再細分一層,即“按業務子模塊的流程”進行劃分,方便業務知道自己什么時候需要使用什么服務。

這里用“用戶運營”業務作為舉例。

“用戶運營”業務的主流程可以分為“引流”、“篩選”、“培育”、“轉化”、“維護”。我們可以按這些模塊進行歸類,比如將私域的活碼配置、預約活動發獎等功能歸在“引流”服務這一類,在業務需要的時候,能夠快速從“服務地圖”上找到。

第三步:服務歸類

當梳理完“服務與業務的利益關系”后,我們需要進行服務內容歸類。

為什么要這樣做?因為如果我們按系統進行服務內容歸類的話,有可能存在一些業務同時需要使用2~3個系統。所以在業務方接觸我們的服務的時候,容易產生疑惑,提高其中的學習成本和使用成本。

因此為了做好服務地圖,我們需要進行服務歸類,讓業務方能夠快速知道“我們的服務內容有什么”,從而并了解這些能力的效果,并展開接入與使用步驟。

在進行服務分類的時候,個人覺得可以基于前面的“業務了解”,按以下維度分類:

1.一級類別按業務大類歸類:

業務大類是從“公司業務流程”上拆解出來的類別。比如游戲行業就可拆分為“負責游戲制作的游戲研發”、“負責導入玩家的游戲營銷”、“負責維持游戲運轉的游戲運營”、“給公司運轉提供支撐的底層支撐”。

按業務大類能夠讓高層清晰地了解到中臺部門的服務布局,以及對公司運轉的輔助作用。

2.二級類別按業務子模塊歸類:

業務子模塊的分類方式一定程度和公司內對部門/崗位的劃分相關,一般由某個部門或某幾類崗位負責一個業務子模塊。

按業務子模塊進行服務分類,能向上清晰地呈現中臺部門對不同業務模塊的賦能情況。而業務的接入者往往不用關注太過于宏觀的內容,通過子模塊的分類方式,他們清晰地圈選出他們需要關注的內容,而不是從龐雜的資料中找到自己需要使用的能力。

3.三級分類按業務子模塊流程歸類:

基于“業務子模塊”的流程可以進行三級分類,這一般和業務子模塊的步驟節點有關。

按業務子模塊流程分類,能幫助業務使用者更清晰地知道自己在什么階段需要使用到什么樣的服務內容,以提前做好接入和使用的準備。

服務地圖制作

在完成服務內容整理之后,我們就完成了制作服務地圖的前置任務了,這時候我們需要開始進行服務地圖的制作。分為以下步驟。

第一步:地圖內容整理

前文提到,服務地圖需要告訴使用者以下信息:

1.我們的能力有什么?能做成什么樣?(What)

2.我們的能力能做成什么效果?(Why)

3.我們的能力能在業務的什么節點發揮作用?需要在什么時候接入完成?(When)

4.要如何接入與使用我們的能力?(How)

所以第一步,我們要基于我們梳理的服務內容結構進行“What”、“Why”、“When”、“How”的內容填充。

1.What:

我們要準備一個服務內容的說明,可以從“背景”、“描述”、“服務流程”等維度對服務內容進行說明。為了更清晰地說明“What”,我們也可以準備一個demo,這個demo可以是一個測試服的鏈接、一個線上業務的案例。通過demo,業務方可以代入其中,讓業務方親自體驗下“我們的服務是什么”。

2.Why:

我們可以從服務內容的“目的”和“作用”入手,對服務內容進行描述。但這樣難免有點空洞,因此我們可以搜集并整理功能標桿案例與收益預期。

功能標桿可以盡量選取在內部有一定知名度 且效果較為突出的項目,我們需要向業務方展示我們的服務在其中作用,以及起到的量化作用,比如“代金券功能在最近的XX游戲上輔助創收1000w,拉收提升20%”。

功能標桿一方面可以進一步解釋“服務能力有什么”(What),另一方可以讓業務方直觀地了解到服務內容的價值。如果我們選擇的標桿在公司內部有一定的知名度時,業務方在看到這個標桿時,就會豁然開朗,“哦~原來是這個~”、“原來有這么個作用~”,然后就會毫不猶豫地接入我們的服務。

如果我們是一個未有“標桿”的服務內容,則可以嘗試撰寫“收益預期”,嘗試說明接入這項服務,業務方能得到怎么樣的輔助或提升。

3.When:

這個問題可以從服務內容的“起效節點”、“接入周期”、“接入節點建議”3方面撰寫。

“起效節點”指服務內容在接入方的什么階段會發揮作用,比如項目的測試期、首發期、增長期、成熟期。

“接入周期”指服務內容的使用從“發起需求”到“正式使用”的周期間隔,因為往往中臺的服務內容需要一定的接入配置、測試聯調成本,甚至有些項目需要接入API、SDK等內容。所以我們需要對“接入周期”進行評估,以說明其中的接入成本。

“接入節點建議”是基于“接入周期”進行的接入節點預估,考慮到接入時間成本的存在,為了避免不錯過“起效節點”,往往需要提前預留大于“接入周期”的接入時間。

4.How:

關于“How”的內容,我們可以通過撰寫“接入流程指引”、“技術接入說明”、“配置說明”、“使用說明”等內容來滿足。

其中“接入流程指引”可以先說明能力接入的流程、相關節點的對接人、每個階段的具體事項,用來引導業務方接入并使用我們的服務。如果是較為復雜的服務內容接入,最好由專門的人員進行輔助接入,幫忙進行能力解答和接入指引。

“技術接入說明”則是技術層面的具體描述,需要交由技術撰寫,因此不展開。

“配置說明”和“使用說明”則需要手把手指引業務方在接入完成后進行能力的使用,涵蓋“如何正確配置”、“如何正確使用”。

第二步:服務內容呈現

當我們準備好地圖內容后,就需要考慮進行地圖內容的呈現了。個人覺得,一個合格的服務地圖需要包含以下內容。

1.基于服務歸類的能力清單:

基于我們前面進行的服務歸類,我們最多可以對服務內容分為三個等級的類別,分別是“按業務大類”、“按業務子模塊”、“按業務子模塊流程”。

因此,我們可以列出一個服務清單列表,里面匯總了所有的服務內容。就好像阿里云這里的“解決方案”的呈現方式,也是按三個大類別進行歸類。

2.充分體現“What”、“Why”、“When”、“How”的內容呈現:

用戶點開服務清單的每個內容時,我們需要對某個服務內容進行“What”、“Why”、“When”、“How”的清晰呈現與說明。

比如阿里云這里,就用圖文并茂的方式充分說明了“功能是什么”、“接入的優勢和作用”,然后通過“在線咨詢”、“聯系咨詢”可以知道“如何接入”。

個人覺得充分體現“What”、“Why”、“When”、“How”的內容有以下幾個特點:

1)描述清晰簡潔、通俗易懂:因為服務內容大多數是技術層面的內容,但是接入方卻不一定是技術。所以我們的措辭和用語盡量簡潔清晰,避免使用深奧的技術語言,且最好能從業務視角出發進行描述,最終呈現的是“業務能快速看得懂的內容”。

2)內容結構清晰:需要把內容盡量按“What”、“Why”、“When”、“How”的結構呈現,避免出現一大坨文字的情況。

3)具有充分的案例說明:前文提到我們需要準備demo和標桿案例。因為具體的事物是能夠快速幫助業務了解服務內容的“What”和“Why”,這能最大程度減少業務方不能理解的情況。

4)多模態呈現:我們可以不僅僅局限于文字,還以補充以圖片、視頻等形式,以降低理解的門檻。

3.提煉重點服務的首頁:

當服務內容過多時,如果直接把過多的內容直接塞給業務方,業務方還是會一下子覺得頭痛。因此我們需要設計一個“提煉重點服務”的首頁。

這個首頁需要對服務內容進行篩選,將高價值的、必接的、高頻的服務內容提煉出來,再按一個清晰的結構進行呈現。如此,便可解決文首提到的“如果中臺提供的能力服務量遠遠大于接入方的短期接入能力時,要如何安排優先順序接入”問題。

比如微信小游戲的能力地圖,就是按常用能力進行了匯總和梳理,接入方可以快速或者自己最需要接入的內容。

此外,首頁還可以引入推薦功能,結合接入項目的類型、階段、狀態,推薦適合他們的服務內容,從而實現“需求與服務”的精準匹配,極大降低其中的對接成本,并快速發揮中臺的服務價值。

后續的運營

以上步驟就基本完成了服務地圖的建設,但是這并不意味著相關工作的完結。因為中臺的本質是“沉淀”和“復用”,服務地圖只是“沉淀”和“復用”的一種展現形,我們還需要進行后續的持續運營。

我們需要配合業務在實踐中沉淀的“優質方案”,從而形成一定的服務內容沉淀,總結歸納到我們的“服務地圖”中,再以此賦能到更多其他的業務上。

持續運營的動作構成了一個循環,這個循環可以稱為“中臺服務增長飛輪”,我們的服務地圖建設和后續運營需要以構建“中臺服務增長飛輪”為目的,以最大化中臺系統的價值。 小結

以上便是個人針對“服務地圖”構建的一些思考了。服務地圖的存在,能在中臺發展到一定階段的時候,更好地向業務、向上級傳達中臺的能力和作用,并幫助中臺部門在后續構建“中臺服務增長飛輪”。

本文由人人都是產品經理作者【檸檬餅干凈又衛生】,微信公眾號:【檸檬餅干凈又衛生】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!