WebSphere Operational Decision Management 意思決定のパターンについて

ビジネス・ルール管理システムを導入する場合の作業として重要なのは、業務ルールを整理することです。業務ルールの整理には、どのような種類のルールに分類できるのかがポイントです。今回は、ルールのパターンについてご紹介します。

Pierre Berlandier (pberland@us.ibm.com), Senior Technical Staff Member, I.B.M.

Pierre Berlandier photoPierre Berlandier は15年に渡ってILOGサービスを担当しています。その間、数多くのILOGのお客様におけるエキスパート・システムやリアルタイム・インテリジェント・エージェントの領域のルール・プログラミング・パラダイム実装を成功へと導き、最近ではその領域をビジネス・ルール・アプリケーションへと拡大しています。


developerWorks 貢献著者レベル

2012年 3月 30日

はじめに

ビジネス・ルール管理システムは、アプリケーションから意思決定を抽出し、これらの意思決定を一元管理し、ビジネスに合わせて変更できるようにすることです。ここでは、意思決定にルールを分類する方法を説明します。意思決定の仕組みを理解することが、必要なビジネス・アジリティーを実現するためには大切な要因となります。

意思決定のアーティファクト

図1 意思決定のアーティファクト概要
図1 意思決定のアーティファクト概要

アプリケーションは意思決定リクエストにより、特定の意思決定をビジネス・ルール・管理システムに「アウトソーシング」できます。特定の「意思決定」を識別するために、それぞれの意思決定はルール・セット ID とともに渡されることで識別されます。その際、アプリケーションは意思決定のコンテキストと、意思決定の対象となるオブジェクト情報も一緒に渡します。

オブジェクト情報 (XOM: 実行オブジェクトモデル) はビジネス・ルール管理システム内で、意思決定プロセスを表現するルールで使用される語彙 (BOM: ビジネス・オブジェクト・モデル) に変換されます。意思決定リクエストを受取ると、その情報はルール・フロー (ルール・セットに対して定義されたフロー) により、定義済みの各種のルールにルーティングされます。ビジネス・ルール管理システムには、意思決定を行うために使用できるビジネス・ルール、意思決定表、意思決定ツリーが用意されています。このすべてを、アプリケーションまたはソリューションのニーズに合わせて使用することができます。

意思決定レスポンスは、意思決定によって更新された情報、または新しく提供された情報と一緒にアプリケーションに返されます。これらの情報はアプリケーションに返される前に、アプリケーションが理解できる形に変換されます。

次の章では、ソリューションおよびアプリケーションが意思決定を行うために分類される標準的なパターンについて説明します。


検証パターン

最も基本的なパターンは、参照可能な情報に基づく「決行または中止」の意思決定です。検証パターンでは、アプリケーションのプロセスまたはトランザクションを続行可能な場合の条件を定義するポリシーを設定できます。
ポリシーの例には、前述のシナリオでの適格性ルールおよび検証ルールが挙げられます。ガバナンスおよびライフサイクル管理も、成果物をそのライフサイクルの次の段階に進められるかどうかを決定するために、検証パターンを使用して、すべてのアクティビティーが完了されて必要な情報が揃っていることを確認できます。

図2 検証パターン
図2 検証パターン

ビジネス・ルールを使用して、オブジェクト情報に含まれる主要な基準を基に、拒否の意思決定をしなければならない特定の状況を識別できます。また、意思決定を説明する理由として、ビジネス・ルールをアプリケーションに渡すこともできます。
この理由は、人間が関与する場合には重要です。なぜなら、理由によって意思決定が説明され、次回に望ましい行動をとりやすくなるためです。状況によっては、拒否の意思決定が行われた場合に取るべき是正措置も識別することが有利な手法となることもあります。

決定表では、複雑な条件を表形式にすることができます。この表では実質的に、さまざまな基準の組合わせを範囲として、許容する場合の条件、または拒否する場合の条件を定義できます。ルールを使用する利点の1つは、リスクとパターンについての理解が深まるにつれ、より正確な意思決定を行えるようになることです。このように意思決定を改良する場合には、意思決定ツリーを使用することもできます。意思決定ツリーを使用して、まず始めに明白な意思決定を行ってから、使用する情報を徐々に増やして意思決定の精度を上げるという方法です。


