日経2024年5月1日記事より
プッチンプリン出荷再開を延期 グリコのシステム障害https://www.nikkei.com/article/DGXZQOUF012CE0R00C24A5000000
当初5月中旬の出荷再開を目指すとしていたシステム障害が、さらに出荷再開延期するというプレスリリースが5月1日に発表されました。
いったい何が行っているのか、再び公開情報と一般的な知識の範囲で考察してみたいと思います。
（考察その１は、以下のリンクからどうぞ。）
https://www.at-ai.jp/2024/04/glico/
【SAPでの標準的な製造プロセス概略】
このあたりの業務プロセスは、SAP標準機能を使うと以下のような流れになっています。
・MRPが実行され、その時点での在庫量や出荷スケジュール、需要予測や生産能力などを考慮して工場での品目別生産量とスケジュールが算出され、ロットが定義される。製造指図も発行。
・最終製品の生産量や今後の販売・生産計画に合わせて、BOMに基づいた数量で原材料の発注が行われ原材料の保管スケジュール等に反映。
・製造指図に基づいて、工場のラインで製造活動が実施され、完成した製品在庫が工場内倉庫に入庫される。その後、物流センターへの在庫移動が行われ、物流センターからそれぞれの得意先へ出荷。
・原材料在庫は、おそらく最終製品の生産量からBOMで展開される原材料数量をバックフラッシュでマイナスする行為を、最終製品完成に合わせてトランザクション投入。
・一連の取引に関連して発生する会計伝票が、リアルタイムで財務会計・管理会計モジュールに連携される。
【不具合の状況 日経新聞記事より】
https://www.nikkei.com/article/DGXZQOUF012CE0R00C24A5000000
・物流センターの実際の在庫数とシステム上の在庫数が一致しない状況が続いている。
・グリコによると常温品や冷凍品にもシステム障害の影響が出ているものの、冷蔵品に比べて賞味期限が長いため、在庫数の誤差を手作業で修正しながら出荷を継続できている。
・冷蔵品は物流センターへの入庫から出荷までの時間的猶予が短く、修正作業が追いつかなくなったことが出荷停止の理由だという。
⇒この状況が日経記事ではじめて公開されてしまうのが、なかなかの衝撃でした。
【現場で起こっていること 推察】
・在庫数が合わないということで、どのプロセスで在庫が合わなくなっているか、システム内のロジックを追っかけ、および関連する業務プロセスを追っかけながら、システムや業務運用の不具合箇所を特定する対応を行っている（記事やプレスリリースによれば、これは特定が完了したとなっている）。もしかしたらマスタの構造やSAPのコンフィグレーション、などシステム設定に起因している可能性もあるので、それも検証していると思われます。システム間のインターフェースプログラムの不具合であれば、システム間の整合性を合わせるべくその検証も行われるでしょう。そもそもシステム切替時のデータ移行時点で不具合を起こしていたのが検知できないまま本番に突っ込んでいる可能性もあります。トランザクションデータだけでなく、マスタデータの移行でおかしくなっていることも考えられます。
・また、アプリロジックとは別にインフラ視点でデータの処理量にインフラやネットワークが追い付かない場合には（AWSなどクラウドを使っていれば自動でスペックが拡張されるようにも思えますが、、、詳細は分かりかねます）、インフラやネットワークのスペック増強が必要になり、最終的にはインフラ、ネットワーク、アプリケーションのすべてがうまく動作するか検証して復旧、ということになります。
・冷蔵品については製造・出荷を止めたが、常温品や冷凍品については製造・出荷を継続しているということで、日々工場のラインが夜間止まるタイミングで（24時間稼働でなければ）システムの理論在庫と工場や物流センターの実際の在庫をExcelなどに突合して差分を洗い出し、在庫修正伝票を日々入れている。合わせて、このチェックを毎日行いながらシステムや業務運用の不具合箇所の特定につながる情報収集も行っている。ただし、記事やプレスリリースの内容が正確であれば、不具合の内容は特定されているということでこれ以上の不具合箇所特定は不要かもしれません。
【今後復旧に向けて必要な対応 推察】
・プログラムロジックの修正、システム設定の変更、マスタ構造の見直しなど、システム関連の対応。その後の結合テスト、総合テスト、UATなど整合性。
・業務運用の変更が必要な場合、その対応とUAT。
・インフラ、ネットワークのスペック増強が必要であるとしたら、それも行ったうえでシステム運用テストを含めた全体のテスト。
・そもそもシステム切替時のデータ移行でやらかしていたのであれば、移行データの修正。トランザクションデータだけでなく、マスタデータも。
・どこかのタイミングでシステムや製造・出荷処理を止め、在庫などトランザクションデータの整合性を合わせるためのデータパッチ処理と整合性検証。→その後、会計含めたデータ復旧。数量の整合性だけでなく、金額の整合性も合わせなければならないので、さらに労力がかかるはず。
・3月末締めの第一四半期決算は新システムが稼働していないので決算開示はできると思いますが、6月末締めの第二四半期決算は、そんなに簡単に決算開示できる状況にないはずで、どこまで決算発表遅延をもたらすかは未知数です。決算の正しさをどうやって証明できるのか、SAPがスムーズに稼働していればシステムの信頼性は確保されているのですが、この状況だとシステムの信頼性をそんなに簡単には証明できないのでは、と懸念されます。
ここまで状況が深刻だと、ちょっと着地が見えなくなってきていますが、現場に携わる方々にはくれぐれもお身体を壊さぬよう祈っています。また続報が出たら、そのタイミングで改めて考察したいと思います。
コメント