原創(chuàng)2025-01-06小艾老師

TOGAF企業(yè)架構師認證知識體系考證須知證書含金量培訓大綱 3分鐘小視頻我要提問

TOGAF 認證是 The Open Group 頒發(fā)的架構框架專業(yè)認證，是企業(yè)在規(guī)劃、設計、實施和管理 IT 架構時所使用的一種方法和標準。它提供了一個開放的、靈活的、可擴展的方法來構建、部署和管理企業(yè)的 IT 架構，幫助企業(yè)提高 IT 效率、降低成本、提高業(yè)務靈活性和創(chuàng)新能力。

中文名TOGAF企業(yè)架構師認證
英文名The Open Group Architecture Framework
英文簡稱TOGAF
頒證機構The Open Group
證書類別企業(yè)架構（業(yè)務架構，數(shù)據(jù)架構，應用架構，技術架構）
同類認證SAFe for Architects、CBA

今天我們來聊聊TOGAF 10中的一個重要概念——業(yè)務場景，以及如何創(chuàng)建一個切實可行的業(yè)務場景。話不多說，直接開始！

01?業(yè)務場景是啥？

很多小伙伴可能一提到“業(yè)務場景”，腦袋里就想到了“什么是業(yè)務需求”“客戶的需求到底是什么”，但實際上，業(yè)務場景可不光是“需求”那么簡單。它是描述一個特定商業(yè)環(huán)境下，系統(tǒng)、流程和角色如何交互的一個框架。簡單來說，業(yè)務場景幫助我們從整體上理解“現(xiàn)在的業(yè)務環(huán)境是怎樣的，未來我們希望它變成什么樣”。用《場景革命》中的一句話來說明場景的重要性：產(chǎn)品解決一個問題，場景持續(xù)解決問題。

如何用架構的視角來看待“業(yè)務場景”？TOGAF 10系列指南中明確指出：業(yè)務場景本質上是業(yè)務問題的完整描述，包括業(yè)務和架構方面的內容，確保各個需求在問題的上下文中關聯(lián)起來。

02?業(yè)務場景的創(chuàng)建過程

創(chuàng)建一個業(yè)務場景其實并不是拍腦袋的事，而是需要系統(tǒng)性思考。TOGAF 10的業(yè)務場景創(chuàng)建模型由5個部分組成（與TOGAF 9.2的7個步驟稍有不同），這5個部分幫助我們系統(tǒng)性地創(chuàng)建業(yè)務場景，確保業(yè)務、技術和架構的結合更加緊密。

Problem：識別和記錄問題驅動因素

首先，明確問題的來源和性質，并將其文件化和定級。這一步的關鍵是了解為什么需要這個業(yè)務場景，以及它對業(yè)務的影響程度。

示例：假設你在一家電商公司，當前的退貨流程太復雜，用戶不滿意，客服投訴率高。這就是一個明確的“問題驅動因素”，需要在業(yè)務場景中予以記錄。

Environment：識別業(yè)務和技術環(huán)境

明確業(yè)務和技術環(huán)境，并在業(yè)務場景模型中文件化。這一部分包括與業(yè)務場景相關的業(yè)務模型、技術模型和操作環(huán)境的描述。

示例：繼續(xù)上面的例子，當前的業(yè)務環(huán)境是：客戶提交退貨申請，人工客服手動確認退貨信息，耗時長、效率低。目標業(yè)務環(huán)境可能是：通過App自動提交退貨申請，系統(tǒng)自動審核，減少人工介入。

Outcomes：識別并文件化目標（“SMART”）

目標必須是“SMART”的，即具體的（Specific）、可衡量的（Measurable）、可實現(xiàn)的（Achievable）、相關的（Relevant）、有時限的（Time-bound）。

示例：

不具體的目標：提升客戶滿意度。
具體的SMART目標：在未來3個月內，將退貨流程從5天縮短到2天，客戶滿意度提高10%。

Human Actors：識別人員施動者（參與者）

在業(yè)務場景中，明確與業(yè)務場景相關的人員及其角色，并描述他們在業(yè)務模型中的位置。參與者可能包括客戶、員工、管理員、外部合作方等。

示例：在退貨業(yè)務場景中，人員施動者包括：

客戶：提交退貨申請，提供反饋。
客服：跟進客戶退貨請求，提供幫助和支持。
倉庫管理員：處理退貨的商品驗收和入庫。

Computer Actors：識別計算機施動者（系統(tǒng)元素）

明確在業(yè)務場景中起作用的計算機系統(tǒng)和技術元素，并標明其在技術模型中的位置。這包括應用程序、數(shù)據(jù)系統(tǒng)、自動化工具等。

示例：

退貨管理系統(tǒng)：自動記錄和處理客戶的退貨申請。
客戶服務系統(tǒng)：客服使用的客戶支持工具，用于查看退貨狀態(tài)。
庫存管理系統(tǒng)：用于監(jiān)控退貨商品的入庫和處理。

03?通過創(chuàng)建業(yè)務場景解決工作中的一些常見問題

