BPMS/BRMSを用いた設計③

m.fukasawa

前回(保険会社の請求処理におけるビジネスフローとビジネスルール)の続きです。具体的な例を挙げてご説明していきましょう。

 

まずは、保険会社の請求処理の流れをビジネスフローとして登録します。ビジネスフローのタスクごとに、どのようなビシネスルールの適用を図っていくかを管理するシステムがあります。たとえば、失効処理において約款では、月払と年払では異なる処理となります。団体扱と個人扱と口座振替扱でも処理が異なります。しかも団体扱いでは、請求の事務取扱マニュアルで、自動に行うのではなく、手動で必ず確認することとなっている団体もあります。失効処理のビシネスルールにも、いろいろなパターンがとあることになります。そのビジネスルールを反映させたもの単位に登録を行います。ビジネスフローを管理する仕組み、個々のビジネスルールを呼出す仕組み、それとビジネスルール単位に作りだされたプログラムこれらをどのように組み合わせるかを考えました。実際にどのように考えたかを示しましょう。

デシジョンテーブル
(表1をクリックして拡大する)

失効処理をデシジョンテーブルで表す

A1、B1、C1、D1、E1、F1、G1は、ビシネスルールを実際に動かすプログラムです。団体月払いは、A1、B1、C1、D1、E1、F1、G1というように処理が進んでいきます。個人Ⅰは、A2、B1、C1、処理パス、E3、処理パス、G3というように処理が進んで行きます(表1)。

ルールの変更要件
(表2をクリックして拡大する)

ルール変更要件を加える

さてここで、個人処理の中で、失効処理のみA3というルールが加わった処理を個人Ⅱとして追加します。それ以外の処理は個人Ⅰと同じだとします。処理テーブルに個人Ⅱという処理グループが付け加えられ、失効処理にA3という処理がつけ加えらます。前の請求処理が登録されるものは、独立して変更はありません。非常に容易に新しい処理が付け加えらます(表2)。しかも個人処理Ⅱは、失効の処理以外は個人処理Ⅰのコピーです。図で示すと随分簡単そうに見えますが、実際にはビジネスルールの解析から始めなければなりませんでした。その当時、3000団体もの数があり、1つ1つの団体ごとに請求処理の分析をしました。ビジネスルールの解析は、ユーザーが主体として動きました。その結果をプログラムを行う人が理解できるものでなければなりません。分析結果の資料は、ユーザとシステムが理解できる仕様書でなければなりません。

デシジョンツリー
(表3をクリックして拡大する)

デシジョンツリーで分析する

これをデシジョンツリーで記述することにしました(表3)。表は個人の失効処理デシションツリーです。処理Noに条件文をつけ、最後にアクションNoと行動を書く。このデシションツリを見て、プログラムチームの人たちが工夫してくれたことがあります。トレース機能を付けてくれたことです。トレースと指定すると、処理NoやアクションNoが表示されるのです。どの処理を通ってきたかすぐわかるようになりました。トラブルのとき、データさえわかれば、トレース機能で処理手順がわかるのですごく重宝しました。現在の保守作業にかかわっている人に聞き機会がありましたので、デシションツリーのことを聞きました所、使用していないとのことでした。あるのは、従来のプログラム仕様書のみ。どこを直したか、なぜ直したのか管理するのに大変だと思いますが。

 

(深澤満)

深澤満氏は、当社のパートナー企業のコンサルタントです。BPMSとBRMSを活用したシステム設計に関する特別連載Blogを寄稿していただくことになりました。