業務流程優化

業務流程優化簡介

對於 Professional Cloud Architect 而言，優化不僅僅是讓程式碼運行得更快；它是要讓 業務 (Business) 運行得更快。雲端技術是將緩慢、手動且孤島化 (Siloed) 的流程轉變為精簡、自動化和數據驅動工作流的催化劑。

架構師必須在技術能力（如 Serverless 或 AI）與業務成果（如縮短「上市時間 (Time to Market)」或提高「客戶滿意度」）之間架起橋樑。

白話文解釋（Plain English Explanation）

類比 1 — 餐廳出餐口（Workflows + Eventarc）

想像一家忙碌的餐廳。服務生（事件）把點菜單放到 出餐口。叫菜員（Workflows）讀單之後依序呼叫燒烤師傅、炒爐師傅、擺盤師傅，每一步都有時序要求。Eventarc 就是新單到來時響起的鈴。沒有出餐口，廚師會互相喊話、菜也會涼掉；有了出餐口，整個廚房就像一台具有確定性的狀態機。

類比 2 — 機場行李系統（Document AI + DLP）

托運行李時，掃描器讀標籤、X 光檢視內容、輸送帶把行李分送到正確的閘門。Document AI 就像標籤掃描器：把紙本發票轉成結構化 JSON。Data Loss Prevention (DLP) API 就像 X 光機：在資料寫進儲存之前，先標記敏感資訊（護照號、信用卡號）。輸送帶（Workflows）再把行李送往正確的閘門（BigQuery、審核者、退款佇列）。

類比 3 — 圖書館卡片目錄（BigQuery + Looker）

過去找書要翻一抽屜的卡片。今天輸入一個查詢，系統就告訴你書在哪、還有誰借過相關書籍。BigQuery 是數位目錄；Looker 是把整份書單交到你手上的圖書館員。業務流程優化就是把「每週紙本報表」變成「任意提問、秒級回答」。

雲端驅動優化的核心支柱

1. 手動任務自動化： 用自動化觸發器（例如 Cloud Workflows）取代人工交接。
2. 數據驅動決策： 使用即時分析而非「直覺」或每週報告。
3. 組織敏捷性： 透過彈性的基礎設施，使業務能夠快速轉型。
4. 成本效率： 從固定容量模式轉變為「按需付費」模式。

Application Integration（前身為 Cloud Workflows 的 iPaaS 層）

Application Integration 是 Google Cloud 的 iPaaS（Integration Platform as a Service）。它位於純 Workflows 之上的一層：業務分析師不需寫 YAML，而是以拖拉方式串接 Salesforce、SAP、ServiceNow、Workday、Jira 等 100 多個 SaaS 系統的預建 連接器 (Connectors)。

何時選 Application Integration、何時選 Workflows

• Application Integration：適合公民開發者 (citizen developer)，可視化編輯器，內建已協商好 OAuth 的連接器，支援含人工審批步驟的長時間流程。當流程跨多個 SaaS 系統時最合適（例如「Salesforce 新商機 → 建立 SAP 客戶 → Slack 通知」）。
• Cloud Workflows：開發者導向的 YAML/JSON，每次執行成本較低，最適合用來編排 Google Cloud 服務（Cloud Run、Cloud Functions、BigQuery）。當流程主要在 GCP 內部時最合適。

PCA 重點 Application Integration 功能

• Integration Connectors — 透過 Private Service Connect 連到 100 多個企業應用，流量不離開 Google 骨幹網路。
• Sub-integrations — 可重用的流程片段（類似「函式」），讓大型整合維護得起來。
• Data mapping — 視覺化、類似 JSONata 的來源/目標 schema 轉換。
• Error handling policies — 不用寫程式碼就能宣告重試、死信、補償規則。

範例：Lead-to-Cash 流程

Salesforce lead 建立 → Application Integration → 透過 Clearbit connector 補強資料 → DLP 遮罩 PII → 寫入 BigQuery → 觸發 Workflows 在 Cloud Run 上佈署試用租戶。每一段在 Cloud Logging 都可稽核、可重試、可觀測。

