レベル: 初級 保坂 大輔, WebSphereテクニカル・セールス, IBM
2009年 6月 29日 本連載ではBPMのアプローチによりお客様の課題をどう解決することができるか、またIBMの提供するBPM製品がどのようにそれを実現するのかを紹介し ます。
最終回の今回はITを活用したBPMの導入の課題とそれを成功に導くためのポイントについてお話しています。
BPMの現状と課題
今まで3回にわたってBPMについてご紹介してきた本連載ですが今回がいよいよ最終回です。今回はITを活用したBPMをどのように実践するのか、第一歩を踏み出す時の課題とそれを克服するための方法について考えてみたいと思います。
第1回でお話したように、ビジネス・プロセスに注目してそれを改善しようというBPM自体は目新しい概念でもありませんし、IT用語でもありません。一方で、現在、企業を含む様々な組織の運営にはITが利用され、日々の業務を行うためにIT技術は非常に重要な要素になっています。BPMを効果的に実践するにはITの活用が不可欠です。では、ITを活用したBPMの実践はどの程度、世の中で進んでいるのでしょうか？
調査会社による様々なレポートでもBPMへの興味と期待が高いことが伺え、IBMでも世界中にBPM事例が数千件とかなり増えてきました。一方で、IT技術の活用という面で見てみると、これらの事例の多くはIT技術の部分的な適用であり、しかも、パイロット・プロジェクトであったり、最初の適用事例であったり、というものがほとんどです。そもそも全く手をつけてないというのが圧倒的多数のようです。まして、IT技術を駆使して全社的にBPMを実践しています、という例はほとんどないのが現状ではないでしょうか。
興味はあるのだけれど、やってない。これはどういうことなのでしょうか？面倒だからやってない、なんてことでは当然ありません。やはりITを活用したBPMの実践には様々な課題があるからです。ここからは経験則的な話になってしまうのですが、我々が日々の活動や世界各国の仲間との情報交換からえた情報を元に、その課題が一体、何であるのかを考えてみました。
それらを整理すると、以下の3つになります：
- 組織内の抵抗
BPMというのはITに限定したものではなく、その組織自体の改革をも含む概念です。そのため、必ずその変化に反対する人達が現れます。表面に出てきて反対するか、裏で反対工作をするのかは別として、ある程度以上の人間が集まっている組織において変化への拒否反応が起こるのは避けられません。中には変化自体に拒否感を持つ「現状のまま過ごしたい」という欲求を持つ人もいるでしょうし、その変化によって自分の役割が不要になるのではないかという恐れが拒否感に繋がる場合もあるでしょう。これは組織を改革する時に表れる一般的な課題だと言えます。
直感的な拒否感の一方で、もう少し限定的にBPM自体や、または最初に具体化されたBPM関連のITプロジェクトに対して、その有効性を疑問視するため反対する人もいます。ITを使ったBPMの実績が十分でない、そのプロジェクトでは効果がない、効果に対して費用とリスクが多すぎる、などがその理由です。
これらの抵抗により最初のBPMプロジェクトが開始できなかったり、または骨抜きにされてしまったりということがよくあります。
- どう始めればいいのかわからない
「BPMって何か良さそうだな、うちでもやってみたい」と思ったとしても、何から手を付けていいのかわからないということも良くあります。具体例で言うと「やってみたいんだけれどなぁ。実際にうちの会社で始めるのは難しいだろうな…」というようなコメントをよく耳にします。
上記で挙げたような課題があって、その解決策にある程度目星がついたとしても、どこから手を付けて、どういうスキルが必要で、どのぐらいお金がかかって、どれぐらい時間がかかって、どういう効果が望めるのか、ということが全然見えません。よって第一歩を踏み出すことができず逡巡して忘れ去られたり、検証プロジェクトを繰り返したり、ということに陥りがちです。
- 既存システムの存在
ほとんどの企業や団体はすでに稼動している現行システムを大量に抱えています。これらのシステムを全て新規に作成しなおしたり、大幅な修正を加えたり（いわゆる“ビッグバン・アプローチ”）するということは現実的ではありません。また、現行システムを再利用する場合でも、現在の業務で使用されていますから、長時間停止したり障害が発生したりするようなことがあってはなりません。これは高速道路を走っている車をそのまま走りながら改造するような話です。
さらにビジネス・プロセスを定義して、そこから既存システムを呼び出すような設計をしたとしても既存システムの持つ機能をそのような単位でサービスとして提供できるとは限りません。ビジネス・プロセスが既存システムの中にハードコードされている場合やデータが密接にロジックと結びついている場合などは、そのビジネス・プロセスを管理する対象に含められないかもしれません。
ピンと来るものはありましたか？
日本を含む様々な国のIBM社員やお客様の話を聞いていて面白いと思うのは、日本でも海外でも同じようなことが課題に挙げられていることです。よく日本の特殊性が語られますが、もちろん世界と共通の点もあるわけで、どちらかというと共通する課題が多いのではないかと感じます。結局、人間は同じようなことを考えて同じようなことで困っているんですね。
では、これらの課題を乗り越えてBPMを実践するにはどうすればいいのか。以下に、様々なBPM経験者の話を聞いて筆者なりにまとめてみた成功するBPMのポイントを挙げてみます。これらのポイントには漏れもダブりもあると思いますが、何かヒントになる事柄も含んでいるはずです。共感したり、これは違うと思ったり、読み物として楽しんでいただければと思います。
最初のBPMプロジェクトを成功させるためのポイント
ここで紹介する成功のポイントは以下の通りです：
- 組織内の協力体制の確立
- ガバナンスの確立
① 正しい方法論/アプローチの採用
② 教育
③ ビジネス・プロセス・オーナーの明確化
- 技術の正しい活用
① インフラ/標準の活用
② IT資産管理
- 初期に成功を勝ち取ること
- 忍耐力
① 一歩目は大変
② 人の期待値の管理
これも面白いことに、様々な業界や国の人達が同じようなことを言っています。全て言うのは簡単、実行するのは大変ですがこれらを考慮することにより少しでも成功する確率を高めることができるのであれば苦労の甲斐はあります。
見ただけである程度はわかっていただけるかもしれませんが、もう少し詳しく説明していきましょう。
1．組織内の協力体制の確立
この連載を通して見てきたようにBPMとはビジネス・プロセスを中心にして継続的にビジネスを改善しようという概念でありIT用語ではありません。ITは非常に重要な要素ではありますが、それを実現するための手段の一つにしか過ぎないのです。IT部門だけでドンドンBPMの実践を進めていって「上手くいった！」などということを望むのは無理があります。それぞれのビジネス・プロセスにまつわる業務を行っている部門の協力と、何よりそれらをより広い視点で見ている経営層の協力が欠かせません。
この説明だけでは少し抽象的過ぎてわかりにくいかもしれませんから、組織内の協力がないために失敗するパターンの例をもう少し具体的に書いてみましょう：
- “BPM推進”と名づけられた組織がBPMの実践を目指すが、業務部門は自分が最初のプロジェクトにはなりたくない。「今回のうちのプロジェクトはいいから、よそのプロジェクトで始めてよ」と先兵になることを拒否する。その結果、なかなか実プロジェクトが始まらず、次期の組織変更で結果を出せない“BPM推進”は解散となる。
- IT部門が“BPMプロジェクト”として全社のSOA化と絡めた大規模な情報基盤の改革プロジェクトを実施する。各業務部門間の調整がつかず、結局、次世代の情報基盤は現状の焼き直しとなる “ただ新しいだけで古い”設計となってしまい、実態は何も変わらずBPMという言葉だけが残った。
- IT部門主導で、あるプロジェクトをBPM実践の最初の例として取り上げ業務部門と協力して実施しようとする。業務部門からのBPMを考慮しない要件をそのまま受け入れているうちに、BPMとは呼べないただのワークフローのアプリケーションを開発してしまい、社内の意見は「BPMって別に今までと同じだね」ということになる。
どこかで聞いたような話はありますか？これらはBPMに限らず何か全く新しいことを行う時にはいつでも起こりうる話かもしれませんね。
組織全体の方針としてBPMを実践しようという経営層の決定の元、業務部門とIT部門が協力して将来像と現行のプロジェクトで実践することを切り分けて、将来像を見据えながら現行の開発をしっかり行うというのが理想的な姿です。
2．ガバナンスの確立
“コーポレート・ガバナンス”という言葉で耳にする機会があると思いますが“ガバナンス”とはざっくり言うと、“組織としてちゃんとする仕組み”のことです。ここでは“BPMをちゃんと導入/実践する仕組み”があるかどうかということになりますね。（“ちゃんと”って何？という細かいことは気にしないでください）
①正しい方法論/アプローチの採用
今までBPMを実践するIT基盤を持っていない組織がいきなり素晴らしいシステムを作成できる、なんてことは普通ありえません。残念です。では、そういう時はどうするのか？
やはり専門家に頼むことになります。世の中には経験豊富な専門家がいますから、そういう“プロフェッショナル・サービス”を活用するというのが現実的な回答になります。
また、何らかの方法論に基づいたアプローチを実施することも大切です。毎回、行き当たりばったりで開発していると過去から体系的に学んでいないため、同じ間違いを繰り返す可能性があります。振り返って過去に行ったアプローチを改善することができないためそのアプローチが洗練されることもありません。（継続的に改善する、もうお馴染みの考え方ですよね）
実績のある方法論を使い、論理的で裏づけのあるアプローチで設計/開発ができる、プロフェッショナル・サービスを選択することが大切です。また、そのアプローチのどこが良くてどこが悪かったのか、次回はどのように改善できるのかというノウハウや教訓を組織内に蓄積する仕組みと、それを共有し再利用する仕組みも次回以降の成功率を高める重要なポイントです。
②教育
活用した方がいいのは確かですが、プロフェッショナル・サービスに任せっきりというわけにはいきません。やはりBPMを実践する組織自体も学んでいかなくてはなりません。やはりこれもがむしゃらに教育をすればいいということではなくロードマップを作ることが必要です。
必要なスキルは何か？何人ぐらい必要なのか？またそれはいつなのか？育成計画を立て、それを実行し、さらに評価する（これもまたお馴染みの話ですね）というサイクルを回して組織自体のBPMリテラシーを高めていきます。
組織内に抱えておく必要のないスキルであれば一時的に外部から調達するという手段を検討するのもよいでしょう。
③ビジネス・プロセス・オーナーの明確化
意外に盲点なのがビジネス・プロセスに関する責任範囲の不明確さが原因で失敗してしまうパターンです。具体的にはビジネス・プロセスのオーナーを決めていないために色々な人がよってたかって複雑なプロセスにしてしまったり、逆に遠慮しあって必要な変更が加えられなかったり、ということが発生してしまうということによる失敗です。
各ビジネス・プロセスは誰がオーナーであるかをきっちりと決めて、その人もしくは組織が責任を持って管理する必要があります。ビジネス・プロセス内でオーナーが複数存在してしまいそうな場合は、サブプロセスを使って責任範囲を切り分けるという方法も有効です。例えば、部門横断的なある業務のメインプロセスはBPMを推進する部門が管理し、そこから呼び出される各業務固有のサブプロセスは当該業務部門が管理する、といった形です。
責任範囲を明確にするのはビジネス・プロセスに関連するその他のビジネス上の概念についても同様です。連載の第3回で紹介したようなビジネス・サービスの概念を利用するのであればレポジトリーに定義されているビジネス・ロジックもその対象になりますし、ルール・エンジンを利用するのであれば、そこに定義されるビジネス・ルールについても同様にオーナーを明確にすることが大切です。
3．技術の正しい活用
ここまで繰り返し主張してきたようにBPMを効果的に実践するためにはIT技術の活用が不可欠です。正しい技術を正しく適用することも成功のためには重要なポイントです。
①インフラ/標準の活用
これから新しいことを始めようという時に、経験のないまま一から自分で作るというのは、その心意気は買えますが、効率的な方法とは言えません。すでに経験をしている先人がいるわけですから、その知恵やノウハウを使わない手はありません。いわゆる「巨人の肩に乗って」先を見通せば自分でやるよりは遠くまで見えるというわけです。（「巨人の肩…」はニュートンの言葉として有名ですが、どうも当時すでにそのような格言があってニュートンはそれを引用したということのようですね。余談ですが…）
この連載で紹介してきたBPM関連のミドルウェアをBPMインフラとして活用するというのはその一つの例です。世の中に出ているミドルウェアやアプリケーションは沢山あって、その中には何か今回の用途にマッチするものがあるはずです。
ミドルウェアの活用ということで言うと、例えば、本格的なデータベースのソフトウェアを自分で作るというのはありえませんよね？既存のデータベースのソフトウェアをフリーのものであれ、有料のものを購入するのであれ、利用しながらシステムを構築するはずです。BPMにおいても同様です。費用対効果を考えながら使えるものは使いましょう。
インフラに相当するものだけではありません。その業界標準となっている規格やテンプレートを活用したり、BPMのシステムを構築するためのIT技術標準（この連載でご紹介したSCA1やBPEL2など）を活用したりするのも大切です。
これらを上手に活用すればリスクとコストを減らし、成功の確率をぐっと高めることができます。
②IT資産管理
SOAを活用してBPMのシステムを構築する場合、SOAのサービスの定義などのIT資産は再利用の対象になります。上手に活用すればコストの削減や開発時間の短縮に繋がります。一方で、再利用するためには管理することも必要で、例えば、変更が入った時にどこが影響を受けるかということも知る必要も出てきます。ところが実際には、これらのIT資産は表計算ソフトなどでアナログに管理されており、なかなか思うように再利用が進んでいないというのが現状、というケースが多いのではないでしょうか。
あるプロジェクトが始まったとしましょう、すでに終わったプロジェクトや現在進行中の別プロジェクトなどで作成された膨大なIT資産が表形式で残っているので、その既存のIT資産の中から、例えば、サービスを再利用したいとします。表を調べて適当なサービスがあるかどうか探すのですが、微妙にサービスに関する表現が違っていて検索に引っかからなかったり、サービスの粒度が同じかどうかわからなかったりして、どれを再利用できるのかわかりません。ひょっとするとバージョンが変わっているものもあるかもしれません。結局、よくわからないので同様のサービスを新規に作ってしまう、、、という感じで再利用は進まず、どんどん重複したサービスが溜まっていってしまいます。
このような事態を防ぐには、やはりIT資産を管理する専門の要員を置いて管理、運営することが必要です。必要であればIT資産を管理する専門のソフトウェアを活用することも検討するといいでしょう。例えばIBMではRational Asset Manager (RAM)やWebSphere Service Registry & Repository (WSRR)という製品を提供しています。RAMはIT資産の再利用を目的として主に開発時に利用され、WSRRはIT資産の中でもサービスに着目して、検索、ライフサイクル管理、変更があった場合の影響分析などに利用されます。
この話はITガバナンスの話ですから、「2．ガバナンスの確立」という一つ前の成功ポイントに分類してもいいですね。この辺りの話題に興味のある方は記事の最後にある「参考文献」にある連載「SOAにおけるサービスの運用管理を考える」や「RAMの紹介」を参考にしてみてください。
4．初期に成功を勝ち取ること
最初のプロジェクトは慎重に選ばなくてはいけません。早い段階で成果を出せるようなプロジェクトにすることが大切です。成果を出すことによりBPMが有効であるという社内の合意形成を促進することができますし、逆になかなか目に見える成果が出ないと前述の抵抗勢力を勢いづかせることになってしまいます。こうなってしまうと次のプロジェクトを進めることは難しくなり、せっかくの継続的な改善というBPM本来の特長を発揮できないまま終わってしまいます。（囲み記事「コッターの8段階の変革プロセス」参照）
 |
