ビジネスマンのためのビジネスルール入門⑳

k.shirai

意思決定の要件定義(もしくは要求開発)のアプローチの続きです。前回は、意思決定を必要とするタスクにおける最上位の意思決定の属性の定義について触れました。それは、その意思決定に関する固有の質問と可能な回答のセットビジネスコンテキスト(重要パフォーマンス指標、意思決定ロジックを管理する部門、実行する部門、影響を受ける利害関係者など)でした。次のステップは、この意思決定の構造を分解することです。

意思決定要件ダイアグラム
(図をクリックして拡大)

最上位の意思決定を説明する

前回のおさらいを兼ねて、非常にシンプルな例で説明していきましょう。B2Bの大口注文に対する受付プロセスを考えてみます。最初に発注企業からの注文データを収集した後、注文の適格性を判定するというタスクが次に実行されます。このタスクは、典型的なデシジョンタスクです(判定はデシジョンワードです)。したがって、適格性の判定という意思決定ノードをそのタスクの直下に置いて点線で結びます。ここからは、ビジネスユーザーとのファシリティセッションを通じて、意思決定要件を明確にしていくことになります。まずは、前回ご説明したように、その意思決定に関する質問と可能な回答を明確にします。前者は「この大口注文は、受け入れ可能だろうか?」、後者は「はい/いいえ」のようなものになるでしょう。ビジネスコンテキストも明確にしておきます。

 

インプット情報を明確にする

次に「その意思決定をするために必要なインプット情報は何ですか?」と質問します。ビジネスユーザーは「注文情報と取引リスクの2つが必要だね」と回答します。ここで重要なのは、インプット情報には取引データ履歴データのようなインプットだけでなく、他の意思決定のアウトプットが含まれる場合があることです。したがって、それを確認するために「注文情報と取引リスクという2つの種類のインプット情報は、どこから取得されるのですか?」と質問します。ビジネスユーザーは「前者は最初のタスクで入手されるものだし、後者は取引リスクの判定結果だね」と回答します。つまり、この取引リスクの判定結果というのは、他の意思決定のアウトプットとなるわけです。

 

ビジネス知識と知識ソースを明確にする

続けて「その意思決定に必要なビジネス知識は定義されていますか?」と質問します。ビジネスユーザーは「適格性判定ルールというスプレッドシートで管理しているよ」と回答します。さらに「その適格性ルールの拠り所となるものは何ですか?」と質問します。「大口取引ガイドラインという業務方針書で決められているよ」という回答が返ってくるでしょう。

 

意思決定要件をダイアグラムで描写する

このような問答を繰り返すことによって完成されたものが、図のような意思決定要件ダイアグラム(DRD)であり、その意思決定に関する本質的な構造となります。この中で、実際にBRMSで実装されるビジネス知識は、適格性判定ルールリスクスコアとなりますが、意思決定要件フェーズにおいてはその存在を確認するだけで十分です。もちろん、ビジネスユーザーが用意してくれているならば、後のフェーズにために大切に保管しておきます。

 

(マーケティング担当:白井)

次のBlog

このブログは、弊社が提供するトレーニングコース「BRMS入門」からの抜粋です。ご関心のある方は、こちらをご覧ください。