Workflows + Eventarc 編排模式

Cloud Workflows 是確定性的編排器；Eventarc 是事件路由器。兩者結合是 GCP 上事件驅動業務流程的骨幹。

經典模式

1. 來源產生事件（GCS 物件 finalize、BigQuery 寫入、Pub/Sub 訊息、Audit Log 紀錄）。
2. Eventarc 以 CloudEvents schema 與觸發器 (gcloud eventarc triggers create) 過濾事件。
3. Eventarc 觸發 Workflows 執行，並將事件 payload 傳入。
4. Workflows 編排後續步驟：HTTP 呼叫、子流程、平行分支、指數退避重試。

為何比純 Pub/Sub + Cloud Functions 好

• 有狀態編排：Workflows 追蹤步驟狀態最長一年；Cloud Functions 無狀態，要做同樣的事必須額外用 Firestore/Spanner。
• 內建重試語意：每一步可以宣告 try/retry/except 區塊。
• 可視化執行圖：每次執行都會在主控台得到甘特圖時序，方便除錯。
• No-code 分支：依事件 payload 值做 switch 分支。

實例：發票審批

main:
  params: [event]
  steps:
    - extract:
        call: http.post
        args:
          url: https://documentai-...
          body: {gcsUri: ${event.data.name}}
        result: invoice
    - branch:
        switch:
          - condition: ${invoice.amount > 10000}
            next: humanApproval
          - condition: true
            next: autoApprove
    - humanApproval:
        call: googleapis.workflowexecutions.v1.callback

callback 步驟會暫停流程，直到審批者點擊連結，把原本三天的電子郵件串轉成具有稽核的確定性狀態機。

Document AI：發票與表單處理

Document AI 透過預訓練與自訂 processor 從非結構化文件（PDF、掃描、相片）抽取結構化資料。對業務流程優化來說，它消除了財務、人資、採購中最大的瓶頸：人工資料輸入。

PCA 相關 processor

• Invoice Parser — 開箱即用抽取供應商名稱、明細、總額、稅號，支援 50 多種語言。
• Form Parser — 通用的 key-value 抽取（W-9、保險理賠、員工入職表單等）。
• Contract Parser — 抽出當事人、生效日、續約條件、管轄法。
• Custom Document Extractor — 用 50-100 份標註樣本訓練屬於該領域文件的 processor。
• Specialized processors — 駕照、護照、W-2、薪資單。

參考架構

GCS bucket (上傳) → Eventarc → Workflows → Document AI 批次 processor → DLP 遮罩 → BigQuery (結構化資料列) → Looker 儀表板。

當單檔超過 10 頁或每小時數百檔時，請使用 batch processing（非同步），擴展性與成本皆優於同步的 processDocument endpoint。

Human-in-the-loop (HITL)

對於高價值文件，請啟用 Document AI Workbench HITL。低信心度的抽取結果會被導向標註介面，由人類確認後資料才往下流。如此可維持 99% 以上正確率，又能自動處理 80-90% 的量。

Apigee：合作夥伴與 B2B 整合

當業務優化需要把內部能力暴露給外部合作夥伴（銀行、供應商、經銷商）時，光是 Cloud Run endpoint 不夠用。Apigee X 是把內部服務變成具治理、可貨幣化產品的 API 管理層。

與業務流程相關的 Apigee 能力

• API proxies — 在任何後端（Cloud Run、GKE、透過 hybrid 連到地端）前面套上一致的認證、流量管制、轉換。
• 開發者入口網頁 — 合作夥伴自助上線（取 API key、看文件、下載 SDK），把整合時程從數週縮短到數小時。
• OAuth 2.0 / OIDC / API key 政策 — 不用在每個服務寫安全機制就能標準化。
• Quota and spike arrest — 保護下游業務系統不受失控合作夥伴影響。
• Monetization — 階層方案（free / pro / enterprise）、費率表、帳務報表。讓 API 變成營收。
• Analytics — 在 Apigee UI 看每個合作夥伴的延遲、錯誤率、流量儀表板。

