業務流程的改善沒有終點。在「改善」之後，往往又會發現新的「問題」。
PDCA 循環是甚麼？
這是一種「持續不斷改善」的思維方式。例如，以下這些讓人覺得不太對勁的情況，都可能成為改善主題。
- A. 收到客戶投訴
- B. 銷售團隊的成果沒有提升
- C. 好不容易發出錄用通知，卻被對方婉拒
- D. 每天早上都花很多時間「找手機」……
而感受到「課題」的那一刻，正是啟動 PDCA 專案的機會。（Plan ⇒ Do ⇒ Check ⇒ Act ⇒ Plan ⇒ …）
改善主題 A：食品工廠的衛生管理
- Stage.0（問題設定）：客戶投訴產品中「混入毛髮」。對食品加工工廠來說，這是信任受損的危機。防止再次發生是最大的目標。
- Stage.1（Plan）：基於「自我檢查容易流於寬鬆」這一假設，設計了由作業人員兩兩配對的「Buddy 檢查制度」。彼此確認毛髮是否外露、是否有漏用滾輪清潔等。目標是 30 天內達成毛髮混入為零。
- Stage.2（Do）：在部分工廠運用「Buddy 檢查制度」，並加強抽樣檢查。
- Stage.3（Check）：1 個月後，彙整檢查結果及客戶回饋，確認毛髮混入為零。此外，同時也帶來了附帶效果，也形成了彼此確認儀容整潔的文化，並營造出更容易指出小異常和小失誤的氛圍。
- Stage.4（Act）：正式修訂工廠的「衛生管理標準」，並將「Buddy 檢查」完整納入新進員工教育課程。同時，團隊也開始討論是否應加強管理毛髮以外的異物（工作服纖維、手套碎片等），並將其視為新的改善課題。
改善主題 B：銷售洽談中輸給競爭對手
- Stage.0（問題設定）：失單理由中，「價格方面輸給競爭對手」的比例有增加趨勢。
- Stage.1（Plan）：基於新進成員「未能充分傳達產品」這一假設，新開發了「能明確呈現成本效益的提案書範本」。目標是將「成交率從 20% 提升到 25%」。
- Stage.2（Do）：在部分銷售團隊導入新的提案書範本。同時，徹底要求針對每位客戶，以數字說明成本削減金額與業務時間削減效果。
- Stage.3（Check）：1 個月後，分析洽談數、成交率和失單理由。因「價格太高」而失單的情況有所減少，ROI 說明的效果在一定程度上得到確認。另一方面，成交率本身仍維持在 20%，這表示價格以外的因素也可能影響成交。
- Stage.4（Act）：將新的提案書與說明方法推廣至所有銷售團隊，並納入銷售手冊。同時，團隊內也認識到新的課題：「對於甚麼情況應進入正式商談階段，原本就存在認知差異」。
改善主題 C：應屆畢業生招聘中的錄用後婉拒
- Stage.0（問題設定）：近年來，錄用後放棄率偏高。今年未能確保預定錄用人數。
- Stage.1（Plan）：基於「錄用後是否也需要讓候選人更了解公司？」這一意見，規劃了後續跟進措施。目標是「將錄用後放棄率從 30% 降至 15%」。
- Stage.2（Do）：針對已獲錄用者，舉辦了「職場參觀＆員工交流會」這一後續跟進活動。
- Stage.3（Check）：分析錄用後婉拒理由後發現，錄用後放棄率從 30% 降至 20%，但未達成目標。不過，以「對工作內容理解不足」為理由的婉拒有所減少。
- Stage.4（Act）：將後續跟進活動納入下一年度的標準流程。同時，也發現有一定數量的人反映「入職後的職涯發展不清晰」。
改善主題 D：早晨的手忙腳亂
- Stage.0（問題設定）：手機經常不知去向，尤其是在早上。可能在被窩裡、沙發縫裡，偶爾還會在雪櫃上。
- Stage.1（Plan）：在床邊設置「手機專用托盤」，並制定規則：使用後一定要放在那裡。目標是「早上的尋找時間從 3 分鐘降至 10 秒」。
- Stage.2（Do）：在托盤上貼上寫有「放在這裡」的便條，並開始執行規則。
- Stage.3（Check）：經過 1 個月後，仍能維持手機尋找時間為零。早晨出門變得更順暢了。不過，鑰匙不見的問題開始浮現。
- Stage.4（Act）：將托盤擴展為「手機・鑰匙・錢包托盤」，並正式採用為生活標準流程。然而，也開始意識到新的課題：睡前一直使用手機，是否助長了熬夜？進而是否也助長了早晨的手忙腳亂？
最重要的是哪個 Stage？
PDCA 循環的難點，在於「如何銜接到下一個 Plan」。
也就是說，第一次的「Stage.1（Plan）」之前有一個「課題」（← Stage.0）。但是到了第二次的「Stage.1（Plan）」，這個「課題」往往會變得模糊。（※ Stage.0 ⇒ Stage.1 ⇒ Stage.2 ⇒ Stage.3 ⇒ Stage.4 ⇒ Stage.1 ⇒ …）
PDCA 無法持續轉動的最大原因，是「課題的消失」。必須持續意識到：第 n 輪的 Stage.4（以及 Stage.3），同時也兼具第（n+1）輪 Stage.0 的作用。
甚麼是 BPM 循環？
「PDCA 循環」是一般改善的框架，而「BPM 循環」則是聚焦於業務流程改善的思維方式。（※ Business Process Management）
「BPM 循環」的出發點，同樣也是對「課題」的認識。
改善主題 X：客戶詢問回應流程
- Stage.0（問題設定）：既有客戶投訴「回應太慢」。確實是需要緊急處理的查詢。
- Stage.1（Plan）：流程負責人基於「不同 CS 負責人對緊急程度的認知存在差異」這一假設，新增了「由 AI 自動判定緊急程度的工序」。對於 AI 判定為「緊急程度最高」的查詢，目標是「60 分鐘內給出初步回覆」。
- Stage.2（Do）：所有Email 查詢都開始按照「緊急程度」自動分類。
- Stage.3（Check）：執行 2 週後，分析了到初步回覆為止所需的時間以及客戶滿意度。所有緊急查詢都在 60 分鐘內得到回覆。確認了所需時間縮短，以及客戶滿意度改善。
- Stage.4（Act）：根據回覆負責人的回饋，開始提升 AI 判定的準確度。另一方面，也出現了「除了緊急程度之外，也應判定難易度」的意見。
改善主題 Y：審批流程
- Stage.0（問題設定）：人工步驟「主管審批」的滯留時間較長，決策速度慢。
- Stage.1（Plan）：流程負責人認為，「撰寫審批意見和退回意見似乎花了不少時間」。於是，在審批工序之前，新增了「由 AI 同時準備審批意見與退回意見」的步驟。
- Stage.2（Do）：「審批意見草稿」和「退回意見草稿」開始由 AI 自動生成。主管可以根據需要修改後再進行審批。
- Stage.3（Check）：執行 2 週後，分析了到審批完成為止的前置時間與滯留時間。結果確認，撰寫意見所需時間有所減少，尤其是在簡單案件中，審批速度得到了提升。
- Stage.4（Act）：主管開始發表「判斷視野變得更廣」等正面評論。另一方面，申請人方面也開始零星出現「這是不是不恰當的評論？」等負面回饋。
改善主題 Z：Web 內容更新流程
- Stage.0（問題設定）：由於複製貼上失誤，網誌原稿在缺少「最後一章」的狀態下被發布了。
- Stage.1（Plan）：流程負責人判斷，「人工複製貼上」無法避免失誤。於是自動化了「建立草稿」（WordPress.com）。目標是複製貼上遺漏為零。
- Stage.2（Do）：經工作流程審批後的原稿（標題、正文、摘要）會作為 WordPress.com 的草稿文章自動登記。發布負責人也能夠專注於版面設計。
- Stage.3（Check）：經過 1 個月後，仍未發生複製貼上遺漏或章節缺失等單純錯誤。發布作業所需時間也大幅縮短。
- Stage.4（Act）：除了網誌原稿以外，這個工作流程也開始被用於其他內容。發布作業變得更順暢的同時，對文章表達品質審閱的需求也增加了。也開始出現「是否需要 AI 審閱？」這樣的意見。
改善主題 W：訂單處理流程
- Stage.0（問題設定）：訂單內容仍由人工登記，登記錯誤層出不窮。
- Stage.1（Plan）：流程負責人將流程改為：收到訂單 Email後自動啟動工作流程。同時，新增 AI 工序「訂單內容擷取」，讓訂單內容可以被預先填入。目標是將「接單登記錯誤率從 10% 降至 4%」。
- Stage.2（Do）：銷售負責人的工作，從「登記訂單內容」，變成了「比對並檢查訂單內容與預先填入的訂單內容」。
- Stage.3（Check）：商品代碼、數量、交期的登記錯誤大幅減少，錯誤率降至 1%。
- Stage.4（Act）：根據銷售負責人的回饋，發現存在「訂單內容本身有誤」的情況。團隊內意識到新的問題：是否應該自動化與報價內容的核對（差異檢查）？
最重要的是哪個 Stage？
即使在「BPM 循環」中，持續明確「下一個課題」也非常重要。
第 n 輪的 Stage.4（以及 Stage.3），同時也兼具第（n+1）輪 Stage.0 的作用。必須持續意識到這一點。
BPM 循環中，BPM Suite 在 BPM 循環中非常重要
要在現實業務中持續運轉這樣的「BPM 循環」，就需要一個支援設計、執行、監控和改善的基礎平台。
確實，僅靠人手來運轉「BPM 循環」並非不可能。但是，若要高效率地運轉，能夠整合提供支援 PDCA 各個階段功能的「BPM Suite」會非常方便。例如，”Office Suite” 就是將文件、試算表、簡報應用程式整合提供。
「Questetra BPM Suite」提供以下功能。
Plan（Design）：
- 流程設計功能：流程負責人對業務流程和業務資料進行建模。結果，業務流程和資料項目會被「可視化」。
- 分支設定、電郵自動發送設定、電郵接收等待設定、表單接收等待設定、PDF 自動生成設定、子流程連動設定、ECMAScript 處理設定等
- 分派規則編輯功能：流程負責人設定各工序的任務處理候選人（承接規則）。
- 業務資料編輯功能：字串型、數值型、日期型、日期時間型、檔案型、表格型等。
- ※ 也被稱為 IT 業務管控功能、流程設計功能等。定義工作流程圖時，常會使用國際標準記法 BPMN。
- ※ 有時也會統稱為建模功能、Design-Time 功能、設計功能、開發功能。
Do（Execute）：
- 發布功能：流程負責人將模型（工作流程應用程式）作為業務系統投入運用，並視需要進行版本升級。
- 任務處理功能：一般員工處理「我的任務」。被分派給自己的任務，可以直接作為日常業務進行處理。
- ※ 有時也會統稱為工作流程功能、Runtime 功能、執行功能、運用功能。
Check（Monitor）：
- 進度狀態確認功能：監控執行中流程的個別進度。可以掌握目前進展到哪個工序。
- 熱力圖功能：監控執行中流程的整體分佈。可以確認目前哪個工序出現壅塞。
- 執行資料彙整功能：確認所有工序已完成流程的實績（瓶頸等）。更容易找出下一個改善點。
- ※ 有時也會統稱為監控功能、狀態監控功能、效能監控功能。
- ※ 主要用於 Runtime，但也有助於面向下一次 Design-Time 的檢討與修訂。
Act（Optimize）：
- 團隊聊天功能：可以與團隊成員聊天。便於討論人員配置和人員輪班。
- 應用程式聊天功能：可以與工作流程應用程式連結後進行聊天。便於累積並共享改善中的發現。
- 案件聊天功能：可以與流程連結後進行聊天。便於共享案件特有的情況。
- 自訂頻道功能：便於聚焦特定話題進行討論。
- ※ 有時也會統稱為內部聊天功能。
- ※ 流程負責人會根據進度狀況和執行資料，視需要優化 Runtime 中的資源分配和負責人數。
- ※ 流程負責人會認識工作流程應用程式中的課題，並將其作為下一次 Design-Time 的線索。
另外，在 BPM 領域中，「Plan ⇒ Do ⇒ Check ⇒ Act」有時也會被稱為「Design ⇒ Execute ⇒ Monitor ⇒ Optimize」。不過，其本質並沒有改變。
總結
無論是 PDCA 還是 BPM，都是「察覺課題，並反覆進行改善」的思維方式。不過在實際情況中，這種改善很容易依賴個人或團隊的意識。不知不覺間，下一個課題變得模糊，循環也可能停下來。
尤其是在 BPM 中，面對的是「改善業務流程本身」這一項難度更高的工作。必須重新檢視業務流程、角色分工以及資料處理方式。如果仍停留在依賴個人經驗的運用方式，就很難持續運轉下去。
正因如此，Check（監控）和 Act（改善）階段，是應該由 IT 系統支援的領域。只有具備能夠可視化流程進度和執行資料，並持續掌握瓶頸與課題的環境，才能銜接到下一次改善。
BPM Suite 能夠一體化支援設計、執行、監控和改善這個循環，並成為在日常業務中持續推動改善的基礎平台。要實現持續性的業務改善，重要的不是「察覺到問題後再改善」，而是「維持一個讓改善持續運轉的機制」。