編輯導語：企業架構可以輔助企業完成業務及IT戰略規劃，還是企業信息化規劃的核心，也有助于個人職業的健康長遠發展。本文作者對企業架構的全景以及業務架構設計進行了分析，感興趣的小伙伴們一起來看一下吧。

有價值的東西是才值得我們投入時間和精力的，企業架構為什么就值得我們投入時間和精力來學習呢？主要由以下兩方面原因：

1）對公司而言

企業架構可以輔助企業完成業務及IT戰略規劃。在業務戰略方面，它定義企業的愿景/使命、目標/目的/驅動力、組織架構、職能和角色；在IT戰略方面，定義業務架構、數據架構、應用架構和技術架構，是IT戰略規劃的最佳實踐的指引。

企業架構是承接企業業務戰略與IT戰略之間的橋梁與標準接口，是企業信息化規劃的核心。

2）對個人而言

有助于職業的健康長遠發展，比如成為CIO，首席信息官通過指導對信息技術的利用來支持公司的目標，具備技術和業務過程兩方面的知識，常常是將組織的技術調配戰略與業務戰略緊密結合在一起的最佳人選。

一、企業架構全景圖

1. 企業架構的模塊劃分和主要工作內容

企業架構包含了四部分，BA（Business Architecture，業務架構）、DA（Data Architecture，數據架構）、AA（Applications Architecture，應用架構）、TA（Technology Architecture，技術架構）。

企業架構由全局戰略規劃驅動，我們來看下戰略、BA、DA、AA、TA五者之間的關系。

圖 1-1 戰略、BA、DA、AA、TA的執行順序

如圖所示，戰略、BA、DA、AA、TA實際位于以下三個層次上：

• 公司戰略
• 業務架構
• 方案架構

這五者的核心關系，可以概況為以下幾點：

• 戰略是公司高層設計，卻是業務架構師的需求
• 業務架構師的工作時“戰略進，業務架構出”
• 業務架構是業務架構師的設計，卻是數據、應用、技術架構師的需求

環環相扣，上層驅動下層，下層支撐上層。

圖 1-2戰略、BA、DA、AA、TA的關系

2. 從戰略到架構，再到實施的實際過程

通過上面的內容，我們知道了戰略、業務架構、方案架構的關系，下面我們看下實際工作中架構路線圖和實施規劃環節是如何操作的。

圖 1-3 戰略到架構的實施過程

執行的要點是釘到崗位（左側），落到文檔（右側），細到機構調整、技術采購、項目研發等工作包。主要有以下環節：

• 戰略：公司管理層牽頭、規劃發展部全程支持，產出物：《xx-xx年戰略規劃書》
• 業務架構：信息科技部的架構師團隊中的業務架構師負責，產出物：《業務架構書》
• 方案架構：信息科技部的架構師團隊負責，產出物：《技術方案書》
• 架構路線圖：涉及預算，CI0牽頭制定、董事會批準，產出物：架構路線圖
• 實施規劃：CIO牽頭制定，產出物：實施計劃
• 項目管控：采取研發的項目由PMO負責，采取購買的項目由總經理辦公室負責

這里需要補充說明的一點是，實施計劃不僅僅是從“架構藍圖到研發”的計劃，也是從“架構藍圖到IT與非IT的方方面面”。

• IT方面：支持業務架構藍圖所需的所有“IT能力”有哪些？項目是研發還是購買？相應識別技術采購工作包、人員培訓工作包。
• 非IT方面：支持商業藍圖所需的“組織能力”有哪些？相應識別機構調整工作包、新建部門工作包、人員培訓工作包。

二、戰略驅動的業務架構設計

1. 業務架構（BA）是什么？

對于業務架構，OMG業務架構組給了如下定義：業務架構是企業治理結構、商業能力與價值流的正式藍圖。業務架構明確定義企業的治理結構、業務能力、業務流程、業務數據。其中，業務能力定義了企業做什么，業務流程定義企業怎么做。

具體而言，就是：

• 業務功能是由業務流程實現的
• 業務流程由業務步驟、業務角色、業務數據、業務事件、業務規則組成。

2. 業務架構出現的背景

