Recently in BPM Category

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

  

昨日のソフトバンクの「ビジネス+IT」に先月の「BPMフォーラム」のセッションで発表した事例についての記事が掲載されました。「ある油圧機器メーカー社長が掲げた「特注品で売上を伸ばす」を実現したBPMの取り組み」と題した内容で日本BPM協会の岩田アキラさんの「BPM推進フレームワーク」の紹介に続いて、ぼくが一昨年と昨年に参加した「業務見える化」プロジェクトの成果を発表したことについて書かれています。

1カ月以上も前なので今ごろかとか、記事のジャンルがコスト削減だったといったツッコミはあるにしても、こうして記事にしてくれたことは単純にうれしい。フォーラムでの話は「BPM推進フレームワーク」に準じて実行したら成功しましたという流れですが、実際には同時進行といった方があっていて、つまり、実際のプロジェクトをやりながら、一方ではフレームワークの作成も行っていた。

まあ、結果的には推進フレームワークに則ったやり方だった、あるいは実際にやって効果を出したことをフレームワークに反映させたということになります。これはぼくが両方にかかわっていたからこそとちょっぴり自負しています。 今ではBPM協会の「BPM入門セミナー」でも紹介されています。具体的な事例があるのとないのとは雲泥の差があります。掛け声だけでは説得力がないのでこうした事例を交えた進言が意味があるのです。

事例があるというのは、ただやってみましたということではなく、きっちりと成果を出さなくては意味がありません。記事に出ている会社ではすぐに成果が定量的にもでてきたという成功例です。それが、単に業務プロセスを見える化したからだけではなく、経営者のリーダシップ、進取の精神に富んだ企業風土の醸成、情報共有・コミュニケーションの活性化、技術・ノウハウの継承、人材育成など多くの要因によって達成されています。

ですから、コストダウンという即物的なジャンルで括られても困るのですが、非常に参考になる取り組みです。日本の中小企業が強くなるヒントが詰まっているように思います。(大企業にも当てはまると思いますが、組織の壁と決定のスピード感のなさ、リスクテイクできない体質という問題が横たわっていてすぐの実行は難しい)現在も続いていますので、また新たな成果が出たら紹介していこうと思います。
  

昨日、目黒の雅叙園で開かれた第7回BPMフォーラムに参加する。もう7回目になるわけだが、終わってから事務局の人たちと打ち上げしたとき感慨深けによく続いたたなあと言っていた。ぼくはほとんど出ているので、その変遷というか流れを見てきたが、今回の特徴はおそらくユーザの人たちの割合が増えてきたことではないだろうか。

はじめた当初は、ベンダーの人たちの参加も多く、どちらかというと開発メソッド的な捉え方でBPMは見られていたように思う。そしてある種の期待感があってこれから導入企業が増えてきそうだという観測もあったのである。ところが、IT投資が抑制されているという面もあって、新たな投資案件にBPMを適用するという例がなかなかあらわれないという現象が続いている。

従って、最近の傾向としては開発ツールとしてのBPMSといったトーンが薄れてきて、プロセス改革に向けた、いわゆるビジネスマネジメントの活動といった側面が表に出てきているといえる。これは本来のBPMに近づいたわけだから非常によい方向である。だから、ユーザ企業の人たち関心に答えることをしていかなくてはいけない。

知り合いの何人かのベンダーの人と話していたら、単にBPMSを売ろうとしてもなかなか売れないと言っていた。ツールを売るというスタンスだとシステム屋さん向けにプロモーションすることになるが、情報システム部門のひとたちにプロセス改革といっても通じないと嘆いていた。だから、経営者と事業責任者へアプローチしないといけないのだが、それが不十分で今後の課題だと言っていた。

そうした流れを象徴的に発信した(と思っている)のが、日本BPM協会のBPM推進フレームワークで、フォーラム冒頭でも事務局長の横川さんの方から紹介があり、それを受ける形で午後の最後のセッション「これからの業務改革アプローチ:BPMは、こう取組む~実践事例に見る新・推進フレームワークの有効性~」で報告を行った。

