主張・講演ERPパッケージ

ERPパッケージ導入での留意事項

先にERPパッケージの利点と,その運用を誤ったときの危険について述べました。ここでは,利点を追求し危険を回避するための対策をテーマにします。ERPパッケージの普及当初から教科書的な指摘がいわれてきました。それはそれで適切な指摘なのですが,現実的にはそれ自体に内蔵する危険もありますし,どうも売らんがなの策略に利用されていることもあります。それに対する指摘と対処についても考えます。


ERPパッケージ導入での教科書的な指摘

ERPパッケージを成功させるには,その当初から多くの指摘が行われていました。その主なものを列挙します。これらは,ERPパッケージに限らず,自社仕様でのシステム開発でも重要なことですが,ERPパッケージによる開発ではリスクが大きいために,特に重視されるのです。

導入目的を明確に
目的を明確にして,それの実現を重点的に推進することが必要です。ERPパッケージは価格が高いので,単に自社開発の代替手段としたのでは,かえって費用が高くなってしまうこともあります。BPR推進の一環としてパッケージを活用するというアプローチが必要です。
情報システム以外の対策を重視する
BPRを推進するためには,業務を変更することが肝心です。そのなかには,自社内部の変革だけでは解決できず,SCMのように関係先との交渉を伴う改革も多くあります。ERPパッケージという情報システムだけに関心が偏るようでは成功しません。
利用部門の認識を高める
ERPパッケージによる開発では,カスタマイズを減らすことがパッケージを安価に迅速に導入するポイントになります。それは,現状の業務に合わせて情報システムを構築するのではなく,ERPパッケージに合わせて業務の仕方を変更することも要求されます。これは利用部門の要望を抑えることでもあります。このような事情を利用部門が認識しないと,ERPパッケージを導入する効果が失われてしまいます。
要求事項を明確にする
業務をERPパッケージに合わせるということは,業務に合致したERPパッケージを選択することが重要だということになります。業務とERPパッケージがどの程度合致するかを調べることを,FIT/GAP分析といいますが,これを十分に行うことが必要です。それを効果的に行うには,個々のERPパッケージの検討に入る以前に,ERPパッケージに求める事項を明確にしておくことが重要なのです。
よきパートナーを選択する
ERPパッケージによる開発では,全社的なBPRとの連携を円滑にするために経営コンサルタントの協力を得ることと,ERPパッケージでのシステム開発に経験のある専門家の協力を得ることが必要になります。このようなパートナーの選択がシステムの成功失敗に与える影響は非常に大きいのです。
トップのリーダシップが重要である
このように,ERPパッケージの導入は,単なる情報システムの開発というよりも経営戦略の構築に近いものなのです。それを成功させるには,トップが強力なリーダシップを発揮して推進することが不可欠です。
小さく生んで大きく育てる
いかにERPパッケージが統合業務パッケージだとはいえ,当初から全業務を対象にするのは困難です。当初は一般会計など一部の業務から開始して,逐次対象業務の拡大を図るほうが円滑に導入できます。このとき当面は一般会計が対象だとしても,しっかりとした全体計画を策定しておかなければなりません。

これらの指摘は適切であり重要です。でも,現実にはなかなか難しいのです。次に現実面からの問題点と対処につて考えます。


カスタマイズの排除

ERPパッケージ導入に際して,最も強調されるのが「カスタマイズをするな」です。

カスタマイズの危険

カスタマイズ−特に独自の機能をERPパッケージの本体に組み込むカスタマイズ−をすると,そのために開発期間が長くなり開発費用がかさみます。しかも,ERPパッケージがバージョンアップしたときに,カスタマイズした部分が正常に稼動するかどうかの確認が必要になります。これは非常に困難を伴います。それで,ERPパッケージ導入を成功させるには,カスタマイズを極力抑えることが必要なのです。

「カスタマイズをするな」ということは,情報システム開発にコペルニクス的な発想の変革を求めることになります。従来は,ユーザニーズをよく取り込むことが開発の基本とされてきました。「ユーザ主導の情報システム」が当然といわれていたのです。ところがERPパッケージでは,ユーザニーズを極力取り入れないことを要求します。ERPパッケージの機能がBPRを実現しようという経営者の要求にマッチしたからそれを導入するのだと考えれば,これは「ユーザ主導から経営主導へ」の転換であるといえます。これを関係者全員が認識しなければなりません。

ところが,「カスタマイズをするな」とはいっても,現実にはそう単純ではないのです。

ERPパッケージの選択

