動かないコンピュータForum

第43回 業務改革と「動かないコンピュータ」の関係について考える

動かないコンピュータ・フォーラム 主宰者 中村 建助=日経コンピュータ編集

日経コンピュータを読む理由No.1 「動かないコンピュータ」連載が単行本になりました。全国の書店でお求めいただけます。

フォーラムの主旨と参加ルールへフォーラム・トップへ

 2004年最初の「動かないコンピュータ・フォーラム」は、業務改革と動かないコンピュータの関係について考えたい。

 企業がさらなる成長や利益の拡大を実現するために業務を見直すことは当然である。情報システムが業務と不可分のものである以上、業務改革に伴って情報システムにも何らかの変化が現れるのも当然のことだ。

 だが、本来なら企業に成功をもたらすはずの業務改革が、情報システムの開発に困難をもたらすことがあるのも事実である。大きな問題だが、年始ということもあり今回は、業務改革と「動かないコンピュータ」の関係について考えてみたい。

 今回も、いつものように皆さんからのご意見をお待ちしています。ご意見を書き込まれる方は、この画面の一番下の方にある「Feed Back!」を使ってお書き込み下さい。「コメントを書く」という文字の部分をクリックしていただければ、ご意見の記入欄が別画面で現れます。

ERPパッケージ導入の難しさがこの問題を象徴

 まず、業務改革プロジェクトが動かないコンピュータを招いた典型的なパターンを以下に示したい。

 ある企業が業務改革プロジェクトをスタートさせ、情報システムの大幅な刷新を決定。この決定を受けて、大規模なERPパッケージ(統合業務パッケージ)の導入をスタートする。ところが、システムの導入に手間取り、稼働時期を見直したり、システムの導入コストが予定を大きく上回ってしまう。大企業の大規模システム開発は、場合によっては100億円を超す費用を投じる。この費用が2倍、3倍に膨らむことになれば、単に業務改革が遅れるだけでなく企業収益にも大きな影響を与える。

 こういった例のほかに、何とかシステムは完成したものの、「動かす」ことだけを重視して仕様を変更したり、開発規模を縮小してしまう。その結果、業務改革プロジェクトの狙いを達成するという真の目的はほとんど達成できないシステムが完成するといったケースもある。

 BRP(ビジネス・プロセス・リエンジニアリング)というかけ声とセットになってERPパッケージの導入が日本で進み始めて約10年が経過した。パッケージ・ソフトそのものの品質や機能が原因となってERPパッケージの導入が難航する例は減りつつあるが、業務改革実現のツールとしてERPパッケージが大活躍しているという例を、記者はあまり聞いたことがない。

 実際に最近も、ERPパッケージの大規模導入を進めていた複数の企業で、プロジェクトの難航しているという話を耳にした。

 ある企業では、100億円をはるかに超す潤沢な予算を確保して、稼働してわずか1、2年というシステムの廃棄を実行してまで、ERPパッケージの大規模導入に踏み切った。しかし実際には、業務改革案をまとめ、具体的なERPパッケージの導入方法を決定する過程で膨大なコストが発生してしまった。もともと過剰とも思える金額の予算を準備していたため、なんとか稼働には成功したが、同業からはこのプロジェクトの総コストに対して、「なぜここまでかかるのか」という疑問の声が絶えない。

 別のある企業では、業務改革プロジェクトをスタートさせ、あるERPパッケージを導入することまでは決定。ソフトを購入したが、結局どういったシステムを導入すべきかを決めることができなかった。プロジェクトは一端中断、ベンダーの見直し等を含めてプロジェクトを進めている。

 また別のある企業では、業務改革の狙いとして「グループ経営の強化」を掲げ、親会社だけでなく関連会社を含めて同一のERPパッケージを導入しようとした。しかし、実際にはグループ会社間の業務に大きな差があるうえに、個別の企業の意見を調整することに手間取って、システムの稼働時期が大きく遅れてしまった。さらにこのプロジェクトの関係者によれば、「最初に作ろうと思っていたのとはまるで違うものが完成することになりそうだ」という。

 「ERPパッケージの導入は難航することが多い」といわれることがあるが、現在は「ERPパッケージを使ったからといって業務改革を成功させるのは簡単ではない」という方が正確なのかもしれない。

業務改革を阻むものは何か

 社内の変化や競合企業との関係、あるいは時代の変化に応じて、個別の企業のあるべき業務の姿は刻々と姿を変えている。しかし、既存の組織や業務のプロセスをこういった変化に会わせて柔軟に変更していくのは至難の業だ。
その結果、現在の企業の業務のプロセスがあるべき姿から遠のいてしまう。

 ビジネスのプロセスが変わる以上、これと不可分の存在である情報システムも必要に応じて変わるべきだということに異論のある方は少ないだろう。
