« 暑いよー! | メイン | ビジネスモデルを実装する-まとめ »

ビジネスモデルを実装する-閑話休題(5)

改善と改革

この言葉の違いはおおかたの人はわかっていると思うが、単なる言葉の意味の違いではなく、実際にどう実行するかという点で意外とわかっていないのではないかと思うことがある。つまり、改善も改革も同じようなアプローチをするということである。

よく見かけるのは、業務改革プロジェクトとかプロセス改革委員会とか言って始めるのだが、おそらくほとんどのケースで現状分析して、そこでの問題点を洗い出しましょうなんてことをやる。

いわゆる、AsIs分析である。そこから、ToBeと導き出そうという進めかたである。一見よさそうに見えるし、まったくダメだというわけでもないので、ついこうしたアプローチがまかり通るがちょっと考えてみる必要があると思う。

現状分析から問題点を抽出してというのはいわゆる問題解決型のアプローチであるが、これだとどうしても現状に引っ張られてしまい、斬新なそして画期的なアイデアが生まれにくいという欠点がある。ただし、この場合の問題点の設定が非常に適確で当を得たものであると改革的な答えにたどり着く可能性はある。議論のかみ合わないことが起こるのはこの問題設定が間違っている場合が多いのである。

こうした問題解決型の対極は仮説検証型であるが、このほうが改革には向いているだろう。現状にあまりとらわれずにこうしたほうがいいという仮説を設定して、そこに行き着くためにどうしたらいいかを考えることである。ただここでも、この仮説の立て方が問題で、この設定に左右されてしまうのは問題解決型と同様の悩みである。

ですから、改革のアプローチは現実的には両者の中間に解があるように思う。すなわち、現在の問題を意識しながら、そこからの連続ではなく、少し“跳んだ”仮説をいくつか立て、それをケーススタディ的に検証して、その中からBetterケースを選択するというアプローチではないでしょうか。

さて、ここで業務プロセス改革ということについて考えてみます。現状業務プロセスすなわちAsIsプロセスを書き出して、それをToBe化しますというのは多くの場合プロセス改善です。ではプロセス改革はどうしたらいいのでしょうか。

実はプロセス改革は、プロセスのところだけでは改革はできません。せいぜい改善でしょう。プロセス改革とはビジネスモデル改革と一対のものなのです。他社と差別化する新規のビジネスモデルができ、それを実現するためにプロセスを改革するということなのです。新しい価値を生み出さなければ改革ではないからです。

従って、業務プロセスの重要な役割は、ビジネスモデルの変革に素早く柔軟に対応できるものでなくてはいけないということです。そのためには、AsIsからToBeということではなく、プロセスの構造の本質を見極め、すぐにデザインできることであり、変化対応力のある構造と機能を持っているということなのです。

トラックバック

このエントリーのトラックバックURL:
http://kamawada.com/~masanori/blog/mt/mt-tb.cgi/1472

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2010年07月26日 10:50に投稿されたエントリーのページです。

ひとつ前の投稿は「暑いよー!」です。

次の投稿は「ビジネスモデルを実装する-まとめ」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type