ブログ

  • 為什麼我們的部門主管不畫業務流程圖?

    為什麼我們的部門主管不畫業務流程圖?

    English version

    為什麼我們部門主管不畫業務流程圖?

    0. 「業務流程圖」究竟是什麼?

    最近,我收到好幾位讀者的評論,說:「壓根兒就不明白業務流程的必要性在哪裡。」

    這也難怪,對於一般人來說,恐怕根本沒見過業務流程圖這種東西。當然,更不可能有按照業務流程圖來處理工作的經驗……我在(心裡默默地)想,既然如此,不明白它的必要性也是再正常不過了……

    所以,今天我想回歸初心,針對「業務流程圖的必要性以及具體的業務流程圖畫法」,把目前思考的內容整理出來。(這可能是一項相當繁重的工作……)

    「Web 稿件製作」業務流程圖示例

    1. 究竟為何需要「業務流程圖」?

    首先,「業務流程圖」到底是什麼?

    有的稱它為「流程圖 (Flowchart)」,有的稱「業務程序圖 (Business Process Diagram)」,還有的稱「工作流圖 (Workflow Diagram)」……說法五花八門。簡單來說,就是「能讓人看懂業務如何開展的圖」。在日本的行政機關,它被正式稱為「業務流轉圖」

    其最大特徵在於,業務手冊是用「文字」編寫的,而業務流程圖則是使用被稱為「圖表」(Chart) 的圖形來描述的。……如果想用外來語蒙混過關的話,肯定會被人追問「那 Chart 到底是什麼?」,Chart 本意是指「海圖、航空圖、天氣圖」。也就是說,業務流程圖是「為了了解應行之路而繪製的地圖」。 「Flow(流)」+「Chart(圖)」這一表達的含義就是「能看清全局走向的圖」。與文字不同,它能讓人迅速理解整體脈絡。

    說起來,以前曾受過一本叫「Chart 式」的數學參考書的照顧。據說它的名字寄託了「希望這本參考書能像船上的海圖一樣發揮指引作用」的願望(摘自維基百科)。(那時候「紅皮 Chart」對我來說可是相當大的考驗啊……嗯?這不重要!)

    理想的業務流程圖,應該能讓全體員工解決以下問題:

    • 在整體業務流程中,我負責哪一個作業環節?
    • 我需要接收什麼 (INPUT),產出什麼 (OUTPUT),並交給誰?

    1-1) 【同步】為了在公司內同步現狀流程,或溝通變更內容
    1-2) 【培訓】為了在公司內傳授現狀流程
    1-3) 【外部報告】為了向公司外部報告現狀流程

    1-1. 為了在公司內同步現狀流程,或溝通變更內容

    這是我列舉的第一項需求。

    例如,如果你想進行諸如「優化業務流以提升團隊整體生產力」或「設計防止舞弊的資訊傳遞流程」等進階討論,那麼一份詳盡的現狀業務流程圖就是必不可少的……

    不過……「在公司內同步現狀或溝通變更」實際上是一個非常高階的利用目的。當你真正嘗試繪製時會發現,即使是那些駕輕就熟的日常工作,往往也存在嚴重的「因人而異」情況,或者說「流派」林立。也就是說,「現狀流程」往往是「千人千面」。說白了,大家各做各的。例如,以下這種「因人而異」的例子,在任何公司都隨處見:

    1-1-1. 客訴處理流程

    在撰寫投訴回覆郵件時,員工 A 總是先讓上司審閱完所有回覆內容後再發送,而員工 B 則只是偶爾才讓上司審閱。

    1-1-2. 新 Web 頁面上線流程

    在官網上線新頁面時,員工 A 習慣先讓設計師畫插圖,自己同步寫正文,然後再請設計師排版;而員工 B 則是等正文完全寫好後,才一次性委託設計師處理插圖和排版。

    順帶一提,「業務流程因人而異(屬人化)」這種說法往往會引起很大的誤解。
    -A. 擔當者技能的個人化:「因人而異導致產出品質(結果)不同」
    -B. 資訊傳遞路徑的個人化:「因人而異導致傳遞步驟和路徑不同」
    不言而喻,我們這裡指的是 (B) 「工作流轉的路徑和順序沒有統一規則」。但在日常談話中,人們更多是在 (A) 的語境下使用這個詞。在討論過程中兩者容易發生偷換,因此需要特別注意。例如,在說「由於 Excel 水平因人而異導致成果參差不齊」或「A 部長和 B 部長的判斷標準不同」時,也常被冠以「業務(流程)屬人化」的說法,但實際上,這種情況下業務流程往往反而是標準化的。

    1-2. 為了在公司內傳授現狀

    「在公司內傳授現狀流程」是一個非常直觀的需求。

    比如在團隊接收新人時,如果有流程圖就會非常方便。無論是校招新人還是異動,只要把圖往他手裡一遞:「喏,我們團隊就是按這麼個路數幹活的」,新人就能立刻掌握大致的工作流轉。對於處於擴張期、大量招人的企業或異動頻繁的公司,流程圖可謂是非常有效的武器。這可比說「給你一份公司規章和操作手冊……」要強百倍。(反正他們絕對不會讀的……爆)

    對於那些試圖用「我們這兒可沒流程圖這種玩意兒。是 OJT,O-J-T(在職培訓)!」這種時髦詞彙掩飾的上司,需要格外小心。誠然,投身實戰、身體力行的 On Job Training 從快速培養戰鬥力的角度來看確實是種有效手段。但另一方面,它往往也可能演變成一種「磨練(不給支援)」式的殘酷訓練。也就是說,得不到前輩指導的新人只能靠自己從懸崖下往上爬,結果就是在完全沒有傳承到公司核心「業務流轉」經驗的情況下長大了。(並建立了一套野路子的「業務流轉」?)

    1-3. 為了向公司外部報告現狀流程

    與前兩個需求相比,第三個「1-3. 向外部報告」可能是一個略顯消極的需求。

    最典型的例子就是基於 SOX 法(薩班斯法案)的內部控制報告制度。上市企業等需要向金融監管機構提交「業務流轉圖」,以此證明公司的治理是有效的。這最終有助於保護投資者。(不過,提交了報告並不意味著現場就會變得更有活力,也不意味著銷售額會增長……)

    2. 那麼,為何「業務流程圖」並不存在?

    在第一章中,利用目的(需求)已經明確了(?)。業務流程圖是必要的(!)。

    那麼,既然是「必要的東西」,為什麼往往「沒有」(或者說不畫)呢?

    2-1) 畫不出來
    2-2) 雖然會畫,但覺得沒意義所以不畫
    2-3) 雖然會畫,但不知道該由誰畫所以不畫

    2-1. 畫不出來

    「畫不出來」這點很好理解。

    做不出來的東西自然沒法存在。如果有老鷹,還可能生出小鷹,但如果連老鷹都沒有,那自然什麼也生不出來。(這比喻好像不太對)

    但這種情況實際上非常多。你可以嘗試描繪一下身邊的業務流程。即使是久經沙場的老員工,在打開 PowerPoint 或 Visio 點擊「新建」的那一刻,面對那張空白畫布,往往也不知道該從何寫起。這並不是因為不了解業務,相反,他們可能比誰都清楚。純粹是因為業務流程的描繪太難了。(它看不見摸不著。它不是能用照片或影片拍下來的東西。而且平時也根本沒機會見到別人的案例。)

    筆者本人至今已擁有建模約 500 個業務的經驗。正因如此,我現在只要聽一遍訪談,就能當場畫出業務流程圖(←純屬自誇)。但是,剛開始的時候,畫好一個流程圖要花 5 個甚至 10 個小時。而且,睡一覺起來再看那個流程圖,總能發現好幾處需要改進的地方。前 10 個流程圖往往都要經歷無數次推倒重來。(笨蛋笨蛋笨蛋。致:昨天的我,來自:今天的我)

    2-2. 雖然會畫,但覺得沒意義所以不畫

    「雖然會畫,但覺得沒意義所以不畫」,在某種意義上是一種很深刻的狀況。

    但這種情況也不在少數。那麼,為什麼會覺得「沒意義」呢?這通常可以歸結為以下兩個理由:

    • A) 「因為業務流程圖很快就會過時(陳舊化)」
    • B) 「單靠業務流程圖無法管控業務的流轉」

    以 [A] 業務流程圖的陳舊化為例,比如 [A1] 「電腦採購改為由行政部統一調撥了」或者 [A2] 「組織架構調整導致部門和團隊結構變了」等內部因素,以及 [A3] 「由於競爭對手出現,必須將標準交付期縮短一半」等外部因素,都會導致業務流程本身發生變化。在那一瞬間,好不容易畫好的流程圖就成了過去式。維護起來有多難就不用我多說了。此外,關於 [B] 管控困難的問題,雖然可以考慮「把流程圖貼在牆上」、「每月進行研修」等各種措施,但僅憑畫在紙上的業務流程圖,其效力確實有限。

    2-3. 雖然會畫,但不知道該由誰畫所以不畫

    「雖然會畫,但不知道該由誰畫所以不畫」,這就讓人頭疼了。

    明明能做卻不做,說白了就是某種職責履行缺位。你可能會覺得意外,但在業務流程管理已經成熟的組織中,這種情況反而經常發生。

    例如,當涉及到如何讓生產部門和銷售部門的工作流轉得更順暢時,不可避免地會產生利益衝突。這就是所謂的跨部門業務流程。諸如「訂單資訊的校驗工作應該由銷售部門在前期完成吧」之類的棘手話題,必須有個了斷。這不僅需要精通雙方部門的業務,還需要本著「全局優化」的名義進行調停。畢竟人嘛,都想離麻煩事遠一點。(這種情況屬於高深的組織論範疇。歸根結底,似乎只能由組織最高層任命一名「流程所有者 (Process Owner)」來解決了)

    3. 順帶一提,為何「業務流程圖」畫起來這麼難?

    繪製業務流程圖確實很難。(正如在「2-1. 畫不出來」中提到的)。在這裡,我想深挖一下業務流程圖難以動筆的原因。

    順帶一提,我們不討論繪圖工具方面的問題。也就是說,如果把繪圖比作畫畫,我們不討論紙筆的問題。在這裡,我想探討的是諸如「奔馬」為何難畫、「人體」為何難畫這種對象物本身所蘊含的難度

    3-1) 其實根本就沒有內部規則
    3-2) 應該以多大的顆粒度來描述處理步驟,讓人很糾結
    3-3) 例外處理應該寫到什麼程度,讓人很糾結

    3-1. 其實根本就沒有內部規則

    「其實根本就沒有內部規則」,這簡直讓人扼腕。

    畢竟你想描繪的模特兒根本就不在場。嘛,直接說「不在」可能有點太粗暴了,但如果你想畫的業務流程,一會兒像「馬」,一會兒像「車」,一會兒又像「寺廟」……當你完全搞不清它真實的形態時,自然沒法動筆。

    沒有業務流程(內部規則),業務還能運轉嗎?嘛,它確實能動。只能說,人類這種生物實在是太了不起了。

    3-2. 應該以多大的顆粒度來描述處理步驟,讓人很糾結

    「應該以多大的顆粒度來寫」,這是高手才會說的話。

    我在第一章中以「撰寫投訴回覆郵件」作為一個作業環節舉了例,但它還可以進一步分解為「撰寫標題」、「撰寫正文」、「複核」等。描繪的顆粒度可以無限細分。雖然存在各種顆粒度設定的方法,但作為一項原則,業務流程圖中描繪的環節顆粒度最好設定為「一名員工接收 INPUT 到產出 OUTPUT 為止的一個完整動作」。

    3-3. 例外處理應該寫到什麼程度,讓人很糾結

    「例外處理應該寫到什麼程度」,這是一個終極難題。甚至可以說是永恆的煩惱。

    這也算是一項原則:發生頻率較低的情況應該略去。如果要把發生頻率極低的例外處理都畫出來,那就沒完沒了了。而且,畫得越細,整體就越難看懂。話雖如此,對於重要業務,也存在所謂的「應急預案 (Contingency Plan)」理念。即便極其罕見,也希望能確保一旦發生時能迅速切換流程。

    4. 那麼,到底該怎麼畫「業務流程圖」?

    基於必要的理由(第一章)、它不存在的理由(第二章)以及繪製困難的理由(第三章)……我想探討一下「業務流程圖的畫法」以及「應該由誰來畫業務流程圖」。

    是的……它必須是那種能夠輕鬆維護水平的業務流程圖。它必須是那種對全體勞動者都方便好用的業務流程圖。它必須是那種為了讓公司變得更好而存在的業務流程圖。

    4-1) IT 工具高級化的趨勢
    4-2) 國際記號標準化的趨勢
    4-3) 流程所有者 (Process Owner) 這一理念

    4-1. IT 工具高級化的趨勢

    不出所料,或者說這是理所當然的事,在工具層面我們希望借助 IT 的力量。電腦萬歲!

    進入 21 世紀後,基於「把業務上的數據交互交給電腦來做吧」這一思想的 IT 技術得到了開發。雖然這在 20 世紀以「工作流系統」的名義就已存在,但它是其大幅擴展後的 IT 產物。雖然認知度目前還不算高,但它被稱為「BPM 系統」。

    概念很簡單。只要通過業務流程圖等方式把業務規則教給電腦,電腦就會自動充當人與人之間數據交互的媒介。也就是說,電腦能判斷「下一環節是什麼」或者「這個案件應該流轉給誰處理」,從而順暢地推動工作流轉。例如,如果有人做好了「報價單」並輸入電腦,電腦就會去問申請人的上司:「請核對內容並決定是否批准」。再比如,如果有人寫好了「日語原稿」並輸入電腦,電腦就會告訴翻譯人員:「請把這份日語原稿翻譯成英語原稿」。

    無論是 100 個還是 1000 個任務,它都能掌握公司內所有業務的進度,不斷推動工作的流轉。說句不好聽的,人類成了其中的「齒輪」。電腦會把工作搬到你面前,你只需按部就班地完成作業即可。

    順帶一提,工業革命帶來的「機械化」曾引發人們對人類尊嚴的質疑,而這一「IT 化」趨勢也將導致人類工作的大幅減少。但是,人類只需去承擔下一個角色即可。就像智慧型手機幫我們記住了電話號碼後,人類雖然退化了,但這未嘗不是好事。(在西洋棋或將棋中輸了也沒關係吧。寫小說、寫部落格……只有人類才能做的事情還有很多)

    4-2. 國際記號標準化的趨勢

    既然如此,那就必須是那種能夠輕鬆維護水平的業務流程圖。

    這是全世界的人都在思考的問題,迄今為止也有許多業務流程圖格式(圖示的畫法以及圖示之間的連接方式)被提了出來。

    2000 年以後,伴隨著這一「IT 工具高級化的趨勢」,業務流程圖的畫法(描繪方式)統一為了 BPMN 這一格式。格式本身目前仍在進化過程中,但已成為不容置疑的標準(事實標準)。這是由 IBM、Oracle、Microsoft 等 IT 巨頭主導的產物,具有極高的合理性,其特徵是無論電腦還是人類都易於理解。(這可不僅僅是 Questetra 一家的主張)

    最近,美國政府和日本政府也相繼出現了採用的跡象,政府內部業務由 BPMN 描述的那一天已指日可待。(關鍵詞:「業務與系統優化」)

    4-3. 流程所有者 (Process Owner) 這一理念

    「是不是只要用好 IT 工具 (BPM 系統) 並學習 BPMN 就行了?」 答案是響亮的「是」。

    但是,還有更重要的事情。那就是明確誰是業務流程圖的維護責任人。他們被稱為「流程所有者 (Process Owner)」。換句話說,應該為公司內的每一項業務流程確定一名流程所有者。初期即便兼職也可以。

    這是本稿中最關鍵、最重要、最 Important 的事情。(?!?!)

    正如資訊系統或品質管理一樣,這類人力成本雖然屬於「間接投資」,但從中長期來看,其投資效果應該非常高。不,應該說必須雇用那些投資效果高的人。根據組織的不同,甚至可能需要以高管待遇雇用統籌這些流程所有者的負責人。事實上,正如負責資訊戰略的 CIO (Chief Information Officer) 或技術戰略的 CTO (Chief Technical Officer) 一樣,設立負責全公司流程優化的 CPO (Chief Process Officer) 這一統籌職位的公司也不在少數。(雖然也有觀點認為應由 COO 或 CFO 承擔,但理應通過有關「業務流程」的專業知識來統治全公司)

    順帶一提,BPMN 也是為電腦而存在的。想要改善業務流程的普通大眾(包括基層的流程所有者),並不需要深入理解 BPMN 的深奧部分。但是,需要通過接觸大量的業務流程圖,達到大致能看懂的程度。

    那麼,流程所有者應該做什麼呢?(根據截至 2013 年的見解),我认为可以总结为:[A] 「學習方法論(秘訣)」和 [B] 「模仿優秀案例」。

    4-3-1. 學習方法論(秘訣)

    關於 [A] 方法論,雖然有《BPM 100 Success Secrets》等專業手冊,但目前尚不存在權威的教科書。(不過,我认为今後針對「OMG 認證 BPM 專家資格考試 (OCEB)」的深入淺出的解說書會出現的)。就目前而言,由於市面上已經流傳著各種關於業務流程畫法的良書或雜誌文章,只要關注它們就足夠了。

    4-3-2. 模仿優秀案例

    關於 [B] 優秀案例,目前還沒怎麼見到。這其實很正常,提高業務效率的秘訣是不會輕易公開的。在某些情況下,它是「競爭力的源泉」。不過,最近已經可以搜尋到大量的業務流程圖模板或範例了。Questetra 也不例外,營運著一個名為「工作流範例」的業務模板提案網站。裡面刊載了 500 多個業務流程圖,歡迎使用「報價單」或「請示書」等關鍵詞進行搜尋。

    5. 總結

    不知不覺寫了這麼長一篇文章(而且後半部分隱約能看出寫累了的感覺),最後是 Questetra 的廣告。(沒錯,我就是為了這個才寫的……)

    實際上……竟然…… Questetra 就是……這款夢幻 IT 工具「BPM 系統」的開發公司。(這鋪墊夠直白吧)。而且,我們還受到全球最大的調查公司 Gartner 的關注,被評為「全球 BPM 領域的 Cool Vendor」。(這恐怕是一件很厲害的事情)

    而且用法非常簡單。只要有 Web 瀏覽器就行 (SaaS BPM)。詳情請參閱《用戶支援網站》的手冊頁等,這裡僅摘錄部分步驟:

    1. 確定流程(拖拽操作)
      通過擺放圖示來設計業務流。各個處理環節(任務)用圓角矩形表示。
    2. 確定輸入項(數據設定)
      設計業務所需的欄位,如文本型、日期型、選項型等。
      例如:「申請理由」、「申請人姓名」等
    3. 設定訪問級別
      決定在哪個環節可以輸入哪些欄位。
      例如:「在審批環節不可編輯『申請理由』」等
    4. 設定負責人
      決定各個環節由誰(或哪個小組)負責處理。
      例如:「審批環節由申請人的上司負責」等
    5. 設定分支規則
      在網關處編寫條件分支表達式。
      例如:「500 萬日圓以上流轉至社長」等


    讓全世界的工作,流轉得更順暢!!
    株式會社 Questetra 執行長 (CEO) 今村元一 (2013-01-18)

  • 契約更新漏れは、仕組みで防ぐ

    契約更新漏れは、仕組みで防ぐ

    契約更新連絡を手作業で行っていたため送信漏れが発生し、解約率の上昇につながっていた。タイマーによる待機制御で指定日に確実に送信できるようになり、送信漏れがゼロに。業務負荷の軽減と顧客信頼性が向上した。

    1. 課題:契約更新連絡の漏れ

    DejiDejiコンサルティング社は、現在、約30社の顧客企業とDX推進支援に関する業務委託契約を締結しています。契約期間は3か月から1年程度で、そのうち約8割の顧客が契約を更新しています。営業部の契約管理担当者は、営業担当者がシステムに登録した顧客情報を参照し、契約終了の60日前および30日前に、顧客へ更新意思確認のメールを手作業で送信しています。

    しかし、契約管理担当者は他の業務も並行して担当しているため、業務が立て込むと、連絡すべきタイミングでメールを送信できない場合があります。連絡が遅れると、顧客は更新可否を判断するための検討時間を十分に確保できません。

    その結果、更新意思確認が遅れ、契約更新の機会を逃すリスクが生じていました。このような連絡の遅れは、解約率の上昇や追加フォローの増加を招き、営業担当者の業務負荷をさらに高める要因となっていました。

    2. 解決策:タイマーイベントで指定日に自動送信

    プロセスオーナーは、契約更新プロセスの中にタイマー中間イベントを組み込み、指定された日にメールが自動送信される仕組みを構築しました。

    具体的には、担当者が事前にメール内容を作成し、送信に不備がないかを確認(承認)します。承認後はプロセスが自動的に進行し、あらかじめ設定された送信日(60日前・30日前)まで待機します。送信日になると、メールが自動送信されます。

    これにより、決められた期日に確実に顧客へ連絡が届く状態が整いました。

    Basic Edition
    Advanced Edition
    Professional Edition
    ワークフロー図詳細を見る
    1.顧客登録

    営業担当者が顧客情報を登録します。

    x1.送信予定日時

    登録された顧客情報から契約更新の意思確認メール送信予定予定日時の情報が自動でセットされます。

    2.送信承認60日前

    契約担当者が契約終了60日前に、メールの内容や送信日に誤りがないか確認し、メール送信の承認を行います。

    60日前通知メール送信

    顧客にメールを送信します。

    3.送信承認30日前

    契約担当者が契約終了30日前に、メールの内容や送信日に誤りがないか確認し、メール送信の承認を行います。

    30日前通知メール送信

    顧客にメールを送信します。

    Basic Edition
    Advanced Edition
    Professional Edition
    ワークフロー図詳細を見る
    1.顧客登録

    営業担当者が顧客情報を登録します。

    x1.送信予定日時

    登録された顧客情報から契約更新の意思確認メール送信予定予定日時の情報が自動でセットされます。

    2.送信承認60日前

    契約担当者が契約終了60日前に、メールの内容や送信日に誤りがないか確認し、メール送信の承認を行います。

    待機60日前

    プロセスは60日前まで待機します。

    60日前通知メール送信

    顧客にメールを送信します。

    3.送信承認30日前

    契約担当者が契約終了30日前に、メールの内容や送信日に誤りがないか確認し、メール送信の承認を行います。

    待機30日前

    プロセスは30日前まで待機します。

    30日前通知メール送信

    顧客にメールを送信します。

    中央のバー操作で Before / After が比較できます

    3. 効果

    更新連絡の確実な実施

    指定日に自動送信されるため、メール送信漏れが発生せず、更新機会を逃さなくなりました。

    担当者業務負荷の軽減

    日次の確認作業や送信作業が不要となり、他の業務に集中できるようになりました。

    顧客信頼性の向上

    適切なタイミングで連絡が届くことで、顧客に安心感を与え、継続率の維持につながりました。

    4. その他の業務への応用

    請求書送付タイミングの自動化

    支払期日前に自動送信することで、請求漏れや送付遅延を防止できます。

    定期レポート配信の自動化

    月次・四半期レポートを指定日に送信し、報告業務の属人化を防げます。

    契約満了通知の自動送信

    契約終了前の事前通知を自動化し、更新や終了判断を円滑に進められます。

  • 为什么我们科长不画业务流程图?

    为什么我们科长不画业务流程图?

    English version

    为什么我们经理不画业务流程图?

    0. “业务流程图”究竟是个啥?

    最近,我收到了好几个人发表的评论,说:“压根儿就不明白业务流程的必要性在哪儿。”

    也难怪,对于普通人来说,恐怕根本就没见过业务流程图这种东西。当然,更不可能有按照业务流程图来处理工作的经验……我在(心里默默地)想,既然如此,不明白它的必要性也再正常不过了……

    所以,今天我想回归初心,针对“业务流程图的必要性以及具体的业务流程图画法”,把目前思考的内容整理出来。(这可能是一项相当繁重的工作……)

    “Web原稿制作”业务流程图示例

    1. 究竟为何需要“业务流程图”?

    首先,“业务流程图”到底是什么?

    有的叫它“流程图(Flowchart)”,有的叫“业务过程图(Business Process Diagram)”,还有的叫“工作流图(Workflow Diagram)”……说法五花八门。简单来说,就是“能让人看懂业务如何开展的图”。在日本的行政机关,它被正式称为“业务流转图”

    其最大的特征在于,业务手册是用“文字”编写的,而业务流程图则是用被称为“图表”(Chart)的图形来描述的。……如果想用外来词蒙混过关的话,肯定会被人追问“那 Chart 到底是个啥?”,Chart 本意是指“海图、航空图、天气图”。也就是说,业务流程图是“为了了解应行之路而绘制的地图”。“Flow(流)”+“Chart(图)”这一表达的含义就是“能看清全局走向的图”。与文字不同,它能让人迅速理解整体脉络。

    说起来,以前承蒙过一本叫“Chart式”的数学参考书的照顾。据说它的名字寄托了“希望这本参考书能像船上的海图一样发挥指引作用”的愿望(摘自维基百科)。(那时候“红皮Chart”对我来说可是相当大的考验啊……嗯?这不重要!)

    理想的业务流程图,应该能让全体员工解决以下问题:

    • 在整体业务流程中,我负责哪一个作业环节?
    • 我需要接收什么(INPUT),产出什么(manufacture),并交给谁(OUTPUT)?

    1-1) 【同步】为了在公司内同步现状流程,或沟通变更内容
    1-2) 【培训】为了在公司内传授现状流程
    1-3) 【外部报告】为了向公司外部报告现状流程

    1-1. 为了在公司内同步现状流程,或沟通变更内容

    这是我列举的第一项需求。

    例如,如果你想进行诸如“优化业务流以提升团队整体生产力”或“设计防止舞弊的信息传递程序”等进阶讨论,那么一份详尽的现状业务流程图就是必不可少的……

    不过……“在公司内同步现状或沟通变更”实际上是一个非常高阶的利用目的。当你真正尝试绘制时会发现,即使是那些驾轻就熟的日常工作,往往也存在严重的“因人而异”情况,或者说“流派”林立。也就是说,“现状流程”往往是“千人千面”。说白了,大家各做各的。例如,以下这种“因人而异”的例子,在任何公司都随处可见:

    1-1-1. 投诉处理流程

    在撰写投诉回复邮件时,员工 A 总是先让上司审阅完所有回复内容后再发送,而员工 B 则只是偶尔才让上司审阅。

    1-1-2. 新 Web 页面上线流程

    在官网上线新页面时,员工 A 习惯先让设计师画插图,自己同步写正文,然后再请设计师排版;而员工 B 则是等正文完全写好后,才一次性委托设计师处理插图和排版。

    顺便提一下,“业务流程因人而异(属人化)”这种说法往往会引起很大的误解。
    -A. 担当者技能的个人化:“因人而异导致产出质量(结果)不同”
    -B. 信息传递路径的个人化:“因人而异导致传递步骤和路径不同”
    不言而喻,我们这里指的是 (B)“工作流转的路径和顺序没有统一规则”。但在日常谈话中,人们更多是在 (A) 的语境下使用这个词。在讨论过程中两者容易发生偷换,因此需要特别注意。例如,在说“由于 Excel 水平因人而异导致成果参差不齐”或“A 部长和 B 部长的判断标准不同”时,也常被冠以“业务(流程)属人化”的说法,但实际上,这种情况下业务流程往往反而是标准化的。

    1-2. 为了在公司内传授现状

    “在公司内传授现状流程”是一个非常直观的需求。

    比如在团队接收新人时,如果有流程图就会非常方便。无论是校招新人还是人事调动,只要把图往他手里一递:“喏,我们团队就是按这么个路数干活的”,新人就能立刻掌握大致的工作流转。对于处于扩张期、大量招人的企业或人事调动频繁的公司,流程图可谓是非常有效的武器。这可比说“给你一份公司规章和操作手册……”要强百倍。(反正他们绝对不会读的……爆)

    对于那些试图用“我们这儿可没流程图这种玩意儿。是 OJT,O-J-T(在职培训)!”这种时髦词汇掩饰的上司,需要格外小心。诚然,投身实战、身体力行的 On Job Training 从快速培养战斗力的角度来看确实是种有效手段。但另一方面,它往往也可能演变成一种“狮子摔子(不给支援)”式的残酷训练。也就是说,得不到前辈指导的新人只能靠自己从悬崖下往上爬,结果就是在完全没有传承到公司核心“业务流转”经验的情况下长大了。(并建立了一套野路子的“业务流转”?)

    1-3. 为了向公司外部报告现状流程

    与前两个需求相比,第三个“1-3. 向外部报告”可能是一个略显消极的需求。

    最典型的例子就是基于 SOX 法(萨班斯法案)的内部控制报告制度。上市企业等需要向金融厅提交“业务流转图”,以此证明公司的治理是有效的。这最终有助于保护投资者。(不过,提交了报告并不意味着现场就会变得更有活力,也不意味着销售额会增长……)

    2. 那么,为何“业务流程图”并不存在?

    在第一章中,利用目的(需求)已经明确了(?)。业务流程图是必要的(!)。

    那么,既然是“必要的东西”,为什么往往“没有”(或者说不画)呢?

    2-1) 画不出来
    2-2) 虽然会画,但觉得没意义所以不画
    2-3) 虽然会画,但不知道该谁画所以不画

    2-1. 画不出来

    “画不出来”这点很好理解。

    做不出来的东西自然没法存在。如果有老鹰,还可能生出小鹰,但如果连老鹰都没有,那自然什么也生不出来。(这比喻好像不太对)

    但这种情况实际上非常多。你可以尝试描绘一下身边的业务流程。即使是久经沙场的老员工,在打开 Power Point 或 Visio 点击“新建”的那一刻,面对那张空白画布,往往也不知道该从何写起。这并不是因为不了解业务,相反,他们可能比谁都清楚。纯粹是因为业务流程的描绘太难了。(它看不见摸不着。它不是能用照片或视频拍下来的东西。而且平时也根本没机会见到别人的案例。)

    笔者本人至今已拥有建模约 500 个业务的经验。正因如此,我现在只要听一遍访谈,就能当场画出业务流程图(←纯属自夸)。但是,刚开始的时候,画好一个流程图要花 5 个甚至 10 个小时。而且,睡一觉起来再看那个流程图,总能发现好几处需要改进的地方。前 10 个流程图往往都要经历无数次推倒重来。(笨蛋笨蛋笨蛋。致:昨天的我,来自:今天的我)

    2-2. 虽然会画,但觉得没意义所以不画

    “虽然会画,但觉得没意义所以不画”,在某种意义上是一种很深刻的状况。

    但这种情况也不在少数。那么,为什么会觉得“没意义”呢?这通常可以归结为以下两个理由:

    • A) “因为业务流程图很快就会过时(陈旧化)”
    • B) “单靠业务流程图无法管控业务的流转”

    以 [A] 业务流程图的陈旧化为例,比如 [A1]“电脑采购改为由行政部统一调拨了”或者 [A2]“组织架构调整导致部门和团队结构变了”等内部因素,以及 [A3]“由于竞争对手出现,必须将标准交付期缩短一半”等外部因素,都会导致业务流程本身发生变化。在那一瞬间,好不容易画好的流程图就成了过去式。维护起来有多难就不用我多说了。此外,关于 [B] 管控困难的问题,虽然可以考虑“把流程图贴在墙上”、“每月进行研修”等各种措施,但仅凭画在纸上的业务流程图,其效力确实有限。

    2-3. 虽然会画,但不知道该谁画所以不画

    “虽然会画,但不知道该谁画所以不画”,这就让人头疼了。

    明明能做却不做,说白了就是某种职责履行缺位。你可能会觉得意外,但在业务流程管理已经成熟的组织中,这种情况反而经常发生。

    例如,当涉及到如何让生产部门和销售部门的工作流转得更顺畅时,不可避免地会产生利益冲突。这就是所谓的跨部门业务流程。诸如“订单信息的校验工作应该由销售部门在前期完成吧”之类的棘手话题,必须有个了断。这不仅需要精通双方部门的业务,还需要本着“全局优化”的名义进行调停。毕竟人嘛,都想离麻烦事远一点。(这种情况属于高深的组织论范畴。归根结底,似乎只能由组织最高层任命一名“流程所有者(Process Owner)”来解决了)

    3. 顺便说下,为何“业务流程图”画起来这么难?

    绘制业务流程图确实很难。(正如在“2-1. 画不出来”中提到的)。在这里,我想深挖一下业务流程图难以动笔的原因。

    顺便提一下,我们不讨论绘图工具方面的问题。也就是说,如果把绘图比作画画,我们不讨论纸笔的问题。在这里,我想探讨的是诸如“奔马”为何难画、“人体”为何难画这种对象物本身所蕴含的难度

    3-1) 其实根本就没有内部规则
    3-2) 应该以多大的颗粒度来描述处理步骤,让人很纠结
    3-3) 例外处理应该写到什么程度,让人很纠结

    3-1. 其实根本就没有内部规则

    “其实根本就没有内部规则”,这简直让人扼腕。

    毕竟你想描绘的模特根本就不在场。嘛,直接说“不在”可能有点太粗暴了,但如果你想画的业务流程,一会儿像“马”,一会儿像“车”,一会儿又像“寺庙”……当你完全搞不清它真实的形态时,自然没法动笔。

    没有业务流程(内部规则),业务还能运转吗?嘛,它确实能动。只能说,人类这种生物实在是太了不起了。

    3-2. 应该以多大的颗粒度来描述处理步骤,让人很纠结

    “应该以多大的颗粒度来写”,这是高手才会说的话。

    我在第一章中以“撰写投诉回复邮件”作为一个作业环节举了例,但它还可以进一步分解为“撰写标题”、“撰写正文”、“复核”等。描绘的颗粒度可以无限细分。虽然存在各种颗粒度设定的方法,但作为一项原则,业务流程图中描绘的环节颗粒度最好设定为“一名员工接收 INPUT 到产出 OUTPUT 为止的一个完整动作”。

    3-3. 例外处理应该写到什么程度,让人很纠结

    “例外处理应该写到什么程度”,这是一个终极难题。甚至可以说是永恒的烦恼。

    这也算是一项原则:发生频率较低的情况应该略去。如果要把发生频率极低的例外处理都画出来,那就没完没了了。而且,画得越细,整体就越难看懂。话虽如此,对于重要业务,也存在所谓的“应急预案(Contingency Plan)”理念。即便极其罕见,也希望能确保一旦发生时能迅速切换流程。

    4. 那么,到底该怎么画“业务流程图”?

    基于必要的理由(第一章)、它不存在的理由(第二章)以及绘制困难的理由(第三章)……我想探讨一下“业务流程图的画法”以及“应该由谁来画业务流程图”。

    是的……它必须是那种能够轻松维护水平的业务流程图。它必须是那种对全体劳动者都方便好用的业务流程图。它必须是那种为了让公司变得更好而存在的业务流程图。

    4-1) IT 工具高级化的趋势
    4-2) 国际记号标准化的趋势
    4-3) 流程所有者(Process Owner)这一理念

    4-1. IT 工具高级化的趋势

    不出所料,或者说这是理所当然的事,在工具层面我们希望借助 IT 的力量。计算机万岁!

    进入 21 世纪后,基于“把业务上的数据交互交给计算机来做吧”这一思想的 IT 技术得到了开发。虽然这在 20 世纪以“工作流系统”的名义就已存在,但它是其大幅扩展后的 IT 产物。虽然认知度目前还不算高,但它被称为“BPM 系统”。

    概念很简单。只要通过业务流程图等方式把业务规则教给计算机,计算机就会自动充当人与人之间数据交互的媒介。也就是说,计算机能判断“下一环节是什么”或者“这个案件应该流转给谁处理”,从而顺畅地推动工作流转。例如,如果有人做好了“报价单”并录入计算机,计算机就会去问申请人的上司:“请核对内容并决定是否批准”。再比如,如果有人写好了“日语原稿”并录入计算机,计算机就会告诉翻译人员:“请把这份日语原稿翻译成英语原稿”。

    无论是 100 个还是 1000 个任务,它都能掌握公司内所有业务的进度,不断推动工作的流转。说句不好听的,人类成了其中的“齿轮”。计算机会把工作搬到你面前,你只需按部就班地完成作业即可。

    顺便提一下,工业革命带来的“机械化”曾引发人们对人类尊严的质疑,而这一“IT 化”趋势也将导致人类工作的大幅减少。但是,人类只需去承担下一个角色即可。就像智能手机帮我们记住了电话号码后,人类虽然退化了,但这未尝不是好事。(在国际象棋或将棋中输了也没关系吧。写小说、写博客……只有人类才能做的事情还有很多)

    4-2. 国际记号标准化的趋势

    既然如此,那就必须是那种能够轻松维护水平的业务流程图。

    这是全世界的人都在思考的问题,迄今为止也有许多业务流程图格式(图标的画法以及图标之间的连接方式)被提了出来。

    2000 年以后,伴随着这一“IT 工具高级化的趋势”,业务流程图的画法(描绘方式)统一为了 BPMN 这一格式。格式本身目前仍在进化过程中,但已成为不容置疑的标准(事实标准)。这是由 IBM、Oracle、Microsoft 等 IT 巨头主导的产物,具有极高的合理性,其特征是无论计算机还是人类都易于理解。(这可不仅仅是 Questetra 一家的主张)

    最近,美国政府和日本政府也相继出现了采用的迹象,政府内部业务由 BPMN 描述的那一天已指日可待。(关键词:“业务与系统优化”)

    4-3. 流程所有者(Process Owner)这一理念

    “是不是只要用好 IT 工具(BPM 系统)并学习 BPMN 就行了?” 答案是响亮的“是”。

    但是,还有更重要的事情。那就是明确谁是业务流程图的维护责任人。他们被称为“流程所有者(Process Owner)”。换句话说,应该为公司内的每一项业务流程确定一名流程所有者。初期即便兼职也可以。

    这是本稿中最关键、最重要、最 Important 的事情。(?!?!)

    正如信息系统或质量管理一样,这类人力成本虽然属于“间接投资”,但从中长期来看,其投资效果应该非常高。不,应该说必须雇用那些投资效果高的人。根据组织的不同,甚至可能需要以高管待遇雇用统筹这些流程所有者的负责人。事实上,正如负责信息战略的 CIO (Chief Information Officer) 或技术战略的 CTO (Chief Technical Officer) 一样,设立负责全公司流程优化的 CPO (Chief Process Officer) 这一统筹职位的公司也不在少数。(虽然也有观点认为应由 COO 或 CFO 承担,但理应通过有关“业务流程”的专业知识来统治全公司)

    顺便提一下,BPMN 也是为计算机而存在的。想要改善业务流程的普通大众(包括基层的流程所有者),并不需要深入理解 BPMN 的深奥部分。但是,需要通过接触大量的业务流程图,达到大致能看懂的程度。

    那么,流程所有者应该做什么呢?(根据截至 2013 年的见解),我认为可以总结为:[A]“学习方法论(秘诀)”和[B]“模仿优秀案例”。

    4-3-1. 学习方法论(秘诀)

    关于 [A] 方法论,虽然有《BPM 100 Success Secrets》等专业手册,但目前尚不存在权威的教科书。(不过,我认为今后针对“OMG 认证 BPM 专家资格考试(OCEB)”的深入浅出的解说书会出现的)。就目前而言,由于市面上已经流传着各种关于业务流程画法的良书或杂志文章,只要关注它们就足够了。

    4-3-2. 模仿优秀案例

    关于 [B] 优秀案例,目前还没怎么见到。这其实很正常,提高业务效率的秘诀是不会轻易公开的。在某些情况下,它是“竞争力的源泉”。不过,最近已经可以搜索到大量的业务流程图模板或样例了。Questetra 也不例外,运营着一个名为“工作流样例”的业务模板提案网站。里面刊载了 500 多个业务流程图,欢迎使用“报价单”或“请示书”等关键词进行搜索。

    5. 总结

    不知不觉写了这么长一篇文章(而且后半部分隐约能看出写累了的感觉),最后是 Questetra 的广告。(没错,我就是为了这个才写的……)

    实际上……竟然…… Questetra 就是……这款梦幻 IT 工具“BPM 系统”的开发公司。(这铺垫够直白吧)。而且,我们还受到全球最大的调查公司 Gartner 的关注,被评为“全球 BPM 领域的 Cool Vendor”。(这恐怕是一件很厉害的事情)

    而且用法非常简单。只要有 Web 浏览器就行(SaaS BPM)。详情请参阅《用户支持网站》的手册页等,这里仅摘录部分步骤:

    1. 确定流程(拖拽操作)
      通过摆放图标来设计业务流。各个处理环节(任务)用圆角矩形表示。
    2. 确定输入项(数据设定)
      设计业务所需的字段,如文本型、日期型、选项型等。
      例如:“申请理由”、“申请人姓名”等
    3. 设定访问级别
      决定在哪个环节可以输入哪些字段。
      例如:“在审批环节不可编辑‘申请理由’”等
    4. 设定负责人
      决定各个环节由谁(或哪个小组)负责处理。
      例如:“审批环节由申请人的上司负责”等
    5. 设定分支规则
      在网关处编写条件分支表达式。
      例如:“500 万日元以上流转至社长”等


    让全世界的工作,流转得更顺畅!!
    株式会社 Questetra 代表执行役 CEO 今村元一 (2013-01-18)

  • 【受賞報告】Questetra BPM Suite、「ITreview Grid Award 2026 Winter」 にてワークフローシステム部門「High Performer」を受賞

    【受賞報告】Questetra BPM Suite、「ITreview Grid Award 2026 Winter」 にてワークフローシステム部門「High Performer」を受賞

    株式会社クエステトラ(本社:京都市中京区、代表執行役CEO:今村元一)は、同社が提供するクラウド型業務プロセス管理システム「Questetra BPM Suite」が、「ITreview Grid Award 2026 Winter」のワークフローシステム部門で「High Performer」を受賞したことをお知らせします。

    また、BPMツール部門(BPM:Business Process Management)においても「Leader」を受賞し、2部門での受賞を果たしました。

    受賞カテゴリーの詳細は、以下をご参照ください。

    株式会社クエステトラは今後も、ITreview をはじめとするお客様から寄せられるレビューを真摯に受け止め、「Questetra BPM Suite」の顧客満足度向上に努めてまいります。

    ITreview Grid Award 2026 Winter について

    アイティクラウド株式会社(本社:東京都港区、代表取締役社長 兼 CEO:黒野 源太)が運営する「ITreview」は、ビジネス向けIT製品・クラウドサービスのレビュープラットフォームです。

    ITreview Grid Award とは、同プラットフォームに投稿された実際のユーザーレビューをもとに、四半期ごとに優れたIT製品・クラウドサービスを表彰するアワードです。顧客満足度および市場での認知度の観点から評価され、一定の基準を満たした製品には、その評価を示すバッジが付与されます。

    「High Performer」はユーザーから高い顧客満足度を獲得している製品に、「Leader」は高い満足度に加え、認知度の面でも優れた評価を得ている製品に与えられる、名誉ある称号です。

    ユーザーレビュー(例)

    Questetra BPM Suite とは

    Questetra BPM Suite は、クラウド型の業務プロセス管理システム (SaaS BPMS) です。ワークフローシステム(ワークフローアプリ)の開発および運用が、Webブラウザだけで完結します。プログラミングの知識(Codingスキル)は必要ありません。業務部門が主体となって、継続的に業務プロセスを改善できます。

    稟議申請や見積提出、問い合わせ対応などの定型業務プロセスを、ワークフローシステムとしてノーコードで作成できます。さらに、生成AIを組み込むことで、「ドラフト文書の自動生成」や「回答案の草案作成」といった知的作業の自動化も実現できます。

    Questetra BPM Suite では、実際の操作感や業務への適合性を確認できる無料トライアルを提供しています。ワークフローシステムや業務改善基盤の導入をご検討中の方は、ぜひお気軽にお問い合わせください。

    ・60日間無料トライアルはこちら: https://questetra.com/ja/
    ・お問い合わせはこちら    : https://questetra.com/ja/contact/

    株式会社クエステトラ

    株式会社クエステトラは京都を拠点とする SaaS BPM ベンダーです。世界中のビジネスプロセスを最適化します。

    商号

    株式会社クエステトラ (Questetra, Inc.)

    代表

    代表執行役CEO 今村 元一

    所在地

    京都市中京区御池通間之町東入高宮町206 御池ビル4階

    設立

    2008年4月

    資本金

    1億8405万7500円

    本プレスリリースに関する問い合わせ

    pr@questetra.com or 075-205-5007

  • 提升營運品質的三個途徑

    提升營運品質的三個途徑

    提升業務品質是企業面臨的重要課題,也是提高產品與服務品質不可或缺的條件。

    本文將在明確「業務品質提升」定義的基礎上,詳細解析提升業務品質的具體方法。

    什麼是業務品質提升?

    雖然「業務品質提升」這一術語的定義有時較為模糊,但在這裡,我們將解決以下三個課題定義為業務品質提升:

    1. 減少工作(作業)中的錯誤(提高精確度)
    2. 增加單位時間內的處理數量(提高生產力)
    3. 消除因負責人不同而產生的品質波動(穩定作業品質)

    關於第1點,或許無需贅言,作業精確度的提升會直接帶動產品與服務品質的提高,這是不言而喻的。然而,如果為了提高精確度而導致作業時間延長,生產力就會下降,甚至可能增加額外的成本。

    因此,第2點提到的「在保持精確度的同時提高生產力」就顯得至關重要。當然,如果能在控制成本的同時,實現精確度與生產力的雙重提升,那是理想的狀態。

    而第3點則是針對減少品質波動的舉措。例如,新手與資深員工在作業熟練度上自然存在差異,這種差異需要被抑制。根據行業不同,可能還需要消除由時段或季節等條件引起的品質波動。

    解決這些課題將直接關係到產品、服務品質及客戶滿意度的提升。那麼,基於這三個關鍵點,我們具體該如何提升業務品質呢?

    提升業務品質的三種方法

    1. 可視化與定量化

    在提升業務品質的過程中,首先要實踐的是業務的「可視化」與「定量化」。

    可視化有時也被稱為「可視化管理」,這裡是指通過圖表等形式展現業務現狀,以「肉眼可見的形式」梳理出整個業務流程及存在的問題與課題。此外,在定量化方面,需要測量並數據化必要的資料,例如從作業開始到完成所需的前置時間(Lead Time)。此時,不僅要明確現狀數值,還要明確目標數值,這樣能更順暢地解決課題。

    2. 標準化與最佳化

    另一方面,要改善業務品質的「波動」,首先必須實現業務標準化。

    例如:

    • 只有特定的人才能處理某項業務(過度依賴特定人員 / 業務碎片化)
    • 每個人都按自己的方式進行作業

    這類情況很容易導致業務品質參差不齊或業務停滯。

    因此,需要通過將業務步驟與注意事項轉化為 SOP(標準作業程序),實現「標準化」,使任何人都能開展作業。當然,在進行標準化時,必須提煉出在當時看來最佳的作業流程。

    此外,在實施標準化後,進行第1點所述的可視化與定量化,並對成果進行衡量與驗證非常重要。而且,制定的手冊與流程必須根據作業環境的變化及社會形勢,不斷地進行「最佳化」,使其始終保持最佳狀態。

    3. 數位化與自動化

    在上述要點的延伸線上,便是業務的數位化與自動化。

    例如,將基於紙本進行的業務電子化,可以降低紙本文件的保管與管理成本。此外,如果累積的數據在電腦上得到了妥善管理,就能省去查找過往文件的時間。這種「管理的便捷性」與「檢索便利性的提高」,是提升業務效率與業務品質的關鍵點。

    另一方面,如果利用 RPA 工具等實現作業自動化,就能消除作業品質的波動。由人工操作時,受負責人狀態或疲勞程度等因素影響,作業精確度難免會出現波動;而使用 RPA 由機器人執行作業,則可以保持穩定且無差異的作業品質。

    此外,利用被稱為「工作流系統」的軟體,可以實現整個業務「流程」的自動化。下一項將結合具體案例,講解工作流系統與提升業務品質的關係。

    助力業務品質提升的工作流系統

    工作流系統是一套協助企業輕鬆實現業務流程可視化的軟體。

    該軟體能根據創建的流程圖自動推進業務,並實現工作的自動交接。由於工作流系統中累積了業務往來記錄及處理耗時等數據,因此對作業衡量與驗證所需的定量化也變得非常容易。這與業務自動推進及可視化便捷性相結合,在進行業務標準化時將提供巨大幫助。

    此外,通過應用工作流系統,還可以實現申請、審核、簽核、報價、合約及開立發票等各種日常業務的數位化

    例如,在導入 Questetra BPM Suite 實現訂單審核業務自動化與數位化的 Vital Information 股份有限公司案例中,每年約 500 件申請所伴隨的紙本文件消失了,從而削減了紙張印刷費用與存儲空間。該案例還報告稱,管理部門以往進行的存檔文件印刷及歸檔作業也隨之消失,每月節省了約 20 小時的業務時間。

    順便提一下,我們提供的 Questetra BPM Suite 是一款雲端工作流系統。

    雲端系統的特點包括申請後即可立即使用,以及只要有網路環境,無論身處何地都能輕鬆訪問與辦公室相同的系統進行工作等。

    能夠強力支持業務品質提升的 Questetra BPM Suite 目前提供免費試用。立即免費試用 Questetra BPM Suite,開啟您的業務優化之旅。

  • 提升运营质量的三个途径

    提升运营质量的三个途径

    提升运营质量是企业面临的重要课题,也是提高产品和服务品质不可或缺的条件。

    本文将在明确“运营质量提升”定义的基础上,详细解析提升运营质量的具体方法。

    什么是运营质量提升?

    虽然“运营质量提升”这一术语的定义有时较为模糊,但在这里,我们将解决以下三个课题定义为运营质量提升:

    1. 减少工作(作业)中的错误(提高精度)
    2. 增加单位时间内的处理数量(提高生产率)
    3. 消除因负责人不同而产生的质量波动(稳定作业质量)

    关于第1点,或许无需赘言,作业精度的提升会直接带动产品和服务品质的提高,这是不言而喻的。然而,如果为了提高精度而导致作业时间延长,生产率就会下降,甚至可能增加额外的成本。

    因此,第2点提到的“在保持精度的同时提高生产率”就显得至关重要。当然,如果能在控制成本的同时,实现精度和生产率的双重提升,那是理想的状态。

    而第3点则是针对减少质量波动的举措。例如,新手和资深员工在作业熟练度上自然存在差异,这种差异需要被抑制。根据行业不同,可能还需要消除由时段或季节等条件引起的质量波动。

    解决这些课题将直接关系到产品、服务质量及客户满意度的提升。那么,基于这三个关键点,我们具体该如何提升运营质量呢?

    提升运营质量的三种方法

    1. 可视化与定量化

    在提升运营质量的过程中,首先要实践的是业务的“可视化”与“定量化”。

    可视化有时也被称为“可见化”,这里是指通过图表等形式展现业务现状,以“肉眼可见的形式”梳理出整个业务流程及存在的问题和课题。此外,在定量化方面,需要测量并数值化必要的数据,例如从作业开始到完成所需的交付周期(Lead Time)。此时,不仅要明确现状数值,还要明确目标数值,这样能更顺畅地解决课题。

    2. 标准化与优化

    另一方面,要改善运营质量的“波动”,首先必须实现业务标准化。

    例如:

    • 只有特定的人才能处理某项业务(过度依赖特定人员/业务碎片化)
    • 每个人都按自己的方式进行作业

    这类情况很容易导致运营质量参差不齐或业务停滞。

    因此,需要通过将业务步骤和注意事项转化为SOP,实现“标准化”,使任何人都能开展作业。当然,在进行标准化时,必须提炼出在当时看来最佳的作业流程。

    此外,在实施标准化后,进行第1点所述的可视化和定量化,并对成果进行衡量和验证非常重要。而且,制定的手册和流程必须根据作业环境的变化及社会形势,不断地进行“优化”,使其始终保持最佳状态。

    3. 无纸化与自动化

    在上述要点的延伸线上,便是业务的无纸化与自动化。

    例如,将基于纸质进行的业务电子化,可以降低纸质文件的保管和管理成本。此外,如果积累的数据在电脑上得到了妥善管理,就能省去查找过往文件的时间。这种“管理的便捷性”和“检索便利性的提高”,是提升业务效率和运营质量的关键点。

    另一方面,如果利用 RPA 工具等实现作业自动化,就能消除作业质量的波动。由人工操作时,受负责人状态或疲劳程度等因素影响,作业精度难免会出现波动;而使用 RPA 由机器人执行作业,则可以保持稳定且无差异的作业质量。

    此外,利用被称为“工作流系统”的软件,可以实现整个业务“流程”的自动化。下一项将结合具体案例,讲解工作流系统与提升运营质量的关系。

    助力运营质量提升的工作流系统

    工作流系统是一款可以在电脑上轻松实现业务流程可视化的软件。

    该软件能根据创建的流程图自动推进业务,并实现工作的自动交接。由于工作流系统中积累了业务往来记录及处理耗时等数据,因此对作业衡量和验证所需的定量化也变得非常容易。这与业务自动推进及可视化便捷性相结合,在进行业务标准化时将提供巨大帮助。

    此外,通过应用工作流系统,还可以实现申请、审批、报批、报价、合同及开票等各种日常业务的无纸化

    例如,在导入 Questetra BPM Suite 实现订单审批业务自动化和无纸化的Vital Information 股份有限公司的案例中,每年约 500 件申请所伴随的纸质文件消失了,从而削减了纸张印刷费用和存储空间。该案例还报告称,管理部门以往进行的存档文件印刷及归档作业也随之消失,每月节省了约 20 小时的业务时间。

    顺便提一下,我们提供的 Questetra BPM Suite 是一款云端工作流系统。

    云型系统的特点包括申请后即可立即使用,以及只要有网络环境,无论身处何地都能轻松访问与办公室相同的系统进行工作等。

    能够强力支持业务质量提升的 Questetra BPM Suite 目前提供免费试用。立即免费试用 Questetra BPM Suite,开启您的业务优化之旅。

  • 集計後の数値変化をAIで文章化

    集計後の数値変化をAIで文章化

    AIが売上データを分析し、注目すべき変化を自動要約。取引先別の増減を分かりやすく文章化し、見落としがちな中規模取引先の変化にも気づけるようになった。経営層と営業部の認識を揃えて迅速な判断につなげる。

    1. 課題:取引先別売上の大規模化で変化が埋もれる

    MokuMokuクラウド社の経理部は3名体制で、会計データの取込みから月次の取引先別売上集計、前月比の算出までを仕組み化していました。これらの定例業務は安定して運用されており、集計結果は経営層や営業部にも共有されていました。

    しかし、取引先数の増加により、取引先別売上高一覧(前月比付き)は数百行規模となり、経理担当者が一覧を目視で確認しても、どの取引先を重点的にチェックすべきか判断できない状態になっていました。

    実際の月次確認作業では、上位数社については売上金額や前月比の増減を把握できていました。一方で、売上規模が中程度の取引先では、前月比に大きな変動があっても一覧の中に埋もれ、営業部や経営層に共有すべき変化を十分に拾い上げられていませんでした。

    2. 解決策:AIに売上変化の要点を文章で説明させる

    プロセスオーナーは、集計後の工程にAIエージェントを追加し、数値一覧に加えて変化の内容がテキストでアウトプットされるようにしました。

    具体的には、AIエージェントに「前月と当月の差分データから、特筆すべき売上変化を簡潔に説明する」というプロンプトを設定しました。これにより、差分データの中から変化が大きい点や特徴的な動きが抽出されます。月次処理が実行されるたびに、AIは取引先別売上の変化を文章で要約します。

    Basic Edition
    Advanced Edition
    Professional Edition
    ワークフロー図詳細を見る
    2ファイルを登録

    当月ファイルと前月ファイルを登録し、月次比較の処理を開始します。

    ピボット集計

    取引先 × 補助科目単位で売上金額を集計し、月次の売上構造を一覧化します。

    ピボット結合

    当月と前月の集計結果を共通項目で結合し、比較可能なデータを作成します。

    差分と変化率の算出

    前月比の増減額および変化率を算出し、売上の変化を数値として明確にします。

    email

    経営層および営業部へ自動通知(共有)します。

    Basic Edition
    Advanced Edition
    Professional Edition
    ワークフロー図詳細を見る
    2ファイルを登録

    当月ファイルと前月ファイルを登録し、月次比較の処理を開始します。

    ピボット集計

    取引先 × 補助科目単位で売上金額を集計し、月次の売上構造を一覧化します。

    ピボット結合

    当月と前月の集計結果を共通項目で結合し、比較可能なデータを作成します。

    差分と変化率の算出

    前月比の増減額および変化率を算出し、売上の変化を数値として明確にします。

    AIエージェント

    差分データをもとに、前月から当月にかけて特筆すべき売上変化をAIが文章で要約します。

    上位取引先だけでなく、中規模取引先の重要な変化も抽出します。

    email

    AIが整理した注目ポイントを、経営層および営業部へ自動通知(共有)します。

    中央のバー操作で Before / After が比較できます

    3. 効果

    重要な変化の即時把握

    集計表を開く前に、売上が大きく増減している取引先を文章で把握できます。

    中規模取引先の変化の可視化

    上位取引先だけでなく、売上規模が中程度の取引先で起きている変化にも気づきやすくなりました。

    関係者間の認識統一

    経営層と営業部が、注目すべき取引先や売上変化を同じ前提で把握できます。

    分析・説明負荷の軽減

    集計結果の読み取りや説明にかかる手間が減り、改善策の検討に時間を使えるようになりました。

    4. その他の業務への応用

    問い合わせ対応状況の把握

    日別・担当者別に集計された問い合わせ件数をもとに、対応件数や遅延が目立つポイントをAIが文章で要約することで、管理者は詳細な一覧を見る前に、対応が滞っている領域を把握できます。

    プロジェクト進捗の確認

    タスク数や進捗率をまとめた一覧表から、遅延が広がっている工程や、想定外に工数が増えている作業をAIが抽出し、注目点として提示することで、早めの軌道修正につなげられます。

    人事・勤怠データのチェック

    部署別・月別に集計された残業時間や休暇取得状況をもとに、前月から大きく変化している部署や個人をAIが整理して伝えることで、管理職は注意すべき傾向をすぐに把握できます。

  • 業務改善所需的三大「核心素養」

    業務改善所需的三大「核心素養」

    業務改善的主導者:「流程所有者」必備的三大素養

    本文目錄

    1.誰應該推動「業務改善」?

    「什麼樣的人適合擔任改善負責人?」

    關於業務改善負責人的畫像,我們經常被問到此類問題。在本篇部落格中,我想(認真地!!)探討一下改善負責人應當具備的「素養」

    2.什麼是【業務】?

    首先,「業務」這個詞語的含義其實非常廣泛。

    在討論「業務改善」之前,我們必須對這裡使用的【業務】一詞進行更準確的定義。

    2-1. 搜尋「業務」這個詞

    所謂的業務是……

    • 「關於職業或事業,持續進行的工作」(詞典定義)
    • 「日常持續進行的職業性工作」
    • 「作為職業而從事的工作」(維基詞典)
    • 「將輸入轉化為輸出的活動」(某專業網站)

    嗯……總覺得不夠直觀。嘗試查閱各種資料,但那些以「業務是指……」開頭的解釋大多晦澀難懂。(真是令人頭大)

    雖然我深耕「業務流程管理」這一領域已超過五年,但結論是:想要直接定義「業務」幾乎是不可能的。在這裡,大家只需要理解為「這是一種很難用一句話概括的東西」即可。

    2-2. 「工作」與「業務」的詞義對比

    不過,透過對比,我們可以逐漸理解它的真意。(這種方式出乎意料地有趣)

    請試著對比以下兩種表達(閉上眼,默念幾遍):

    • a1. 「推進一項工作」
    • a2. 「把業務推動起來」

    原來如此。這兩者在語感上有微妙的區別。「業務改善」中的【業務】更偏向 a2。看來我們要改善的不是「某一次工作的做法」,而是「反覆進行的做法」。

    再看這個……

    • b1. 「委託一項工作」
    • b2. 「委託一項業務」

    明白了。相比「工作」,「業務」給人一種更強的「重複性」印象。

    最後再來一組……

    • c1. 「工作承包」
    • c2. 「業務外包」

    沒錯,這裡的 c2 就是我們常說的「業務外包契約」,或者是「外包」、「整體託付」。也就是說,這並不是一種「交付一個成果就結束」的委託,而是一套持續運作的職能。

    2-3. 列舉帶有「業務」的常用詞彙

    按同樣的邏輯,請嘗試列舉 10 個左右的相關詞彙。

    業務承接、業務委託、業務審計、業務改善指令、業務流程……有人可能會聯想到「品質的波動」,有人則會想到「交付週期的波動」。【業務】是一個與 ISO 或 QCD(品質、成本、交付)密不可分的詞彙。

    ……綜上所述,如果要強行用一句話來定義,業務就是「重複性的工作」!

    3.必備的素養

    雖然列舉起來沒完沒了,但如果要將「業務改善所需的素養」濃縮為三點,我認為是:

    3-1. 需要業務「知識」

    「真相就在現場!」(致敬經典台詞)

    反覆發生的事情,只有身處現場的人最清楚。這聽起來是理所當然的事。但現實中經常上演這樣的戲碼:公司為了改善業務開發系統,外包了半年後,卻抱怨說「那家系統公司根本不懂業務!」……其實,外包公司確實不可能完全了解。

    •  上線後還要反覆修改需求?不行!太燒錢了!
    •  要把設計圖畫得天衣無縫?不可能!根本寫不完!
    •  那乾脆放棄電子化?不,這絕對不行!

    雖然業務系統開發的「內製化 / 自行開發」對企業來說是一個需要勇氣的決定,但真正擁有業務知識的人只在公司內部,這是不爭的事實。

    3-2. 需要改善的「魄力」

    「咱們把辦公室弄得更順手一點吧!」「好主意!」
    「欸,那個誰,你來負責調整座位佈局!」「(額……不要吧,太麻煩了……)」

    這並不是因為教育沒跟上。事實上,絕大多數人天生對主導變革感到抵觸。這種事在正常心態下很難推動。

    特別是要改變業務流程,需要一種「正義感」,或者說「理性的洞察力」。在我視之,這些其實都包含在「幹勁」裡。是想要改變的「初衷」,更是「魄力 / 執行力」。(當然,前提是具備 3-1 提到的業務知識)

    3-3. 需要周圍的「支持」

    「哇,這個配置調得好不合理啊……」
    「哎,這桌子放那邊不是更好嗎?」

    變革必然伴隨閒言閒語。倒不是說說話的人有惡意,只是人們往往習慣先否定,而不是先感謝。「喂,我的位置怎麼跑這來了!」「搞什麼,業務不挨著財務怎麼行!」——變革會產生各種投訴。每個人都會試圖守護自己的利益,或者哀嘆原本平衡的「局部最佳化」被打破。

    說到底,一旦你改變業務流,各方「要求改回去」的壓力就會接踵而至。即使你事先公示了方案並詳細解釋過,結果可能也差不多。但你不能被這些阻力擊倒。記住,你是從「全局最佳化」的視角進行的改善。……不過話雖如此,一個人頂著壓力確實容易崩潰。

    因此,負責人必須是一個獲得周圍支持的人。必須達到一種「既然是那個人說的,那我们就先按這個試試看吧」的效果。換句話說,就是「領導力」。(狐假虎威或許一時有效,但難以持久)

    4.總結

    業務改善最核心的三個素養是:『1. 業務知識』、『2. 魄力』和『3. 周圍的支持』。

    為了讓大家能牢記,我建議用一個諧音記憶法:

    • 【知】知識、【魄】魄力、【支】支持
    • ⇒【知】知識、【支】支持、【魄】魄力

    作為基礎的「知識」固然重要,但集齊這三者並保持平衡的「智、支、志(魄)」才是關鍵。

    想要業務改善獲得成功,首先要在組織中找到 『那個最懂業務、最有威望的人』,然後大家一起去拜託他吧!

  • 业务改善所需的三个“能力储备”

    业务改善所需的三个“能力储备”

    业务流程优化的主导者:“流程所有者”必备的三大素质

    本文目录

    1.谁应该推动“业务流程优化”?

    “什么样的人适合担任改善负责人?”

    关于业务流程优化负责人的画像,我们经常被问到此类问题。在本篇博客中,我想(认真地!!)探讨一下改善负责人应当具备的“素质”

    2.什么是【业务】?

    首先,“业务”这个词语的含义其实非常广泛。

    在讨论“业务流程优化”之前,我们必须对这里使用的【业务】一词进行更准确的定义。

    2-1. 搜索“业务”这个词

    所谓的业务是……

    • “关于职业或事业,持续进行的工作”(词典定义)
    • “日常持续进行的职业性工作”
    • “作为职业而从事的工作”(维基词典)
    • “将输入转化为输出的活动”(某专业网站)

    嗯……总觉得不够直观。尝试查阅各种资料,但那些以“业务是指……”开头的解释大多晦涩难懂。(真是令人头大)

    虽然我深耕“业务流程管理”这一领域已超过五年,但结论是:想要直接定义“业务”几乎是不可能的。在这里,大家只需要理解为“这是一种很难用一句话概括的东西”即可。

    2-2. “工作”与“业务”的词义对比

    不过,通过对比,我们可以逐渐理解它的真意。(这种方式出乎意料地有趣)

    请试着对比以下两种表达(闭上眼,默念几遍):

    • a1. “把工作运转起来”
    • a2. “把业务运转起来”

    原来如此。这两者在语感上有微妙的区别。“业务流程优化”中的【业务】更偏向 a2。看来我们要改善的不是“某一次工作的做法”,而是“反复进行的标准化路径”。

    再看这个……

    • b1. “委托一项工作”
    • b2. “委托一项业务”

    明白了。相比“工作”,“业务”给人一种更强的“重复性”印象。

    最后再来一组……

    • c1. “工作承包”
    • c2. “业务外包”

    没错,这里的 c2 就是我们常说的“业务外包契约”,或者是“外包”、“整体托付”。也就是说,这并不是一种“交付一个成果就结束”的委托,而是一套持续运作的职能。

    2-3. 列举带有“业务”的常用词汇

    按同样的逻辑,请尝试列举 10 个左右的相关词汇。

    业务承接、业务委托、业务审计、业务流程优化指令、业务流程……有人可能会联想到“质量的波动”,有人则会想到“交付周期的波动”。【业务】是一个与 ISO 或 QCD(质量、成本、交付)密不可分的词汇。

    ……综上所述,如果要强行用一句话来定义,业务就是“重复性的工作”!

    3.必备的素质

    虽然列举起来没完没了,但如果要将“业务流程优化所需的素质”浓缩为三点,我认为是:

    3-1. 需要业务“知识”

    “真相就在现场!”(致敬经典台词)

    反复发生的事情,只有身处现场的人最清楚。这听起来是理所当然的事。但现实中经常上演这样的剧码:公司为了改善业务开发系统,外包了半年后,却抱怨说“那家系统公司根本不懂业务!”……其实,外包公司确实不可能完全了解。

    •  上线后还要反复修改需求?不行!太烧钱了!
    •  要把设计图画得天衣无缝?不可能!根本写不完!
    •  那干脆放弃数字化?不,这绝对不行!

    虽然业务系统开发的“全自研/内部开发”对企业来说是一个需要勇气的决定,但真正拥有业务知识的人只在公司内部,这是不争的事实。

    3-2. 需要改善的“魄力”

    “咱们把办公室弄得更顺手一点吧!”“好主意!”
    “那谁,你来负责调整工位布局!”“(额……不要吧,太麻烦了……)”

    这并不是因为素质教育没跟上。事实上,绝大多数人天生对主导变革感到抵触。这种事在正常心态下很难推动。

    特别是要改变业务流程,需要一种“正义感”,或者说“理性的洞察力”。在我看来,这些其实都包含在“干劲”里。是想要改变的“初衷”,更是“魄力/气势”。(当然,前提是具备 3-1 提到的业务知识)

    3-3. 需要周围的“支持”

    “哇,这个位置调得好没品位啊……”
    “哎,这桌子放那边不是更好吗?”

    变革必然伴随闲言碎语。倒不是说说话的人有恶意,只是人们往往习惯先否定,而不是先感谢。“喂,我的位置怎么跑这来了!”“搞什么,销售不挨着财务怎么行!”——变革会产生各种投诉。每个人都会试图守护自己的利益,或者哀叹原本平衡的“局部最优”被打破。

    说到底,一旦你改变业务流,各方“要求改回去”的压力就会接踵而至。即使你事先公示了方案并详细解释过,结果可能也差不多。但你不能被这些阻力击倒。记住,你是从“全局最优”的视角进行的改善。……不过话虽如此,一个人顶着压力确实容易崩溃。

    因此,负责人必须是一个获得周围支持的人。必须达到一种“既然是那个人说的,那我们就先按这个试试看吧”的效果。换句话说,就是“领导力”。(狐假虎威或许一时有效,但难以持久)

    4.总结

    业务流程优化最核心的三个素质是:『1. 业务知识』、『2. 魄力』和『3. 周围的支持』。

    为了让大家能牢记,我建议用一个谐音记忆法:

    • 【知】知识、【魄】魄力、【支】支持
    • ⇒【知】知识、【支】支持、【魄】魄力

    作为基础的“知识”固然重要,但集齐这三者并保持平衡的“智、支、志(魄)”才是关键。

    想要业务改善获得成功,首先要在组织中找到 『那个最懂业务、最有威望的人』,然后大家一起去拜托他吧!

  • 工作流與 BPM 的七個差異

    工作流與 BPM 的七個差異

    1. BPM 的概念

    「工作流」和 「BPM」。要比較這兩個詞,首先需要分別明確各自的「定義」。這裡我們來探討一下 「Business Process Management」(BPM) 的定義。

    1-1. 將業務流程逐步推向「最佳化」的活動

    在 IT 產業中具有巨大影響力的美國高德納(Gartner)公司所給出的定義,可以說是必須要掌握的。〔Gartner, Inc:IT 諮詢公司,Wikipedia /

    Gartner 術語集《Business Process Management(BPM)》

    【作者意譯】業務流程管理(BPM)是「普遍的行為規範」(Discipline)之一。也就是說,它透過運用各種手段來對業務流程進行「發現」「建模」「分析」「測量」「改進」,並最終實現「最佳化」。所謂「業務流程」,是為了取得符合業務策略的成果,而對人員、系統、資訊與實物的行為進行協調與控制。不過需要注意的是,業務流程不僅包括「步驟明確、可以反覆執行的流程」,也包括「持續發生變化的流程」。此外,在這種管理活動中(雖然並非絕對必要),多數情況下會藉助電腦技術(Technologies)。因此,業務流程管理活動也會對「資訊通訊方面的投資」(IT 投資)以及「機器控制方面的投資」(OT 投資)起到指引方向的作用。

    【引用原文】 Business process management (BPM) is a discipline that uses various methods to discover, model, analyze, measure, improve and optimize business processes. A business process coordinates the behavior of people, systems, information and things to produce business outcomes in support of a business strategy. Processes can be structured and repeatable, or unstructured and variable. Though not required, technologies are often used with BPM. BPM is key to align IT/OT investments to business strategy.

    需要牢牢掌握的一點(也就是非常重要的一點)是:

    這一點。

    【作者吐槽】「BPM is a discipline.」 這句話中的 “discipline” 很難翻譯。本文中我刻意將其譯為「行為規範」。詞典裡也有諸如「群體的紀律」「組織內部的統制」「基督教的法規」「學問領域」等譯法,但我覺得都不太貼切。另外,我也經常看到被翻譯成「BPM 是一個學科領域」的情況。不過,這種日語譯法在我看來已經不只是「不順」,而是接近「誤譯」。從原義或哲學層面來看〔例如米歇爾·傅柯所說的 “discipline”,參見 Wikipedia En〕,它本應帶有一種更強烈的「來自權威的教導」的語感。因此,我認為將其譯為「教義」「行動指標」「行為規範」等,會更加恰當。

    1-2. 從「定義」業務流程開始的活動

    我們已經明白,「BPM」是一種「行為規範」,是用來指代在部門內部或全公司範圍內推進的各類「舉措/活動」的詞語。那麼,這樣的「舉措」究竟是如何被實踐的呢?

    在企業中推進各種「舉措」時,多數情況下都會設定指標和目標。在業務流程的管理活動中,也經常會參考「組織的成熟度」。雖然會因實際推進的公司不同,或支援的顧問公司不同而有所差異,但基本上都會參考由「第 1 階段到第 5 階段」構成的五個階段。(有時也會假設「尚不存在管理對象的狀態」,而額外設置「第 0 階段」。)

    作者本人認為,若用中文來表達,大致採用「0:混沌」「1:定義」「2:統制」「3:治理」「4:控制」「5:順應」這樣的表述會比較貼切。

    Gartner 的 BPM 標準(6 個階段)

    Gartner 研究報告:BPM 成熟度模型識別出成功採用 BPM 的六個階段

    • 階段 0: 認識到營運中的低效率
    • 階段 1: 建立流程意識
    • 階段 2: 建立流程內部的自動化與控制
    • 階段 3: 建立跨流程的自動化與控制
    • 階段 4: 建立企業級價值評估與控制
    • 階段 5: 建構敏捷型業務結構

    另外,與其他管理活動(如 QMS、EMS、ISMS 等)不同,「業務流程管理」並沒有對應的國際標準(ISO)。這是因為「業務流程」這一概念本身就包含了諸如「品質管理流程」「環境評估流程」等多種流程,其涵蓋範圍過於廣泛。

    與成熟度相關的標準規範

    • QMS:Quality Management System(品質管理體系)
      • 用於管理製造產品及所提供服務的品質。於 1987 年實現國際標準化(ISO9000)。
      • 品質管理系統〔Wikipedia /
    • EMS:Environmental Management System(環境管理體系)
      • 用於管理為實現環境目標而開展的各項舉措。於 1996 年實現國際標準化(ISO14000)。
      • 環境管理體系〔Wikipedia
    • ISMS:Information Security Management System(資訊安全管理體系)
      • 用於管理資訊資產的安全。於 2000 年實現國際標準化(ISO/IEC 27000)。
      • 資訊安全管理體系〔Wikipedia /
    • PMS:Personal Information Protection Management(個人資訊保護管理體系)
      • 用於管理個人資訊保護相關的各項活動。日本工業標準(JIS Q 15001)。
      • 個人資訊保護管理體系〔Wikipedia

    1-3. BPM 活動的歷史

    那麼,順便一問,「業務流程管理活動」(BPM 活動)大約是從什麼時候開始被實踐起來的呢?

    在 IT 產業和顧問行業中,一種被廣泛支持的觀點認為:BPM 的理論基礎可以追溯到 F·泰勒在約 1910 年提出的《科學管理法》。也就是說,泰勒在其「勞動者管理的方法論」中,主張諸如「工具與作業步驟的標準化」「標準作業時間的設定」等理念。即便在一百多年後的今天,它依然作為一種「分析並協調組織內部工作流的管理理論」而廣為人知〔科學管理法:Wikipedia /〕。
    並且,據稱這種「對流程進行管理」的思想,又被繼承並發展到 20 世紀 60 年代的「改善活動」(品質管理方法論)、20 世紀 80 年代的 “CMMI”(軟體開發方法論),以及 20 世紀 90 年代的 “COBIT”(IT 治理方法論)等之中。

    這裡最重要的是:

    這個點。

    仔細想想,「想要管理流程」這一表述本身就是一個極其普通的說法。我認為,它是一種建立在悠久歷史之上、一直延續至今的「普遍的行為規範」。
    而「業務流程管理(BPM)」這一詞語本身,則是在進入 2000 年代之後才逐漸受到關注,其契機正是 Gartner 公司提出了“Business Process Management Suite(BPMS)”這一新造詞。

    【作者吐槽】
    我一直以來都有這樣的想法:「對業務流程進行管理」這一行為,對高度社會化的人類來說,其實是一種極其自然的欲求。說得極端一點,甚至會讓人覺得——「所謂『業務流程管理的故事』,不就是『人類的歷史』本身嗎?」比如說,當豐臣秀吉下令對全國農耕地進行測量時,我認為當時應該已經存在流程的概念了。像「測量步驟」「角色分工」「報告格式」之類的內容,似乎都已經被定義(也就是被管理)過了。
    〔不過我也不太確定〕

    1-4. 那麼,「BPMS」這個詞真的有必要嗎?

    關於「Business Process Management Suite(BPMS)」這一術語,我們也有必要先確認一下美國 Gartner 公司給出的定義。

    Gartner 術語集《Business Process Management Suites(BPMSs)》

    【作者意譯】業務流程管理套件(BPMS)是用於推進 BPM 專案與 BPM 策略的應用基礎平台。也就是說,它支持流程改進的整個生命週期。具體而言,不僅涵蓋流程發現、流程定義、流程設計,還支持實現、監控、分析以及持續性的最佳化等所有改進活動。與一般性的解決方案(如資訊系統等)不同,BPMS 通過模型驅動的方法,使業務人員與 IT 人員能夠協同合作,從而持續推動業務流程的演進。

    【引用原文】 Business process management suites (BPMSs) are the leading application infrastructures to support BPM projects and programs. A BPMS supports the entire process improvement life cycle – from process discovery, definition and design to implementation, monitoring and analysis, and through ongoing optimization. Its model-driven approach enables business and IT professionals to work together more collaboratively throughout the life cycle than is possible with other approaches to solution delivery.

    我認為,之所以需要重新提出 BPMS 這個詞,歸根結底是因為想把一種新的技術趨勢——「模型驅動的方法(Model-Driven Approach)」推廣給社會大眾
    關於其詳細內容,我希望能在後續章節中逐步進行說明,而在這裡,先請關注

    以下這一點即可。

    【作者吐槽】
    “Suite” 的意思是「一整套」。酒店的「套房(Suite Room)」裡配備了「各種不同的房間」。打包軟體中的「Office 套件(Office Suite)」裡,則集合了 Word、PowerPoint 等「各種不同的軟體」。順帶一提,「Suite」和「Sweet(甜的)」發音相同;但西裝(Suit)、泳衣(Swimsuit)以及高達(Mobile Suit)中的 “Suit(s)” 發音卻不一樣。〔完全無關緊要〕

    1-5. 各種各樣的 BPM 定義

    那麼,除 Gartner 之外的其他組織是如何定義業務流程管理(BPM)的呢?總體來看,其定義和表述大多都接近 Gartner 的觀點——也就是 “BPM 並不一定是用來指代 IT 工具的術語”。

    另一方面,也存在將 BPM 定義為「IT 工具」的情況,因此需要特別注意。(例如:國際標準規範《BPMN 2.0》的術語表)

    Business Process Model and Notation (BPMN), Glossary informative

    【作者意譯】業務流程管理:是用於支持流程管理(例如流程的分析、定義、處理、監控、管理等)的服務和工具其中也包括對人與應用程序層級交互的支持。BPM 工具能夠減少人工流程,並對部門與應用程序之間的請求流轉路徑進行自動化控制。

    【引用原文】 Business Process Management: The services and tools that support process management (for example, process analysis, definition, processing, monitoring and administration), including support for human and application-level interaction. BPM tools can eliminate manual processes and automate the routing of requests between departments and applications.

    也就是說你只需要理解,

    就可以了。

    2. 工作流的定義

    在本章中,我們將一邊與 “BPM” 進行比較,一邊把重點放在「工作流」這一術語上。

    2-1. 業務流程管理是在工作流管理的延伸線上

    在工作流研究領域享有盛名的阿爾斯特教授(尤其以 2000 年代的「工作流模式研究」和 2010 年代的「流程探勘研究」而聞名)〔Win van der Aalst,Wikipedia 〕,在其論文《BPM 的發展動向調查》(2003)開頭中這樣寫道。

    《BPM 的發展動向調查》 / “Business Process Management: A Survey”(2003 年)(快取 PDF)

    【作者意譯】業務流程管理(BPM)可以被認為是傳統工作流管理(WFM)系統與相關實踐的延伸。(省略)許多人認為,業務流程管理(BPM)是繼 1990 年代工作流浪潮之後的「下一步」。(省略)儘管 BPM 的定義多種多樣,但在絕大多數情況下,其中都明確地包含了工作流管理(WFM)。

    It can be considered as an extension of classical Workflow Management (WFM) systems and approaches. … Many people consider Business Process Management (BPM) to be the “next step” after the workflow wave of the nineties… There exist many definitions of BPM but in most cases it clearly includes Workflow Management (WFM).

    並且,在其十年後的論文《BPM 的廣範圍發展動向調查》(2013)中,也給出了同樣的說明。

    《BPM 的廣範圍發展動向調查》 / “Business Process Management: A Comprehensive Survey”(2013 年)(快取 PDF)

    【作者意譯】
    BPM 可以被認為是工作流管理(WFM:Workflow Management)的延伸。WFM 主要聚焦於業務流程的自動化,而 BPM 則具有更為廣泛的範圍。也就是說,BPM 不僅涵蓋流程自動化和流程分析,還包括進度管理以及作業體制的構建等內容。(省略)傳統的工作流管理(WFM)以對業務流程進行機械式自動化為主要目標,對於流程中存在人類參與這一事實,以及對管理活動的支援,並未給予太多關注。

    BPM can be seen as an extension of Workflow Management (WFM). WFM primarily focuses on the automation of business processes, whereas BPM has a broader scope: from process automation and process analysis to operations management and the organization of work… Traditional WFM technology aimed at the automation of business processes in a rather mechanistic manner without much attention for human factors and management support.

    我認為,即使到了 2020 年代,這些觀點在 IT 產業中依然構成了基本的思維方式。也就是說,

    這樣的認識已經深入人心。

    【作者吐槽】在教授的論文 “Business Process Management: A Survey” 中,BPM 的定義是從工作流研究者特有的視角來闡述的(例如圖論應用研究、形式語言應用研究等)。其中一個很有意思的點在於,他明確否定了「看不見的流程」。文中指出:「在我們的 BPM 定義中,僅限於可操作的作業流程(operational processes)。也就是說,戰略流程或無法被明確描述的流程將被排除在外。請注意,流程必須處於被認知、被識別的狀態。若沒有關於作業流程的信息,是無法提供任何支援的。」〔←嗯,這種想法我能理解〕

    2-2. 工作流技術是 BPMS 的一個組成要素

    Gartner 公司也在《BPMS 產品選型標準》(2009 年)以及《iBPMS 產品選型標準》(2011 年)中提到過:

    【作者意譯】BPMS 包含 10 個功能領域,而工作流技術不過只是其中的一個部分而已。

    這樣一個內容。

    雖然這並非官方文件,但在 2010 年的一篇博客《你真的明白工作流和 BPM 的區別嗎?》中,也曾有人強烈主張「這兩者完全不一樣!」。(來自研究部門的觀點)

    Do You Understand the Difference Between Workflow and BPM?

    【作者意譯】BPMS 中搭載的是工作流的「進化形態」。說得更直白一些,工作流不過只是 BPMS 所包含的 10 項技術之一而已。

    Thus, a BPMS includes a more advanced form of workflow. Furthermore, workflow is just 1 of 10 technologies found in a BPM Suite.

    不愧是調查研究公司,這樣的主張非常具有邏輯性。並且,他們將這一組件(部件)稱為「流程編排引擎」(Process Orchestration Engine)。在此之前也曾使用過「工作流引擎(Workflow Engine)」這樣的稱呼,但也許在命名層面上,同樣有必要從「工作流」這一說法中「畢業」了。(參見:Workflow Reference Model)

    【作者吐槽】
    比如說,當(對智能手機並不了解的年長者)問你「功能機和智能手機有什麼區別?」時,你會怎麼回答呢?恐怕一時會不知從何說起吧。即便解釋「可以用應用程序!」或「觸摸屏操作、沒有實體按鍵!」,對方也未必能真正理解。也許只能簡單地說一句「能做很多事情!」,然後直接演示給他看。不過,我認為一開始先告訴對方「智能手機(幾乎)具備功能機的全部功能」這一點非常重要。接下來,關鍵就在於如何讓對方切身感受到這種「多功能」所帶來的優點與缺點。

    • ▼BPMS 產品選型標準 2009▼(本次調研列舉了在選擇 BPMS 產品時需要考慮的功能,共計 10 個核心組件)
    • ▼iBPMS 產品選型標準▼本次調研將探討在選擇 iBPMS 產品時需要考慮的各項功能。
      • 流程編排引擎功能用於將案件推進到下一個流程環節。
      • 模型驅動的開發環境用於支持流程設計以及流程內部各工序的設計。
      • 在各個流程環節中所需要的各類文檔都可以被查閱並保存。
      • 人員可以自然地進行確認和輸入操作。
      • 將各個案件與合適的資源(例如人員或機器等)進行關聯。
      • 可以通過現狀監控功能,對工序名稱、進度以及變化情況等進行分析。
      • 可以隨時對流程的實際績效進行測量,或者進行預測。
      • 通過業務規則管理功能,實現流程的快速開發。
      • 通過系統管理功能,可以掌握 iBPMS 系統的運行狀況。
      • 處理組件的存儲功能可以提高組件的複用性。
    • Selection Criteria Details for Business Process Management Suites, 2009 (This research lists a universe of features to consider when selecting a BPMS. The 10 BPMS Core Components)
      • Process Execution and State Management Engine
      • Model-Driven Composition Environment
      • Document and Content Interaction
      • User and Group Interaction
      • Basic Connectivity
      • BAM and Business Event Support
      • Simulation and Optimization
      • Business Rule Management
      • Management and Administration
      • Process Component Registry/Repository
    • Selection Criteria Details for Intelligent Business Process Management Suites (This research examines the key features to consider when evaluating an iBPMS.)
      • The Process Orchestration Engine Drives the Process From One Activity to Another
      • The Model-Driven Composition Environment Helps Design Processes and Their Supporting Activities
      • Content Interaction Management Supports the Content Needed to Complete Process Activities
      • Human Interaction Management Enables People to Interact Naturally With Processes
      • Connectivity Links Processes to the Resources They Control
      • Active Analytics Are Needed to Monitor Activity, Progress and Changes in Processes
      • On-Demand Analytics Are Needed to Measure and Project Process Outcomes
      • Business Rule Management Is Needed to Guide and Implement Process Agility
      • Management and Administration Features Help Monitor and Adjust the iBPMS
      • The Process Component Registry/Repository Provides Component Leverage and Reuse

    【作者吐槽】
    Gartner 公司對「支援 BPM 活動的產品」(BPM 產品)進行了更加細緻的分類。具體來說,他們按照三種類型進行研究和區分:「BPM 平台」 → 「BPMS」 → 「智能型 BPMS(Intelligent BPMS)」。如果說得直白一些,他們的主張可以理解為:「如果重視『預測未來的能力』,就應該充分運用智能型 BPMS。」〔← 對於規模較大的組織來說,這一點尤為重要。〕

    2-3. 那麼,「工作流自動化(Workflow Automation)」到底是什麼?

    那麼,進入 2020 年代後,我們越來越頻繁聽到的「工作流自動化(Workflow Automation)」究竟指的是什麼呢?雖然也能見到將其直譯為「工作流的自動化」這樣的說法,但我並不認為這種直譯在中文語境中真正傳達了其含義。

    順便一提,在 Gartner 公司的術語集中並不存在 “Workflow Automation” 這一術語。Gartner 公司反而更傾向於推動 “iPaaS”(Integration Platform as a Service,整合平台即服務)。〔至於 “Workflow Automation” 和 “Robotic Process Automation(RPA)” 之間的區別,就留到以後再談吧……〕

    在日本,「工作流產品」這一說法往往給人一種「有人參與其中」的強烈印象,具體來說,多半是指諸如「申請審批流程」或「費用報銷流程」之類的場景。〔可以說是一種 “以人為中心的工作流(Human-Centric Workflow)”〕

    株式会社 Eightred 有價證券報告書

    工作流產品,是指將企業中涉及各類業務的事務流程——從審議、申請到審批、決定——進行電子化,以實現業務流程的效率提升與自動化,並強化內部操控等目的的一類產品的統稱。

    不過,如果回顧前面各節中關於「定義的歷史」,大致就能理解這裡的含義了:在「工作流自動化(Workflow Automation)」這一說法中所指的「工作流」,更多帶有一種「面向機器的(以系統整合為中心的,Integration-Centric)工作流」的語感。

    也就是說,如果一定要把當今的 “Workflow Automation” 翻譯成港澳台表達來理解的話,可以將其理解為「一連串處理的全自動化(或一連串作業的全自動化)」。它是在沒有人工介入的情況下執行的,從而能夠大幅提升定型作業的生產效率。

    (例如: IFTTT、 Zapier、 kissflow、 Pipefy、 Box Relay、 WorkFusion、 K2 Software、 等等)

    另外,我認為將專業術語逐一翻譯成繁體中文(進行本地化),最終往往會兜兜轉轉地引發混亂。基本上,還是應該按世界通用語原樣使用(並加以理解)比較合適。

    3. 作為 BPMS 特徵的「模型驅動」究竟是什麼?

    要讓一個「工作流系統」被稱為 “BPMS”,所必需的要素——「模型驅動」,究竟指的是什麼呢?

    3-1. 歸根結底,「模型(Model)」是什麼?

    從根本上來說,「模型(Model)」這個詞大致包含兩種含義:「模型(仿製品)」和「榜樣(典範)」。

    • 塑料模型:模仿出來的東西,並非實物本身。
    • 分子模型:模仿出來的東西,並非實物本身。
    • 角色模型(Role Model):作為理想對象的人,與自己並不相同。
    • 時尚模特兒等:作為理想形象的人,與自己並不相同。

    也就是說,作為 BPMS 特徵而使用的:

    我可以這樣理解為它雖然無法對對象進行完全的描寫,但可以說是對其具有代表性的關鍵要點進行了明確規定的東西。

    3-2. 什麼是流程模型?

    那麼,「將流程進行『模型化』」這一表述,是否僅僅指繪製流程圖呢?

    在當今的語境中,「流程模型」在概念上通常由以下三個要素來界定。

    • 業務流轉: 各個環節以怎樣的順序相互連接〔流程建模〕
    • 業務數據: 在流程中會傳遞哪些數據〔數據建模〕
    • 承接規則: 由誰來承接(個人、團隊中的某人、或機器等)〔資源建模〕

    也就是說,要將業務流程進行模式化,不僅需要業務流程圖(流程圖),還必須規定諸如「地址、姓名、電話號碼」等業務數據,以及像「鈴木先生」或「鈴木先生所屬部門的負責人」這樣的承接規則。

    【作者吐槽】作為一種表述,「流程圖」還有許多不同的叫法,比如:流程圖、流程示意圖、業務流轉圖、工作流圖、流程圖解(Flow Diagram)、流程圖表(Flowchart)、工程表等等。以我個人的看法,這些稱呼之間並不存在本質上的差異。(老實說,去細究它們之間的「區別」本身就有些徒勞……)另外,作為具體的標記與表示方法,BPMN(Business Process Model and Notation) 已經實現了國際標準化。

    3-3. 什麼是模型驅動?

    「模型驅動(Model-Driven)」常常被翻譯成「模型驅動型」這樣的說法,但說實話,這個譯法並不太讓人有直觀的感覺。

    從根本原因來說,是因為日語中並不存在一個能夠準確對應 “Drive / Driven” 的詞語。“Drive” 在原本的含義中帶有「賦予推動力、增強勢頭」的意思。在網球或足球中,也會使用「給球加上旋轉(打出驅動球)」之類的說法。因此,

    這樣理解就差不多了。

    具體來說,正如前一節所示,需要對「業務流程」「業務數據」「承接規則」進行建模。然後,系統將以該流程模型為基礎(由該模型驅動)進行實現(自動構建)。

    另外,傳統上,在完成「建模」(也可稱為「設計」)之後,主流的 BPMS 仍然需要由工程師進行「實現(Implementation)」。不過,近年來,No-Code 開發(無需程式碼的系統開發/軟體開發)逐漸成為一種趨勢。

    而在今天,也有不少組織開始傾向於使用這樣一種 BPMS:只要「流程模型」(也可稱為「工作流應用」)完成,就可以立即投入運行。(← Questetra BPM Suite!!)(← 不好意思,這是「立場發言」…)

    【作者吐槽】這只是我的個人看法,但我認為「數據驅動經營」(以數據分析為起點做出判斷的經營方式)並不適合被翻譯成「數據驅動型經營」。同樣地,像「事件驅動(Event-Driven,用用戶操作作為觸發點來啟動處理的程序)」,或者「截止期限驅動開發」(隨著截止日期臨近而被激活的開發風格)這樣的說法,即便帶點玩笑意味,也完全可以直接保留為 “Driven”。仔細想想,“USB Driver” 我們說的是「USB 驅動程序」,而不會說成「USB 激活軟體」。我認為在全世界使用相同的術語反而更有效率,這和 Tsunami(海嘯)、Emoji(表情符號)的傳播邏輯是一樣的。至於「大空翼」的「驅動射門(Drive Shot)」,我想那大概就是一顆「被極度強化的球」吧。〔不確定〕

    4. 歸根結底,Workflow 和 BPM 有什麼不同?

    每一種產品都有各自的特點。因此,要準確地說明「工作流產品」這一類別與「BPM 產品」這一類別之間的差異,並不是一件容易的事情。請理解,下面所提到的這些「差異」,只能從宏觀層面來進行說明。

    另外,正如前文在歷史考察中提到的那樣,BPM 產品(BPMS)能夠同時控制人類與機器(電腦)的行為。不過,其本質性的區別在於是否進行了「模型化」。也就是說,Workflow 與 BPM 的差異,歸根結底在於:是否存在流程模型,以及流程模型存在所帶來的優點與缺點。

    4-1. 業務流程的設置方式不同

    在 BPM 產品(BPMS)中,建模的核心是工作流圖(BPMN 圖)。

    這確實是一個極其重要的優勢,但同時也構成了一種劣勢。也就是說,「幾乎可以描述任何流程走向」的這一特性,直接導致了較高的學習與熟練成本。〔BPMN 「讀起來」並不難,但「畫起來」還是相當費力的。

    不過,改善活動本身是沒有終點的。

    • 根據不同案件條件改變流程路徑的設置
    • 在超時後自動推進到下一環節的設置
    • 在流程中途分流到多個環節的設置
    • 將既定的數據編輯操作自動化的設置
    • 自動調用子流程的設置
    • 與其他雲端服務(外部 API)進行自動通信的設置
    • 等等

    如果使用 BPM 產品(BPMS),就能夠實現各種各樣的流程走向(Control Pattern)以及各種形式的控制與編排(API Orchestration)。

    4-2. 承接規則的設置方式不同

    在 BPM 產品(BPMS)中,可以設置(從廣義上說也就是進行「建模」)較為複雜的「承接規則」。

    • 指定某一環節的處理負責人為 1 人(案件到達時即已完成分配)
    • 指定某一環節的處理負責人為多個人(由其中任意一人承接)
    • 以角色名稱來指定處理負責人(若對應多人,則由其中任意一人承接)
    • 設置為按順序輪流成為處理負責人(案件到達時即已完成分配)
    • 等等

    如果使用 BPM 產品(BPMS),就可以實現上述各種不同形式的工作分配方式。

    4-3. 共享業務流程的方式不同

    在 BPM 產品(BPMS)中,所有業務流程都會以圖形化的「工作流圖」(BPMN 圖)的形式進行創建。同時,建模的結果也可以作為「流程模型」進行保存。(例如在 Questetra BPM Suite 中,為 “.qar” 文件)

    這樣一來,流程負責人就能更容易地向他人說明本部門的業務流程;而管理層及相關部門也可以隨時查看當前的業務流程現狀。

    4-4. 可以查看流轉過來的案件的上游處理履歷

    在 BPM 產品(BPMS)中,不僅可以查看案件的「當前位置」,還可以在工作流圖(BPMN 圖)上確認其至今為止所經過的「路徑」。各個流程環節的處理負責人也可以根據需要,查看上游環節的處理人員。

    4-5. 可以監控當前正在流轉的所有案件

    在 BPM 產品(BPMS)中,可以在工作流圖(BPMN 圖)上查看所有正在處理中的案件的「當前位置」。例如,可以識別出容易發生滯留的流程環節,從而採取諸如「增加人員配置或引入自動化」等措施,或是「調整業務流程」等行動,將其與持續改善相結合。〔狀態監控〕

    4-6. 可以彙總統計所有已處理過的案件

    在 BPM 產品(BPMS)中,可以按案件負責人或案件流轉路徑來彙總統計實際績效數據。例如,可以實現按負責人生成績效報表的自動化。〔績效監控〕

    4-7. 可以在顆粒度層面上對累積的數據進行控制

    在 BPM 產品(BPMS)中,可以對業務數據的查看權限進行非常細緻的設置。這樣一來,案件處理人員就更容易進行「向同事或相關部門諮詢」,以及「從同事或相關部門獲取建議與回饋」。

    5. 結語

    BPM 活動的意義,正是在於持續不斷地進行改善(←「持續性的改善」)。即便是在看似微不足道的事務性流程之中,也隱藏著大量的「問題點」和「改進空間」。

    各位身處一線的流程負責人們,不僅要認真面對那些「已經看得見的業務流程」(也就是已經被模型化的業務流程),也要同樣認真地面對那些「尚未看得見的業務流程」(還沒有被模型化的業務流程)。讓我們一起,腳踏實地地把一個個小小的改善不斷累積起來吧。彼此共勉……

    PS:常見的誤解

    • 工作流系統是專門針對申請業務流程的系統,BPM 工具則面向受單系統、製造系統等更大規模的業務流程
    • 『工作流是為了快速、順暢地推進申請與審核業務的工具,而 BPM 則是對整體業務進行分析、解析問題點,並通過重組業務來推動效率提升的工具
    • 工作流系統主要由人工推動流程,而 BPM 工具除了人工處理之外,還會執行由業務應用系統完成的處理
    • 『如果想改善紙本流程,推薦使用工作流系統;而 BPM 系統功能豐富,但有些過於龐大……
  • 申請から承認・発注までを自動化し、購買業務を効率化。

    申請から承認・発注までを自動化し、購買業務を効率化。

    資材調達プロセス

    申請から承認・発注までを自動化し、購買業務を効率化。

    Questetra BPM Suite 導入前

    業務の流れが整理されていない

    申請・承認・発注・受領報告の手順が人により異なり、フローが統一されていない。

    業務の進捗が見えない

    どの申請が承認待ち/発注済みか不明。個別確認に時間を取られている。

    業務の変化に対応できない

    取引先別ルールや発注形式が変わるたび周知が必要。例外対応が増える。

    ワークフローイメージ

    申請→承認→発注→受領→経理連携までを可視化・統一化できる。

    各案件の状態が一覧化され、滞留や発注漏れをすぐ把握できる。

    取引先別ルートや自動メール工程も、設定変更で即日反映できる。

    プログラミングなしで、業務アプリの設計や処理の自動化が可能です。

    自動処理工程(計算・メール送信等)を配置でき、業務の生産性が高まります。

    業務プロセス、各案件の進捗、滞留ポイント、処理時間を可視化できます。

  • 工作流与 BPM 的七个区别

    工作流与 BPM 的七个区别

    1. BPM的概念

    “工作流”和 “BPM”。要比较这两个词,首先需要分别明确各自的“定义”。这里我们先来探讨一下 “Business Process Management”(BPM) 的定义。

    1-1. 将业务流程逐步推向“最优化”的活动

    在 IT 行业中具有巨大影响力的美国高德纳(Gartner)公司所给出的定义,可以说是必须要掌握的。〔Gartner, Inc:IT 咨询公司,Wikipedia /

    Gartner 用语集《Business Process Management(BPM)》

    【作者意译】业务流程管理(BPM)是“普遍的行为规范”(Discipline)之一。也就是说,它通过运用各种手段来对业务流程进行“发现”“建模”“分析”“测量”“改进”,并最终实现“最优化”。所谓“业务流程”,是为了取得符合业务战略的成果,而对人员、系统、信息与实物的行为进行协调与控制。不过需要注意的是,业务流程不仅包括“步骤明确、可以反复执行的流程”,也包括“持续发生变化的流程”。此外,在这种管理活动中(虽然并非绝对必要),多数情况下会借助计算机技术(Technologies)。因此,业务流程管理活动也会对“信息通信方面的投资”(IT 投资)以及“机器控制方面的投资”(OT 投资)起到指引方向的作用。

    【引用原文】 Business process management (BPM) is a discipline that uses various methods to discover, model, analyze, measure, improve and optimize business processes. A business process coordinates the behavior of people, systems, information and things to produce business outcomes in support of a business strategy. Processes can be structured and repeatable, or unstructured and variable. Though not required, technologies are often used with BPM. BPM is key to align IT/OT investments to business strategy.

    需要牢牢掌握的一点(也就是非常重要的一点)是:

    这一点。

    【作者吐槽】“BPM is a discipline.” 这句话中的 “discipline” 很难翻译。本文中我刻意将其译为“行为规范”。词典里也有诸如“群体的纪律”“组织内部的管控”“基督教的法规”“学问领域”等译法,但我觉得都不太贴切。另外,我也经常看到被翻译成“BPM 是一个学科领域”的情况。不过,这种日语译法在我看来已经不只是“不顺”,而是接近“误译”。从原义或哲学层面来看〔例如米歇尔·福柯所说的“discipline”,参见 Wikipedia En〕,它本应带有一种更强烈的“来自权威的教导”的语感。因此,我认为将其译为“教义”“行动指针”“行为规范”等,会更加恰当。

    1-2. 从“定义”业务流程开始的活动

    我们已经明白,“BPM”是一种“行为规范”,是用来指代在部门内部或全公司范围内推进的各类“举措/活动”的词语。那么,这样的“举措”究竟是如何被实践的呢?

    在企业中推进各种“举措”时,多数情况下都会设定指标和目标。在业务流程的管理活动中,也经常会参考“组织的成熟度”。虽然会因实际推进的公司不同,或支援的咨询公司不同而有所差异,但基本上都会参考由“第 1 阶段到第 5 阶段”构成的五个阶段。(有时也会假设“尚不存在管理对象的状态”,而额外设置“第 0 阶段”。)

    作者本人认为,若用中文来表达,大致采用「0:混沌」「1:定义」「2:管控」「3:治理」「4:控制」「5:顺应」这样的表述会比较贴切。

    Gartner 的 BPM 标准(6 个阶段)

    Gartner 研究报告:BPM 成熟度模型识别出成功采用 BPM 的六个阶段

    • 阶段 0: 认识到运营中的低效率
    • 阶段 1: 建立流程意识
    • 阶段 2: 建立流程内部的自动化与控制
    • 阶段 3: 建立跨流程的自动化与控制
    • 阶段 4: 建立企业级价值评估与控制
    • 阶段 5: 构建敏捷型业务结构

    另外,与其他管理活动(如 QMS、EMS、ISMS 等)不同,“业务流程管理”并没有对应的国际标准(ISO)。这是因为“业务流程”这一概念本身就包含了诸如“质量管理流程”“环境评估流程”等多种流程,其涵盖范围过于广泛。

    与成熟度相关的标准规范

    • QMS:Quality Management System(质量管理体系)
      • 用于管理制造产品及所提供服务的质量。于 1987 年实现国际标准化(ISO9000)。
      • 质量管理体系〔Wikipedia /
    • EMS:Environmental Management System(环境管理体系)
      • 用于管理为实现环境目标而开展的各项举措。于 1996 年实现国际标准化(ISO14000)。
      • 环境管理体系〔Wikipedia
    • ISMS:Information Security Management System(信息安全管理体系)
      • 用于管理信息资产的安全。于 2000 年实现国际标准化(ISO/IEC 27000)。
      • 信息安全管理体系〔Wikipedia /
    • PMS:Personal Information Protection Management(个人信息保护管理体系)
      • 用于管理个人信息保护相关的各项活动。日本工业标准(JIS Q 15001)。
      • 个人信息保护管理体系〔Wikipedia

    1-3. BPM 活动的历史

    那么,顺便一问,“业务流程管理活动”(BPM 活动)大约是从什么时候开始被实践起来的呢?

    在 IT 行业和咨询行业中,一种被广泛支持的观点认为:BPM 的理论基础可以追溯到 F·泰勒在约 1910 年提出的《科学管理法》。也就是说,泰勒在其“劳动者管理的方法论”中,主张诸如“工具与作业步骤的标准化”“标准作业时间的设定”等理念。即便在一百多年后的今天,它依然作为一种“分析并协调组织内部工作流的管理理论”而广为人知〔科学管理法:Wikipedia /〕。
    并且,据称这种“对流程进行管理”的思想,又被继承并发展到 20 世纪 60 年代的“改善活动”(质量管理方法论)、20 世纪 80 年代的 “CMMI”(软件开发方法论),以及 20 世纪 90 年代的 “COBIT”(IT 治理方法论)等之中。

    这里最重要的是:

    这个点。

    仔细想想,“想要管理流程”这一表述本身就是一个极为普通的说法。我认为,它是一种建立在悠久历史之上、一直延续至今的“普遍的行为规范”。
    而“业务流程管理(BPM)”这一词语本身,则是在进入 2000 年代之后才逐渐受到关注,其契机正是 Gartner 公司提出了“Business Process Management Suite(BPMS)”这一新造词。

    【作者吐槽】
    我一直以来都有这样的想法:“对业务流程进行管理”这一行为,对高度社会化的人类来说,其实是一种极其自然的欲求。说得极端一点,甚至会让人觉得——“所谓‘业务流程管理的历史’,不就是‘人类的历史’本身吗?”比如说,当丰臣秀吉下令对全国农耕地进行测量时,我认为当时应该已经存在流程的概念了。像“测量步骤”“角色分工”“报告格式”之类的内容,似乎都已经被定义(也就是被管理)过了。
    〔不过我也不太确定〕

    1-4. 那么,“BPMS”这个词真的有必要吗?

    关于“Business Process Management Suite(BPMS)”这一术语,我们也有必要先确认一下美国 Gartner 公司给出的定义。

    Gartner 用语集《Business Process Management Suites(BPMSs)》

    【作者意译】业务流程管理套件(BPMS)是用于推进 BPM 项目与 BPM 战略的应用基础平台。也就是说,它支持流程改进的整个生命周期。具体而言,不仅涵盖流程发现、流程定义、流程设计,还支持实现、监控、分析以及持续性的最优化等所有改进活动。与一般性的解决方案(如信息系统等)不同,BPMS 通过模型驱动的方法,使业务人员与 IT 人员能够协同合作,从而持续推动业务流程的演进。

    【引用原文】 Business process management suites (BPMSs) are the leading application infrastructures to support BPM projects and programs. A BPMS supports the entire process improvement life cycle – from process discovery, definition and design to implementation, monitoring and analysis, and through ongoing optimization. Its model-driven approach enables business and IT professionals to work together more collaboratively throughout the life cycle than is possible with other approaches to solution delivery.

    我认为,之所以需要重新提出 BPMS 这个词,归根结底是因为想把一种新的技术趋势——“模型驱动的方法(Model-Driven Approach)”推广给社会大众
    关于其详细内容,我希望能在后续章节中逐步进行说明,而在这里,先请关注

    以下这一点即可。

    【作者吐槽】
    “Suite” 的意思是“一整套”。酒店的“套房(Suite Room)”里配备了“各种不同的房间”。打包软件中的“Office 套件(Office Suite)”里,则集合了 Word、PowerPoint 等“各种不同的软件”。顺带一提,“Suite”和“Sweet(甜的)”的发音是相同的;但西装(Suit)、泳衣(Swimsuit)以及高达(Mobile Suit)中的 “Suit(s)” 发音却不一样。〔完全无关紧要〕

    1-5. 各种各样的 BPM 定义

    那么,除 Gartner 之外的其他组织是如何定义业务流程管理(BPM)的呢?总体来看,其定义和表述大多都接近 Gartner 的观点——也就是 “BPM 并不一定是用来指代 IT 工具的术语”。

    另一方面,也存在将 BPM 定义为“IT 工具”的情况,因此需要特别注意。(例如:国际标准规范《BPMN 2.0》的术语表)

    Business Process Model and Notation (BPMN), Glossary informative

    【作者意译】业务流程管理:是用于支持流程管理(例如流程的分析、定义、处理、监控、管理等)的服务和工具其中也包括对人与应用程序层级交互的支持。BPM 工具能够减少人工流程,并对部门与应用程序之间的请求流转路径进行自动化控制。

    【引用原文】 Business Process Management: The services and tools that support process management (for example, process analysis, definition, processing, monitoring and administration), including support for human and application-level interaction. BPM tools can eliminate manual processes and automate the routing of requests between departments and applications.

    也就是说你只需要理解,

    就可以了。

    2. 工作流的定义

    在本章中,我们将一边与 “BPM” 进行比较,一边把重点放在“工作流”这一术语上。

    2-1. 业务流程管理是在工作流管理的延伸线上

    在工作流研究领域享有盛名的阿尔斯特教授(尤其以 2000 年代的“工作流模式研究”和 2010 年代的“流程挖掘研究”而闻名)〔Win van der Aalst,Wikipedia 〕,在其论文《BPM 的发展动向调查》(2003)开头中这样写道。

    《BPM 的发展动向调查》 / “Business Process Management: A Survey”(2003 年)(缓存 PDF)

    【作者意译】业务流程管理(BPM)可以被认为是传统工作流管理(WFM)系统与相关实践的延伸。(省略)许多人认为,业务流程管理(BPM)是继 1990 年代工作流浪潮之后的“下一步”。(省略)尽管 BPM 的定义多种多样,但在绝大多数情况下,其中都明确地包含了工作流管理(WFM)。

    It can be considered as an extension of classical Workflow Management (WFM) systems and approaches. … Many people consider Business Process Management (BPM) to be the “next step” after the workflow wave of the nineties… There exist many definitions of BPM but in most cases it clearly includes Workflow Management (WFM).

    并且,在其十年后的论文《BPM 的广范围发展动向调查》(2013)中,也给出了同样的说明。

    《BPM 的广范围发展动向调查》 / “Business Process Management: A Comprehensive Survey”(2013 年)(缓存 PDF)

    【作者意译】
    BPM 可以被认为是工作流管理(WFM:Workflow Management)的延伸。WFM 主要聚焦于业务流程的自动化,而 BPM 则具有更为广泛的范围。也就是说,BPM 不仅涵盖流程自动化和流程分析,还包括进度管理以及作业体制的构建等内容。(省略)传统的工作流管理(WFM)以对业务流程进行机械式自动化为主要目标,对于流程中存在人类参与这一事实,以及对管理活动的支援,并未给予太多关注。

    BPM can be seen as an extension of Workflow Management (WFM). WFM primarily focuses on the automation of business processes, whereas BPM has a broader scope: from process automation and process analysis to operations management and the organization of work… Traditional WFM technology aimed at the automation of business processes in a rather mechanistic manner without much attention for human factors and management support.

    我认为,即使到了 2020 年代,这些观点在 IT 行业中依然构成了基本的思维方式。也就是说,

    这样的认识已经深入人心。

    【作者吐槽】在教授的论文 “Business Process Management: A Survey” 中,BPM 的定义是从工作流研究者特有的视角来阐述的(例如图论应用研究、形式语言应用研究等)。其中一个很有意思的点在于,他明确否定了“看不见的流程”。文中指出:“在我们的 BPM 定义中,仅限于可操作的作业流程(operational processes)。也就是说,战略流程或无法被明确描述的流程将被排除在外。请注意,流程必须处于被认知、被识别的状态。若没有关于作业流程的信息,是无法提供任何支援的。”〔←嗯,这种想法我能理解〕

    2-2. 工作流技术是 BPMS 的一个组成要素

    Gartner 公司也在《BPMS 产品选型标准》(2009 年)以及《iBPMS 产品选型标准》(2011 年)中提到过:

    【作者意译】BPMS 包含 10 个功能领域,而工作流技术不过只是其中的一个部分而已。

    这样一个内容。

    虽然这并非官方文件,但在 2010 年的一篇博客《你真的明白工作流和 BPM 的区别吗?》中,也曾有人强烈主张“这两者完全不一样!”。(来自研究部门的观点)

    Do You Understand the Difference Between Workflow and BPM?

    【作者意译】BPMS 中搭载的是工作流的“进化形态”。说得更直白一些,工作流不过只是 BPMS 所包含的 10 项技术之一而已。

    Thus, a BPMS includes a more advanced form of workflow. Furthermore, workflow is just 1 of 10 technologies found in a BPM Suite.

    不愧是调查研究公司,这样的主张非常具有逻辑性。并且,他们将这一组件(部件)称为“流程编排引擎”(Process Orchestration Engine)。在此之前也曾使用过“工作流引擎(Workflow Engine)”这样的称呼,但也许在命名层面上,同样有必要从“工作流”这一说法中“毕业”了。(参见:Workflow Reference Model)

    【作者吐槽】
    比如说,当(对智能手机并不了解的年长者)问你“功能机和智能手机有什么区别?”时,你会怎么回答呢?恐怕一时会不知从何说起吧。即便解释“可以用应用程序!”或“触摸屏操作、没有实体按键!”,对方也未必能真正理解。也许只能简单地说一句“能做很多事情!”,然后直接演示给他看。不过,我认为一开始先告诉对方“智能手机(几乎)具备功能机的全部功能”这一点非常重要。接下来,关键就在于如何让对方切身感受到这种“多功能”所带来的优点与缺点。

    • ▼BPMS 产品选型标准 2009▼(本次调研列举了在选择 BPMS 产品时需要考虑的功能,共计 10 个核心组件)
    • ▼iBPMS 产品选型标准▼本次调研将探讨在选择 iBPMS 产品时需要考虑的各项功能。
      • 流程编排引擎功能用于将任务推进到下一个流程环节。
      • 模型驱动的开发环境用于支持流程设计以及流程内部各工序的设计。
      • 在各个流程环节中所需要的各类文档都可以被查阅并保存。
      • 人员可以自然地进行确认和输入操作。
      • 将各个任务与合适的资源(例如人员或机器等)进行关联。
      • 可以通过现状监控功能,对工序名称、进度以及变化情况等进行分析。
      • 可以随时对流程的实际绩效进行测量,或者进行预测。
      • 通过业务规则管理功能,实现流程的快速开发。
      • 通过系统管理功能,可以掌握 iBPMS 系统的运行状况。
      • 处理组件的存储功能可以提高组件的复用性。
    • Selection Criteria Details for Business Process Management Suites, 2009 (This research lists a universe of features to consider when selecting a BPMS. The 10 BPMS Core Components)
      • Process Execution and State Management Engine
      • Model-Driven Composition Environment
      • Document and Content Interaction
      • User and Group Interaction
      • Basic Connectivity
      • BAM and Business Event Support
      • Simulation and Optimization
      • Business Rule Management
      • Management and Administration
      • Process Component Registry/Repository
    • Selection Criteria Details for Intelligent Business Process Management Suites (This research examines the key features to consider when evaluating an iBPMS.)
      • The Process Orchestration Engine Drives the Process From One Activity to Another
      • The Model-Driven Composition Environment Helps Design Processes and Their Supporting Activities
      • Content Interaction Management Supports the Content Needed to Complete Process Activities
      • Human Interaction Management Enables People to Interact Naturally With Processes
      • Connectivity Links Processes to the Resources They Control
      • Active Analytics Are Needed to Monitor Activity, Progress and Changes in Processes
      • On-Demand Analytics Are Needed to Measure and Project Process Outcomes
      • Business Rule Management Is Needed to Guide and Implement Process Agility
      • Management and Administration Features Help Monitor and Adjust the iBPMS
      • The Process Component Registry/Repository Provides Component Leverage and Reuse

    【作者吐槽】
    Gartner 公司对“支援 BPM 活动的产品”(BPM 产品)进行了更加细致的分类。具体来说,他们按照三种类型进行研究和区分:“BPM 平台” → “BPMS” → “智能型 BPMS(Intelligent BPMS)”。如果说得直白一些,他们的主张可以理解为:“如果重视‘预测未来的能力’,就应该充分运用智能型 BPMS。”〔← 对于规模较大的组织来说,这一点尤为重要。〕

    2-3. 那么,“工作流自动化(Workflow Automation)”到底是什么?

    那么,进入 2020 年代后,我们越来越频繁听到的“工作流自动化(Workflow Automation)”究竟指的是什么呢?虽然也能见到将其直译为“工作流的自动化”这样的说法,但我并不认为这种直译在日语语境中真正传达了其含义。

    顺便一提,在 Gartner 公司的用语集中并不存在“Workflow Automation”这一术语。Gartner 公司反而更倾向于推动 “iPaaS”(Integration Platform as a Service,集成平台即服务)。〔至于“Workflow Automation”和“Robotic Process Automation(RPA)”之间的区别,就留到以后再谈吧……〕

    在日本,“工作流产品”这一说法往往给人一种“有人参与其中”的强烈印象,具体来说,多半是指诸如“申请审批流程”或“费用报销流程”之类的场景。〔可以说是一种 “以人为中心的工作流(Human-Centric Workflow)”〕

    株式会社 Eightred 有价证券报告书

    工作流产品,是指将企业中涉及各类业务的事务流程——从审议、申请到审批、决定——进行电子化,以实现业务流程的效率提升与自动化,并强化内部操控等目的的一类产品的统称。

    不过,如果回顾前面各节中关于“定义的历史”,大致就能理解这里的含义了:在“工作流自动化(Workflow Automation)”这一说法中所指的“工作流”,更多带有一种“面向机器的(以系统集成为中心的,Integration-Centric)工作流”的语感。

    也就是说,如果一定要把当今的 “Workflow Automation” 翻译成日语式表达来理解的话,可以将其理解为“一连串处理的全自动化(或一连串作业的全自动化)”。它是在没有人工介入的情况下执行的,从而能够大幅提升定型作业的生产效率。

    (例如: IFTTT、 Zapier、 kissflow、 Pipefy、 Box Relay、 WorkFusion、 K2 Software、 等等)

    另外,我认为将专业术语逐一翻译成日语(进行本地化),最终往往会兜兜转转地引发混乱。基本上,还是应该按世界通用语原样使用(并加以理解)比较合适。

    3. 作为 BPMS 特征的“模型驱动”究竟是什么?

    要让一个“工作流系统”被称为“BPMS”,所必需的要素——“模型驱动”,究竟指的是什么呢?

    3-1. 归根结底,“模型(Model)”是什么?

    从根本上来说,“模型(Model)”这个词大致包含两种含义:“模型(仿制品)”和“榜样(典范)”。

    • 塑料模型:模仿出来的东西,并非实物本身。
    • 分子模型:模仿出来的东西,并非实物本身。
    • 角色模型(Role Model):作为理想对象的人,与自己并不相同。
    • 时尚模特等:作为理想形象的人,与自己并不相同。

    也就是说,作为 BPMS 特征而使用的:

    我可以这样理解为它虽然无法对对象进行完全的描写,但可以说是对其具有代表性的关键要点进行了明确规定的东西。

    3-2. 什么是流程模型?

    那么,“将流程进行‘模型化’”这一表述,是否仅仅指绘制流程图呢?

    在当今的语境中,“流程模型”在概念上通常由以下三个要素来界定。

    • 业务流转: 各个环节以怎样的顺序相互连接〔流程建模〕
    • 业务数据: 在流程中会传递哪些数据〔数据建模〕
    • 指派规则: 由谁来指派(个人、团队中的某人、或机器等)〔资源建模〕

    也就是说,要将业务流程进行模式化,不仅需要业务流程图(流程图),还必须规定诸如“地址、姓名、电话号码”等业务数据,以及像“铃木先生”或“铃木先生所属部门的负责人”这样的指派规则。

    【作者吐槽】作为一种表述,“流程图”还有许多不同的叫法,比如:流程图、流程示意图、业务流转图、工作流图、流程图解(Flow Diagram)、流程图表(Flowchart)、工程表等等。以我个人的看法,这些称呼之间并不存在本质上的差异。(老实说,去细究它们之间的“区别”本身就有些徒劳……)另外,作为具体的标记与表示方法,BPMN(Business Process Model and Notation) 已经实现了国际标准化。

    3-3. 什么是模型驱动?

    “模型驱动(Model-Driven)”常常被翻译成“模型驱动型”这样的说法,但说实话,这个译法并不太让人有直观的感觉。

    从根本原因来说,是因为日语中并不存在一个能够准确对应 “Drive / Driven” 的词语。“Drive” 在原本的含义中带有“赋予推动力、增强势头”的意思。在网球或足球中,也会使用“给球加上旋转(打出驱动球)”之类的说法。因此,

    这样理解就差不多了。

    具体来说,正如前一节所示,需要对“业务流程”“业务数据”“指派规则”进行建模。然后,系统将以该流程模型为基础(由该模型驱动)进行实现(自动构建)。

    另外,传统上,在完成“建模”(也可称为“设计”)之后,主流的 BPMS 仍然需要由程序员进行“实现(Implementation)”。不过,近年来,No-Code 开发(无需编程的系统开发/软件开发)逐渐成为一种趋势。

    而在今天,也有不少组织开始倾向于使用这样一种 BPMS:只要“流程模型”(也可称为“工作流应用”)完成,就可以立即投入运行。(← Questetra BPM Suite!!)(← 不好意思,这是“立场发言”…)

    【作者吐槽】这只是我的个人看法,但我认为“数据驱动经营”(以数据分析为起点做出判断的经营方式)并不适合被翻译成“数据驱动型经营”。同样地,像“事件驱动(Event-Driven,用用户操作作为触发点来启动处理的程序)”,或者“截止期限驱动开发”(随着截止日期临近而被激活的开发风格)这样的说法,即便带点玩笑意味,也完全可以直接保留为“Driven”。仔细想想,“USB Driver” 我们说的是“USB 驱动程序”,而不会说成“USB 激活软件”。我认为在全世界使用相同的术语反而更有效率,这和 Tsunami(海啸)、Emoji(表情符号)的传播逻辑是一样的。至于“大空翼”的“驱动射门(Drive Shot)”,我想那大概就是一颗“被极度强化的球”吧。〔不确定〕

    4. 归根结底,Workflow 和 BPM 有什么不同?

    每一种产品都有各自的特点。因此,要准确地说明“工作流产品”这一类别与“BPM 产品”这一类别之间的差异,并不是一件容易的事情。请理解,下面所提到的这些“差异”,只能从宏观层面来进行说明。

    另外,正如前文在历史考察中提到的那样,BPM 产品(BPMS)能够同时控制人类与机器(计算机)的行为。不过,其本质性的区别在于是否进行了“模型化”。也就是说,Workflow 与 BPM 的差异,归根结底在于:是否存在流程模型,以及流程模型存在所带来的优点与缺点。

    4-1. 业务流程的设置方式不同

    在 BPM 产品(BPMS)中,建模的核心是工作流图(BPMN 图)。

    这确实是一个极其重要的优势,但同时也构成了一种劣势。也就是说,“几乎可以描述任何流程走向”的这一特性,直接导致了较高的学习与熟练成本。〔BPMN “读起来”并不难,但“画起来”还是相当费力的。

    不过,改善活动本身是没有终点的。

    • 根据不同任务条件改变流程路径的设置
    • 在超时后自动推进到下一环节的设置
    • 在流程中途分流到多个环节的设置
    • 将既定的数据编辑操作自动化的设置
    • 自动调用子流程的设置
    • 与其他云服务(外部 API)进行自动通信的设置
    • 等等

    如果使用 BPM 产品(BPMS),就能够实现各种各样的流程走向(Control Pattern)以及各种形式的控制与编排(API Orchestration)。

    4-2. 指派规则的设置方式不同

    在 BPM 产品(BPMS)中,可以设置(从广义上说也就是进行“建模”)较为复杂的“指派规则”。

    • 指定某一环节的处理负责人为 1 人(任务到达时即已完成分配)
    • 指定某一环节的处理负责人为多个人(由其中任意一人指派)
    • 以角色名称来指定处理负责人(若对应多人,则由其中任意一人指派)
    • 设置为按顺序轮流成为处理负责人(任务到达时即已完成分配)
    • 等等

    如果使用 BPM 产品(BPMS),就可以实现上述各种不同形式的工作分配方式。

    4-3. 共享业务流程的方式不同

    在 BPM 产品(BPMS)中,所有业务流程都会以图形化的“工作流图”(BPMN 图)的形式进行创建。同时,建模的结果也可以作为“流程模型”进行保存。(例如在 Questetra BPM Suite 中,为“.qar”文件)

    这样一来,流程负责人就能更容易地向他人说明本部门的业务流程;而管理层及相关部门也可以随时查看当前的业务流程现状。

    4-4. 可以查看流转过来的任务的上游处理履历

    在 BPM 产品(BPMS)中,不仅可以查看任务的“当前位置”,还可以在工作流图(BPMN 图)上确认其至今为止所经过的“路径”。各个流程环节的处理负责人也可以根据需要,查看上游环节的处理人员。

    4-5. 可以监控当前正在流转的所有任务

    在 BPM 产品(BPMS)中,可以在工作流图(BPMN 图)上查看所有正在处理中的任务的“当前位置”。例如,可以识别出容易发生滞留的流程环节,从而采取诸如“增加人员配置或引入自动化”等措施,或是“调整业务流程”等行动,将其与持续改善相结合。〔状态监控〕

    4-6. 可以汇总统计所有已处理过的任务

    在 BPM 产品(BPMS)中,可以按任务负责人或任务流转路径来汇总统计实际绩效数据。例如,可以实现按负责人生成绩效报表的自动化。〔绩效监控〕

    4-7. 可以在颗粒度层面上对积累的数据进行控制

    在 BPM 产品(BPMS)中,可以对业务数据的查看权限进行非常细致的设置。这样一来,任务处理人员就更容易进行“向同事或相关部门咨询”,以及“从同事或相关部门获取建议与反馈”。

    5. 结语

    BPM 活动的意义,正是在于持续不断地进行改善(←“持续性的改善”)。即便是在看似微不足道的事务性流程之中,也隐藏着大量的“问题点”和“改进空间”。

    各位身处一线的流程负责人们,不仅要认真面对那些“已经看得见的业务流程”(也就是已经被模型化的业务流程),也要同样认真地面对那些“尚未看得见的业务流程”(还没有被模型化的业务流程)。让我们一起,脚踏实地地把一个个小小的改善不断累积起来吧。彼此共勉……

    PS:常见的误解

    • 工作流系统是专门针对申请业务流程的系统,BPM 工具则面向受单系统、制造系统等更大规模的业务流程
    • 『工作流是为了快速、顺畅地推进申请与审批业务的工具,而 BPM 则是对整体业务进行分析、解析问题点,并通过重组业务来推动效率提升的工具
    • 工作流系统主要由人工推动流程,而 BPM 工具除了人工处理之外,还会执行由业务应用系统完成的处理
    • 『如果想改善纸质流程,推荐使用工作流系统;而 BPM 系统功能丰富,但有些过于庞大……