目次


ビジネス・プロセス・マネジメントの採用シナリオ

組織が BPM ソリューションを実装または展開する方法の概要

Comments

概要

一部のビジネス界の人々にとって、ビジネス・プロセス・マネジメント (BPM) は、ワークフローやモデリングと同義です。すなわち、ビジネスによって運営されるプロセスを文書化し、これを参照目的および場合によっては改善を設計するために使用します。一方、技術者にとっては BPM はプロセス自動化と同義です。すなわち、自動化できるプロセス内のステップを特定し、これらのタスクを自動化する情報技術 (IT) 機能または「サービス」を実装することです。これらのアプローチはどちらにも価値がありますが、どちらも全体的に BPM を理解しようとするものではないので、どちらのアプローチも BPM のすべての価値を得るものではありません。BPM は単なるワークフローでも、単なるプロセス自動化でもありません。

今日、組織はビジネスの機敏性を必要としているため、BPM の導入に乗り出しています。増え続けるお客様の要求や環境の脅威に新製品や新サービスで迅速に対応し、ビジネス戦略の計画された変更を速やかに可能にする能力を必要としています。迅速に拡大したり、ビジネス・パートナーのネットワークを制限したりする機敏性が必要です。こうした状況において、BPM はビジネスの機敏性を実現する要因になり得るので、BPM の実装環境には、何らかの形で次の機能を組み込むことがあります。つまり、モデリング、シミュレーション、ワークフロー、ビジネス・ルール、ビジネス・データ、ビジネス分析、コラボレーション、ヒューマン・インターフェース、ビジネス・イベント、ビジネス・アクティビティー・モニタリング、コンテンツ、コンプライアンス、セキュリティー、およびシステム統合です。図 1 は、BPM ユーザー (例: ビジネス・アナリスト、管理者) が役割ベースのビューを使用して、必要な機能 (例: ビジネス・ルール、ワークフロー) を提供するBPM プラットフォームと対話する様子を示しています。

図 1. BPM 機能
BPM capabilities
BPM capabilities

BPM イニシアチブとその結果作成される BPM ソリューションは、包括的なものです。それは導入の障壁が高いことを意味するのでしょうか。開始するにはこれらの各機能分野の専門家が必要であることを意味するのでしょうか。まったくそのようなことはありません。実際に、BPM の主な前提の 1 つは、プロジェクトをシンプルに開始できることと BPM 機能を段階的に展開することが容易であることです。この記事では、IBM BPM 製品を実現要因の例として使用して、BPM 採用と展開のベスト・プラクティスについて説明します。これらのプラクティスは、IBM による数千もの BPM カスタマーの実装から選び出されたものであり、組織に固有のニーズに合わせてカスタマイズ可能であり、BPM イニシアチブの開始または展開に使用できます。また、3 つの採用シナリオ (ビジネス主導ディスカバリー、対話とコラボレーション、継続的なプロセス最適化) にしたがって分類できます。これらの採用シナリオは、正式なリストではなく、互いに矛盾するものでもありません。

ビジネス主導ディスカバリー

ビジネス主導ディスカバリーの採用シナリオは、中心となるビジネス領域の特定から始まります。例えば、銀行が口座開設プロセスの事前資格審査に柔軟性がないことが分かったり、電気通信会社が、ターゲットを絞ったオファーによるマーケティングや販売キャンペーン管理を改善する必要があったり、教育関係の行政機関が教師免許の交付と管理を最適化する必要があったりすることです。適切なビジネス領域を選択するには、ビジネス・チャンス、コスト、ペイン・ポイント、およびコンプライアンス要件の検討が必要です。

ビジネス主導ディスカバリーには、プロセス・ディスカバリーが必要です。これは、ターゲット・ビジネスの現在の運営方法 (「As Is」の状態) と、もっと重要なのは、ビジネスの今後の運営方法 (「To Be」の状態) を理解することです。検討内容には次のものがあります。

  • 各タスクの完了に要する時間
  • それに要するコスト
  • 伝達される情報 (紙の文書、ファックスなどを含む)
  • ビジネス・プロセスに関与する担当者 (役割)
  • 担当者が使用する情報チャネル (例: 電子メール、電話、Web ポータルなど)
  • ビジネス・プロセスをサポートするバックエンド・システム (アプリケーション)

プロセス・ディスカバリーを実行すると、業界固有のアプローチにより価値実現時間 (TTV) が大幅に改善されます。例えば、対象となるプロセスの業界ベンチマークを見直して、競合他社のオペレーションや業界の水準との比較を文書化することが役立ちます (例: 顧客獲得に要する時間、国税庁での不正申告件数など)。重要業績評価指標 (KPI) や業界固有の資産 (プロセス図など) は、プロセス・モデリングの有効な出発点になります。例えば、組織は、(白紙やブランク画面ではなく、) WebSphere Business Modeler を使用して作成される標準的な銀行口座開設ビジネス・プロセス・モデルから開始したり、すでに文書化されている業界固有の KPI のリストの中から選択したりすることができます。これらのソフトウェア資産は、他の業界固有資産や業種にとらわれない資産と一緒に WebSphere Industry Content Pack for Banking に組み込まれています (情報源を参照)。

