メイン

BPMの正しい理解のために アーカイブ

2008年7月28日

BPMの正しい理解のためにーはじめに

 いま、BPMが話題になっている。雑誌でも取り上げる回数や誌面が増えてきて、BPMを冠したセミナーも多く開催されているように思える。

ところがその中味は一律ではなく、百花繚乱とまではいかなくとも様々な切り口の提示がなされている。
もちろん、それぞれ特徴があるのだから、違いがあってもいいのだが、基本的なところで外れていたりするものもあるような気がする。

あまり変な方向に行ってしまうとバズワードにもなりかねないので、早めにゆずれないコアのコンセプト、技術、アーキテクチャ、技法などを整理しておいたほうがいいと思う。

このBPMは、事業運営からシステム開発あるいは開発後の運用まで含めた広範囲の概念である。それゆえ、その一部をもってしてBPMと言ってもらっても困る。まずはこの全体感がきちんと背景にあって語っている人が少ないことを指摘したい。

広範囲であるという意味は、ビジネスとITという昔から言い古されたフレーズかもしれないが、今度こそ本当に融合されるべきものだという意識がもてるかということでもある。

常々思うのだが、企業でITが導入されて以来、人間とITの位置関係は多少の変化はあったにしろ基本的に変わっていないのではないかと思っている。すなわち、ITが主で人間はそのITに使われていることです。

そこが今変わろうとしている。人間主体のシステムに変貌させるときが来たのである。そこを理解しないと意味がない。それができないと、単に業務フロー図作成ツール、もしくはIF文を書かなくて済むツールで終わってしまうのである。

そこで、BPMを正しく理解し、正しい導入の仕方を議論するために、なぜ変わろうとしているのか?どう変えたいのか?誰が望んでいるのか?どうしてできるのか?といったことを考えていきたいと思う。

2008年7月29日

BPMの正しい理解のために-変わること

前回、人間とITの位置関係が変わろうとしていると書いた。そのことについてもう少し言及する。まずこれまで変わってこなかったのだろうかという疑問がわく。

最初はホスト-端末の関係だったけど、クライアント-サーバー型になってITは奉仕する側になったじゃないかという人もいるかもしれません。でも本質的な変化だったのでしょうか。それは単にシステム的な役割分担が変わっただけで、人間とITの関係は変わってないのではないでしょうか。

ITの最初の登場は大きな電子計算機であり、そのときは順番待ちで使っていた。そういう状況ではコンピュータを使わせてもらっているという感覚でしょうか。そしてPCが登場して、パーソナル業務では自由に使えるようになりましたが、企業システムでは端末がPCに置き換わっただけでした。

そして前述したようにオープンシステム化しても基本となる位置関係は変わらないままだったように思います。すなわち、コンピュータシステムに命令されているかのように、決まったデータを決まったやり方で決まった時間までに打ち込むことであったのです。

しかし、よーく考えてみてください。会社の仕事というのは、組織としてやるべきことをその一員である個人が処理していくことです。それは自分たちが決めたルールに従って、自分たちのペースでやるべきもののはずです。そこに必要ならITを道具として使うというスタンスになるべきです。

そういう位置関係がこれから求められるのではないでしょうか。実はこうしたことはウエブの世界ではとうにやられていることなのです。ウエブの世界の主役は個人です。個人は好きなようにアクセスし、好きなサービスを選んで使います。そして、面白くなかったら消えていきます。ここでは徹底した顧客志向です。企業情報システムの顧客は従業員であるという意識はもっとあってもいいと思うのですがいかがでしょうか。

また機能的なことで言うと、ネットやウエブの最大の特徴はなんでしょう。別な言い方をすると、従来のコンピュータシステムと違う点はどこかということです。それは、「双方向コミュニケーション」、「オンデマンド」、「ハイパーリンク」ではないかと思っています。こうした機能の登場により、人間とITの関係もずいぶんと変わったものになりました。

逆の表現だと、「一方通行コミュニケーション」、「オンサプライ」、「ノンリンク」といったところでしょうか。これって、今の企業システムそのものでしょう。

ウエブでネットで普通にやっていることを企業システムに持ちこむだけでいいのです。だから、すごく難しい話というわけでは決してありませんが、最大の壁は既成概念にとらわれたシステム屋さんと今の仕事のやり方を変えたくないエンドユーザではないでしょうか。
 

2008年7月31日

BPMの正しい理解のために-プロセス中心で考える

人間が主役になって自分の導線あるいは組織のルールに従って仕事を進めるとなるとプロセス中心に考えざるを得ないことになります。

これまでにもデータ中心だとかオブジェクト指向といったやり方が提示されてきていますが、どうしてもコンピュータでハンドリングするデータはとか、プログラムモジュールに落とし込むためのオブジェクトはとかだったりして、いまいち現実のビジネスプロセスの表現という意味では物足りなかったのではないでしょうか。

いやちゃんとやればできるという声がDOA+コンソーシアムあたりから聞こえてきそうですが、少なくともユーザが見てすぐにわかるようなものになっていないのではないでしょうか。

やはり、いまユーザが実際に回しているプロセスの実相をそのまま表現し、それをあまり変えずに実装していくというのが必要なのだと思っています。ここの意識改革というか、発想の転換が大事になります。

少し話しは変わりますが、前回ウエブの世界と対比しましたが、いやあ、企業システムはクリティカルだから、ネットのシステムなんかと一緒にするなというようなお叱りをうけそうですが、そうですかねえ。これも考え方を改めたほうがいいのではないでしょうか。いまやウエブサービスの方がクリティカルであるし、パフォーマンスやキャパシティ要求も企業なんかとくらべると格段に厳しいように思う。

誤解されているかもしれないので整理をする。たぶん反論として、銀行のATMやそれこそ先日トラブルがあった東証のシステム、あるいはJRの発券システム、コンビニのPOS、宅急便のトラッキングシステムのようなものがあるという指摘があるかもしれない。いま議論しているのはこうしたその会社の本当の根幹をなすシステムは対象外です。

これらは、製造業でいったら製造設備であったり、生産ラインであったりするものだから、この議論でいっている企業情報システムとは一線を画しているので注意してください。

ですから、生産、出荷、販売、購買、会計、人事といった一般的な企業システムにウエブで行われていることを適用するのはそんなに難しいことではないと思いますがいかがでしょうか。

話は戻ると、ここではプロセス中心に考えることの重要性を言っているのです。顧客があるいは社員やマネジメントが一番わかりやすい考え方だからです。人が使いやすい、動かしやすいプロセスをつくり、コントロール&オペレーションするというのがめざすところになります。

2008年8月 5日

BPMの正しい理解のために-期待は何か

BPMへの期待は何かを考える前に、いまの仕組みで何が問題なのかということを考えていることにする。こういうときはだいたい使い手側と作り手側の両面から考えることが必要だ。ニーズの問題とシーズの問題である。それぞれにもつ問題点もあるし、相互の関係における問題も存在する。

ここで一番の問題は相互の関係性にあるような気がする。それはこのブログでも何回か取り上げている「情報の非対称性によるインセンティブの歪み」である。ユーザはITのことがよくわかっていない、ベンダーはユーザの業務のことがよくわかっていない、しかし作るのはコンピュータシステムであることからくるものである。

だからできたものの情報はベンダー側に偏ってしまう。いいですかここが非常に重要なところですが、“コンピュータシステム”を作るからこういうことが起きるのです。“動く業務プロセス”を作ってくれればいいのです。そうすれば、この情報の非対称性は解消されるのです。

こうした仕組みを提供してくれるのがBPMなのかもしれないと期待しているのです。喩えは少し無理があるかもしれないが、テレビゲームにある自分で好きなようにチームを作り選手を動かせるサッカーゲームのようなものがほしいのです。決してふざけて言っているわけではなく、おおかたの業務は結局こういうことではないのかと思う。

少々脱線したが、今の問題は事業を預かるマネジメントがその業務プロセスがどんな風にできているかがわかっていないことにある。そんな状態だから、いま何が起こって、これから何が起こりそうなのか、過去に何があったのか、という現在、未来、過去の事業の状況をつかめないでいるから不正や不祥事がおこるのである。

