BPMプロジェクト成功の鍵［5］ - 分析・把握・発見：BPTrends（13）（1/2 ページ）

BPMプロジェクト実行フェイズの最初のステップは、プロセスの分析だ。分析のための分析に陥ることなく、ブレークスルーをもたらす改善策を導かなければならない。

[著：デレク・マイヤー, 訳：高木克文，日本能率協会コンサルティング]

ステップ6：プロセスの理解

本稿は、米国BPTrends.comからアイティメディアが許諾を得て翻訳、転載したものです。

　最初の課題は、プロセスを真に理解することだ。そのためには、いったんプロセスの外に出て、それが何のために存在するのかを見届けるべきである。欠陥を残したままのプロセスの自動化は進ちょくを早めはするが、既存の問題を増幅するどころか、新しい問題を招くことにもなりかねない。従って、プロセスの運用の仕方と、その根底に潜むビジネスニーズについての仮説を、新鮮な目で見詰め直すことが大切である。プロセスに対する深い理解が得られれば、プロセス改善に着手する前の改善機会の発見が、はるかに容易になるのだ。

　ここで誘惑の手を差し伸べてくるのは、詳細にわたるモデル作りへの取り組みである。これは、（不可能ではないとしても）明らかに難しい。プロジェクトが、まさしく分析まひに陥る道程でもある。

　プロセスの枝葉末節へのこだわりは、ほとんど確実に時間の浪費に結び付く。このことを、心しておかなければならない。適用するソリューションは、現在の物事のやり方とは異なるものなのだ。

　重要なことは、ほとんどの社員の現在のやり方が「ベストプラクティス」ではない、という認識である。一定の「分析まひ」期間を経れば、慣れたやり方（ほとんど以前と同じやり方）に戻っていることが多い。1〜2年後になると、プロセスに対する別の見方があることに突然気付く。そして、ようやく当初の試みを放棄し、新たに得た教訓に基づく急進的プロセス改善に、再び取り組むことになる。しかし、その過程で、数人年の活動工数を浪費し、膨大な機会を失ってきたことは事実だ（フローダイアグラムで）エンドツーエンド・プロセスの複雑な詳細のモデリングによってプロセスを把握・理解したというのは、誤った思い込みでしかない。

　スターティングポイントが必要なことは、いうまでもない。しかし、もっと重要なことは、改善に用いる基礎的なアプローチと手法を超えた視野を持つことだ。とはいえ、やはり、既存プロセスの実態を踏まえた将来の評価ベースライン設定に十分な詳細データは確保しておかなければならない。それには、テクノロジが役立つ。シミュレーション・ツールを用いた「As-is」モデルの詳細分析は（もし、それがあれば）、改善とリスク低減に結び付く。

　しかし、この種の分析から、プロセスそのものを根本的に改善するためのアイデアが生まれてくることは、めったにない。ここにこそ、スキルを備えたビジネスアナリストやプロセスアーキテクトが真価を発揮できる場がある。彼らは、プロセスを別の角度からとらえる方法について十分に訓練され通じた人材でなければならない。

■フローダイアグラムを補完する

　この段階でのベストプラクティスは、プロセスに関する相対的検討を可能にする補完テクニックを用い、組織の上位レベルにおけるプロセスモデリングを数回試みることだ。これは重要なポイントである。多くの組織に見られるのは、真の客観性を見失い、手間暇掛けて「As-is」プロセスのモデル化に取り組んでいる姿である。どのようなソリューションを適用するにせよ、アプリケーション活用の成功の鍵（CSF）は、その後のプロセスの短サイクルの反復と改善にあるのだ、ということを忘れてはならない。

　最終的には──「間違いのないモデルはないが、役立つものもある」というデミングの格言のとおり──、すべてのモデルは現実の一表現でしかない。新鮮な視点を持てば、フローダイアグラムが唯一のテクニックであったときには見えなかった実態が浮かび上がり、プロセスの真の理解に結び付く。フローダイアグラム中心のアプローチを補完するテクニックとして、ロールアクティビティダイアグラム（RADs）とオブジェクトステートトランジションネットワーク（OSTN）の利用を推奨したい。

• RADsは、「生起するアクションとトランザクションの結果として生じる役割（ロール）の状態変化」に焦点を当てる。見た目はBPMNダイアグラムのようでもあるが、誰が誰と何をするかを示し、プロセスの作用と役割に注目させるのが、RADsの大きな特長だ。また、従業員にとっては、プロセス内の他者の役割が認識できるとともに、顧客の視点がとらえやすくなる。RADsは非常にコンパクトなテクニックでもある。例えば、某大手不動産会社では、24ページもあったフローダイアグラムが、わずか1シート上に整然と示されるようになった。RADsに関する参考文献としては、マーティン・オウルズによる著書、「ビジネスプロセス：その正しいアプローチ」が最良である。
• OSTNは、IDEF3として知られる米国国防省規格の一部である。異なるアクティビティの出現に応じて状態を変え、どのように物事（ビジネスオブジェクト）がプロセス内を移動しているかを示す。焦点の対象は、（アクティビティの順序ではなく）あくまでオブジェクトである。プロセス内の各ステップがオブジェクトを修正・変換する過程をとらえられるのが、このテクニックが優れた点だ。IDEF3として知られる米国国防省規格の一部である。異なるアクティビティの出現に応じて状態を変え、どのように物事（ビジネスオブジェクト）がプロセス内を移動しているかを示す。焦点の対象は、（アクティビティの順序ではなく）あくまでオブジェクトである。プロセス内の各ステップがオブジェクトを修正・変換する過程をとらえられるのが、このテクニックが優れた点だ。

　ほかのモデリングテクニックにも、同様の機能を持つものがある。しかし、それらのアプローチは、付加価値をもたらすプロセス内のステップ（ビジネスオブジェクトが状態を変える場）にモデラーの照準を合わせる。ここに大きな相違点がある。

■プロセスモデリングの注意点

　初期段階のフローチャート作成（ほとんどの場合、これが出発点になる）に際し、モデリングチームは、アクティビティについて想定できる全ルートを把握しようとしない方がよい。むしろ、コアプロセスと主要な例外事項に重点志向すべきである。しかし、例外事項の処理に、どれだけの力と時間が注がれているかは把握しておかなければならない。

　プロセスアーキテクチャには、手続きと流動性の高い業務処理方法の双方のニーズが確実に反映されていなければならない。しかし、適切なプロセスアーキテクチャのデザインは簡単なことではない。これはテクノロジの問題ではなく、ビジネスデザインそのものの1つなのだ。

　まず、アナリストにはプロセスの完全な理解が求められるが、この作業はプロセスの詳細にわたるモデリングと同一のものではない。プロセスモデリングは、通常、まさしく（業務のやり方に非効率が認められるときに）プロセスそのものを変更する行為である。しかし、プロセスに関するあらゆる事柄をモデル化しようとすれば、分析まひに陥ることが避けられないであろう（特に、ドリルダウン機能分解テクニックを用いているときは）。このことが何よりも深刻な問題である。

　プロセス最適化は1つの道程であって、一時的なイベントではない。これを理解しておくことが、重要なポイントになる。1つの純正アプローチにこだわらず、異なる見方を対比してこそ、この理解が得られるのだ。さらに、複数のモデルを対比することにより、（大きな投資を伴う）技術的サポート環境の導入に先立ち、プロセスに関する理解を確実に高めることができる。

　ハイレベルにおけるプロセスの把握が完了すれば、反復的開発の方法が、次に備えるべきコアテクニックになる。ダイナミックで変化し続けるビジネス環境に対処するためのテクニックである。