ERPの運用で失敗しないためには？失敗する原因と対処法、 ERPの導入効果を実現する方法を解説！
時間とコスト、そして労力を費やしてERPを導入しても「結果が出ない」という状況の発生することがあります。
ERPの導入を承認した経営層のかたは、ERPの導入前にどんな結果を期待しておられたのでしょうか。
それは、導入後に実現されていますか?
ERPの導入を苦労して推進された業務部門やIT部門のかたは、導入後のどんな状況を思い描かれていたのでしょうか。
それは、現実になりましたか?
この記事では、導入前の想定と導入後の結果との乖離のいくつかの具体例を挙げ、その原因と対処法について提案いたします。
目次
1. ERP導入前のプロセスで業務が進められている（経営/業務部門の側面）
1.1 BPRが定着せず、いつの間にか元に戻っている業務プロセスがある
ERPの導入に際しては、多くの場合BPR（Business Process Re-Engineering）が行われます。ERP導入とBPRは不可分とも言えますし、BPRの実施とERPの導入の両方を行って、初めて効果が現れるとも言えます。ERP導入と並行して行われるBPRは、とても多くの時間と業務経験と業務担当者の知恵が必要です。
一方、労力をかけたBPRなのに、ERPを運用している間にいつの間にか導入前の業務プロセスに戻っているという現象の発生することがあります。そして、せっかく作った新業務フロー図も役に立たなくなってしまっているのです。
どうしてこんなことが起こるのでしょうか。原因は、大きく分けて２つあります。
1つ目は「BPRの内容が業務メンバーに腹落ちしていない」ことです。そしてこれが、新業務プロセスの定着しない最大の原因となります。
慣れ親しんだ業務プロセスを変えることは、業務部門に一時的な作業負荷、精神的負荷をもたらします。これを防ぐためにはERP導入時に業務部門が積極的に関与し、BPRを主体的に進めることが重要です。業務部門の納得感がないままERP導入、BPR実施が進んでしまうと「やらされ感」だけが残り、IT部門や外部業者をスケープゴートにした被害者意識を生むことになります。
業務部門が積極的に関与するための方法として「キーユーザ」を作るという方法があります。各業務プロセスのアドボケーター（考えを主導する人）である「キーユーザ」を決めて、その人を中心にしてBPRに臨み、ERP導入後の運用フェーズにおいても、その人が新業務プロセスを守る役割を果たします。なお、この「キーユーザ」は年長者や役職者とは限らず、プロセスの中核となる人という基準で選ぶと組織の成長にもつなげることができるのではないでしょうか。
BPRが定着しない原因の2つ目は「アドオン開発」です。
「ERPの標準機能だけでは業務がまわらない。でも、どうしてもBPRにはそぐわない」という場合には、アドオン開発を行うことになります。アドオンと呼ばれる自社向けの追加プログラムはERP本体のバージョンアップ時や他システムとのインターフェース変更時の対応時に時間とコストがかかり、障害の原因になる可能性も高いため、積極的にはお勧めできませんが、自社独自のビジネスプロセスを残さなければいけない場合のひとつの手段となります。
しかし、アドオン開発の要件定義を行う際に「旧業務プロセス」をベースにしてしまうと、新旧の業務プロセスが混在することになり、慣れ親しんだ業務のやり方に傾いて行ってしまうのです。また、アドオン開発までには至らなくても、ERPから離れたところで隠れた業務プロセスが進んでいる場合があります。例として「ERPに入力するためのデータをExcelで準備する」というようなケースです。
無理なBPRや無計画なアドオン開発がBPRの定着を妨げることになるのですが、事前の防止策、事後の改善策とも「業務部門が腹落ちするまで、業務部門が主体となって新業務プロセスについて話し合う」ことがポイントになります。
BPRについて更に詳しく知りたい方は下記記事をご覧ください。
1.2 経営判断に必要なデータがすぐに出てこない
「ERPを導入するとビジネスの透明性が確保され、データの精度も高まるので、意思決定のためのデータがリアルタイムに手に入ると聞いていたのに、以前と変わらずに『データの準備に時間がかかる』と言われてしまう」という経営層からの苦言を聞くことがあります。
前項では業務プロセスにフォーカスしましたが、このケースの場合はシステムのアウトプットに着目する必要があります。一概には言えませんが、ERPを導入する際に、プロセスや入力部分は多くの時間をかけて検討するものの、経営層が必要とする出力部分の検討にかける時間が少ないというケースが見受けられます。
通常業務に必要な帳票類については、プロセスの一部として議論の対象となるのですが、経営に近い業務としてのシミュレーションや意思決定に必要なデータの抽出についての検討が手薄になってしまうのです。
この問題への対応として「データベースを開放するのでEUC（End User Computing）でユーザー自身がデータを抽出して利用する」というコンセプトが導入されることがあります。しかし、「ERPと周辺システムのマスタデータの不整合」「それぞれのデータの意味を定義するためのデータ辞書が不十分」「ユーザーのトレーニング不足」などの課題が立ちはだかります。
これらの課題への対応も、やはり事前協議が重要だと言えます。
経営層のかたのデータに関する要望は多岐にわたりますので「優先順位をヒアリングする」という姿勢も大切ですし、それをもとに、導入するERPと親和性の高いビジネスインテリジェンス（BI）システムを導入するという方法も考えられます。
課題の一つである「ERPと周辺システムのマスタデータの不整合」については、マスタデータ基盤の検討・整備が必要となります。
2. 運用に想定以上の手間とコストがかかる（業務/IT部門の側面）
2.1 IT部門の予想外の負担
ERPの導入が無事完了すると「運用フェーズ」が始まります。この運用フェーズには意外と手間とコストがかかるものです。通常運用として順調に稼働している場合には問題なく、手間もコストも予想通りなのですが、以下の状況が発生すると一気に手間とコストがかかるようになります。
ERPのバージョンアップの際のアドオンや周辺システムの対応
ERPはユーザー企業からの要請や法対応のための機能追加/変更のために、バージョンアップが行われます。先の項でもふれたように、この時、ERPと連動しているアドオンプログラムはそれに対応しなければいけません。また、その前には「対応する必要があるのか」という技術的な判断も必要です。そして、実は、これに多くの手間がかかるのです。自社のIT部門だけで対応できない場合は外注コストも発生します。
この問題への対応としては、ERP導入前後の区別なく「アドオン開発をむやみに増やさないこと」に尽きます。許容範囲であるならば「アドオン開発ではなく業務プロセスの変更で対応」が望ましいと言えます。ただし、これは、先に述べた「無理やりのBPRを行わないこと」と矛盾します。あくまで、バランス感覚が必要であり、そのためのディスカッションが必要だということになります。
ERPシステムと外部システムとのインターフェースの不具合
外部インターフェースを利用してERPと周辺システムをつなぐ方法がありますが、情報システムはそのコンポーネントが多くなればなるほど複雑になり、障害の発生する確率が高まります。そして、一旦障害が発生すると、障害の切り分け、原因の特定、原因の除去に手間がかかりますし、インターフェースのどちら側が責任を持つかという不毛な議論が生まれることにもなります。
なお、この2つの状況に対応する方法として「ポストモダンERP」という考えが提唱されています。これは、「カバーする業務領域を絞ったシンプルなERPを構築し、ERPで不足する機能をSaaSなどのクラウドサービスを連携させて実現する、次世代型のERP」を意味します。
「ポストモダンERP」については、下記記事で詳しく説明しています。
2.2 業務部門の予想外の負担
IT部門だけではなく、ERPの運用フェーズでは、業務部門にも以下のような予想外の負担がかかることがあります。
例外処理対応
BPRを通じて定義した新業務プロセスでは対応できない例外的なビジネスケースが発生した場合、どのようにERPにデータを入力すればいいかは未知の世界となります。そのERPに習熟した社員や外部ベンダーとのコミュニケーションチャンネルを確保しておくことは必須要件です。
マスタデータの整合性の確保
ERPを導入することで部門内、部門間のマスタデータの整合性が取れるようになります。しかし、各部門で共有するようなマスタの場合、入力内容の定義や入力タイミングなど、部門間の調整が必要です。
たとえば、メーカーでの製品マスタの場合、生産部門、営業部門、経理部門、調達部門、物流部門など、全ての部署に影響が及びます。マスタ登録業務も新業務の1種であることは忘れないようにしたいものです。
上記の問題は、システム設計時に十分なIT共通基盤を整備できなかった場合に発生します。ERPを選定する段階で、既存の基盤状況から、導入時に整備する必要がある部分を検討する必要があります。
3. 全体統合のためのCABの考え方
ERPを運用する際に、選定時から状況が変化するなどによって、システム変更や業務変更が発生する場合があります。このときに部門間コミュニケーションの仕組みとして、「CAB（Change Advisory Board 変更諮問委員会）」を設置することも有効です。
CABはITIL（Information Technology Infrastructure Library ITサービスの方法論を体系的にまとめた書籍群）が提唱している考え方です。CABの役割は「変更案件が発生した時に、影響やリスクについて話し合うこと」ですが、ERPの運用については、システムの変更だけではなく、業務プロセスの変更についてもテーマにすることができます。
ある部門が「どうしてもｘｘ業務プロセスを変更しないといけない」というアイデアを提出すると、各業務部門の代表者が自身の所属部署の立場でその影響を分析し、リスクを確認し、変更の是非を協議するという仕組みです。
そして、変更案件以外にも、課題が発生した場合には、協力して解決にあたるというメリットがあります。
なお、ERP向けのCABは、IT部門と各業務部門の代表で構成されることになりますが、前述した「キーユーザ」が部門代表を兼任するのも良い方法です。
4. 最後に
この記事では、ERP導入後の「こんなはずじゃなかった」を防ぐ方法について提案させていただきました。
ただ、事後の対応よりは事前の対策が有効なことは言うまでもありません。
その意味では、導入前の「導入目的の明確化」「体制の確立」「業務部門の主体的な関与」が重要です。
システムは、導入すれば成功というものではありません。導入後の運用で活用し、メリットを享受して、初めて成功だと言えます。そのためには、ERPが業務を連携させるように、各業務部門/IT部門が組織として連携してERPの導入/運用を進めていただければと思います。
もし、ERP系業務パッケージシステム投資を進めたいが、ノウハウや経験を持ったメンバーが社内におらず、投資リスクが大きすぎるため意志決定に踏み切れないという方、GPTechでは、システムの発注者であるお客様が、主体的かつ適切にパッケージシステムを調達できるように支援を行っています。
お気軽にお問い合わせください。
この記事の編集者
武田 祥太郎
大学時代法学部で労働基準法の研究を進める中で日本の労働生産に課題を感じ、ITによる企業体質の健全化を目指して（株）グローバル・パートナーズ・テクノロジーに新卒入社。 民間企業のITガバナンス、マネジメント支援業務に従事し、同社のナレッジ活用知見を活かしてIT調達ナビで記事の展開にも携わる。