カスタマイズを少なくするには,自社ニーズに最も適したERPパッケージを採用することが重要です。ERPパッケージには多様な製品があり,それぞれに特徴を持っています。しかし,どれが自社に適しているかを比較評価するのは,専門家でもかなり困難なのです。  ERPパッケージ導入の重要性を考えれば,本来は経営者自身が評価するべき事項ですが,経営者にその判断を求めることは困難でしょう。それを強いれば「たまたま,経営者仲間の会合で〇〇がよいといっていた」とか「〇〇の説明に来たときの話に同感した」ような理由で決定することにもなりかねません。それが危険なことは明白です。
 だからといって,その評価を利用部門や情報システム部門に任せたのでは,経営主導の情報化戦略にはならないでしょう。また,その解決方法としてコンサルタントの起用がありますが,これにも問題があります。多くのコンサルタントは特定のERPパッケージに関係しています。そのために,どのコンサルタントに相談するかによって,自動的にERPパッケージが決定されることになる危険があります。
 それを防ぐのがFIT/GAP分析です。事前に自社の業務を検討してERPパッケージに求められる機能を列挙して重要度を定めておくことが非常に重要なのです。

カスタマイズを抑えるために

ERPパッケージの不足機能には,中核機能の不足と入出力への不満があります。

中核機能の不足

いかにカスタマイズをするなとはいえ,販売形態や生産形態が自社独特のビジネスモデルを実現する機能がない場合は,それを放棄してまでERPパッケージに合わせることはできません。それを実現できるERPパッケージが発見できなかったときは,むしろERPパッケージによる開発を諦めたほうが無難です。
 しかし現実には,避けられるカスタマイズが多いのです。ERPパッケージの機能をよく検討すれば,ほぼ満足できる程度の機能を持っているのに,未だ検討の初期段階でカスタマイズが必要だという声があがることがよくあります。ベンダの技術者が不勉強でカスタマイズが必要だとしてしまうこともあるのです。それを回避するために,複数のベンダに提案書を提出させて,それらを比較検討するのが効果的です。
 逆に,ERPパッケージのほうが多くの機能を持っている場合があります。そのような場合,とかくそれらの機能を取り入れたくなりがちですが,それによりシステムが不要に大規模になることがあります。ERPパッケージはリアルタイム処理が標準になっていることが多いのですが,それを実現するためにネットワークやサーバに多様な対策が必要になります。リアルタイム処理が必要かどうかを検討することにより,全体の費用を抑えられることが多いのです。

入出力部分のカスタマイズ要求

カスタマイズの要求は多様ですが,入力方法の改善や出力帳票のデザインあるいは多様な情報出力要求が大部分を占めています。出力関係での要求の多くは,それらをデータウェアハウスのような情報検索系システムにすることにより回避できます。また,入力関係の幾分かはワークフロー管理システムに抱かせることができます。
 このように入出力部分(すなわち,ヒューマンインタフェースに関係する部分)をERPパッケージから切り離すことにより,ERPパッケージがカバーする範囲の規模が半減しますし,しかもロジックの分野に限定できますので取扱いが容易になります。
 さらには,情報検索系システムのデータ体系をERPパッケージ導入以前に構築しておくことができれば,全業務を通したコード体系やファイル体系ができます。それにより,ERPパッケージでの開発作業も容易になりますし,逐次拡大アプローチをとっても,後述するような業務間の再調整が比較的容易になります。これらは一般の基幹業務系システムと情報検索系システムの関係でも同じで,別章で詳述しています。

カスタマイズ禁止が継続できるか

適切なERPパッケージが選択できて,利用部門の現状維持的なニーズや趣味的ニーズを排除したとして,それが将来も続くでしょうか? そもそもこれまでの情報システムの開発や保守に費用がかかっているのは,ユーザのカスタマイズ愛好症と情報システム部門のガバナンス能力欠如にあるのです。もし,利用部門がERPパッケージに対するのと同様につまらぬ要求をつつしみ,情報システム部門が毅然とした態度で情報システムを構築できれば,現行の情報システムはもっと費用も安く要員も少なくですむのです。
 ERPパッケージの導入時期では,経営者も厳しく監視するのでユーザニーズを抑えることができるが,導入して数年も経つと経営者の関心が低くなります。そうなるとカスタマイズ愛好症が息を吹き返す。気がつかないうちにカスタマイズだらけのシステムになってしまう危険があります。これを防ぐためには,恒久的な監視体制を作る必要があります。
 しかし,あまりにもユーザニーズを抑制したのでは,ユーザは困ってしまいます。それを回避するためにも,情報検索系システムの普及は効果的です。


ERPパッケージ運用にかかる費用

