JMS 日本経営システム

経営シリーズ

  • 情報システム

ERPパッケージ導入を成功させるには─業務革新につなげる5つのポイント─

No.620 | 2021年12月号

今月の視点


 日本企業が初めてERPパッケージ※を導入したのは、 1992年である。その後約30年の間に、ERPは広く普及してきた。

 統合保証、短期開発というERPの利点を享受した会社がある一方で、期待した効果を得られていない会社も少なくない。「業務混乱と費用の膨張に耐えかねて、ERP導入を断念した」という深刻なお話を伺うこともある。こうした会社の経営者の多くは、ERPに過剰な期待を抱き、システムベンダーに過度に依存して導入を進めてしまったことを自戒されている。

 基幹システムの刷新をはかる際には、自社にふさわしい開発手段を慎重に選び、ERPを選んだ場合には、それを前提とした新たな業務基準を自ら定め、確実に業務革新を実現したい。

 今月は、ERPの利点を確実に享受するために、どのように選択・開発・導入を進めていくべきか、考えてみたい。

※ERPパッケージとは、財務会計、販売、購買、在庫管理など事業の基幹業務を支える情報システムを、一つに統合して製品化したパッケージシステムの総称。以下、ERPと表記。

1 問題事象

 ERPの導入過程で発生する問題事象は、以下3点に集約される。

①稼働遅延・不稼働

 アドオン※やカスタマイズ※の開発遅延、 マスタ整備の停滞などによって稼働が遅れ、最悪の場合は不稼働となる事象である。

※アドオン:ERPが具備していない機能を開発するため、別の追加プログラムを独自開発し、ERPとのデータ連携させること。ERPパッケージの標準機能・プログラム自体は変更しない。

※カスタマイズ:ERP標準機能のプログラム自体を変更すること。

②過剰投資

 ERPの導入過程で業務不適合機能が事後発覚し、アドオンやカスタマイズが増え、予算を超過してしまう事象である。

 またERPの保守期限終了により、想定外の追加更新投資を余儀なくされることもある。

③目的未達

 例えば、重複入力廃止による業務省力化を狙ってERPを導入したが、現場の業務負担はかえって大きくなってしまったというように、導入目的を達成できなかった事象である。

 以上の問題事象が発生する主因は、以下の3点にある。

①適合しないERPの選択

 自社に適合しないERPを選ぶことにより、アドオンやカスタマイズが増え、投資費用も膨らみ、開発期間も長期化する。

 自社が新システムに要求する機能のうち、要求に合致しているERP機能の割合(適合率)が、8割を下回ると、上記のような問題事象が発生する確率は高くなる。

②現行業務への執着

 ERPは汎用品である。いかに適合率が高くても、現行業務を全く変えずに導入することはできない。現行業務に過剰に執着してERPの導入を進めてしまうと、アドオン・カスタマイズが増え、前述のような問題事象が発生しやすくなる。

 但し、現行業務は、業務担当者が工夫を積み重ねて作り上げてきたものであり、担当者にも強い自負がある。ERPに合わせるというかけ声だけで変えられるものではない。

③ユーザー推進事項の欠落

 いかに優れたERPとシステムベンダーを選定しても、ユーザーが決めるべきこと、ユーザー自身で進めなければならないことをおろそかにしてしまうと、問題事象を招く。

 問題事象を回避するには、現行業務の把握、ERP導入後の業務ルールの設定、アドオン要請への対応、マスタ整備などの事項を、ユーザーが責任をもって確実に遂行しなければならない。

 以上をまとめると、ERPを円滑に導入し、期待した効果を享受するには、下記3点が必要条件といえる。

❶自社に適合するERPを選ぶこと

❷選んだERPに、できうる限り業務を適合させること

❸ユーザーが主導してプロジェクトを進めること

2 ユーザーが主導する推進事項

 ERPを前提として基幹業務システムを刷新する際には、ユーザー自身が、以下の推進事項を遅滞なく進める必要がある。

(1) プロジェクト計画立案
  (自社導入組織の組成、目的定義、稼働目標と仮説設定)

(2) 基本要件の策定

(3) ベンダー選定

(4) 要件適合調整