冒頭に設定したユーザおよびベンダーの個別の期待はどうなのだろうか。ユーザの期待は上述の説明で事足りそうだが、問題はベンダーサイドの期待である。ベンダーの最大の関心事が当然こういうことをやって儲かるのかということである。ここが非常に難しいところで、仕組みや仕掛けが革新的であれば、ビジネスモデルや収益モデルも従来とは違ってくるのは言うまでもない。

ここでは人月ビジネスの終焉だとかはあまり叫ばないが、ひとつだけ言っておきたいのは、IT業界ってこういうことが過去にもありましたよね。古くはハードウエア売りで添え物としてのソフトウエアからソフトウエア主体のビジネスへの転換、さらにサービスウやソリューションビジネスへの移行など、その都度対応してきたわけです。ですから、これからもきっとできると思いますがプレーヤーが変わっているかもしれませんね。
 

2008年8月 6日

BPMの正しい理解のために-IT化の余地はまだまだたくさんある

前々回にビジネスモデルが変わるというようなことを言ったが、おそらく今のようなソリューションがもつターゲット領域だけのビジネスを想定すると、かなりの生産性向上でコストも下がるのでパイが縮少して現状のベンダー数を食わせることができなくなるはずだ。それ以外でもオープンソースの使用割合の増加などチープ革命もあるので収益モデルが立ちにくくなる。

だからといって、嘆くなと言いたいのだ。実は、企業ではIT化の度合いはまだまだ低いのである。中堅・中小企業だけではなく、大企業においてもしかりである。ということは、いままでIT化されていない領域に拡大することによって収益を確保できる可能性は十分あると考えている。もちろん、そういうふうに事業構造を変えた企業が生き残っていくということは言うまでもない。

現状の会社業務をITを意識しないで書き出してみてください。いかに手作業が多いかに気がつくはずです。手作業でデータを固めて、それをシステムに投入するとか、いわゆる、調整、確認、連絡などの業務が多いことわかります。

しかも、そういうところで重要な意思決定をしていたり、手間がかかっていたりします。そこをIT化するのです。いっぱいありますよ。これまでのITはそれらを拾ってきていなかったのです。ですから、ここをIT化していけばまだまだ仕事はあるのです。それによりユーザにとってもウエブの顧客接点からバックヤードまでがつながるメリットがあります。
 
おそらく、この空白地帯を埋めるのにBPMが威力を発揮すると考えている。バックヤードの仕組みでは重たいし、ウエブでは業務のところが弱いということだから、そこの橋渡しをBPMでやるということなのだ。さて、それを誰がやるのか。
 

2008年8月11日

BPMの正しい理解のために-戦略の実行エンジン

BPMにおいて従来との違いでかなり大きなところは、BPMは事業戦略、IT戦略を実現するエンジンであることです。そんなことはすでに、ERPなんかで実現しているじゃないかという反論がきそうですが、ほうとうにできているでしょうか。

“戦略の実行”ということを考えてみて下さい。単にシステムを作ることではないということですよね。システム開発だけで戦略が実行できたとは思わないでしょう。意外とみなさんシステムを作りましたで終わってやしませんか。

そうなんですね、構築したシステムを日々動かしてこそできるのです。業務プロセスのオペレーションということです。目標との乖離を修正するためにオペレーションを変えるとか、BSCで設置したKPIを監視して所定値に収めるとかをすることが必要になってきます。

これまででも、こうしたことができるという人もいましたが、かなり難しかったのではないでしょうか。なぜなら、コントロールが効くシステムになっていないのにできませんよね。せいぜい死体解剖的に起こったことを解析することぐらいではなかったのではないでしょうか。

この概念こそがBPMが大きなインパクトを与えるものです。ですから、このことのために業務プロセスを可視化するのであり、責任をもっている人の掌中にプロセスをつかませてあげることなのです。

経営とITという言われ方で、戦略をITに落としこんでいくのだと意気込んでやりますが、つながっていたでしょうか。必要機能をアドオン、カスタマイズすることには熱心ですが、戦略は最初にえらいコンサルが入ってSWOTやBSCなどいろいろな手法を使って作るのだが、システムの開発が進むとそんなものはどこかに吹っ飛んでしまい、ただ動けばいいやというものができあがる。

繰り返しますが、これが従来のERPではなしえなかったことです。もちろんワークフローではいうまでもなくできっこありません。
 

2008年8月12日

BPMの正しい理解のために-プロセスだけではない

BPMというとプロセスだけのようにとらえられる節がありますが、そうではなくて機能もデータも重要です。企業の情報システムは基本的には「機能」と「プロセス」と「データ」からなりたっています。

「機能」というのは何かというと、業務処理だったり情報処理でもいいのですが、インプットされた情報を加工して新たな情報をつくることとも言えます。ただこれだとかなり細かいことまで含まれてくる可能性があるので、ここでは“単位意思決定”という定義にしたいと思います。

そうなると、誰が意思決定するのかということでそれぞれの機能が変わってきます。システムを使うひとは大きく、顧客、オペレータ、スタッフ・マネジメントにわけることができます。

依頼・問合せ・苦情などをしてくる顧客、オペレーショナルなデータを生成するオペレータおよびその責任者、経営視点で戦略的な意思決定を行うスタッフや事業部長・部門長といった人たちです。

彼らに対する機能は違うことはおわかりになると思います。機能の主なものはユーザインターフェースになりますからわかりますよね。ですから一律ではなくそれぞれの立場にあった機能を提供していかなくてなりません。これ以上は本論を外れるのでここまでにしておきます。

さて、データですが、データにも種類があります。リソース系のデータ、すなわちマスタデータとイベント系のデータ、トランザクションデータでしょうか。ただ、もう少し広義に解釈して、これにビジネスルールを加えたらどうかと思います。

ビジネス活動の糧となるデータ、あるいは参照情報、それとそうしたリソースを使っておこなったビジネス活動で生まれたデータ、それと意思決定で従うべき業務ルールである。業務ルールはリソース系のデータと言えないこともないのでそちらに含めて考えてもよいでしょう。

ということでBPMアプリケーションを構築するとなると、必ずプロセス以外の要素である、機能とデータはきちんと設計していかなくてはいけない。そのなかでも上述したようにいくつかに分解できるので、適正に分解し、それぞれに適した設計、ツール選定などが必要になります。
 

2008年8月19日

BPMの正しい理解のために-システム化範囲

いまの開発方法論ではどうしても上流設計とシステムに落とすところで結びつきが薄くなる。例えば、一生懸命業務フローを書いたのに、それがそのまま実装されることはなく、画面と帳票の設計にすりかわっていく。ええ業務フローはどこへ行っちゃったのということになる。

こうしたやり方では“システム化業務”といって、システム化できる部分だけをIT化して終わりである。IT化できるところがシステム化範囲となっているわけです。

ということは何のことはない、自動化できるところだけシステム化すればいいのだから、極端な話、上流設計はいらない。もっと簡単なのはパッケージやソフトウエアにある機能を使うだけでいい。

このブログを読んでくださっているみなさんはもうお気づきだと思うのですが、従来型の限界がここにあります。ですからここの発想の転換、逆の視点が今求められているのです。

ビジネスをオペレーションするには、IT化されていようが、そうでなくても業務プロセスとして一貫化されていなくてはいけません。そしてそれが見えていなくてはなりません。これが何度も繰り返しますがプロセス中心の考え方です。

そして、従来システム化されなかった部分であるコラボレイティブな業務がウエブサイトの情報共有空間で実現できるようになったので、そこと従来のトランザクション型の処理と一体化させることで一貫化された業務プロセスの構築が可能になったのです。

これが見える化でもあるのです。

もうひとつ大事なことは、設計と実装の乖離がなくなったことです。設計と実装が連続技としてできるということは、開発の手戻りとか仕様変更を回避できるようになります。

BPMの登場はここがポイントで、要求定義と要件定義がつながるのです。

ところで、どうして設計と実装の乖離がないかを説明しなくてはいけませんね。それは次回にします。
 