ERPパッケージは,それ自体が高価なものです。大企業を対象にしたものでは数億円しますし,それによる開発にはコンサルタントやベンダ技術者の利用が不可欠であり,それにはソフトウェアの数倍の費用がかかります。開発運用プロジェクトにかなり多数の自社要員が長期間従事することになります。中堅企業向けのERPパッケージはそれほどではありませんが,企業の体力からすれば,相対的には大企業よりも負担が大きいともいえます。
 しかも,将来的にはこのような見える費用以外に,多くの費用がかかるのです。それを考慮しないと,せっかく導入したERPパッケージを維持できずに廃棄してしまうような事態にもなりかねません。

逐次拡大かビッグバンか

「小さく生んで大きく育てる」のは一見適切なアプローチですが,これには深刻な問題があります。既に多様な情報システムを持っているのですから,それらとERPパッケージで構築したシステムとの間のインタフェースが問題になります。しかも両者は異質のシステムなのです。データの受け渡しでの変換システムも必要ですし,汎用コンピュータでのバッチ処理とWeb環境でのリアルタイム処理のスケジュール調整も必要です。
 逐次拡大の方針ですと,適用業務を拡大するたびに新しい境界線が生じ,そのたびにインタフェースの作成が必要になります。しかも,このインタフェースシステムはかなりのベテラン能力を必要としますし,境界線が変われば不要になります。それなのに,このシステムはなんらの付加価値も生まないのです。

ですから,理想的には全業務をいっせいに置き換えるビッグバンアプローチのほうがよいのです。そもそも統合業務パッケージなのですから,全業務を検討して設定することにより,矛盾のないシステムができるのです。とりあえず特定の業務をやってみるようなアプローチですと,他の業務を取り込んだときに,それとの調整のために既存の業務も変更しなければならなくなる危険が生じます。
 しかしビッグバンを行うには,かなりの期間にわたって新旧の2系列システムを開発運用することになり,期間も費用も莫大なものになります。また,初めての経験ですから,当初からビッグバンを行うのはリスクが高すぎます。それでは,ERPパッケージを導入する敷居が高くなります。「小さく生んで・・・」は導入企業の都合もありますが,それにもまして売り手側の都合があるのです。

これを解決するために,私は次のアプローチを提唱しています。これは大企業にしか通用しないかもしれませんが,最初は小規模の関係会社を対象にしてビッグバンを行うのです。これによって,ERPパッケージ導入のノウハウや限界などを習得して,それから本体のビッグバンを検討するのです。これによって,両者の持つ危険を和らげることができます。
 対象関係会社は情報子会社にするのが適切です。一般に情報子会社は業務の種類は少ないし,データ量もあまりありません。しかも,利用者が情報システムのプロですから,どのような要求がどう影響するかも知っていますし,ある程度のトラブルは自力で対処できます。しかも,これで得たノウハウを営業に使うこともできるのです。

保守料が高い

ERPパッケージに限らず一般にソフトウェアは買取費用だけでなく保守料がかかります。これはERPパッケージそのものの機能アップを対象としたもので,個々の企業での業務アプリケーションの機能改善のためではありません。ですから,当初開発したものに全然手を加えなくても発生するのです。
 保守料はERPパッケージによりまちまちですが,なかには買取価格の20%以上のものもあります。ですから5年ごとに新しいERPパッケージを購入しているようなものです。高価なERPパッケージの場合には,毎年1億円以上の保守料を払うようなケースもあります。

保守改訂費用

当然ながら,自社の都合で改善や変更をするときには,別途の費用がかかります。経営環境は激変していますので保守改訂は必ず発生します。しかも,ERPパッケージは全業務に関係していますので,頻繁に改訂が必要になります。
 自社で構築した情報システムならば,情報システム部門が熟知していますので保守改訂は比較的容易です。ところがERPパッケージでは,内部まではわかりませんし,わかったにせよ勝手に修正することは禁じられています。ベンダに依頼することになりますが,開発に従事した技術者が他のプロジェクトに従事していたり退社していたりして,保守にも従事できる保証はありません。記録文書だけで業務システムを理解して保守するのですから,かなり非効率な作業になります。

バージョンアップ

自社都合ではなくメーカー都合によりバージョンアップが行われます。当然,新バージョンのほうが機能が優れているし,新しいバージョンにする費用は保守料に含まれていることが多いので高が知れています。しかし,新バージョンにより,既存のシステムが不都合なことが起これば利用企業が困るのですから,バージョンアップのたびにテストをして順調に動くことを確認しなければなりません。その費用はバカになりません。
 ERPパッケージは案外ハードウェアを選びます。新バージョンにより,それまで使っていたサーバやクライアントの容量を増強したり,OSを最新のものに変更したりする必要が出てきます。ネットワーク環境についても同様です。これらの費用が捻出できずに,バージョンアップを見送ることも多いのです。

