共用方式為


使用流程優化工作負載設計

本文涵蓋使用流程的目標工作負載優化。 工作負載的不同元件有不同的需求和重要性層級。 藉由將工作負載分割成流程,您可以排定工作負載的不同部分的優先順序,並更妥善地讓工作負載投資與每個流程的重要性保持一致。

此工作負載優化程式是反覆的,且牽涉到三個主要步驟:(1) 定義工作負載內的流程結構、(2) 定義技術需求,以及 (3) 設計流程以符合需求(請參閱圖 1)。

此圖顯示具有五個動作的三步驟程式。第一個步驟是定義流程。若要定義流程,您必須瞭解必要條件並記錄流程。第二個步驟是定義流程需求。若要定義流程需求,您必須建立技術目標。第三個步驟是設計流程。若要設計流程,您必須遵循流程設計最佳做法,並開發和測試流程。建置和測試動作有一個箭號回到第一個動作(瞭解必要條件),指出此程式的反覆專案。圖 1:使用流程優化工作負載的程式。

定義流程

在定義流程需求之前,您必須瞭解流程的商業驅動因素。 定義流程的必要條件是識別商務程式及其支援使用案例。 當您瞭解必要條件時,可以開始記錄流程。

了解必要條件

流程是支援工作負載功能的動作序列。 流程有兩種主要類型:使用者流程和系統流程。 使用者流程會決定用戶互動。 系統流程會決定工作負載元件之間的通訊。 流程支援商務程式和使用案例。 工作負載是由多個使用案例所組成。 您需要在記載流程之前,先識別流程支援的商務程式和使用案例(請參閱圖 2)。

顯示兩個方塊的圖表,彼此堆疊在一起。頂端方塊代表商務程式,其區段標示為階段 1、階段 2 和階段 n,表示商務程式中的階段序列。從每個階段,三個垂直箭號會向下指向三個方塊的數據列,代表不同的使用案例。每個方形分別標示使用案例、使用案例 2 和使用案例 n。每個方塊都包含具有標籤流程流程 1、Flow 2 和 Flow n 的唯一流程圖。使用案例全都是單一工作負載的一部分。商務程式的每個階段都會連結到特定的工作負載使用案例,而每個使用案例都有自己的流程。圖 2:商務程式、使用案例、流程和工作負載之間的關聯性。

識別商務程式

商務程式是一系列符合商務需求的動作(階段)。 流程會決定使用者或數據完成商務程式每個階段所採用的順序。 例如,在線銷售產品是商務程式。 此商務程式中的階段可能是在線列出產品、接收訂單,以及提供產品。

識別使用案例

使用案例會定義流程的功能需求。 您需要先識別並瞭解流程支援的使用案例,再建立流程的技術需求。 每個使用案例都應該在商務程序中支援一個階段(請參閱圖 2)。 使用案例應該定義下列屬性:

  • 目的:清楚說明工作或目標,例如啟用在線購買。 此明確性會引導功能設計,並設定流程設計的明確目標。

  • 重要性:評估使用案例的重要性,範圍從例程到重大。 指派給使用案例的值會通知流程的優先順序和設計。 高價值使用案例可能需要增強的錯誤處理、效能微調或用戶體驗考慮。

  • 取用者:識別使用者(客戶、員工)或系統元件是否為主要取用者。 此分類決定其為使用者流程或系統流程,並影響設計。

  • 事件:定義起始和結束使用案例的觸發程式或條件。 這些事件會定義流程的界限。

  • 執行:瞭解使用案例的作業頻率和變異性,以預期系統負載。 您必須設計流程來處理不同的執行案例。

  • 相依性:識別與其他風險管理使用案例的相關性。 辨識使用案例的相依性有助於設計與其他系統元件順暢整合的流程。 您必須確保輸出與後續進程的必要輸入和相容性的可用性。

記錄流程

使用案例來記錄流程。 您應該概述或對應流程中所需的每個動作。 擷取決策準則和路徑。 識別與其他使用案例的互動。 此大綱可作為流程設計和管理的藍圖。 您也需要擷取流程的相關商務資訊。 請務必在流程檔中包含下列詳細資料:

  • 流程描述:流程的高階描述。

  • 商務程式:流程支援的商務程式。

  • 進程擁有者:擁有商務程序的個人。

  • 項目關係人:您應該通知或諮詢流程狀態或變更的個人。

  • 呈報路徑:您應該連絡的個人或群組來解決問題。 這是一連串的人。 個人責任的範圍與路徑上的每個人一起成長。

  • 業務影響:此流程對企業的重要性。

  • 重要性評等:指出流程相對重要性的質化標籤。