我們分別從國外國內來了解一下，業務架構出現的背景，便于我們更好的理解業務架構的使用場景，業務架構是跨部門跨組織的業務需求，單個小系統的生命周期，根本就沒有業務架構環節。

1）跨系統規劃——業務架構在全球出現的背景

國外軟件系統經過長期發展，在經過多年實踐后，1962年發表于哈佛商業雜志的《信息系統總規劃》這篇文章，拉開了跨部門、跨組織需求規劃的序幕。此后多年，IBM等企業進行了很多實踐。

1982年，IBM公布了業務系統規劃（Business System Planning，BSP）方法論。這是個重要事件，對業界產生了大而持久的影響。

此后多年，業務架構快速發展，如Togaf、FEAF等。

以上歷史告訴我們，業務架構脫胎于跨系統、重視跨系統需求。站在開發者的角度，業務架構就是跨部門、跨組織的業務需求。

2）信息孤島——業務架構在國內“火”起來的契機

國內有個現象，一提到業務架構，就會大談信息孤島。這是為什么呢？因為國內真正開始重視業務架構設計，就是從解決信息孤島的痛點開始的。

21世紀初，國內的信息化進程從部門信息化推進到了企業信息化。企業部門間的（集團子公司間的）協同聯動需求，帶動了IT信息系統間的信息共享和協同聯動需求——同時產生了信息孤島問題（財務、人力資源、采購、銷售、OA、CRM各自為戰）。

因為信息孤島所具備的三大弊端，促使業務架構在國內火了起來，以下是三大弊端：

1. 無法協同—低效
2. 重復建設—浪費企業資源
3. 貽誤發展時機—這個影響最大，頭部企業錯失風口也會被趕超、變得落后

那如何解決信息孤島的問題呢？

在一系列系統分頭建設之前，先設計業務架構，定義統一藍圖，這是根本。數據一張圖、數據共享、流程打通、服務編排，都是圍繞統一藍圖具體展開。

業務架構是跨系統的，那么它和子系統的關系是什么樣的呢？

圖 2 – 1業務架構和子系統的關系

圖中的大V、小V分別表示什么呢？

• 一個大V，表示方案的業務架構、分期實現、上線驗收。
• 兩個小V，表示子系統的需求分析、程序開發、系統測試。

大V部分，是總體方案的生命周期。在大V的需求階段，必須研究和定義清楚跨部門、跨組織的業務需求，這些需求往往是跨系統的。例如，客戶報修業務功能明顯需要呼叫中心系統、CRM系統、工單系統協同聯動，才能支持客服接聽電話、確認客戶資料、記錄報修內容、派遣維修工程師上門這一連串操作。

小V部分，是某一個系統的生命周期。在小V的需求階段，必須分析和定義清楚這一個系統的需求，這些需求往往是系統內的。例如，CRM系統負責客戶資料管理。

綜上所述，方案級、子系統級這兩級生命周期是同時存在的。舉個典型的例子，某公司要做一個ERP系統，他會怎么做呢？

1）立項階段

由于方案涉及的范圍廣、部門多，所以有必要做業務架構設計。這時，由業務架構師擔綱業務架構設計，并提交《業務架構書》。

2）一期工程階段

假設主要涉及系統A的需求、開發、測試等。

這時需求分析員沖上去，負責《系統A需求說明書》，當然需求分析員要參考上游的《業務架構書》整體約定。

注：這里只所以說是假設，是因為實際操作中可能是實現某個業務功能需要同時開發系統A、系統B、系統C的部分功能，并不是說一期工程的所有功能必須隸屬于同一個系統。

3）二期和三期功能

假設主要涉及系統B的需求、開發、測試等。

這時這時需求分析員沖上去，負責《系統B需求說明書》，當然需求分析員要參考上游的《業務架構書》整體約定。

3. 實踐攻略：業務架構的實際工作內容

業務架構要想成功，首當其沖的是，架構師要做正確的事，即在業務架構的實際工作內容上有充足的經驗，不能遺漏。

相反，業務架構師分析環節的缺失，意味著業務架構藍圖規劃項的缺失，影響從投資角色到方案設計，到實施規劃，再到IT工作包和非IT工作包識別等所有后續工作。

業務架構 = 業務功能 + 組織結構 + 業務流程 +業務數據