このセッションでは、推進フレームを作ったコモンセンス部会(ぼくもメンバーです)のリーダの岩田アキラさんからフレームワークのコンセプトや意義について話して、そのあとぼくのほうから実践事例を紹介し、後は協会理事である太田大作さんがモデレータとなったパネルディスカションを行った。

全部で55分という短い時間だったので、ぼくのプレゼンも15分しかなく言いたいことが言えなかった面もあるのだが、最低限のことは主張できたかなあと思っている。新しいフレームワークのポイントは、まずは従来のデータベースアプリケーション主体からBPMアプリケーションに軸足を移そうよねというパラダイムの転換を訴えたことがあります。このことは以前からずっと言い続けたぼくとしては大変心強く感じました。

それと、PC、PD、POという3つの環をシンボリックに表現したことです。Process Change(プロセス改革推進)、Process Development(プロセス開発)、Process Operation(プロセスオペレーション)が三位一体となって動く姿を提示している。特にオペレーションの位置を引き上げたことが特記されるところです。従来のBPMではあまり表にでてきていなかったところで、オペレーションできちんと成果をあげなければいくらいい戦略をたてても、いくらいいツールを使ったとしても何ら意味のないことなのである。

ということで、ぼくの年来の主張が埋め込まれたものになり、こうしてプレゼンもさせていただけたことが大変うれしく思う。セッションが終わったあとに出席者のアンケートを見せてもらったのだが、もっと詳しく聞きたいといった声も多く好評だったようななので早速追加セミナーを開こうという話になった。ぜひ、皆さんと一緒になって議論する形で実現できたらいいと思っている。

他のセッションや基調講演にも触れなくてはいけないのだが、まだちょっとプロセスという概念がばらばらのような気がする。ただ、わりと事例を中心にな話されているという印象でよいことだと思うのだが、欧米の金融、保険、証券といった例はまだこれからという日本の企業には突出しすぎているように感じられた。プロセスの適用というのは様々なところがあり、あまり製造業でいう工場のような領域(例えばATM、株取引、切符発券、空港オペレーションなど)は、少し分けて考えた方がいいように思う。
  
3月6日に目黒の雅叙園で開かれる「第7回BPMフォーラム2012」で登壇することになりました。BPM実践事例/ソリューショントラックの最後にあるセッション「これからの業務改革アプローチ:BPMは、こう取組む~実践事例に見る新・推進フレームワークの有効性~」で事例の紹介のプレゼンとそのあとのパネルディスカッションに参加します。

内容的には、岩田アキラさんのほうでBPM協会で作成したばかりの「BPM推進フレームワーク」の説明をしていただいて、私の方から事例ということで一昨年、昨年にわたって製造業を営むある中小企業で行った「業務見える化」プロジェクトの成果について発表します。実践した例が、結果的にこの推進フレームワークに準じたものになっていたいうトーンの話をします。

「BPM推進フレームワーク」は以前からありましたがその改訂版となります。このたびのポイントは、ニュースにもありますように、3つの輪のコンセプトにあります。すなわち、「プロセス改革推進」「プロセス開発」「プロセスオペレーション」の3つの輪が連動して動くことです。このことはずっとこのブログでも言い続けてきたことで、特にオペレーションの重要性を引き上げていることに特徴があると思っています。

要するに、従来のように開発に重きを置いたものから実際の業務運用のところにも重心を向けたことです。つまり、作ってナンボの世界から使ってナンボという世界へ移行させたところです。そうなると、必然的にユーザが主体となった取り組みとなり、先日も書いたように、BPMはIT活動ではなくビジネス・マネジメント活動であるという色合いが濃くなります。これがBPMがめざす本来の姿ではないでしょうか。

そんな考え方や姿勢が伝わればいいと思っています。ぜひ「BPMフォーラム」に足を向けてビジネスに貢献するためのアプローチとしてのBPMを感じていただきたいと思っています。私にご連絡いただければ参加費の割引が受けられますのでお申し出ください。
 
BPMの正しい理解のためにーはじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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