如需詳細資訊,請參閱 流程範例

定義流程需求

利用使用案例來建立流程的技術目標。 為符合良好架構架構 (WAF) 五個支柱的流程定義可測量的目標。 這些要素提供設定技術目標的架構:

  • 可靠性目標:評估每個流程的重要性,並據此設定可靠性目標。 判斷效能閾值,並建立明確的服務等級協定 (SLA) 和目標 (SLA)。 較高的關鍵性流程需要更嚴格的可靠性目標。

  • 安全性目標:根據數據敏感度和用戶活動分析每個流程的安全性需求。 實作並持續更新安全性措施以符合這些需求,同時確保符合法規標準。

  • 成本目標:瞭解每個流程的需求,以取得有效的資源配置。 設定目標以平衡成本與效能。 請確定資源使用量符合商務優先順序。

  • 操作目標:定義有效監視和疑難解答的計量。 目標應確保有效率的資源使用,並與組織目標保持一致。

  • 效能目標:以每個流程的初始需求為基礎效能目標。 確保基本流程接收足夠的資源,並持續調整目標,以符合不斷演進的需求,並增強用戶體驗。

設計流程

設計流程以符合技術目標。 您應該熟悉流程設計最佳做法,以達到正確的結果。 建置及測試流程。 反覆運算設計,直到它符合您建立的技術目標為止。

遵循流程設計最佳做法

當您設計流程時,請遵循流程設計最佳做法。 設計良好的流程具有下列屬性:

  • 範圍:識別每個流程的相異起點和結束點。 清除界限有助於優化使用者或系統互動。

  • 邏輯: 使用邏輯步驟順序設計流程。 針對最有效率的路徑進行優化,並減少不必要的步驟。

  • 維護:易於更新和維護的設計流程。 使用模組化元件,您可以修改,而不會影響整個工作負載。

  • 定義:納入觸發或引導流程中每個步驟的特定條件。 此精確度可確保流程能準確地回應使用者輸入、數據變更或系統狀態。

  • 可靠:在您的流程中建置錯誤處理和例外狀況路徑。 有效的錯誤管理可防止中斷,並在非預期的情況下維護流程完整性。

  • 可調整:確定它可以處理不同的負載,並適應成長或縮小使用者基底或數據磁碟區。

  • 安全:在流程中內嵌安全性措施。 保護數據和用戶互動,以防止未經授權的存取和威脅。

  • 有效率:規劃在不過度布建的情況下有效率地使用資源。 請記住成本優化。

  • 使用者中心:針對使用者流程,請將流程設計與使用者的期望和行為一致。 讓它直覺化,並降低新用戶的學習曲線。

開發和測試流程

開發流程以符合技術目標並進行測試,以確保其符合其需求。 此程式會驗證流程是否如預期般運作、有效率地處理其工作,並符合技術目標。 以下是建置和測試流程的指引:

  • 選取技術:選擇符合設定目標的技術,以可靠性、安全性和效能。

  • 開發流程:根據設計建置流程,記住設定的目標。

  • 測試流程:進行測試以確保流程符合目標。 視需要反覆運算以符合目標。

  • 監視:實作監視工具來追蹤資源使用量和成本。

定期檢閱流程,以符合設定目標和業界標準。 使用來自監視和稽核的意見反應來改善流程。 視需要調整目標和程式,以配合不斷變化的業務需求或技術進步。

優化流程

在整個流程生命週期中重複本文中定義的程式。 當您逐一查看流程設計時,請使用架構完善的架構,從每個要素的觀點優化流程:

流程範例

以下是幾個流程範例,可協助您設計流程。 這些範例會使用 可靠的 Web 應用程式模式參考架構 作為基礎,並顯示您應該在每個流程上擁有的檔。

此圖顯示以 Relecloud 為基礎的範例流程。

使用者流程 1:建立即將推出的音樂會

流程描述:客服中心員工會使用應用程式來建立即將推出的音樂會。

  • 商務程式:此流程支持 購買票證 程式,但它是異步的,降低了其關鍵性。

  • 流程擁有者:Sales 主管。

  • 項目關係人:銷售部門、音樂會規劃和營運、平臺小組和應用程式小組。

  • 呈報路徑:應用程式小組、平臺小組,然後是銷售部門。

  • 業務影響:此流程對於在銷售平臺上提供新的音樂會很重要,直接影響業務的主要收入來源。 當通話中心員工因為此流程無法使用而無法建立音樂會時,它會對收入和公司的聲譽產生負面影響。 不過,此程式的高可用性並不重要,因為音樂會通常每周排程。 銷售部門為此程式指定了 95% 的可用性需求,並同意在上班時間以外停機進行維護。

  • 關鍵性評等:低。

