コンサルラウンジ#テック
アーモンド効果を飲もうとしたら、コンビニに無い。
なんと、グリコのシステムトラブルで新規発注ができていないらしい。
調べてみると4月からシステム停止！？基盤ソフトウェアは独S社、導入はD社。
1ヶ月も基盤システムが止まるなんて、通常ありえることなのでしょうか。なぜ、上手くいかない場合のリカバリープランが無かったのでしょうか。
素人でも分かるリスク対策を用意しないなんて、通常あり得るのでしょうか。
(編集済み)
7
アーモンド効果を飲もうとしたら、コンビニに無い。
なんと、グリコのシステムトラブルで新規発注ができていないらしい。
調べてみると4月からシステム停止！？基盤ソフトウェアは独S社、導入はD社。
1ヶ月も基盤システムが止まるなんて、通常ありえることなのでしょうか。なぜ、上手くいかない場合のリカバリープランが無かったのでしょうか。
素人でも分かるリスク対策を用意しないなんて、通常あり得るのでしょうか。
内情は分かりませんが、100億を超える規模になると、スコープもステークホルダーも多すぎて、誰かスーパーマンが数人いればコントロール出来るようなレベルになく、様々な要因が絡まっているでしょう。
素人でもわかるリスク対策がなかっただろうとか、リカバリープランが陳腐だっただろうとか、到底思えないです。
基幹システムをやっている身としては、いつか自分にも起こり得る事なので、中の人にとても同情しています。
入念なリカバリープランに対して、それを超えるほどの問題が起きたということでしょうか。
それでは、リカバリープランの意味がないですね。。
基盤ソフトの品質管理がどのように行われているかわかりませんが、システムを切り替える際に以前のシステムにすぐ戻すなどはできないものなのでしょうか？
Webアプリケーションレベルの経験だと、システム切り替えで1ヶ月システムが止まるなんて想像できないんですよね。。
そうですね。一般的な基幹システム更改プロジェクトのリカバリプランは旧システムへの切り戻しですが、今回SCM領域が含まれていますので、一見して稼働判定OKの基準を超えて進んだものの、数日経ってデータ移行不備やプログラムバグやパフォーマンスイシューなどが起こり、実在庫とシステム在庫にズレが生じて、既に部分的な修正では回復できない場合、進むも地獄、切り戻すのも地獄の状態になります。(何が何処に何個あるかわからないので、全操業を止めて人海戦術でデータ修正する)
テストが不十分だったとか、移行リハーサルが不十分だったとか、稼働判定基準が甘かったとか、何なりと要因は考えられますが、おそらく複数ベンダーに外部サプライヤなどが関係していて非常に窮屈な制約の中で現場は最善行動した上での結果なのではなかろうかと思います。
これらはあくまで想像ですが、私の経験上、ハナから勝ち筋が数ミリしかないプロジェクトが現実に立ち上がって、それを託されたプロマネが1ミリでも成功率を上げるために数年かけて命を削り、最後は皆んなで祈りを捧げて神頼みするのが、大規模な基幹システム更改プロジェクトの現実かと思います。
ITの会社にいるとみんながある程度リテラシーあること前提になりますが、事業会社のようにITレベルもばらばら、かつ色々な部門が絡む大規模プロジェクトだと、想定してなかったような要件が出てきたり、考えていた通りに回らなくなったり……というのはありうるのかなぁと思います。
プロが入っているので想定できるような対策はやったけれどもやはり起きてしまった、ということではないかな〜と勝手に推測しますが、原因が分かったらぜひグリコさんとデロイトさんには教えてほしい&売ってほしいです……。
他のプロジェクトにも役立つ知見がたくさん含まれてそうです。
基幹システムとwebでは性質が異なると、前のスレッドでも話題になりました。webと同列に考えられるものではないです。
https://link.workcircle.app/JtrbkgHuo1P7NzAi8
ERPの場合、パッケージの基本機能に業務プロセス側を合わせる形で要件を実現します。そのため、エンドユーザー側（様々なリテラシーレベル）が後にごねるなど、問題が起きやすいです。またウォーターフォール型のPJになり、前工程での考慮漏れに関して圧倒的に不利です。色んな機能が有機的に絡んで結合しているため、一つの問題が他にも波及しやすいという特性もあります。
大きな問題が一つ起きてそれを解決出来ないのではなく、大きな考慮漏れがいくつもあり、それらが絡み合って、本来なら大きく手戻りさせる所、それをやってるとこれまでの工数を凄まじくムダにするのでやっつけで対応できないか、どうなんだ？うーん、結局数ヶ月前に戻るしかない・・・（オーバーヘッド入れると実質それ以上）、と言ったような状況かなと想像出来ます。
大規模システムの更改で、しかも1年遅延して、デロイトもグリコ側の担当も相当追い詰められていたと推察します。
リカバリープランも立てられていたに決まってると思いますが、想定してなかったミスが発覚して戻りたくても戻れなかったんでしょう。切り替えを完了させて、稼働させた後に出荷や在庫データ不整合がわかった、とか。
まあ地獄っすよね。
デロイトはもちろん、グリコ側の担当者も経営層からなぜリリースを許可した、なぜ見抜けなかったと問い詰められてるでしょうし、SAP更改プロジェクトにおける悪い事例として、後世に語り継がれるのかもしれません。
大規模プロジェクトの更改って本当に地獄なんすよね。。。いくら想定しても想定してなかった問題ってでてくるので。
ただそれでも文字通り命を削ってコンティンジェンシープランを二重三重に考え用意しておくことがPMの役割といえば役割なんですけど。
私はPMのほうに同情してしまうなあ。。。