経営の基幹システムであるERP（Enterprise Resources Planning）。
自社の成長や管理に向けた抜本的な解決策としてERP導入を検討されている企業さんは多くいらっしゃるものの、いざ、導入に向けた見積もりや発注を進めるにあたり、実際にどのような流れで「企画」から「導入」までが実施されるのか、ベンダーに言われるがまま進めるというのは不安になりませんか。
そこで今回は、どのような工程でERP導入が進むか、発注企業と開発ベンダーで導入に際してどんなタスクを実行していくか、ERPの導入手順について解説します。
システム開発におけるERP導入の位置づけ、他のシステム開発手法との違い、という視点で見ると理解しやすいと思います。
ERP導入は「業務基幹システム開発」の際のアプローチの1つであり、また業務基幹システム開発は、それ以外も含めた「システム開発」のカテゴリーの1つです。そのため、システム開発→業務基幹システム開発→ERP導入、とそれぞれ元となる方法論を元に、ERPの導入プロセスは確立されてきました。
業務基幹システムについて様々な定義がありますが、ここでは顧客から見えない、企業内で用いられる業務遂行やサービス提供の中核を担うシステム、とイメージしてください。顧客から見えるシステムの例には顧客から見える、販売機会や情報、SNSなどによってリレーションを提供するウェブサイトがあります。その他にもPCやスマートフォン等のデバイスで動作するアプリケーションもシステムの一種、と言えるでしょう。
業務基幹システムの開発方法は、大きくERPを導入する、カスタムメイドする、の２種類に分かれます。カスタムメイドは別名、スクラッチ開発と呼ばれることもあります。ERP導入は、新規にゼロからつくるカスタムメイドのスクラッチ開発と対比して、既に開発されている標準機能やマスタデータ構造を用いることで、導入費用を抑えられたり、スピーディーに開発できたりといったメリットがあります。
ERP導入は、主要なシステム開発手法である「ウォーターフォール・モデル」をベースとしていることが多いです。ウォーターフォール・モデルは、システム開発のプロセスを大まかに分析・設計・実装・テスト・運用という順序に区切って、各工程が終わると次の工程に進むという、まるで川の上流から下流に向けて水が流れていくかのようなイメージから、そう呼ばれています。
ウォーターフォール・モデルがERP導入のプロセスとして採用されている理由として、
といったことが上げられます。
もちろん企業ごと、担当者ごとに業務遂行の手順は個々に違っているでしょう。ただ、自動車業界には自動車業界ならではの、生産部門には生産部門ならではの、人事担当には人事担当の、共通する管理情報があるはずです。
ERPパッケージは、そうした業界、業種、職種に応じてスムーズな業務遂行、情報管理を行っていくために、必要な機能を標準機能がひとまとめになっています。
ERP導入をウォーターフォール・モデルで行う場合のフェーズ、プロセスと成果物、実施者の移り変わりに沿ってまとめると下記のようなV字を作成することができます。本稿ではこれをERP導入プロセスの全体像を表す「ERP導入のV字モデル」と呼びます。
システム開発プロジェクトの構想・企画や対象部門・対象業務などを特定する段階は、発注企業側では情報システム担当、開発ベンダー側ではITコンサルタントといった人たちが担当します。どのERPパッケージを導入するのが適切か、Fit/Gap分析と呼ばれる、自社の業務とERPパッケージの適合度合いについて確認を実施するのもこの段階です。次の段階に進む前に、どのERPパッケージを導入するかを判定します。どのERPパッケージも不適合という場合には、カスタムメイドを検討します。
導入するERPパッケージの選定が終わると、自社業務でERPを使用するための設定についての検討が始まります。この段階は、発注企業側では現場のオペレーションを知っているマネージャー層、開発ベンダー側ではシステムエンジニアが担当します。ERPを使い始めるためのマスタデータの登録・移行作業や、業務で使用している帳票、既存システムのトランザクションデータの移行をどう行うか、詳細を決めていきます。既存の業務・システムをERPパッケージの標準機能がカバーしていない場合には、追加開発やインターフェースのためのシステム設計も行います。インターフェースとは、ERPと既存システムを共存させ、データ連携のためのプログラムを開発し、日次や週次、月次などのサイクルを決めてデータ同期させます。
システム設計が終わるとプログラム開発や実機のチューニング作業を行います。開発は開発ベンダー側のプログラマーが行い、プログラム単体での動作確認も開発ベンダー側で行われることがほとんどです。これらはプログラム開発のために用意した開発環境、テスト環境を使用して行われます。
発注企業側では総合テスト（複数のプログラム群が、設計の通りに動作しているかどうかの確認）を行い、納品物としての承認を行います。別名、受入テストとも呼ばれており、受入確認が取れたプログラムは適切なタイミングで本番環境へと移送されます。開発ベンダー側では、プログラムやデータの移行計画を作成し、本番稼働に備えます。本番稼働開始日は関係者の間では、「カットオーバー」「Go Live（ゴーライブ）」「ローンチ」などと呼ばれています。
プログラム開発や動作確認、データ移行計画と並行して行われる、重要な準備作業が、現場トレーニングです。これまで使用していた操作に慣れているシステムから、新しいシステムに切り替わることで、業務プロセスや操作方法に変更が生じています。新しいシステムに切り替わっても戸惑わないよう、あらかじめ操作マニュアルを作成し、研修などを行うのです。また、現場の業務担当者の中には新しいシステムを使うことへの心理的な抵抗感を持っている人もいることがあるため、なぜ新しいシステムに切り替わるか、ERP導入によってどういった便益がもたらされるか、ERP導入の背景や意義についてもコミュニケーションをとり、理解を求めていくことが重要です。
様々な準備作業を行い、ERPが本番稼働した当初は、想定していなかったシステム障害や、業務の切り替えに伴う現場のトラブルシューティングへの対応が必須となります。特にシステム障害は、売上や費用のロス、対外的な信用といった経営インパクトの大きさから重要度判断を行い、重要度の高いものから優先的に障害回復を行っていきます。週次や月次で発生する業務や動作するプログラムがあることを考慮すると、通常業務が安定運用に入るまでERP稼働から最低でも2ヶ月は見ておく必要があります。
システム障害や現場のトラブルシューティングが落ち着いてきたら、稼働後に発生した新規開発要求や、本番稼働まで間に合わなかった開発要求などについて、追加開発の実施是非などを検討し、実行に移します。同時に、今後の保守運用体制を発注企業側、開発ベンダー側、双方を交えて整備します。
カスタムメイドの開発と異なり、既にひとまとめになっている標準機能やデータ構造を用いることで、開発工数を削減できることがメリットである反面、これまで行っていた業務やシステム操作手順を、ERPの仕様に合わせて変更する必要も発生してきます。ERP導入の際にはBPR（Business Process Re-engineering）の視点を持ち、システム刷新の機会を活かし、プログラム開発のみならず業務への深い理解もあるITコンサルタント、システムエンジニアの助けを借りながら業務改善を考えていくことが重要です。
業務について最も詳しい発注企業側の現場担当者と、開発ベンダー側でしっかりとコミュニケーションを行い、お互いに協力し合う意義が伝わったでしょうか。より良いシステム開発を行いたい、という思いは開発ベンダー側も強く持っているものなので、ぜひ開発ベンダー任せ、言いなりにならずに、希望などリクエスト、思ったことは伝えて頂きたいと思います。