前回は、マクロワークフローとミクロワークフローとでは業務処理の性格も違い、処理の担い手も違うことを提示しました。そうした違いがあるのなら、それらの機能を実現する“場”も変えたらいいというのがここでの立場です。

従来は、これらを一緒くたに考えていて、下手するとそれを全部コードで書いていたのではないでしょうか。あるいは、あらかじめ同じプラットフォームに組み込まれたパッケージというものを使っているかもしれません。餅は餅屋というか適材適所を考えるべきであると思います。そういうことができるようになったのもSOAという概念のおかげでもあります。

さて、それではまず、ミクロワークフローである単位意思決定をどういうところで行なうかを考えていきましょう。意思決定プロセスはサイモンを持ち出すまでもなく、いろいろな情報を参照しながら、選択肢を見つけ、調整しながら最終的な答えを導き出し、業務だと承認されて終わります。

ですから、この営みをどこでやるかになるわけですが、意思決定をする“場”には、3種類のものがあると考えられます。一つは、従来のような画面や帳票回付で、二つ目が、一般的なワークフローです。そして、3つ目が、情報共有型Webサイトです。

画面･帳票は、担当者が画面を開いて、あるいは帳票を回して意思決定していくもので、一般的なワークフローは、申請(起案)－承認ワークフローと呼ばれるようなもので順番に回していくわけです。情報共有型というのは、SNS、Blog、Wikiといった参加型の仕組みを持ったWebサイトのことです。

それらをどう使い分けていくのかを検討するには、意思決定の形態について考えてみるとよいと思います。まず単独行動なのか、それとも複数の人間が関係するグループ行動なのかを考えましょう。

従来は、単独行動で行なっているケースがけっこうあったのではないでしょうか。例えば、今のシステムの画面操作を考えてください。担当のオペレータが一人で画面を開いて入力するシーンでは、少ない参照情報のもと単独で意思決定しているのではないでしょうか。

もちろん、重要なものは電話、メール、FAX、直接の会話などで調整や確認をしながら意思決定をするでしょうが、おおかたは担当の単独意思決定があり、最後に承認をもらうパターンではないでしょうか。

こうしたやり方は、一般的なワークフローもそうですが、決まりきった流れの定型的な処理であればいいのでしょうが、各所と調整をとらなくてはいけないとか、差し戻しが頻繁に起こるようなケースでは、手作業に頼らざるをえないか、複雑なワークフローを書いてわけがわからなくなるような気がします。

こうしたことを考えていくと、従来の画面と帳票はもはや役目は終えたように思うのですが、いかがでしょうか。重要なことだけではなく、通常の意思決定もできるだけ関係者の参加で意思決定ができるようにするほうが意思決定の質と速さが向上します。

現実的には、定型的なものもあるので、一般的なワークフローと情報共有型Webサイト（これをCollaborative Work Spaceと呼びたい）の組み合わせになると思っています。

次回は、マクロワークフローの実現の場を中心に議論していいます。