業務架構的實際工作內容有哪些呢？

業務架構的前身是1982年IBM發布BSP等跨系統規劃方法，所以，業務架構本質上是跨系統規劃。

但是，業務架構的內容遠遠超過了跨系統需求分析這個范圍，覆蓋跨系統業務架構藍圖規劃這個更大的范圍。究其原因，是業務架構必須發揮從戰略向實施過渡的橋梁作用—上街公司戰略，下接IT實施和非IT實施。

不錯，業務架構也涵蓋了非IT部分的藍圖！

我們來看下細化的業務架構實際工作模型。

圖 2 – 2 業務架構藍圖

就大的方面而言，業務功能定義企業做什么？組織結構定義誰來做？業務流程定義怎么做？業務數據提供必要的支撐，因此，業務功能、組織結構、業務流程、業務數據四者，構成了業務架構藍圖的核心。

同時，商業模式揭示的是企業產品、企業核心資源、客戶、伙伴、渠道、成本、利潤之間的本質關系。商業模式這個現代工具，也是業務架構藍圖的必須規劃項。

就小的方面而言，第一，業務渠道在哪里？組織結構是圍繞部門、角色、職能展開的，而組織結構、業務渠道、合作伙伴是緊密相關的。所以，業務架構師在梳理組織結構的同時，應結合渠道戰略和合作伙伴戰略，定義業務渠道規劃，定義合作伙伴規劃，這些都是業務架構藍圖的“一等公民”。

第二，價值鏈在哪里？價值鏈模型是對一個企業所有生成經營活動的總體描述，是規劃業務架構藍圖時的必做項目?？梢詫I務功能進行三級劃分、層層分解：

• 頂級分解—做價值鏈模型
• 一級分解—做功能域分解
• 二級分解—做功能子域分解

第三，業務流程 = 主干流程 + 分支流程 + 業務規則：

主干流程通用性強，不易變。例如：買火車票時，“選票-搶票-支付”這個流程是穩定的。

分支流程個性化強，常變化。例如，選座分支流程，靠窗、不靠窗、坐票、臥鋪（上下中鋪），買兒童票、成人票、學生票也要進入分支流程。

業務規則細節性強、碎片化，所以建議一邊定義業務流程，一邊定義相應的業務規則。

綜上，業務架構藍圖的內容應該明確！全面！直觀！詳細！

上面我們學習了業務架構包含的內容，可能不夠直觀，我們通過案例來加深我們對每個模塊的理解。

1）業務架構藍圖五要素

我們借助業務架構藍圖五要素，管窺一下中國鐵路12306平臺的業務架構。

• 目標業務功能：線上購票、線上支付、線上退票等
• 目標組織結構：在原組織結構基礎上，新建IT運維中心
• 目標業務流程：先登錄、后搶票、再支付、超時未支付則釋放票源
• 目標商業模式：線上購票，省事省力（這個僅是價值主張）
• 目標業務數據：用戶賬戶、列車時刻表、坐席數據、訂單、支付記錄等

2）業務渠道、合作伙伴、價值鏈

下圖分析了證券公司的業務功能與相對應的業務渠道：

圖 2 – 3 用價值鏈來分析業務

價值鏈包括核心業務層和支撐層，這里的核心業務層屬于價值鏈對業務功能和服務的頂級分解。

經紀業務包括客戶開發、交易功能、客戶服務，業務功能分為三個層級，頂級分解、一級分解、二級分解，這三個是業務功能的頂級分解。

從圖中我們知道該證券公司有四個核心業務，分別是經紀業務、自營業務、資產管理、企業融資。

相關傳統渠道，主要是營業部柜臺；相關電子渠道，可以是綜合服務門戶、客戶端、手機APP等；公司員工可以通過綜合管理門戶完成日常工作與協調。

4. 實踐攻略：戰略驅動的業務架構的步驟

在做規劃時我們常采用GAP分析法，先確定當前現狀，然后給出我們的期望，分析目標和期望的差距。如果有人和一個新手這樣說，可能是不夠的，你至少需要回答以下幾個疑問：