(5) 新業務設計
  (ERP導入後の具体的業務手順・基準・ルールの設定)

(6) 設計・品質監理
  (追加開発機能の設計監理、受入テスト計画策定と実行)

(7) 移行
  (移行計画の立案、移行契約監理、移行作業実行管理)

(8) 運用テスト・初期流動対応

 次頁以降に、推進事項ごとの概要を記述する。

(1) プロジェクト計画立案

 トップマネジメント直轄のプロジェクトチームを組成する。

 プロジェクトチームはまず、基幹業務システム刷新の目的を明確に定義・共有した上で、目的実現時のシステムの全体像(仮説)を描き、その稼働目標とスケジュール、投資予算の概要を設定する。

(2) 基本要件の策定

 商流、物流、製造実態、取引条件、管理会計制度など、システム刷新を進める上での前提条件や現行業務内容を具に把握した上で、新システムに求める要件を具体的に定義し、「基本要件書」としてドキュメントにとりまとめる。

 当然のことであるが、基本要件書は、現場業務責任者と論を尽くした納得づくのものでなければならない。

 自社に適合するERPを選ぶため、基本要件書はERPを選択する前にとりまとめ、候補となるERPとの適合率を正確に算出できる記述仕様にしておく。

(3) ベンダー選定

 基幹システムの開発(ERP導入)を委託するベンダー候補を探索し、基本要件書を基に提案を依頼する。

 候補ベンダーの提案を受領する前に、選定基準を明確にしておく。ERPの適合率、価格・スケジュールの妥当性、契約条件、導入担当者条件は、重要な選定基準となる。

 選定基準に基づいて提案内容を精査し、最適な条件を引き出した上で、ベンダーを選定する。

 選定したベンダーとはまず、要件適合調整(後述 (4))を対象とする準委任契約を締結する。

(4) 要件適合調整

 基本要件書を基に、対応するERPの機能を一つひとつ確認し、機能ごとの業務適用方針を定めていく。作業は、プロジェクトメンバーと選定したシステムベンダー担当者との集中協議を重ねて進める。

 基本要件に記述した品質条件と、ERP標準機能との間に差異がある機能については、アドオン開発をして基本要件を充足させるか、ERP標準機能使用を前提として基本要件で想定していた業務を変更するか、判断していく。この一つひとつの判断が、基幹システムの品質、投資、そして業務効率を決める。

 一通りの要件適合調整が完了した後に、適合率・アドオン開発部分の追加価格条件等をふまえて、ERPを導入するかどうかの最終判断を下す。導入を決めた場合は、ベンダー選定時に合意した条件に基づき、システムベンダーと契約を締結する。

(5) 新業務設計

 要件適合調整の結果に基づき、ERP活用を前提とする業務手順・基準・業務ルールを定める。具体的には、当初作成した基本要件書を更新・追記する形で、業務基準書としてとりまとめる。基本要件を設計した時と同じように、業務責任者と論を尽くし、納得づくで策定しければならない。

 業務基準書は、以下のような目的で活用される。

 ・ ベンダーとの要件適合調整をした結果の確認証憑

 ・ 業務責任者と要件適合調整をし、合意した結果の確認書類

 ・ 業務担当者にERP導入後の業務内容を説明する資料

 ・ 運用テスト・本番稼働で都度参照する業務マニュアル

(6) 設計・品質監理

 要件適合調整でアドオン開発とした機能の基本設計書を確認し、監理する。入出力機能を中心とする外部設計とERPとの連携処理仕様が、監理の焦点となる。

 アドオン部分の機能不備が導入過程で発生すると、稼働遅延リスクが高まる。基本設計書とプログラム品質は、受入段階でユーザーが確実に検証しておかなければならない。

 基本設計が完了した後、ユーザーがプログラム機能を検証するための受入テスト計画を事前に策定しておく。受入テスト計画は、検証対象とする業務パターン、テスト手順、使用するテストデータ条件などを具体的に定義しておく。

 プログラム完成後は、受入テスト計画を基にテストを実施し、機能を周到に確認する。