モデリングは、ビジネス・プロセス (「As Is」と「To Be将来」の両方の状態) を理解し、文書化するのに使用します。モデリング・ツールは、使いやすい製品 (スモール・フットプリント、最小限の構成要件、非 IT ビジネス・ユーザー向け) であると同時に、必要なモデリング機能を提供するものでなければなりません。Microsoft® Visio® のような文書化ツールは、ビジュアル文書を使い慣れた形式で作成できますが、BPM プラグインを使用する場合であっても、適切な BPM モデリング・ツールではありません。これらのツールは単に視覚的要素を保管するだけで、(基礎のモデリング・フレームワークやメタモデルによってサポートされる) 真のモデリング・ツール機能がありません。その結果作成される成果物は、デジタルの「行き止まり」です。つまり、正常に機能するソフトウェア・コードを作成したり、詳細なプロセス分析を行ったりするには、他のソフトウェア・ツールへのインポートが必要です。一方、図 2 に示されている IBM BlueWorks Live や、WebSphere Business Modeler、WebSphere Lombardi Edition の Designer は、本格的なモデリング・ツールであり、Business Process Modeling Notation (BPMN) などの業界標準の構成体を提供します。この機能は、実績のあるモデル駆動型開発 (MDD) アプローチをサポートするのに重要です。これらのツールを使用すると、ビジネス・ユーザーとテクニカル・ユーザーの両方がプロセス・モデルを設計し、構築することができます。これらのプロセス・モデルは分析され、最適化され、実装コードに直接変換できます。

図 2. IBM BlueWorks Live におけるビジネス・プロセス・モデル

また、全機能を持つ一部のモデリング・ツールは、プロセス・シミュレーションを行います。つまり、ディスカバリー時のプロセス・モデルを最適化するために「what if?」シナリオを実行します。シミュレーションを使用すると、最小限の労力で、ビジネス環境や実稼働環境に悪影響を与えることなく、代替アプローチを実験し、評価して、貴重なインサイトを収集することができます。同様に、IBM の WebSphere ILOG® JRules などの業界最先端のビジネス・ルール管理システム (BRMS) を使用すると、ビジネス・ルールへの変更の効果を、適用前に実証することができます。例えば、教師免許のテストと資格認定プロセスに、教師が 18 歳ではなく、21 歳であることを求めるルールが含まれる場合、この変更の影響を受ける、認定を申請中の教師数を判別することが可能です。ビジネス・ルールとビジネス・プロセスとの関係については継続的なプロセス最適化で詳しく説明します。

Lean、Six Sigma、Lean Six Sigma および Business Process Re-Engineering 方式で示されるように、このビジネス主導ディスカバリーの採用シナリオには、プロセス改善も適合します。これらのイニシアチブの目標は、ビジネス・プロセスを改善するために、ビジネス・プロセスをディスカバーし、モデル化することです。WebSphere Business Modeler は、プロセス改善イニシアチブをサポートする有効なモデリング・ツールです。ビジネス・プロセスの改善には、BPMのIT 実装環境が含まれる場合と含まれない場合があることに注意してください。例えば、業務案件担当者が FAX マシンまで歩くのに時間がかかるため、毎週 2 時間以上も時間を無駄にしていることが、分析により判明する場合があります。この場合、改善の推奨事項は、FAX マシンを担当者のワークステーションに近づけて配置することです。しかし、最も有効かつ最新のプロセス改善には、継続的なプロセス最適化で説明しているように、BPM ソフトウェア・スイートを使用した主要ステップの自動化が必要です。

最もコスト効率の高いビジネス・プロセス・モデリングを導入する場合、時間のかかる提案要求 (RFP) や技術的な概念検証 (PoC) 活動と対照的に、BPM プラットフォームの使用体験と評価を相対的にシンプルかつ迅速に行って、TTV を短縮することができます。さらに、これらの調達活動に通常関わるユーザーは技術者ではありませんが、これらの非技術者が BPM IT 製品評価に参加し、ベスト・プラクティスに従うことをお勧めします。こうした理由から、IBM の BlueWorks Live などのクラウド・デリバリー・モデルを介した BPM が最適です。パブリック・クラウドを活用すると、ソフトウェアの調達やデプロイメントについて、評価する組織が IT 部門に依存することがなくなります。必要なエンド・ユーザー・ソフトウェアは、エンド・ユーザーのパーソナル・コンピューターやラップトップに通常すでにインストールされている Web ブラウザーのみです。

ビジネス主導ディスカバリー採用シナリオは、ビジネスの運営方法や、ビジネス・プロセスの改善が「最終結果」に与える影響の理解を容易にします。正常な実装における通常の次のステップ (または別の出発点) は、新たに設計されたビジネスのベスト・プラクティス (つまり、BPM モデリング・ツールを使用してモデル化されたプロセス) を実用可能にすること、および組織全体の人々を参加させることによってコラボレーションを確保することです。これには、対話とコラボレーションの採用シナリオが適用されます。

対話とコラボレーション

このセクションでは、BPM のコラボレーションの側面とともに、アドバンスド・ケース・マネジメントと呼ばれる密接に関連した概念を取り上げています。

BPM にとって重要な成功要因はコラボレーションです。参加者は、ビジネス・プロセスのディスカバリー、実装、および実行中に必要に応じて対話できなければなりません。さまざまな部門、特に物理的または地理的に分散した部門からのユーザーが参加し、有意義かつ効率よくコラボレーションして、プロセスを適切に行うには、ワークショップとミーティングが不可欠です。このように、コラボレーションの監査証跡 (例えば、ディスカッション、レビュー、コメント、または承認) を、参加者の電子メールやハードコピー・ファイルに埋没させるのではなく、ビジネス・プロセスのモデルにリンクすることができます。参加者は、承認を決定する権限が与えられ、意思決定を行うか、他のアクションを取る必要があるときに通知を受け取ることができます。参加者が余分な労力を事実上費やすことなく、完全性、正確性、適時性を高めるために活動の監査証跡を自動的に保持できます。