• 業務架構師具體要分析什么？怎么才算是戰略驅動？——能否具體到政策文件？戰略方針？市場調研？友商對標？
• 從戰略到藍圖，中間的邏輯是什么？——能否具體到小目標分解？小策略制定？
• 我們首先應該怎么做？——就連一個小的進銷存系統，也要先進行業務調研，不是嗎？

1）落地：設計步驟

我們看下作者分享的戰略驅動的業務架構（BA）設計三步法。

圖 2 – 4 業務架構的設計步驟

圖中的三大步很明確，也非常貼近實際。

優點1：明確的戰略驅動起點。方法中明確了三種戰略驅動因素（Drvier）的類型，因為實際中就是國家政策、企業戰略、對標友商者三者之一觸發了后續的調研、規劃與實施。

優點2：明確的調研環節，在第一步中，包含了調研環節。

優點3：強調了從戰略到藍圖的過渡邏輯，在第2大步中，扎扎實實地規劃好業務架構目標/策略，才能確保藍圖充分支撐戰略。這一步屬于高層級業務架構設計。

優點4：目標藍圖與Gap分析并重，在第3大步。

設計BA目標藍圖這一步屬于低層級業務架構設計，其中Gap環節是必須環節，我們必須識別出業務架構的增量有哪些，給出對應的實施措施。

Gap分析的價值在于，它是持續進行架構治理所必需的，除了BA規劃環節應用，在AA、DA、TA設計環節也均有應用。

2）要點：明確Driver，做好調研

業務架構設計必需做好的第一件事，就是100%明確戰略驅動因素是什么。

業務架構設計必須做好的第二件事，就是調研。通過調研，廣度上理解企業的宏觀環境、行業趨勢，縱深上理解戰略的前因后果、來龍去脈、橫向上理解企業的競爭格局、友商動向。

粗看，調研范圍很廣，讓人理不清頭緒。細看卻有規律，主要三條線，分別是管理層訪談、戰略的來龍去脈、可借鑒案例。

圖 2 – 5 業務架構設計需要調研的內容類別

3）要點：從戰略到藍圖的內在邏輯

從戰略到藍圖的內在邏輯，由四個概念支撐起的骨架：

1. Driver：戰略驅動因素
2. Goal：業務架構目標
3. Strategy：業務架構策略
4. Blueprint：業務架構藍圖

這是一個大型企業，推進數字化采購轉型如何從戰略到藍圖的構建邏輯，相信它有助于我們的理解以下幾點。

圖 2 – 6 戰略到藍圖的內在邏輯

1. 圖中從上到下是Driver、Goal、Strategy、Blueprint四層體系
2. Driver層：1個戰略驅動因素，公司向數字化轉型
3. Goal層：3個業務架構目標，可以理解成數字化轉型的具體目標分解
4. Strategy層：10項業務架構策略，理解成3個Goal需要提升的能力。最關鍵的一點是，10項策略完全圍繞業務架構藍圖5要素展開，如組織業務架構提升、業務功能提升等
5. Blueprint層：按業務架構藍圖五要素定義藍圖，這是業務架構師的主要工作

綜上所述，從戰略到藍圖的內在邏輯主線是：確定Driver—目標分解—策略設計—藍圖定義。邏輯明確，創新有據。

只有業務架構師真正洞悉了戰略意圖、準確領會了戰略動機，之后的業務架構設計工作都是有跡可循的，工作量再大，也不可怕。

4）工具：GAP分析

• 內容1：列出基線業務架構，以及目標業務架構的高層描述
• 內容2：對比分析，識別GAP——業務能力差距、IT能力差距

5. 實踐案例

1）數字化轉型–確定Driver，做好調研

①推進：確定Driver

項目假定為：某鐵路數字化服務轉型工程。

業務架構師（張三）知道業務架構的Driver是整個業務的起點，必須找準、吃透。

張三了解到，數字化轉型工程的Driver是公司剛制定的《公司戰略規劃》。

《公司戰略規劃》中闡述了數字化服務轉型的背景：近年來，互聯網技術的發展，提高了各行各業的服務水平，極大方便了人們群眾的衣、食、住、行、醫、學、玩等方面。從企業的角度而言，借助互聯網、大數據等技術，積極推動數字化轉型，擁抱以客戶為中心的服務模式，能搞提高客戶滿意度和企業競爭力。

