意思決定モデリングの基本

ビジネスの専門家は、ビジネスに関する意思決定に適用するためにクライアント・アプリケーションが呼び出す意思決定サービスをモデル化し、定義して、デプロイできます。

Decision Center で意思決定サービスを作成し、それを実行環境に配布します。 次の図に示すように、クライアント・アプリケーションは意思決定サービスを呼び出してデータを処理します。

Diaram は、コンポーネント間の相互作用を示します。

Decision Centerでは、次の 2 つの方法で意思決定サービスを作成できます。
  1. 開発チームが基礎となるモデルを作成し、このモデルを使用して意思決定ロジックを作成します。
  2. 意思決定モデル・サービスでモデルとロジックを作成します。
このトピックでは、意思決定モデル・サービスの作成に関する以下の 2 つの側面について説明します。
  • ノード構造のモデリング
  • 意思決定ロジックのオーサリング
注: 分かりやすくするために、意思決定サービスという用語は、2 つのアプローチを区別する必要がある場合や、特に意思決定サービスのモデル化部分を参照する場合を除き、全体を通じて使用されます。

ノード構造のモデリング

顧客に挨拶して挨拶をする簡単な意思決定サービス (例えば、「こんばんはジョーンズ夫人」) について考えてみます。

意思決定サービスには、適切な挨拶を生成するための以下の情報が必要です。
  • お客様名
  • 希望する性別と学位
  • 時刻

以下のダイアグラムは、意思決定サービスをモデル化しています。

ダイアグラムは、データ・ノードと意思決定ノードを含むモデリング・ダイアグラムを示しています。

モデリングの観点から、意思決定のビジュアル表示と入力データの間の関係を作成して定義します。

ダイアグラムでは、これらのビジュアル表示はノードと呼ばれます。 以下の図は、Name データ・ノードによってフィードされる Salutation 意思決定ノードを示しています。

図は、Salutation ノードと Name ノードを示しています。

名前として Jones を指定した場合に意思決定サービスによって返される挨拶は、「Hello Jones」になります。

意思決定サービスのダイアグラムを理解して保守しやすくするために、意思決定ノードを他の意思決定ノードに依存させることができます。 例えば、時刻に基づく挨拶文を返すように意思決定サービスを詳細化するには、Hour を入力として使用する「Greeting」という別の意思決定ノードを作成し、その結果を Salutation ノードで使用できるように意思決定ノードをリンクします。

ダイアグラムは、意思決定サービス内のノードを示しています。

8PM に Jones という名前を指定した場合に意思決定サービスによって返される挨拶は、「こんばんはジョーンズ」になります。

敬称 (例: Mr.、婦人、Dr.) を追加するには、以下のようにします。 挨拶文をさらにパーソナライズするには、「Courtesy Title」という名前の意思決定ノードを作成し、2 つのデータ・ノードの性別と学位を使用してフィードします。 この意思決定ノードは、Greeting ノードのような最終意思決定ノードにフィードします。

ダイアグラムは、意思決定サービス内のノードを示しています。

8PM に性別ミセスを指定し、学位を持たない Jones を指定した場合に意思決定サービスによって返される挨拶文は、「こんばんはジョーンズ夫人」になります。

クライアント・アプリケーションがこの情報を提供すると、意思決定サービスはこのデータを処理して決定を返します。 モデリング部分を要約すると、以下のようになります。
  • 意思決定ノードとデータ・ノードを作成してリンクします。
  • 入力データを受け入れて、その上にあるノードまたはクライアント・アプリケーションに結果を出力するように、それぞれの意思決定ノードを設計します。 結果の取得方法については、以下の 意思決定ロジックのオーサリング セクションを参照してください。

データ・モデル

データ・モデル という用語は、意思決定モデルのさまざまなデータ・アスペクトを区別するために使用できます。

データ・ノードの作成に加え、データ・モデリングでは、すべてのノードに適切なタイプを割り当てる必要があります。 ノードにタイプを割り当てると、以下の詳細が指定されます。
  1. ノードが受け入れおよび送信できる情報 (例えば、数値や日付など)。
  2. 意思決定ロジックを作成する際の可能性。
以下の例では、さまざまなタイプの 4 つの異なるデータ・ノードが意思決定ノード Approval にフィードします。

ダイアグラムは、意思決定サービス内のノードを示しています。

この図では、4 つのデータ・ノードがフラットにレイアウトされています。 多くの場合、関連するデータを 1 つのエンティティーの下に再グループ化するカスタム・タイプを作成するとより便利です。 以下の図には、上記の図と同じ入力データが含まれていますが、ローンに関連するすべてのデータ・ノードは、カスタム・タイプ loanのデータを処理する 1 つのノードの下にグループ化されています。

