本当にそれでいいのか? ERP導入の進め方 システム導入編(2)

今回は、「ERP導入の進め方」における「システム導入」をテーマにしたいと思います。システム導入のなかでも、要件定義とカスタマイズについて事例を交えて紹介いたします。

要件定義

要件定義では一般的に下記のタスク(工程)があります。

作業タスク作業内容成果物
FIT&GAP要件整理追加業務検討事項を検討する実現方針書(更新版)
FIT&GAPプロトタイプ作成シナリオに沿って、パラメータ設定を実施し、代表製品でのプロトタイプを構築するプロトタイプシナリオ(更新版)
FIT&GAP新業務フローに沿ってプロトタイプでオペレーションを行い、業務要件の適合性を確認する新システムフロー
実現方針書(更新版)
不適合箇所を明確化し、その原因・対応策を検討する
不適合原因及びその対応策に基づき新業務フローとプロトタイプの見直しを実施する
修正した内容を基に業務要件との整合性を再確認し、対応方針を確定する
主要マスタ設定主要なマスタ(品目・BOM・品目工程・場所・取引先 など)の方針を検討する実現方針書(マスタ方針)
マスタ移行データシート
アドオン・カスタマイズ要件アドオン対象機能の洗い出しを実施し、アドオン方針案を作成するアドオン要件書
アドオン機能一覧
アドオン見積
各アドオン要件の検討を行い、方針を決定する
インターフェース要件インターフェース対象データの洗い出しを実施するインターフェース要件書
インターフェース方法、インターフェースタイミングを検討する
各インターフェース要件の検討を行い方針を決定する
  • FIT&GAPの手順

    FIT&GAPは、森を見る(ERPの適用範囲を決める)、木を見る(プロセスフローを作成する)、枝葉を見る(画面・項目を確認する)の順で進めます。
    最初から画面や項目を見てFIT&GAPを行うと、ERP固有のプロセスが考慮されず、現行システムの画面や項目との比較に終始してしまいがちです。これでは、あるべき姿を忘れて現状踏襲のシステムになってしまうでしょう。

    森を見る(ERPの適用範囲を決める)工程では、すべての業務要件を単一のERPでカバーするのではなく、複数のパッケージを組み合わせて考える方が、低コスト・低リスクで良い結果になることが多いです。
    例えば、輸出入の手続きはERPを利用するよりも専用パッケージを用いた方が使い勝手がよく、ERPのカスタマイズも少なく済みます。また、ワークフローの場合も専用パッケージを利用すれば全社で一元管理できるという利点があります。ただし、インターフェイスの開発工数が多く高価になってしまう場合があるので注意が必要です。したがって、複数のパッケージを組み合わせる場合、ERP連携が容易か、もしくはそうした事例があるかどうかに留意するべきでしょう。

    木を見る(プロセスフローを作成する)工程について説明します。どのようなERPでも、導入すれば従来のシステムとは業務プロセスが変わるので、画面などを詳細に見る前に、プロセスフローのレベルでFIT&GAPを行う必要があります。
    とくに、現状の組織と業務分担がERPのプロセスに適合しているか否かのチェックが重要です。例えば、計画主導型の生産を志向する場合、計画立案の業務は増えますが、反対にその後の作業が減少して工場全体の効率が上がります。このような場合は、計画部門に人員をシフトする必要があります。

  • 主要マスタの設定について

    スクラッチシステムをERPに変える時に注意が必要な点が、マスタのメンテナンスです。スクラッチシステムではマスタの主管部門が1部門であることが多いですが、ERPでは1つのマスタでも項目ごとに担当する部門が異なる場合も多くあります。
    このため、マスタの登録/更新のタイミングや方法、業務ルールを関係する部門間で検討しておく必要があります。

  • 主要マスタの理解

    ERPを導入すると、従来のシステムとはマスタの構造が大きく変わることがあります。新旧のマスタを比較することで機能の理解を深めるのが良いでしょう。

    • マスタ登録/更新や受注・発注の承認のマスタの取り扱い
    • 得意先に関する情報(納品先、売掛先、請求先、与信管理など)のマスタでの取り扱い
    • EBOMとMBOMの構造上の相違点の取り扱い
    • 製番管理での先行手配、さみだれ手配の取り扱い
    • 外注の渡り歩きがある場合の、BOMや工程マスタでの取り扱い

カスタマイズ

FIT&GAPの結果を踏まえカスタマイズ方針を決定します。カスタマイズ(またはアドオン)はなるべく控えるのが基本ですが、企業の競争力を維持するのに必要な場合、得意先との取引慣行のため従来の手順を維持しなければならない場合など、カスタマイズが必要なこともあります。

カスタマイズ要否の基準例
カスタマイズ対象判定ステップ(イメージ)
  • 新業務要件を破棄できるか?

    その業務がなぜ必要か、業務をなくした場合にどの部門にどのような影響があるかを検討します。
    例えば、発注した部材に欠品が多いため欠品管理に必要な帳票を作成しているケース、もしくは欠品シミュレーションなどを業務要件としているケースでは、欠品自体がなくなれば当該業務は必要なくなります。つまり、欠品をなくすためにはどうしたら良いかを検討する、ないしは、欠品をなくした他社事例を参考に業務改革を行うべきでしょう。

  • パッケージに業務を合わせられるか?

    新業務要件が必要でパッケージにその機能が用意されている場合は、パッケージの標準機能を活用できるよう業務プロセスを変更します。
    例えば、承認業務をERPで行う場合、承認後の申請内容変更には制限が掛かっています。場合によっては承認を取り消した後に変更を行い、再度、承認申請する必要があります。スクラッチシステムでは、承認後の変更を厳密に制限していないケースもありますが、ERPの導入に合わせて正しい業務手続きを定めましょう。

  • 他のシステムで実現できるか?

    一般に帳票は数百種類あることが多く、これらをすべて1つのERPで実現するには多くのカスタマイズが必要となり、現実的な方法ではないでしょう。ERPの導入を機にペーパーレスを志向して、同じ業務要件であればERPの画面上で処理する、または画面からExcelの帳票をダウンロードして、必要な帳票に加工する方法もあります。

  • カスタマイズの優先順位は?

    必須カスタマイズであっても、人手での代替案が考えられる場合は2次開発分として繰り延べる方が良いでしょう。
    過去には、1次開発したシステムを運用するなかで、2次開発分として積み残したカスタマイズが約8割も不要と判断された事例もあります。これは、ユーザーのカスタマイズ要求が、従来のシステムによる業務運営を前提にしていることが原因だと思われます。

いかがでしたでしょうか?

次回は「システム導入編」マスタ、データ移行、テストついて説明します。