2008年8月20日

BPMの正しい理解のために-設計と実装の連続性

システム開発で設計というとこれまではシステム機能に寄っていってしまいます。どうしても、システム化あるいはコーディングするための設計になります。

ところがユーザが見ているのは自分たちのビジネスがどう実現できているかです。ですから、極端な話システム機能はどうでもいいのであって、自分たちの仕事の流れ、事業の実態が追えるかどうか、コントロールできるかです。

ですから、ビジネスを設計したらそれがそのとおり動く仕組みを提供する必要があって、以前“動く業務プロセス”というい方をしましたが、それがBPMでもあるのです。ただし、このときのアクティビティの定義が問題であまり細かすぎてもいけないし、大雑把でもいけないということです。

そして、上流の戦略から落ちてきたプロセスモデルがそのまま実装されるのが望ましいのです。従来はここに断絶がありました。システム化できる業務を抜き出してそこを実装するための設計・開発にはいるというわけです。

そうなると、ビジネスの連続した動きが見えなくなってしまい、そのシステムを動かすために人が動作するという逆転がおこるのです。

さて、この連続性を可能にするにはどうしたらよいのでしょうか。トップダウンアプローチとして上流から分解してくるプロセス粒度とボトムアップアプローチである実装を意識したプロセス粒度が合致することです。この設計と実装の交差点が定義できることが重要になります。

こうしたことができると上流から下流まで、戦略からIT実装までがシームレスにつながり、ビジネス側の要求がどう実現されるのか、ITの持つ機能がビジネスにどう生かされるのかが見通せるのである。

これがBPMの非常に大きな特徴である。言い方を変えると、こうした良さを引き出せるBPMを志向しないと意味がないのである。何度も言いますが、単なるワークフローでもなければ、プログラミングの自動化でもないのです。
 


2008年8月25日

BPMを正しく理解するために-経営とITの同期

いま、ぼくの周りで「経営とITの同期」ということが盛んに議論されている。先日もカリフォルニア州立工科大学の一色教授とのディスカッションでもこの言葉がでてきた。

ところでよくいわれるのが「経営とITとの融合」ですが、どうもよく考えると経営とITが融合するという状態がイメージできない。それよりも経営とITが同期するというほうがしっくりくる。したがって、これからは「経営とITの同期」ということにする。

ではその経営がITと同期するというのはどういうことなのだろうか。同期というからには経営側から見てもIT側から見ても整合的に同じように動くことを意味している。すなわち、

・経営に役立つITになっていること
・ITを使いこなす経営になっていること

だと言える。

これだと抽象的なのでもう少しわかりやすくすると、どういう状態のことをいうのかとなる。それは、

1.業務プロセスを可視化しコントロールしている
2.戦略を実現するために事業全体の適正なオペレーションができている
3.業務パフォーマンスの把握と戦略へのフィードバックがなされている

ではないでしょうか。

まずは、自分たちの経営や事業運営の核となる業務プロセスをコントロールできていることが大事です。何をやっているのかがわからないで結果だけ見せられた、成績はこうでしたといわれても手の打ちようがありません。いまのプロセスの状態を見えることで制御が働きます。

さらに経営方針や事業戦略が狙い通りに実現できるように事業全体をオペレーションすることがもっと大切なことになります。

こうして動いた業務プロセスのパフォーマンスや事業の結果をきちんとモニタリングして、評価して最初の戦略立案へフィードバックさせます。

要するに大きなPDCAサイクルを回すことなのです。しかしながら、これまでの問題点は、この戦略から実際に動く業務プロセスへのつなぎが不十分であるということなのです。

この問題を解決するツールとしてBPMSがあります。すなわち、経営とITを同期させるフレームワークがBPMSなのです。
 

2008年8月26日

BPMを正しく理解するために-日経SYSTEMSの特集から

今日発売になる「日経SYSTEMS」9月号は「SOAアプリの開発基盤BPMツール」というタイトルでBPMSの特集を組んでいる。

ぼくもこの記事に関する取材を受け、ひとことだけ載っていたが、この記事について考えてみる。

まずは率直な感想は今のBPMの課題が浮かび上がったということである。どういうことかというと、事例として出ているものをよくみると2つのタイプがあることがわかる。

ひとつは佐世保重工の例にあるように機能とプロセスを分離して、機能をサービスとして外部化することでプロセスに組み上げるモデリングである。一方、他の事例では申請・登録系などを対象としたワークフローツールとしてのBPMSである。コードレス志向で開発生産性を高める方向に重きを置いたものである。

この二つの間で大きく違うのは、サービスの粒度である。前者は比較的大きな機能という捉え方ですすが、後者はそれよりも小さな粒度であるアクションレベルのものをBPMSでつなげている。

この二つでどちらが良くてどちらが悪いというわけではない。もちろん両方ともありだが、両方とも何かが足りない。

大きな粒度でプロセスを作ったときは、実装にどう落とすかという問題が残る。一方、ワークフローだとコアに近いところの業務プロセスへ展開した場合、膨大なアクティビティ数になってしまい、プロセスの可視化が難しくなる。

ということは、両者の課題をうまく解決すればいい。ビジネスモデルから業務プロセスへ落としこみ、それを動く仕組みとして実装していかなくてはいけないわけで、まずはビジネスモデルから業務プロセスへ連結性を維持するには大きな粒度がいる。それはそれで大きな流れのプロセスを作るのだ。これはマクロワークフローでもある。

次にその“粒”=アクティビティ・機能の中を細分化されたフローに分解するのである。これはミクロワークフローで、申請・登録などはこれにあたる。

こうしたレベル化がポイントである。マクロワークフローとミクロワークフローに分けたが、言い方を変えると、固定的(静的)プロセスと変動的(動的)プロセス、あるいは戦略的プロセスと戦術的プロセスともいえるのではないでしょうか。

この記事からうかがえるようにまだまだBPMについての定義や体系が定まっていなく、人によって語っていることが違っていることも多い。

これから、いろいろな議論や実績の評価により、輪郭がはっきりしてくると思うが、単なる新しい個別のソフトウエアだとかアーキテクチャというだけではなく、業界構造やIT人材像なども変えていくほどの影響力があるということだけは確かだと言えそうだ。
 

2008年8月29日

BPMを正しく理解するために-要求定義と要件定義

経営とITの同期を議論していくと、経営の要求をどうITに反映させていくのかとう問題が出てくる。ここの議論での焦点は、「要求定義」と「要件定義」の違いである。

米国ではこの前者の「要求定義」のための「要求工学」というのがしっかりとあるというのは一色教授の話にもあった。「要求工学」というのは要求獲得―要求仕様化―要求検証―要求管理というサイクルを工学的にやろうという動きである。

日本にも要求工学はあることはあるし、要求開発というコンソーシアムもあるのだが、概して、「要件定義」に寄っている。どういうことかと言うと、システム化するための要件、システムとして備える要件に持っていってしまうということである。

そうなると端的にいえば、システム化できる業務だけに限った要求になってしまう。この時点で、経営とITの乖離が起きる。経営戦略の達成は何もIT化できる業務だけでできるわけではなく、手作業やコラボレーションなども重要な手段であるからである。

ここが従来の上流設計と言われるところの不備である。ですから、いつのまにかビジネス上の要求がとんでいってしまい、単なるコンピュータシステムを作ることになってしまうのである。

ですから、要求工学に則ってきちんと要求を定義し、それは崩さすIT化するという連続性を担保した要件定義にならなければいけない。

もう少し詳細化していうと、経営戦略たとえばバランススコアカードで設定したKPIなどを実現するための業務プロセスを大きな流れから徐々に分解していきます。このときは、人間系でやろうがITでやろうが関係無しに、業務のアクティビティとして定義します。そこで定義したアクティビティを定型ITとともに不定型なコラボレイティブな場とで実装していくのです。このあたりは、設計と実装の連続性のところで書いたとおりです。

こうしたレベルになってくるとオペレーショナルな観点で決めていくので、より柔軟に考えていけばいいのです。すなわち、使う人の使い勝手で変えてもいいし、新しい技術ができたら乗り換えてもいいのです。それは戦略的な要求を損なうものではありません。

