みなさん、おはようございます！タカハシ(@ntakahashi0505)です。
こちらの記事は、タカハシが音声メディアVoicyの「スキルアップラジオ」にて放送した内容から、ピックアップしてお届けします！
今回のテーマは、今さら聞いてもいいIT用語 #22: 「ERP」です。
なお、以下で実際にお聴きいただくこともできます！
では、よろしくお願いいたします！
今さら聞いてもいいIT用語「ERP」
今日は、今さら聞いてもいいIT用語シリーズ第22回をお送りしていきます。
このシリーズは、今さら人に聞けない、でも知っておいた方が良い気がする、そんなIT用語を耳からこっそり学べるシリーズとなっています。
今日紹介するキーワードは「ERP」になります。
4月に発生した江崎グリコのシステム障害で、プッチンプリンが出荷できなくなっちゃったニュースもあったんですが、それに関しても少し触れていきたいと思っています。
ERPとは
ERPはEnterprise Resources Planningの略で、直訳すると「企業資源計画」となります。
企業が持つ資源、リソースには人・物・金などがありますが、それがいつ、どれだけ、どこにあるかというのを可視化し、効率よく使おうという考え方のことをEnterprise Resources Planning、企業資源計画と呼んでいます。
なので、元々「ERP」というのは経営の考え方を表す単語だったんです。
そして、企業の人・物・金といった資源を可視化する際に便利なのがデータということになります。
データを一元的に集めてそれを可視化できるようにする、そのためにはシステムが必要です。
これをERPシステムというんですが、最近では、このERPシステム自身を、単純にERPと呼ぶようになってきているということです。
ERP未導入の状態
わかりやすさのために、もう少しERPどうといったものか解説していきます。
ERPを導入する前の話しとして、経理のシステムとか販売管理のシステムとか、工程管理のシステムとか、企業活動をする上で必要なシステムを部門ごとに導入しているとします。そうするとどうなるか。
たとえば、営業部門では売り上げ管理システムを使っています。
ある営業さんが一定の商品を販売しました。すると、営業部門では売上げを売上げ管理システムに入力します。
ただ、この情報は経理部門や製造部門にも渡す必要があります。というのも、経理部門では経理システムにその売り上げ情報を入力する必要があるからです。
また、製造部門の方では、工程管理システムの方にその売れた数を入力する必要がありますよね。そして、在庫を減らします。
在庫が減ったのであれば、それはまた経理部門もその情報が欲しいわけです。
混在するシステムの弊害
このように、個別の部門でそれぞれのシステムを使っていると、それぞれに入力が必要になりますし、お互いで共通するようなデータの受け渡しが必要になります。
何度も同じデータを入力する手間があちこちでかかっており、そしてそのデータの受け渡しに場合によってはタイムラグが発生するわけです。
なので、1ヶ月に1度しか経営の重要指標がまとまらない、といったことが起きてしまうわけです。
ちなみに、今のような話は、小規模事業者の場合は個別のExcelとかでやっていることが少なくないんじゃないかと思います。
つまり、このようにバラバラになっているシステムとシステム上にあるデータを一元管理しよう、ひっくるめてまとめておいて可視化や効率よく使えるようにしよう、というシステムがERPということになります。
ERP導入のパターン
さて、このERPなんですが、どうやって作るかでいうと、大きく2つのパターンがあります。
ERPパッケージの導入
1つはERPパッケージと呼ばれるものを導入するものです。
これは、多くの企業が必要とするであろう機能があらかじめパッケージングされたERPになります。
つまり、あり物をそのままパッケージとして買ってくるイメージです。
あり物を買ってくるわけですから導入コストが安くて済み、導入期間が短くて済む、などのメリットがあります。
また、多くの企業が同じパッケージを利用しているので、安定したシステムを期待することができますし、みんなが欲しいと思っている機能が順次アップデートされる、そういったことも期待することができます。
フルスクラッチで開発
一方で、もう1つの作り方がフルスクラッチと呼ばれるものです。
これは、0から全てを作る受託開発型のERPになります。
こちらは、コストや開発期間、安定性、アップデートなどの面で言うとERPパッケージに劣るんですが、その最大のメリットは自社独自のシステムを自由に作ることができるということです。
みなさんの会社では、このERP実現するためにはどちらの方法が望ましいと思いますか。ちょっと一緒に考えてみていただければと思います。
江崎グリコのシステム障害の例
参考に、4月に起きたプッチンプリンで有名な江崎グリコがシステム障害を起こしたニュースを紹介したいと思います。
江崎グリコはERPを4年がかりで構築しました。4月3日にそのERPの全面的な移行を実施したんですが、その際に、切り替えに伴うシステム障害が発生してしまいました。
その結果、全国の物流センターで出荷業務に停滞が生じてしまったんです。
そして、プッチンプリンをはじめとする同社の製品と、同社が物流販売を請け負っていた他社チルド食品の出荷ができなくなりました。
そして、正常な出荷再開までは少なくとも2か月かかると報じられています。
ERPの導入でかなりの損害が出てしまったわけです。
この時、江崎グリコが導入しようとしていたのが、ドイツの大手ERPパッケージメーカー、SAPのERPでした。
元々完成品であるはずのERPパッケージなのに、導入でなぜこれほどまで失敗をしてしまったのか、不思議に思わないでしょうか。
カスタマイズの弊害
実は、SAPに限らず、ERPパッケージの導入でこのような障害が発生してしまうということは少なくないようなんです。
というのも、本来のERPパッケージが求める業務プロセスがこれまでの自社の業務プロセスに合わない時、自社の業務プロセスの方を優先してしまおうという力学が働きやすいということなんです。
その場合どうするかというと、その合わない部分についてアドオンと呼ばれる追加開発やシステムのカスタマイズを施すということをします。
その結果、稼働後にその追加開発部分に障害が発生したり、もしくはERPパッケージ本体とのデータ整合性が取れなくなりシステム障害が発生したり、といったことが起きてしまうということなんです。
安易なカスタマイズの前に
これに関して、SAPのCEO、クリスチャン・クライン氏はこのように述べています。
変化への抵抗は、複雑な業務プロセスを生み出し、その結果、アップグレードに高額な費用のかかるERPを生み出す。
SAPで言うと、大手ERPパッケージメーカーとして、随時良いアップデートをしていきたいということを考えているわけです。
最近で言うと、AI機能の導入など、そういったことが期待できるわけです。
しかし、変化を嫌い、独自で追加開発をしてしまうと、そういったアップデートの恩恵を受けづらくなり、さらにコストもかかるようになるので、極力やめてほしい。
そういったことを訴えているわけです。
つまり、ERPは導入したい、安くて済ませたい、でも今の業務を変えたくない、そういったうまい話はないということなんです。
ERPパッケージに合わせると、これまで現場で研ぎ澄まされてきた自社の強みをスポイルしてしまうかもしれない。
しかし、かといって容易にアドオン対応にすると、アップデートの遅さやコスト増、システム障害のリスクが増すということなんです。
自社として何を優先するのかを徹底的に突き詰める必要があって、それを元にERP導入を検討していく必要があるということなんです。
まとめ
ということで、今日はVoicy「スキルアップラジオ」の放送から「今さら聞いてもいいIT用語 #22: ERP」をお届けしました。
タカハシのVoicyの放送はこちらからお聴きいただけます。
チャンネルのフォロー、コメント、SNSでのシェアなどなど、楽しみにお待ちしております。
では、また。