データ補完パターン

異種混合のソリューションに伴う問題の1つは、情報の表現を処理する方法がアプリケーションによって異なることです。場合によっては、あるアプリケーションに必要な情報がそのアプリケーションに直接提供されないことや、クライアント・アプリケーションから提供される情報の形式が適切でないことがあります。また、個々のアプリケーションが異なる方法で情報を生成する場合もあります。データ補完パターンでは、ルールを使用することによって、体系的かつ管理可能な方法で必要情報を補完します。このパターンの一例は、自動車保険のグループ情報です。グループは車両のメーカーとモデルによって分類されています。データ補完パターンの重要な価値は、グループ情報をさまざまな情報源から導き出す一貫性のある管理された方法を提供することです。

図3 データ補完パターン
図3 データ補完パターン

最も単純な形では、ビジネス・ルールを用いて欠落した情報を導きだすための条件とアクションを定義できます。また、複数の要因 (例えば、排気量、車種、自動車の安全機構など) を検討する場合には、意思決定を適用することもできます。


分類パターン

ソリューションでよく使われるパターンには、分類、領域、および列挙のパターンもあります。このパターンで識別するのは、既知の状況または情報のクラスです。分類システムまたは分類法は、ビジネスが現在把握している、起こりうる状況を反映します。ルールはこれらの状況に対してオブジェクト情報を突き合わせ、最適なオブジェクト情報を選択します。前述のシナリオでは、組織および製品の適合性を示す見積もり分類システムを基にしてルーティングを行うことが考えられます。その場合、分類応答を基に、その分類に適切な供給者にメッセージをルーティングできます。

この手法は、分類することができない未知の状況または情報を識別するためにも使用されてきました。例えば、故障の識別では、特定の情報の組み合わせが認識されると、故障のクラスを自動的に診断して、解決のプロセスを設定できます。故障を分類できない場合には、手動によるルーティングによって、その故障を診断するプロセスを行わなければなりません。このタスクが完了し、新しいソリューションが提供された後、この新しい分類をルールに追加すれば、以降に発生した同じ障害を自動的に解決できるようになります。

図4 分類パターン
図4 分類パターン

これまで説明したパターンと同じく、分類パターンでもルールと意思決定表を使用して、特定の情報パターンを基に情報のクラスを識別できます。分類は一般的に階層型であることから、意思決定ツリーを使用して、最初に粗いレベルで分類し、後続に進むにつれて、より詳細なサブレベルの分類を行うことが可能です。


計算パターン

必要となる (そして市場に合わせて動的に変更しなければならない) ビジネス意思決定の多くは、価格、利幅、スケジュールなどの基準と関連します。これらの情報と、検討対象のオブジェクト、そして検討する際に適用する背景との間には複雑な関係があります。例えば、保険料の設定ルールを考えてみてください。この場合、ルールの基準となるのは、保険が適用される自動車とその自動車のドライバーです。また、ルールには、実施中の販売促進に応じた割引も適用しなければなりません。意思決定の結果として生成されることになるのは、当初の意思決定要求に含まれるオブジェクトと関連する、新しい情報オブジェクトです。自動車保険の場合のルールは、図5に示すようにドライバーと自動車の組み合わせに対する見積もりのリストを提供します。

図5 計算パターン
図5 計算パターン

この汎用パターンは、ビジネス・ルール、意思決定表、そして意思決定ツリーのあらゆる側面を利用するために、さまざまな方法で使用できます。複雑な意思決定プロセスでは、フローを設計するステップが必要になる場合もあります。フローによって、最初に (意思決定ツリーを使用して) 料金設定ポリシーを決定し、それから選択されたポリシー・ルールを適用できるようにするためです。このようにすれば、料金設定に関する戦略を、料金設定ポリシーの個々のルールの詳細から切り離すことができます。


スコアリング・選択パターン