ですからここでの議論である、「要求定義」と「要件定義」の違いを正しく理解することが非常に重要なことといえます。


2008年9月 1日

BPMを正しく理解するために-ITは投資かコストか

先日、ITC協会の研究会のあとの呑み会で題記のような議論になった。

80年代を謳歌した日本産業界も90年以降、アメリカに置いてきぼりを食ってしまった。その原因は、IT化の質と量の差である。

アメリカも、80年代はまだコスト削減が主体のIT投資であったが、その投資対効果が疑問視され、もう少し戦略的に投資しなくてはいけないということに気がつき、その領域への投資額も増やしていったのである。

反対に日本は相変わらず維持保守のための投資が主体で、それ以外でも自動化による省力化だとかいった効率化を目指したものにカネをかけている。

要するに、日本では情報システムはコストと考えているが、アメリカでは投資というようにとらえているから、ROIをちゃんと評価してやっている。この差が大きいのではと言うような議論であった。このあたりのことは。野口悠起雄も「ジェネラルパーパステクノロジー」で書いている。

別な言い方をすると、コストと考えているうちは経営戦略も何もないのだから、前回に言ったような「経営とITとの同期」なんてことは関係ないのだろう。

しかし、前述したように日本経済の弱体化をもたらした大きな要因に戦略的IT投資ができていないことがあげられるわけで、そうなるとだんだん経営者もわかってくるので、これから有効なIT投資をどうしたらよいかという問いかけが活発になることが予想される。その答えは、いままで言ってきている経営と同期したITの構築ということになるのです。

2014年6月30日

事例に学ぶBPM成功のポイント(1)

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

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

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

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

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

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

  

2014年7月 7日

事例に学ぶBPM成功のポイント(2)

(2) 戦略課題の具体化と解決
リーマンショックのような経済全体が減速してしまうような場合、売上の落ち込みが激しいのは標準在庫品です。何がなんでも必要というわけではなくユーザにも在庫もあるでしょうから買い控えもできるからです。つまり標準在庫品の販売は景気の変動に弱いという性格をもっています。景気が安定して経済成長も右肩上がりの時は問題なかったのですが、経済成長は停滞しているがビジネス環境のへ変化が激しい時代ではそうした時代にマッチしたビジネスモデルに変える必要がでてきました。

ビジネスモデルを変えるには戦略が必要です。そこでよくとられるものが顧客・市場戦略です。事例では、標準在庫品では景気に左右されるというのなら特注品にシフトしたらどうかというのが新たな戦略として出てきました。こうした戦略立案には理論あるいは技法のようなものがあるのかというとありません。おそらく経営者のひらめきがいちばんではないでしょうか。

しかし、単なる思いつきというわけではありません。大事なのは経営者の頭のなかにこうした会社にしたいという経営理念、こんな事業をやりたいというビジョンがしっかりともっていなくてはいけないということです。そしていったんやると決めたら従業員に対して明確に考えを伝え、思いを共有することが重要です。

ところが、その掛け声だけでは新しい戦略の実行はできません。必ず、何か新しいことをやろうとするとそれを阻害するものが現れます。一番大きな阻害要因はいったい何でしょうか。これもよく言われるかと思いますが、従業員の意識の問題です。大部分の人は基本保守的ですから、今やっていることを変えたくないという意識が働きます。

ここでもまた、「意識を変えろ」とか叫ぶだけでは変わりません。従業員は変化の結果として自分の仕事がどう変わり、負荷がどうなるのか、責任が重くなるのかといったことが気になります。それがわからないうちは不安のほうが先にあって、そのためにどうしても保守的にならざるを得ないわけです。

また、会社として収益がどうなるのか、売上が増えてくれるのかといったことを示してくれたら、儲かりそうだからがんばってもいいかなと思うのです。つまり、会社として、事業としての変化の仕方とその結果についても、そして個人としてのタスクがどうなるかを見える化することが大変重要なのです。

それと、現実的な阻害要因の洗い出しも必要になっていきます。リソースの問題として不足はないのか、業務管理として不備はないのか、いまの組織や責任の所在で対処できるのかといって検討である。事例では、特注品へシフトするわけですから、顧客要求をきちんと聞き取らなくてはいけませんし、また設計者の負担も増え、ちゃんと見積もりをしないと赤字なのに受注してしまうといったことが浮かび上がってきます。そこから課題を抽出していくわけです。事例では下記のような課題が出てきました。

・ベテランの営業に依存しない要求確認
・収益性を確保した見積
・役割分担の確化

BPMアプローチでは、プロセスを記述することで会社全体、事業全体といったマクロな視点での見える化ができ、また詳細化したプロセスでは、課題を解決するために必要な機能がはっきりしてきますので、新しい戦略を実現するオペレーションのイメージが出来るのです。

【成功のポイント】
トップマネジメントが経営理念に基づいて明確なメッセージを発信し、強いリーダーシップを発揮すること
  


2014年7月17日

事例に学ぶBPM成功のポイント(3)

(3)継続的な活動
BPMの非常に重要な考え方に継続的な活動というのがあります。よくBPMとBPR(Business Process Reengineering)が混同されますが、BPRというのは、時限的に改革するイメージです。それに対してBPMは継続的な活動です。ここまでやれば終わりということがないのです。

プロセスというのは、化学プロセスや生産プロセスなどをみてもわかるように所定のアウトプットを出すために連続的に稼働させるものですから、そうしたコントロールすることと同時により早くとかより多くといった改善を行って行きます。ビジネス・プロセスも同じように絶えずプロセスの状態をセンシングして、管理範囲から外れないようにコントロールしなくてはいけません。

継続的な改善活動は、プロセス内での改善、たとえばアクティビティを中抜するとか、適用ルールを変えるとか、参照情報を増やすとかいった改善もさることながら、新しいプロセスを追加するといったこともあります。ビジネスモデルを変えた結果、それに見合ったプロセスが求められた場合とかです。

本事例では、取り扱い商品を標準在庫品から特注品へとシフトしました。そこでのキープロセスは「見積提示プロセス」でした。顧客要求をきちんと把握して、それを設計部門にエスカレーションして、粗々の設計を行い、提案図面や原価を算出してもらい、製造部門と相談して納期を決め、見積書を作成するといったプロセスです。

最初の重要なポイントは顧客要求確認シートです。特注品の場合は顧客の真の要求を聞き出すのはなかなか難しいものです。ベテランの営業だと経験から導き出すことができるかもしれませんが、若手だとインタビュー項目に抜けがあったままで設計に渡したりするので、聞き取りをやり直すこともしばしばでした。そこで、あらかじめ聞くべき項目を設定してそのシートに埋め込むことにしました。

ただ、最初から完璧なものはできるわけではありませんから、とりあえず必要最低限のものを用意しておいて、不足するものがあったらあとで追加するといったやり方をしました。ですから、常に追加、修正を繰り返すしながらブラッシュアップするわけです。こうした継続改善は他のアクティビティでも同様にやっていきます。

こうしたことで特注品の売上も伸びたのですが、既存顧客を相手にしているとやはり頭打ちになってきます。そこでビジネスモデル上の顧客セグメントを見直すことになります。新規顧客の開拓が必要になるわけです。そうなると、いままでのプロセスだけではうまく行かなくなります。ビジネスモデル要素のどこがポイントとなるかによってキープロセスも違ってきます。

この場合は言うまでもなく「新規顧客開拓プロセス」ということになります。どういう業種業態なのか、地域はどこなのか、会社の規模はとかのターゲットを決め、キャンペーンをどんな風にやるのかといったことが並んだプロセスが対象となります。といったように、日常的な課題を解決するようなところから、ビジネスモデルの変化に対する対応といったところまで、継続的な活動を行うことが大変大事なことになのです。

【成功のポイント】
継続的な取組みでプロセスを進化させること
  

2014年7月29日

事例に学ぶBPM成功のポイント(4)