ダイアグラムは、意思決定サービス内のノードを示しています。

データ・モデリングについて詳しくは、「 データ・モデリングの詳細: カスタム・タイプ、デフォルト値、リスト」トピックを参照してください。ここでは、データ・ノードに設定できるデフォルト値についても説明しています。

注: 以下の図に示すように、これまでに使用された例は単純です。 より複雑な意思決定サービスでは、複数の最上位の意思決定ノードを使用して、複数の意思決定をクライアント・アプリケーションに返すことができます。 また、1 つのデータ・ノードが複数の意思決定ノードにフィードする場合もあります。

ダイアグラムは、意思決定サービス内のノードを示しています。

意思決定ロジックのオーサリング

各意思決定ノードのロジックを作成するには、以下のプロセスを実行するための 1 つ以上の ビジネス・ルール を作成します。
  • それぞれの意思決定ノードが受信する入力データを、確立された条件に照らし合わせて評価する。
  • 意思決定ノードの出力、つまり決定を設定または変更するためのアクションを実行する。
これらのビジネス・ルールは、単に以下の形式で表されるビジネス・ポリシーであり、コンピューターによって理解されます。
if 
  <conditions>
then 
  <actions>

顧客が 18 歳未満で学生であるという条件に基づいて、顧客が学生割引を受ける資格があるかどうかを決定する意思決定サービスについて考えてみます。 意思決定モデルには、意思決定ノードの Student の割引にフィードする 2 つのデータ・ノード (Customer age と Category) があります。

ダイアグラムは、意思決定サービス内のノードを示しています。

スチューデント・ディスカウント・ノードの意思決定ロジックを実装するには、以下のビジネス・ルールを作成します。

イメージは、ルールを示しています。
この例では、ビジネス・ルールの内容を色分けして、ビジネス・ルールの作成時または変更時に自由に使用できるさまざまなビルディング・ブロックを示します。
  • オレンジの部分は、意思決定ノードで使用可能な入力データまたは出力データを表します。
  • グレーの部分は、意思決定ロジックの作成に関連するものとして識別されるデータ値を表します。
  • 残りは、さまざまなタイプのデータの比較、評価、および変更に使用されるモデリング言語自体に対応しています ( Decision Center モデリング言語リファレンスを参照)。

意思決定ノードによって処理されるデータ (その出力と、意思決定ノードに直接フィードするノードからのデータ) は、ビジネス・ルールを作成するときに、 'the <data>'の形式で即時に使用できます。 この例では、 Student discount は規則で 'the student discount'として使用でき、 Customer age は 'the customer age'として使用でき、 Category は 'the category'として使用できます。

この重要な点をさらに説明するために、新しいルールを作成するたびに、Decision Center は、ルールを作成する意思決定ノードへの入力として使用可能なデータを評価します。 それから、新規ルールの開始点として以下を提示します。
  1. タイプに従って入力データを比較する (if 部分での) 標準的な条件ステートメント。 ノードで使用可能なすべてのデータに対して条件ステートメントを提示しますが、すべてのルールがすべての入力データに同時に適用されるわけではないため、クリアすることができます。
  2. タイプに従ってノードの出力の値を設定する (then 部分の) アクション・ステートメント。

イメージは、エディター内のルールを示しています。

注: モデリング言語には、ビジネス・ルールを読みやすくする側面が含まれています。 例えば、意思決定というキーワードは、ノードの名前と互いに交換して使用できます。これは、例えば、レポートにおいてルールのこの重要な面を視覚的に特定するのに役立ちます。

カバレッジ

意思決定ノードを作成するときには、クライアント・アプリケーションが入力データとして提供する可能性があるケースの意思決定に到達するために必要なビジネス・ルールを作成します。 これは カバレッジと呼ばれます。 通常、意思決定では、可能な限り多くのケースをカバーするためにいくつかのビジネス・ルールが必要になります。

図は、複数の規則を含むノードを示しています。

提供された入力データに対して多くの条件が考えられる状況を処理するために、意思決定表を使用できます。意思決定表は、共通の構造を持つが、条件とアクションの値が異なるビジネス・ルールをグループ化します。 例えば、収入に基づいて給与スコアを設定するには、さまざまな収入範囲をカバーするために、多くのビジネス・ルールが必要です。 以下の意思決定表は、単純な方法でこれを処理します。

イメージは、意思決定表を示しています。

意思決定表の各行は、1 つの完全なビジネス・ルールを表しています。 左側の列には条件 (ルールの if 部分) が含まれ、右側の列にはルールによって返される意思決定が示されます。

意思決定ロジックには、完全な適応範囲を得るために 1 つ以上の意思決定表と複数のビジネス・ルールが必要な場合があります。 これらのケースでは、ルールがノードに表示される順序が重要であることに注意してください。