技術者はツールの使用が相対的に得意です (例えば、統一モデリング言語 (UML) ツールを使用する設計者や、IT サービス管理ツールを使用する IT オペレーション担当者)。しかし、組織内の IT 専門家でない参加者は、それほどのスキルもなく、快適にツールを使用することもできない場合があります。

仕事中の使用頻度の観点から見てナンバーワンのアプリケーションは何かを、考えてみてください。電子メールです。電子メールを使用して対話し、コラボレーションしています。例えば、販売員は、割引の承認が必要であるので、販売のチャンスを説明するメモを店長に送信するとします。店長が返信して詳細な情報を求めると、販売員はその情報を提供します。店長は、次の電話連絡時に売り上げのチャンスについて話し合ってから、販売部長に一連の電子メールを転送し、販売部長は最終的に承認します。一カ月後、販売員は別の割引承認が必要になります。この販売員はどうするでしょうか。電子メールを送信し、臨時の割引承認プロセスが繰り返されます。

このアプローチの問題は、電子メールまたは電話、もしくはその両方の方法を使用する場合、店長はどの割引が保留中で、どの割引が承認済みであるかが分からないことです。部長は、どの承認要求が保留中であるかが分かりません。店長は、必要な情報がすべて提供されていることをすぐに確認する方法がありません。

必要なステップを迅速に定義する (どのステップが承認ステップか、だれが各ステップの実行を担当するか、いつまでに実行するか) 方法を提供するために、BPM を使用してこの割引承認プロセスを迅速に自動化できたらどうなるでしょうか。担当者が割引の承認を必要とするたびに、割引承認プロセスのインスタンスを立ち上げることができます。最初のステップは自動的に適切な担当者に回され、推奨方法 (例: 電子メールやボイス・メール) の使用をその担当者に通知します。このアプローチを使用すると、割引承認プロセスを標準化できます。その結果は、次のとおりです。

  • 販売員は正確にこのプロセスに従い、誤ってステップを抜かしてしまうことがありません (ただし、プロセス・モデルで定義されたとおり、必要に応じてステップをスキップできます)。
  • 店長は、すべての割引 (保留または承認済み) の一覧を確認できます。
  • 部長は、どの割引が承認保留中であるかが分かります。

IBM BlueWorks Live では、このとおりに実行できます。つまり、通常は電子メールを使用して実行されるこれらのシンプルなプロセスを自動化できます (例えば、マーケティング・キャンペーンの開始、プレゼンテーションの検討や承認、ミーティングの結果や実際に得られた経験、出張の承認、ラップトップ・コンピューターの要求など)。IBM BlueWorks Live でサポートされる BPM を使用すると、組織内の全員 (非技術者を含めて) が、反復可能で予測可能な手順を連携して実行できます。BlueWorks Live プロセスの自動化は、システム統合、高いスケーラビリティー、または高いスループットを必要とする複雑なプロセス (例: 口座開設) には適用されないことに注意してください。

図 3 は、販売員が ACME のビジネス・チャンスのために割引承認ビジネス・プロセス (ACME割引承認プロセス) のインスタンスを開始する例を示しています。テンプレートを使用し、プロセス・インスタンスに文書 (この場合、Excel® スプレッドシート) を添付し、担当者 (販売員、店長、および部長) にステップを割り当て、期日を設定した後、このビジネス・プロセス・インスタンスを開始しました。

図 3. IBM BlueWorks Live におけるプロセス自動化
IBM BlueWorks Live におけるプロセス自動化
IBM BlueWorks Live におけるプロセス自動化

対話とコラボレーションの採用シナリオを適用するには、低い導入障壁と、相当数のビジネス・ユーザーの参加者が必要です。これらの要因により、インターネットでアクセス可能な製品が魅力的になります。

何が自分の周りで起きているかを知るために、友人や家族との連絡を取り続けるには、どのソーシャル・ネットワーキング・アプリケーションを使用しますか。Facebook ですか。ツィッターですか。ソーシャル・ネットワーキングの発想を BPM に適用し、「ソーシャル BPM」にすることを検討してみてください。BPM のリーダーや同僚に同時に、ただし個別につながって、企業の問題の機密性を保持し、必要な作業をサポートし、実行するための適切な配信を適切な時期に受け取るのは、便利ではありませんか。図 4 に示されているように、IBM BlueWorks Live は、パブリック BPM コラボレーション・ブログ・ストリームを、プライベート (企業) 配信と並行し、共存させて提供して、「ソーシャル BPM」の必要性を別個の便利な方法でサポートします。IBM BlueWorks Live は、Software-As-A-Service (SAAS) モデルを使用して提供されます。このモデルには、同じ組織からの個人グループ間のプライベート・コラボレーションをサポートするための、セキュリティーやアクセス権限が組み込まれています。

図 4. IBM BlueWorks Live のプライベート・コミュニティーとパブリック・コミュニティー

