互聯(lián)網(wǎng)產(chǎn)品，本質是一種高效的滿足用戶對數(shù)據(jù)進行增、刪、改、查等需求的方式和載體。
SaaS，適應云時代而生的一種產(chǎn)品形態(tài)。只需要一個瀏覽器或者客戶端即可以完成所需的數(shù)據(jù)流轉。
企業(yè)級SaaS，適用于大規(guī)模協(xié)同，實現(xiàn)多角色多組織之間共同對數(shù)據(jù)進行增、刪、改、查的產(chǎn)品。
隨著參與角色的增多，發(fā)生事件的增多，企業(yè)級SaaS除了在滿足業(yè)務需求的前提下，更要注重滿足管理需求。企業(yè)級SaaS中的數(shù)據(jù)中心，即是滿足業(yè)務需求，也是滿足管理需求。
以下六步可以大致的幫助產(chǎn)品經(jīng)理來搞定數(shù)據(jù)中心的規(guī)劃與設計（為了將方法論更具象的表述，我會以智能客服SaaS來進行業(yè)務場景的舉例）。
（一）明確需求
B端產(chǎn)品需求獲取的辦法有很多，我總結了大概有四種，包括觀察法（看業(yè)務方的實際工作場景）、訪談法（詢問業(yè)務方實際工作中的需求點）、角色扮演法（有條件的去實際操作幾次業(yè)務流）、經(jīng)驗萃取法（通過思考把感性的經(jīng)驗量化）。
這四種需求獲取的方式在深度上依次遞進，看、問、體驗、思考。想做好B端產(chǎn)品，就很難將產(chǎn)品范疇的工作與業(yè)務范疇的工作割裂開，如果說C端產(chǎn)品講究用戶思維，那么做B端產(chǎn)品一定要有業(yè)務思維。
管理中常常提到HR要懂業(yè)務，其實產(chǎn)品經(jīng)理也是一樣，要能聽到炮火聲才能知道仗怎么打。
然而很多時候產(chǎn)品經(jīng)理獲取需求的辦法是——看看競品有沒有。
這并不是最可怕的情況，因為追趕競品也是一種不容易犯錯的辦法。
最可怕的是一不懂業(yè)務，二不看市場，憑既有經(jīng)驗去臆想需求。
企業(yè)級SaaS的業(yè)務方一般有一線人員與管理人員兩種角色，經(jīng)過對這兩種角色分別進行幾次需求調研之后，可以提煉出這些需求：
1、管理側需要實時查看正在產(chǎn)生的數(shù)據(jù)，用來進行調度或者決策；
2、管理側需要客觀數(shù)據(jù)進行統(tǒng)計和分析，用來進行流程優(yōu)化或者產(chǎn)品改進；
3、管理側需要檢查歷史數(shù)據(jù)進行問題排查和質量管理；
4、管理側可以查看數(shù)據(jù)報表或者導出數(shù)據(jù)進行向上匯報；
5、業(yè)務側需要查看工作時間內(nèi)的相關業(yè)務數(shù)據(jù)，用來調整工作節(jié)奏；
。。。。。。。
（二）搭建架構：
數(shù)據(jù)中心由數(shù)據(jù)構成，數(shù)據(jù)二字要分開來解釋，一類是日志（據(jù)），一類是指標（數(shù)）。前者是原材料，后者是衍生品。
按照時間維度數(shù)據(jù)又可以分為存量數(shù)據(jù)和增量數(shù)據(jù)，一定時間段內(nèi)的數(shù)據(jù)變化，就是實時監(jiān)控的范疇。
根據(jù)需求場景，數(shù)據(jù)中心應由實時監(jiān)控、統(tǒng)計分析、系統(tǒng)日志三個模塊組成。并且要針對不同用戶組進行鑒權。
比如有系統(tǒng)管理員權限的客服經(jīng)理可以看到整個系統(tǒng)的運轉情況，以及每個客服的工作完成情況。但是只有客服權限的一線客服只能看到整個系統(tǒng)的排隊情況，以及自己完成的工作情況用來掌握自己休息的節(jié)奏。
（三）構建系統(tǒng)日志：
數(shù)據(jù)指標的統(tǒng)計源，是系統(tǒng)日志。
系統(tǒng)日志是數(shù)據(jù)統(tǒng)計的依據(jù)。
我們首先要搞清楚有哪些數(shù)據(jù)流，產(chǎn)生了哪些系統(tǒng)日志，才能從這些系統(tǒng)日志里萃取出數(shù)據(jù)指標。
怎樣搞清數(shù)據(jù)流？
業(yè)務流的背后就是數(shù)據(jù)流，一套完整的數(shù)據(jù)流，包括角色節(jié)點、流轉規(guī)則、表單數(shù)據(jù)。系統(tǒng)中的用戶角色有哪些，他們之間的數(shù)據(jù)交互是怎樣的，有哪些表單數(shù)據(jù)產(chǎn)生了，搞清楚這些，數(shù)據(jù)流就搞清了。
一般企業(yè)級SaaS都有多個角色，包括visitor 、user、vip、admin等。我們要搞清楚系統(tǒng)業(yè)務側的服務對象是誰，管理側的管理對象是誰。數(shù)據(jù)中心的本質是記錄業(yè)務側的生產(chǎn)數(shù)據(jù)，為管理側提供決策服務。
哪些系統(tǒng)日志需要被記錄下來？
不是所有的系統(tǒng)日志都需要在數(shù)據(jù)中心里體現(xiàn)，只有跟業(yè)務相關的數(shù)據(jù)才有價值。
比如，用戶與客服的對話記錄、用戶排隊時間、客服響應時間等等是需要業(yè)務側和管理側關注的，但是每條query的傳輸時長，控件的觸發(fā)時長，系統(tǒng)的qps等這些后臺日志，與業(yè)務關聯(lián)度低，所以不用出現(xiàn)在數(shù)據(jù)中心。
這里要解釋一下我對前臺和后臺的界定范疇。
拿客服SaaS舉例，用戶與客服對話的界面相對于客服側屬于前臺，客服工作的界面相對于用戶側屬于后臺，相對于管理側屬于前臺。
整個客服系統(tǒng)相對于產(chǎn)品經(jīng)理來講又都是前臺，支撐客服系統(tǒng)的底層架構才是后臺。這里指的后臺日志，是指底架構的后臺日志，而不是客服系統(tǒng)的后臺日志。
系統(tǒng)日志是數(shù)據(jù)統(tǒng)計與分析的基礎，數(shù)據(jù)統(tǒng)計的指標項取決于系統(tǒng)日志里是否包含這些字段。比如要查看用戶咨詢量的趨勢，但用戶進入時就沒有加時間戳，那顯然就只能呵呵了。
產(chǎn)品經(jīng)理要根據(jù)業(yè)務場景把所需要的字段梳理出來給工程師進行開發(fā)，對于工程師來講，他們專注的是工程質量，而不是業(yè)務場景。這里并沒有什么約定俗稱的事情，文檔里沒有的，就默認為沒有。
產(chǎn)品經(jīng)理要把每個字段的含義與取用規(guī)則寫理清楚，寫明白。具體的實現(xiàn)由工程師來完成。
以客服SaaS為例，核心的數(shù)據(jù)流是用戶與客服的對話，那么根據(jù)業(yè)務場景每一組對話應該有如下字段應該被記錄下來：
對話ID/對話內(nèi)容/來源渠道/用戶ID/問題類別/客服ID/對話狀態(tài)/開始時間/結束時間/用戶評價/等待時長/是否被轉發(fā)
工程師會把這些字段組成一個表單，字段不同，表單也不一樣。
再比如，應用人工智能技術的客服系統(tǒng)，會有機器人客服的角色，人機對話的場景就會有區(qū)別。這些字段就需要被記錄下來：
queryID/來源渠道/用戶ID/時間戳/query/機器人回復/匹配度
這些表單就組成了系統(tǒng)日志部分。每一個字段都可以作為篩選項，也可以通過一定條件對表單進行排序。一般會取時間戳作為排序條件，ID類字段作為查詢條件，其他字段作為篩選條件。這些條件構成了系統(tǒng)日志所需的查看方式。
（四）數(shù)據(jù)指標項的設置與分析：
系統(tǒng)日志搞完了，原材料就有了，那么數(shù)據(jù)指標應該怎樣設置呢？
指標項可以根據(jù)統(tǒng)計方式不同分為，計數(shù)項、運算項、時間項。
計數(shù)項：每個字段其實都可以作為計數(shù)項，是一種絕對值計數(shù)。例如對話數(shù)。
運算項：一種情況是兩個或兩個以上計數(shù)項進行交叉運算得出的值，比如求和，求差，求百分比，求平均值。例如用戶對客服的滿意度。
另一種情況是這個字段本身的屬性就是一個值，而不是文本。
這種情況常見于財務系統(tǒng)，例如基本工資這個字段。那么基本工資這個字段就可以作為序列項進行運算，比如拿月份作為分類項，年度基本工資總數(shù)，月度基本工資漲幅，單月基本工資占全年基本工資的半分比就是運算項。
時間項：一般指時長，利用相應的時間戳算出來的。可以是正計時，也可以是倒計時，還可以是累計時長。例如用戶等待時長。
這些指標項又該怎樣去分析呢？
根據(jù)業(yè)務場景選擇相應的字段作為篩選項，看這個字段涵蓋數(shù)據(jù)的計數(shù)項或者運算項，就是分析的范疇。
例如選擇問題這個維度，看不同問題分類所屬對話的分布，就可以看出哪一類問題是熱點問題。
應付復雜的業(yè)務場景，不僅要支持分維度，還要支持分類別。還是拿智能客服系統(tǒng)舉例子，統(tǒng)計分析可以分為對話維度、問題維度、渠道維度、又可以歸類為系統(tǒng)，客服，機器人三個類別。
具體的指標項設置和分析，是行業(yè)方法論的范疇。產(chǎn)品經(jīng)理想要做好一個行業(yè)的SaaS，成為這個行業(yè)的業(yè)務專家是必要的。這些數(shù)據(jù)項按照時間維度構成的表單，就是統(tǒng)計分析部分。這部分的交互要支持靈活的篩選。
（五）可視化設計：
滿屏堆表單，不是一個好產(chǎn)品。我們要進行合理的可視化呈現(xiàn)。
數(shù)據(jù)可視化的方式有很多，網(wǎng)上有關于這方面比較成熟的方法論。圖表類型的選擇，我就不在這里過多敘述。我要補充的是產(chǎn)品經(jīng)理如何寫一份可視化需求的文檔交付給設計師和工程師。
其實很簡單，每個圖表的背后都是一個表單。
文檔里要包含以下幾點要素：
1、圖表類型，例如趨勢圖、餅圖、雷達圖等。
2、分類項（X軸）的定義，例如取用哪個表單里的哪一個字段數(shù)據(jù)，或者直接用年月日時分秒。
3、序列項（Y軸/Z軸）的定義，例如取用哪個數(shù)據(jù)序列的值，值的格式（分數(shù)/百分比/小數(shù)點），刻度的單位（百/千/萬）。
4、圖表標題、圖例、數(shù)據(jù)標簽。
5、最后規(guī)定出你要強調的數(shù)值區(qū)間或者數(shù)據(jù)項即可。
（六）考慮一些業(yè)務功能：
1、實時監(jiān)控
將一定時間范圍內(nèi)的增量數(shù)據(jù)（包括日志和指標）單獨作為一個模塊展示，就是實時監(jiān)控模塊。
這里可以用dashboard的設計，關鍵字段突出展示與可視化圖表相結合。
重點是要與工程師確認好刷新機制，在實時性和成本之間有個取舍。
數(shù)據(jù)項的計數(shù)一般取得是那個刷新節(jié)點的數(shù)據(jù)，類似快照的概念。
2、權限管理
不同級別的用戶組在數(shù)據(jù)中心的查看和操作權限是要有過濾的。
一般一線業(yè)務人員是沒有查看整個系統(tǒng)數(shù)據(jù)的權限，但是有些場景業(yè)務人員也要關注整個系統(tǒng)的數(shù)據(jù)流轉情況。
比如客服中心，客服也要掌握整個客服平臺的用戶排隊情況，來判斷自己的工作節(jié)奏。
這里的處理辦法是實時監(jiān)控界面要有支持全屏的設計，每個工區(qū)都可以放置電視大屏用來進行實施監(jiān)控的展示。
3、增加功能控件
數(shù)據(jù)中心除了支持查數(shù)據(jù)，也可以根據(jù)業(yè)務需求增加操作功能。
例如客服SaaS的實時監(jiān)控模塊，可以通過查看，每個客服的狀態(tài)，負荷度，正在處理的問題進度，管理員可以根據(jù)需要進行問題的轉發(fā)，實現(xiàn)人員調度的需求。在每條數(shù)據(jù)的后面加個轉發(fā)問題的控件即可。
4、支持報表制作與數(shù)據(jù)導出
方便管理側進行報表制作與數(shù)據(jù)導出。
走完以上六步，數(shù)據(jù)中心就基本完成了規(guī)劃與設計。
總結
講透一個具體的點簡單，講透一條連貫的線很難，講透一個通用的面難上加難。
這是一篇我個人從業(yè)以來在數(shù)據(jù)中心的規(guī)劃與設計上的梳理和總結，我已是盡可能的以一個通用的面的形式去闡述。這也僅代表我個人的水平和觀點，不具備權威參考性。
為了使整篇文章更加有偏重和結構，我適當?shù)陌盐樟嗣枋龅念w粒度，有些細節(jié)并沒有完整的交代，在實際的產(chǎn)品設計中，還需要產(chǎn)品經(jīng)理進行深度的思考和補遺。
高階產(chǎn)品經(jīng)理應該關注的點在于業(yè)務邏輯和數(shù)據(jù)邏輯，所以我就沒有進行原型和交互示例，有這方面需要的產(chǎn)品經(jīng)理可以私信我。
感謝pmcaff社區(qū)提供的這次交流機會（其實是給我挖了個大坑，我通宵碼了以上文字來填坑）。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://m.lukmueng.com/
相關文章