(7) 移行

 ERP導入時のマスタ整備やデータ移行作業は膨大であり、導入のボトルネックになることが多い。

 基本設計書の確認完了後、マスタ整備方法、ERPに初期セットするデータ対象範囲、移行元データ、旧システムデータを活用した移行手法などを定めた上で、移行計画書としてとりまとめ、計画的に推進する。移行作業の一部をベンダーに委託する場合には、移行計画書に委託内容を明記し、委託の契約証憑とする。

 移行作業の実行段階では、事務局が実行進捗を確実に把握・管理して遅延を防ぐ。

(8) 運用テスト・初期流動対応

 業務担当者への運用・操作教育、実データを利用した運用テスト計画を綿密に立てて実施した上で、本稼働させる。

 運用テスト期間および稼働後数カ月は、データ入力進捗を監視する。業務担当者から不備事象の連絡があった場合には、まずマスタ設定不備がないか、誤操作がないかを確認し、要因を特定する。あってはならないことだが、運用テストや初期稼働段階でプログラム不備が発覚した場合には、即時にデータ復旧と改修を施す。但し、操作性の改修要望など不備事象以外の要請には慎重に対応し、今後の改修計画立案の材料とする。

 次節では、ERPを導入した2社の事例を紹介する。いずれも、当初から前述の標準手順を適用した事例ではなく、問題事象に直面した後に、上述の標準手順を適用した事例である。

3 A社の事例

(1) A社の状況

 A社は、大手電機メーカーを主要顧客とする部品メーカーである。数年前、主要顧客の経営破綻が引き金となり、業績が急落した。取引銀行が再生を主導し、経営再建で定評のある投資会社がスポンサーに選定された。投資会社の担当者が副社長に就任し、実質的な経営再建を推進することになった。

 副社長がA社にきてまず頭を悩ませたのは、信頼できる経営数値、セグメント情報を得られないことだった。部門ごとにセグメント別業績数値を提出させても、財務数値とつじつまが合わなかった。計算根拠を詰めても、担当者の回答は要をえなかった。

 A社の決算や業績管理資料は、各部門がエクセルを利用して独自に実績をとりまとめ、これを経理部が汎用会計パッケージに入力して決算書類を作成していた。各部門の実績集計作業はブラックボックス化していた。

 副社長は、一日でも早く全社業務を統合した基幹システムをつくり、信頼できる元データから出されたセグメント情報を基に経営判断できる状態にしければならないと強く感じた。

(2) ERPの選択と先行導入着手

 副社長は、豊富な導入実績があるERPを導入することを決めた。そのERP導入を手掛けているベンダーに声をかけ、できる限り早く導入することを依頼した。ベンダーの担当者は副社長の意を汲み、正式契約手続を待たずに導入作業に先行着手した。

 ベンダーと正式契約を締結する前に、副社長がERP導入責任者に任命した生産管理部長に状況を聞いたところ、次のような想定外の回答があった。

 「ERPの説明を受ける度に、現行業務と適合しない部分が発覚しています。正直、 このまま導入できる自信がありません」

 これを聞いた副社長は、懇意にしていた経営コンサルタントに声をかけ、状況をどう打開すべきか、相談した。

 ひとまずベンダーとの正式契約締結を保留し、コンサルタントとともに実態を把握した上で打開策を練ることにした。

(3) プロジェクト計画

 副社長とコンサルタントはまず、A社とベンダー双方の担当者に話を聞き、導入作業の実態を正しく把握することにした。

 導入作業は、現行業務とERP機能を比較する方式で進められていた。A社担当者は、現行業務をベンダー担当者に説明していたが、専門用語や煩雑な業務用書類が壁となり、ベンダー担当者はその内容を十分に理解できていなかった。

 ベンダー担当者は、A社担当者にERPの機能を丁寧に説明していた。しかしA社担当者は現行業務を前提として、ERPを活用して業務を進めるイメージを描くことができず、ひたすらに現行業務を説明することに終始していた。この結果、アドオン・カスタマイズ対応という結論が膨れ上がっていたのである。

 副社長は、仕切り直しが必要だと感じた。プロジェクト体制を再組成し、コンサルタントの支援を受けてプロジェクト計画を改めて立て直した。

 新たなプロジェクト計画は、選定したERPの導入を前提とするが、副社長が直接統括するプロジェクトを再組成し、A社が主導して導入を進めることを前提として作成された。「経営判断のための情報取得」という目的を実現するための新たな業務処理内容を具体的に設計し、その業務を遂行するために絶対に必要となるシステム機能とその品質条件(基本要件)を、まずはA社で定義することにした。その上で、基本要件を基に、具体的なERPの適用方法を定めていくことにした。