接下來，我們用一些現(xiàn)實工作中的問題來具體說說怎么創(chuàng)建業(yè)務場景。

1.客戶抱怨：“我們的業(yè)務系統(tǒng)太慢了！”

假設你是負責IT架構的主管，某個部門的同事跟你抱怨：“我們的業(yè)務系統(tǒng)太慢了，每天操作一堆數(shù)據(jù)，要花好幾個小時?！边@時候，傳統(tǒng)的做法可能是急急忙忙開會，討論怎么加速系統(tǒng)性能。但如果從TOGAF的角度來看，這個問題的背后其實可能隱藏著更深層次的業(yè)務需求和痛點。

在TOGAF中，我們可以通過創(chuàng)建一個“業(yè)務場景”，明確：這個慢系統(tǒng)是因為數(shù)據(jù)量大，還是業(yè)務流程太復雜？或者是技術架構不匹配？通過梳理出這些場景，我們就能找到根源，而不是簡單的“加速”系統(tǒng)。

關鍵問題：

定義場景背景：系統(tǒng)慢的背景是什么？是因為用戶同時操作太多，還是數(shù)據(jù)存儲處理效率低？
描述業(yè)務需求：到底是因為快速查詢需求，還是是其他操作對性能要求過高？
分析影響因素：是業(yè)務流程問題，還是技術架構問題，還是數(shù)據(jù)管理的問題？

通過這些步驟，你就能建立起一個具體的業(yè)務場景，從而為后續(xù)的解決方案提供有力支持。

用TOGAF10中的方法創(chuàng)建業(yè)務場景：

步驟	詳情
識別和記錄問題驅動因素	問題：業(yè)務系統(tǒng)響應時間過長，操作員需要花費大量時間處理數(shù)據(jù)，直接影響業(yè)務處理效率和客戶響應時間。驅動因素：數(shù)據(jù)量增長過快，系統(tǒng)設計未考慮高并發(fā)，查詢和處理邏輯不夠優(yōu)化。
識別業(yè)務和技術環(huán)境	業(yè)務環(huán)境：客戶服務部門的操作員每天需要在系統(tǒng)中錄入和查詢客戶訂單信息。技術環(huán)境：使用傳統(tǒng)的集中式數(shù)據(jù)庫架構，未部署緩存和異步處理機制，前端系統(tǒng)依賴手動查詢，未實現(xiàn)批量操作。
識別并文件化目標（SMART 原則）	具體（S）：將系統(tǒng)查詢時間從30秒減少到5秒內。可衡量（M）：在2個月內實現(xiàn)操作速度的提升，并通過性能測試驗證。可實現(xiàn)（A）：通過數(shù)據(jù)庫索引優(yōu)化、引入緩存技術等手段實現(xiàn)。相關性（R）：提高系統(tǒng)響應速度，直接改善客戶服務效率和客戶滿意度。時間限制（T）：2個月內上線新方案。
識別人員施動者	操作員：客戶服務部門的前臺人員需要快速查詢客戶訂單數(shù)據(jù)。管理者：客戶服務部門的主管需要監(jiān)控操作效率，衡量改進效果。
識別計算機施動者	數(shù)據(jù)庫：傳統(tǒng)的關系型數(shù)據(jù)庫，可能需要調整索引或采用更高性能的數(shù)據(jù)庫方案（如NoSQL）。中間件：考慮是否需要使用緩存中間件（如Redis）來加速常用查詢的響應時間。前端系統(tǒng)：需要優(yōu)化前端的查詢邏輯，避免不必要的請求，或啟用本地緩存。

2.團隊成員：我們部門的溝通不暢，很多時候信息共享不到位

再比如，很多公司都有部門間溝通不暢的問題。有時，一個部門根本不知道另一個部門的需求，而另一個部門也不知道自己的需求變化已經(jīng)影響到了他人。這種信息不對稱經(jīng)常導致重復工作、效率低下。

如果按照TOGAF的思路來做，我們可以通過“業(yè)務場景”來理清楚：在不同的部門和職能之間，信息流是如何流動的，哪些環(huán)節(jié)可能出現(xiàn)瓶頸，哪些環(huán)節(jié)又沒有產(chǎn)生足夠的價值？

關鍵問題：

界定場景范圍：這不是一個部門的問題，而是整個公司的流程都沒有優(yōu)化?？梢詮目绮块T合作入手，看看是否有工具可以促進信息的流動。
分析場景影響：如果溝通不暢，部門之間的協(xié)作就會受到阻礙，導致業(yè)務延誤，影響客戶體驗。
定義解決方案：是否需要一個協(xié)作平臺，或者一個統(tǒng)一的信息系統(tǒng)？這就是一個TOGAF框架下的具體業(yè)務場景，它幫你看清問題所在，并找到解決辦法。

用TOGAF10中的方法創(chuàng)建業(yè)務場景：

