ビジネス・プロセス・マネージメントの現状〜「経営と情報の架け橋」の実現にむけて第5回

業務を分類する

現在の企業活動にとってITシステムはなくてはならない存在となっています。しかしながら、企業活動の全てが、ITシステム化されているわけではありません。例えば、工場で試作を行うために部材を倉庫から持ちだす場合は、表1のような作業が行われます。

人が、どんな部材が必要なのか考え、ある場所から部材を持ってきます
勝手に部材を持ち出すわけにはいかないので、倉庫システムに出庫情報を入力します
倉庫システムは、日次の特定の時間で部材在庫情報を集計し、危険在庫数に至っていれば、アラームをあげます

表1：部材を倉庫から持ちだすプロセス

表1の作業を前回までにご説明したeEPCモデルで表現します（図2）。すると、企業活動全体において各業務は、「人が行う業務なのか？」「人がシステムを使って行う業務なのか？」「システムが行う業務なのか？」と区別することができます。

図2：業務の区分とeEPCモデル
（画像をクリックすると別ウィンドウに拡大図を表示します）

特に、「人がシステムを使って行う業務」は、人がシステムから情報を抽出し、情報をシステムへ入力するためには、何らかのユーザインターフェースを必要とするということです。今、皆様がこの文章を読まれているPCの画面が、このユーザインターフェースに当たります。そして、技術の進展によって出現してきたマイクによる音声認識、指紋・静脈認証、RFIDなどのインターフェースを利用した様々な解決方法（ソリューション）が検討されています。ここで重要なことは、「人間の脳がITシステムと直結しない限り、何らかのインターフェースが必要」ということです。

このように可視化されたビジネス・プロセス・モデルにおいて、課題がある業務のうちITシステム化すべき対象業務を洗い出していきます。

そして、課題がある業務のうち「人が行っている業務」については、新規に業務パッケージを導入するか、もしくは、新規にシステム機能を開発することを検討します。

既に「ITシステムを使っている業務」「システムだけで行っている業務」については、課題が解決できるようにITシステムを改修していくことを検討します。

最近では、ビジネス・プロセスの課題を検討した結果、複数のシステムを連携させることで課題を解決するというSOA的な検討が注目を浴びています。

このようにITシステム化対象業務を洗い出し、それぞれに対してどのような解決アプローチをとるのか検討することが、ITシステム要件の整理にあたります。

業務改善へのARISの活用

ここで、ITシステム化要件抽出というアプローチ以外に、業務改善に向けARISを活用するアプローチとして、簡単に2点ほどご紹介します。

まず、業務改善の一助となるARIS製品の機能としては、ビジネス・プロセス・モデルをHTMLに変換し、イントラネットで社内に公開するWeb Publishing機能があげられます。この機能を利用してビジネス・プロセス・モデルを社内イントラで広く公開し、そのモデルに対して現場からのフィードバックをメールで受け取ることができます。このように、現場の業務規定資料としてプロセスを活用し、更なる業務改善を目指すというアプローチがあります。

もう1点としては、eEPCモデルの各オブジェクトに組織人員数やイベント発生頻度、業務処理時間を入力して、動的にシミュレーションし、定量的にビジネス・プロセスを評価することができます。

このような機能をご紹介すると、よく「ARISがどこまで業務改善点を指摘してくれ、どのような改善策を与えてくれるのか？」という質問を受けます。しかし、我々は、「ARISがソフトウェアである以上、改善点や改善策を与えてくれるものではありません。但し、課題に対して改善策を検討する際の何らかの"気づき"を得ることができる機会が増えるという価値をARISが提供してくれます」と答えています。

もし、ソフトウェアやITツールがそのような改善点を示してくれるのであれば、人間がいらなくなる世界、つまりは、ITに支配される世界がやってくるのかもしれません。しかし、ソフトウェアやITツールは、人間が活用してはじめて効果を発揮するものであり、そのような世界はやってこないと思います。

プロセスからアプリケーションへ

さて、話を元に戻し、ビジネス・プロセスからITシステム化要件を抽出した状態で、ビジネス・プロセス・モデルをシステム開発に活用していく例をご紹介します。

このアプローチは、図3に示すように「ビジネス・モデルの小島」と「ITという小島」に「ビジネス・プロセスという架け橋」をかけることにあたります。これは、まさに「経営と情報の架け橋」をかけることにあたります。、我々は、このアプローチをProcess to Application（P2A）と呼んでいます。

最近は、ITシステムに関するシステム・プロセス・モデルを描き、システム開発を行う分野をBPMと呼ぶことが多いようですが、この意味でのBPMという定義は、P2Aを指しており、狭義の意味でのBPMと考えるべきです。

筆者は、BPMという言葉が氾濫し、様々な定義で乱用されている現状に対し、懸念を抱いています。ビジネス・プロセスが、システム開発においてどのような位置にあるか？ということを明確にするためにも、BPMという言葉が、プロセス設計・プロセス導入・プロセス評価というサイクルを継続的に実施するという定義で活用されることが、まず必要だと感じます。