起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何從零規劃一個解決方案級產品矩陣（二）
在沒有完整產品規劃經驗的情況下，如何從零規劃一個解決方案級產品矩陣？本文從制訂產品路線圖和產品設計功能兩個維度出發，總結相關經驗方法，希望對你有所啟發。
一、制訂產品路線圖
1. 資源約束下的范圍裁剪
至此，我們已將智慧能耗解決方案的實現路徑有了基本概念，下面就開始根據戰略愿景開始第一階段的產品設計。但第一階段需要并行完成計量與采集的前端設備，IoT平臺，設備管理平臺，以及能耗管理平臺，工作量依然龐大。公司資源特別是軟件資源無法覆蓋，必須對范圍及功能進行裁剪，否則會變成一個裹腳布項目。
智能硬件部分，策略是利用之前的技術積累，將之前的預研成果進行排列組合，快速實現硬件 demo。后期再針對上層應用需求，調整升級嵌入式程序。極大減輕硬件部門壓力。
IoT 平臺簡化為僅保留基本功能的后臺服務，南向對接公司內部硬件，北向對接能耗管理應用平臺，功能上簡單實現設備上下行數據接入與協議轉換，數據上打通應用軟件與智能硬件。后期根據市場及公司資源情況，再考慮是否將其升級為通用型的 IoT 服務平臺。
將設備管理拍扁，簡化為基本的設備資產管理并入能耗管理平臺。將有限的應用軟件團隊，全部投入到最核心也最復雜能耗管理應用平臺。
通過以上裁剪，將第一階段的戰略目標轉換為下圖所示的三層簡結構。軟硬件團隊互為黑盒，獨立并行開發，中間通過輕量的數據服務提供橋接，形成數據閉環。
現在，項目團隊在懷揣方案全景的前提下，可以各自輕裝急行了。
2. 目標用戶的核心場景分析
自此，已完成從行業，到企業，再到項目的頂層設計。現在，我們將拿起擴大鏡，對具體業務場景進行更細致的觀察分析，識別出典型需求，進而開始功能規劃。
通過市場調研分析，我們把用戶使用場景，按是否計費與是否實時監控兩個維度，劃分為如下 4 個象限，并對對能耗管理典型場景的核心述求進行的簡單勾勒。
數據遠程采集及基礎數據接入場景： 如貨場，倉庫等，此場景下，只需對表端數據進行遠程采集，僅提供原始數據在線顯示及設備資產管理，系統不參與任何業務處理。這是最簡單的使用場景，涉及的系統功能為基礎功能，其它場景也需要使用。
自管物業等能耗抄收場景： 比如水電自管的老舊小區，公寓出租物業等，此場景下，存在管理方與使用方。管理方需要對使用方信息進行管理，對使用方的水電氣熱消耗量進行計量及收費。分戶計量及費用收繳是其主要訴求，設備運維不太關注。系統目標是覆蓋多種收費場景，兼容水電氣熱多種表計，做到采集，計量，計費，收繳費自動化。
商場園區等綜合能耗管理場景： 商業園區場景下，同時存在收繳費及能耗設備監控的需求。希望在一個平臺對水電氣熱用量及費用進行統一管理，同時對節點設備進行監管，但設備監控的實時性與復雜性工業能耗監控低得多。
- 對水電氣熱多類型表具的運行健康進行監控
- 對設備端異常狀況進行報警及管理
- 覆蓋二級抄表市場一表一戶，一戶多表，公攤，等商務租賃場景
- 兼顧后付費用戶與預付費用戶的遠程抄收繳費。
- 自動抄收，自動賬單，線上線下繳費支持。
- 方便用戶自助查詢繳費充值。
- 對能耗數據進行分級分時多維分析
- 成員及權限管理
工業能耗監控場景： 此場景下，主體是同一企業，目標對重點區域，重點設備能耗及運行等監控，無內部租戶概念，不涉及收繳費流程。因業務需求，可能存在多種非能耗設備的接入需求，從而形成一整天監管系統。此場景下，能耗監管，設備狀態特別是異常狀態監控是其主要訴求。系統目標是事前預測，事中監控，事后分析。
- 設備實時監控及管理
- 異常狀況報警及管理
- 運行參數捕獲分析
- 能耗分級分時多維分析
- 數據可視化展示
3. 構建核心業務概念模型
我們將能耗管理典型業務環節進行抽象，得到如下概念模型已便于觀察分析。模型中紅色矩形為關鍵業務實體，矮圓柱為關鍵數據，連線為他們間的關系。
通過觀察分析發現，能耗管理的業務本質是數據管理，其核心業務可抽象為三條數據流。
- 一條是由設備檢測的實時能耗數據和硬件檢測點的時空坐標所構成的，水電氣熱消耗量的時空數據流。這是研究能耗區域與時間分布的主線，能為企業生產銷售上的分析決策提供時空上的四維視角。
- 一條是由計量點位的用戶歸屬，及歸屬用戶所對應的計量計費方案，所構成的能耗費用數據流。計算能耗經濟成本，主要依賴這條數據流。
- 一條是由設備狀態，監控事件，環境傳感等實時數據流構成的，設備監控數據流。對設備運行的監控，主要依賴這條數據流。
以上三條數據流，分別對應1,2,4象限的應用場景中的核心業務。三條數據流合起來，就構成了第三象限的核心業務。我們將上述洞察豐富到概念模型上，于是構建出如下識別度更高的概念模型，用以指導進一步的產品設計。
4. 產品路線圖
通過對典型場景下業務概念模型的進一步分解與取舍后，得出第一階段的核心功能范圍，制定出如下產品路線圖，用以指導后續設計研發工作。
二、設計產品功能
1. 設計功能結構
現在讓我將視角再切回起點，提出智慧能耗解決方案的原因，是因為市面方案存在架構老舊，兼容困難，業務割裂，數據孤立，擴展受限，售后及維護成本高昂等問題。
而我們的方案定位，是提供一套軟硬件一體，水電氣熱綜合管理，抄收繳管一條龍服務，后付預付全覆蓋，能耗數據全打通的一站式解決方案。能耗管理云平臺的設計目標就是解決現狀問題，實現方案定位所設定的目標。 在進入功能設計之前，我們需要確定一個相對靈活的系統結構，這個結構需要有如下特點：
從上述要求出發，兼顧預留后期擴展的基礎上，對智慧能耗系統進行拆分。以使用人員的類型差異為拆分線索，將智慧能耗系統劃分為商戶管理端，企業業務管理端，用戶遠程查繳費客戶端。其中企業業務端暫時只實現 web 版，后續再行實現移動版。這是極簡關系架構關系圖。
各端的目標用戶及大致功能描述如下： 商戶管理端： 目標用戶為我司及其它具備客戶承接能力的表具廠，系統集成商，渠道商等合作服務商。提供設備管理，客戶管理，客戶設備類型及功能配置等管理功能。
企業業務管理端： 目標用戶是『園區物業管理方』等我方或服務商客戶。提供用企業內部能耗用戶管理，能耗設備管理，能耗數據的遠程抄收，費率配置及費用收繳業務，并提供數據分析及報表下載等管理功能。
用戶查繳費應用： 目標用戶是能耗商戶下屬的終端用能用戶。提供用戶自行遠程查詢能源使用情況，繳費賬單及遠程充值繳費等業務。減少企業及其用戶的交易成本。
將系統結構與功能范圍結合，制訂出如下功能結構圖。圖中不同顏色代表功能的不同優先級。藍色優先級最高，其后依次為青，橙，黑，灰。
從上述認知的基礎上，做進一步分析梳理，設計了各端權限控制及數據流轉架構。
2. 設計數據基座
有了前面工作的鋪墊，現在開始進入具體的業務設計。在進入具體業務設計前，讓我們再次觀察之前所抽象出的業務概念模型。不難發現，這是一個典型的，由數據驅動的 AIoT 業務流。
全部業務由紅，綠，黃，紫四條數據鏈組成，覆蓋了四種典型的業務場景。其中紅色數據鏈是關鍵數據輸入。其它三條數據鏈都是在紅色數據鏈的基礎上，輔以不同業務規則而發展出來的數據應用。
也就是說，紅色數據鏈是整個業務的數據基座，我們需要確保它的健壯性，挖掘它的可能性。
紅色數據鏈的外部輸入是各類傳感與智能設備。我們通過“設備檔案”，記錄設備的類型，歸屬層級，網絡類型，關鍵參數等數據，為后續構建設備的節點網絡進行數據構建。
每個設備節點都有獨立 ID，而它們上傳數據都會帶有時標，也就是說，每個設備節點都是一個天然的時序數列發生器。而每個智能設備都會有一個物理上的安放點或檢測地點。這樣我們就能將設備上一維的時序數據，關聯上三維的空間數據，升維成四維的時空數據。
我們引入了“最小計量區”這個概念，用來代表具體設備的檢測點，并關聯空間坐標。因為我們關注的是園區管理，需要更細的空間劃分。所以在地理位置的基礎上，進一步拓展出樓棟/樓層/區域三級空間維度。結合行政區劃上的省/市/區縣/鄉鎮/村組，我們構建了 8 級空間，用于以后的數據切片及分層統計。
通過上述方式，我們已經將設備上的單一的原始數據加工成有6個時間深度（年月日時分秒），8 個空間深度，帶48 個切面的原子數據。再加上節點網絡維度的劃分。我們有了一個可能性極大的數據基座。
下面以智能電表為例，說明下紅色數據鏈的在實際系統中的加工過程。
3. 設計業務實現方案
之前，我們通過是否計費與是否實時監控兩個維度，將紛繁復雜的業務場景劃分為了四個場景類型。并抽象了關鍵業務模型，提煉出了 4 條數據鏈。同時將設備輸入通過紅色數據鏈加工成了數據基座。下面，我們將在數據基座的基礎上，開始具體業務實現方式的設計。
這里選擇既有設備監控又需計費的商務園區場景為目標，進行能耗業務設計。因為這個業務場景，涉及到數據基座中的全部數據鏈的使用。完成這個場景的設計后，其它 3 個場景，只需此基礎上配置各自的業務規則，就可以完成各自的業務設計。為簡化問題，我們將設備這塊內容折疊變換將核心業務抽象為如下模型。
從模型中可以看出，統計最小計量單元的實時用量，就能得出不同區域在不同時段用量。通過查詢用戶使用區域，就能統計到用戶的耗能情況。通過計費規則與出賬規則的計算，就能得到用戶賬單費用。
大的邏輯是這樣的，但實際情況遠比這復雜。就拿支付賬單舉例：商務園區場景下有先用后付及預付后用兩種業務形態，支付方式可分線上與線下兩種方式。同時因為管理方式不同，預付業務有充值及退還，費用不足提醒，透支額度授予，自動閥控反制等業務管理需求；后付業態有滯納賬單等罰性手段等業務管理需求。下圖是對能耗費功能的大體描述。
拆分到上面這個程度，我們已經對這塊的業務建立起了總體印象，對后續功能的總體走向有了把握。但認知還是停留在宏觀層面，業務邏輯的顆粒度太大，不足以指導系統開發。需要進一步細化挖掘，才能形成對業務的微觀層面的理解，最終提煉出實現業務的關鍵路徑，進而設計出對用戶真正有用的功能。
下面抽出付費模式這個業務點舉例，其進一步細化分析如下：
后付費模式（1:1，1:n，n:1）：
預付費模式（1:1）：
通過上述的細化分析后，我們才真正認識到實際場景下用戶需求的多樣性，才能設計出覆蓋全面，從容應對多種業務場景的能耗收費功能。而不是一個漏洞百出，需要頻繁打補丁才能運行的收費模塊。
綜合上述分析與業務模型，與設計按用戶類型配置個性收費方案的功能，覆蓋典型業務場景下的所有業態。對于無需收費的內部能耗監控場景，不配置收費方案即可。
對于需要收費的場景，我們提供自動抄收，自動出賬，自動扣費，遠程繳費，以及自動催收，自動閥控等自動化能耗計量計費及收繳一條龍服務。并且覆蓋了水電氣熱多種能耗類型。
文章內容較長，將分成三個篇章輸出。后續篇章會在上述內容的基礎上，對 2B 類產品的 PRD 輸出示例與項目總結等內容進行輸出。
本文由 @李金堯 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
作者你好，看了你的文章，覺得總結得很系統和精煉，能否聯系您為我們的產品進行交流，價格可雙方協商
大佬，s端中的商戶管理中的商戶 就是b端的企業嗎？
你好，是SaaS系統。S 端被管理的商戶就是 B 端企業賬號。
感謝大佬解惑
大佬，看你分為三類用戶，還有個商戶管理端，你這個產品是一個SaaS化的產品嗎？
都是干貨！求更新！
可以分享一下原圖嗎？好幾張圖看不清了
這里主要是分享思考思路，里面圖片沒特意設計，部分不太清晰也是刻意為之，原因是有些可能涉及業務內容。實際項目中涉及的文檔比文章描述的多上一個數量級，同樣是上述原因，設計細節不便公開。
理解，感謝！
厲害 很細致