皆さん、こんにちは。
本ブログは行動経済学を実際のビジネスに適用していくことを主目的としています。
行動経済学の理論を中心に、認知心理学や社会心理学などの要素も交え、ビジネスの様々なシーンやプロセス、フレームワークに適用し、実践に役立てていきたいと思っています。
はじめに
今回はシステムトラブル(システム障害)と行動経済学の関係について書いていきたいと思います。
システムトラブルと言っても、様々な種類、要因がありますが、今回は江崎グリコで発生しているシステムトラブルを題材にします。
江崎グリコのシステムトラブルとは？
最近、日本経済新聞をはじめ、様々なサイトで記事化されているので、見たことがある方も多いと思いますが、江崎グリコで発生したシステムトラブルについて改めて振り返ってみたいと思います。
同記事では今年の4月3日に出荷管理に使うシステムを新しいものに切り替える際にトラブルが発生してしまい、物流センターの一部業務が停止し、乳飲料や洋生菓子など冷蔵品の出荷を一時停止するまでに発展してしまったとあります。
当初は5月中旬を再開のめどにしていたのですが、6月中に延期され、一部の飲料については6/25に出荷再開され始めたようですが、同社の看板商品ともいえる「プッチンプリン」に関しては、出荷再開は「明示できない」となっています。
また、同記事では今回のシステムトラブルに端を発した出荷停止によって、2024年度の営業利益で60億円、売上高に至っては200億円下押しすると試算されていたのですが、再度の延期によって損失額はさらに膨らむことになりそうとあります。
今回のシステムトラブルは、出荷管理に使うシステムを新しいものに切り替える、つまりソフトウェアのアップグレードが原因となるのですが、具体的には「SAP S／4HANA」をベースにした新システムへの切り替えに伴い発生してしまったようです。
今回の出荷停止によって、スーパーなどでの江崎グリコ製品の棚割り・陳列にも影響が出ているようで、出荷再開されても出荷停止前の状態に戻らない可能性まで言及されています。
同記事では、当然ながらその新システムへの切り替えを主導したベンダの責任にも言及されています。
「プロジェクトの主幹ベンダであるデロイト トーマツ コンサルティングのプロジェクトマネジメント能力に懐疑的な見方も広まっている。プロジェクトが終了した段階で、グリコが一連の損失についてデロイトに損害賠償を求めることになるのでは」（大手SIer社員）
確かに、業務として請負い、契約を締結した新システムへの切り替えを遂行できず、挙句、製品の出荷停止という業務に多大な影響、損失を与えてしまった責任はデロイトトーマツコンサルティング及び新システムへの切り替えプロジェクトに参画したシステムベンダーには大きな責任があります。
ただ、以下の記事でも言及されているのですが、長年IT・ソフトウエア業界に携わってきた立場として感じるのは、ユーザー側の利用方法にも問題があるということです。
ERP導入を巡る最大の誤解は、「パッケージソフトの合わない部分は、アドオン（追加開発）ソフトを開発し、自社の業務に合わせればいい」という考えを多くの人が持っている点だ。
(中略)
無理やり自社の業務に合わせるために、アドオンソフトを開発した結果、ERPが標準で持つ業務プロセスやデータと整合性が採れなくなり、稼働後にシステム障害が発生する。
この記事を見た時に、「IT業界あるあるの典型的なシステム障害」だな、というのを率直に感じたのですが、ERPに限らず、ITシステムを導入する際、特に日本ではほとんどの企業は「自社の業務にあわせる」ためにアドオン(追加開発もしくはカスタマイズ)を行います。
SAPなど一般的なIT製品は顧客が個々にカスタマイズすることは前提としていないので、今回のように新システムに切り替える、すなわちアップグレードする際にカスタマイズされた部分の正常動作までは保証しません。
そうすると、今回のデロイトのようにシステム導入、構築をするベンダが責任を負うことになるのですが、対象製品のことを熟知していても、そのカスタマイズした部分がどこまでの影響を与えるかは推測しかできませんし、結果カバーしきれず今回のように整合性が取れなくなり、システムトラブルが発生してしまいます。
本来ITシステムを導入することによって、自社の生産性を上げたい、業務の効率化を上げたいと思っているのであれば、そのシステムにあわせ業務やプロセスを見直すべきなのですが、どうしても今行われている業務プロセスにあわせるという発想からは抜け出せないようです。
そもそもエンドユーザーの業務を効率化するためのソフトウエアではないのだ。そのため、「合わない部分」は発生しない。「合わせる」のが当たり前だからだ。
自社の業務プロセスにこだわり続ける背景
ITシステムの導入目的をそもそも間違えているということが、今回のようなシステムトラブルの一因でもあるのですが、自社の業務プロセスを基軸にするのには何かしら理由があるのでしょうか？
当然ながら「慣れているから」というのが一番の理由かとは思いますが、そこには「サンクコスト効果」が大きく関係しています。
「サンクコスト効果」とは既に投資してしまった費用やコストに対し、もったいないという気持ちが働いてしまい、その後の判断を誤ってしまう傾向のことですが、これには時間や労力といったことも関連しています。
自社の業務プロセスはおそらく長い期間をかけ確立してきて、そこにたどり着くまでには大きな労力を必要としてきたことでしょう。
そういった意味では、「サンクコスト効果」に加え「一貫性バイアス」も発動してしまっており、それを変えるというのはなかなか難しいのかもしれませんが、目的を「今の業務をよりやりやすくする」ではなく、「業務自体をやりやすくし、効率化し生産性を上げていく」ということに切り替えられれば、導入するITシステムに沿って現在ある自社の業務プロセスを変革しやすくなるのではないかと思っています。
また、「今のやり方を変える」ということに抵抗感を示すという点では「不作為バイアス」なども関係しています。
やり方を変えて失敗したくない、実績のある今までどおりの業務プロセスで、ITシステムを入れデジタル化だけ図りたいという気持ちが先行し、ITシステムを導入したのに一向に業務効率が改善しなかった、という結果をもたらしている企業も少なくないのではないかと感じます。
そもそも、「自社の業務にあわせITシステム“の方”を変える(=カスタマイズする)」というのは、一種のアンカーになって「アンカリング効果」が働いてしまい、思考停止に陥っているという面もあるかと思います。
導入される企業のITシステム担当者も、ITシステムを自社の業務にあわせてカスタマイズするというのが当たり前のように行われていたので、それを疑問も持たずに受入れ、それが脈々と受け継がれてしまっているのでしょう。
システムトラブルの軽減
冒頭でお話しした通り、システムトラブルは様々な種類があり、その性格によって対策も異なってくるのですが、今回の江崎グリコの件に関して言えば、業務にあわせたITシステムのカスタマイズは極力避け、ITシステムに業務をあわせに行くということが対策なのですが、これは言うは易しでなかなか社内の理解をすぐに得るのは難しいと思います。
ただ、カスタマイズというのは通常、製品ライセンスを購入するのとは別に費用が掛かりますし、カスタマイズされた特殊な環境をメンテナンスしていくのも大きな労力とコストを必要とします。
これを避けるためには、先述した自社の業務をITシステムにあわせに行くことと、もう1つは既存のITシステムを購入するのではなく、自社向けにゼロベースでシステム開発を行う、いわゆるスクラッチ開発という手もあります。
ただ、いずれにしても自社にITシステムを理解し、問題などが発生した時に対処できる専門人材がいないと、ITシステムを構築・導入したベンダの言いなりにならざるを得なくなり、その委託費用も膨大になっていきます。
そのベンダの言いなりを避けるため、最近はITシステムの利用企業、いわゆるエンドユーザー企業のITシステム内製化の動きなどもあります。
業務をITシステムにあわせていくというマインド醸成も、社内で対応できるよう専門人材を育成、揃えていく内製化も一朝一夕でできることではなく、時間もかかるのですが、生成AIなども高度化し、簡単なプログラムであれば生成してくれるようになっていますし、運用ノウハウの壁打ち相手としての利用も期待できますし、生成AIの助けを借りながら、内製化によってITシステムにあわせた業務改革を行っていく、という取り組みをしてみてはいかがでしょう。
さて、今回はここまでとします。
次回の更新は7/8(月)10:00の予定です。お楽しみに ！