これまでのセクションで説明したパターンは、単一の背景でオブジェクトに関する意思決定を行うというものでしたが、それとは別のタイプのパターンもあります。それは、アプリケーションにある複数のオプションから選択しなければならないパターンです。このパターンの例は、ルーティングの選択、ベンダーの選択、プロバイダーの選択などに関して数多く存在します。例えば、さまざまなプロバイダーのサービス・パフォーマンスに基づいてルーティングを選択するなどです。

リソースのオプションがトランザクションの一環としてルール・エンジンに渡される場合には、このパターンを使用してリソースを最適化することもできます。つまり、各オプションにコスト関数を基準としてランクを付け、相対スコアに応じて、最も大きい値を持つ最もコストの低いオプションが選択されるようにするという仕組みです。

図6 スコアリング・選択パターン
図6 スコアリング・選択パターン

オプションの選択を「必要」とするアプリケーションまたはソリューションは、評価対象のオプション (プロバイダーの状況) のリストおよび内容(見積もり要求) を併せてパッケージ化します。各オプションがルールに渡されると、ルールは機会とコストに基づくスコア、そして評価対象のビジネスに適切なリスク判定基準を設定します。これらのオプションとそれぞれのスコアのセットをアプリケーションに渡せば、アプリケーションがスコアに応じてオプションを選択できます。

この手法では、基本的な選択の意思決定ロジックはアプリケーションに維持しながらも、時間とともに進化する管理された一貫性のあるルールによって、意思決定の結果を変更できます。新しいオプションが選択可能になる (新しいサービス・プロバイダーが使用可能になる) たびに、選択ポリシーをすぐに、そして一貫して適用することができます。


メッセージ変換パターン

エンタープライズ・アプリケーション・インテグレーション (EAI) ミドルウェアには、情報をある表現から別の表現に変換するためのコネクターが用意されています。ほとんどの場合、この変換はメッセージ構造に対して定義された情報アーキテクチャーまたはスキーマに基づいて行われます。最近のソリューションにはさまざまな標準 (そしてそれらの標準の複数のバージョン) を使用する異種混合のアプリケーションが関与するようになってきていることから、単に構造だけに基づいて変換することはできません。この状況に対処できるのが、ルールです。ルールでは、情報のコンテンツだけでなく、構造も使用して変換を定義できます。これまで説明したパターンと組み合わせると、情報を検証して企業全体でより一貫性を持たせることができるため、誤った解釈を減らし、相互運用性を改善することができます。

図7 メッセージ変換パターン
図7 メッセージ変換パターン

例えば、医療情報の ICD-101 メッセージのような多数のコンポーネントで構成されるメッセージが対話の一環として到着した場合を考えてみてください。既存のソリューションには、このメッセージに別の表現 (例えば ICD-9 フォーマットなど) が必要だとします。しかしながら、ICD-10 から ICD-9 へのマッピングは固有ではありません。その場合、ルールを使用すれば、推奨される変換と、実際のコードのマッピングを識別するための意思決定表を特定できます。したがって、ICD-9 フォーマットのオブジェクトを既存のソリューションで使用できることになります。

実際には、構造変換はそれほど頻繁に変更する必要がないため、既存の変換コネクターと拡張機能で上手く対処できます。
ただし、ルールを使用すれば、コネクターを再デプロイすることなく、マッピング・コードを変換するだけで、推奨されるコード変換の変更に対応できます。


まとめ

意思決定のパターン分類は、ビジネス・ルール管理システムの導入時に行われるルールの抽出作業の中で、ルールを整理するという意味でとても重要な作業です。
適用する業務によっても存在する意思決定のパターンは異なります。抽出された意思決定がどのパターンに分類されるのかを分析することで、ルール・プロジェクトの構造の決定の要因となり、ルール・フローによる順序付けに役立ちます。
今回ご紹介したパターン以外にも、意思決定のパターンは存在します。ルールの設計の段階で、ルールの整理、パターン分けを行うことは、そのプロジェクトを成功に導く鍵となります。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=807083
ArticleTitle=WebSphere Operational Decision Management 意思決定のパターンについて
publish-date=03302012