《公司戰略規劃》中和數字化轉型戰略的核心表述是：樹立以人為本、客戶至上的服務理念，創新服務方式，完善服務標準，推動數字化服務轉型，提高服務水平。

②推進：做好調研之管理層訪談

管理層訪談不是讓業務架構師去了解行業，而是要領會管理層的關注點、主要看法。

通過訪談，業務架構師應了解：

• 現狀：管理層認為當前的主要不足在何處？ 比如訂票不方便
• 目標：管理層希望變革達到的目標是什么？ 比如管理層希望建立網上綜合服務門戶
• 措施：管理層認為可能的舉措有哪些？比如運用互聯網
• 政策：管理層非常關注哪些相關政策？
• 對標：管理層特別關注的對標企業是誰？如：國外企業售票的做法
• 其他：管理層的其他關注點，如：提升企業形象

③推進：做好調研之可借鑒案例研究

研究可借鑒的最佳實踐、最佳案例，也是調研的必做內容。

究其原因，業界每個階段的最佳實踐、最佳案例，都反映了業界當時的實踐水平。所以，如果業務架構師收集并分了業界當前最佳實踐案例，就可以在自己負責的架構設計中更好的把握設計方向、制定設計標準。

2）數字化服務轉型—確定BA目標與策略

業務架構目標和策略包含以下兩方面：

• 內容1：闡述業務能力短板，確定業務架構目標
• 內容2：闡述在組織結構、業務流程、業務功能、商業模式、渠道創新等方面的具體策略。并說明依據，如國外水平、對標分析、用戶調查、用戶畫像、數據統計、技術趨勢、機會節點等。

①推進：差距分析

Baseline Business Architecture：

圖 2 – 7 基線架構

Target Business Architecture：

圖 2 – 8 基線架構

上述案例，我們通過GAP分析，識別了業務能力差距和IT能力短板，從而識別業務架構目標與策略，這是采用自底向上的方法。

為我們后續環節做準備，比如我們識別出了核心業務需要增強的包括銷售、客運、貨運、清算、售后，新增的包括增值業務，在制定在業務功能、業務流程、業務數據、組織結構、商業模式模塊給出對應的策略。

如：從上圖價值鏈分析中看到，我們新增的業務需求是增值業務，通過電商業務、旅游代理可以實現，再進一步想一下，就會知道我們的目標是增收，接著可以自頂向下思考，增收除了電商業務、旅游代理，我們還可以做保險代理，通過服務門戶這個渠道觸達用戶。

②推進：確定目標與策略

只有扎扎實實地規劃好業務架構目標與策略，才能確保后續業務架構藍圖定義充分支撐戰略。

確定業務目標與策略環節，是業務架構設計的高層部分。后續的業務架構藍圖定義，是業務架構設計的低層部分。前者引領者后者的發展方向，由此可見“確定業務架構目標與策略”這一環節的重要性。

這一步，有三種做法：

1. 自頂向下：將Driver分解為子目標，將子目標映射到業務架構策略
2. 自底向上：通過Gap分析，找到能力短板，從能識別業務架構目標與策略
3. 上述兩種做法相結合，循環展開，互為驗證

鐵路系統數字化轉型，提高服務水平是Driver，如何才能達到這個終極目標？

答案是：

• 便民：例如提供在線訂票服務，呼叫中心服務
• 增效：用取票機、檢票機提高檢測效率和準確性，同時也降低了用人成本
• 增收：提供服務門戶

圖 2 – 9 確定目標與策略

3）數字化服務轉型—定義BA藍圖（組織結構）

圖 2 – 10 組織結構視圖的內容

組織結構視圖包括三個模塊，組織結構、業務渠道、合作伙伴。

組織結構及改進主要描述部門設置、崗位設置、崗位職責等；合作伙伴及改進主要描述加強與供應鏈上下游的合作伙伴之間的關系。業務渠道創新也是業務架構設計的常見策略，下面會舉例說明。

組織結構：下圖是運用GAP分析的方法，畫出當前組織結構和目標組織結構，并表示出變動點。

圖 2 – 11 組織結構GAP分析

新手業務架構師往往認為組織結構沒啥好設計的，其實恰恰相反，一旦組織結構需要變革，必然影響重大。

