オレからするとこんなに長引くのが意外。
詳細はこちらPDFを見てみる。
基幹システムを切り替えた際に発生したシステム障害により、全国の物流センターでの出荷業務に遅滞が生じ、当社のチルド食品およびキリンビバレッジから販売を受託しているチルド商品※で一部のお取引先様に遅配や欠配が発生しておりました。それらの解消に向け、4月14日(日)からチルド食品の出荷業務を一時的に停止し、4月18 日(木)に一部を再開いたしましたが、物流センターでの出荷に関するデータの不整合等が発生したほか、想定を超える受注品目数に対し処理が間に合わず、4月19日(金)から再度出荷を停止しております。
チルド商品でトラブっているので、ビスコは安定供給されている。
長期化するトラブル
最初のニュースが出た時、「新システムでトラブルか。旧システムに切り戻して安定させるまで3日くらい」とか思っていたオレが甘かった。どうやらこの文面から見ると旧システムへの切り戻しはせず新システムで頑張っているようだ。
もう一か月経っている。ちょっと考えられないくらい時間を使っている。
ことの発端は4月3日だ。グリコが基幹システムを切り替えた際に障害が発生し、一部の受発注、出荷業務に影響が出た。4月5日に発表されたリリース文は5行と短く、簡潔な説明と、取引先への謝罪の言葉が並んでいた。
ところが、その後の4月14日には乳製品、プリンなどの洋生菓子、果汁飲料、清涼飲料などの冷蔵品について、全国の物流センターでの業務が一時的に停止となる。18日には一部業務を再開し、順次復旧が進むとみられたが、ここでも不具合が生じた。
具体的には、システム上の在庫数と実際の在庫の数が異なるなど、データの不整合があったという。また、全国から寄せられた受注量は想定の範囲内だったものの、システムエラーが続いたために処理が間に合わず、結局、再度停止になってしまった。
細かくは追っていなかったけど、なにやらうまくいったりうまくいかなかったりしているようだ。
3ページ目から。
現在は5月中旬の再開を目指して復旧に当たっているが、これより早期に復旧する可能性も、さらに遅れる可能性もある。基幹システムの障害の原因、データの不整合との関連性など、原因をすべて特定できているわけではない。「復旧に向けて、出荷業務の手順の見直しや、システムのさらなる改修の可能性も含めて検討している」（グリコ広報）。
障害が発生した新基幹システムは、総投資額340億円のグリコにとって巨大プロジェクトだった。グリコは2014年に完全子会社だったグリコ乳業を吸収合併したが、システムはバラバラだった。会計など統合している分野もあったが、生産関係で異なるシステムを利用していたという。
来月まで掛かるらしい。
会社は、当初、今月中旬の出荷再開を目指していましたが、システムの改修作業に想定より時間がかかっていることや、システムが正常に動くかどうかを確認する検証が必要になったことから、出荷停止の延長を決めたということです。
会社は、来月中の再開を目指して作業を行うとしています。
来月中が6月中旬なのか来月(6月)のどこかを指しているのかわからないけど、最悪さらに2か月弱ってこともあるのか。
主犯
実は担当社はすでに判明している。
これほどまでのトラブルを引き起こすきっかけとなった基幹システムの切り替えプロジェクトは、どのベンダーが手掛けたのか。江崎グリコの広報は「複数のベンダーが携わったが、個社名は公表していない」とするが、ダイヤモンド編集部の取材で、プロジェクトを担った主幹ベンダーがデロイト トーマツ コンサルティングであることが判明した。
実は、デロイトが手掛けてきたプロジェクトは1年超も大幅に遅延した上に、障害を発生させた「ボロボロの案件」（コンサルティング業界関係者）だったのだ。システムが1カ月近く止まるような大惨事も極めてまれだ。
「1カ月近く止まるような」実際には3カ月になりそうだけどな。ダイアモンドがデロイトトーマツコンサルティングだと突き止めたのは、ずーっとデロイトトーマツを追っていたかららしいけど、そこはまあいいか。
でもさ、デロイトトーマツ憎しで記事書いちゃだめだよ。主犯はグリコに決まっているだろ。デロイトトーマツを採用したのも、プロジェクトマネジメントに失敗して遅延させたのもグリコの調達ミスじゃん。他のベンダーに切り替えるとか、スコープを変える(つまり新システムのカットオーバー時の稼働範囲を絞るとか)はどうなの？
なんでこうなったのかの内部情報は公開されていないので、そこについては論評できない。なので、こういう大トラブルにならないようにするためのテクニックについて書いていく。
システム移行でトラブルを極小化するテクニック
最初の方にも書いたけど、旧システムに切り戻ししなかった理由は情報がないのでよくわからない。例えば、新システムに合わせて物流倉庫内の機器や製造装置側も一部刷新し、その刷新した物流倉庫内の機器や製造装置は旧システムでは稼働させられない みたいな切り戻しできない条件があるという話ならわかる。まあ情報が無い以上想像でしかない。
そういう事情を踏まえても、こういう基幹系、大規模なシステムを切り替える時は次のようにトラブルに備える。
- 並行稼働期間を設ける
- 切り戻しできるようにする
- 移行テストを入念に
並行稼働期間を設ける
開発の遅延でそういう余裕(金銭？時間？)が無かったのかもしれないけど、旧システムで運用している時に新システムにも同じデータを投入し、旧システムでできていたことを新システムでも実現できることを確認するフェーズは必要。
グリコのような製造系では、場合によっては24h365Daysで動かしているかもしれないし、毎日朝から稼働して夜には終了(あるいはその逆で夜開始朝終了)しているかもしれない。でも、並行稼働はやればできる。
並行稼働はその分のシステム開発も必要になるけど、旧→新への切り替え時の安心感が違う。「その分のシステム開発」とは、旧システム稼働中に新システムにデータを入れたり、出力結果を突き合せたりするツール等である。図にしたほうが分かりやすいので図にする。
並行稼働期間を設けないとこんな感じ。
並行稼働期間を設けるとこんな感じ。黄色のツール部分が必要になるけど、同じ入力なら同じ出力になるよねっていう確認はできる。
新規機能とかそういうのは後回しでもいい。まず製造業としては製造が第一である。買ったものを加工し、できたものを売って初めて収入になるわけで、注文とか在庫も含めてその根幹は押さえないと。
今回起きているデータ不整合は、こういう並行稼働期間で問題を抽出できる。
切り戻しできるようにする
上に予想を書いたようになんらかの事情で旧システムと新システムでは、システム外の状況が完全互換ではない可能性はある。でも、それにしたってなんらかの方法を用いれば互換度を向上することは可能。例えば、物流倉庫内の機器や製造装置の刷新があるとしてもシステム移行と同時に入れ替えない、つまり旧システムで使っていた物流倉庫内の機器や製造装置もいつでも稼働できるようにするとか、新しい物流倉庫内の機器や製造装置と旧システムを先につないで稼働させるとかである。
システム移行する時は、なにかうまくいかないことが起こるものである。トラブルは構成要素の数だけいくらでも想定できるので、一気に移行せずに段階を踏むだけでリスクヘッジになる。
グリコの状況ではどうも切り戻しはしていないように見える。切り戻しして並行稼働期間設けていれば避けられたトラブル長期化に見える。いや、内部的には結局新システム稼働できていないじゃないかっていう大問題なんだけど。でも、対外的に迷惑は掛けずに済む。
移行テストを入念に
並行稼働期間も切り戻しもそうなんだけど、そういう形でリスクヘッジしていくと、自然に移行テスト、移行訓練は何度か行うことになる。
グリコでは、場合によっては24h365Daysで動かしているかもしれないので移行テスト・移行訓練をやりにくいかもしれない。でも、そこは他の業種だって24h365Daysで動かしているシステムを移行してきているわけで、一部業務を縮退させてでも移行テスト・移行訓練は行うべきである。
TVでCM打ってアナウンスされるような業種を例にすると、道路・鉄道・銀行などであろうか。一部通行止めとか、一部運休・折り返し運転や代替輸送とか、一定期間取引停止などである。
しっかり計画して事前に関係各所に協力を求めて移行テスト・移行訓練を数回実施すべきである。
まとめ
いやしかし、デロイトトーマツコンサルティングは訴訟起こされるかもなグリコに。
そしてグリコはキリンビバレッジに損害の補償が発生するかもしれない。
