[BPM ビジネスプロセス革新実践ガイド]

2009年9月25日(金)ビジネスプラットフォーム革新協議会（BPIA）

4. 第2ステップ（特定ビジネスプロセスプロジェクト）

1) プロジェクトの規模

通常このプロジェクトは、表1のような規模で実施します。

2) 計画

第2ステップでは、本格的なBPMシステム導入の前提プロジェクトとしての1つのビジネスプロセスを実施します。そこでまず、対象とするビジネスプロセスを決めます。[node:1179, title="前回"]の第1ステップと同様に、BPMシステムを導入することによる効果を定量化でき、改善によるメリットが会社全体にPRできるようなビジネスプロセス、言い換えれば在庫管理など問題の多いビジネスプロセスを対象としてください。

実際の設計や開発に入る前に、第1ステップのときと同様、計画を検討します。第1ステップの計画段階で策定した、大括りのマイルストーンをより詳細にして、第2ステップでのプロジェクトを確実に遂行するための計画に落とし込みます。プロジェクト計画を策定する際、新たに導入するBPMシステムツールの具体的な検討・検証作業を加えます。

上記の計画を策定し承認されれば、いよいよここから本来の第2ステップでのプロジェクトとしての設計・開発・運用に入ります。ここから先は、BPMシステム構築においても一般的なシステム構築の工程（要件定義・基本設計・詳細設計・製造・試験・運用開始）と基本的には変わりません。

3) BPMシステムツールの検証

第2ステップで実施する必要があるのが、BPMシステムツールの検証です。BPMシステムツールの検証にあたっては、様々な観点から機能を検証し、BPMシステムツールや開発体制を決定します。ここで重要なことは、第2ステップで実施する特定ビジネスプロセスのBPMシステムだけではなく、第2ステップ（全社展開プロジェクト）で実施する本格展開までを見通して、機能・運用・コストをも含めたBPMツールの検証・評価を実施することです。これにより、慎重な検証と評価が後の開発・運用上のリスクを大きく減らします。

検証・評価する主な項目は以下のようになります。

1. 接続性

   採用する予定のBPMシステム製品が自社の既存システムと接続可能かを検証します。特に接続先が手組みのシステムである場合、BPMシステムツール側に連携方法が用意されていないことがあるので、注意が必要です。また、関連会社や取引先やお客様などの外部システムとの接続の検証も必要です。

2. 性能

   連携の際に受け渡されるデータ量に耐えられるだけの性能が出るかを検証します。性能が得られないときは、業務要件を見直したり、ハードウェア増強を検討したりします。場合によっては大量データ連携のために別途補助ツールを導入する必要があります。

3. システムとしての運用性

   作成したBPMシステムは柔軟な管理が可能かどうかを検証します、既存のシステム運用ツールや運用管理基準との整合性を確認します。

4. 柔軟性

   刻々と変化するビジネス環境に対して、BPMシステムとしてのビジネスプロセスも、変化に柔軟に対応できるかが重要です。BPMシステムとして拡張性やメンテナンスが容易かどうかは、検証にあたり重要なポイントになります。

5. プロセスの可視化

   プロセスの可視化は、採用するBPMツールにより表現方法に違いがあり、自社ですでに実施しているBPM活動に、より近いイメージの表現ができるBPMシステムツールを選択すると関係者の理解も早くなります。

6. モニタリング

   プロセスを監視するために、プロセスの実行査証をどのような形で残せるかどうか、またリアルタイムにプロセスを監視しプロセスの違反や異常があった場合に、プロセスオーナーや業務実施部門などに通知する機能があるかどうかを検証します。

7. 社外関係者（ベンダー、システムインテグレータ、コンサルタント）のサポート

   採用を予定しているBPMシステムツールベンダーや、実際に開発を担うシステムインテグレータ、または様々な局面で支援を仰ぐコンサルタントが、十分な経験や知識を持っているか、十分なサポートを提供可能かを確認します。

8. 費用

   初期導入費用（ライセンス費用）と保守費用（ライセンス保守費用）が適切か、また将来の導入範囲や業務量の増大に対して費用の増加がどのくらい発生するかなど、自社にあった最適な価格体系になっているか確認します。

これらの事項を検証することで、技術的な観点からBPMシステム導入の開発リスクの低減を図ることができます。

実際の検証作業は、時間や費用の制約がある場合、ベンダー、システムインテグレータ、コンサルタントの今までの知見を活用し、机上で実施することもあります。また、この検証作業は第2ステップでのプロジェクトのみではなく、第3ステップでも新しい技術要素が加わった時点で、実地もしくは机上で実施します。

上記の検証項目を慎重に検討し、自社に最適なBPMシステムツールを選定・購入します。

4) 設計

要件定義

開発段階以降は、基本的に第1ステップで実施した内容と同じですが、第2ステップでは、新たに本格的なBPMシステムツールを使って開発するため、図1のようなスケジュールとなります。要件定義段階では、構築するビジネスプロセスの要求事項を把握し、機能要件とシステム要件を明確にします。まず現状を調査し、ビジネスプロセスのあるべき姿をビジネスプロセスに表現します。ここでは第1ステップ同様に、ビジネスプロセスモデリングツールを使いBPMNで記述します。必要に応じてビジネスプロセスモデリングツールに搭載されているシミュレーション機能を実行し、事前に対象プロセスをある程度改善します。その際に、運用していくためのモニタリングのポイントと評価軸を決めます。

基本設計

要件定義で確定した要件をもとに、仕様を明確にし、BPMシステムの骨組みを設計します。要件定義で定義したビジネスプロセスから、システムの利用者から見た画面や帳票や業務実施タイミングを明確にします。またBPMシステムツールでの構築方式を明確にし、BPMシステムツールと既存システムとの一連のやり取りを順序立てて整理します。

さらに、既存のシステムから流用できる機能と、新たに作成するビジネスプロセスごとの機能を明確にしてまとめます。システム的な要件として、信頼性・性能・セキュリティ・拡張性・運用についてもまとめます。