テックノート

テックノート>デジタルトランスフォーメーションのための超高速開発基盤! Vol.4

  • ルールベースAI/BRMS
2016.08.26

デジタルトランスフォーメーションのための超高速開発基盤! Vol.4

デジタルトランスフォーメーションのための超高速開発基盤! Vol.4

業務プロセスを可視化するための経営手法といえばBPMですが、思ったような成果が出なかったという評価も耳にします。BPMは業務プロセスの改善やイノベーションの糸口を見つけるために取り組むべきものですが、明確に目的を意識しないと、業務プロセスを表現するだけで終わってしまいます。今回の記事では、BPMを真に使える手段にするために、ビジネスルールアプローチがいかに有効かを説明します。(全5回連載)


Vol.4 BPMを成功させるためのビジネスルール分離 ― プロセスとビジネスルールの正しい関係とは

なぜビジネスプロセスをうまく描けないのか

ビジネスプロセスをモデル化する試みはなぜ失敗しやすいのでしょうか。プロセス図を作ることの意義は、業務をわかりやすく可視化し、改善点を見つけることにあります。ところが、ビジュアライズツールでプロセス図を作成するだけで満足し、その先に進まないというケースが非常に多く見受けられます。

これでは「プロセス図を作成すること」が目的になってしまい、BPMの本来の役割をまったく発揮できていません。ビジネスプロセスはタスク(手続き)の連なりで表されるものです。これをそのまま図に描いてみると、様々なポイントで分岐が必要になることがわかります。そして分岐点の前段には、ある条件(あるいは複合条件)に応じてその後のタスクを変えるプロセスが必ず存在します。

厳密には「判定する」ことはタスクですが、判定条件はタスクではありません。しかし、IT関係者の多くは慣れ親しんだフローチャートのようにプロセスを記述してしまい、結果として複雑化していきます。こうして最終的にできあがった数十ページにも及ぶ成果物は、複雑すぎて結局業務プロセスの可視化につながりません。そこから有益な情報を得るのは難しいでしょう。


「判断」はタスクではない

例えば、以下はある受注・割引価格適用の例です。ビジネスプロセスのみで描かれたプロセス図は図1のようになります。

プロセス図における割引価格の適用例

プロセス図における割引価格の適用例


プロセス図を描く上で一番重要なポイントは、「判断」をタスクにしないことです。なぜなら、「判断」は条件に応じた結果を導き出すためのルールであり、これは本来、判定順序を問わないもの(IT業界の方には宣言的と言ったほうがしっくりくるかもしれません)だからです。例えば上の図1に描かれているプロセスを、大きく「特別割引判定」というプロセスと捉えると図2のようにシンプルになります。

プロセス図における割引価格の適用例(ルール分離)

プロセス図における割引価格の適用例(ルール分離)


具体的な割引率、すなわち「判断」は、ビジネスルールとしてプロセス図から切り離しBRMS (Business Rule Management System)で管理します。いわゆるビジネスルール分離です。

分離前の例では、購入者がロイヤル顧客かそうでないかによって3つの状態に分岐し、さらに購入金額や顧客期間に応じて7通りの割引率へとたどり着きます。こうしたルールの領域はシステムの中でも変更頻度が極めて高い部分ですが、このように独立させることでプロセスに影響を与えずに済むという効果もあります。

変動性の高いビジネスルールをプロセスから切り離すことで、構造化モデルとしてのプロセスの安定性をより高めることができるようになります。なお、プロセスとルールの切り分け方については、別稿「意思決定のモデル化がなぜ重要なのか」で触れたモデリング手法「DMN(Decision Model and Notation)」でも説明していますので、そちらもご参照ください。


デジタルトランスフォーメーションを成功させるために

社内の全業務を横断的に支援する情報システム部門は、改善のミッションを担うことが多いかと思いますが、デジタルトランスフォーメーションの波がいよいよ押し寄せてきたこの時代には、従来通りの「やり方」を捨てる必要があります。その時、これまでこの連載で説明してきた様々な手法はどれも強力な助けになるはずです。

自立的な業務の可視化分析手法である「BPEC/B-NASS」では、業務プロセスの問題点を独力で明らかにできます。さらにモデリング手法を取り入れることで、ビジネスルールを中心とした柔軟性のあるシステムが実現します。また、プロトタイプ構築のフェーズでは、やはり超高速開発が有効でしょう。

そう考えると、デジタルトランスフォーメーションを目指す企業に有効なアプローチは、「もっと気軽に試しながら有効なビジネスを検証していくこと」とご理解いただけるかと思います。今のビジネスを劇的に改善する、アイディアを素早く形にする、それをすぐに修正できるという、「最初から最後まで計画通りにやりきる」アプローチではありません。

次回は連載のしめくくりとして、新しい取り組みに入る前に障壁となる基幹システムのレガシーモダナイゼーションについて、ビジネスルール分離の観点から説明します。



連載記事

デジタルトランスフォーメーションのための超高速開発基盤! Vol.1
デジタルトランスフォーメーションのための超高速開発基盤! Vol.2
デジタルトランスフォーメーションのための超高速開発基盤! Vol.3
デジタルトランスフォーメーションのための超高速開発基盤! Vol.5


執筆者のご紹介

アシスト佐藤 彰広

佐藤 彰広
東日本技術本部

2002年入社。Oracle Databaseのエンジニアとして、企画・プロジェクト管理に従事。その後、ビジネス開発部隊として新規ソフトウェアの調査・発掘を経て、ルールベースAI「Progress Corticon」の日本での立ち上げを担う。

本記事をご覧いただいている方へのご案内

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。


関連している記事

  • ルールベースAI/BRMS
2016.09.21

デジタルトランスフォーメーションのための超高速開発基盤! Vol.5

従来、基幹システムで最も重視されたのは自社のビジネスを止めないための堅牢性であり、そこに多額の投資が行われてきました。しかし、ビジネスの中核を担う基幹システムが変革を阻む枷となってしまっているケースがあります。

  • ルールベースAI/BRMS
2016.08.04

デジタルトランスフォーメーションのための超高速開発基盤! Vol.3

今ふたたび超高速開発に注目が集まっています。その真の目的は、単なる開発スピードの向上でもコスト削減でもありません。ビジネス変革ツールとしての超高速開発を解説します。

  • ルールベースAI/BRMS
2016.07.05

デジタルトランスフォーメーションのための超高速開発基盤! Vol.2

システム開発の約7割は「導入したのに使われない、改善されない」という失敗に陥るとも言われています。業務改善の観点から、システム導入で失敗しないための自立的な業務の可視化分析手法としての「BPEC」、それを利用してシステム要求につなげるための手法「B-NASS」について解説します。

ページの先頭へ戻る