グリコ炎上

そうですね。一般的な基幹システム更改プロジェクトのリカバリプランは旧システムへの切り戻しですが、今回SCM領域が含まれていますので、一見して稼働判定OKの基準を超えて進んだものの、数日経ってデータ移行不備やプログラムバグやパフォーマンスイシューなどが起こり、実在庫とシステム在庫にズレが生じて、既に部分的な修正では回復できない場合、進むも地獄、切り戻すのも地獄の状態になります。(何が何処に何個あるかわからないので、全操業を止めて人海戦術でデータ修正する)

テストが不十分だったとか、移行リハーサルが不十分だったとか、稼働判定基準が甘かったとか、何なりと要因は考えられますが、おそらく複数ベンダーに外部サプライヤなどが関係していて非常に窮屈な制約の中で現場は最善行動した上での結果なのではなかろうかと思います。

これらはあくまで想像ですが、私の経験上、ハナから勝ち筋が数ミリしかないプロジェクトが現実に立ち上がって、それを託されたプロマネが1ミリでも成功率を上げるために数年かけて命を削り、最後は皆んなで祈りを捧げて神頼みするのが、大規模な基幹システム更改プロジェクトの現実かと思います。

(編集済み)

ITの会社にいるとみんながある程度リテラシーあること前提になりますが、事業会社のようにITレベルもばらばら、かつ色々な部門が絡む大規模プロジェクトだと、想定してなかったような要件が出てきたり、考えていた通りに回らなくなったり……というのはありうるのかなぁと思います。

プロが入っているので想定できるような対策はやったけれどもやはり起きてしまった、ということではないかな〜と勝手に推測しますが、原因が分かったらぜひグリコさんとデロイトさんには教えてほしい&売ってほしいです……。

他のプロジェクトにも役立つ知見がたくさん含まれてそうです。

基幹システムとwebでは性質が異なると、前のスレッドでも話題になりました。webと同列に考えられるものではないです。

https://link.workcircle.app/JtrbkgHuo1P7NzAi8

ERPの場合、パッケージの基本機能に業務プロセス側を合わせる形で要件を実現します。そのため、エンドユーザー側（様々なリテラシーレベル）が後にごねるなど、問題が起きやすいです。またウォーターフォール型のPJになり、前工程での考慮漏れに関して圧倒的に不利です。色んな機能が有機的に絡んで結合しているため、一つの問題が他にも波及しやすいという特性もあります。

大きな問題が一つ起きてそれを解決出来ないのではなく、大きな考慮漏れがいくつもあり、それらが絡み合って、本来なら大きく手戻りさせる所、それをやってるとこれまでの工数を凄まじくムダにするのでやっつけで対応できないか、どうなんだ？うーん、結局数ヶ月前に戻るしかない・・・（オーバーヘッド入れると実質それ以上）、と言ったような状況かなと想像出来ます。