June 2014 Archives

今回から標題のような記事をシリーズとしてエントリーしておこうと思う。筆者が関わった事例をベースにしたBPM(Business Process Management)が成功するためのポイントについてである。BPMもだいぶ浸透してきているとはいえ、まだまだほんとうに理解されていないとか、成果を疑問視されたりしているところもあるので、実際の適用事例が語るところを示すことで認知度を高めたいと願っている。以下フェーズを追いながらどんなことをして、どんなことに注意しなくてはいけないのか、どうしたらうまくいったのかという点について記していくことにする。  
           
1. BPMの取組み       
(1) BPMを始めるきっかけ
まずは、BPMを始めるきっかけということを見ていきましょう。いきなりBPMをやりましょうとか、BPMS(Business Process Suite)を入れましょうかということはないと思います。もしそれであれば失敗するでしょう。ビジネス上の要請があって初めてその要請に応える手段としてBPMが採用されることになります。

ではそのビジネス上の要請というのはどういったものでしょうか。大雑把な言い方をするとビジネス環境の変化に対する対応ということなのではないでしょうか。経済状況が変化した、あるいは競争環境が変わった、消費動向や市場・顧客が従来と違ったものになったといったことが自分の会社に影響を及ぼす、あるいは及ぼそうとしているときに経営者は何らかの手だてを考えます。

その時にどんな変化対応の仕方をしたらよいのか、その時の新しいビジネスモデルはどんな形になるのか、変化対応するときの阻害要因は何なのか、それを乗り越えるための課題は何なのか、どれだけのリソースを投入すればいいのか、あるいは調達しなくてはいけないのかといったことの答えを見つけ出さなくてはいけないことになります。

本事例は、2008年に起きたリーマンショックで既存製品の売上が半減してしまったという製造業の中小企業のものです。大企業ならいざしらず中小企業においては主力製品でもあることから会社の存続も危ぶまれるというのもまんざら嘘ではない事態になりました。この製品は、ほとんどが標準の在庫品販売がメインですので、一気の景気後退でユーザの買い控えが起きたのです。

さて、こんなときはどうしたらよいでしょうか。景気の回復をじっと待つのでしょうか。そうは行かないのは誰の目にも明らかです。この会社では戦略を変えることを選択しました。ただあたりまえですが、戦略を変えるだけではなくそれを実行しなくてはいけません。掛け声だけでやれるわけではありません。そこで取り組んだのがプロセスを中心にして事業や業務を見直すことでした。そして、新しい戦略のもとに業績の回復に成功したのです。

【成功のポイント】
ビジネス環境の変化に対する対応力をつけるにはプロセス視点でビジネス活動を捉えること
  

  

5つの誤解の2つ目は「IT化、自動化を目指す」です。プロセス設計からシステム構築へ向かうときに、何がなんでもITを使ってシステムを作るということは少ないかもしれませんが、大方の人はプロセス設計の段階においてもIT化してそれを自動的に動かすということを頭に浮かべているのではないでしょうか。

それはそうかもしれませんね。ITシステム構築プロジェクトだからどうしてもそういう態度になってしまいます。しかし、一旦そうした頭を空にしてみたらいかがでしょうか。つまり、プロセスを描くときに自分たちの業務の流れをITを使っていようがいまいが関係なしに書いてみることです。

実はこのことはプロセスの本質的な意味合いを理解する上で大事なことだと思います。よく現状の業務フローを書いてくださいというと端末画面が出てきてそれを使ってフローが進む図を書きます。画面の遷移で業務を進めているフローになっています。こうした書き方をやめたらどうかと言っているわけです。あるいは申請・承認フローを描くことも多いでしょう。

ただ、前回に議論したようにバックヤードシステムではこうした業務フローになっています。プロセス的な要素が少ない領域ではあり得ることです。しかしながら、そうではない顧客接点プロセスといった領域では、端末の画面が出てくるようなフローを書くのは避けたいものです。