步驟	詳情
識別和記錄問題驅動因素	問題：不同部門之間的信息共享不及時，造成項目延遲和客戶投訴增加。驅動因素：各部門依賴獨立的溝通工具（如郵件、微信群等），缺乏統(tǒng)一的協(xié)作平臺，導致信息流不通暢，信息滯后和冗余問題頻發(fā)。
識別業(yè)務和技術環(huán)境	業(yè)務環(huán)境：市場部、銷售部和產(chǎn)品開發(fā)部門需要協(xié)同工作，頻繁共享客戶需求、銷售反饋和產(chǎn)品開發(fā)進度。技術環(huán)境：部門依賴獨立的工具（如郵件和Excel）共享信息，缺乏統(tǒng)一的協(xié)作平臺和工作流工具。
識別并文件化目標（SMART 原則）	具體（S）：在1個月內上線一個統(tǒng)一的協(xié)作平臺，取代各部門的分散工具。可衡量（M）：協(xié)作平臺的使用率達到80%，并減少20%的郵件流量和延遲響應時間。可實現(xiàn)（A）：通過引入如Worktile、騰訊TAPD、PingCode等現(xiàn)成的SaaS協(xié)作工具來實現(xiàn)。相關性（R）：提高信息共享的速度和準確性，減少項目延遲，提升客戶滿意度。時間限制（T）：在1個月內完成部署和員工培訓，2個月內實現(xiàn)全面使用。
識別人員施動者	業(yè)務用戶：市場部、銷售部和產(chǎn)品開發(fā)團隊的成員是關鍵用戶，需要接受新平臺的培訓并使用平臺。管理者：各部門的主管需要推動員工采用新平臺，并監(jiān)控使用率和效果。
識別計算機施動者	協(xié)作平臺：如Worktile、騰訊TAPD、PingCode等工具，提供跨部門的溝通和協(xié)作支持。移動設備和桌面設備：確保平臺支持手機端和桌面端的使用，方便隨時隨地訪問信息。

3.IT部門和業(yè)務部門“脫節(jié)”了

另一個常見的問題是，IT部門和業(yè)務部門的需求常常無法對接。IT部門認為自己的技術能力很強，業(yè)務部門卻總是覺得IT無法理解他們的實際需求。這個脫節(jié)看似是溝通問題，但深入一看，往往是兩者在目標和視角上的差異。

在TOGAF中，業(yè)務場景幫助我們明確，IT和業(yè)務之間的差異不僅僅是語言不通，而是兩者從不同的角度看待問題。IT往往聚焦于技術細節(jié)，而業(yè)務則更多關注“這個技術能解決什么實際問題”。

關鍵問題：

定義目標和需求：明確IT部門和業(yè)務部門各自的目標。比如IT關注系統(tǒng)穩(wěn)定性和安全性，而業(yè)務關注如何提升用戶體驗和加速市場反應。
識別關鍵問題：這個場景里，業(yè)務和IT之間_大的鴻溝是什么？是不是業(yè)務對技術要求不夠清晰，還是IT沒有提前與業(yè)務討論需求？
尋找連接點：通過業(yè)務場景的創(chuàng)建，可以發(fā)現(xiàn)雙方的共同目標，比如提升客戶滿意度，縮短開發(fā)周期等，從而幫助雙方對齊目標。

用TOGAF10中的方法創(chuàng)建業(yè)務場景：

步驟	詳情
識別和記錄問題驅動因素	問題：IT部門與業(yè)務部門的目標不一致，導致IT交付的系統(tǒng)未滿足業(yè)務需求。驅動因素：業(yè)務需求未明確定義，IT部門的關注點偏向技術實現(xiàn)，忽略了業(yè)務目標。
識別業(yè)務和技術環(huán)境	業(yè)務環(huán)境：業(yè)務部門希望推出一款新產(chǎn)品，并要求快速上線，但IT部門的系統(tǒng)交付周期較長，導致新產(chǎn)品上市延遲。技術環(huán)境：IT團隊采用敏捷開發(fā)方式，但未與業(yè)務部門對接優(yōu)先級和關鍵需求，需求不斷變更。
識別并文件化目標（SMART 原則）	具體（S）：建立業(yè)務和IT的聯(lián)合項目組，以確保業(yè)務需求的傳達和優(yōu)先級的確定。可衡量（M）：在3個月內實現(xiàn)需求的透明化，減少50%的需求變更次數(shù)，并縮短項目交付時間20%。可實現(xiàn)（A）：通過Scrum儀式中的"需求澄清會"，確保IT與業(yè)務的對齊。相關性（R）：IT和業(yè)務目標一致有助于確保項目交付的成功率，避免項目延誤或失敗。時間限制（T）：3個月內實施聯(lián)合項目組的機制，并開始跟蹤需求變更次數(shù)。
識別人員施動者	業(yè)務用戶：市場部的業(yè)務分析師需要明確定義業(yè)務需求，并參與Scrum會議。 IT開發(fā)人員：開發(fā)團隊的架構師和開發(fā)人員需要定期參與與業(yè)務的溝通，確保需求明確。
識別計算機施動者	項目管理工具：如Jira、Trello或其他敏捷項目管理平臺，確保業(yè)務和IT能夠在一個平臺上透明化溝通和管理需求變更。開發(fā)工具：如GitHub和CI/CD工具，支持IT團隊的敏捷開發(fā)。