BPM コラボレーションを実現する鍵となるのは、BPM ユーザー・インターフェース (UI)、すなわち BPM の顔です。BPM ソリューションの成功のためには、ユーザー・エクスペリエンス、使いやすさ、直観性の重要さを過小評価してはいけません。前述のように、日常的に行われるビジネス・プロセスの大部分には、人間の対話が必要です。したがって、BPM ソリューションの UI とそれ以外の部分との間の緊密な連携が必要です。IBM の WebSphere Lombardi Edition は、この原則を念頭に置いて作成されました。完全な BPM ソリューションである Lombardi は、電子フォームや、ビジネス・プロセスの進行に伴うこれらのフォーム間のフローを定義できます。図 5 で示すように、Lombardi では、これらのフォームは「Coach」と呼ばれます。

図 5. WebSphere Lombardi Edition の Coach

私は、ユーザー・インターフェース (例: 企業全体のポータル、企業全体の電子フォーム用テクノロジー) を標準化するお客様に協力してきました。このアプローチで得た経験から、正常な BPM の実装はこの環境と両立しなければならない (ただし、おそらく初期の概念検証には必要ありません) ことがはっきりしています。例えば、BPM 関連のウィジェットやフォームは、ポータル・テクノロジーと両立しなければなりません。役割ベースのダッシュボードは、非常に優れていることが証明されました。これは、ビジネス・ユーザーが、意思決定を行われなければならないときに適切な情報に適切な時にアクセスできるからです。この原理については、アドバンスド・ケース・マネジメントと BPMでもっと詳しく説明します。

IT が提供する機能 (例: サービスやビジネス・ルール) で自動化できないタスクは、「ヒューマン・タスク」と呼ばれます。これらのタスクには、人と人との対話や、人とシステムとの対話が必要です。こうしたタスクについて、設計者は、プロジェクトの最初から例外について考慮していなければなりません。例えば、店長が休暇中はどうなるか。このインスタンスのみで承認ステップを省略することは可能か。ヒューマン・タスクと例外管理は、BPM の正常な実装に重要であり、選択された BPM プラットフォームがこれらをサポートすることを確認する必要があります。例えば、WebSphere Dynamic Process Edition では、(タイマーに基づいて) 自動的に、またはライブ・プロセスの場合は実行時に手動で、タスクの再割り当てを行うことができます。

アドバンスド・ケース・マネジメントと BPM

アドバンスド・ケース・マネジメント (または Dynamic Case Management) は、文書中心の BPM 製品を、もっと包括的なソリューションに発展させるものです。これには、エンタープライズ・コンテンツ管理 (ECM)、コンテンツ分析、コラボレーションとソーシャル・ソフトウェア、ビジネス・ルール、および BPM が含まれます。アドバンスド・ケース・マネジメント (ACM) の背景にある発想は、これらの機能ごとに個別の製品は、1 つのソリューションに統合される場合であっても、「ケース (業務案件)」のニーズを満たさないので、業務案件とナレッジ・ワーカーという概念を中心にした新しい包括的な製品が必要であることです。

業務案件は、人が物理フォルダーに保持していたものと、このフォルダーに関連して実行したプロセスまたは手順です。例えば、業務案件は、患者の医療記録、保険金請求、年金加入手続き、またはクレジット・カードの紛争などです。図 6 で示されているように、必要なものは、業務案件を 360 度見渡す全体ビューです。

図 6. アドバンスド・ケース・マネジメント
アドバンスド・ケース・マネジメント
アドバンスド・ケース・マネジメント

ACM が有効であるのは、ナレッジ・ワーカー (業務案件担当者) の経験が、案件解決の効率的かつ最適な結果に一番重要である場合です。ACM にはビジネス・プロセスが関わり、文書の広範囲に及ぶ処理 (用紙フォーム、概要、許可、複写など)、厳密なガバナンスとコンプライアンス (監査証跡を含む)、高度な案件分析と報告、および案件を担当する人々の間のコラボレーションが必要です。BPM アプリケーションでは、ビジネス・プロセスがソリューションの中心にあり、ACM アプリケーションでは、ナレッジ・ワーカーと業務案件がソリューションの中心にあります。

他のセクションで説明されている大部分のベスト・プラクティス (ディスカバリー、モデリング、コラボレーション、自動化、頑強性など) が ACM に適用されることに注意してください。

BPM プロジェクトと同様に、業界固有の知識や、事前定義された出発点すなわち業務案件テンプレートを持つことで、ACM 実装の価値実現時間が大幅に短縮されます。業務案件テンプレートは、特定の業界およびビジネス領域からのベスト・プラクティスを収集します (例えば、教員免許、自動車保険請求、個々の銀行口座、または抵当権申請の業務案件テンプレート)。

IBM の ACM 製品である Case Manager は、業務案件アプリケーションを迅速に設計して、業務案件テンプレートから開始するか、インタビュー・モードで業務案件を作成することができます。業務案件ソリューションの定義により、業務案件に関するタスク (ビジネス・プロセス)、文書タイプ、役割、業務案件タイプなどの成果物の作成が可能になり、これらのすべてが、業務案件に関連した幅広い情報 (ビジネス・インテリジェンス) へのアクセスを可能にします。また、業務案件に関連したコンプライアンスの文書化が可能になります。さらに、IBM Case Manager は、業務案件の解決に必要な臨時のタスクまたはプロセスの作成にも対応します。

ACM ベース・ソリューションの主要コンポーネントは、ユーザー・インターフェースです。UI が適切であり、業務案件担当者に分かりやすいものであることを確認することが重要です。役割ベースのダッシュボードは、これに関して非常によく機能して、適切な業務案件情報に適切な時期にアクセスできるようにし、他の担当者とのコラボレーションと対話を可能にします。ウィジェットやマッシュアップなどの最新の UI テクノロジーを活用することで、必要なカスタマイズに対応します。

