我就職于一家tob的數字化服務公司，主要為各類大中型企業服務，提供數字化轉型的咨詢、診斷、評估、落地實施等一條龍的服務。
在這個過程中接觸了很多百億規模營收的公司，即有之前熟悉的零售連鎖行業，也有很多未曾接觸過的行業，如醫藥，保健品，工業等。
在服務的過程中，無論是前期的戰略規劃還是系統頂層架構設計，對我這種常年生活于互聯網公司的人來說，最大的感受不是在于許多傳統行業的同學不向往數字化，而是大多數人也說不清楚怎么樣叫數字化。
對于大多數人來說，包括一些在互聯網公司的人員，對于數字化、信息化、數智化這些層出不窮的概念未必都有很清晰的理解和認知。下圖是我對于各類公司在廣泛意義上對數字化理解的細分拆解：
數字化階段拆解
工具化：有些公司還停留在所謂IT時代，大多數對于系統的理解是進行單點的操作工具。
比如單一的財務系統，通過導入excel生成訂單記錄的訂單系統等。
這類公司對于系統的理解更多是excel表的延伸，不具備太多流程化的信息能力。不過此類公司在當前時代已經比較少見了。
信息化：這個階段的公司屬于市面上的主流情況，公司內部通過購買、自研等方式已經完成了線上、線下業務流程的打通和閉環，可以通過一定量的信息化系統完成日常的運營、操作、執行等動作。
信息化的典型特征就是看起來系統貌似各個環節都有。但是各自為政的情況比較多。而且數據底層的連通性較差。
不少公司的管理者往往期望在這個階段就開始所謂數字化的轉型，但實際上還是缺乏很多必要的支撐。
自動化：在這個階段是容易產生誤差最大的階段。
自動化是建立在信息化的基礎上，目的是提高系統間的協同能力，這里包括一體化的中臺能力，底層的數據架構。從根本上來說自動化是通過系統的協同完成完整的線上作業流程，從而降本增效。
大多數傳統公司會誤解的點主要是高層在很多時候會忽略這個階段，嘗試從有系統到智能決策一步過渡，但實際運行過程中我們發現，大多數的信息化能力僅僅是有，而還沒有做到自動協同，一體化管理決策的基礎搭建。
數智化：這個階段我理解才是我們常常想象的數字化。
智能化決策、數據中樞等等都是我們夢寐以求的能力，到達這個解決的公司是比較少的，往往會通過加速進程的方式使得部分環節達到初步的能力。
數字化轉型過程中之所以有這么多的誤解，最大的原因還是認知問題。這也就是為什么這么多網上類似的文章提到數字化轉型不僅僅是系統升級，更多是戰略、組織的變革。
在調研和溝通的過程中，來自數字化轉型企業的人員甚至高管經常會問到類似的一些問題：
- 目前我們系統都比較健全，但是在對業務支撐上總是不太夠用，是出了什么問題？
- 目前我們的需求來自于業務方，業務人員并不知道如何提出相應的問題，更多的需求都是解決操作易用性的問題。
- 多數傳統企業還是早年信息化的認知階段，所以在進行數字化轉型時候往往按照以前的ERP設計思路來改造數字化架構，感覺到處都別扭。
在我看來，服務過這么多家各行各業頭部客戶以后發現，數字化轉型主要面臨的是對于系統價值的認知及使用模式發生了變化。
很多早年傳統的管理者，甚至是IT負責人都不能很好的理解其中的價值和含義，才使得數字化轉型變得步履蹣跚。
數字化轉型在我看來，對于企業業務的經營改革主要是來自于對于認知的變化，體現的現象就是要求一些非標的能力、行為、準則逐步建立結構化的形式和數據，從而提供數據驅動業務發展、決策的模式。
早期企業對于系統的訴求更多是完成降本增效的訴求，所以更多以工具的形式來輔助業務運營。
隨著市場環境的不斷變化，我們漸漸開始進入到烏卡時代(VUCA volatile，uncertain，complex，ambiguous ),企業需要面對更多的不確定性，更多的競爭，對于企業經營來說也要求脫離以往粗放型的人為決策管理方式，變為精細化、數據化、標準化的高效管理模式。
在這個前提下，對于數字化對系統的要求也不僅僅是工具，而是需要精準的數據、多維度的決策判斷、直達一線的命令傳達效率等等。
這些都需要通過數字化及系統、數據的改進過程中不停的對組織、戰略認知進行調整，從而逐步達到數字化轉型的目的。
而在這個過程中，如何量化線下人為的各種運營動作和行為，能夠完成從非標到標準化、結構化的過程就是建模的過程。在我看來，掌握建模方法的平臺才能最快最有效的快速完成數字化轉型的道路。
二、數字化建模框架
我們知道想完成企業的結構化標準化，就需要從戰略、執行、模式等多方面出發，這樣看來建模也不僅僅是系統層面的架構設計，更多是要看符合戰略、模式的契合度。
企業架構（EA Enterprise Architecture）的框架設計在業內也有很多已經成型的方案，從宏觀上來說，企業架構包括業務架構、產品架構（應用架構）、技術架構、數據架構。
企業架構作為宏觀的指導框架，可以幫助負責人從公司角度來審視如何指導拆解目前的事務及結構、機制等。目前的主要架構模型也很多，比如TOGAF,ZACHMAN,MEAF等。這里我們重點介紹下前兩個。
ZACHMAN作為比較早期的企業架構理論發起者，他的框架是大多數企業框架的雛形。
zachman框架
從結構上來看，他的理論基礎是通過5W1H的問問題方式對不同類型的模型進行分析設計。這個方式在現在來看已經是比較普遍的理論方式了。
5W2H（多了一個how much）目前很多時候被運用在調研需求的時候或者產品規劃設計的時候，從起源來說都是從zachman的框架延伸出來的。
我們可以認為某個產品或者業務是一個企業，通過這種方式來進行“企業架構”的設計，即我們說的產品業務的規劃設計。
模型上zachman框架主要是三類模型：業務模型、產品模型和技術模型。這些模型在后來的絕大多數框架設計中都是主要的組成部分。
而另外一個影響比較大的則是TOGAF框架，相信這個框架很多人都聽說過，而我們可以發現現在很多時候產品經理的一些規范、方法論也都來自于此框架的體系。
TOGAF框架
上圖可以看到TOGAF的框架跟現在我們日常的需求管理流程是很相似的，只是從顆粒度看日常的需求更小一些。
兩者都是通過對業務能力的了解（調研）進行架構設計，并根據設計的框架逐步進行內容的開發。
所以我們可以看到企業架構設計的元素和原理與日常我們在進行產品需求規劃設計是很相似的，這也就是為什么常說產品經理理論上是一個公司的ceo，他負責的部分從認知上來說應該站在企業公司或者產品頂層的角度來思考問題。
從上面的一些經典企業架構來看我們會發現，在管理企業架構的時候整體下來主要是對四個部分進行架構設計和建模的操作，即業務架構、產品架構（應用架構）、技術架構、數據架構。作為一般企業核心的四套架構設計，其中包含了很多需要掌握的建模模型、梳理方法論等。
我基于在互聯網大廠（曾在京東、阿里多家一線履職過）的中臺經驗，結合我近年來為各大不同行業的頭部企業的數字化轉型咨詢、評估的情況。我梳理了一下數字化轉型需要進行的一系列建模及設計的頂層框架。
數字化建模藍圖
這個框架是基于多行業的實操落地經驗總結的，在不同的框架中運用了多種模型，包括對流程分解的，prd梳理的、業務架構建模的，產品建模的等等。其中技術模型考慮到相對更底層，且和業務價值的關聯相對較弱，這里不進行展開和解讀。藍圖中有一些模型是來自于一些成熟的方法論，比如PCF，DDD，有一些則是根據我的實際經驗結合方法論提煉出來的建模方法。希望對于大家有借鑒參考的作用。考慮到文章篇幅過長，本章中涉及方法、建模的詳細過程不在本文累述，后續我會單獨寫一些系列文章來講解本文里面哪些模型的詳細拆解過程。接下來我們來看下這個建模藍圖中都有哪些會運用到的模型及方法。
三、數字化建模詳解
上面我們說到了數字化架構有4種架構，除了偏底層的技術架構以外，其他的幾種都是反映企業業務運營特征的核心架構，而不同架構下也有不同的模型表現形式：
1. 業務架構模型
負責表達業務運營機制模式的模型，主要解答業務的機制，規則等。常見的業務模型主要包括業務流程圖、業務SOP規范，業務決策規則清單等等。
形式上不限于線上，線下的excel等各種格式也是比較常見的。
價值流梳理
海外倉業務管理模型
2. 產品架構模型
通過業務架構的模型進行系統層面的解讀。包括產品分層模型等。
產品建模的過程其實就是日常產品經理的常見工作內容，包括流程圖、ER圖，產品規劃藍圖，產品roadmap等等，甚至PRD里面的邏輯描述其實也是基于一定規律的建模模型獲得的（很多資深產品經理腦海中已經形成一定的經驗，所以不需要特意去建模獲取）
建模在產品經理的日常過程中是特別常用的工作方式，也是方法論沉淀的方式，甚至即使是前端的產品經理，在設計頁面的時候也需要運用到一些信息架構設計的模型或者方法。
某平臺采購下單流程模型
3. 數據模型
基于業務的梳理和建模，構建數據層面的模型包括物理模型，數據實體，數據血緣，數據流向等等
訂單模型
整體架構的建模是從業務模型開始，業務模型代表著公司的業務機制及模式，業務建模產生相應的業務元素，如業務流程，業務角色，業務動機等。這些元素是其他模型等必備要素。
業務模型分解的元素和規則可以用來進行數據建模，數據建模根據業務訴求搭建相應的數據結構和模型，從而滿足業務的記錄、觀測、分析的各類數據訴求。
而數據模型也是產品建模的重要組成部分，產品建模時候也需要參考數據模型來進行相應的產品設計及劃分。
產品建模則是我們真正意義上完成業務價值流在數字化上的體現。好的產品建模可以最大程度的還原業務的真實作業場景，盈利方式，合理規則，有效監控等等一系列的能力。從而幫助業務更上一個臺階。
模型之間關聯
產品建模根據業務戰略、執行、落地等多個維度，也會分解成若干層，不同維度的產品建模代表著不同的含義和價值實現。
總之，所有的模型建模的目標都是為了最大程度的提供還原度高、標準化、結構化的業務模式解讀，并可以通過在線的能力有效的解決線下的各種問題。
在不同的架構中，建模的方法及建模后的產物都有著很強的聯動性，在日常的產品、業務工作過程中，很多東西我們都是無意識的在使用，而忽略了他們之間的關系。
比如我們畫的產品流程圖是基于業務流程圖來進行制定的。產品的邏輯是根據業務執行的邏輯進行轉譯的。這些其實都屬于建模層面的產物。
接下來我們簡單看下各部分架構內都有哪些模型及規范的。
我們日常用到的一些設計的流程大多數是源自于TOGAF的企業架構，在TOGAF的企業架構中有一種架構的開發方法，簡稱ADM(Architecture Development Method,ADM)。
ADM是從企業架構的角度給出了對于架構設計的設計思路和路徑。而路徑上可以看到業務架構的設計和愿景是產品架構（信息架構設計）的前提，所以我們可以理解為ADM在日常工作中就是我們產品需求設計的一個流程框架。
我們可以看到流程上都要進行業務規劃（架構愿景）、業務調研、分析（業務架構）、產品規劃設計（信息系統架構）、技術方案設計（技術架構），復雜項目還會有多條線的整體產品方案（解決方案）等。
下圖是ADM的各個環節的關系圖
在實操場景下，現在絕大多數公司的產品需求設計流程都是和ADM的架構設計流程是相似的，原因在我看來產品需求設計更多是對于業務訴求及規范的理解和轉義（讓語言上更解決系統語言的表述方式）。所以在設計業務架構的時候都是相通的。
ADM是從宏觀角度劃分不同環節的關系及路徑，那么另一種企業架構CBM（component business model組件化業務模型）設計思路則是更加細化到更細的領域進行。
CBM引入了領域和職能的概念，進一步將價值單元進行劃分，不同領域在不同職能上都有特定的價值組件（BC），而每個價值組件既可以是業務的也可以是系統的。
當然在數字化的認知下，原則上業務組件都可以通過量化完成系統化的構建。
這種分層分域的邏輯產品經理是不是看著十分的熟悉？
沒錯，大多數的產品架構藍圖也是基于這個理念進行劃分設計的。后面我們會細說下關于產品建模時候藍圖如何聚合領域。
前面我們說了，業務架構、產品架構、數據架構是息息相關的，而架構建模的源頭來自于對于業務架構的設計。
4. 業務架構
業務架構目前市面上主流的設計框架是價值流+流程的組合，即通過識別企業業務價值流，構建實現價值流的流程從而完成整個業務架構的設計。
在實際落地過程中我發現一個問題，價值流是屬于頂層設計，而流程更多是聚焦到所有分支場景的執行操作，中間還需要有一個橋梁來連接，也就是說同樣場景或性質的流程應該形成統一規范，即業務的SOP。基于上面的設計框架，最合適的業務架構建模框架包含的元素有
1.價值流（價值主張、價值流、價值流階段）;
2.業務SOP（規則集合、流程合集的價值主張）;
3.業務流程（即包括所有業務場景的執行流程及邏輯規則）。
原則上業務SOP的模型形式和價值流和業務流程的的模型類似相通的地方，大多通過流程圖的方式來展現。
5. 業務價值流
比如上圖就是一個供應鏈企業的生產、交易價值流梳理，而下面提煉的階段就是價值流階段包含生產價值流階段和交易的價值流階段。
價值流中間的每個細節節點如加車、下單等又構成了一個SOP的規則、流程集合。里面包含很多不同的處理子流程。
很多時候大家在梳理業務價值流的時候會和系統的流程混淆。一般情況有以下幾點區別：
- 業務價值流重點描述場景、角色的交互，系統只是其中的一小部分，而系統流程的交互主要是線上系統交互為主。
- 業務流程的節點需要表達業務價值的階段或者成果，如履約完成、審核開票等。而系統流程中間有不少是系統的底層處理，比如數據的轉換之類的。
業務架構的建模框架如下：
業務架構建模框架
我們上文有提到業務架構建模核心是價值流和流程的梳理和拆解。其中價值流分為識別和價值流階段梳理。
什么叫價值流呢？
企業存在的核心在于為客戶提供價值，即其價值主張。業務的價值流是為了實現其價值主張而進行的方式。
業務價值流解讀是產品建模、拆解的前置依賴條件，無論是平臺級規劃還是單獨條線的規劃都是如此。
舉個例子，騰訊的核心產品是微信和QQ，那么他的價值主張是什么呢，價值流又是什么呢？
騰訊的核心能力是社交類軟件，那么它的價值主張就是社交嗎？并不是。我們知道，騰訊有很多其他產業，比如投資京東、美團等，它投資不同領域的產業目的是將連接屬性做到最大化。
因此騰訊的價值主張是“連接”，因為無論是人與人之間的連接，還是人與行業之間的連接，都需要圍繞連接開展。
而騰訊的價值流基本以連接后的導流，引入為主，通過連接提供更大的客戶群體。
阿里的價值主張則相反，它通過買斷自運營的方式實現進場（比如餓了么、高德等），再通過制定平臺規則和平臺統籌實現統一管理，實現各種服務、商品、信息的流通。
因此阿里的價值主張是“撮合”，撮合的本質是降低商業摩擦成本，并通過各種規則和能力使得商業成交轉化率得到大幅提升。
阿里的業務價值流主要以平臺間商品價值的互換和組合銷售為主的交易流，提供更高更多的客單。
綜上可以看出，價值主張為公司確定了很多隱性的東西。如果我們沒有深入理解這個概念，就容易設計出一些跑偏的架構。
價值流的識別和制定也是來自于一些內外部的輸入，包括戰略輸入、動機輸入、商業模式輸入。
數字化轉型需要制定一系列的戰略決策，不單單是進行系統的改造升級，戰略決策及業務動機會直接導致數字化的傾向性。
比如戰略上希望打造供應鏈一體化平臺，那么業務動機和商業模式則會聚焦在提高供應鏈產能、周轉，擴大分銷渠道等能力上，商業模式也以大宗批發為主，零售為輔助。
這樣的輸入下，價值流的核心會聚焦在后端及B2B的模式上做延伸，類似S2B2C等等。
而如果戰略上希望打造的是全渠道營銷平臺，那么供應鏈就會弱化，更多是完成渠道和用戶的轉化能力。
關于戰略、動機、商業模式的輸入可以通過構建戰略屋的方式來得到公司層面或者事業部層面的戰略構建。
業務價值流依存于輸入的差異和變化，價值流則絕對后續的業務架構建模。
業務價值流是一個端到端的流程合集，為客戶、利益相關者或最終用戶創造整體結果。即為某個或某群特定的利益相關方提供完成企業或平臺價值主張的流程或標準。他是由若干個價值流階段構成，即我們常說的關鍵環節
下圖是一個標準的電商價值流的示例：
- 價值主張：交易平臺，為客戶提供交易及履約服務；
- 價值流：交易價值流（或叫價值鏈）；
- 價值流階段：共五部分（加購物車、下單、支付、分揀打包、配送）。
價值流的識別和價值階段的拆解有助于我們快速找到業務的核心邏輯及目標價值。方便對后續的更細維度的流程、功能、業務邏輯進行拆解。
識別價值流以后就需要進一步對業務價值流或者價值流節點拆解、細化。形成可以落地執行的內容，如流程、規則、策略等。
這時候要PCF（ Process Classification Framework流程分類框架）,PCF不是一個業務上的模型，更像是對于業務流程梳理的時候一個通用的規范。
他可以讓業務人員在梳理業務流程和SOP的過程中按照一定的規范快速梳理出自己業務的相應流程和規則。
PCF共計有13個分類的流程框架，5個級別流程拆解層級。
13個分類流程框架
PCF將13個分類流程框架分為兩大類：日常運營類的和管理支持類的。而這13個分類在日常我們的工作中最常用到的是運營流程類的相關框架。
PCF的最大作用是通過框架一定程度上窮舉了不同層級對于業務流程的概述。你可以通過PCF的內容快速了解到當前需要梳理的業務流程都有哪些種類，他們的大體關系是什么樣的。
按照PCF的劃分，整個流程被分成了5級：
1. 類別：可以理解為是表達當前領域下對于價值流和價值主張的流程。
2. 流程組：是解答上一級流程劃分的集合，我們也可以理解為是價值流階段，代表是不同節點的組合。
3. 流程：這個層級的流程也是以流程集合形式體現的，差別在于這個層級更聚焦在具體的成功轉化上，這個層級的”流程”會消耗到資源，所以需要從業務的實際工作維度來進行設計，可以理解為是我們常見的業務SOP。
比如售后分類中，售后維修可能是流程組的概念，那么維修評估、維修報價等等就是我們說的“流程”，他需要開始對資源進行消耗。
而維修評估不單單是一個獨立的業務流程，還可以進行進一步的拆解，即下層級的活動。
4. 活動：這個層級的流程則是我們通常意義上表達的業務流程，主要是進行生產、操作流程的。
5. 任務：任務屬于在更細維度的事務拆解，一般情況下這個顆粒度分解的內容可以理解為處理業務的原子因素。在DDD領域設計里面的事件、命令其實就是對應這個維度的。
需要說明下，有時候業務場景沒有那么復雜，事件和命令的原子因素也可以對應上級的內容。
5個層級樣例
比如上面這張圖就汽車是企業風險合規整治的一個流程框架概述，通過逐級拆解可以找到業務場景下需要梳理的流程清單，方便我們在做業務架構設計的時候快速窮舉查找。
PCF不會涉及到具體的業務元素，但在判斷是否完善業務場景和流程的時候，可以作為參考的架構來看，此外PCF還有很多不同行業的細分框架，對于具體業務理解更有助于判斷。下面這個就是汽車生成行業的客服管理流程分類框架。
汽車PCF流程分類框架樣例
說了這么多流程分類的方法論，也許對于很多產品出身的同學來說感覺不是那么好理解，那么我通過系統的相關模型給大家解讀下如何來看待業務架構設計中PCF對于產品架構設計和日常需求的作用。
PCF的五層分類前兩層可以便于我們去快速找到對應領域業務的關鍵價值流和價值流階段的內容。而后面的三層可以指導我們去識別業務SOP、業務流程梳理的完整度。
前期業務建模的架構越完整，對于識別出來的流程、角色、事件、命令就會越準確，后面去進行系統領域的劃分設計就會更加容易匹配，輸出價值。
我們以訂單中臺系統中的一個部分拆單模塊為例來看下，假設我們認為拆單模塊的流程是一個完整的流程分類，那么他的鏈路就是我們說的價值流，里面的節點是價值流階段，再往下拆分的就是子流程，即流程、活動、任務。
子流程都是需要消耗資源的，即需要調用相關系統計算、更新數據等。
拆單流程分類框架示例
業務流程拆解后，為了后續可以進行系統的架構和建模，可以在已經完成的業務流程中做一些“標簽”的識別，我們可以通過流程節點識別出來事件、命令、角色。這個概念是來自于DDD領域設計中的事件風暴。
在實際的建模和落地實施過程中我發現，事件、命令就是最小的業務單元，而能夠講業務流程拆解到最小業務單元，在進行后續的產品架構設計，甚至產品具體功能的PRD編寫時都有很大的便利和指導性。
以一個審批流程為例，我們可以看到，事件、命令作用于每一個節點上，通過拆解可以找到最小單元的變化數據和最小單元的操作動作。從而進一步結構了業務在運行之中的核心“原理”。
事件、命令拆解示例
對于產品建模來說，業務架構建模是非常重要的過程，很多企業沒有能做好這塊，或者說對于業務設計更多來自于腦海中的概念和口述，缺乏更多的細節。
這樣就導致產品規劃、設計時候很多產品經理經常會抱怨業務沒有想清楚，方案感覺都是拍腦袋的原因。
另一方面，業務的經驗更多來自于運營過程中的不斷收集，內容更多是碎片化的積累，如果希望做數字化轉型，業務架構建模的體系能力是很重要的。
業務建模后很多元素是產品建模的基礎，比如流程、規劃、目標等。下面這個圖來自于建模藍圖中的一部分，表明了業務建模和產品建模的轉換關系。
業務建模與產品建模的關系
說完業務模型，我們來看下產品模型，產品建模解決的是設計的框架及對待問題的處理方案準則。很多的信息和數據都是來自于業務建模的轉化，產品建模需要通過對業務的理解和抽象形成系統層面的模型來指導產品系統的搭建。
按照從宏觀到細節，我將產品模型分成了三層。
- 頂層建模：針對業務價值流和階段進行拆解，找到核心的業務價值，轉義業務架構建模形成的信息。
- 領域建模：基于DDD的方法論針對產品領域進行聚合，形成不同產品領域的模型。包括一二級域。通過產品能力矩陣識別領域缺失，逐步完善領域建模。
- 產品功能點建模：指的是基于上面模型的原子要素（事件、命令、角色等）和流程、邏輯進行具體需求的整理，也就是我們整理prd的過程。通過模型可以及時發現需求梳理的問題，進行完善。
產品建模：頂層模型、領域模型
產品功能點建模
產品的的分層建模目的是通過不同維度的建模可以將對應層級的業務架構進行轉化，比如價值流的梳理轉化的產品層面就是頂層架構建模，可以通過價值流和價值流階段的識別，快速確認在數字化中核心的產品鏈路是哪些，核心產品鏈路要賦予更高層次的數字化能力的規劃。
舉個簡單的例子，一個供應鏈企業和一個營銷型企業雖然同樣都需要交易、營銷、供應鏈的能力，但是數字化產品架構設計時，由于業務架構上的價值流和流程的級別不同，所以產生了差異化產品架構設計的情況。
供應鏈企業對于庫存、商品、物流方向的智能化、自動化能力就需要有一些深度規劃，而營銷型企業則需要加強用戶運營，營銷的玩法。
供應鏈企業產品架構示意圖
營銷型企業產品架構示意圖
頂層產品架構設計會影響到在領域建模時對于根據產品能力矩陣進行領域能力完善時的側重和取舍。
產品建模的頂層建模不僅僅只是照抄業務架構建模的價值流內容，而是需要判斷出業務的屬性特征，從而得到產品可以賦能的核心價值點。
除了進行分層轉化以外，產品架構設計最重要的是提煉出兩個東西：
- 系統流程，系統流程代表著業務線上還原的場景，還原度越高越能夠體現業務架構設計的準確性。而且系統流程直接決定了交互的邏輯、關系，所以系統流程的梳理是很重要的一項產品建模；
- 事件、命令、角色，通過事件風暴獲得的事件、命令、角色是基于業務建模的，在進行產品建模的時候需要根據系統場景和流程補充很多系統層面的事件、命令、角色。
比如訂單的下單就需要增加一些線上的審核校驗事件或命令，促銷發券就需要有一些促銷計算的過程等等。
在產品建模中，事件、命令這些元素是業務的最小單元，也是系統執行的最小單元，我們可以理解為它就想PCF分類框架中的最后層級的流程分類：任務。
所以包括領域建模、功能點建模都需要通過事件、命令進行歸因識別，確保業務、產品從上到下的邏輯是統一的。
在產品分層建模中，我使用的核心思路是基于DDD領域設計的思路，包含了各類領域設計的元素：聚合根、事件、命令、限界上下文等。
下圖是我總結的關于DDD領域設計中各個元素間的關系：
數據建模
市面上講述數據架構的詳細文章很多，也說的比較清楚，關于基礎的概念這里我不單獨累述了，考慮到數據結構還是比較方法化，很多東西和概念對于之前接觸不多的人來說容易繞暈，本文重點用一些通俗的表達讓大家來理解下這塊的內容。
業務和產品建模的關系類似于人類起源之時人類生產活動和工具的關系。業務建模代表人們的基本運營規則和方法，而產品建模則是通過更多系統化的能力提供快速提升的手段。
而數據建模則像是語言一樣，負責傳達和表達人們真實的想法和沉淀積累。所有業務、產品的行為都會以數據的形式記錄下來以便進行更多的分析、判斷。
所以數據建模既來源于業務、產品建模，又對它們有導向的作用。
在進行數據模型的抽象之前，很多基礎的信息都是來自于對于實體的理解和拆分。所以ER實體建模是進行數據架構的前提條件。
業務實體與數據架構的關系
數據實體識別完成后，我們就需要根據需要將數據分層、拆解、得到相應更獨立的數據結構，這就是數據建模的過程。
舉個例子，我們現在有一個訂單的實體建模，那么根據訂單的使用場景、信息、類型等維度對數據就有不同的訴求和分析角度。
我們可以根據場景拆分成交易場景、財務場景、售后（訂單快照）等等，不同場景下的數據需要完成哪些分析，從而聚合形成相應的數據結構。
上面的描述方式類似口語，在實際建模過程中則會根據模型的特點分為邏輯模型、概念模型和物理模型。
簡單來說概念模型就是表達實體的關系，可以用“實體-關系”（E-R）圖來呈現，它的實現代表了自然語言的轉化。
邏輯模型則是技術側在進行理解的時候用技術的語言解讀實體關系的內容，這個過程和業務建模轉化成產品建模由異曲同工的過程。
物理模型則是邏輯模型的落地，是對于真實數據庫表的描述，包含了表、視圖、字段、數據類型等等要素。可以理解為是具體的表結構。
需要說明的是這里面的表結構可能會因為場景、業務屬性、用途等進行聚合或者拆分，理解上不是我們常規見到的業務系統里面的數據庫結構，比如訂單的數據可能就有多維度數據聚合的寬表來進行財務、業務上的分析使用。
除了模型外，關于數據的源頭、流向、血緣關系也是數據架構建模的時候需要重點關注的，這些相當于我們在做業務、產品建模時候管理相應生命周期的閉環是一個道理。只有能夠最大程度記錄和體現業務、產品生命周期下的情況及特征，才是數據建模最大的價值。
四、數字化建模工具
說完了建模的方法，那么通過什么方式或者手段來建模呢？構建的模型都有哪些常用的形式呢？
首先，模型是包含很多種形式的，主要的作用是通過抽象的方式固化下來相對核心主要的模式、規則、流程等。所以模型等表現形式是多種多樣的。
我們日常畫的流程圖就是建模的一種形式，業務梳理的規則列表，產品整理的數據字段，開發的接口規范，業務運營的流程，sop。這些都是模型的范疇。
我們這里面的模型是廣義上的模型，而不僅僅是常規印象中的算法模型那些。
類似下述的這些圖都屬于模型的范疇，包括但不限于價值流、流程、規范、框架、規劃等。
交互模型
業務流程
架構圖
其次，建模的規范和標準是需要統一化的，在產品中大家見到的最多的模型語言就是UML，UML可以基于各種鏈路流程進行制圖，表達他們之間的流轉和關系。
此外還有對于業務建模常用到的BPMN規范。接下來我們重點介紹這兩種語言。
1. UML
關于UML的基本概念相信在很多的書籍或者文章上大家都有閱讀過，這里面我就不再啰嗦了。重點我講下我對于UML的理解以及在架構、模型設計時候的一些底層邏輯。方便大家理解對于UML的合理使用。
UML在產品經理或業務運營人員日常的畫圖中經常會用到，它有一些基本元素和類型，我總結了一下，大概有以下幾類：
1）實體元素：包括各類實際行為或者載體的表達，開始結束的表達以及對于判斷的表達等。這些實體元素在各類圖中用于對業務載體、產品系統載體、邏輯載體進行描述。
需要注意的是，這里面提到的實體載體是指對業務或系統上某個規則或模型的載體，他可能是一系列的流程、sop、策略或具體角色、任務等。
流程建模示例
上圖中的矩形和判斷的菱形元素都是在表達實體的內容，包括判斷邏輯和業務動作行為。
2）連接關系：連接關系用于表達實體元素間的互動邏輯，不同類型的連接關系形成不同類型的圖，如并列關系。
下列是我們日常常見UML的模型圖分類及樣例：
UML圖樣例
2. BPMN
除此以外還有一種規范其實也是我們經常見到的，就BPMN（Business Process Modeling Notation 指業務流程建模與標注）。
BPMN可以理解為是UML的升級版本，在BPMN中，包含的基礎元素有：
- 流對象（Flow Object）用來操作數據的流向的對象，所有流轉含義的內容都可以通過流對象表達，包括事件、網關、活動等。
- 數據（Data）：數據對象是一個顯示活動是如何需要或產生數據的。它們通過關聯與活動連接起來。
- 鏈接對象?（Connecting Objects）：連接對象將流對象連接起來形成一個業務流程的基本結構。
- 泳道（Swimlanes）：通過泳道對主要的建模元素進行分組。
- 描述對象：我們可以理解為擴展信息等內容主要進行注釋，輔助描述等。包括組和注釋兩種概念。
在日常工作中，這兩種語言其實沒有太多本質性的差異，很多產品經理畫的流程圖或者泳道圖都是混合了兩種語法的產物。
大多數的流程大家會基于UML的格式來進行，但是從我個人的經驗來看BPMN在進行業務建模復原的時候更容易表達業務的上的一些場景、觸發機制等。所以可以使用一些BPMN語法的概念來進行特殊節點的描述。
比如UML開始節點并沒有表明太多元素或者觸發的動機，而在BPMN中規定流程的初始需要通過某類事件或者場景的觸發，即設定相應的流對象。這個概念有助于建模時對場景的描述更加具體完善，避免缺失和遺漏。
此外，對于我們常規建模的圖形來說，大體可以粗略的歸為兩類：結構靜態圖和行為圖。
結構靜態圖一般是用UML的格式來畫，代表一些今天結構的圖，比如產品架構圖、組織結構圖等。這些一般不代表行為或動作。
另一種就是行為圖，比如我們經常畫的流程圖，系統交互圖，時序圖等都是這個范疇，代表一系列行為的動作流轉。在這種圖里面可以加入一些BPMN的元素用來豐富表達的含義。
尤其是在進行業務行為描述的時候對于特殊的場景、觸發邏輯等可以通過BPMN的元素進行表達，方便進行事件、命令抽象的時候更加完善。
五、總結
數字化轉型是一個痛苦的過程，但又是一個必經的過程。如何能夠通過數治代替人治是數字化的核心改革。
建模是決定能否變成可量化、可衡量、可延展的商業體系的標準之一。一個數字化轉型成功的企業都需要具備良好的合理的建模基礎。通過模型可以有效的防止、預估、判斷各類不可控情況的發生和蔓延。
本文重點講解了各種模型、方法之間的關系及內部的結構邏輯，考慮篇幅沒有特別深入的展開。后續我會對每部分單獨寫文講解其中的方法及實操內容。
作者：高暉，微信號公眾號@產品老高
本站文章收集整理于網絡，原文出處： ，本站僅提供信息存儲空間服務。如若轉載，請注明出處。
