第2回 BPP研究会 所感

少し遅くなってしまいましたが、4月7日（火）に開催された「第2回 BPP研究会」の感想です。

すでに他の参加者の方々（begiramaさん、悲喜子さん、mark-wadaさん・・・）も記事を書かれていますが（その他の方もすでに書いていたらすみません。コメントでURLを教えてください）、私も簡単な感想を書いておきます。

今回の議論の中で、以下の表に示す4つのキーワードが出てきました。この4つのキーワードの定義が明確になったので、私としてはすっきりして良かったなーと思います。

キーワード	言葉の定義
アクティビティ	・SCORのプロセスレベルでいうところの「レベル4」 ・「ユースケース実践ガイド」でいうところの「ユーザー目的レベル」 ・「単位意思決定」が行われるレベル
単位意思決定	・インプット情報をアウトプット情報に変換する、人の意思決定プロセス。 ・「アクティビティ」とほぼ同義。
マクロワークフロー	・アクティビティをフローでつないでプロセスを構成するワークフロー。 ・SCORのプロセスレベルでいうところの「レベル3」に該当。 ・このレベルでは、戻し処理は原則としては扱わないこととする。
ミクロワークフロー	・アクティビティ自体を構成するワークフロー（一種のサブプロセス。申請～承認系のワークフローに相当）。 ・SCORのプロセスレベルでいうところの「レベル4」に該当。 ・このレベルでは、通常戻し処理が必要となる。

ただし、上記の定義に基づいたプロセスモデリングが成立するのは、「企業の定型的な業務を前提とした場合である」との結論で、研究会は終了したと思っています。そこで、「企業にとって競争優位をもたらすのは定型プロセスなのか、非定型プロセス(プロジェクト型)なのか」という命題は悲喜子さんのブログでも取り上げられています。

この研究会では、定型的なプロセスを前提として当面の議論を進めていくのかなと思っていました。しかし、実は違うことになるようです。

帰り際にmark-wadaさんに聞いたお話やブログ記事からは、次回のテーマとして非定型プロセスも議題にあげることが伺えます。企業に強みをもたらすのは、定型的なルーチンワークではなく、コラボレーション型のプロセスではないかとの思いが背景にありそうです。このあたりをどのようにモデル化していくのかは、とても面白いテーマだと思います。

業務の構造化

第2回「ビジネスプロセスパターン研究」の開催日程がせまってきました。しかし、第2回のテーマである「業務の構造化」に関する記事をこれまで書いていませんでした。そこで、まずは現時点での見解を書いておこうと思います。

正直、業務の構造化についてはすごいアイデアがあるわけではなく、まだメモレベルです。しかし、自分の考えを整理する上でもいったんブログに書いておこうと思います。

まず、業務の構造化を考える場合の軸としてすぐに思いつくのが、業種や業務で分ける（パターン化する）という方法です。

１．業種でパターン化する（小売、製造、金融・・・など）
２．業務でパターン化する（営業、会計、人事・・・など）

上記の軸を組み合わせて、業種と業務のマトリクス・・・なども作れそうですが、考えてみるとこの区分ではかなり粒度が粗いですね。そこで、もっと業務とかプロセスに落とし込んだモデルが必要になりそうです。業種や業務に依存しない汎用的な業務のモデルとして、以前のmark-wadaさんの記事では「コアプロセスチェーン」という例を挙げていました。

今回、私はどのような軸で業務を構造化しようかと思ったのですが、「情報（人、物、金を含む）の流れ」に基づいてパターン化できないものかと考えました。この軸で分けた場合、以下のようなパターンが存在すると思います。下記パターンのカッコ内の記述は、システム的な動きを意図しています。

（１）受付⇒調査⇒回答（イベント⇒情報作成⇒情報提示）
（２）申請⇒承認（情報作成⇒イベント⇒意思決定⇒情報蓄積）
（３）作業依頼⇒結果確認（イベント⇒情報取得）
・・・・・などなど

上記のようなパターンを組み合わせて、複雑な業務プロセスも表現できたらよいですね。ちなみに、書きながら思ったのですが、このようなパターン化は先日の記事で書いたmark-wadaさんの「業務コンポーネントのパターン」とも重なる部分があります。パターン化のアイデアをうまくすり合わせできたら良いなと思っています。

ビジネスプロセスモデリング2つの視点

１．「ビジネスプロセスモデリング」の定義

BPMを推進する際は、以下の3つの領域を考慮しながら、企業にとって最適なモデル（＊１）を構築する必要があると考えています。

（１）企業戦略の領域
（２）業務の領域
（３）ITの領域

＊１：ここでいうモデルとは、いわゆる「業務フロー」だけではなく、戦略マトリクス、ビジネスモデル、組織関連図、サプライチェーン、システム構成図などのモデルも含みます。

今回取り上げる「ビジネスプロセスモデリング」とは、上記２の領域で扱う「ビジネスプロセスモデル（業務フロー）を作成する」ことを意味しています。

２．背景

私はこれまで、会社の仕事で（片手間ではありますが・・・）BPMツールの使い方を検討・試行してきました。BPMツールを使用したモデリングの流れは以下のようになります。

（１）現行の業務をモデル化する
（２）BPMNの記法に沿った形で、業務モデルを詳細化する
（３）Webサービスや画面との連携を定義してBPELに落とし込む

確かにこれで、システムとしては動きます。しかし、実際にBPMプロジェクトを推進するにあたっては、以下の疑問が発生します。

そもそも「ビジネスプロセスモデル」はどのような粒度で記述すべきなのか。

最終的にシステムとして実装して動かすためには、画面やWebサービスと紐づくレベルまで詳細化する必要があります。また、KPIに基づいて指標の測定・管理が可能な単位である必要もあると思います。しかし、BPMNやBPELのことは考えず、現行の業務、もしくはあるべき業務の形をモデル化しようという場合、どのような粒度で業務を切り出せばよいのでしょうか？

３．ビジネスプロセスモデルに関する2つの視点

このような粒度の問題はITの世界ではよく語られるところです。コンポーネントベース開発であれば、コンポーネントの粒度が問題となりますし、SOAであればサービスの粒度が問題となります。そこで、BPMにおいて業務プロセスの粒度をどう考えるべきか、というのが今回の疑問点です。とりあえず思いつくのが、以下の2つの視点によって、粒度を変えるという方法です。

（１）経営者・マネージャの視点
　全社の業務の流れ、業務間の情報の流れがわかるレベル

（２）現場の視点
　作業手順のレベル

今回の記事は、単なるアイデアメモにすぎませんが、これから仕事を進める中で、効果的なビジネスプロセスモデリングの手法をさらに検討していきたいと思います。