図 7. IBM のアドバンスド・ケース・マネジメント (ACM) ソリューションである Case Manager の機能
IBM のアドバンスド・ケース・マネジメント (ACM) ソリューションである Case Manager の機能
IBM のアドバンスド・ケース・マネジメント (ACM) ソリューションである Case Manager の機能

私は、ビジネス・プロセスに関連した紙の文書数を削減する (または完全になくす) ことを選択できるお客様と協力して、正確性の改善、コストの削減、処理時間の短縮を可能にしてきました。このアプローチは、IBM Forms などの電子フォーム・ソリューションでサポートされます。電子フォームは、視覚的に紙のフォームと同一にすることができます。

エンタープライズ・コンテンツ管理 (ECM) と BPM との間には、多くの統合点または類似点があります。これらの連携の背景にある中心の発想は、コンテンツをプロセス対応にし、プロセスをコンテンツ対応にすることです。この分野 (WebSphere Adapters for ECM など) では、最新の改善が行われました。例えば、生命保険の申し込みの場合、申込者に 3 つの文書 (健康診断の結果、信用報告書、および署名済みの申込書) を求めるとします。3 つのすべての文書が受領された後、自動的に引き受けプロセスを開始するように、ソリューションを設計できます。後の引き受けプロセス時に、保険業者は、担当するビジネス・タスクをダッシュボードから受け取ると、3 つのすべての文書にアクセスできます。図 8 は、IBM Case Manager が業務案件関連の文書にアクセスできるようにする方法を示しています。

図 8. IBM Case Manager における文書管理と BPM

継続的なプロセス最適化

継続的なプロセス最適化の採用シナリオは、非常に広範囲にわたります。実際に、継続的なプロセス最適化は、他の BPM アクティビティー (ディスカバリー、モデリング、自動化など) によってサポートされる包括的な目標と見なすこともできます。継続的なプロセス最適化には、頑強性と柔軟性の両方を備えた BPM ソリューションを使用した、ビジネス・プロセスの継続的な管理とモニター、改善の設計、およびプロセス・ステップの自動化が含まれます。このセクションでは、継続的なプロセス最適化の次の側面について簡単に説明します。

  • ビジネス・アクティビティーのモニター
  • プロセス自動化
  • ビジネス・ルール
  • ビジネス・イベント

ビジネス・アクティビティーのモニター

ビジネス・アクティビティー・モニタリング (BAM) は、運用データ (進行中のローン取り組みプロセス数や、所定の業務案件担当者のワークロードの内容) から、もっと高度なビジネス分析 (顧客需要動向の予測など) までにわたって、組織で何が起きているかをリアルタイムでビジネス・ユーザーが表示できるようにします。場合によっては、このトピックを「可視性と制御」と呼びます。一部の組織では、入り口点として始めにこれを調べることに意味があります。例えば、実際に毎週処理するローン申請数 (処理していると考えている数ではなく) を理解したり、クライアントに新製品を認可するのに要する時間や、特定の製品に必要な処理時間が増えるかどうか、およびその理由を知りたい場合があります。これを行うのは、自分が見たものに基づいてアクション (例えば、業務案件担当者間でのタスクの再割り当て、ボトルネックであった新規プロセスに関する、お客様の営業担当員の訓練、プロセスの各部の自動化など) を取りたいからです。ビジネス・プロセスのモデリングと自動化に時間と労力を費やしたその他の組織の場合は、BAM を使用して、これらの自動化されたビジネス・プロセスを把握して、制御できるようにすることに意味があります。

ビジネス・インテリジェンス (BI) は、幅広いデータ統合、ダッシュボード、スコアカード、分析およびレポートを提供します。そのため BI は必然的に BAM と BPM にリンクされます。これは、BAM が運用データや現状を表示する一方で、BI はもっと幅広い情報や、現在の状態が生じた理由に関する履歴分析を利用できるようにすることを見れば分かります。BI により、組織内の役割セット全体で標準化された詳細で最新の報告情報や、臨時の情報を取得できるので、必要に応じて新しいレポートを作成できます。BI を使用すると、プロセスの改善や最終的には最適化を実現するために、「what if」シナリオを調査するシミュレーションを実行するベースとして、分析を実行して問題の理由を理解する (根本原因分析) ことができます。

では、BI と BPM はどのように関連しているでしょうか。これは、次の 2 つの観点から調べることができます。

  • ビジネス・プロセスを実行するときに、どのビジネス・インテリジェンスが必要であるか
  • 特定のビジネス・インテリジェンスに基づいて、どのプロセスを開始すべきか

最初の観点は、意思決定の改善に関するものであり、業務案件担当者が必要なとき (例えば、ビジネス・プロセス・インスタンスからタスクが割り当てられたとき) に関連情報にアクセスできることを確認します。WebSphere Business Monitor (BAM コンポーネント) では、BAM ダッシュボードの一部として Cognos (BI コンポーネント) レポートを表示できます。

2 番目の観点では、アクションを自動化し、標準化して、ビジネス状況に素早く対応します。例えば、特定のイベントに基づいて、Cognos は、WebSphere Process Server で実行中のプロセスを自動的に呼び出して、Cognos からの関連ビジネス・データを渡すことができます。BI の詳細については、情報源の IBM Cognos を参照してください。

プロセス自動化

