■    いきなりToBeを書く

プロセス設計というと普通は現状分析をしてAsIsとして書き出して、それをいろいろな角度から分析して、見直しをして、変えるところを見つけ出し追加・削除・変更を施してToBeにする。これって、ちょっと変だと思いませんか。AsIsに問題があるから、直そうとしているのにAsIsをベースにしているわけです。そこでは、どうしても現在の延長線すなわち連続的な思考になり、少なくともイノベーティブなものは出てきそうもないですよね。

だから、そんなことをする必要があるのかということです。もちろん、業務プロセスは現状にないわけではなく、現にビジネスをやっている限りどんな企業でも必ずあります。それならその業務プロセスがAsIsではないのかという指摘もあろうかと思います。問題は、ほとんどの場合、AsIsのプロセスを書いていますといっても業務分析、作業手順になってしまっているから意味がないと言っているのです。

業務体系表に従って、組織のそして個人のタスクを書き出すわけです。それって、組織や人の仕事を解析するのであって、改革とかビジネスモデル変更要求引き出しとかいった動きとは別です。重要なのは、今やっている事業にとってどういう業務プロセスだとビジネスの要請から持ち込まれる要求を実現できるかである。設計とは、そういった業務プロセスを設計することです。

ですから、設計アプローチは現状がどうのというよりToBeをいきなり設計するという感じにならざるを得ないのです。つまり、これも何度も言っているのですが、組織と人から離れて、かつITシステとも無関係に俯瞰的な目線で書き出しましょうと言っているわけで、そうなるとほぼ必要なプロセスは決まってきます。このプロセス(まだフローを主体にしたもの)はすでにToBeというわけです。

さらに、そのプロセスに必要な要素を当てはめていくことで全体としてのToBeになります。ただ、ここで気をつけなくてはいけないのが、ToBeのレベルのことである。本当に理想的なものといったら技術的に難しかったり、リソースが不足していたりということは往々にしてありますし、経済合理性がない場合もあります。ですから、ToBeという言い方がよくないのかもしれません。ベストは難しいのです。

会社の成熟度に応じた、その時点で採れる最適な形態をToBeというふうに定義したほうがよいと思う。現有する経営資源のもとで当該ビジネスの執行にもっともよい業務プロセスを現状からではなく、ビジネス起点で書いてみるというのが最も簡潔で分かり安いアプローチだと思うのです。いきなりToBeを書こうというよりも、ビジネス起点で書き出すと自ずとToBeを書く事と同じになってしまうと言ったほうが適切なのかもしれませんね。
  

No TrackBacks

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

Leave a comment