マニュアル統制の悪夢とBPMの利点を考える：M&A時代のビジネスガバナンス（3）（1/2 ページ）

前回はID管理には、アクセス権限の適切な設定を行う「アイデンティティ・プロビジョニング」と、設定されているアクセス権限を検証する「アイデンティティ監査」の2つの役割があることを紹介した。今回は、ITガバナンスの中でも特に「ビジネスプロセスマネジメント（BPM）」について説明する。

[国谷 俊夫，サン・マイクロシステムズ株式会社]

BPMは内部統制に有効だ

　個々の業務をつなぎ、ビジネスの効率化や最適化を継続的に目指そうとするビジネスプロセスマネジメント（BPM）。その考え方や関連製品の紹介記事は、すでにWebサイト上に多く存在する。このようにBPMは広く認知されている概念ではあるのだが、内部統制に対して効果があることはあまり知られていない。

　BPMといっても、その製品アーキテクチャは数種類あり実に多様だ。現在では、業務プロセスのモデリング機能にたけた製品と、システム間を連携させながら業務プロセスの構築と実行をシステム化する製品、これら2種類が主力である。

　前者のモデリングに注力した製品は、既存システムに縛られずに業務プロセスの設計が可能であるため、表現の自由度が高く、かつては経営者や業務コンサルタント向けともいわれてきた。ただし、システムへ実装するためには、コード自動生成機能はあるものの、既存システムとつなぐためのモジュールの開発が別途発生する場合がある。

　一方、後者のシステム連携にたけた製品は、EAIやSOAを実現する製品の拡張機能としてBPMを実装している。その歴史故に、連携できる対象アプリケーションが豊富であることが特徴だ。モニタリングや権限管理機能も充実しており、「ゼロコーディング」のようなコードを書かずともデータ連携や業務プロセスの構築、および稼働状況を確認できるアプリケーションの構築が可能な製品もある。

　このような技術が、もともと理論先行のイメージが強かったBPMを現実のものとしている。両者ともお互い補完関係にあるのだが、今回は特に、内部統制の継続的な実行力を備える手段として、後者の「システム連携のアーキテクチャ」が極めて重要であることをご理解いただきたいと考えている。

マニュアル統制の悪夢に陥ると……

　かつてシステムが各部門主導で導入された結果、“それぞれ異なる経緯を背負ったシステム”が、全社に散在するのはよくある一般的な状況だ。このような“分断されたシステムをまたぐ業務プロセス”には、多くの統制が必要であることに気付いてきた現場のプロセスオーナーも多いと思われる。

　半永久的に続く、内部統制のような部門や業務を超えた全社最適型プロジェクトでは、全サイクルにおける作業の有効性や効率性を、あらかじめ議論する必要がある。しかしながら、こうした中長期の戦略が十分検討されないまま、統制活動の実務が「マニュアル統制」で実装されるというケースは非常に多い。

　「マニュアル統制」とは、運用中のアプリケーション間が分断されていたり、アプリケーションに統制機能が不足していることが原因で、補完的に人的処理が発生する作業を指す。こうした手作業の裏には、必ず「ミスを犯す」というリスクが伴うことを忘れてはいけないが、それ以上に憂慮すべきは、ミスを防ぐための施策を含め、業務の正当性を確認する“内部テストで評価すべき項目”が多岐にわたってしまうということだ。

　図1は、各境界点で統制活動が必要になることを抽象的に説明したものだ。マニュアル統制では、システムから出てきた情報の受け取り方やその情報の扱い方、さらに次の業務への渡し方を、事細かに定義する必要がある。当然、それらが正しく遂行できることや、遂行できていたことを証明するためのテスト方法も定義しておく必要がある。

図1：システム連携による統制の自動化（クリックで拡大）

システム連携による統制の自動化
マニュアル統制（連携なし）ではシステム間の統制活動が多くなる傾向がある。統制ポイントが増えると、それに伴うテスト項目も多くなるので、より多くのリソースを内部統制に割く必要が出てくる。そのため、統制の自動化（システム連携、システム統合）を目指す必要がある