使用者流程 2:搜尋音樂會

流程描述:客服中心員工會使用應用程式來搜尋即將推出的音樂會。

  • 商務程式:此流程支持 購買票證 程式,但如果搜尋函式無法使用,客服中心員工可以選擇列出所有音樂會。

  • 進程擁有者:用戶體驗 (UX) 部門。

  • 項目關係人:銷售部門、平臺小組和應用程式小組。

  • 呈報路徑:應用程式小組、平臺小組、銷售部門經理隨叫用。

  • 業務影響:此流程可讓來電中心員工快速找到音樂會,並屬於正常銷售程式的一部分。 此流程的高可用性並不重要,因為員工即使缺席也有能力列出音樂會。 這確實會降低來電中心員工的體驗可能會降低並影響生產力。 客戶可能會因為等候時間或延遲增加而遇到挫折感。 銷售部門要求在一般上班時間提供此流程的 99%。

  • 關鍵性評等:中。

使用者流程 3:取得音樂會的清單

流程描述:客服中心員工會使用應用程式來取得音樂會清單。

  • 商務程式:此流程直接支持 購買票證 程式。

  • 進程擁有者:平臺主管。

  • 項目關係人:銷售部門、平臺小組、數據小組。

  • 呈報路徑:數據小組、數據小組待命工程師、平臺小組待命工程師。

  • 業務影響:此流程是企業產生營收交易的重要路徑不可或缺的一部分。 高可用性是不可或缺的,因為客服中心員工依賴此流程來處理票證購買。 為了辨識其重要性,商務會為此流程規定 99.9% 的運行時間,其中包括延長的工作時間。

  • 關鍵性評等:高。

使用者流程 4:購買票證

流程描述:來電中心員工會使用應用程式( 驗證和授權 程式)代表 Relecloud 客戶購買即將推出的音樂會票證( 清單即將推出的音樂會 程式)。

  • 商務程式:此流程是應用程式的核心功能和流程。

  • 流程擁有者:Sales 主管。

  • 項目關係人:銷售部門和所有技術小組。

  • 呈報路徑:應用程式小組待命工程師、平臺小組待命工程師、數據小組待命工程師、首席營運官。

  • 業務影響:此流程的高可用性非常重要,因為它會直接啟用客戶票證購買。 此流程的任何故障或無法使用都會對營收和公司的聲譽產生重大影響。 此業務為這個重要程式設定了嚴格的需求,預計即使在延長上班時間,仍需要 99.9% 的運行時間。

  • 關鍵性評等:高。

使用者流程 5:驗證和授權

流程描述:來電中心員工安全地登入應用程式。 系統管理員會為他們提供適當的角色,以代表 Relecloud 客戶購買票證。

  • 商務程式:此流程直接支持 購買票證 程式。 如果沒有這項功能,客服中心員工就無法登入應用程式以購買票證。

  • 進程擁有者:平台小組。

  • 項目關係人:平臺小組、營運小組和銷售部門。

  • 呈報路徑:平臺小組待命工程師、首席運營官。

  • 業務影響:此流程需要高可用性,因為如果此流程無法正常運作,則呼叫中心員工無法購買票證。 如果此流程無法使用,則直接影響營收和信譽。 這是商務預期 99.9% 運行時間的關鍵程式,包括延長上班時間。

  • 關鍵性評等:高。

系統流程:收集遙測

流程描述:若要瞭解生產系統中的狀態變更,Web 應用程式和 API 實例會收集並傳送資訊、錯誤和警告。 此數據可協助作業小組執行異常偵測、疑難解答和分析。

  • 商務程式:此流程不支援任何商務程式,但它為營運小組提供重要的數據。

  • 流程擁有者:Operations 主管。

  • 項目關係人:作業小組、平臺小組和數據小組。

  • 呈報路徑:作業小組(24/7),數據小組隨叫用工程師。

  • 業務影響:此流程對於企業的監視和持續改進工作至關重要。 它必須盡可能多餘且具有復原性。 作業小組負責在任何失敗后快速還原此流程,以避免遺漏重要資訊和警告。 如果流程無法達到預期的可用性,則有忽略生產問題的風險,可能會導致嚴重後果。 為了降低風險,營運部門的目標是99%的運行時間、24/7。 他們必須提前至少 48 小時排程維護相關的停機時間。

  • 關鍵性評等:中。