ワークフローサンプル: 第521話：業務プロセスの自動化とは？（その４）

過去3回の記事

では、「業務プロセス内」の自動化について

A. 業務プロセス内の「次の工程」に自動的に進むようにする
B. 業務プロセス内の「とある工程」が無人で処理されるようにする

という２視点の違いを解説するとともに、それぞれの設定方法について述べました。

今回（最終回）の記事では「業務プロセス間」の自動化について、整理してみたいと思います。

業務プロセス同士の接続

◇ 業務プロセスの位置づけ

これまでは『見積書承認プロセス』や『受注報告プロセス』といった「個々の業務プロセス」にフォーカスして議論しました。しかし、全社視点での自動化（生産性の向上）を推進するには「業務プロセス同士の接続性」についても考えなければなりません。

このようなステージでは、あらかじめ社内の「業務プロセス」を可能な限り列挙しておくことが改善議論の近道となります。

つまり、全体俯瞰によって各業務プロセスの位置づけや依存関係が明らかになり、また各業務プロセスのあるべき「インプット」と「アウトプット」が明確になります。伴って、業務プロセスの責任者（プロセスオーナー）が目指すべき運用方法や改善方向も明らかになるでしょう。

◇ 業務プロセスの列挙

では社内には、どのような「業務プロセス」があるのでしょうか？

事業内容や組織規模によって大きく異なるのは言うまでもありません。同時に「社内全ての業務詳細を把握できている人は居ない」と考えるべきでしょう。つまり「業務プロセスの列挙」は誰が担当するにしても、ある程度の現場ヒアリングが必要となります。

そして、調査結果の列挙の際は、全体俯瞰しやすいようにカテゴリ分類して列挙するのが重要と言えます。

方法論としては、会社の損益を計算する際の「製造原価」「販売費」および「一般管理費」といった費用区分や、研究機関のプロセス分類法を活用して、社内の業務プロセスをマッピングするのが現実的となります。

＜APQCによるプロセス分類手法＞

戦略立案プロセス (Develop Vision and Strategy)
製品開発プロセス (Develop and Manage Products and Services)
製品販売プロセス (Market and Sell Products and Services)
製品納入プロセス (Deliver Products and Services)
顧客支援プロセス (Manage Customer Service)
人材開発プロセス (Develop and Manage Human Capital)
ＩＴ管理プロセス (Manage Information Technology)
財務管理プロセス (Manage Financial Resources)
設備管理プロセス (Acquire, Construct, and Manage Assets)
リスク管理プロセス (Manage Enterprise Risk, Compliance, and Resiliency)
渉外関係管理プロセス (Manage External Relationships)
遂行能力開発プロセス (Develop and Manage Business Capabilities)

[見積承認プロセス-受注報告を起動]

[受注報告プロセス-見積承認から起動]

◇ 接続するデータ項目の整理

業務プロセスの列挙が完了すれば、たとえば「見積書承認プロセス」と「受注報告プロセス」の2つの業務プロセスには、強い連続性があることが分かります。（もちろん見積と受注の関係であれば、列挙するまでもなく明らかなのですが…）

この様な場合、「見積書承認プロセス」から「受注報告プロセス」への、自動的な案件データ受け渡しを検討すべきです。つまり、「見積書承認プロセス」において『受注』となった案件が、自動的に「受注報告プロセス」に流れ始めるような仕組みにすることで、データ投入の手間を省くことができます。

なお、継承させるデータ項目については、後ろプロセス（子プロセス）から前プロセス（親プロセス）の「データ項目」を見て、業務に必要となるデータを選択するのが良いでしょう。

（もっとも、子プロセスで必要となるデータについて、「親プロセス内の工程で取得しておいてほしい」となるケースもあります。）

◇ 具体的な接続設定の例

この例では、見積書承認プロセスの最後に「メッセージ送信イベント」が配置され、受注報告プロセスの先頭にある「メッセージ開始イベント」への接続内容が設定されています。

そして、以下の５つのデータが引き継がれる設定となっています。

見積書承認プロセスにある『見積提出先会社名』が、受注報告プロセスの『お客様会社名』として、
見積書承認プロセスにある『担当者部署名＋氏名』が、受注報告プロセスの『お客様部署名＋肩書き』として、
見積書承認プロセスにある『見積担当者』が、受注報告プロセスの『担当営業』として、
見積書承認プロセスにある『明細テーブル』が、受注報告プロセスの『明細テーブル』として、
見積書承認プロセスの『案件ID』が、受注報告プロセスの『注意事項』に。

＜メッセージ送信イベントの設定画面＞

業務プロセスのサイズについて

「１つの業務プロセスにすれば良いのでは？」

たしかに「長大な業務プロセス」として業務プロセスを定義すれば、業務プロセス間の接続をする必要がありません。この例で言えば「見積書承認プロセス」と「受注報告プロセス」を合体させて「見積提出および受注報告プロセス」とすれば良いのです。

しかし、この「長大な業務プロセス」には、いくつかの問題点があります。

改善責任者（プロセスオーナー）の担当範囲が広くなる
利害関係者が多くなり改善変更の合意形成に時間がかかるようになる
テスト運用する際の手間が大きくなる
データ項目数が多くなり集計しづらくなる
データ項目数が多くなり適切なデータ閲覧権限を設定できなくなる
エラー案件制御を行う管理者が多くなり対処責任が不明確になる

つまり、責任者（プロセスオーナー）に日常的なプロセス改善が期待される場合は、ある程度小さい単位で業務プロセスを区分しておく必要があると言えます。

業務プロセスの自動化の意義

経済学者シュンペーターに言わせれば、「イノベーション」には５つのパターンがあります。

新しい財貨の生産
新しい生産方法の導入
新しい販路の開拓
原料あるいは半製品の新しい供給源の獲得
新しい仕組みや組織の実現

100年以上も前の提言ながら、未だに広く使われるパターン分類です。そして、「2.新しい生産方法」や「5.新しい仕組みや組織の実現」などは、日々の業務改善の延長にこそあると言えるでしょう。

業務プロセスそのものを企業の競争力の源泉とするためには、「自動化」を含めた業務プロセス改善を、日常的に継続的に実施していきたいものです。（改善サイクル／PDCAサイクル）

[受注報告プロセス：「1. 受注登録」画面]