(4) 基本要件設計

 プロジェクトは、現行業務を分析・共有した上で、新たな基幹システムに求める機能を具体的に記述し、これを「基本要件書」としてドキュメントにとりまとめた。

 基本要件書は、ERP導入を前提とし、要件とERP標準機能とのギャップが明確になる記述仕様で作成した。

(5) 要件適合調整

 基本要件書が完成した後、ベンダーと要件適合調整に関する準委任契約を締結した。

 要件適合調整作業は、基本要件書とERP機能とを照らし合わせ、一つひとつ適合のさせ方を決める方式で進めたため、スピーディに協議が進められた。

 協議は、A社プロジェクトメンバーとベンダー担当者とで短期集中で審議し、コンサルタントが議事運営を担当した。そのまま要件に適合できないERP機能が複数出されたが、標準機能を前提とする業務代替案をその場で設定し、業務責任者の同意をとった。ERP導入によって負荷が増えてしまう業務もあったが、「できる限りアドオン開発はせずに短期導入する」というプロジェクト方針に基づき、多くは業務変更で対応することになった。

 一点、作業過程で致命的なギャップが発見された。副社長は、当初から累加法による組別総合原価計算に基づく製品別利益実績情報の取得を要請しており、基本要件もこれを前提として組み立てられていた。一方、ベンダーが提案したERPには、非累加法による標準原価計算機能の適用を前提としていた。本件について、ベンダー責任者との協議・交渉を重ね、結果としてベンダー側が開発元のモジュール変更をしてもらうことになった。

 要件適合調整がほぼ完了したところで、システムベンダーから導入工程に関する正式見積が出された。A社側で更新した基本要件書を契約証憑とし、要件変更がない限り価格変更がないことを、正式契約に組み込んでもらった。

(6) 導入

 移行・運用テストの過程で、業務担当者から様々な要請が出されたが、契約効力と要件統制により、追加投資は全く生じなかった。

 要件適合調整の結果に、A社としての例外処理対応を含めた業務ルールを定め、新業務基準書としてとりまとめ、それを基に現場への浸透をはかり、周到に運用テストを続けた。新業務基準書は何度もブラッシュアップされた。

 マスタ整備をはじめとする移行作業は難航したが、A社は異例の短期間でERPの導入をはかることができた。

 稼働段階では、ERP導入により現場の負荷が高まる一部の業務が懸念されていた。しかし、要件設計段階から協議を重ねて合意していたこと、業務基準書に基づき周到に運用テストを実施したことにより、本稼働時には現場への定着がはかられ、信頼できるセグメント別経営情報の取得という基幹システム刷新の目的は達成された。

4 B社の事例

(1) B社の状況

 B社は、車両用基幹部品を製造するメーカーであり、持株会社が事業会社の株式を保有するグループ経営形態を採っている。近年、海外を含めた積極的な企業買収を進めてきたこともあり、グループ会社の業務・システムは、ばらばらの状態だった。このため連結決算には膨大な業務負荷と時間を要していた。

 社長は、業界で実績のあるERPをグループ各社に一斉導入し、業務の効率化・合理化、決算の早期化をはかるとともに、各社の経営実績数値をスピーディに、横並びで見られる状態にすることを構想した。