では、何が問題で業務改革からスタートしたシステム開発が、「動かないコンピュータ」で終わってしまうのだろうか。

 理由はいくつか考えられる。まず第一には、業務改革の方針自体に問題があった場合だ。その企業にとって本当に必要な業務改革を実行するのではなく、競合他社が相次いで導入している、ハッキリ言えばブームになっているから、といった安易な理由で業務改革の方針を決めてしまったケースである。業務改革といえばERPパッケージといった、一次の状況にも、こういった側面があったといえるのではないだろうか。

 このほかに、全社的な視点で業務改革プロジェクトを進めるはずが、実際には一部の部門の利益だけを考えた計画になってしまっている場合が考えられる。企業内部の力関係や、プロジェクト・メンバーの顔ぶれがによって、こういった問題が起きる可能性は十分にある。議論の前提が偏っていれば、あるべき業務改革を進めることは難しい。

 また、業務改革の方向自体は正しかったが、この狙いを正確に反映して情報システムを変えることができなかった場合である。業務とシステムの両面の知識を持ったメンバーを、プロジェクト・メンバーにそろえることができなかったケースである。

 業務改革の一環としてERPパッケージを導入する企業は、「システム部門のリストラ」という目的を持っていることが少なくない。大半のシステム部門は売り上げには直接は貢献していないからだ。アウトソーシング・ブームがこれを後押ししている。

 既製品であるERPパッケージを導入すれば、システム部門に頼らなくても情報システムを運用できるようになる。システム部門は既存の手作りの情報システムには精通しているが、ERPパッケージについて、豊富な知識や運用ノウハウを持っていることは少ない。まずERPパッケージを導入して、システム部門の仕事をなくそう、ということだ。

 プロジェクトが成功すれば自分たちの役割が縮小することを承知の上で、私心を捨ててシステム部門がプロジェクトにかかわるだろうか。実際には、ERPパッケージの導入に当たって、システム部門の反発が大きかったためなのか、外部のベンダーを中心にERPパッケージの導入を進めている企業も少なくない。

 こういった企業の場合には、システム部門が積極的に参加しないために、業務要件をシステムに正確に反映できないことがあり得る。

突然増えた「全体最適」という言葉

 少し脱線する。このテーマに関連して記者が気になることがある。最近、業務改革に沿って情報システムのあり方を見直す企業から、「“全体最適”の視点からシステムのあり方を考えた」という声がよく聞こえてくるのが。この考え方自体には何の問題もないと思うが、その企業にとっての全体最適をどうやって決定するのだろうか。

 全体最適とはいっても、結局具体的な方針は企業のそれぞれのセクションに属していた人間を中心にして決定するはずである。複数の人間が議論しても全体最適の視点を見いだすのは難しいのではないだろうか。

 さらに脱線すると、「全体最適」という言葉を良く耳にするようになったのは、「ザ・ゴール」というビジネス書が日本で2001年に出版されて以降のことだ。ちなみに、米国では同書は1984年に出版されている。

 ザ・ゴールはもちろん優れた本なのであろうが、出版されて約20年が経過した本の内容を、翻訳が出たからといって飛びつくというのはどうなのだろうか。出版は1984年である。本当に、全体最適を追求している企業なら、ザ・ゴールを原文のままで読み、そのエッセンスを理解する時間は十分にあったはずだ。

 少し脱線が長くなった。本題に戻る。

コンサルタントは万能薬ではない

 以上のような問題を乗り越えて、業務改革プロジェクトを成功させるにはどうしたらよいのか。一つのアイデアは、企業の外部から業務やシステムに知識を持った専門家を雇って、業務改革を進めるということになるだろう。専門的な知識を持っていることに加え、企業の外部の人間だから中立の目線でプロジェクトにかかわることができるからだ。

 だが、この方法も万全ではない。外部の専門家を活用しても「動かないコンピュータ」が誕生する可能性は十分にある。実例がこのことを証明している。

 にこの問題については、過去の「動かないコンピュータ・フォーラム」の中で取り上げている。「企業の外部から業務やシステムに知識を持った専門家」といえば多くの場合、コンサルタントということになる。このテーマは、皆さんからの反響が高かったので、ご記憶の方もいらっしゃるだろう。

 第16回の「失敗とコンサルタントの関係」と、この問題の総括編である第17回のコンサルタントだけを非難できないがそうである。

 第16回では、コンサルタントがかかわった動かないコンピュータの事例を匿名で紹介するとともに、コンサルタントを有効に活用するためには、経営トップが果たすべき役割が大きいことを指摘している。

どうなれば成功といえるのか

 いろいろと述べてきたが、情報システムの変革を伴って業務改革を進めることが難しいことは間違いない。

 ここからが本題です。では、果たしてどういった場合であれば、情報システムの変化や刷新が業務改革に貢献したと言えることができるのでしょうか。また、情報システムの新規開発や再構築を通して、業務改革の成功をさせるためには何が重要なのでしょうか。

 あるいは、業務改革に踏み切る場合には、情報システムについてどのような思想を持った上で、実際のプロジェクトをスタートさせるべきなのでしょうか。みなさんのご意見をお待ちしています。

 なお、前回まで掲載した2007年問題関連のテーマには、普段に増して大きな反響がありました。 この問題については、動かないコンピュータ・フォーラムだけでなく、日経コンピュータ本誌の記事を通じて、どう対処すべきなのかを考えていきたいと思います。

 最後にご挨拶を。年が明けて2004年になりました。今年もよろしくお願いします。


 以下の「Feed Back!」欄で読者の皆様のコメントを募集中です。実名や所属組織の概要なしで書き込んでいただいて構いません。

 特定の法人や個人を誹謗中傷するような内容や、公序良俗に反する内容の書き込みは受け付けません。一度掲載した後でも、上記のルールにそぐわないメッセージがあると判明した場合には、掲載後も削除することがあります。ご了承願います。締め切りは1月30日(金曜)午後6時までとさせていただきます。

 いただいたご意見は、本フォーラムのほか、本誌Webサイトおよび本誌編集部発行の「日経コンピュータ Express Mail」、日経コンピュータ本誌、縮刷版など日経コンピュータ本誌の再録媒体において掲載させていただくことがありますので、ご了承ください。それ以外への転用は致しません。


今回のテーマへの投稿は1月30日(金曜)午後6時で締め切らせて頂きました。ありがとうございました。みなさまのご意見を基にした総括記事は、2月5日木曜に当サイトで公開する予定です。