それと、次回にも議論になるかと思いますが、どこの会社でも必ず業務プロセスはあるわけです。IT化されてないものはプロセスではないと誤解している人が、「IT化、自動化を目指す」間違いを犯すのではないでしょうか。コンピュータがない時代でもビジネスをやっていたし、業務プロセスはあったのです。いまでも、ITをそろばんとして使っている会社がいっぱいあります。人手で業務を回していてもそこにはプロセスがあるのです。

ですから、プロセス設計はITとは無関係に設計すべきなのです。つまり、どういう意思決定をして、どういう判断をして依頼者に応答していくか、そのために必要な作業はどんなことでどういう手順でやっていくのかを定義してくわけですが、それはITとかは関係ないのです。そうして設計されたプロセスをオペレーションしていくにはITを使ったほうが良いのかを吟味すればいいのです。

もしITが使えないようなところ、あるいはわざわざITを使う必要がなければ人間がやればいいのです。また、自動化も無理してやることもないわけで、自動化というのは一見良さそうだが、自動化のロジックを一生懸命考える割にはそれだけの効果がない場合もありますし、例外が起きた時の影響などを考えると慎重にやるべきだと思うのです。「IT化、自動化を目指す」のもいいけれど適材適所でやるべきなのです。
  

さて、ここまで3つのパラダイム変化である「データ・機能中心からプロセス中心へ」「作って終わりから動かしてナンボへ」「個人作業からチームワークへ」ということを説明してきました。ただ、変わるというと全面的に移行しなくてはいけないように思われがちですが、"軸足を移す"といったくらいに受け止めてください。

次の議論はそのことにも関係するのですが、「5つの誤解」です。次のようなものになります。

(1) プロセス志向アプローチはどこにでも適用すべきだ
(2) IT化、自動化を目指す
(3) 新たな業務プロセスを開発する
(4) データや機能は重要ではない
(5) ワークフローのことである

では、まずは最初の「プロセス志向アプローチはどこにでも適用すべきだ」という誤解についてです。どういったアプローチにしろ、データ、機能、プロセスはみな必要です。ここで機能というのがわかりづらいかもしれませんが、まあざっくり言うとユーザインターフェースと考えてください。

プロセス志向アプローチは"プロセスを中心にして"みていきましょうという主張です。中心ということは先行してと言い換えてもかまいません。つまり、最初にプロセスを考えましょうということで、その後にデータだとか機能を考えるというやり方です。こうしたやり方がどこにでも通用するのかというとそうではないというのはお分かりになると思います。

データや機能を中心にしたアプローチは従来のITシステムでよくやられていたものです。画面とか帳票をベースにして、そこに登録・検索・出力といった機能を作るというものです。販売実績とか出荷実績といったデータを入力するとか、リソース系のデータ、商品、顧客、取引先、従業員といったものを管理するためのDRUD画面です。

確かに、こうしたシステムはもちろんバックヤードには必須ですし、それがないと決算出来ないわけです。ただ、単純なデータの出し入れですからプロセスはないのです。こうしたシステムがなぜか"基幹システム"と呼ばれて、ITシステムの本丸であるように捉えられていました。そこを考えなおそうというのがプロセス志向の問題提起なのです。

だから、こうしたデータの出し入れだけで済んでしまうような領域にはプロセス志向はなじまないのです。では、それ以外の領域はどういったところなのでしょうか。最も典型のところが「顧客接点」です。お客さんのさまざまなサービス要求に応えるところです。ここは単なるデータベースアプリケーションではうまくいきません。なぜならば、登録するデータを生成するまでが大事だからです。データを生成する過程がプロセスといえます。

このように適用する領域によってプロセス中心で考えるのか、それともデータを主体としてシステムを構築したほうがいいのかをきちんと見極めることが重要なのです。やみくもにデータ志向だプロセス志向だと一方に偏らないようにしたいものだ。