次なる誤解は「新たな業務プロセスを開発する」ということになりますが、誤解が誤解を生むかもしれないので少し注意が必要です。というのは、新たな業務プロセスを全く開発しないのかというとそんなことはなくて、場合によっては開発することもあるからです。

ここであえてこういう表現をしたのは、最初から新しいプロセスをつくり上げるのだと意気込まないほうがよいという警鐘をならしたかったからです。業務システム構築のプロジェクトが発足すると、IT化されていない部分がプロセスがないかのように錯覚して、そこが問題だと言わんばかりに新業務システムを開発するのだということになる。

ただ、最初に言ったように結果的には新たなプロセスにはなるのだが、順序が逆なのです。つまり、AsIsとかToBeというのをあまり意識せずに素直に業務プロセスを記述することから始めたらどうだろうか。なぜなら、業務プロセスというのは、ビジネスをやっている以上必ず存在するもので、意識、無意識に関わらず日々プロセスを回しているのです。

それは、マクロレベルのプロセスを見ればわかると思いますが、会社の大小、業種・業態に関係なしに共通的なもので、例えば販売、購買、受注出荷、生産なんていうプロセスは同じプロセスです。ですから、それをIT化しているから高度なプロセスであるというのも一概には言えないわけです。ホワイトボードとメールで仕事していても良いプロセスということだってありえます。

システム化のアプローチとして、最初に新しい業務プロセスを開発するのを目的化するのではなく、あくまで、自分たちのビジネスをオペレーションするためにはどんなプロセスになっているのがよいのかの観点でプロセスを記述することです。そこから、さまざまな問題が浮かび上がってきます。

個人の裁量で進めていたり、お客さんを無視して自分たちの都合だけで処理していたり、時間がかかっても平気だったり、ルールに従わなかったりといったプロセスの仕組みというより、プロセスを進めるための仕掛けのところの不備だとかが問題になってくる。こうしたプロセス管理に不可欠な組織能力をどう醸成していくかが大きいような気がします。

広義の意味ではこれもプロセスとも言えるのですが、フロー的な部分よりもこちらのほうが開発要素が多くあるのではないでしょうか。例えば多く見受けられるのはルールの欠如と役割の不明確です。このことは、別な言い方だと業務フローを変えるのが業務プロセスを開発することだとは必ずしも言えないのです。ルールがない中で業務フローを変えても意味がないのです。今回はプロセスとはが頭に入っていないとちょっとわかりづらかったかもしれませんね。
  

No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/138

Leave a comment