ビジネスプロセスモデリングでは粒度と結合度に気をつけろ

今回は、具体的にどのようにして、ビジネスプロセスを組み立てるかを考えます。
ビジネスプロセスをデザインする際の作業の進め方には、大きく分けて2とおりのアプローチがあります。
1つは、現行のプロセスを分析し、その改善策を練っていくというもの。
もう1つはあるべきプロセスを一から描くというものです。


手作業やバラバラなシステムによるものであっても、すでに何らかのプロセスが動いているのであれば前者の方法をとることができますが、まったく新規に事業を立ち上げるといったケースなどでは後者の方法を選択せざるをえないことになります。
それでは以下、具体的な作業の進め方を、まずは前者のアプローチに沿って見ていくことにしましょう。
すでにプロセスが動いているとしても、それが全社的な視点で見た場合に最適なものになっているという保証はありません。むしろ、その部門や担当者にとっては都合よく最適化されているものの、他の部門や全社的な視点からは無駄だったり、うまくつながらなかったりといったケースが少なくありません。
従って、まずは、前後のビジネスプロセスとのつながり(インプットとアウトプット)や、入力あるいは参照されるデータに着目し、なぜ現行のプロセスが生まれたのか、なぜ今のかたちになったのかを解明する必要があります。
「なぜ」を問い重ねていけば、「以前からそうだったから」、「それが慣習だから」といった薄い根拠を基に構築されているビジネスプロセスが浮かび上がることがあります。
これが多いんですよね。ERPプロジェクトでは… それをそのままERPで実現しようとして、アドオン開発に次ぐ、アドオン開発で、結果的に費用が増大し、プロジェクト自体も火が噴いてしまう…
また、システムを個別に構築してきたために、特定のビジネスプロセスの中でデータのインプットとアウトプットがつながっておらず、その間を手作業で橋渡し(再入力)しているような個所が見つかるケースもあります。
こうした問題点を洗い出し、解きほぐしてやるだけで、ビジネスプロセスの効率が格段に上がることは珍しくありません。
では、後者のアプローチをとる場合には、どのようにすべきなのでしょうか。
ゼロベースでビジネスプロセスを描くとなると、とかく肩に力が入ってしまうものです。しかし、実際には、この世にまったく影も形もなかったようなビジネスプロセスが新たに誕生することなど、まずありえません。新規事業であれ、新しい取引形態であれ、ほとんどの場合、類似した既存のビジネスプロセスが存在するものです。
例えば、インターネットで書籍を販売するというビジネスプロセスを見ても、顧客が書棚(ネット上ではデータベース)から選んだ商品の注文を受け付け、出荷し、料金を請求するという流れは、一般の商取引と何ら変わるところがありません。
従って、参照できるビジネスプロセスのモデルを探し出し、それを参考にしながら新しいプロセスのインプットやアウトプット、求められる付加価値などを定義していけばよいのです。
ビジネスプロセスのモデル化やデザインを考える際には、粒度と結合度が重要なカギになります。
まず、粒度は、ビジネスプロセスのデザインにかかわる人々の間で、共通理解を形成するための不可欠な要素です。
IT部門と事業部門との間で、互いにイメージしているビジネスプロセスの粒の大きさが異なっていると、プロジェクトを進める際に重大な齟齬が生じてしまいます。
IT業界においても、BPM、EAI、ワークフロー管理などの製品カテゴリーが正しく理解されていないケースが見受けられますが、こうした認識のずれが社内的にあれば、全社的な視点に立ったビジネスプロセスの最適化など、とても不可能です。
一般的に、現実のビジネスおよび業務をモデル化する場合は、まずは大きな粒でプロセスをとらえ、その関係を明らかにしたうえで、徐々に詳細化していくのが定石です。
サブシステムレベル(在庫管理、販売管理と言ったレベル)から機能レベル(受注、出荷、請求と言ったレベル)、そして、処理レベル(請求で言えば、顧客照会、単価照会、売上高算出、請求書発行というレベル)へと落とし込んでいきます。
これをプロセスの可視化と呼びます。
ビジネスプロセスの分析やモデル化にあたっては、今、どのレベル(粒度)について議論をしているのかについて、絶えずすりあわせをしておく必要があります。
次に、結合度ですが、これは、プロセス同士のインプットとアウトプットをどのようにつなぎ合わせるかを考えるうえで欠かせない要素です。
一般に、システムをつなぐ方法には、結合度が強い(密な)順に「リアルタイム連携」、「キュー連携」、「バッチ連携」の3つがあります。
例えば、AとBという異なる処理(または機能、サブシステム)がある場合、リアルタイム連携は言うまでもなく、Aが実行されたらすぐにBが実行されるという関係であり、一連の流れが単一の制御元の配下にある状態を指します。
一方、キュー連携(メッセージ・キューイングなどとも呼ばれる)は、Aが実行されたらBの実行は待ち行列に入れられ、都合のよいときに実行されるため、Aの実行の制御とは切り離されます。
バッチ連携の場合も、キュー連携と同様に2つの処理の制御は切り離されることになりますが、その起動は時刻指定などによって行われます。
さまざまな粒をそれぞれ、どの結合度で連携させるべきかを考えること、言ってみれば、これが、ビジネスプロセスモデリングにおける最も重要な検討事項なのです。
具体的な作業の進め方としては、まず、「現在、手作業で行われているこの部分の連携をシステム化したらどうなるか」、「今バッチ連携している部分をリアルタイム連携にしたらどうなるか」といったように、仮説を立てたうえで、どのような粒の大きさでビジネスプロセスを分解し、それぞれをどの程度の結合度で連携すれば効率的であるかを検証するのが望ましいのではないでしょうか。
また、ビジネスプロセスを分解するにあたっては、それによって生じる業務の粒を、全社共通なもの、複数部門で共有できるもの、部門固有なものに分けて整理することも肝要です。
本来は部門固有のビジネスプロセスであっても、分解のしかた次第では、他部門でも共有することができるプロセスコンポーネントを抜き出し、定義することが可能になります。
さらに、ビジネスプロセスの変化のスピードにも着目する必要があります。
不変的なプロセスであるのか、それとも年単位などで変わる可能性があるプロセスなのかによって、デザインの手法が変わってくるからです。ただし、頻繁に変化するプロセスであっても、細かく分解してみると、変化が求められる業務はごく一部分で、そのほかの部分は不変的な業務であるようなケースも出てきます。
ビジネスプロセスのデザインと見直しを行うにあたっては、まずは全社共通で不変のプロセスから、全社共通で変化が必要なもの、そして部門固有のものへという優先順位で検討することがよいのではないでしょうか。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*