目次 |
プロセス改善とは
企業活動は「複数のビジネスプロセスから成り立っている」と考える事が出来る。プロセス改善（ビジネスプロセス改善）とは、企業にとっての「あるべき姿」に近づける方向にビジネスプロセスを変更する活動である。BPI（Business Process Improvement）とも言われる。
ただし「あるべき姿の設定」は、合理的な説明が困難であるが故に組織意思決定が難しく、また加えて「あるべき姿を設定すべきタイミング」は、内部要因・外部要因により時事変化する性格を持つが故に決め難い。また「ビジネスプロセス」の変更を管理把握する方法も容易ではない。すなわち、ビジネスプロセスとは業務の進め方であり、そこにはルールや慣習だけでなく様々なノウハウが存在し、その全貌を記述する事は容易ではなく、単純化・形式化した何点かの図表等を用いて管理把握する事が多い。なお、図表等で単純化された定義全体を「プロセスモデル」、またその中で「業務の流れ」を定義した図を「業務フロー図」と呼ぶ。
「プロセス改善」は、既存の各ビジネスプロセスの改良だけでなく、ビジネスプロセスの新規追加、廃止、統合、分割などを含む。
プロセス改善の動機
プロセス改善の実施動機は様々に想定されるが、以下の２軸４通りに分類できるケースが多い。
- 合理的(演繹的)に導いた仮説検証
- トップダウン指示
- ボトムアップ改善
- 経験的(帰納的)に発見された課題解決
- トップダウン指示
- ボトムアップ改善
「仮説検証」とは、プロセスモデルの分析、シミュレーション、場合によっては想像により、予想された方針を実験しようとする動機である。対して「課題解決」とは、実際に不正・偽装・事故・生産量低下が発生した状況、あるいは発生しつつある状況を踏まえて、プロセス改善に取り組む動機である。
また「トップダウン指示」とは管理職からの指示に基づく動機であり、「ボトムアップ改善」とは従業員の自発的な活動と言える。
プロセス改善の手順
多くの場合、改善対象とするプロセス（もしくはプロセス群）に対し、現状と将来の２つを記述し、それらの差分を埋めるためのタスク・手順を列挙し実行する。
- 現状のビジネスプロセスを単純化・形式化したもの（「現状モデル」あるいは「As-Isモデル」と呼ばれる）
- 将来のビジネスプロセス、あるべきビジネスプロセスを単純化・形式化したもの（「理想モデル」あるいは「To-Beモデル」と呼ばれる）
多くは、業務処理手順を記述した「業務フロー図」（フローモデル）の差分をもとにタスク列挙されるが、「業務分掌表(担当表)」（組織モデル）や「業務データフォーマット」（データモデル）の差分にも配慮しなければならないケースは少なくない。現実問題として、列挙されるタスクの多くはコンセンサスを図る活動である事が多い。
なお、この様なプロセス改善の循環継続的な実施（PDCAサイクル）を「BPMサイクル」と呼ぶ場合がある。
プロセス改善の実施責任者
プロセス改善を実施推進する責任者は、経営者、部署責任者である事が多い。しかし、特にボトムアップ型の改善を推進する場合において、個々のプロセスにそれぞれの改善推進者を設定するケースもある。なお、個々のプロセスの改善責任者を「プロセスオーナー」と呼ぶ場合がある。
とあるプロセス変更が「改善とみなしうるかどうか」は、組織や組織の状況によって異なる。すなわち、とある組織にとって「改善」であっても、他の組織では「改悪」になるケースは少なくない。手法としては様々なパターンが想定できるが、情報システム（BPMSやERPなど）の支援が必須になるものも少なくない。プロセスオーナーには広い視野をもって判断する力が求められると言える。
プロセス改善のフレームワーク
受託生産型の事業や製品品質を重要視する事業においては、その生産プロセスの整備状況が事業の成否にかかわる。
例えば、ソフトウェア業界においては、ソフトウェア開発プロセス（情報システム開発プロセス）の改善能力に関して定量的に評価する試みが続けられている。委託側にしてみれば、委託先選定時の重要な資料となるケースが多い。（「CMMI（能力成熟度モデル統合）」と呼ばれる）
- CMMI
- ITIL
- Automotive SPICE
- ISO/IEC 15504
フローモデルレベルでの改善例
フローモデルレベルでの変更が多い場合に、プロセス担当者（「パーティシパント」と言う）全員が現状フローを把握し続ける事が困難になる。そのような場合には「ワークフローエンジン」による支援が望まれる。
なお、「重要タスクの実行時には、必ず作業監視者を置く」などのタスクレベルでの改善（あるいは業務ノウハウ）については触れない。
同時並列処理
「C1→C2→C3」の順に実施していた各タスクを、タスク「C1」終了後、タスク「C2」とタスク「C3」を同時並行に開始することで全体所要時間を短縮させる。
タスク追加
プロセスの最後（もしくは途中）に「レビュータスク」や「評価タスク」を追加する事で、プロセス成果物の品質向上を図る。（ループ化させる事も想定される）
条件分岐処理
「処理する案件」(「プロセスインスタンスと言う」)の内容によって処理経路を変える事で、業務負荷を削減させたり、あるいは滞留リスクを低減させたりする。より適した処理経路の選択を実現する場合にも使われる。
タスク削除
例えば、「あまり内容を閲覧しない押印タスク、確認タスク」など、プロセス中にある滞留リスクの高いタスクを削除する事で、業務負荷を削減させたり、あるいは滞留リスクを低減させたりする。
データモデルレベルでの改善例
データ追加
右図「契約報告プロセス」を想定した場合、プロセスを通じてアウトプットされる基本データは、以下の様なものが想定される。すなわち、例えば「L1:草稿確認」タスクにおいては、上流タスク「S1:草稿作成」で入力された情報がすべて表示され、そのインプットデータ(太字表記)をもとにアウトプットデータとしての「契約書草稿承認チェック」が入力される。
| データ名 | データ型 | データ条件 | S1 | L1 | S2 | L2 | A1 |
|---|---|---|---|---|---|---|---|
| 販売先法人名 | 文字 | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者名 | 文字 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者連絡先 | 電話番号 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者連絡先 | 住所 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約書 | ファイル | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約書草稿承認 | チェック | 必須 | - | 入力 | 表示 | 表示 | 表示 |
| 契約完了報告文 | 文字 | 任意 | - | - | 入力 | 表示 | 表示 |
データ追加例として「契約金額」を追加する事で、「L1:草稿確認」以下のタスクで、契約書の重要度把握が素早く出来る様になる。加えて契約金額の容易な集計や、契約金額による経路分岐追加(フローモデルレベルでのプロセス改善)が出来る様になる。
| データ名 | データ型 | データ条件 | S1 | L1 | S2 | L2 | A1 |
|---|---|---|---|---|---|---|---|
| 販売先法人名 | 文字 | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者名 | 文字 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者連絡先 | 電話番号 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者連絡先 | 住所 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約書 | ファイル | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約金額 | 数字 | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約書草稿承認 | チェック | 必須 | - | 入力 | 表示 | 表示 | 表示 |
| 契約完了報告文 | 文字 | 任意 | - | - | 入力 | 表示 | 表示 |
データ可視性変更
上述「契約報告プロセス」の「A1:請求書発行」タスクで、販売先担当者に関する個人情報が閲覧できる意味はさほどない。この例にはないが、販売部門でのみ共有されればよい情報が管理されている場合もある。「可視性」を下げる事で、情報漏えいリスクを低減させる事が出来る。
| データ名 | データ型 | データ条件 | S1 | L1 | S2 | L2 | A1 |
|---|---|---|---|---|---|---|---|
| 販売先法人名 | 文字 | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 販売先担当者名 | 文字 | 任意 | 入力 | 表示 | 表示 | 表示 | 非表示 |
| 販売先担当者連絡先 | 電話番号 | 任意 | 入力 | 表示 | 表示 | 表示 | 非表示 |
| 販売先担当者連絡先 | 住所 | 任意 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約書 | ファイル | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約金額 | 数字 | 必須 | 入力 | 表示 | 表示 | 表示 | 表示 |
| 契約書草稿承認 | チェック | 必須 | - | 入力 | 表示 | 表示 | 表示 |
| 契約完了報告文 | 文字 | 任意 | - | - | 入力 | 表示 | 表示 |
リソースモデルレベルでの改善例
複数人対応
特定の一人が対応していた業務、あるいは上司等により特定の一人が指名されていた業務を、グループ(複数人)で協調的に対応させる事で、停滞リスクを低減できる。（立候補制）
能力経験による自動割当
担当者の能力(翻訳可能言語や資格など)や経験(年数やパターン)を管理し、その能力経験を参照し自動的に割り当てる。例えば「問い合わせ回答」のタスクで、10年前の製品に関する問い合わせは、キャリア10年以上の担当者に担当させる。もって停滞を防ぐ事が出来る。
組織数の増減
例えば各10人10グループの組織を各20人5グループに再編するなどグループ数を減らす事で、各タスクで対応できる要員が増え、プロセス停滞を防ぐ事が出来る。
全社レベルでのプロセス改善例
プロセスの結合
例えば「受託サービス販売プロセス」と「受託開発生産プロセス」を連結する事で、連続的で途切れない業務処理、社内データの共有が実現できる。場合によっては、他部署業務の理解などによって広い視野をもつ人材を育成できる可能性もある。
プロセスの共有化・独自化
例えば「日報プロセス」や「リスク管理プロセス」を全部署共通化させる事で、全社レベルでのノウハウ共有や部署間比較等が実現できる。「プロセスの標準化」と呼ばれる。他方、硬直化し誰も変更提案ができなくなった「日報プロセス」や「リスク管理プロセス」を各部署独自化させる事で、各部署の思うままにフローモデル等の改変をさせる事により、部署によっては改善が進む可能性がある。
「プロセスの標準化」はプロセスの硬直化を招きかねないが、全体最適思考に基づいている点で有効であると言える。巨視的、長期的、進化論的視点に立てば、全体最適の思考に基づき「プロセスの標準化」のもとに各部署のプロセスを淘汰する時期と、局所最適の思考に基づき「自治」のもとに様々な可能性を追求する時期があって良いとも言える。
プロセス改善の失敗例
- 「プロセスモデル」を作成する余裕がない。
- 「実業務のやり方」が変わる時に「プロセスモデル」を更新する余裕がない。
- 個性が反映されていない。特に管理職の交代によって変わった「やり方」が反映されていない。
- 新人が入るたびに(メンバ能力にあわせて)「やり方」が変わるが、その度に更新されない。(参考：「SL理論」)
- 「プロセスモデル」だけが変わり「実業務のやり方」は変わらない。
- 改善のコンセンサスが図れない。（参考：「フェアプロセス」）
- 「プロセスモデル」と「実業務のやり方」を元に戻したくなったのに戻せない状態になった。
参考
関連記事
- BPM
- BAM
- 見える化
- TOC
- KPI
- KGI
- CSF
- PDCAサイクル
- プロセス
- プロセスアセスメント (プロセス評価)
- プロセスモデル
- プロセスダイアグラム (業務フロー図・ビジネスプロセス図)
- BPMN
- ドリルダウン
- ナッシュ均衡
- ABC
- SL理論
- 工事進行基準
- キャズム
- Q-BPM:プロセスダイアグラム画像の書き方
- Q-BPM:サンプルプロセス記事の書き方
- BPM Story 第2話：カイゼン効率の高い業務領域（2009年6月）
- Questetra BPM Suite を用いたBPM改善事例
