これから提示する作法は、もちろんどんなものにも適用できるかというとそうではありません。まず、注意しなくてはいけないのは、実装を意識したボトムアップの手法だということです。
事業戦略とかビジネスゴールから業務プロセスに落とし込んでいくトップダウン手法がありますが、本作法はAsIsベースのボトムアップ手法です。実際には両者の組み合わせでおこなうハイブリッド型のアプローチが有効になります。
こうした組み合わせもケースでいろいろなやり方がでてきます。AsIsのプロセスを切る出して、そのプロセスをベストプラクティスモデルと突き合わせて改善していくというオーソドックスな場合や、新規事業などはそのままモデルを適用する場合もあります。また、IT化のレベルが低い会社などでは、まず現状のシステムの見える化をするだけで十分だという場合もあると思います。ですから、トップダウンだとかボトムアップだとかはあまり気にしない方がいいのかもしれません。
要は、自分たちが現に行っている事業がどういう業務プロセスから成り立っていて、それが役に立っているのかを把握できるかである。それが分かれば、今のままでいいのか、変えなくてはいけないのかが明らかになるのではないでしょうか。
基本的には、「書類コンポーネントをベースにしたCMS-BPMSを使った業務アプリケーション構築」のための設計になっています。
ただし、それだけに特化したものでもありません。プロセスというものは機能の組合せで成り立っていることは何度も申し上げていますが、その機能をコンポーネントと捉えていく考え方であれば適用は可能です。すなわち、そのコンポーネントを書類というようなオブジェクトを想定するのか、また違ったものに定義してもかまいませんが、同程度の粒度でみているものであれば、同じように設計が可能です。
BPM（Business Process Management）アプリケーションを考える場合は、多くの場合はマスタデータは整備されているという前提に立ちます。業務プロセスをまわすために必要なリソースデータ、例えば、顧客、取引先、商品、従業員マスタなどは既に用意されていて、それらを参照するようにしています。
ただし、BPMでももちろんデータを扱いますので、データディクショナリーを保有し、データの一貫性やデータベースの重複の回避など、整合性を保つ必要はあります。
もし、整備されていない場合はデータモデリングから入り、マスタの構築を行ないます。
同じように、ビジネスルールについても、別途保持しているという前提です。それらのルールに従って、分岐の発生や意思決定の方法が規定されていきます。もちろん、そのプロジェクトで新たに出てくるビジネスルールもあります。
こうした、前提条件についてもこれからの作法の中に出てきますのでそこでまた議論したいと思います。