從上圖，我們可以看出來，之前企業自己做IT開發，目前公司計劃在做開發的同時，自己也做IT運維。相應的，企業組織結構新增了IT運維中心。

業務架構師應盡早明確組織結構的可能變化。因為無論是新建部門，還是部門增強、人員能力增強，都屬于TOGAF中的能力增量，是需要后續非IT工作包實現的。

不僅如此，組織結構的變化還影響整個企業的治理結構，從經營管理，到制約監督，再到績效考核。

總之，業務架構師雖然經常被當做跨系統軟件需求分析師降級使用，但真正承擔業務架構藍圖規劃任務的業務架構師，是必須能扛得起很多“非IT”規劃的。

4）數字化服務轉型—定義BA藍圖（業務渠道）

渠道在百度百科上的解釋是“比喻達到某種目的的途徑”，業務渠道就是用戶為了達成業務目的的途徑。如下圖，列車長通過補票終端這個渠道幫助用戶完成補票，客運公司通過大屏幕告知乘客車次信息。

業務渠道創新示例：

圖 2 – 12 業務渠道設計案例

網站、手機APP、補票終端、大屏實現了購票、補票、查看車次信息線上線下聯動，提升了用戶體驗和公司內部效率。

由上圖可知，業務渠道不是完全孤立的業務架構藍圖規劃項，它和業務流程、業務功能、組織結構是相互呼應的。因此，我們規劃業務渠道時，也應考慮這些。

關于渠道聯動，有同行這樣總結：

• 低層次：信息孤島，豎井林立，客戶在手機上買了票，在PC上竟然查不到
• 一般層次：信息共享，多個前端共用統一的后臺系統
• 高層次：渠道聯動，流程拉通，多崗位、多前端、多應用之間流暢的流程協同

5）數字化服務轉型—定義BA藍圖（業務功能）

圖 2-13 業務功能視圖

企業是由一系列為顧客制造價值的活動和功能組成的，我們的業務功能就源自于可以為顧客制造價值的活動和功能。

企業的價值鏈展示了企業的設計、生產、營銷、運輸等為顧客創造價值的一系列活動、功能以及業務流程之間的連接情況。價值鏈有兩個主要的組成部分：

• 核心業務：創造主要的顧客價值
• 支持活動：為核心業務提供支持服務

繼續來看運輸公司數字化服務的案例，業務架構師，面對運輸企業數字化服務轉型的任務，經過潛心研究，給出了下圖的價值鏈劃分結構。

圖 2 – 14 運用價值鏈分析業務功能

有的同學可能會有疑問，為什么會在核心業務模塊同時存在客運和貨運兩個區別較大的業務類型？在實際工作中可能只負責客運、貨運其中一個模塊。

前面我們業務架構出現的背景也有提到，在國內業務架構是為了解決信息孤島發展起來的，業務架構師就是要在全局做規劃，而不是梳理單個系統。

以上我們已經整理了價值鏈，現在我們要分解功能域了，下圖是一級功能域分解圖：

圖 2 – 15 一級功能域拆分

接下來，做業務能力Gap分析，我們可以看到新增的一級功能域有4個，增強的一級功能域有13個。

通過價值鏈分析到一級功能域劃分的轉變，我們會有以下收獲：

① 價值鏈分析模型為后續功能域劃分奠定了基礎，管理支持+核心業務這個業務功能呢域劃分框架確實很好用，并且廣受業界認同，在溝通的過程中自然也容易被其他人接受。

②類似“上車前、上車中、下車后”時間軸思維，是業務架構師必備的分析技能，同時，是甲方企業領域專家們經常使用的分析習慣。

業務架構設計不僅要定義出目標架構，還要使用GAP分析法，識別出需要增強的架構能力，為后續實施做準備。具體包括業務功能變化與增量、組織結構變化與增量、業務流程變化與增量、業務數據變化與增量。

6）數字化服務轉型—定義BA藍圖（商業模式）

商業模式揭示的是企業產品、企業核心資源、客戶、伙伴、渠道、成本、利潤之間的本質關系。簡單說，就是為什么同樣的事，有的企業行，有的企業不行。