Apigee vs API Gateway

• API Gateway — 輕量化，適合內部/微服務 API，沒有開發者入口網頁，按呼叫計費。適用於「把 Cloud Functions 暴露給手機 app」。
• Apigee — 完整堆疊，含入口網頁、貨幣化、進階分析、轉換政策。適用於「把 API 暴露給 200 家銀行合作夥伴並提供 SLA」。

範例：Open Banking 合規

某銀行透過 Apigee 暴露帳戶聚合 API。政策強制 mTLS、FAPI 合規 OAuth、每家 fintech 的個別流量管制，每次呼叫都稽核寫進 BigQuery。fintech 從開發者入口網頁數小時內完成 onboarding，取代過去 12 週的採購加 VPN 流程。

Cloud Tasks：可重試的非同步工作

Cloud Tasks 是全代管的延遲、可重試 HTTP 工作佇列。Pub/Sub 適合扇出廣播、Eventarc 適合事件路由，而 Cloud Tasks 強在 每一單位工作的個別控制：每個 task 都是獨立的 HTTP 請求，可獨立排程、限流、重試。

Cloud Tasks 是正確答案的情境

• 把使用者請求和緩慢工作解耦 — 使用者按下「寄出 10,000 封信」，API enqueue 10,000 個 task 後立即回傳 200，由 Cloud Run worker 慢慢消化佇列。
• 限流外部 API — 設定 maxDispatchesPerSecond 來尊重合作夥伴每秒 100 次的配額。
• 排程任務 — scheduleTime 可延後最長 30 天（例如「使用者註冊 7 天後寄信」）。
• 每個 task 的重試與退避 — 每個佇列可以個別設定 maxRetryDuration、minBackoff、maxBackoff。

Cloud Tasks vs Pub/Sub vs Workflows

• Pub/Sub — 多訂閱者、廣播語意、at-least-once。沒有每訊息排程。
• Cloud Tasks — 每 task 恰好一個消費者、可逐 task 排程與限流、目標是 HTTP。
• Workflows — 編排多步驟流程；Cloud Tasks 派送單一工作單位。

模式：幕等 webhook 扇出

某個業務事件（「訂單已出貨」）需要通知 5 個合作夥伴 webhook，每個有自己的流量管制與重試政策。Pub/Sub 扇出到 5 個 Cloud Run 服務；每個服務再依該合作夥伴的配額個別 enqueue Cloud Task。某合作夥伴掛掉時只有他的佇列退避，其他的照樣出貨。

AppSheet：公民開發者應用

AppSheet 是 Google Cloud 的 no-code 平台。業務使用者直接從 Google Sheet、BigQuery 資料表或 Cloud SQL 資料庫建立行動版與網頁版應用程式，不需要工程開單。

AppSheet 對流程優化的價值

最大的優化常常來自取代 試算表加電子郵件 工作流程：巡檢表單、庫存盤點、現場服務工單、審批流程。傳統 IT 沒辦法為每一個都做客製化 app，於是這些試算表就一直留著。AppSheet 讓擁有流程的人自己建 app。

能力

• 資料來源 — Sheets、Excel、BigQuery、Cloud SQL、Salesforce、Smartsheet。
• 離線優先行動版 — 在倉庫、工地、偏鄉皆可運作，重新連線時自動同步。
• 流程自動化 — Bot 觸發器於資料列新增/更新時啟動，寄電子郵件、呼叫 webhook、執行 Apps Script。
• 條碼/QR/NFC 掃描 — 內建於行動 app，用於資產追蹤。
• 治理 — 管理主控台控制誰能發布 app、允許哪些資料來源、以 IAM 控管存取。

參考情境

某製造廠每日安全巡檢都用紙本。AppSheet 取代寫字板：巡檢員掃描機台的 QR code、在手機上填表、相片同步到 GCS，Bot 觸發 Workflows 執行；只要有任何不合格項目就自動開 Jira 工單。廠長看 Looker Studio 即時儀表板。建置時間：一個週末、零工程師。

