Recently in BPM Category

昨日のソフトバンクの「ビジネス+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とともに不定型なコラボレイティブな場とで実装していくのです。このあたりは、設計と実装の連続性のところで書いたとおりです。

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

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

About this Archive

This page is an archive of recent entries in the BPM category.

IT一般 is the next category.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.34-en