制定商業模式時并不是說全局只有一個商業模式，我們可以根據我們的目標分別制定商業模式，比如上述案例中，該鐵路運輸公司的目標有三個：便民、增收、增效，我們就可以設計三個商業模式。

就鐵路企業的數字化服務轉型而言，要便民，應支持隨時通過網絡、電話、手機App獲取企業服務。

圖 2 – 16 目標為便民時的商業模式

就鐵路企業的數字化服務轉型而言，要增效，可以借助硬件設備和智能控制系統，促進取消、檢票等環節的數字化轉型，提升效率。

圖 2 – 17 目標為增效時的商業模式

商業畫布，借助九個小格子，構建了簡介高效的系統化思維環境，是個了不起的發明。

從上述例子可以看出，商業模式有如下優勢：

• 利于有效設計，可以激發服務創新、流程創新、跨界合作等好的創意
• 利于有效匯報，商業模式凸顯了“為什么這么干”的內在邏輯

個人認為，商業模式融合了BRD和MRD的內容：

• BRD：商業需求文檔，關注為誰（客戶細分）、解決什么問題（價值主張）、需要做什么（關鍵活動）、花費什么資源（關鍵資源）、性價比（成本/收入）如何
• MRD：市場需求文檔，關注消費者怎么觸達（渠道通路）、怎么獲得合作伙伴

7）數字化服務轉型—定義BA藍圖（業務流程）

業務流程視圖是應用架構的輸入，也是業務架構中最落地、篇幅最大的章節。

作者在文章中對業務流程的協作方法進行了論述，結論是簡單的業務流程可以采用流程圖的方式繪制，業務流程分支較多且復雜的強烈建議使用文本化描述。

業務流程定義規范：

• 第一部分：業務功能概述，業務功能通過主干流程和分支流程實現，要點是“1個主干+N個分支”方式的流程分解

• 第二部分：主干流程，要點是“階段化+步驟化”，并附每步業務或數據模型規則

• 第三部分：分支流程，要點是“注明在主干流程的分叉位置”，并附每步的業務或數據模型規則

• 第四部分：關鍵UI原型/UI流程，這部分為可選

圖 2 – 18 業務功能概述

圖 2 – 19 主干流程

圖 2 – 20 分支流程

圖 2 – 21關鍵UI原型：UI流程

這部分很重要，上面也有提到，業務流程視圖是應用架構的輸入，所以對這塊再總結一下。

我們發現，分支流程和業務場景有完美的對應關系。識別分支流程，就是場景化思維。相反，如果不區分主干流程、分支流程，后續業務需求變更會波及一大片，而不是改一個分支流程這么簡單了，這太不專業。

業務功能很多，業務場景更多，業務流程定義了什么呢？業務流程定義一個業務功能，其中包括多個業務場景。比如購票包括了多人購票、購買兒童票等。

業務規則多如牛毛，如何避免業務規則碎片化？圍繞業務步驟定義業務規則，業務步驟可以是主干流程步驟、分支流程步驟。

關于是否使用業務流程圖：越是核心的業務流程，越是分支多、業務規則多，此時建議采用文本化規范，這樣呈現的信息更加全面。不復雜的業務流程，可以沿用流程圖的方式。

三、總結

這篇文章對企業架構進行了概述，詳細講述了業務架構出現的背景及實際攻略，并通過實際案例加深我們對業務架構的理解。

我們來一起回顧一下文章中涉及到的概念之間的關系。

• 企業架構 = 業務架構 + 應用架構 + 數據架構 + 技術架構
• 業務架構 = 組織結構 + 業務功能 + 業務流程 + 業務數據 +商業模式
• 業務功能 = 頂級價值鏈 + 第一層功能域分解 + 第二層功能子域分解
• 商業模式 = 商業模式畫布分析
• 業務數據 = 數據域 + 數據模型 + 數據規則

戰略驅動的業務腳骨設計實戰步驟，精華在于，從戰略到業務架構藍圖的跨度太大，邏輯鏈條接不上氣，所以分兩步走：

• 從戰略到策略
• 從策略到藍圖

如果讀完之后感覺通過企業架構可以提升自我、有利于公司發展，就行動起來吧！

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

題圖來自Unsplash，基于CC0協議