消失的布丁
爱吃布丁的小伙伴可能早就发现了，格力高家的招牌销冠——プッチンプリン（噗叽布丁）好长一段时间都买不到了。
这款布丁早在2013年就以累计销量51亿颗的数据被吉尼斯世界纪录认定为全球销量最多的布丁。
噗叽布丁盒子底面有一个塑料“开关”，吃的时候把布丁倒扣在容器上，折断底部小开关，布丁就会完整丝滑地滑落到容器中，倒扣的焦糖顺势流下，就像店里刚刚浇上的一样，顺畅脱模的过程治愈无数强迫症患者，使其从1972年发卖以来畅销至今。
据格力高官网发表的消息，以这款布丁为首的17个品系的冷藏食品因系统故障暂停出货，市场断货逾两个月之久。
时间线
→4月3日 格力高实行基干系统切换，由此发生系统障害，导致物流混乱，部分货品出货延迟。
→4月14日 全日本范围冷藏食品出货暂停。
→4月18日 部分冷藏食品计划恢复出货，并逐步恢复全部食品的出货。不料随即再次发生障害，管理系统显示的在库数量和实际不符，恢复日程推迟到5月中旬。
→4月24日 宣布麒麟饮料公司委托贩卖的3个系列的商品也受波及暂停出货。
→5月1日 宣布已特定到障害原因，但解决问题需要时间，为求日后能安定供给，决定继续延长断货时间。
与“噗叽布丁”一起消失的还有格力高家17个系列，约82种冷藏食品。截至成稿时，格力高方面仍未更新消息。据日经报道说，全部商品有望在6月内恢复出货。
该事件给格力高造成深刻的打击，不仅自家产品生产不了，发不出去，还波及到了友商，眼看着各大超市便利店的货架被别家商品占据，日后能否抢占回来还是个未知数。
→5月8日 格力高修正2024年12月期预期经营数据，受系统故障影响，营业额由3510亿日元修正到3360亿日元，净利润由150亿日元修正到110亿日元。
事件概况
格力高2014年合并了旗下的全资子公司“格力高乳业”，但由于合并之前使用的系统就不一样，生产体系的系统一直是各干各的。类似的事情在格力高内部，生产、营业、财务等方方面面都存在着。
2022年，江崎悦朗社長就任，他认为数字化改革势在必行，积极培养人才，并下决心改革全公司的基干系统。新系统将统合之前各自为政的老旧系统，做到从系统上整合各流程，极力缩减人工；把顾客信息、研发及调达数据联系起来，以方便经营者及时做出合适的判断。这一改革涉及到好几家Vendor，其中挑大梁的就是大名鼎鼎的D社。
格力高这次系统切换故障是由SAP ERP移行SAP S/4HANA时发生的。据日经xTECH报道说，该项目总投资额有342亿日元之多（约合人民币将近16亿），本来预期在2022年12月完成，已经延期一年多不说，项目投资也比初期预想金额提高了1.6倍。
如此巨额的投资换来一大堆烂摊子事儿和巨额的亏损，一时间D社的业务能力遭受怀疑，成了众矢之的。
如上文所说，这个项目投资大，时间长，规模巨大而且涉及多家公司，所以导致问题的原因复杂，真正的原因或许只有深入项目内部并衔接方方面面的“内部人士”才说得清。作为局外人我们只能从表面来分析一二：
▌①定制化太繁琐？
大家都知道日企的IT项目最喜欢搞定制。由于各个流程部门多年来用惯了旧系统，新系统拿过来他们需要去适应，尽管新的业务流程可能更高效更好用，但很多人对改变旧习惯十分抗拒。这样就要求在新系统中不断添加大量迎合旧体系的“定制化功能”。而SAP本就很复杂，还要无休止地加定制开发，使得实施和后续维护都变得困难。
▌②测试不足？
项目已经延期1年多，说明进展并不顺利，可能是格力高内部觉得差不多今年4月可以上了，结果一上线就出这么大的事儿。一般来说系统切换上线之前要经过无数次测试，想定本番中可能出现的各种问题并且准备好对策。
测试做得足够充分的话大概率出问题也不至于这么严重。本来就涉及生产、营业、财务等多种业务的大规模系统整合，可谓牵一发而动全身，尽管项目庞大原因复杂，但是测试做得不充分想必是原因之一。
▌③为啥没有新旧系统并行或启动回退机制？
一般来说，新系统上线前应该充分预想上线后可能发生的各种障害，万一出问题至少可以退回到旧系统以确保业务不受影响。显然这次没有这方面的准备。
有业内人士分析称，双系统并行需要无休止核对两个系统的数据，而且接口可能会有冲突，数据不一致还得人工核对，对于如此规模巨大的项目是不现实的。
那么为什么不roll back？首先，这次基干系统的移行涉及到多个生产环节，而已知出问题的只是出货这一部分，4月初刚发现故障的时间点还不至于因为出货的故障把整个系统叫停。而后发现问题没有那么容易解决的时候为时已晚，错过了最有利的时间窗口，其他生产环节已经在新系统上运行很久，可谓骑虎难下进退两难，只能选择继续。
▌④人员的问题？
由于此类项目开发周期太长，规模太大，涉及到的Vendor也有好几家，这就无可避免地会遇到关键岗位人员的流动，导致项目关键信息无法充分衔接。再有就是协力公司分包的情况很普遍，大多BP不会贯穿项目始终，前后的信息都无法有效地上承下传，也不会为项目的死活负主责。此外，精熟技术的人才短缺，很多人只是接受过SAP的培训就出去干活，并不太懂SAP的人却在做要件定义和基本设计。
▌⑤Vendor的问题？
据悉这个项目最初是由印度系大手T社做的，D社是后期接手进来的。这其中发生了什么，内部的人肯定不方便说。不清楚用户跟Vendor之间哪个环节出了问题，但作为负责项目上线的D社来说，责任或多或少，总归脱不了干系。
2025年の崖
SAP上线出问题不是什么稀奇事儿，稀奇的是影响时间之长。这就不得不提到「2025年の崖」。
「2025年の崖」问题是由2018年9月日本经济产业省的DX报告提出来的。该报告指出日本国内企业若要保持竞争力必须要推进DX改革，否则2025年开始，因低效率、低竞争力导致的经济损失将直线上升，推测每年损失将达到12兆日元。
报告称到2025年，持续稼动超过21年的老旧系统将达到全部的6成，这些老旧系统对抗攻击的能力不足，信息外流的风险很大，加上曾经负责旧系统开发的骨干人员即将退休，种种因素促使当下急于刷新基干系统的企业越来越多，今后类似格力高的基干系统刷新障害可能也会越来越多。
如此旷日持久的严重系统障害大企业的话尚且有余力应对，如果发生在中小企业身上可能就是危及到生死存亡的灾难。由此可见企业DX改革虽紧要但不可马虎，每一步都要稳扎稳打，防患未然。
Tgo技术者之家，持续关注在日IT人关心的各种资讯，打造在日技术者的专属社区。欢迎留言交流互动。
ITgo