考試應警覺的限制

AppSheet 不能取代完整的 SaaS 產品。題目若提到「百萬同時在線使用者」「複雜的交易邏輯」或「客製化 UI 元件」，答案會指向 App Engine / Cloud Run 加上完整前端框架，而不是 AppSheet。

DLP API 在優化流程中的角色

Sensitive Data Protection 服務（前身為 Cloud DLP）負責檢測、分類、去識別化敏感資料。在流程優化中它是一道護欄，讓自動化變得安全。

整合模式

• 在 Workflows 中即時檢測 — 在 Document AI 抽取後、寫入 BigQuery 之間呼叫 dlp.projects.content.inspect。出現非預期 PII 的資料列就阻擋或隔離。
• 送進分析前先去識別化 — deidentifyContent 搭配 FORMAT_PRESERVING_ENCRYPTION 可維持參照完整性（同一個 SSN → 同一個 token），同時移除原值。
• BigQuery 欄級遮罩 — 以 DLP 為基礎的動態資料遮罩讓分析師看到遮罩後值，另有一小群人能看原值。
• GCS 掃描工作 — 排程 dlpJobs 偵測無意間裝了未遮罩 PII 的 bucket。

範例流程

客服電子郵件抵達 GCS bucket → Workflows 觸發 Document AI → 在寫入 BigQuery 前 Workflows 呼叫 DLP deidentifyContent，infoTypes: [EMAIL_ADDRESS, PHONE_NUMBER, CREDIT_CARD_NUMBER] → 分析師查詢去識別化後的資料集；另有獨立的 support_pii 資料集（CMEK 加密、嚴格 IAM）保存原始資料供受規管用途。

在 BigQuery 上做業務流程建模

無法衡量就無法優化。BigQuery 是堆放業務流程事件的分析倉儲，讓領導層找出瓶頸。

在 BigQuery 上做流程探勘 (Process Mining)

• 透過 Storage Write API（低延遲、exactly-once）把每一次 workflow 步驟轉換串流寫進 BigQuery。
• 把事件記錄建模為 (case_id, activity, timestamp, actor, attributes) —— 這是 Celonis、ProcessGold 等工具採用的標準 schema。
• 用 BigQuery SQL window 函式（LEAD、LAG、DURATION）計算每步驟延遲、重工率、與標準路徑的吻合度。
• 把 KPI 物化到 BigQuery scheduled queries 或 Dataform 供下游儀表板使用。

實用 BigQuery 功能

• BigQuery ML — 直接在事件記錄上訓練 churn 或異常偵測模型，資料不出 BigQuery（CREATE MODEL ... OPTIONS(model_type='ARIMA_PLUS')）。
• Authorized views — 把彙總後的 KPI 開放給業務團隊，原始事件資料仍受保護。
• Row-level / column-level security — 強制 EMEA 團隊只能看到 EMEA 案件。
• BI Engine — 讓主管的 Looker 儀表板達到亞秒級反應。

範例查詢：訂單到收款 (Order-to-Cash) 瓶頸

SELECT
  activity,
  APPROX_QUANTILES(TIMESTAMP_DIFF(end_ts, start_ts, MINUTE), 100)[OFFSET(95)] AS p95_minutes
FROM `proc.events_pivoted`
WHERE process = 'order_to_cash'
GROUP BY activity
ORDER BY p95_minutes DESC;

第一列就是流程中最久的步驟 —— 那就是優化投資該下的地方。

Looker 嵌入式分析：營運儀表板

Looker（平台本身，不是 Looker Studio）把受治理、可信任的指標放到營運人員眼前。對流程優化的價值是 共享語意：因為 LookML 一次定義好「open ticket」或「active subscriber」，所以每個團隊看到的定義都一樣。

嵌入式分析模式