コッターの8段階の変革プロセス：
ジョン・コッターはハーバード・ビジネス・レビューの論文で有名な「企業改革 八つの落とし穴」を発表しました。企業変革における、いわゆる“べからず”リストですが、逆の意味にとれば変革を成功させるための8段階のステップということになります。今回の記事で成功のポイントとして挙げた「初期に成功を勝ち取ること」はBPMシステムを導入した経験者からよく聞く話なのですが、これを聞くたびにコッターの書く6つ目の落とし穴「計画的な短期的成果の欠如」を思い出します。実際に非常に似たことを言っています。BPMの導入というのは組織改革の話でもあるので、当然といえば当然なのですが、改めてコッターの著作を読んでみるとBPM経験者の語る内容と似ている内容が多いのに気づきます。
筆者としては、今回の記事に書いた内容はまとまりもなく元になる情報も経験も少ないわけですが、それほど的外れなことを主張しているわけでもないんだなと、久しぶりにコッターの本を読み返してみて少し安心しました。
今回の記事ではITをBPMに活用するという観点から成功のポイントなどというものを挙げてみているのですが、コッターの述べるもっと大きく、そして体系だった「変革をいかに進めるか」という観点からそれらのポイントを咀嚼していただけると(ただ乗りできて)非常に助かります。
|
|
では、早い段階で成果を出せるプロジェクトの条件とはどういうものでしょうか？
恐らく一番大きな要素は、小さく始めることです。小規模に短時間で行えるプロジェクトなら、リスクも限定できますし、管理も簡単です。一方で、BPMの性格上、あまり範囲を限定すると狭い範囲での部分最適を目指すことになり、BPMの有効性を示す肝心の成果が出ない恐れもあります。この辺の相反する条件を踏まえた判断は難しいのですが、既に経験されている方々が異口同音におっしゃる「大きく考えて小さく始める」というキーワードがヒントになるでしょう。あるべき将来像を大きく描いて、その第一歩としてその一部の範囲にBPMを適用しようという考え方です。このキーワードを当てはめながら、どのようなプロジェクトが相応しいのかということを考えると、成功確率を高められそうです。
さらにもう一つ大切なことは繰り返すことです。小さく初めてその小さな成功を繰り返していきます。繰り返しているうちにその適用範囲が広がりどんどんその成果は大きくなっていくはずです。BPMは継続的な改善を目指すものですから、続ければ続けるほど成功の確率とその成果が増えていくことでしょう。
5．粘り強さ
最後は精神論的な話になります。
①一歩目は大変
ここまで来てこんなことを言うのもなんですが、お気づきの通り、今までお話してきた成功のポイントを全て満たすことは大変です。また、全て満たしたとしても「最初の第一歩は非常に苦労するから覚悟しておいた方がいい」というのが、経験者の多くがおっしゃることです。
ある海外のお客様がこんなことをお話になっていました。「システムの変更というだけではなく、経営や業務のあり方の変革でもあるBPMという概念の導入は大変な困難でした。しかし、我々には他の選択肢はなかったのです。現状の硬直的なITシステムとM&Aによって統合された複数の会社によるバラバラのビジネス・プロセス。このままでは厳しい競争に勝ち抜くことはできず、3年後には我々の会社は存在していなかったでしょう。我々はやり抜くしかなかったのです。」
ここまでの覚悟で臨まれる方は多くないかも知れませんが、従来のITシステムの構築とは違う初めてのことが多く、特に1回目は大変だということは確かでしょう。一方で、一度始めれば2回目以降は従来では考えられないほど楽になったということを、多くの方がお話になっているというのも、また事実です。
上記のお客様はこう続けられていました「現在の我々のシステムはさらなるM&Aにも十分迅速に対応できる柔軟性を持つようになりました。ただ、前述のITシステムの変更以降そういう機会はまだありません…。神様、ありがとう。」
②人の期待値の管理
最後は組織内の人々の期待値の制御についてです。「これからわが社はITを活用してBPMを効果的に実践する組織に生まれ変わります。その第一歩としてこのプロジェクトをスタートさせます。」などと宣言した時、組織内の人達の期待は高い方がいいでしょうか？それともあまり期待してもらわない方がいいのでしょうか？
経験者の語るところによると、やはり“中庸”がいいようです。期待値が低過ぎるとそもそもプロジェクトが始まらない場合がありますし、始まったとしても十分なサポートが得られず成功する確率は低くなります。一方で、期待値が高すぎると、成功と見なされるハードルが上がってしまい、プロジェクトは上手くいったにもかかわらず「なんだあんなものか。やっぱり駄目だね。」などと失敗のレッテルを貼られてしまうこともあります。
人の期待値を管理するというのは非常に難しく、これには苦労したという意見を聞きます。完璧に管理するのは無理でしょうが、このことを頭に置いておくのと、全く意識しないのとではやはり違いは出てくるでしょう。これに関しては何か秘策があるわけではなく忍耐力の話のようです。常に意識しながら、社内の期待値のコントロールに泥臭く、粘り強く取り組むしかないようです。
まとめ
この連載では「BPMと名前を聞く機会は多いが今ひとつピンとこない」と思っている方や純粋に「BPMって何？」という言葉自体が初耳だという方を仮の読者として想定して、できるだけわかりやすくそのモヤモヤを解消してもらえることを目指して最新のIT技術を中心にBPMにまつわる話をご紹介してきました。今回も「課題と成功のためのポイントが対応付けられていない」とか「スコープの違う話が並列に挙げられている」など論文のつもりで読んでいると色々突っ込みどころはあるでしょうが、いくつか「ほぅ」と思う点があって読み物として読みやすければいいと割り切って書きました。
先日、髪を切りに行った時に担当の美容師の方と話していたんですが、なんとこの連載を読んでくれていたらしく「全く知らなくても何となくわかった」と言ってくれました。ITとは全く無関係の人からそのようなコメントをもらえて目的は達成できたんだなと嬉しく思いました。この連載を読んでいただいた方の中に少しでもそう思っていただく方がいらっしゃれば、これまた非常に嬉しいことです。4回に渡ってお付き合いいただきありがとうございました。
注釈
1第1回の記事、注釈を参照
2第2回の記事、注釈を参照
参考文献
著者について | | | IBMソフトウェア事業WebSphereブランドに所属するテクニカル・セールスです。BPM関連製品を担当しており、主にお客様への提案活動やセミナー等での講演を行っています。 |
記事の評価
| 