(2) ERP導入着手

 社長は、ERP導入に着手することを決断した。大手IT企業に勤めていた元システムエンジニアを採用し、システム課長としてERP導入を任せることとした。

 社長の命を受けたシステム課長は、 前職の会社の元同僚に連絡し、 部品メーカーの導入実績があるERPの見積もりを依頼した。

 正式見積は要件定義工程を終えてから実施することを条件とした簡易見積ではあったが、想定していた投資額の枠内に収まっていたため、前職のIT企業をERPベンダーとして導入作業を委託することを起案し、承認を得た。

 早速、ERPベンダーが主導する要件定義作業が開始された。要件定義作業は主として製造部の各課長が対応し、率直に業務の現状と要望を伝えた。

 要件定義工程が完了した後、ベンダーから正式見積が提示された。見積は、当初想定していた投資枠を大きく上回っていた。パッケージ標準機能をそのまま適用できる部分が想定以上に少なく、アドオン開発が全体価格の半分以上を占めていた。

 システム課長からの報告と稟議を受けた社長は、要件定義に参加していた製造部課長を呼び、状況を聞いたところ、次のような話が聞かれた。

 「標準機能をそのまま使える業務はほとんどありませんでした。まだ業務内容はベンダー担当者に十分に伝わっていません。業務に適合しない機能は、また後で出てくると思われます」

 要件定義に関わっていた他の社員の話も聞いたが、ほぼ同じような意見だった。

 社長は悩んだ末に、選定したERP導入を停止することした。ERPベンダーには、要件定義に関わる契約金額を支払い、自社に適合する新たなERPを改めて選定することにした。

(3) 体制の再構築・プロジェクト計画

 社長は、懇意にしているコンサルタントに声をかけ、実情を伝えた上でERPベンダーの再選定を支援してもらうことにした。管理部長をリーダーに据え、システム課長は事務局とし、業務に精通した課長クラスのメンバーを再選定し、プロジェクトを再組成した。

 プロジェクトはERPの導入目的を再確認し、計画を立て直した。

(4) 基本要件の設計

 プロジェクトは、ERP再選定の前に、自社としての基本要件を明確に定義することにした。業務システムの現状を改めて可視化した上で、目的を達成するために、新たなシステムが具備しなければならない要件を具体的に定義していった。社長には、ERP導入以外の選択肢はなかったため、ERPの適合度が浮き彫りになる記述仕様でとりまとめることとした。

(5) ベンダー選定

 プロジェクトは、3社のERPベンダーに声をかけ、評価基準を設定して適合度を評価した。

 いずれの候補ベンダーが提案するERPも、原価計算システムだけは適合度が半分にも満たなかった。原価計算システムを除くと、3社のうち1社が提案するERPは、適合度が80%と相対的に高かった。

 プロジェクトは、このERPを採用し、原価計算システムは独自開発とする案を上申した。現行業務を踏襲せず、ERP標準に合わせることによる業務革新を旗印とし、各部門との調整により、最終的には90%以上の適合度を目指す方針を定めた。

(6) 要件適合調整

 基本要件書とERP標準機能の説明書を基に、ERPベンダー、製造部門責任者との要件適合調整協議を重ねた。

 結果、アドオン開発は大幅に抑制され、投資は想定を下回る水準になった。

 その後移行・導入作業が進められ、計画通りにERPは導入された。

5 留意点 (ERP導入を業務革新につなげる5つのポイント)

 事例のA社とB社は、自社が主導して要件設計、開発・導入を進める方式に切り替えたことにより、基幹システムの刷新目的を達成することができた。

 事例に基づき、改めてERP導入をはかる際に留意すべきことを5つ挙げておく。

(1) 自社推進体制の整備

 基幹システムの刷新をはかる時は、以下の条件を満たす社内推進体制を整備すべきである。

《条件1》トップ直轄プロジェクト

 事例の2社はいずれもトップ直轄プロジェクトを組成し、機動的に意思決定できる体制を整えたことにより、難局を乗り切ることができた。ERPの選択・導入の過程では、多くの意思決定事項があり、失敗するプロジェクトは、ここで意思決定の不全がある。トップ(CIO)が実質的な意思決定をできる体制をとることが、成功の必要条件といえる。

《条件2》業務の中核人材の登用

 プロジェクトメンバーは、情報システム部門だけではなく、業務の中核を担う人材を任命し、業務部門が主体的に取り組む責任体制を整えなければならない。