プロセス自動化は、BPM 実装の主要コンポーネントです。プロセス自動化は、品質と正確性 (ヒューマン・ファクターを減らすことによってエラー率を下げます)、意思決定の速度、および生産性の改善 (ユーザーの関与を減らすと、タスクの完了に要する時間が短くなります) を実現します。プロセス自動化には、ビジネス・プロセス (ビジネス機能) の中で自動化できる部分の識別が必要です。ビジネス・タスクがサービスとして自動化された後、そのサービスは他のビジネス・プロセスで再利用できます。その結果、作成または管理するリソース数が減ります。

これには、サービス指向アーキテクチャー (SOA) が必然的に適用されます。SOA イニシアチブには、一般に何らかのレベルのプロセス自動化が含まれます。トップダウン SOA アプローチは、ビジネス・プロセスを分解し (レベル 1、レベル 2 のサブプロセス、レベル 3 のサブサブプロセス)、自動化されたビジネス機能にとって意味がある細分性レベルをもたらします。これらの機能を提供するサービスの開発は、プロセス自動化に不可欠です。IBM は、この全体的な BPM 指向のアプローチを、Smart SOA 対応 BPM と呼びます。これは、プロセス自動化のコンテキストで最も適しています。主なステップは、ビジネス・プロセスの自動化に必要なサービスの識別、(署名を伴う操作を含む) サービスごとの明確な記述と安定したインターフェースの作成、およびこれらの個々のサービスのライフサイクルの作成と管理であり、それぞれのステップとターゲット・ビジネス・プロセスとの関係が明確に記述されていることを確実にします。サービスの識別と実装について詳しくは、情報源で Service Oriented Modeling and Architecture (SOMA)を参照してください。

大部分のビジネスは、実績のあるレガシー・システムでサポートされています。メインフレームで実行する COBOL アプリケーション、iSeries で実行する RPG アプリケーション、またはクライアント/サーバーもしくは仮想 IT 環境で実行する分散 Java™ Enterprise Edition (JEE) または .NET アプリケーションです。BPM プロジェクトは独立して作動することはなく、BPM ソリューションは何らかの形でこれらの既存システムと統合する必要があります。これらの既存システム (ユーザー自身のものまたはビジネス・パートナーのもの) を BPM ソリューションで活用できることを確認する必要があります。場合によっては、このドメインを「接続性」と呼びます。BPM プラットフォームが接続性機能を活用できることが重要です。BPM ソリューションのアーキテクチャーの考慮事項では、これについて、および SOA の働きについて詳しく説明します。プロセス (Business Process Execution Language (BPEL) など) やサービスの技術的な実装と、これらのバックエンド・システムとの統合を可能にするツールが必要です。WebSphere Integration Developer は、BPEL、Service Component Architecture (SCA) コンポーネントおよびメディエーション (メディエーションは、利用者とプロバイダーとの間の接続を可能にします) の実装に使用されるツールです。

ビジネス・ルール

ビジネス・ルールと BPM は関連しています。私は、現在ビジネス・ルールのユーザーである組織が BPM の実行を希望していたり、その逆である組織を数多く見てきました。これは良いことです。ビジネス・ルールは、アプリケーション・コード内部の奥深くや、単に対象分野の専門家の頭の中などの、どこにでもあります。図 9 に示されているように、WebSphere ILOG JRules のようなビジネス・ルール管理システム (BRMS) を使用すると、これらのルールを中央で管理できます。

図 9. WebSphere ILOG JRules:BRMS
WebSphere ILOG JRules:BRMS
WebSphere ILOG JRules:BRMS

ビジネス・ルールは、チェックリスト、妥当性検査、ルーティングなどの自動化に使用されます。条件 (if、then、else) として表示できるものはすべて、ビジネス・ルールにすることができます。図 10 は、行政機関 (年金) に関連したビジネス・ルールの例を示しています。ビジネス・ルールの長所は、非技術系のビジネス・アナリスト (または開発者) が、それらを理解し、変更できることです。ビジネス・ルールは自然言語 (英語など) で表示され、ルール内の特定の値を (厳密なガバナンスやアクセス制御の下で) 変更できます。例えば、図 10 に示されているルールでは、ビジネス・アナリストには、Service Years の値を 10 から 12 に変更する権限が与えられています。

図 10. ビジネス・ルールの例
ビジネス・ルールの例
ビジネス・ルールの例

BPM の観点から見ると、ビジネス・ルールは「意思決定サービス」と呼ばれます。ビジネス・プロセス内の特定のステップでは、ビジネス・ルールを開始 (実行) し、ルールの実行結果に基づいて、次の手順 (次に進むビジネス・プロセスのブランチ) を自動的に決定します。例えば、Educator Certification ビジネス・プロセスの一環として、意思決定サービス (ビジネス・ルール) を呼び出すことができます。このサービスは、申込者が認定テストを受ける要件を満たしているかどうかを自動的に判別します。満たしている場合、プロセスは「テスト分岐」(教師がテストを受ける) に進みます。満たしていない場合、不足している内容に基づいて、プロセスは別のブランチ (申込者の経歴確認など) に進みます。

ビジネス・ルールは、ビジネスに機敏性を実現する要因の例であり、柔軟な BPM ソリューションを可能にします。その他の柔軟性の側面も重要です。例えば、BPM ソリューションは、例外を管理し、未完了プロセス・インスタンスを (再デプロイメントなしに) 変更できるようにする必要があります。例えば、ライブ・プロセス・インスタンス内でのステップのスキップや後方ジャンプなどです。BPM のこの動的な側面が重要であり、WebSphere Dynamic Process Edition の中心です。