　一方、業務がシステム的に連携できている場合には、統制活動そのものはシステム内部に含まれることになる。システムは常に同じ条件下で同じ結果が期待できるという特徴を持っているため、予防的な統制が働くようになる。そのため、その評価に当たっても、マニュアル統制に比べて極めて省力化が期待できる。これを以下では、「統制の自動化」と定義する。

内部統制の自動化とは

　前述のような、「業務のつなぎ目をどのように自動的に統制するか？」という議論は、大抵2つの解にたどり着く。

　1つは、業務そのものを「作り直して」一本にまとめ上げる方法、そして2つ目は業務を何らかの方法でシステム的に連携する方法、である。

　ERPなどのパッケージ製品を一斉に導入して業務プロセスを統合することは、統制の自動化を実現する手段として、立案段階においては最もシンプルなアプローチといえる。

　しかし、いま現在残された時間や、必要な作り込みの量、その作り込みが将来の製品アップグレードにも耐えられるのかといった判断、そして現状の業務とのギャップに関する社員教育、と懸念事項が多いのも事実だ。

　また、業務提携や経営統合といった事業環境変化のスピードに乗って経営層が期待する相乗効果を早期に発揮するためにも、ITの役割が決定的であることは間違いない。従って、システム運用負荷の増大となり得る、特定のプロプライエタリな技術で記述されたシステムへの、過度なカスタマイズ・追加開発は避けるべきである。

　つまり、見た目には業務プロセスが連携され、統制の自動化が達成できていても、オープン性や柔軟性という観点が見落とされていては、内部統制の持続が困難になるというわけだ。

　そこでBPMが必要になる。BPMは既存の業務プロセスを生かしたまま、内部統制の実現方法を模索する企業にとって有効な解となる。

　つまり、いまあるものを捨てて統合パッケージ製品の導入に踏み切ることなく、部門と部門、もしくはシステムとシステムの間に発生する内部統制上のリスクを低減させることが可能なのだ。こうした効果は、次に挙げるようなシステム連携にたけたBPM製品の特徴によるものである。

• 「集中化」：システム間の接続に必要なビジネスロジックは、標準規格であるBPMN（Business Process Modeling Notation）によって表現、構築されている。そして、BPMで定義された業務プロセス上を流れるデータは、すべてBPMのデータベースに記録される。これにより該当業務についての全履歴を、1カ所から一貫して確認することが可能になり、内部統制の有効性を評価する際の負担を軽減することができる。
  
  例えば、ファイル転送やメッセージング・システムのみで連携されたシステムでは、「過去においてどのようなデータが実際に渡されたのかを確認すること」までは考慮されていないことが多い。こうした場合は、BPMの場合とは異なりマニュアル統制と同等の手間が掛かる可能性がある。

• 「接続性」：システム連携は、長期にわたって最も実績のあるEAIをベースとした技術によって実現されている。既存のほとんどのパッケージアプリケーションに対して共通となるデータ交換基盤を、製品基本機能の範囲で確立することができる。データ交換の仕様はアプリケーションにネィティブな方法でも、Webサービスでも、実装者にとって最も都合の良い技術を選択できる。

• 「柔軟性」：システム同士を直接接続すると必ず問題になるのは、サポートマトリックスやバージョン互換性である。どこかのシステムをアップグレードする度に、そのほかも引きずられるようなことがあっては、縦割り構造では特に不都合だ。EAIは包括的な連携を実現し、その結果、個々のシステムはビジネスサービス要素として露出されるようになる。このように、バージョン依存部分を連携基盤で吸収し、データへのインターフェイスを提供することによって、直接接続よりも高い柔軟性を確保することができる。

• 「リアルタイム性」：業務が接続されていくうえで、最も気を使うのは例外やエラー発生時における対処方法だ。BPMは業務の進ちょくがデータベースで管理されているので、問題点が解消された後のリトライが容易である。これを実現するためにはリアルタイムにアラートを挙げられる管理レポート機能が必要であり、一部のBPM製品で実装されている。

図2：BPMのアーキテクチャ（クリックで拡大）

BPMのアーキテクチャ
既存システムをEAIなどの連携技術により、共通プラットフォームに載せ、その上で業務プロセスを構築する。各技術要素が連携してサービスを構成し、そのサービスが連携して業務プロセスとなる様子を模式的に表現している

次に、具体的な例を挙げてみる。