《条件3》事務局機能の充実

 業務の中核を担う人材は、多忙である。メンバーの負荷を極力抑えながらプロジェクトを遅滞なく進めるために、事務局機能を充実させる必要がある。事務局は、調査、論点設定、仮案設定、協議運営を担うとともに、「システム化できない業務を、いかに負荷なく遂行できるようにするか」といった現場の切実な課題に寄り添って丁寧に対策を考えなければならない。またマスタ整備に関わるERPの移行には多大な労力がかかる。業務責任者に完全に任せきってしまうと、遅延を招く。現場とともに、移行に関わる課題にも寄り添って方策を考え、徹底支援する動きが欠かせない。

 トップマネジメントは、さらに多忙である。プロジェクトが直面している状況を、トップマネジメントに正しく伝え、意思決定を仰ぐことは簡単ではない。しかしこれをおろそかにすると、問題事象を招く。トップマネジメントに対し、簡潔にわかりやすく状況を報告し、決めるべき論点を明確にし、プロジェクト案や選択肢を提示する形で意思決定準備をする事務局機能が欠かせない。

(2) ベンダー選定前の要件設計

 自社に適合するERPを選択するためには、新業務のあり方とシステムに求める機能を具体的に定義した基本要件を、 ERP
を選択する前に、ユーザー自らが作成しておくべきである。

 ERPベンダーの導入プロセスには、通常「要件定義」といわれる工程がある。これはERPを選択するためのものではなく、ERPの適用を前提とした要件適合調整作業といえる。

 事例B社は、 ベンダーとの要件定義作業を実施した後にERPの導入をとりやめたが、ERPを選定した後に導入を取りやめる決断をすることは容易ではない。ERPの選定前に、選定基準としての基本要件をもっていなければならない。

 また、選択したERPに業務を適合させるためにも、基本要件は必要である。後述する要件適合調整は、具体的な基本要件を基に、漏れなく効率的に行うことが望ましい。

(3) 明確な基準に基づくERPベンダーの選定と契約

 ERPベンダーを選定する際には、 候補各社が提案するERPの機能が、基本要件を充足しているか否かを、具体的かつ定量的に把握しなければならない。そのために、基本要件書は、ERPが要件を満たせるか否か、満たせる場合はどのような手段で満たせるかということを、具体的に検出・比較できるように作られていなければならない。こうした適合率をはじめとする具体的な基準を明確にし、ERPベンダーを選定する必要がある。

 ERPを導入する場合、要件適合調整を終えなければ具体的な投資額が確定しないため、契約時には金額条件が曖昧になりがちである。しかし、ユーザーとして投資予算は固めておく必要がある。ベンダーを選定する段階で契約上の金額条件を合意しておくことが、投資予算遵守の鍵となる。

(4) 選定したERPへの適合

 ERPを選んだからには、ERP標準機能の活用を原則として、新たな業務を設計すべきである。現行業務に執着すると、アドオンが膨大になっていく。

 しかし、ERPは既製品である。アドオン開発を一切せずに導入できることは少ない。標準機能活用を強引に押し付けすぎると、業務効率が著しく阻害され、当初の目的が実現できず、最悪の場合は稼働できなくなることもある。

 事務局は、アドオン開発の意思決定材料を一つひとつ準備するとともに、現場業務責任者との調整を、丁寧に、迅速に行わなければならない。

(5) 事実に基づく業務革新

 基幹システムを刷新する際には、標準化・効率化に向けた業務革新をプロジェクト目標に設定すべきである。

 業務革新は、現行業務にこだわっていては実現できない。しかし、現行業務の把握を怠っても、業務革新を実現することはできない。例外処理を見落とし、その対応策が要件から漏れてしまったことが、不適合の事後発覚、問題事象を招くことは少なくない。

 具体性と実効性を備えた革新的な新業務案は、対外取引関係、管理会計制度・原価計算制度など基幹システムの前提条件、例外を含めた業務処理パターンと現行業務処理内容等を具に把握してこそ生み出される。

 現場に入り込み、現行業務の徹底した理解に努め、その創意工夫に感嘆しながら、具体的な事実に基づく切実なニーズをつかみ取る。地道な作業ではあるが、これを実践できると、業務革新を支えるERPを選び、円滑に導入できる確率は、大きく高まる。