解説： ビジネスプロセス・マニフェスト
日本語訳に当たり：
昨年11月のラスベガスのBBCカンフェランスで知った、ビジネスプロセス・マニフェストです。発行元の BPTRends, LLC から正式な翻訳権を得ましたので、マニフェストの日本語訳とその解説を連載でお届けします。BPMの本場、北米でのビジネスプロセスの考え方がよくわかります。
日本でのBPMの扱い方は、BPMN（ビジネスプロセス・モデリング表記法）からソフトウェアを自動作成することに重きが置かれているようです。いくら自動的にソフトウェアがプロセスを実行してくれても、ビジネスや経営に貢献するビジネスプロセスになっていないと効果が出ないばかりでなく、余計にコストがかかってしまうことになりかねません。はたして、どのように経営に貢献するビジネスプロセスを特定するのでしょうか。BPMNをいくら学習してもその解は得られないようです。
（画像をクリックするとマニフェスト日本語版がダウンロードできます）
本場のBPMはビジネス/経営に直結するビジネスプロセス変革/改革やプロセス再設計が中心です。ソフトウェアで実践することはずっと下流の工程です。このビジネスプロセス・マニフェストにより、本場のBPMに対する基本的な考え方を知ることができます。
それはまさにBABOKでいう、要求の階層構造（ビジネス要求、ステークホルダー要求、ソリューション要求）そのものです。「ビジネスアナリシスの扱うソリューションはITのみならずビジネスプロセス、．．．」というBABOK®のフレーズを思い出しながらお読みいただけると幸いです。
以下、解説です。
ビジネスプロセスの運用上の定義
- 組織のビジネスプロセスは、顧客および他のステイクホルダーに価値ある結果の作成に関与するすべてのリソースによって行なわれる業務について明確に記述する
実は、辞書の上では、運用に耐えうるようなビジネスプロセスの定義はありません。マニフェストでは、上記のように定義しています。大変シンプルで平易な定義です。読者の皆さんにも違和感はないのではないでしょうか。
つづいて、このマニフェストでは下記のように8つの原則を掲げています。
原則
- 業務に関して：ビジネスプロセスは組織の業務について記述する：
- 価値創造に関して：ビジネスプロセスは、そのビジネスプロセスの顧客および他のステイクホルダーの価値を創造する：
- リソースに関して：ビジネスプロセスは、様々な組織あるいは組織単位の中のリソースの組み合わせによって行われる。
- コンテキストに関して：ビジネスプロセスは定義されたビジネス・コンテキスト内に存在する。
- モチベーションに関して：ビジネスプロセスのゴールと目標は、ビジネスの戦略的ゴールと目標を支援する。
- プロセス名に関して：理想的なビジネスプロセス名はあいまいさがなく、ビジネス上親しみがもて、一貫して使用される。
- モデルに関して：ビジネスプロセス・モデルは多角的な視点（パースペクティブ）、表記法（ノーテーション）、図（ダイアグラム）を可能にする。
- ユニークさに関して：ビジネスプロセスは、他の組織資産を利用するユニークな組織資産である。
それでは、各々の原則に関して解説を続けます。
業務に関して：ビジネスプロセスは組織の業務について記述する：
- ビジネスプロセスの中で行なわれる業務は、物理的入力または情報入力を出力に変換する。
- ビジネスプロセスはアクティビティのセットで構成される。各々のアクティビティもまたその下位のアクティビティのセットで構成される場合がある。
- 組織のビジネスプロセスの完全なセットは、その組織によって行われるすべての業務について記述する。
- ビジネスプロセスは、厳密に構造化された繰り返し業務で構成される場合と、緩やかな構造で様々な形態をとる場合がある。
【解説】
最初の項目は特に問題ないと思います。入力（インプット）を何らかの出力（アウトプット）に変換するのがビジネスプロセスですから。
2番目の「各々のアクティビティもまたその下位のアクティビティのセットで構成される」がポイントです。要するにビジネスプロセスは階層構造を持つことを明確に謳っています。単なる業務フローだけを言うのではありません。
3番目も特に異論はないと思います。
4番目の前半の「厳密に構造化された繰り返し業務」が通常のプロセスです。あえて言えば定常業務を表しています。ウォーターフォール型の業務と言っても差し支えありません。後半の「緩やかな構造で様々な形態をとる」業務は非定型な業務です。例えば営業の業務は緩やかな構造で、相手（顧客）により同じアクティビティ（例えば訪問）を何度も繰り返す場合もあれば、スキップ（訪問せずにメールだけですま）して次のアクティビティ（例えば見積もり）に移行したりします。また、マネジメントの意思決定のプロセスも大まかな手順はあるかもしれませんが、特に決まっているわけではありません。アジャイル型のソフトウェア開発も緩やかな構造と言えるでしょう。などなど、その形態は様々です。そのどちらもビジネスプロセスとして扱います。
のっけからいきなり、ビジネスプロセスの本質に迫ってきていますね。
価値創造に関して：ビジネスプロセスは、そのビジネスプロセスの顧客および他のステークホルダーの価値を創造する：
- ビジネスプロセスは、顧客および他のステイクホルダーの具体的なニーズおよび期待を満たす成果を出し、測定可能な価値を創造するべきである。
- ビジネスプロセスによって生成される価値は、一つ以上のパフォーマンス・インジケーターによって測定されるべきである。
- ビジネスプロセス内のすべてのアクティビティのパフォーマンス・インジケーターは、その上位のビジネスプロセスのパフォーマンス・インジケーターにトレースされなければいけない。
- ビジネスプロセスのパフォーマンスは、有効性を評価し、かつ改良の機会を識別するためにそのビジネスプロセスのライフサイクル全般にわたり定期的に測定されるべきである。
- ビジネスプロセスのパフォーマンス・インジケーターはそのビジネスプロセスが運用されるすべての場所において経時的に、かつ場所横断的に測定され比較されるべきである。
【解説】
最初の項目と2番目の項目で、ビジネスプロセスが生成する具体的な価値を、パフォーマンス・インジケーターによって測定することを明確にしています。さらに、3番目の項目では、そのインジケーターが上から下までトレースされなければいけないと言っています。これはBABOKのトレーサビリティに対応するものですが、組織の全レベルのビジネスプロセスのパフォーマンスを最上位階層のビジネスプロセスのパフォーマンスに整合させることを意味します。これにより、最上位階層のパフォーマンスを改善/改革するために、どのレベルのどのビジネスプロセスが影響するのかがわかるようになります。
さらに4番目と5番目の項目では、パフォーマンスをビジネスプロセスのライフサイクル全般に定期的に測定し、かつロケーションごとに測定し、比較し、改善ポイント（ロケーションによる違い、時間的なパフォーマンスの違い、など）を見つけて、PDCAを回すことを主張しています。単に自分の担当するプロセスを改善するのではありません、最上位階層のパフォーマンス（それが経営数字に直結します）を改善/改革するためのPDCAです。
ビジネスプロセスをここまで厳密に測定している組織が日本にどれだけあるのでしょうか。また、日本のBPMよりはるかにレベルが高いと思います。
ビジネスプロセス・マニフェストがこれだけ高尚なレベルの内容なことに、感銘を受けるのは筆者のみではないと思います。
次回は引き続き、原則の解説です。「リソースに関して」、「コンテキストに関して」、「モチベーションに関して」を解説します。