一条产线上挂着三种周数——我们是如何把排产计划搞砸的

三个"第28周"，三个时间窗口

那是去年7月的一个周四下午，我在深圳办公室接到项目经理的电话："德国那边说28周的货已经到了，但我们这边的28周排产还差两周。物流说不清楚到底是谁搞错了。"

我打开共享的排产表，三条产线的数据列在同一个Spreadsheet里——德国的车用散热器总成（GPU产线）、深圳的PCBA板卡（SMT产线）、芝加哥的最终组装线。每一条都有"计划周数"一栏。德国那边填的是2026-W28，深圳填的是"第28周"，芝加哥填的是"WK28"。看起来是同一个东西。

仔细一查才发现，德国的W28是2026年7月6日那周。深圳的"第28周"是按中国惯例从1月1日起算的，比ISO周28早了两天。芝加哥用的是4-4-5财务日历，他们的WK28从6月29日就开始了。三个日期跨度加起来差了整整9天。

而我，作为负责整体排产的项目经理，看着这同一个表，以为大家的"28周"是同一个东西，就这样安排了三段完全对不上的供应链节点。

德国：ISO 8601，理所当然的标准

德国工厂的天车系统是一套SAP EWM，所有排产都跑在ISO 8601体系下。周一开始于周日还是周一，他们争论过，但最终SAP的日耳曼设定就是：周从周一开始，第一周是包含1月4日的那周。德国人回答我们的催货邮件时永远带着一个ISO周号，比如"该批次将于W31完成"。

2026年，ISO第28周是7月6日（周一）到7月12日（周日）。德国工厂按此排产，GPU壳体在W27完成注塑，W28初开始散热片装配，W28末下线质检。

深圳：按部就班的"自然周"

深圳的SMT工厂没有SAP。他们用的是国产MES系统，周数的定义和德国完全不同：1月1日是第1周的第1天，不管1月1日是星期几。所以2026年1月1日是周四，那么第1周就是1月1日（周四）到1月4日（周日）——一个只有4天的"第一周"。后面每周从周一开始算起。

按这个算法，2026年的"第28周"从7月6日（周一）开始，到7月12日结束。跟德国工厂刚好对上了？差一点——2026年1月1日刚好是周四，巧合地让两种算法在第28周的周一重合了。但问题出在全年累计上：SMT工厂的生产计划是按自然周累积的，年终结算时差了整整一个"零头周"。

更要命的是，深圳工厂在做排产汇报时，并不会注明"ISO周"还是"自然周"，他们只是在表格抬头写"第X周"，然后复制粘贴到跨国排产表中。这是信息丢失的源头。

芝加哥：4-4-5财务日历，另一个世界

芝加哥的组装线属于美国子公司，财务部门遵循4-4-5零售财年（Retail Fiscal Calendar）。这个系统的逻辑完全独立于ISO和自然周：每个季度有13周，分为两个月4周、一个月5周。财年从2月开始，到次年1月结束。所以芝加哥供应链同事说的"WK28"，指的是财年的第28周，对应公历的8月某周。

芝加哥的采购经理Tina在邮件里写："We need the PCBA boards by WK28 for final assembly. That's mid-August." 我们深圳的同事看到了"WK28"，以为就是7月6日那周，心里想：完全来得及。实际上芝加哥要的是8月中旬，但深圳排产是按7月初准备的。等我们发现时，PCBA板已经过早生产完、堆在仓库吃灰，而芝加哥那边因为缺料停工了三天。

四种周数体系，一张对照表

那次事故之后，我逼着团队做了一张跨国周数对照表。任何涉及跨厂排产的人，必须先在表里确认"你说的是哪种周数"。

2026年7月6日（周一）这一周，在不同体系下：

ISO 8601（德国工厂）:        2026-W28  (7月6日-7月12日)
中国自然周（深圳SMT）:      第28周     (7月6日-7月12日)*
                                        *2026年碰巧对齐，2027年不对
美国周日历周（US传统）:     Week 28    (7月5日-7月11日)
4-4-5财务历（芝加哥组装）:  WK25       (财年Q2第8周，7月)
农历周数（部分中国工厂）:   五月廿二至廿八 (农历五月底)

2026年12月31日这一天的周数：

ISO 8601:     2026-W53? → 错！12月31日是2027-W01 (跨年了)
中国自然周:   第53周 (12月28日-12月31日，只有4天)
US周日历:     Week 53 (12月27日-12月31日，只有5天)
4-4-5财务历:  WK48 (财年最后一个周期)

注意那个12月31日的ISO周数：它属于2027-W01，不是2026-W53。如果你在12月底发邮件说"W53交付"，德国工厂会回复"2026年没有W53"——你会以为他们在找茬，但实际上SAP里真的搜不出W53这个周号。

怎么防止这个事情再发生

1. 排产表里强制标注周数体系

我们改掉了排产表的模板。原来只写"28周"，现在必须写"2026-W28 (ISO)"或"第28周(CN-NAT)"或"WK28 (4-4-5)"。格式不统一没关系，标注清楚才重要。

2. 用公历日期做唯一的"共识锚点"

周数是派生的。公历日期才是共识。我们现在规定所有跨厂沟通必须同时给出公历日期区间，例如"ISO W28 (7/6-7/12)"。周数只是辅助，日期才是权威。

3. 自动化转换而不是人工对照

我自己写了一个小脚本，把三种周数体系自动映射到公历日期。每次收到不同厂的排产表，先用脚本跑一遍，标记出"看起来是同一周但实际上日期不同的"条目。这比人工对着日历算快得多，而且不会算错。

那个项目最后怎样了

我们在发现排产偏差后的第三天紧急调整了深圳的SMT产线，把一部分批次的优先级提前，给芝加哥补上空缺。德国工厂那边因为没有受中国周数影响（他们一直按ISO跑），整体节奏还在。项目最终晚了8个工作日交付，成本超支约6万美金——包括空运补货、加班费和芝加哥厂的三天停工损失。

这事已经过去大半年了，我至今还在用那件事当培训案例。新同事入职，我第一件事就是把那三个版本的"第28周"摆出来，让他们找不同。每次都能讲一小时。

跨国排产的问题从来不在机器上。机器只管来料加工。问题在人和人之间——你我看着同一个"28"，想到的是完全不同的7天。