(4)期待と効果
BPMに何を期待するのでしょうか。その期待に既存の手段では応えられなかったからBPMに期待するのでしょうか。もし、このあたりが明確になっていて、効果が実感できれば、今頃は大ブームになっているはずです。ところが、徐々に浸透してきているとはいえまだまだのようです。ということは、期待するところがないのか、期待することはあるのだがBPMではできそうもないと思っているのかのどちらかなのでしょう。

おそらく今の経営者は期待するところというか、自分たちを取り巻く環境の変化に対して臨機応変に手を打っていかないと持続的な発展どころか事業の継続さえ危なくなるという危機感は持っていると思います。ですから、俊敏にかつ的確に経営の舵取りができる仕組みと仕掛けを期待しているはずです。

そうした期待をかつてはERPやCRMなどに求めたと思いますが無理だったというのが定まりつつあると思っています。ただ、まだまだERPを入れればプロセス改革ができると思っている人もいるように、大金をかけた割には効果がないと分かっていながら、ではどうしたらいいのかと悩んでいるのかもしれません。そうした人たちがそこはBPMだとなぜ飛びつかないのでしょうか。

プロモーションの不足といえばそうなのだが、難しいのは、これこれの問題があるからそれを解決するものとしてBPMがあるといった単純さで訴求できないところがあることです。たとえば、在庫が多いからそれを削減するために在庫管理システムを作ろうといった場合などはわかりやすいのですが、BPMと在庫削減が結びつかないと言われてしまうのです。

つまり、BPMというのは大前提が"ビジネス(事業)全体のプロセスを記述する"ということなのですが、そこがなかなか始められないのです。大前提という意味は、プロセスを書くことで自分たちのやっている事業がいったいどんなものなのか、どんなことをしているのかが俯瞰できるからなのです。すべてはそこから始まるのです。先ほどの在庫の問題にしても単に在庫の部分だけを見ていては、真の原因を見損なってしまうこともありえるのです。

自分たちの事業をプロセスという姿で掌中に納めれば、そこにどんな問題が潜んでいるのか、こういう戦略を実行するにはどこのプロセス改革を行えばいいのかがわかるようになります。これがBPMに期待する大きな理由です。ただ、いま言ったように直接的な問題解決にすぐにいけないので、"せっかち"な経営者になかなか理解してもらえないのかもしれません。

BPMのプロセスを記述して俯瞰して見るということは多くの効果をもたらします。本事例でも、まずプロセスを書いてそれを皆で眺めているとさまざま問題点や課題が浮かんできました。というのも、プロセスというのは多くの要素から成り立っていますから、どの要素に問題があるのかがわかるわけです。業務ルールの不備で混乱しているとか、責任の所在がはっきりしていないとか、同じような仕事を重複してやっているといったようなものが抽出され、そこを改善することで多面的な成果が生まれてきます。成果の主なものは次の3点でした。

① 事業成果の実現
② 人材育成、組織能力の向上
③ IT投資の低減

事業成果の実現では、当初の狙いが、標準品から特注品にシフトして売上を増加させることでしたが、それは特注品の売上を前年比でほぼ倍増させることができて成果を確認できたのですが、予想外というかうれしい誤算だったのが②の人材育成、組織能力の向上という成果です。

え、BPMで人材育成、組織能力の向上?と思われるかもしれませんが、実際に成果が上がったことです。プロセスで自分たちの業務も捉えるわけですから、自分が何をすべきか、他の人が何をやっているのかが見えてきます。そうすると、チームで働くことの意義を自覚でき、結果的に組織能力も向上し、人が育つことにつながるのです。

【成功のポイント】
ビジネス成果を得るには自分たちのビジネスプロセスを手のひらに乗せること、またBPMの大きなメリットである人材育成・組織能力の向上には、多くの人を参加させて大いに議論し成果を共有できる体制をとること

  

2014年7月25日

プロセス思考のすすめ(1)

プロセス志向とかプロセス中心アプローチとか言っている。しかし、正直なかなか理解してもらえないところもある。経営者もさることながらシステム屋さんにもよくわからないとか難しいんじゃないとか言われることがある。どうも、開発方法論のような技術に寄った見方をされるとそう思われるのかもしれない。そこで、志向ではなく思考ということでプロセスを考えてみようと思う。論理的思考やデザイン思考といった位置においてみたらどうなのだろうか。

ビジネスをプロセスという観点で捉えてみようということである。この見方はどこの会社でもやっていると思われがちだが、意外にもできていないというのが実感だ。例えば、経営者が自分たちのビジネスを何でつかまえているかというと決算結果と人と組織である。決算結果は月次なのか日時なのかという違いはあるにしても、実績データとそれを加工した情報から成り立っていて、経営者はそれを見て会社がどうなっているのかつかみます。

また、誰がどうやったのか、組織として機能したのかといった見方もよくやっていて、うまくいかないと人事異動と組織変更に手をつけます。企業活動というのは、ざっくり言うと、「組織目標に従って、様々なリソースを使って、顧客の要求にプロセス活動を通じて応えて、事業成果を上げる」というものです。この、組織目標、リソース、プロセス活動、事業成果(決算)という4つが主要な企業活動エリアになります。

最初に言った実績管理と人・組織は、事業成果(決算)とリソースのエリアのことです。組織目標は良し悪しは別として会社経営していれば必ずありますが、プロセスのところが抜け落ちているように思うのです。というか、あまり関心がなくて、現場に任せてしまっているというのが実状でしょう。また、同じようなこととして今までのシステム屋さんの関心も決算とリソース管理になっています。

そういった状況でプロセス志向といっても、プロセスでビジネスを捉えられないとシステム開発手法ですかみたいな議論に陥る。そこで、プロセス思考を考えてみようと思ったのである。プロセス思考の要諦は、まずはプロセスを描いてみようということです。自分たちがやっているビジネスはどういうプロセスから成り立っていて、どんな活動をしているのかを書き出すことで発想が生まれてくるということなのです。

プロセスは階層構造になっていますから、大きな括りである業務機能のようなところから分解していきます。階層的にみていくというのも大事で、組織の階層と対応付けるとマネジメントの管理すべきレベルと範囲が明確になってきます。例えば、ハイレベルのプロセスは部長、ローレベルはブループリーダーの管理範囲といったことがわかってきます。日本の会社では、課長が部長の仕事をしているとか、その逆で課長のくせに担当者のしごとしかしていないなんてこともわかります。また、越権行為もみつかるかもしれません。

その他、リソースの過不足とか判断基準がないため属人化しているとか、BPO(Business Process Outsourcing)できるとか、さまざまな改善・改革テーマが浮かんでくるはずです。従って、描いたプロセスを見ながら皆がああじゃないこうじゃないと議論し合いながら考え、アイデアを出すという思考法は非常に有効だと思うのです。
  

2014年7月31日

プロセス思考のすすめ(2)

前回、プロセス思考ということでまずプロセスを描いてみて、そこから改善・改革のアイデアを出していくという思考法についてエントリーしたが、もう少し補足しておこうと思う。前回の指摘の中に経営者のプロセス意識の薄さを言ったが、ではミドルマネジメントとか担当者はどうなんだという話から。

実際の現場で活動しているのは主に担当者なのだから、やっていることはプロセスオペレーションである。しかしながら、おそらく上位のプロセスのことはあまり考えていないように思える。つまり、自分のやっていることは広い範囲のプロセスの中のどこに当たるのか、他のプロセスとどう結びついているのかといった見方はあまりしていなのではないでしょうか。

さらにいうと、前回提示した4つの主たる活動領域のうちの組織目標とか事業成果についても無頓着のような気がする。ミドルマネジメントも経営者と担当者の中間的な感じではっきりとしたプロセス観はないと思う。プロセス思考ではこうした各階層の人が一緒になって議論すること(大企業ではトップマネジメントは事業部長)が大事で縦と横の関係も明確になっていく。

もう一つ前回の指摘で経営者の興味は事業成果とリソースにあるということがあったと思うが、ここも大きな問題でプロセス思考をしていないからこの程度に留まっている。まあ、業務システムそのものの対象も事業成果とリソースに行っているからしかたがないのかもしれないが、この変化の激しい時代にそれでよしと思っているのだろうか。

もちろん、先進的な企業だとか小売のようなたえず顧客の動きを見ていないといけない業種などでは、実績を集計してああじゃないこうじゃないなんて言う前に手を打っている。だが、大方の企業はまだ前月の実績を一生懸命分析して一喜一憂している。これは言ってみればちょっと表現はきついが"死体解剖"である。死んでから死因はこうだったと報告する。これでは後の祭りというものだ。

本当は、死体解剖ではなく"生体ドッグ"をしたいはずである。どこか具合が悪そうな兆候が出たらすぐにその原因を突き止めて対処して健康体に戻すというアクションを行うことである。これは、プロセスが描けてオペレーションされコントロールできて初めて可能になるのではないでしょうか。悪い兆候はどこに現れるのでしょうか。どこをみれば原因がわかるのでしょうか。何をすれば戻るのでしょうか。

これらはみなプロセスに備わったものです。言い方を変えると、そういうことがわかるようにプロセスをデザインするということなのです。プロセスを描いてみて、健康体であるべき血圧や血糖値などの基準値をきめて、それをたえず検知するような仕組みをすればよいのです。なぜプロセス思考が大事なのかというのは、こうした健康管理ができる仕組みと仕掛けを考えつくことができるからなのです。病気になってから、死んでからでは遅いのです。
  

2014年8月 7日

事例に学ぶBPM成功のポイント(5)

今回からは、実際にプロセスをどう設計していくかというお話になります。

2. プロセスデザインの進め方  
(1) 対象プロセスの特定

「特注品で新分野を開拓し売上げ・利益をのばす」という戦略に対して「ベテランの営業に依存しない要求確認」「収益性を確保した見積」「役割分担の明確化」といった課題が抽出されました。

特注品だと顧客がどんなものを望んでいるのかをきちんと把握する必要があります。しかし、これはある程度の経験やノウハウがないと難しいのでどうしてもベテランの営業にたよってしまいます。若手でも的確な要求確認ができるような仕組みが要るなあということになります。また、原価を計算しないで要求通り作ってみたら赤字だったなどということも出てきます。特注品は粗々の設計をしますから、顧客要求に対する設計の関わり方も問題になってきます。

こうした問題点をみていくと、最も優先して整備すべきものは何かが見えてきて、それが「見積提示プロセス」であると結論付けました。このように、戦略からそれを実現するための阻害要因を検討し、課題化したものを解決するための狙い所のプロセスを特定していったのです。いきなりこのプロセスにBPMを適用してみましょうといった取組を見聞きすることもあるのですが、単に効率化の手段としてという意味は多少はあるかもしれませんが、大事なことは、戦略とか事業方針といったものとの連動性を持ったBPM適用が効果的です。

さらに、その後特注品という新規商品へシフトしても既存顧客の範囲では限界が出てきて売上げの伸びが止まったため、(STEPⅠ)顧客の範囲を拡大した新たなビジネスモデルを設定し、それを実行するために営業プロセスの中の別のプロセスである「プロモーションプロセス」を対象としたBPMを実行しました。(STEPⅡ)

対象プロセス.png

このように、BPMをいきなりプロセス設計や実装から入ってしまうのではなく、新しい戦略に沿ったビジネスモデルからBPMを適用すべきプロセスを選定していくアプローチが大事になってきます。つまり、ビジネス上の要求の受け皿としてプロセスがあるということなのです。

【成功のポイント】
ビジネスモデルに戦略や課題を記述して、そこを起点としてプロセスにマッピングすること


2014年8月 4日

プロセス思考のすすめ(3)

今回は少し視点を変えてみましょう。「働き方改革とプロセス」というテーマで考えてみます。これを一緒にして考えることなのかと疑問に思われる方も多いでしょうが、実は結び付きがあるという話です。今年の6月24日に「日本再興戦略」改訂2014というのが発表されましたがご存知でしょうか。昨年のものには政策項目ごとにKPIが設定されて、PDCAサイクルを回して進捗管理をすることになっている。どこのコンサルが入ったかどうか知りませんが、企業みたいですね。

それで、今回の改訂ではこの1年間のKPIの達成度の評価と確実な達成のための追加施策を明確にしたのだそうだ。アベノミクスの成長戦略もあまり評判がよくないのだが、そこには言及せずに、ここの中で謳っている「働き方改革」を読んでいてプロセスとの関わりを思い至ったのである。そこにはこう書いてある。

昨年の成長戦略では、個人が円滑に転職等を行い、能力を発揮し、経済成長の担い手として活躍できるよう、行き過ぎた雇用維持型の政策から労働移動支援型の政策へと大胆な転換を行った。 改訂戦略では、多様な正社員制度の普及・拡大やフレックスタイム制度の見直しに加えて、健康確保や仕事と生活の調和を図りつつ、時間ではなく成果で評価される働き方を希望する働き手のニーズに応える、新たな労働時間制度を創設することとした。

この中で大事なことは「雇用維持型から労働移動型」「時間評価から成果評価」という流れであろう。つまり、終身雇用をなくし、雇用を流動化し、単にいるだけで給料をもらうのではなく成果に合わせてもらうということだ。人々のマインド変化がおきるのかというとそう簡単ではないと思う。日本での成果主義は挫折したこともある。

給与体系上では職能給から職務給へのシフトということになる。つまり、主に在籍年数をベースにして与えられる職能レベルで給与が決まる、いわば年功序列型のものから、年功とは関係なしに、与えられた職務でどれだけの成果をあげたかを評価するのだ。ベテランだろうが若手であろうが関係ない、仕事ができたかどうかだけである。これまでずっと日本型の慣行としてあったものが崩れていくのである。ただ、単にアメリカ型にもっていくのではなく、日本型の成果主義にしてほしい。

さてこうした制度の場合、重要な問題が、成果をどういう尺度で誰が評価するということである。いかに客観性をもたせて、だれもが納得する標準的なものになるかどうかは大変難しい。なぜ難しいのだろうか。おそらく、職能については経験とか資格試験とかで評価指標はある程度できるのだろうが、職務というときちんと職務の定義ができていないことが大きいのではないでしょうか。

もちろんどこの会社にも職務要件書とか職務分掌というのがあります。しかし、それらは個別タスクを主体に作業項目をあげているにすぎないと思います。ですから、"成果"という観点からの職務とは違うのです。そこで、プロセス思考なのです。プロセスというのは何度も言いますが、戦略や事業方針といったものを実現するための表現手段ですから、そこにはどんなことをすれば事業成果が達成できるとか、誰が責任を持って的確な意思決定をしたか、それこそKPIをブレークダウンして管理指標が個人にも降りてくるといったように成果との関係が明確なのです。

従って、プロセスをきちんと記述してそのプロセスのどの部分で自分の役割があって、そこで何をなすべきかがはっきりしていれば、自分がやったことがどんな成果をもたらしたのか、その逆に自分の失敗でうまくいかなかったとかがわかるわけである。それを、オープンな世界で実行していけばおのずと客観的な評価に近づくはずである。ということで、「雇用維持型から労働移動型」「時間評価から成果評価」の変革を実現するには、自分たちのビジネスプロセスをちゃんとコントロールできているというのが前提なのである。
  

2014年8月12日

プロセス思考のすすめ(4)

ぼくは、元々がプラントエンジニアでケミカルプロセスを見ていたから、プロセスという言葉がすんなりと入ってくるのだが、意外となじみがないひとが多く、プロセスチーズは知ってるけどなんて冗談を言われる。チーズの場合は、「ナチュラル」に対して「加工」という意味で付けてられたのだそうだ。この加工という訳は若干違うがだいたい合っていると思う。目的のものにするまでにいくつかの処理を行ってそれが終わると完成品となるからである。要求に対して複数の加工(意思決定・判断)を行っていくと言ってもいい。

食べ物の話が出たついでに言うと、プロセスになじみのない人にわかりやすく説明すると"サービス"という概念を持ちだしたほうがいいのかもしれない。おもてなしの精神ですね。サービスと言うのはサービス学会の定義でいうと「提供者が受給者の望む状態変化を引き起こす行為」だから、レストランなどの食事サービスなんてまさにこのことです。お客さん(受給者)のおいしいものをお腹いっぱい食べて満足したいという望みに対して、料理の美味しさだけではなく雰囲気とかおもてなしなどを店側(提供者)が提供するわけです。

だから、プロセスとはサービスのことであると言ってもいいかもしれません。また、外部の顧客に限らず内部の人間でもサービスの受給者となると考えるといたるところにプロセスは存在するといえます。ところで最近では日本の"おもてなし"が注目されていますが、日本料理と西洋料理の違いについて考えてみました。料理の中身のことではなくサービスという観点からみると違うように思える。

どうも日本の料理というのは徹底した顧客志向なのではないと思う。お客さんが楽しめるように、お客さんが満足できるように工夫を凝らす努力をすごくしているように思える。素材から、あるいは風景の取り込みから、さまざまな角度からサービスを提供してくれている。ところが、それに対して西洋料理は、顧客志向ではなくむしろプロダクトアウト型ではないでしょうか。

つまり、こんないいものを作ったので食べろとか、俺の料理はだれにも負けない凝ったものだからうまいはずだといった押し付け型のような気がする。ミシュランのように店にランクを付けることからもうかがえるでしょう。どうだ3つ星のレストランはうまいだろうといったように、お客さんのほうが食べさせてもらっているという感覚である。

と書いたところで皆さんあることに気がつきませんか。企業の"もの作り"と似ていますよね。それで日本の製造業と対比してみてください。これまでの日本における製造業のもの作りはどうも押し付け型ではなかったのか。よいものを作れば顧客が喜ぶはずだ、だから売れるはずだという態度である。だから不思議なのだ。日本の料理にはおもてなし精神があるのにそれとは対極のサービスを提供していたのだ。"おもてなし製造業"というのもあってもいいと思うのである。
  

2014年8月14日

事例に学ぶBPM成功のポイント(6)

(2) プロセス分解
前回対象プロセスの特定ということで営業プロセスの中の「見積プロセス」と「プロモーションプロセス」に絞り込みましたが、まだこのレベルだと抽象度が高く粗いものになっています。実務上のオペレーションレベルまで持って行くには分解・詳細化してかなくてはいけません。これをどうやって行くか、どこのレベルまで分解すればよいのかが今回の論点になります。

この分解・詳細化をいちいちやっていたのでは大変です。そこで参照モデルを使うことにします。というのも、ハイレベルのプロセスであれば、どこの会社でもほとんど同じものであるはずだからです。それぞれの会社の"クセ"や"こだわり"出るのはずっと低いレベルになってからなのです。従って、世の中にある標準的なモデルを活用するのが一番てっとり早く楽な方法です。例えば、SCOR、VRM、PCF(APQC)、ESCORTなどがあります。

しかしながら、モデルもレベルを下げて行くとモデルの数がどんどん増えるのと例外なども出てきますので割と高次でとどめています。(ESCORTが最も低い)このレベルだともちろん実装はできませんから、実装レベルのプロセス設計はあくまで参照モデルを分解・詳細化していくのか、あるいは業務実態に合わせて設計していくのかの選択になってきます。ところがどちらか一方でやるのは効率的ではないので限界があります。従って、現実解としては、両者を合わせたハイブリッド型のアプローチになります。

つまり、「参照モデルを使ってトップダウンで枠組みを作り、それをベースに現実の業務をボトムアップで当てはめる」やり方を推奨しています。参照モデルは網羅性に優れていますが、それゆえに冗長的になります。一方、ボトムアップは所詮AsIsベースですから抜けがあったりします。ですから、お互いを補完する関係を作るのがハイブリッド型アプローチの肝です。

ハイブリッド.png

事例では、最初は営業プロセスの「見積プロセス」というレベルまで分解していきました。そのモデルをベースにして、現実の業務がどうなっているのか実際に営業活動をしている人を中心にディスカッションしながらプロセスを設計していきました。そこから「特注品見積提示プロセス」に詳細化されました。やはり、お手本があるかないかでずいぶんと違ってきます。議論のきっかけにもなりますし、地図があるかないかで行き先のイメージもわきやすくなります。

【成功のポイント】
階層化されたプロセス参照モデルと現有プロセスを併用したハイブリッド型のアプローチで行うこと


2014年8月28日

プロセス思考のすすめ(5)

ちょっと前に「ヤンキー化する日本」(斉藤環著 角川oneテーマ21)という本を紹介したが、ヤンキーという表現をしているが日本人の一般的な性癖だとか考え方といったものを論じている。その中で日本の近現代史の研究者である与那覇潤さんとの対談で「ヤンキーの人は感性を肯定するために知性を批判する」「言語を根本的に受け付けない性質」「日本人は、閉じた世界のシステムを現実と結びつけるのは苦手、閉じた世界であれこれ操作するのは得意」といった論評がすごく印象的だった。

そのことを考えていたら、ふと浮かんだのがこれは日本人がプロセス思考を苦手というか、そういったアプローチをなかなかとらない原因ではないかと思ったのである。実は、プロセス思考というのは、論理的であり、言語的なのである。それで、プロセスを考えましょうというとよく言われるのが、現実は理屈どおりにはいかないよとか、難しいこと言うなよなといった批判がすぐに出てくる。

このことは業務システムの構築局面での話が多いので従来のシステム屋さん(技術屋さんもコンサルも含めて)が従来の非プロセス思考を引きずっていることもあるのだが、もっと日本人の底流に流れている先述したような特徴も影響していそうだ。つまり、仕事なんかそう論理的にできるものではなく、気合でやればいいし、「絆」が大事で愛と信頼があればうまくいくんだという精神があるように思える。

こうした世界はITとの親和性が乏しい。私的な領域では問題ないかもしれないが、特に企業におけるビジネス活動においてはIT活用、システム化の妨げになっているように思う。だから、プロセスを中心にあるいはプロセスを先行して考えましょうと言っても個人がいかに気合をいれられるかといった閉じた世界をシステム化の対象にもってくる。業務の効率化とか、作業改善が先でそのあとにプロセスを考えましょうとなってしまう。順番が逆でしょうと思うのだがこのパターンが多い気がする。

個々の業務を開かれた世界にして現実と結びつけることが大事なのにこれがなかなかできない。この現実との結びつきを仲介してくれるのがプロセスだと思うのだがいかがでしょうか。究極的には企業におけるビジネス活動は「人とプロセス」だとも言える。人が行うタスクという点がプロセスによって、線や面になっていくわけで、そのあたりを実現するためにも、苦手なプロセス思考を採り上げてほしいと願っている。
  


2014年9月 3日

プロセス思考のすすめ(6)

テレビ東京で毎週木曜日に放送される「カンブリア宮殿」というのは、ユニークな経営者や卓越した経営スタイル、斬新なビジネスモデルなどが登場するので毎回楽しくみるし、感心すること、参考になることなども多い。なので、商売柄いつもここで紹介されるビジネスをプロセスで捉えるとどういうことなのかという風に見てしまう癖がついてしまった。

先週の出演者はダイキン工業会長の井上礼之さんだ。驚いたのだが、何と年間売り上げが1兆7800億円だという。井上さんが社長に就任したときが3700億円だったのをそれから20年間で4.5倍にしたことになる。ほとんどが業務用と家庭用エアコンのようだが、うちでももっぱらダイキン製を使っている。やはり性能がいいことが評価ポイントである。

この躍進はひとえに井上さんの功績で、その果敢な経営スタイルが今日の業績につながっている。選択と集中という戦略もさることながら、圧倒的な差別化と素早い決断がビジネス拡大をもたらした。AとBの案があってどっちかというとき、誰も考えないような全く別のC案を持ってきてこれをすぐにやれということがあるという。

もう一つ、ダイキン工業という会社で特筆すべきことは人材育成、人材活用である。ひとことでいうと「厳しい困難を、信頼して任せる」文化にあるのだ。びっくりしたのは毎年行われる盆踊り大会を若手社員が全部取り仕切るのである。25000人もの人が訪れるという大きなイベントを彼らに任せてしまうのである。それは経験にもなるし、社員の一体感にもつながるのだという。

トップの的確で素早い決断とそれを実行する優秀な社員がいるのだ。しかしである。それだけでできるのだろうか。やはり、プロセスが必要ではないかと思うのである。というか、おそらくちゃんとしたプロセスができていてそれを適切に管理しているのだと思う。そうでないといくらできのよい社員といえども組織的なプレーは難しいし、少なくともスピードを求められると苦しいはずだ。

そこで、井上会長の次の言葉がそれを物語る。「一流の戦略と二流の実行力」と「二流の戦略と一流の実行力」があったらどっち選ぶかと問われたら躊躇なく後者であると言ったのである。つまり、いくら立派な戦略があったってそれを実行しなければ意味が無いのだ。それなら、厳格に戦略を策定しなくてもある程度方向性が見えたらやってしまえ、それでうまく行かなかったらすぐに修正すればいいじゃないかという。

このことは、簡単に聞こえるのだが非常に難しい。まずは失敗したらどうしようかということが先にきて、石橋を叩いてしまうことや、やったとしてもうまく行かなかったらその時点で終りとなることが多い。こうした難しいオペレーションができるということは、修正動作が効く仕組み(ぼくがよく言うフィードバックループ)があるからである。

つまり、プロセスが確立していて、なおかつトップの指示が出たらすぐに受け取るプロセスを特定して、まずはオペレーションをしてみるが、うまくいきそうもないというシグナルをすばやく検知して、このままほっとくと失敗すると判断したらすぐに修正するという動きができているということなのである。これは何も高度なITを導入しているとか、最新のシステムが構築されているかどうかは関係ない。案外モチベーションの高い社員の工夫で回しているかもしれない。

ただ言えることは、決断力のあるトップと柔軟なプロセスと忠誠心の高い優秀な社員は優良企業になるための必須条件であるということだ。結局、こうした仕組みと仕掛けを用意させたのは経営者であろうから、一流の経営者はみなプロセス思考の持ち主であると思うのである。
 

2014年9月20日

プロセス思考のすすめ(7)

プロセス思考とは、システム構築のためだけではなく、分析とか戦略立案のためでもある。つまり、プロセスを記述し、それを分析することでビジネスモデルを変更する、あるいは戦略を見直すといったことも可能だということである。また、実際に設計したプロセスをオペレーションした後でも同じようにビジネスモデルや戦略変更を行っていきます。

実は非プロセス思考だとこういうことは難しいと思います。その例を言うと、ERP導入のケースを考えてみてください。ERPがビジネスモデルや戦略に遡及できるかどうかはさておき、本来の考え方としてはパッケージですから、既にスタンダードとしてモデルがあってそれに合わせるということだった。すなわち、型にはまっているとはいえ、上流のモデルを既存のものからベストプラクティスといわれるものに変更することだったのだ。

ところがうまくいかなかったわけだが、その理由は、ERPは戦略とかとの結びつきが弱かったことと基本的には統合データベースという色合いが強くプロセスという概念が乏しいために上へ遡れなかったことだと思う。プロセスという概念は戦略やビジネスモデルに直結しているから先述したようにプロセスを書いて動かしてまた上へもどるというような上下運動が可能なのである。

プロセス思考の需要なポイントのひとつはここにあります。最近、中堅中小企業の経営問題に携わることが多いのだが、選択と集中をしたいのだがどうしたらよいのかとか、最新のITを使って何かできないか、市場が縮小しているがなんとかならないのかといった問題を議論するのだが、どうしても散発的で皮相的なアイデアの応酬となる。そんな時に、ビジネスモデルとビジネスプロセスをとりあえず書いてみたらと思う。

旅行でどこに行きたいとか、行き着くにはどういう経路があるとかと言った時には必ず地図をみながら思案するはずです。とくに複数の人たちが参加した場合は地図がなければ議論はかみ合わないはずです。これと同じように、ビジネスを語るにはビジネスモデルとビジネスプロセス(ハイレベル)を見ながら議論することをお薦めします。

こうしたアプローチの利点は日々のオペレーションにも発揮されることになります。つまり、戦略に合致した実行ができることになります。そこでも、例えば戦略に合致しない顧客が増えてきたら、戦略を変えてそういった顧客を取り込むといった対応もできるのです。可逆反応を引き起こすプロセス思考はこれからますます重要なものになっていくでしょう。
  

2015年5月 7日

BPM協会を退会しました

もう入会してからかれこれ10年近くになり、運営幹事を務めていた日本ビジネスプロセス・マネジメント協会を退会しました。ぼくがビジネスプロセス(BPM)に興味をもったのは以前いた会社で情報システム部門に配置転換になりその後工場から本社に異動になったときからである。業務システムのユーザという立場から作る側に変わって初めの頃は工場だから生産管理システムが中心だった。それが本社だと営業だとか、受注出荷、購買といった業務が対象になる。

あまり経験がない業務だったので勉強しなくてはいけなくなった。工場にいた時に関わったシステム開発ではデータ中心アプローチ(DOA)を採用した。だから、当然そのDOAでもってシステム作りに向かったのだが、どうもうまくいかないような気がしたのである。ここでなぜだろうかと悩んだ。いろいろな角度から考えあぐねた結果浮かんだのが、「データ」「プロセス」「機能」という構成要素だった。

プロセスという要素を採り上げたのは、多分にぼくが化学プラントのエンジニアだったことがあると思う。しかも連続プロセスを扱っていたたらなおさらプロセスを意識したのだ。化学プロセスには連続プロセスとバッチプロセスがあるが、バッチプロセスは簡単に言うとプロセスといいながらも決まったレシピで釜に仕込んであとは仕上がりを待つといったものだから、連続プロセスのように単位操作の連鎖というのとはちょっと違う。

ということで、業務プロセスを化学プラントの連続プロセスと見立ててみたのである。そんな話を素人が勝手に思い込んでもいけないので、著名なITコンサルタントの人に意見を聞きに行った。そうしたら、その考え方は大事ですと言われてわが意を得たりと喜んだのである。そこからビジネスプロセスを調べてみて、あるいは発言している人に会って、BPM協会の存在を知ったというわけである。

しかしながら、まだウオターフォールのスクラッチ開発やパッケージ導入が主だった世界にプロセスと叫んでもなかなか理解されなかった。徐々にではあるが浸透してきて、昨年の「BPMフォーラム」では参加者が500名を越えた。でもぼくにとっては遅いと感じる。日本の経営者の意識が低いというのもあるがきちんと説明できていないこともあるような気がする。

システム開発のメソドロジーというのはついついこれでやるとなんでもできますよと売り込むように、万能薬のように説明してしまうところがある。ERPもそうだし、アジャイルなんてもそうかもしれない。しかし、実際にはそれを導入するのに適した領域というものがあって、そこの見極めがきわめて重要なのである。そこの説明ができていないのだ。

ぼくの会社の事業計画では、もはやBPMに携わることはやらないという決定をくだした。ただ、あくまで提供サービスとしてのBPMコンサルティング業であって、事業のオペレーションにはBPMを活用するのは当然である。すなわち、新規事業を立ち上げるにしても、商品開発プロセスとか設計プロセスがあるし、事業が始まれば営業プロセスや調達プロセスがあるのだから、そこはばっちりとプロセス志向でやっていくのである。

ということで長い間関係した「日本ビジネスプロセス・マネジメント協会」を離れることになりましたが、ずいぶんと多くのことを学び、また多くの人と知り合うことができたこと、また「BPM推進のステップとキーポイント」(BPM推進フレームワーク解説書)の作成に参画できたことに感謝しています。もう今年のBPMフォーラムにも行かないと思いますが、BPMの理解が進み、適切な導入により企業の発展につながることを祈っています。
  

About BPMの正しい理解のために

ブログ「mark-wada blog」のカテゴリ「BPMの正しい理解のために」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

次のカテゴリはBPM関連です。

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

Powered by
Movable Type