What（構造・道具）を先に構想する－その２

前回論じた中でこれからの重要な対象プロセスとして、実行・活動系のプロセスをOntologicalな扱いでシステム化したものが求められるようなことを指摘しました。そこの強化に向けてどういったものを作っていくのかがここでの議論になります。それを示したのが次の図です。この図の赤線で囲ったKeyProcessがそれにあたります。

ですから、それ以外の決算系は既存のERPや会計パッケージで十分であると考えています。
そして、個別的に存在するWebアプリケーションやリソース管理システム（例えば、設備管理、在庫管理、物流管理、人事管理など）もそれぞれ特化したものがあって、それを使えばいいし、そこのデータ管理プロセスが弱い場合は、新しいプロセス構造で補完すればいいと思います。

さて、そのフロントエンドプロセスのシステム構造とツール化の問題になります。前からの流れで、まずはプロセス構造を考えていきましょう。業務プロセスを階層的な見方でとらえると、ハイレベルになればなるほど定型的で反復的であることがわかります。逆に言えば、ローレベルでは非定型でアドホックなものになっています。

ここで注意しなくていけないのは、データ処理や情報処理といったレベルは定型的ではないかということですが、あくまでプロセスというレベルの話であって、スナップショット的なアクションは除いています。

なぜ、レベルが低くなると定型的でなくなるのかというと、人間が介在する余地、すなわち人のつながりで仕事をすることがでてくるため、意図的な要素が入り込んでくるからだと思います。ですから、そこの線引きをする必要があります。道具の作り方が変わるからです。

この2段プロセスの構造が重要なポイントになります。この2段の上位プロセスというのはある程度パターン化できるものです。ここは、個人のつながりではなく組織のつながりになってくるので、あいまいさが排除されてくるのです。この辺りは何度も議論してきたところです。

一方、下位のプロセスでは、あらかじめきちっと決められないことが多く、ケースによって様々な様相を呈します。こうしたタイプでは、線で結んだり、ツリーで書くことは難しいのです。ですから、“線”ではなく“場”という概念が必要になると言っているのです。

上位はフローで下位は場でという構造になります。別の見方で言うと、業務プロセスとは「人のつながりでしたしごとのつながり」という構造になるわけです。しごとのつながりだけでもなくひとのつながりとの合わせ技が現実的な解であると思うのです。