中臺產品經理寶典04:企業級應用設計框架
編輯導語:企業級應用設計對于解決企業內部不同部門間的業務訴求十分重要,本篇文章作者分享了企業級設計應用的設計框架以及具體設計步驟,詳細地講述了企業級應用設計的相關內容,一起來學習一下吧,希望對你有幫助。
一、企業級應用定義
在介紹企業級應用設計流程之前,我們首先要明白什么是企業級應用。
所謂企業級應用就是指那些提供給大型企業內部使用的軟件系統,而這些軟件系統的一個典型的特征就是,企業級應用不僅僅解決一個具體的業務問題,而是要解決一個領域在企業內部不同部門間的所有業務訴求,故此企業級應用往往需要橫跨多個模塊。
例如企業訂單管理系統(OMS),就是將企業內部所有業務的訂單進行匯總至一處進行統一管理。
再從側面理解,與之相對的是各業務線內的一個個業務系統,只且僅解決某個具體的業務問題,這二者關系如下圖所示。
例如業務線中的訂單,首先在業務系統中將訂單接收,隨后傳導至企業的OMS中進行統一匯總,由OMS進行統一透傳與路由至下位系統。
二、企業級應用設計框架
講完了企業級應用的定義后,接下來我們就來談下具體的設計框架。在我的《中臺產品經理寶典》一書中我曾提出過一個面向企業級應用設計的通用MSS模型。
這里最核心的部分可以被摘錄為如下圖的四步:
接下來讓我們一個個展開來看:
1. 步驟01:需求梳理框架
這里需要注意的是,不同于業務系統我們需要將整個領域的完整需求梳理出來。
在領域梳理的范疇中我們需要掌握兩個邊界:業務邊界,系統邊界。
1)業務邊界
按照領域梳理業務需求時,最關心的便是領域到底有多大?例如訂單領域,庫存領域。
我們在這一步要做的就是清晰的理出訂單的生命周期到底是什么?雖然我們要整理整個訂單領域,但是我們頁不可能一味的讓一個訂單系統去管理所有與訂單相關的事務。
例如,在訂單管理的履約環節,雖然預約是嚴格按照訂單的要求進行執行的,但是在此時我們不應該去以訂單在下游系統中流轉。
而是應該生成對應的出庫單或履約單據,由他們去全新開啟一個新的領域的工作,而在他們工作完成之后,只需要將工作結果也就是送達結果回傳給訂單。
這樣就將我們的訂單業務邊界做了清晰的劃分:
這里梳理業務邊界我給大家一個方法:根據業務場景種類來進行劃分,各類場景獨立切分。
例如訂單就是用戶場景內的產物,而庫內作業是企業內部倉庫場景這兩者就應該劃分開并獨立由不同系統承載,這也就是在軟件設計中解耦思想最簡單的一個應用。
當然在用戶場景中還會包含若干個子場景,比如訂單生成,訂單金額計算等等。
2)系統邊界
接著上面的思想繼續展開,一個系統理論上應該只去解決一種問題。而這類問題就是我們這個系統的核心,例如企業級訂單管理系統,它解決的就是訂單的所有用戶場景下商品單據的問題。
介紹完了邊界,下面我們來談談如何來梳理,這里我們按照下圖的公式進行拆解:
- 角色:當前系統參與的業務實際人員角色是什么?用戶角色的崗位是什么?每個崗位的具體日常工作又是什么?
- 場景:這些角色參與的場景有哪些?在各個場景下都分別有什么需求?在當前場景為了完成什么樣的工作?
- 路徑:將前面的角色與場景進行串聯,就能得到每個角色在場景下的任務以及希望得到的工作結果,同時各個場景之間的依賴關系是什么?完成一件事都需要有哪些角色和場景的參與以及怎樣路徑流轉?
通過這樣的分析后,我們就可以將一個抽象化的業務,得到了一個結構化的業務流程圖:業務起點是什么,包含哪些環節,各環節依次有哪些角色參與,最終業務結果是什么。
2. 步驟02:產品框架設計
所謂產品框架設計,本質就是在設計系統的功能架構,那么要如何設計一個系統的功能架構呢?
功能架構設計的第一步,就是要將一個抽象的業務領域劃分為不同系統模塊,讓每個系統模塊可以解決一個領域中的獨立環節。
還是以訂單的例子來說,訂單處理的完整業務領域,我們可以將其劃分為下面6個環節:
- 接單環節:指記錄用戶所需要的商品或服務,并計算各種優惠及總價。
- 提單環節:由接單環節用戶確認后,提交并嘗試生成訂單,此時需要處理商品的庫存鎖定,生成付款單等操作。
- 付款環節:指訂單生成后,用戶支付訂單金額。
- 路由環節:訂單付款完成后,生成有效訂單,此時根據訂單所購商品或服務流轉分單到對應倉儲或門店,為下一步履約做好準備。
- 履約環節:訂單此時轉化為出庫單或履約單,由下游系統接收進行處理,并在完成后回傳履約狀態。(只負責下傳訂單至下位系統)
- 逆向環節:訂單完成后,在指定有效期內可進入售后階段,此時便是逆向環節。
通過環節的劃分,我們就可以得到在訂單領域需要的系統模塊,如下圖所示:
但是截至到現在我們僅僅得到了一堆雜亂無序的功能模塊。還不算完成我們的功能架構設計,我們還需要按照上一步梳理出的不同階段,將對應的模塊功能進行聚合整理,也就是將功能進行分層or分塊。
例如在訂單中我們可以分為三層:售前、售中、售后,如下圖所示:
隨后再將起初得到的各個模塊放入剛才劃分好的各層級中,便得到如下圖所示最終結果:
可以看到,至此我們就很輕松完成了一個產品框架的定義。
在完成了產品框架設計后,我們對一個系統要包含哪些模塊以及系統邊界要做到哪些,我們就有了非常清晰的認知了,接下來我們就需要從宏觀走向微觀,開始逐個去梳理每個模塊內部的功能流程。
3. 步驟03:產品流程設計
這一步我們就是要將前面所得到的模塊進行逐一拆解,來逐個梳理功能流程是什么樣子的?這和我們日常的工作就非常相似了。
具體來說,在這一步我們需要畫出兩個流程圖:
- 功能流程圖:每個功能的基本處理流程是什么樣的?在這里我們重點需要梳理每個流程中詳細的業務規則,并將每個規則以流程圖的形式表示出來。
- 頁面流程圖:在繪制完頁面后,各個頁面的跳轉邏輯是什么樣的?
補充:所謂的頁面流轉圖就是指各個頁面中是什么按鈕或組件觸發頁面跳轉的,用以描述頁面之間的跳轉邏輯,此處的示例如下圖所示:
還是以訂單模塊為例,我們需要在這里產出:
- 訂單優惠的計算邏輯流程;
- 訂單庫存的鎖定邏輯流程;
- 訂單轉出庫單邏輯流程。
這樣我們就將一個功能完整且具體的表示出來了。
如法炮制,我們將第二步產品框架中所涉及的功能都依次描繪出來,這樣一個完整的系統就表述完畢了。
4. 步驟04:功能版本設計
到了這一步其實就比較簡單了,我們只需要將前面的產出,按照最小可迭代原型(MVP)規則進行拆分,并制定版本計劃即可。
具體來說我們此處要做的工作可以分為下面三項:
- 需求清單:將產品藍圖中的功能羅列,得到功能清單;
- 需求管理:使用KANO進行需求優先級分類,在制定第一個版本時要注意盡可能將主流程的功能排入,以便快速上線驗證業務邏輯是否正確;
- 版本規劃:詳細定義隨后的各版本以及包含的功能。
至此一個完整的設計框架就為大家介紹完畢了。
三、總結
綜上企業級應用由于涉及面廣,系統復雜度高,要能成功設計必須要有成熟的模型予以指導,從而幫助我們能有條理且漸進的完成產品設計工作。
#專欄作家#
三爺,微信公眾號:三爺茶館,人人都是產品經理專欄作家,2019年年度作者?!吨信_產品經理寶典》作者,原萬達高級產品、MBA特約講師、獨立創業者,現叮咚買菜B端產品線負責人,擁有多款集團項目從零到一經驗并帶領實現商業化布局。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
- 目前還沒評論,等你發揮!