企業數字化解決方案有業務數字化系統、服務體驗數字化系統和營銷數字化系統這三類,本文作者對數字化業務系統設計方案流程進行了拆解分析,希望能給你帶來幫助。
如何從0-1搭建企業數字化業務流程?每個關鍵步驟中的方法是什麼?整個流程搭建過程中需要注意什麼?
企業數字化解決方案有三類:
不同類型的數字化解決方案設計流程不同,需要注意的關鍵點也不同,今天分享的是業務數字化系統從0-1搭建的設計過程。後續會持續更新其他類型的設計流程,若您感興趣,歡迎交流。
不管是集團内部做業務數字化升級還是為新客戶提供業務數字化解決方案,将現有的業務流程轉化為線上數字化業務流程解決方案,是數字産品經理的基礎能力。
做設計師而不是需求實現者:我們接到很多個項目,都是因為客戶已有的系統無法支持現有的業務流程,或者因為開發團隊的設計能力和架構能力偏弱,所以提供的解決方案隻能是客戶提供的需求的原封不動的原版實現版,甚至是簡化版;真正的數字化解決方案,我們是從客戶業務人員了解實際的業務流程和他們的痛點和期待達到的效果,結合自己專業的設計能力産出更适合的、有拓展性的數字化解決方案。
業務數字化解決方案,一般是企業内部工作人員的使用系統。數字化業務系統設計方案流程可以分為5個步驟:
因為需要對企業内部的業務流程做到全部的理解和掌控,所以調研是非常關鍵的流程。
一、關于調研業務調研的框架性和結構性對後續的方案設計起到了非常關鍵的作用;如果業務調研不全面,設計方案時會影響整體的産品架構;
如果細節理解不到位則設計功能時,可能會導緻功能偏死闆,後續的擴展性較差;
業務調研,用下面的思路進行,能保證框架和細節的全面性
1. 流程初探:業務藍圖
業務藍圖包括業務事件,反饋結果及不同組織部門角色三個基礎要素在内的業務梳理流程圖;通過梳理業務流程中關鍵角色的上下遊合作關系,關鍵角色的主要工作範圍,以及關鍵業務流程的關鍵結果;讓産品經理從全局了解客戶的業務流程框架。
數字化設計方案就設計一棟建築,既需要設計師設計整體的架構和展示方案,也需要建築設計師設計内部的細節的結構和布局;既有設計師可發揮的設計部分,又有必須要遵守的基礎要求。
業務藍圖的流程梳理,有助于設計師了解整個方案的全面貌和内部的業務流轉情況。
業務藍圖:
- 确認組織架構團隊及角色職能
- 确認各個組織角色的上下遊合作關系
- 确認各個角色細節的業務流程需要達到的最終目的以及現有的流程痛點
注意:在第3步确定各個角色的業務流程時,會分成多個模塊;就像建築圖設計好之後,需要設計各個不同區域的詳細方案。
2. 深入業務:矩陣樹
我們了解的主要的業務流轉流程之後,就要針對詳細的業務模塊進行梳理;一般來說,到業務模塊流程,需要整理出模塊的信息流流程。
梳理信息流的流程:
- 模塊分解為多個關鍵元素
- 每個元素的業務流程梳理
- 多種元素耦合交叉處理-梳理總結完整的業務模塊流程架構
- 細節字段調研,通過業務字段反推業務流程
這樣說有些抽象,我們拿一個最常見的模塊舉例子——訂貨模塊。
我們分解訂貨模塊的基礎元素:渠道、商品、賬戶。
1)圍繞渠道
例如:渠道有不同類型;我們需要增加渠道分類的功能;
渠道有訂貨範圍限制,我們需要增加渠道的訂貨範圍功能;需要提供串貨的功能;
不同渠道有上下級的包含關系,我們需要增加渠道組織的功能;
2)圍繞商品
商品在訂單模塊内有什麼特殊點?例如:商品有不同的分類,我們需要提供商品分類的功能;不同商品給不同的渠道價格不同,我們需要做價格體系。
3)圍繞賬戶
賬戶分現貨現款和信用賒賬,那我們需要有信用賬戶的功能;特定的商品有特定的款項,那我們需要做子賬戶的功能。
在梳理過程中,不斷的向下分解,會發現有很多模塊都和多個元素關聯,例如價格提示需要和渠道以及商品關聯;賬戶和渠道以及商品購買關聯。
遇到這種耦合的邏輯時,一旦梳理不清楚,就會導緻後續的方案遺漏功能,所以前期的梳理一定是一層層,細緻的溝通和調研。
最好是梳理出流程圖和Demo圖,和客戶不斷的溝通,進行幾輪後,設計師心裡對整體的方案已經了解了,這個時候可以進入細節的溝通。
最後可以針對關鍵數據表的字段進行溝通;因為字段能反映功能模塊,但是客戶是沒有這個意識的,産品經理和設計師需要有這個能力。
舉個例子,我們的一個客戶在對賬單頁面,提出了要能篩選出訂單核銷和未核銷的狀态的單子的對賬情況,如果沒有這樣字段的要求,那我們在設計方案時可能不會特意設計對應的狀态值。
調研完成後,我們可以梳理出來業務藍圖,和關鍵模塊的流程圖,關鍵業務的流轉情況,可以基于已有的信息做方案設計。
二、方案設計通過快速的Demo設計與交互流程,與客戶進行至少3輪的溝通和确認。
可視化的展示形式絕對是最高效的溝通方式,所以畫圖是數字産品經理必不可少的技能。
通過快速産出原型Demo,讓客戶确認交互流程和業務流程,有助于快速推動業務細節;防止方案設計有偏差。
三、開發實現方案設計完成後,我們需要轉化成技術團隊方便查看的文檔模式,進行快速溝通。
我們現在使用的方式是交互Demo PRD文檔混合的模式,前期調研的内容和背景,也是需要同步給技術團隊的,方便他們通過更嚴謹的方式設計産品結構和技術方案。
除此之外,對交互流程多的,一定要有交互圖,方便技術快速了解流程。
分叉流程多的,一定要有業務流程邏輯圖,方便技術了解邏輯流程。
細節說明多的,一定在PRF文檔通過表格形式表達清楚,方便不遺漏細節。
四、上線實施開發完成後上線的流程,實施過程需要提前準備,将所有的實施内容和素材提前溝通準備好,避免出現『裸房交付』的情況,即上線了,但是因為上線内容沒有提前溝通,導緻上線後業務無法快速驗收和走查測試。
五、系統調優整個設計流程描述好像很完美,但是最終實現到業務端時,可能會有因為業務描述不到位遺漏的需求,也有因為細節字段導緻的需求沒有實現的情況。
因為我們的解決方案重度依賴業務,如果業務提供的信息在前期沒有提供到位,調研時沒有深挖,會導緻這種情況,所以會有系統調優的流程。
這個過程通過業務推動前測試和正式線上業務跑起來測試,會逐步的穩定和順暢。
每個步驟做到位,能對後面的一個步驟起到很好的支撐。
數字化解決方案,并不是将客戶描述的需求直接拿過來,而是基于客戶的業務需求結合專業的數字化能力,為客戶提供合适、穩定、方便、高效的解決方案,這才是專業的設計方案。
專欄作家
邊亞南,邊亞南,人人都是産品經理專欄作家。華秉科技産品合夥人,IT東方會副秘書長,北京理工研究生,《數字突圍》第二作者。專注實體企業數字化升級方案設計和私域流量運營體系搭建,擅長為企業提供全鍊路數字化升級解決方案,以及私域流量運營方案。
本文原創發布于人人都是産品經理,未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!