ビジネス・イベント

ビジネス・イベント処理 (BEP) (場合によっては、複合イベント処理 (CEP) と呼ばれます) は、BPM およびビジネス・ルールの概念と厳密に合致しています。お勧めの BEP 例は次のとおりです (BEP に詳しい場合は、この例をスキップしてください)。クレジット・カードが、カナダのトロントの店舗で東部標準時午前 8 時に使用されました。これが 1 つのイベントです。クレジット・カードが、日本の東京の店舗で東部標準時午前 8 時 1 分に使用されました。これがもう 1 つのイベントです。個々には、これらのイベントは重要ではありません。しかし、BEP に基づいて何らかの相互関連付けを行うと、不正行為の可能性を検出できます。その他のタイプのイベントもあります。例えば、既存のお客様の 1 人が Web サイトにアクセスし、まだ注文していない製品の製品説明を表示する回数を調べます。これが数回発生した後、その製品についてお客様に連絡し、販売促進を行うことができます。さらに、ビジネス・イベントをビジネス・プロセス自体によって生成することもでき、イベントの有無をモニターすることもできます。

BEP は、イベントまたはビジネスの状態を検出し、分析し、相互に関連付けて、人やシステムにアクションを取るように通知します。次の問題は、ビジネス・イベントが検出されたときに何が起きなければならないかです。イベントに応答して取らなければならないアクションを自動化できると想像してみてください。例えば、新製品に興味を示す既存のお客様の場合、お客様が 3 回目に製品説明を表示した直後に、販売促進のオファーを電子メールで自動的に送信できます。検出されたイベントに応答してビジネス・プロセスまたはビジネス・ルールを自動的に呼び出す実装環境を想像してみてください。これはまさに、図 11 で示されるように、BEP と BRMS を一緒に提供する IBM WebSphere Decision Server が実現するものです。

図 11. WebSphere Decision Server - BEP と BRMS の連携
WebSphere Decision Server - BEP と BRMS の連携
WebSphere Decision Server - BEP と BRMS の連携

BPM ソリューションのアーキテクチャーの考慮事項

BPM 実装環境は、サービス品質や非機能要件 (保全性、パフォーマンス、スケーラビリティー、可用性、セキュリティーなど) をサポートする必要があります。これを実現するために、BPM 実装環境は、堅固な BPM プラットフォームで構築されなければなりません。ここでは、アーキテクチャーが最も重要です。BPM プラットフォームを使用して非機能要件に対処する方法を理解している強力な設計者と協働することをお勧めします。例えば、BPM ベースのソリューションが 99% の時間、使用可能であることを確実にするにはどのようにしますか。ビジネス・プロセスで使用されるデータが、全体で正常であり、安全であることを確実にするには、どのようにしますか。使用量が変化するにつれてソリューションを拡大 (または縮小) できることを確実にするには、どのようにしますか。これらの問題は新しい問題ではなく、BPM のみに関連したものでないことは明らかです。非機能要件のサポートのこうした必要性に対する IBM の対応は、SOA やインフラストラクチャーなどのもっと多くの基本的な機能に基づいて BPM プラットフォームを作成することです。これを、Smart SOA 対応 BPM と呼びます (図 12 を参照)。これについて詳しくは、 情報源で BPM、SOA、および Enterprise Architecture 間の協同に関する記事を参照してください。

図 12. Smart SOA 対応 BPM (小売の例)
Smart SOA 対応 BPM (小売の例)
Smart SOA 対応 BPM (小売の例)

アーキテクチャー・スタイルの 1 つである SOA は、他の IT イニシアチブ (BPM など) のサポートに常に使用されなければなりません。例えば、BPM ベースのソリューションは、サービス指向アーキテクチャーのセキュリティーと接続性のコンポーネントを活用できます。一例として、スケーラビリティーの要件について考えてみましょう。IBM BPM 製品は、クラスタリングをサポートする WebSphere Application Server Network Deployment 上に構築されています。したがって、拡張が容易なソリューションの実装が可能です。

SOA スタイルのソフトウェア・アーキテクチャーと開発は、BPM 実装に必須ではありませんが、この 2 つの技法を組み合わせると、機敏性を最大化するだけでなく、ソフトウェアの再使用、内部通信と外部通信、および共同ガバナンス (基幹業務および IT 管理やスタッフを含めて) も最大化します。

一般に、実績のあるプラクティスやトポロジー (例えば、WebSphere BPM V7 Production Topologies で説明されているもの) に従って、価値を実現する必要があります (情報源を参照)。

プロセスの保全性は常に、IBM BPM ストラテジーの中心にあります。プロセスの保全性は、コンプライアンスや規制の要件を満たすのに必要です。プロセスが設計どおりに実行されていることを確実にする必要があります。課題は、個々のトランザクションの保全性 (トランザクションが一回だけ行われたことを確認すること) について論じていないことです。むしろ、エンドツーエンドのビジネス・プロセスの保全性について論じています。これは、内部と外部の両方で複数の組織やシステムにまたがり、非常に長期間実行できるので、補正のようなメカニズムがさらに複雑になります。補正や整合性は、プロセス保全性の主な要素であり、システムが任意の時点で整合性があることを確認します。これは、プロセスが完全に実行されたかどうかや、プロセスが完了できず、ロールバックが必要かどうかに関係ありません。IBM BPM プロセスの保全性は、BPM をサポートする基礎プラットフォーム上の特定の BPM 機能 (接続性、メッセージング、セキュリティーなど) によって実現されます。