• Signed embeds — 伺服器端產生簽署過的 URL，再以 iframe 嵌入 AppSheet、Apigee portal 或自訂網頁應用。權限隨 SSO 一起帶入。
• 客製化視覺化 — 為產業需求加入 D3 圖表（漏斗分析的 Sankey、成本拆解的 treemap）。
• Scheduled deliveries — Looker 每日推送 PDF 或 Slack 訊息附帶異常警示（「過去一小時 EMEA 訂單下跌 30%」）。
• Actions framework — 儀表板上的按鈕呼叫 Workflows webhook，把「洞察」一鍵連到「行動」。

Looker vs Looker Studio（PCA 抉擇）

• Looker Studio（免費） — 臨時、個人分析師儀表板，治理有限。適合自助分析。
• Looker（付費、LookML） — 企業治理、嵌入式分析、KPI 單一事實來源。當需要跨部門一致定義或嵌入合作夥伴介面時必選。

範例迴圈

某物流公司把 Looker 儀表板嵌進派遣員的 AppSheet app。當某路線準時率掉到 90% 以下時，按下行動按鈕會觸發 Workflows 重新指派駕駛，下一次儀表板刷新就能看到影響 —— 在同一個介面內完成「觀察—決策—行動」的閉環。

用於流程優化的 GCP 工具

1. Cloud Workflows 與 Eventarc

• Workflows： 編排微服務和 API。它處理流程中的「業務邏輯」（例如：「如果信用評分 > 700，則批准貸款，否則送人工審核」）。
• Eventarc： 允許你根據來自 60 多個 Google Cloud 來源的事件觸發操作（例如：「當文件上傳至 GCS 時，啟動分析流水線」）。

2. BigQuery 與 Looker

• BigQuery： 為優化提供數據基礎。它允許業務在幾秒鐘內分析數 PB 的數據。
• Looker： 數據民主化。它將即時儀表板送到業務經理手中，以便他們能立即發現流程瓶頸。

3. Vertex AI

• 預測性優化： 使用機器學習 (ML) 預測機器何時可能損壞（預防性維護）或客戶何時可能流失，讓業務能在問題發生 之前 採取行動。

「上市時間 (Time to Market)」指標

在 PCA 考試中，「上市時間 (Time to Market)」是一個常見的業務需求。這裡的優化包括：

• 自助服務入口網頁： 讓開發人員自行佈署環境，而不是等待 IT 部門數週。
• CI/CD 流水線： 縮短將功能從「構思」推向「生產環境」所需的時間。
• Serverless： 消除管理基礎設施的需求，讓團隊可以 100% 專注於業務邏輯。

FAQ — 業務流程優化

Q1. 我該如何確定優先優化哪個流程？

首先關注 「高量、低複雜度」 的任務。這些是「唾手可得的果實 (Low-hanging fruit)」，自動化能提供最快的投資報酬率 (ROI)。

Q2. 優化是否總是意味著裁員？

不一定。在許多雲端轉型中，優化是關於 「減少瑣事 (Toil Reduction)」。它將熟練的員工從「忙碌的工作」（如手動數據錄入）中解放出來，使他們能專注於高價值任務（如策略和創新）。

Q3. GCP 架構中的「卓越營運 (Operational Excellence)」是什麼？

它是運行和監控系統以交付業務價值，並持續改進支持流程和程序的能力。核心原則包括「以程式碼形式執行操作」和「進行頻繁、細微且可逆的變更」。

Q4. Looker 如何協助優化？

Looker 允許業務使用者自行建立報告，無需數據科學家。這消除了「報告請求瓶頸」，並允許公司各個層級做出更快速、數據驅動的決策。

Q5. 架構師在「變更管理 (Change Management)」中扮演什麼角色？

架構師提供使變更成為可能的技術藍圖。他們確保隨著業務流程的改變，底層架構始終保持安全、可擴充且具備成本效益。

架構師最終提示

在 PCA 考試中，如果業務案例提到「手動步驟導致延遲」或「數據孤島化」，請尋找涉及 Workflows、BigQuery 或 Pub/Sub 的答案。始終優先考慮 將枯燥事務自動化 的解決方案。請記住：一位成功的雲端架構師不只是構建一個「雲端系統」——他們是在構建一個「雲端原生企業」。