編輯導語：在數字化轉型的大環境下，越來越多的企業都在進行數字化轉型。本文作者分享了在進行復雜數字化項目時設計產品架構的具體方法思路，講述了產品架構過程中的注意點等，一起來學習一下吧，希望對你有幫助。

數字化轉型背景下，越來越多的企業開啟數字化轉型，B端產品會接觸到越來越多的從0-1搭建數字化系統的項目，這樣的項目需要從0-1搭建產品架構，還需要設計模塊流程，并且嚴重依賴業務流程和客戶支持資源。

復雜數字化系統對產品架構和模塊化間的邏輯處理方法要求非常高；如果模塊間關系處理不清晰，到產品的后續應用環境會出現阻塞的情況，返工成本會很高。如果產品架構設計不合理，那可能會直接導致功能無法順利實現。

那我們在做這樣項目時需要注意哪些事項？有哪些參考準則呢？

一、項目初始：產品架構框架設計：三要素+三條流+精力分配值

1. 業務三元素：整體組織架構，關鍵角色及關鍵權限范圍，以及關鍵業務要素

注意這里三元素不是指我們在系統里實現的功能，而是在客戶現有的業務流程里的內容。

我們需要通過全局視角俯瞰整個項目結構時必須了解的部分；組織架構的分布情況了解清楚才可以設計權限角色架構，關鍵角色權限及范圍幫助我們了解角色權限的顆粒度，關鍵業務要素讓我們了解人與業務的交互關系；這些信息能讓我們搭建起產品架構的第一層結構。

2. 三條流：業務流 數據流 操作流

業務流是基于數字化系統覆蓋范圍內的所有業務的流轉流程，這個大家應該很清楚，但是在實際調研和設計的過程中特別需要注意，我們設計的系統不是將業務流程原原本本的還原出來，而是通過梳理業務流程，發現隱藏的產品架構； 產品經理要通過數字化的設計能力設計完整的產品架構。

舉個例子，我們在給不同的客戶設計訂貨業務系統時，其錢款的實際業務流程是類似的：經銷商充值打款、財務審核確認、業務下單訂貨。

我們在設計架構時，是不是將這個業務流程直接設計出來就OK呢？明顯不是，產品經理應該能捕捉到，這里有『賬戶體系』的結構隱藏在業務之后。

所以在設計產品架構時，我們不但要看到業務的明線，還需要捕捉到產品結構的『暗線』，保證方案的完整性。

另外還需要注意，業務流程梳理完成后轉化成設計方案時，一定要結合全鏈條流程進行設計，否則很容易設計錯誤。

再拿賬戶體系的設計方案舉個例子：業務流程相同，那是不是所有的這樣的業務流程都是設計相同的賬戶體系內？完全不是。

我們為不同的客戶設計過不同的架構體系，雖然業務流程都是一樣的，但是賬戶體系的結構完全不同，原因就是因為后續的結算業務流程不同；所以我們做的A客戶的賬戶體系是歸屬在經銷商邏輯內，B客戶的賬戶體系是歸屬在經銷商訂單內。

通過上述的流程梳理，產品的第二層架構可以細化；我們結合數據流轉邏輯和關鍵角色的操作流程，就可以繼續細化架構；

3. 關于『精力分配值』

項目調研是每個項目都要經歷的一個步驟，調研的手段和方法有很多，我們會花費很多時間和精力在調研的過程中，但是我們更需要關注的是調研的目的。

我們需要通過高層訪談，業務訪談和用戶訪談，獲取項目關鍵目標， 了解關鍵角色以及其主要權限，獲取現有的企業資源支持項目；以方便我們確認系統設計的『精力分配值』。

這里需要注意，項目的設計，并不是將客戶提出的需求事無巨細的設計出來，客戶需求的描述是基于他對業務的認知表達的，最后落地如何設計，是需要產品架構師進行設計的，設計的合理可以為客戶有效節省成本,也就是需要提前預估好系統設計的“精力分配值”。

什么是“精力分配值”？

舉個例子，我們為一個藥械企業做財務數字化系統，他們做數字系統的核心訴求是3年后IPO時，系統需提供所有業務數據，且需要符合審計合規性，保證證據鏈的完整性。

我們通過訪談獲取到核心目標，了解關鍵角色和關鍵業務，在后續設計時，就明確了哪些模塊是必須要詳細設計的，哪些模塊可以做簡化設計；這樣在做項目方案時，我們結合客戶的預算和目標，就可以游刃有余的提供設計方案。

二、架構細化階段：望遠鏡和顯微鏡

經過了前期的調研，對項目的業務流程已經有了大概的了解，那我們需要對產品設計方案進行細化及邏輯合理性審查。

這個過程中，我們需要不斷的從整體到局部的視角切換 審核方案的合理性。

真正到設計過程中，很多模塊間的關聯性非常強，如果僅關注單獨模塊的邏輯，則很容易造成功能不完整；所以我們需要有『望遠鏡』思維，不斷的梳理各個模塊之間的關聯關系，確保任何聯系的那條『線』不會缺失，保證功能完整性。

在建立模塊和模塊的鏈接后，我們需要調回到『顯微鏡』狀態，詳細梳理模塊內各個業務關鍵點如何設計，如何和不同模塊間打造通道，保證系統的完整和合理。

之前我們在設計一個客戶的訂貨業務系統時，就使用了這種方法。

因為下單是整個系統的核心模塊，中間關聯著渠道價格體系，產品授權，賬號，庫存，審核權限，串貨限制，以及信用體系和任務返利體系，在這個模塊設計時，我們通過單個模塊的業務流+多個模塊的限制并行處理，反復的梳理模塊和模塊之間的邏輯，最終能夠將系統完美交付。

三、模塊細節設計

前期的架構設計合理，后續的模塊的細化任務就簡單很多，這個時候注意，方案的設計會較依賴客戶的實際業務需求，所以前期的業務調研一定要做到位，如果業務邏輯梳理以及溝通有歧義，會造成方案設計方向的偏差。

還需要注意：有些設計方案設計出來后，可能會更改業務流程因為之前的業務流程，比如因為之前系統間有數據孤島，新系統因為模塊的鏈接和數據的打通，可能很多業務流程是可以省略的；在遇到這種情況時，大膽設計，小心驗證。

嘗試突破業務的限制，最大化利用數字化的優勢提供價值，才是我們最終的目的。

#專欄作家#

邊亞南，微信公眾號：邊亞南，人人都是產品經理專欄作家。華秉科技產品合伙人，IT東方會副秘書長，北京理工研究生，《數字突圍》第二作者。專注實體企業數字化升級方案設計和私域流量運營體系搭建，擅長為企業提供全鏈路數字化升級解決方案，以及私域流量運營方案。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議