BPM Center of Excellence (COE) は、企業内とプロジェクト間で BPM イニシアチブを成功させる主な要因です。BPM 方式は (ビジネスと IT 間の対話があり、反復するモデル駆動型のアプローチであるという点で) 異なり、ビジネス・プロセスは通常、複数のドメインにまたがるため、COE は BPM にとって重要です。BPM COE は、BPM プロジェクトで役割を果たすすべての人が、役割ごとに何を実行しなければならないか、なぜこの方法で実行しなければならないかを確実に認識するのに役立ちます。BPM COE は、組織内のさまざまなグループが従う標準や手順を設定し、BPM の知識を進行中のプロジェクトに移し、ガバナンス・モデル (ポリシー、プロセス、メトリックを含む) を定義します。BPM COE のセットアップに関連した主なアクティビティーには、COE のミッションの定義、現在の BPM の成熟度の理解、BPM の役割とスキルの定義、および COE 構造とメカニズムの定義があります。BPM COE の推奨事項は実施可能であることが必要です。我々は「BPM COE には実効性が必要だ」とよく言います。標準に従い、手順を踏むのでなければ、標準や手順を定義しても意味がありません。メトリック、インセンティブ・モデルやその他の技法は、BPM COE の成功に役立ちます。

結論

この記事では、BPM 実装のユースケースを、ユーザー採用シナリオ (ビジネス主導ディスカバリー、対話とコラボレーション、および継続的なプロセス最適化) で分類し、説明しました。これらのシナリオを理解すると、組織は、実装する組織に最も適切で有利な BPM の側面に集中することができます。前述のように、これらのアプローチは互いに矛盾するものではありません。例えば、私は、ビジネス主導ディスカバリー・シナリオが重要であったお客様 (ビジネスを新しい国々に展開するために、標準化されたプロセスに対するニーズがあるプロジェクトのごく初期から関わっていた基幹業務ユーザー) に協力してきました。また、進行中のビジネス目標をサポートするために継続的なプロセス最適化が重要であったお客様 (ビジネス・プロセスで必要な機能を提供するために、IT アプリケーションを活用しなければならなかった) にも協力してきました。

BPM の採用は、パラダイムのシフトを伴い、実装する組織にあまりなじみのないプラクティスを使用する必要があります。BPM には、従来の IT プロジェクトとは異なる方法で価値を実現し、IT プロジェクトを実装することが必要です。成功するお客様は、ビジネス・ユーザーと IT ユーザーとの間の頻繁なコラボレーションを含めて、頻繁なマイルストーンや定期的なレビューを伴う反復開発アプローチを採用します。また、BPM の採用には、すぐには利用できないスキルが必要な場合もあります。例えば、経験を積んだビジネス・アナリストは、多くの場合、不足しています。

それにもかかわらず、BPM イニシアチブで成功を収めた組織は、共通の特性を備えています。第一は、彼らは、IBM BlueWorks Live などの、投資の少ない低リスク・ソリューションの使用から始めて、BPM を十分に理解しました。次に、分析を実行して、現行の成熟度レベル (スキルやプラットフォームなど) や BPM に対する要求 (求めるレベルや、いつでも取り掛かれる労力の量) も理解しました。その結果、重視する初期のプロセス領域を識別できたので、その領域における価値を実現すると同時に、この記事に記載されている 1 つ以上の採用シナリオを使用して、BPM 機能の基盤を築くことができました。ところが、彼らは最初のプロジェクトの後で終わりにしませんでした。それどころか、BPM のビジョンを実現するためにプロジェクトをどのように使用するかについて、詳細なプランやロードマップを持っています。また、成功した組織は、自分自身でできることは何か、どこでヘルプが必要か (例えば、組織内の BPM スキルがないため、IBM のような戦略的パートナーと契約するのが妥当な時点) についても非常に明確でした。

組織の目的に合った BPM ソリューション、必要な機能 (ビジネス・ルールや文書管理など) を提供する BPM ソリューション、組織で効率よく実装し、デプロイできる BPM ソリューションがあります。IBM のプロセス改善ディスカバリー・ワークショップは、3 日間の無料ワークショップです。このワークショップでは、組織にとって BPM が適用可能かどうかを調べ、最適な出発点 (例えば、この記事で説明しているシナリオの 1 つ) を評価し、BPM イニシアチブのビジネス・インパクトを理解し、BPM ソリューション・アーキテクチャーのベースラインを定義します。つまり、このワークショップは、BPM の「目的に適した」ソリューションのベースラインを定義します。このワークショップについて詳しくは、情報源を参照してください。

謝辞

この記事は、BPM の取り組みから集められた経験や、これらの経験から得られたベスト・プラクティスがなければ、実現しませんでした。BPM の専門知識を共有し、この記事の発行を可能にしていただいたことについて、お客様、IBM の同僚やビジネス・パートナー様に感謝します。この記事に記述されたトピックは、私が定義したのではなく、単に専門家から集めたものを、包括的な文書で解説しただけです。具体的には、この記事をレビューし、文書の草案を正確で読みやすい記事にするのを手伝ってくれた同僚の皆さん、Pete Melrose、Scott Simmons、Lee Ackerman、Claus Jensen、Stuart Jones、Eric Herness、Rob High、および David Gomez, Jr に感謝します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=658093
ArticleTitle=ビジネス・プロセス・マネジメントの採用シナリオ
publish-date=01192011