問題は,古いバージョンのサポートが一方的に打ち切られることです。ERPパッケージにバグがあっても直してくれませんし,ましてカスタマイズをしたり,それの改訂はしてくれません。それを無理に依頼する場合には,非常に割高なものになります。
 ERPパッケージの導入時には企業収益がよかったのに,バージョンアップ時には悪化したために費用を捻出することができないとなると悲劇です。サポートが受けられないために,必要な改訂も危険なのでできず,既存のものを使い続けることになります。あるいは,ERPパッケージとは別の情報システムを補助的に作るようなことになるかもしれません。

このような事態に備えて,ERPパッケージを導入するときは,将来の保守やバージョンアップのための費用も見込んでおく必要があるのですが,ベンダはそのような忠告はしないし,社内でも高額な投資をした上にそのような費用までも要求しずらいので,問題を先送りしがちです。


ITガバナンスについて

ERPパッケージの導入は,情報化戦略の基本に影響を与えます。それだけにITガバナンスを強化することが求められます。ここでは,それに最も関係の深いトップと情報システム部門の関与について検討します。

なぜトップのリーダシップを強調するのか

ERPパッケージの導入にあたっては,かならず「トップのリーダシップが重要」だとか「導入目的を明確に」などがいわれます。これが重要なことはいうまでもありません。しかし,このようなことpは,どのような情報化案件についてもいえることであり,ERPパッケージに限定したものではありますまい。それを特に強調するのは,何か裏があるのではと勘ぐりたくなります。

自社開発よりも簡単に構築できるというのは幻想にすぎませんし,もしそうだとしてもコスト的に有利だとはなかなかいえません。BPRが実現しないとペイしないのです。ところが,BPRの実現にはERPパッケージ導入だけではなく,多様な取り組みが必要です。ERPパッケージは多額の費用がかかりますし,企業全体に影響します。それが失敗だったとはいえません。
 すなわち,ERPパッケージ導入はかなりのハイリスクだということです。ですから,トップのリーダーシップが重要になります。しかし勘ぐれば,トップを巻き込むことによって,コンサルタントやベンダが自分の責任を顧客になすりつけるための予防策だともいえます。当初はバラ色のERPパッケージ礼賛論を唱え,その効果が出ないと「それはERPパッケージの目的をよく把握せず適切な行動をしなったあなたの責任」というのですから。

でもこれは当然ですね。ましてERPパッケージの失敗を情報システム部門などの責任にするようなトップは,そもそもERPパッケージを導入しようと考えてはいけないのです。自動車の運転すらできない者が飛行機を操縦するようなことは避けたほうが安全でしょう。

情報システム部門の位置づけ

自社の情報システムについて詳しく知っていることが情報システム部門の重要な存在意義でした。情報システムをよく知っているからこそ,改訂作業も円滑に達成できたのです。ところがERPパッケージでの開発作業は,パッケージベンダの技術者と利用部門が中心になりますので,構築された情報システムについて,情報システム部門が利用部門以上に詳しいとはいえなくなります。

それに,ベンダが知らないカスタマイズを行なうと,ERPパッケージのバージョンアップなどのときに,トラブルが発生する危険があるので,改訂業務もベンダが行なうことを契約に盛り込んでいるのが通常です。そのため,情報システム部門は,システムの詳細を知っていても改訂作業を行なうことができないことになります。利用部門からの要求をベンダに伝えるだけの情報システム部門ならば,そのような部門は存在意義がないので,解体したらどうかということにまで発展することにもなります。
 でも,情報システム部門がそのような状況のときに,どの部門が企業全体の情報化戦略を考え,それを「統合業務」パッケージで実現できるのでしょうか? まして,カスタマイズ愛好症が復活したときに,誰がそれを水際で阻止するのでしょうか? ERPパッケージの導入では情報システム部門のITガバナンスの強化が必要なのです。

なかにはERPパッケージの導入検討には情報システム部門を入れるべきではないというコンサルタントもいます。あまりにもリスク回避を重視したり瑣末な事項に執着したりする情報システム部門は不適切です。しかし,抽象的な経営論を弄び現実の情報技術や利用環境に疎いコンサルタントが,自分の弱点を指摘されるのを恐れているようにも勘ぐられます。
 そのような反対勢力を排斥すれば,「経営者は情報技術などは知らなくてもよいのですよ(といってERPパッケージの中身をブラックボックスにする)。経営の観点から貴社のあるべき方向を示せばよいのです(といって,現場での問題から眼をそらせる)」といえば,ERPパッケージとERP(=BPR)を混同させて,「BPRが重要だ。だからERPパッケージを入れるのだ」という論理に引き込むことができます。
 しかし,ここで情報システム部門を無視するとITガバナンスの無政府状態になる危険もあります。ERPパッケージ検討を機会に情報システム部門を情報化戦略部門へと変貌させることが必要なのです。