システム開発で設計というとこれまではシステム機能に寄っていってしまいます。どうしても、システム化あるいはコーディングするための設計になります。

ところがユーザが見ているのは自分たちのビジネスがどう実現できているかです。ですから、極端な話システム機能はどうでもいいのであって、自分たちの仕事の流れ、事業の実態が追えるかどうか、コントロールできるかです。

ですから、ビジネスを設計したらそれがそのとおり動く仕組みを提供する必要があって、以前“動く業務プロセス”というい方をしましたが、それがBPMでもあるのです。ただし、このときのアクティビティの定義が問題であまり細かすぎてもいけないし、大雑把でもいけないということです。

そして、上流の戦略から落ちてきたプロセスモデルがそのまま実装されるのが望ましいのです。従来はここに断絶がありました。システム化できる業務を抜き出してそこを実装するための設計・開発にはいるというわけです。

そうなると、ビジネスの連続した動きが見えなくなってしまい、そのシステムを動かすために人が動作するという逆転がおこるのです。

さて、この連続性を可能にするにはどうしたらよいのでしょうか。トップダウンアプローチとして上流から分解してくるプロセス粒度とボトムアップアプローチである実装を意識したプロセス粒度が合致することです。この設計と実装の交差点が定義できることが重要になります。

こうしたことができると上流から下流まで、戦略からＩＴ実装までがシームレスにつながり、ビジネス側の要求がどう実現されるのか、ＩＴの持つ機能がビジネスにどう生かされるのかが見通せるのである。

これがＢＰＭの非常に大きな特徴である。言い方を変えると、こうした良さを引き出せるＢＰＭを志向しないと意味がないのである。何度も言いますが、単なるワークフローでもなければ、プログラミングの自動化でもないのです。