• HOME >
  • ZAC BLOG >
  • 【チェックリスト付き】現役導入コンサルが教える「失敗しないERP導入」

【チェックリスト付き】現役導入コンサルが教える「失敗しないERP導入」

【チェックリスト付き】現役導入コンサルが教える「失敗しないERP導入」
  • このエントリーをはてなブックマークに追加
  • RSS2.0
  • ATOM

2021/1/15公開

筆者は本ブログを運営する株式会社オロの基幹システム「ZAC」の導入コンサルタントとして6年業務に従事しています。これまでに30件以上の導入プロジェクトに携わり、お客様の導入プロジェクトを支援して参りました。本記事では、これからERPを導入する方や導入を検討している方に知っていただきたい「ERP導入の基礎知識」や「導入の失敗事例」をご紹介しています。

目次

    ERP導入の基礎知識

    ERPの導入について、導入に関わる人、基本的なプロジェクトの進め方、プロジェクト期間について説明します。ERPの導入については、そのパッケージ選定までのフェーズがあることが大半ですが、今回の記事では、導入すべきERPが選定された後の導入フェーズでの基本事項に絞り説明を行います。

    なお後述する失敗事例としては、パッケージ導入フェーズになり押さえられていないといけないもの(導入フェーズで決まっていないことが失敗の原因になりうるといえる)もありますので記事で記載している「フェーズ」という点にも意識いただけると幸いです。

    多くのERPの導入プロジェクトにおいて、ERPが導入される企業の社内で「導入プロジェクトメンバー(PJメンバー)」が選定され、プロジェクトが進んでいく場合が大半です。プロジェクトには、「プロジェクトの責任者」、「プロジェクトリーダー」、「ERPのモジュールの担当者」がアサインされます。

    プロジェクトの責任者

    導入プロジェクトの責任者となり、社内外に対して導入プロジェクトの責任を持ち、プロジェクト進行上想定していなかった事項に対する変更に対する対応や全体進捗に関する管理を実施します。多くの場合が役員の方など、会社の重要事項を決定する立場にある方が担当されています。

    プロジェクトリーダー

    プロジェクトの中心となり、推進する担当者です。プロジェクトリーダーは社内の各部署(ERPのモジュールの担当者)やERPのパッケージベンダーとの連絡調整を行い、プロジェクトを推進する担当者となります。

    ERPのモジュールの担当者

    ERPのモジュール(各機能)の担当者の選定基準は導入企業により異なります。主にERPのモジュールを起点にモジュール単位で担当者がアサインされる場合と、自社の部署を起点に部署ごとに部署にERPを浸透させていくための責任者(事業部・部署の責任者)がアサインされるパターンがあります。
    後者の場合、アサインされる担当者は自部署の業務の責任者でありつつ、ERPの仕様や運用を決め、ERPを自部署に浸透させる役割を担うことになります。

    以上の役割をもった導入プロジェクトメンバーにてERP導入プロジェクトが進みます。主に下記の図のような進め方をとることが多いです。フェーズが進むにつれて導入プロジェクトメンバーだけでなく、社内システム担当、社内展開のための各部署のキーマン、現場メンバーなど関わるメンバーが増えていきます。

    ERP導入プロジェクトの進め方

    事例から学ぶ導入失敗の原因

    導入プロジェクトメンバーをはじめ、多くの方が日常業務をこなしながら関わるERP導入プロジェクト(以下PJ)は、必ずしもスムーズに進むとは限りません。ここからはERP導入の失敗事例とその原因をご紹介します。本記事では重要な順に4点ご説明します。

    ERP導入が失敗する事例
    • 事例1:導入の目的・ゴールが明確になっていない
    • 事例2:ERPと既存システムの適用範囲・つなぎ合わせの部分が整理できていない
    • 事例3:PJメンバーの稼働負荷が高すぎてスケジュール通りにPJを進めることができない
    • 事例4:導入機能・ERPの運用について着地点を見いだせない

    事例1:導入の目的・ゴールが明確になっていない

    ERPに限らずシステム導入において最も重要な視点として、システム導入をすることで企業として(導入部署として)達成すべき目的・ゴールがあるかと思いますが、事例1はその目的・ゴールが明確になっておらず、導入後のシステム導入効果を発揮できなかったり、導入中にPJの適切な意思決定ができずPJ(プロジェクト、以下PJ)がとん挫していく、という場合です。

    導入の目的・ゴールが明確になっていないと、導入の前のフェーズであれば、適切なパッケージ選定ができなかったり、適切な要件定義ができなかったりとPJの根幹にかかわるような部分での判断が正しくできないことにつながります。また、例えば導入フェーズでは社内のユーザー展開に対して、会社としてどういった目的(メリット)があるかを打ち出せずスムーズなシステム利用につなげられない可能性があります。

    1点目の失敗事例を避けるためにシステム導入の目的・ゴールを具体化することが大切です。例えば

    • システムを導入することで帳票加工にかかっている作業工数を◯%削減する
    • 月次処理にかかる時間を◯日削減する

    などの数値目標です。

    こういった目的が明確になっていることで、その目的を達成するための最適なパッケージ選定ができたり、PJ進行中の意思決定を迅速に行うことができます。また明確な目的・ゴールというのは上記のような具体的な数値目標だけに限りません。

    筆者が経験したZAC導入PJで多かったのは、
    「ERPを導入し稼働させることができる=目標達成」と捉えることができる目標もありました。

      • システム導入によって自社の業務をシステムベースの業務フローに沿ったものとして業務標準化を図る
      • Excel運用している業務をシステム化し、電子承認機能を利用することで社内の内部統制の強化を図る

    といった目標です。

    導入の目的・ゴールを明確にするには

    システム導入の目的・ゴールが明確になっていることのチェックポイントとして下記が重要とえます。

    1. 目的・ゴールはシステム導入フェーズでは明確になっている
    2. 目的・ゴールはシステム導入のどのタイミングで達成できる性質のものか、いつ効果測定ができるのか認識できている

    ①について、システム導入フェーズの前にはパッケージ選定やシステム要件の整理フェーズがあります。
    このタイミングで経営判断を行う立場の方がシステム導入をすることで「何を達成したいのか」が打ち出されている必要があります。目的・ゴールに見合うシステムが選定されていたり、目的・ゴールをかなえることを検討するための要件定義がなされていないといけないためです。

    ②について、システム導入後その目的・ゴールが達成されているのか、いないのかを適切に判断ができるタイミングがシステム導入のどのフェーズであるかを意識できるようにしておくこと、導入PJ進行中のメンバーについてもその点を意識できている必要があります。

    例えば、システム導入の目的が上記の数値目標ですと、目標が達成でき、その効果測定ができるのはシステムカットオーバー後(より厳密にはシステムカットオーバー後システム運用が落ち着いたタイミング)と言えます。一方で、業務標準化や内部統制の強化といった目標では、システム運用を検討するフェーズ(導入フェーズ)で理論的には目的が達成できること(または達成可能か判断できること)になります。(もちろん、理論的に検討したシステム運用が、カットオーバー後に運用されなければなりませんので、その運用が行われていることをチェックする必要があります。)

    強調してお伝えしたいのは、システム導入の目的にもさまざまあり、その内容によって、目的達成のために何に対して力を入れて検討する必要があるのかをPJメンバーが考えられていることが必要だと言えます。

    事例2:ERPと既存システムの適用範囲・つなぎ合わせの部分が整理できていない

    ERPのシステム導入において、そのシステムの適用範囲が大きく、システムで自社の業務を一元管理できることはシステム導入のメリットのひとつとなることがありますが、その一方でシステム単体で自社の全業務を管理することはまれだと思います。例えば、弊社システム「ZAC」の場合ですと、財務会計の機能や給与計算の機能は持ち合わせていないため、クライアント側には「ZAC」の他に会計システムをご利用いただいたり、給与計算のためのシステムをご利用いただくことが大半です。

    2点目の失敗事例は、「導入しようとしているERPの適用範囲がどこまでなのか」がPJの開始前に整理されていない結果、導入フェーズになって社内の要件が思わぬ方向に逸れていったり、全くシステムの分野と異なる要件に派生してき、結果システム導入の目的を見失うという事例になります。

    1点目の失敗事例にも通ずる話ですが、今導入しようとしているシステムが何を管理するためのシステムであるか(何を達成するためのシステムなのか)が整理できておらず、結果として、システム導入の目的・優先度がPJ進行中に当初と変わっていくといったケースがあります。

    また、見出しで「ERPと既存システムの適用範囲・つなぎ合わせの部分」と表現しましたが、できれば、システム導入フェーズが始まる段階では、何を管理するためのシステムであるかが可視化できるところまで整理できているとよいでしょう。

    これが正しく整理されていないとPJ進行段階で下記のようなことに陥りかねません。

    • システム導入フェーズになり、他システムとの適用範囲の棲み分けを検討することになりプロジェクト進捗に影響を及ぼす。
    • 導入中に導入範囲外の機能モジュールの追加となり費用・プロジェクト進捗に影響を及ぼす。

    特にパッケージのシステムの場合だと導入~カットオーバーまでの期間が短いことがメリットである一方で、機能範囲などは決まった前提でPJスケジュールが組まれているケースが多く、システムの適用範囲などを導入フェーズで検討する余裕はなく、カットオーバー時期に影響を与える可能性が高いと言えます。

    1、2点目の事例はシステムの導入フェーズでの失敗に限った失敗事例というよりは、システム導入の初期検討段階での目標設定やシステムの適用範囲の整理ができていないことが原因で後のフェーズに影響を及ぼすことになる事例でした。3点目は導入フェーズでの失敗です。

    事例3:PJメンバーの稼働負荷が高すぎてスケジュール通りにPJを進めることができない

    導入PJのPJメンバーは、通常業務があるなかで導入PJにアサインされている場合が多いです。(専任でPJメンバーにアサインされているケースは少ないです。)

    導入PJでは、パッケージベンダーなどの導入サポートを受けながらPJを進行することが多いですが、自社のPJメンバーも稼働負荷が高い状況となります。この稼働負荷を見越したアサインとなっていないと、PJ進行に対して自社のメンバーが必要なタイミングで必要な作業に時間を割けずにPJスケジュールを当初想定していた通りに進めることができずシステム稼働に影響が出てしまう場合があります。

    事例4:導入機能・ERPの運用について着地点を見いだせない

    事例3と同様、導入フェーズでの失敗となります。
    ERPシステムの場合、導入フェーズで運用の最終確定を行うことが多いです。弊社ERP「ZAC」の場合だと動作変更・項目名称変更をパラメータ設定として導入フェーズで実施、最終確定するという進め方をとることがあります。逆に表現すると、導入フェーズになり、運用を一から検討していくというのはパッケージシステム導入のケースとしては少ないと言えます。

    会社の規模や状況によりますが、導入フェーズになり、運用を一から検討していくことがが少ない理由として、お客様がERPパッケージに合わせるという考え方でシステム導入を行っていくことが多くなっているからです。個社別の作り込みでないパッケージシステムを導入する場合、システムの基本機能・業務フローが定まっており、パッケージに会社の業務を合わせるという考え方で導入を進めることで、(フルスクラッチのシステム開発に比べて)初期費用を抑えることができたり、属人的となっている業務フローを標準化することにつなげられたりするというメリットがあります。

    一方でシステムを業務に合わせる考え方で導入を行う場合、導入フェーズの前にシステム要件に関する要件定義を行ったり、パッケージ製品に対するプログラム開発を行うことでカスタマイズ開発フェーズが導入フェーズで入ることがあります。こちらは自社の業務に沿ったシステムとなる一方で、初期システム構築作業に追加で費用が掛かったり、導入にかかる費用もパッケージ製品の導入比べて期間が長期化することになりかねません。

    4点目の事例でお伝えしたいのは、パッケージ導入の進め方に則ってPJを進行したものの、PJ進行段階で進め方の認識が社内で統一されておらず、システムに対する要件が導入フェーズになって大量に発生してまったり、かなり細かいレベルの要望が、導入打合せ時や、現場への展開時に山積してしまい、PJ進行が困難になるケースになるという失敗事例となります。

    まとめ

    以上、ご紹介してきた失敗事例から言えることは、PJの成否はPJ開始時点である程度決まっているということです。失敗事例の1点目でご紹介した「導入の目的・ゴールが明確になっているか」という点は導入PJ開始時点で明らかになっているべきです。この点については、PJメンバーが正しく目的を理解していることはもちろん、システム導入の各種フェーズが切り替わるタイミングで関係者に浸透している必要があります。

    失敗事例の2点目は、適切なフェーズで整理されていないことが失敗(PJのスケジュール遅延や費用変動によるPJ頓挫)につながるという話なので、PJ進行中でも、スケジュールを再検討することが許されるのであれば、整理のフェーズを設けたり、導入フェーズと並行して社内の周辺システムとのかみ合わせを考えることでPJのリカバリができる場合があります。

    3点目の失敗事例については、PJメンバーが導入PJに対するリソース投下ができるよう、PJメンバー外からもリソースの調整を行うことで、進捗のリカバリを行うことが可能です。4点目の失敗事例については、結局のところ、1点目でご紹介したシステム導入の目的に応じて現状を整理し、そのタイミングでできる範囲で何を最優先と捉え、判断するのかにより、リカバリできる内容は変わってきます。

    弊社システム「ZAC」の導入では、「お客様にパッケージシステムに寄り添っていただき、システムに自社の業務を合わせる」という考え方で導入を行っていただくことが多く、どうしてもパッケージに合わせていただくことが難しい点や導入フェーズを進めた結果、パッケージのままではシステム導入の目的が達成できないとなるような場合、PJ仕切り直しの場を設けさせていただくような事例もあります。そのような状況にならないためにも、PJ開始前の社内準備が非常に重要です。下記フォームにはPJ開始前に押さえておきたい要点をチェックリスト形式でまとめています。よろしければご活用ください。

    いかがでしたでしょうか。本記事がERP導入を成功させるために参考になりましたら幸いです。

    【現役導入コンサル監修】 ERP導入で失敗しないために知っておきたいチェックリスト

    ERP導入プロジェクトを成功に導くために押さえたい要点をチェックリスト形式で公開。現役ERP導入コンサルタント監修のもと、プロジェクト開始前に明確にしておきたいことを一覧でご紹介しています。

    無料ダウンロード
    • このエントリーをはてなブックマークに追加
    • RSS2.0
    • ATOM
    植山 隆広

    この記事の筆者

    株式会社オロ クラウドソリューション事業部 顧客支援グループ コンサルタント

    植山 隆広

    新卒で株式会社オロに入社後、クラウドソリューション事業部でクラウドERP「ZAC」の導入支援を経験。これまでの導入社数は30社。導入支援チームのマネジメントも行いながらプレイヤーとしても活躍。

    ページ先頭へ戻る