ERPパッケージによるシステム導入のポイント
ERPシステム導入成功の鍵は？
ERPの導入は、システム検討から含めると数年にわたって続く、長いプロジェクトです。システム導入を成功に導く鍵について、当社パッケージ製品をご採用いただいた先人の皆様の取り組みから、まとめました。本ページでは、ERP導入に係る取り組みのポイントを解説しています。
ERPシステム導入の進め方（簡易チャート）
システム検討を始める方への冒頭で、「IT投資は経営課題を解決する手段の一つである」とお伝えしているとおり、ERPシステムの導入においても、「業務プロセスの効率化」、「収益強化」、「品質管理体制の強化」など、解決すべき課題や目標を明確にした上で、システム化の企画を進めていくことになります。以下の図は、ERPパッケージをベースにした基幹業務システム構築の手順です。1～数年にわたる長い期間を大きなPDCAサイクルで表しています。これらのステップに沿って、取り組みの流れをご紹介します。
ステップごとのポイント解説
ここから、PDCAの流れにそって、１～10まで各ステップについてのポイントを解説します。
Plan：計画・目的
１．業務の整理と課題抽出
2．システム化方針の決定
何のためにシステムを導入するのかその目的と狙いを定め明文化します。システム選定はもとより、その先1～2年におよぶ長いシステム導入プロジェクトでは意思決定を迫られる局面があります。その際、このシステム化方針に立ち返り、判断します。
Do：実行
３．ベンダーの選定
自社の業務課題を解消できるパッケージ製品を選定します。複数のベンダーに提案依頼を出し、各社からの提案を評価する際、共通の「ものさし」が不可欠です。評価基準を設けることで、提案を客観的に評価できます。
また、ベンダー各社からの提案を比較検討しやすくするために、可能な限り定量的な評価を行いましょう。段階評価や数値化が難しい印象や感触については、記述式を併用します。同時に、自社が重視する評価項目や、異なる組織の人数構成比に対して、重み付けして集計します。これにより、バランスのとれた比較が可能となります。
こうした方法により、選定プロセスが透明かつ公正であることが保たれ、選定メンバーが納得のいく形で、より信頼性の高い選定結果へと導くことができます。
４．事前検証・評価
自社への適合性を確認し、システム導入後の適応イメージをより明確にするための、事前検証・評価手法を２つご紹介します。当社パッケージ製品をご利用のお客様の中にも、プロジェクト開始前にこれらの手法を取り入れて導入を進めていくことがあります。パッケージ製品をベースとしたシステム導入に対し、もし懸念や不安があれば、それらを解決するために検討してみるとよいでしょう。
◆PoC（Proof of Concept：実証検証）
主要な業務の流れにそって、パッケージの使い方を実際に見てみます。パッケージの基本機能を確認して、自社に合っているかどうかを評価します。PoCを通じて、システム導入前のリスクを減らし、投資の意味を明確にします。
◆CRP（Conference Room Pilot：会議室パイロット）
ユーザーが実際にパッケージを操作して、模擬的な業務を疑似体験します。ユーザーがパッケージの基本機能を理解しやすくなり、懸念や不安を低減できます。
５．計画・要員確保
プロジェクトは ひとです。
基幹業務システムは、複数の業務組織で広く利用されます。新しいシステムの導入に際しては、経営陣や各業務の意思決定者の積極的な参加が欠かせません。プロジェクトの様々な段階で意思決定が必要とされますので、積極的な参画を奨励しましょう。こうした協力により、利用部門が主体的にプロジェクトに関与することで、新しいシステムや業務の浸透が促進されます。
導入後のシステムは、将来的に5年や10年にわたって利用されます。今までの経験を有するメンバーだけでなく、将来を担う新たな人材もプロジェクトに参加させることで、プロジェクトを通じてスキルの育成や成長の機会を提供できます。このアプローチにより、豊富な経験と新しいアイデアや視点が交わります。このような相互作用が、プロジェクトをひとつの組織として成長させ、長期的な成功に繋がります。
［チェックポイント］
要員確保の方針を決めていますか？
意思決定者が参画していますか？
利用部門（現場）の責任者が参画していますか？
参加者に期待する役割を伝えていますか？
６．要件定義
要件定義における意思決定・方針決定する際に必要なパッケージ製品の知識習得とスキル習熟に必要な期間を確保するようにしましょう。アミックでは、座学中心の学習ではなく、疑似運用を取り入れて、システム理解の浸透を図っています。実際に触れて使ってみることで、業務システムに対する理解が深まっていきます。疑似運用では、自らがマスタを登録し、一連の業務の流れに沿った作業を体験します。擬似的な業務運用を通して、実践的な理解を深め、学習効果を促進します。これにより、要件定義の質と精度を高めます。パッケージ学習を経て、プロジェクトメンバーのパッケージ製品に対する一定の理解が得られた段階で、要件定義書の策定へと進めます。
７．設計・開発・テスト
設計フェーズでは、策定した要件定義に基づき、開発を伴う追加機能の設計を行います。また、策定した要件定義（非機能要件）に基づき、必要なマスタ、セキュリティ、データ移行、 サーバー構成やネットワーク構成などの環境面を含めた設計を行います。開発フェーズでは、基本設計書に基づいて、詳細設計、プログラム開発を進めます。
テストフェーズでは、サーバー環境等の準備が整った後、現地（お客様サイト）で、周辺システムとの連携などの結合テストを実施します。
これらの設計・開発を進める間、お客様（ユーザー企業）は、並行して、自社の業務運用の見直しを進めます。前フェーズで確定したシステムの要件定義に基づき、自社の新たな業務運用手順の見直し、業務マニュアル改定などを行います。また、次フェーズ以降で実施するテストや移行に向けて、新しいシステムに必要なマスタデータの準備を進めます。
Check：目的達成確認
システム導入という実行計画に対し、目標達成確認のフェーズへの進みます。以下の図は、上図のプロジェクト部分（６要件定義～８検証・本番移行）をWモデルで表現した図を以下に示します。これは、一般的なVモデルに対し、品質管理プロセスを各フェーズに配置したものです。ERPパッケージ製品をベースで進める基幹業務システムの導入プロジェクトでは、大きなPDCAサイクルの中で、小さなPDCAサイクルを繰り返します。上流工程から品質を作り込むことで後工程での手戻りを低減し、プロジェクト品質向上に繋げます。本モデルの右端では、左端にある当初策定した業務要求に対する評価を行います。
８．検証・本番移行
また、この期間は、ユーザー向けのキーパーソン教育（トレーニング）を実施し、新システムの習熟度を高める期間でもあります。本稼働後に、安定的に新システムが定着するように、テストとトレーニングを重ねます。検証の結果、本番移行の判定合意がなされた段階で、移行へと進めます。事前のシナリオに基づき、お客様と連携・協力して、移行作業を実施します。
９．効果測定と振り返り
プロジェクトの目標に対して、達成状況を評価できるように、ものさしをプロジェクトの最初の段階で決めておくことが重要です。プロジェクトの開始時点で計測しておいたものと比較して、当初の狙いどおりに改善が図られたのか評価します。基幹業務システムは、多くの組織・業務に跨って利用されます。事前の計測や評価指標の基準についても、組織単位・業務単位で効果測定ができるように、検討しておくと良いでしょう。
また、運用開始後のユーザーの声を吸い上げ、定性的な評価分析も重要です。これらの情報は、業務の見直しやシステムに対する改善に繋がるための重要なインプットとなります。ただし、システムが切り替わった直後は、まだ新しい業務への不慣れな場面もあるため、利用者からマイナスの声が挙がることもあります。そうした声にも丁寧に耳を傾けてみましょう。新しいシステムの安定的な運用状況を評価するためには、一定程度の期間を経た段階で再評価してみるのも一つの方法です。
Action：更なる改善
１０．システムの改善検討
また、プロジェクトの予算や期間などにより、優先順位や重要度の観点から、見送られた要望があります。これらについても、あらためて再評価した上で、二次的に追加対応することも検討します。
また、基幹業務システムは、将来的に５年や１０年にわたって利用されます。これから先は、さまざまな外部環境や組織の変化への対応が求められます。そのためには、システムに対する継続的な改善が不可欠です。
製品のご案内
アミックのパッケージ製品をご紹介しています。
事例を見る
お客様の導入事例をご紹介しています。システムの検討～構築～活用に関する成功事例を皆様のご検討にお役立てください。
セミナーに
申し込む
ERPやMESの導入を検討している方に、取り組みのポイントをご紹介しています。