「失敗しないERP導入」を現役導入コンサルが説く【チェックリスト付き】
ERP導入の基礎知識
ERPとは、企業の持つ資源=「ヒト」「モノ」「カネ」「情報」を一か所に集めて管理し、有効活用するという考え方、またはそれを実現するためのシステムを指します。バラバラで管理するより、効率化を図れる点がメリットです。
ERPは企業資源を有効活用するために複数のシステムが統合されたものです。たとえば、人事・給与管理や販売管理、生産管理など、企業にとって主要な機能が統合されています。
ERP導入のフェーズは、大きく分けて4つあります。
- システムの検討や決定といった「導入序盤フェーズ」
- システムの切替準備、社内周知を行う「導入中盤フェーズ」
- システム切替やデータ移行を行う「導入終盤フェーズ」
- システム導入後のサポートを行う「システムカットオーバー」
今回の記事では、導入すべき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メンバーの高負荷によるスケジュール遅延
- ケース4:システム要件に対する社内認識の不一致
ケース1:導入の目的・ゴールが不明瞭
ERPに限らず、システム導入において最も重要な視点として、システム導入をすることで企業として(導入部署として)達成すべき目的・ゴールがあると思います。しかしその目的・ゴールが明確になっておらず、導入後のシステム導入効果を発揮できなかったり、導入中にPJの適切な意思決定ができずPJがとん挫していくケースがあります。
導入の目的・ゴールが明確になっていないと、導入の前のフェーズであれば、適切なパッケージ選定ができなかったり、適切な要件定義ができなかったりとPJの根幹にかかわるような部分での判断が正しくできない事態につながります。また、導入フェーズでは社内のユーザー展開に対して、会社としてどういった目的(メリット)があるかを打ち出せずスムーズなシステム利用につなげられない可能性があります。
1点目の失敗を避けるためにシステム導入の目的・ゴールを具体化することが大切です。例えば
- システムを導入することで帳票加工にかかっている作業工数を◯%削減する
- 月次処理にかかる時間を◯日削減する
などの数値目標です。
こういった目的が明確になっていることで、その目的を達成するための最適なパッケージ選定ができたり、PJ進行中の意思決定を迅速に行うことができます。また明確な目的・ゴールというのは上記のような具体的な数値目標だけに限りません。
筆者が経験したZAC導入PJでは、
「ERPを導入し稼働させることができる=目標達成」という捉え方が多くありました。
- システム導入によって自社の業務をシステムベースの業務フローに沿ったものとして業務標準化を図る
- Excel運用している業務をシステム化し、電子承認機能を利用することで社内の内部統制の強化を図る
といった目標です。
いずれの場合でも、導入の目的・ゴールは導入PJ開始時点で明らかになっているべきです。また、PJメンバーが正しく目的を理解していることはもちろん、システム導入の各種フェーズが切り替わるタイミングで関係者に浸透している必要があります。
導入の目的・ゴールを明確にするには
システム導入の目的・ゴールが明確になっていることのチェックポイントとして下記が重要です。
- 目的・ゴールはシステム導入フェーズでは明確になっている
- 目的・ゴールはシステム導入のどのタイミングで達成できる性質のものか、いつ効果測定ができるのか認識できている
①について、システム導入フェーズの前にはパッケージ選定やシステム要件の整理フェーズがあります。
このタイミングで経営判断を行う立場の方が「システム導入をすることで何を達成したいのか」を打ち出している必要があります。目的・ゴールに見合うシステムを選定し、目的・ゴールをかなえることを検討するための要件定義をするためです。
②について、システム導入後その目的・ゴールが達成されているのか、いないのかを適切に判断ができるタイミングがシステム導入のどのフェーズであるかを意識できるようにしておくことです。導入PJ進行中のメンバーについてもその点を意識できている必要があります。
例えば、システム導入の目的が上記の数値目標ですと、目標が達成でき、その効果測定ができるのはシステムカットオーバー後です。一方で、業務標準化や内部統制の強化といった目標では、システム運用を検討するフェーズ(導入フェーズ)で理論的には目的が達成できること、または達成可能か判断できることになります。もちろん、理論的に検討したシステム運用が、カットオーバー後に運用されなければなりませんので、その運用が行われていることをチェックする必要があります。
強調してお伝えしたいのは、システム導入の目的にもさまざまあり、目的達成のために何に対して力を入れて検討する必要があるのかをPJメンバーが考えられていることが重要だということです。
ケース2:ERPの適用範囲が不明瞭
ERP導入において、そのシステムの適用範囲が大きく、自社の業務を一元管理できることは、システム導入のメリットのひとつとなります。その一方でシステム単体で自社の全業務を管理することはまれです。例えば、弊社システム「ZAC」の場合、財務会計の機能や給与計算の機能は持ち合わせていないため、クライアント側には「ZAC」の他に会計システムや給与計算のためのシステムをご利用いただくことが大半です。
2点目は、「導入しようとしているERPの適用範囲がどこまでなのか」がPJの開始前に整理されていない結果、導入フェーズになって社内の要件が思わぬ方向に逸れていったり、システムの分野とまったく異なる要件に派生していき、結果システム導入の目的を見失うというケースです。
ケース1にも通ずる話ですが、今導入しようとしているシステムが何を管理するためのシステムであるか(何を達成するためのシステムなのか)が整理できておらず、結果として、システム導入の目的・優先度がPJ進行中に当初と変わっていくといった場合があります。
また、「ERPと既存システムの適用範囲・つなぎ合わせの部分」を整理することもポイントです。できれば、システム導入フェーズが始まる段階では、何を管理するためのシステムであるかが可視化できるところまで整理できているとよいでしょう。
これが正しく整理されていないとPJ進行段階で下記のようなことに陥りかねません。
- システム導入フェーズになり、他システムとの適用範囲の棲み分けを検討することになりプロジェクト進捗に影響を及ぼす。
- 導入中に導入範囲外の機能モジュールの追加となり費用・プロジェクト進捗に影響を及ぼす。
特にパッケージのシステムの場合だと導入~カットオーバーまでの期間が短いことがメリットである一方で、機能範囲などは決まった前提でPJスケジュールが組まれているケースが大半です。そのため、システムの適用範囲などを導入フェーズで検討する余裕はなく、カットオーバー時期に影響を与える可能性が高いと言えます。
この事例は、適切なフェーズで整理されていないことが失敗(PJのスケジュール遅延や費用変動によるPJ頓挫)につながるというケースです。したがって、PJ進行中でもスケジュールを再検討することが許されるのであれば、整理のフェーズを設けたり、導入フェーズと並行して社内の周辺システムとのかみ合わせを考えたりすることでPJのリカバリができる場合があります。
上記1、2点目のケースはシステムの導入フェーズに限った失敗というよりは、システム導入の初期検討段階での目標設定やシステムの適用範囲の整理ができていないことが原因で後のフェーズに影響を及ぼすことになる例でした。3点目は導入フェーズでの失敗です。
ケース3:PJメンバーの高負荷によるスケジュール遅延
一般的に、PJメンバーは通常業務があるなかで導入PJにアサインされていることが多いでしょう。(専任でPJメンバーにアサインされているケースは少ないです。)
導入PJでは、パッケージベンダーなどの導入サポートを受けながらPJを進行することが多いものの、自社のPJメンバーも稼働負荷が高い状況となります。この稼働負荷を見越したアサインとなっていないと、PJ進行に対して自社のメンバーが必要なタイミングで必要な作業に時間を割けず、当初想定していた通りにPJスケジュールを進めることができずシステム稼働に影響が出てしまう場合があります。
このようなケースでは、PJメンバーが導入PJに対するリソース投下ができるよう、PJメンバー外からのリソース調整を行うことで、進捗のリカバリを行うことが可能です。
ケース4:システム要件に対する社内認識の不一致
ケース3と同様、導入フェーズでの失敗となります。
ERPの場合、導入フェーズで運用の最終確定を行うことが多いものです。弊社ERP「ZAC」の場合ですと、動作変更・項目名称変更をパラメータ設定として導入フェーズで実施、最終確定するという進め方をとることがあります。逆に言えば、導入フェーズになり、運用を一から検討していくというのはパッケージシステム導入のケースとしては少ないのです。
会社の規模や状況によりますが、導入フェーズになって運用を一から検討していくことが少ない理由は、お客様がERPパッケージに合わせるという考え方でシステム導入を行っていくことが多くなっているからです。個社別の作り込みでないパッケージシステムを導入する場合、システムの基本機能・業務フローが定まっており、パッケージに会社の業務を合わせるという考え方で導入を進めることで、(フルスクラッチのシステム開発に比べて)初期費用を抑えることができたり、属人的となっている業務フローを標準化することにつなげられたりするというメリットがあります。
一方でシステムを業務に合わせる考え方で導入を行う場合、導入フェーズの前に要件定義を行ったり、パッケージ製品に対するプログラム開発を行うことでカスタマイズ開発フェーズが導入フェーズで入ったりすることがあります。こちらは自社の業務に沿ったシステムとなる一方で、初期システム構築作業に追加で費用が掛かるほか、導入にかかる費用もパッケージ製品の導入と比べて期間が長期化することになりかねません。
このケースでお伝えしたいのは、パッケージ導入の進め方に則ってPJを進行したものの、PJ進行段階で進め方の認識が社内で統一されておらず、システムに対する要件が導入フェーズになって大量に発生してまったり、かなり細かいレベルの要望が、導入打合せ時や、現場への展開時に山積してしまい、PJ進行が困難になるという失敗例となります。リカバリの方法は、1点目で紹介したシステム導入の目的に応じて現状を整理し、そのタイミングでできる範囲で何を最優先と判断するのかによって変わってきます。
【まとめ】ERP導入に失敗しないために
以上、ご紹介してきた失敗例から言えることは、PJの成否はPJ開始時点である程度決まっているということです。そして、以下のポイントを押さえて導入を進めることが肝要と言えます。
ベンダーに任せきりにしない
導入を進めているシステムが「何を管理するためか」「何を達成するためか」明確になっていなかったり、目的がPJメンバーに浸透していなかったりすることで、導入PJは失敗しかねません。ベンダーにすべてを任せきりにしていては、導入中だけでなく導入後もうまく運用できないなど問題が発生する可能性があります。ベンダーの協力は得つつも、自社で舵を切っていくことがERP導入成功への鍵となるでしょう。
部門間のコミュニケーションを図る
ケース4のように、導入PJが進行しているにもかかわらず、社内の認識に齟齬があってPJの進行に遅れが生じるケースは多々あります。複数の機能を統合したERPだからこそ、それらの機能を利用する各部門間でコミュニケーションを図り、要望の吸い上げや要件定義の明確化を行うことが大切なのです。
導入後にも見直しを行う
社内で固めた要件をもとにERP導入が完遂できたとしても、そこで終わりではありません。実際に業務上で使ってみて、やりづらさを感じるようであれば見直す必要があります。また、ERP導入によって達成したかった目標が達成できているのかどうかも、定量的に測定してフィードバックを行わなければなりません。
弊社システム「ZAC」では、「お客様にパッケージシステムに寄り添っていただき、システムに自社の業務を合わせる」という考え方で導入を行っていただくことが多いです。しかし、どうしてもパッケージに合わせていただくことが難しい点や導入フェーズを進めた結果、パッケージのままではシステム導入の目的が達成できないとなるような場合、PJ仕切り直しの場を設けさせていただくような事例もあります。そのような状況にならないためにも、PJ開始前の社内準備が非常に重要です。下記フォームにはPJ開始前に押さえておきたい要点をチェックリスト形式でまとめています。よろしければご活用ください。