プッチンプリンのシステム障害の謎

時事ネタです。
ちょうど、DXとかに絡んだプッチンプリンのシステム障害について謎が多いので書きたいと思います。

【事の経緯】

そもそも、プッチンプリンではなく、江崎グリコ社ですw
概要としては、
江崎グリコ社では受注、製造、在庫管理においてシステムを一新するとのことで、IT会社のデロイト社に依頼してシステムを入れ替えたそうで、最終的なリリースに1年延期していざリリース。
ところが、システム障害で1か月出荷停止とのことです。
システムの乗り換え先はSAPというドイツの超有名(IT業界では)なシステム。SAPエンジニアとか専門エンジニアがいるくらい、昔から有名なシステムです。

【謎その1:ロールバックできない?】

私もこういったシステム乗り換えや統合作業というものを、エンジニアとしてもプロジェクトマネージャーとしても経験しましたが、この案件、とても謎が多いのです。
システムや事業所の規模に関わらず、システムの入れ替えや統合においては「ロールバック」を計画し、テストします。
ロールバックとは、前のシステムに戻す事です。
ITシステムはいくらテストしても実際の動かすと、想定外は必ず起きますし、そういうものです。
トラブルゼロはほぼありません。なので、今回のように致命的な障害が発生した場合には、必ずロールバックします。
ロールバック自体もテストします。新システムがこけた!という設定にして、ロールバックの手順から実際までをテストします。
プッチンプリン(便宜的にそういいます)では、それがなかったのでしょうか?普通ではありえません。
もしくは、可能性がゼロではない事としては、江崎グリコ社が「ロールバックできなくていいよ!すすめちゃって!」と、男気見せたのかww その場合、デロイト社は誓約書を交わすでしょうね。

【謎その2:2重化はしていないのか?】

予算との兼ね合いにはなりますが、この規模のシステムなら二重化を検討します。
同じシステムを2つ作っていつでも入れ替え可能にすることです。ただ、二重化できる部分とできない部分がありますが、みんな大好きプッチンプリンのためならしてもやそうです。

【謎その3:ITコンサルタントはいない?】

詳しくはわかりませんが、この手の規模であれば、基本、登場人物が3人出てきます。
・江崎グリコ社・・・発注元
・デロイト社・・・ベンダー。IT導入する受注側
・ITコンサルタント・・・江崎グリコ社側に立って、デロイト社のIT用語などを通訳する人、マネージメントする人。
もしITコンサルがいれば、こんな大規模な障害は通常はありえないところです。なぜなら、テストや障害、ロールバックについてもITコンサルが、何らかの助言や危険回避を江崎グリコ社に発言するからです。
考えられることとしては、
A. デロイト社がITコンサル的な事をした
B. いない
C. 江崎グリコ社が言う事聞かない
のどれかですが、いずれも間違いですね。
デロイト社のようなITツールの提供側に、コンサルティングさせては絶対にいけません。
都合よく誘導されてしまいますし、それが彼らの仕事です。

【謎その4:なぜ一気に新鋭に統合?】

詳しい内部の業務事情や財務状況、経営計画がわからないと言い切れないところがままありますが、そもそも江崎グリコ社のシステムはかなり古かったようです。それを一気に新鋭のシステムに乗せ換え、統合とのことですが、果たして正しい判断だったのか・・・
まずは、この手の製造の流れについて、簡単に便宜的にわかりやすく解説すると、
・受注システム というのがあり、プッチンプリンの製造依頼数をAEONから受付するみたいなものです。
・製造管理システム というのがあり、プッチンプリンを何個作ったか、原価いくらだったかを管理します。
・在庫管理システム というのがあり、プッチンプリンが何個冷蔵庫にあるか?を管理し、出荷数も管理します。
・販売管理システム というのがあり、プッチンプリンをAEONに何個販売したか?不良品は?などを管理します。
と、厳密にはもっとありますが、ざっくりはこういう感じ。
事業規模や会社の事情によりますが、一般的には、これらが分かれてたりします。
分かれてる場合は、このそれぞれのシステムをつなぐ、簡単なアプリがあったりします。
え?1つにまとまったほうがよいのでは?いいえ、それは言い切れません。
1つにすることで、受注部分で融通利かせてることによる売上や利益、会社の独自性などがあったりします。

システムが新しくなるということは、特に新鋭のシステムに変える・統合という事は、何を意味するか?
・業務の流れが全く変わる→従業員さんへの業務教育が必要、時間かかる。
・古いままでの江崎グリコ社の強みが消える可能性。これについては、消えてもよいという経営判断もあります。
・障害発生時に切り分けが難しい。
・障害発生時に全滅(今回がまさにそれ)の可能性。
・本当に新鋭システムへの統合が必要だったのか?という疑問
が出てきます。
なので、部分的に進めたり、2か所だけ統合するなど、リスク分散をするのが普通です。

【考えられること】

あくまで憶測ですので、ご理解ください。
状況証拠から考えると、以下が可能性としてありえます。
・そもそもITコンサルがいなく、プッチンプリンがデロイト社に丸め込まれた
・業務教育が足りてなかった
・江崎グリコ社としても、新鋭システム、統合システムというカッコよさで導入に至った。実際の社内の業務分析が甘かった
・江崎グリコ社としても、トップダウンで現場の話を聞かなかった
・デロイト社のプロジェクトマネージャーはポンコツもしくは、上司がポンコツ
いずれにおいても、デロイト社だけではなく、江崎グリコ社としても、問題があったでは?と思えます。

いかがでしょうか?IT経営をしっかり取り入れなかった、勉強しなかった最悪事例が出てしまいました。
プッチンプリン、頑張って復旧してほしいですね。
ちなみに、厳密にはプリンではないんですよね。原料など見てみてくださいね。

返信を残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA