KONGSBERG为丹麦大带海峡VTS交付先进船舶交通管理系统

详细拆解

KONGSBERG 为丹麦大带海峡 VTS 交付了一套新的船舶交通服务系统，消息是 6 月 25 日发的。发布稿里有四件我能真正抓住的东西：合同由 DALO（丹麦国防部采购与后勤组织）授予；软件是 KONGSBERG 自研的 Foresight 海事领域感知软件系列，并为这个站点做了专门适配和开发；它与现场既有的雷达和 CCTV 基础设施做了集成，而且由 KONGSBERG 对集成与接口承担全部责任；另外还配了一份长期的托管服务协议，保障连续性、可靠性和生命周期支持。稿子里剩下的全是形容词。我先把话说透，它给出的事实有多单薄：没有通行时间，没有吞吐量，没有可用性数字，没有前后对比。

所以在别人替我建模之前，我先自己建。把一条海峡想成一个只有一个服务台、而且有硬性几何上限的队列。船到了，排序、放行、通过、离场。服务速率由航道、桥跨和分道通航制决定，没有任何软件能给它加一条车道。VTS 能做的是缩短这个队列里的等待部分，并让等待变得可预测；它加不了通行能力。这个区别就是全部关键，因为读到这类消息的人，脑子里想的往往是自己去买了通行能力。

还要注意这套系统到底提供的是什么，发布稿在这点上异常谨慎：它为通过大带桥的船舶提供信息服务。是信息，不是指令。这不是这次交付的短板，VTS 本来就是这个东西，而它恰好告诉你什么才该指望：关于一个通行能力固定的咽喉点，你能拿到更好、更早、更权威的信息。如果你的波罗的海箱子曾经在卸货港干等过一条“还有两天到”、结果等了四天的船，那么这件事的价值不在于海峡变快了，而在于上游有人更早知道了。

先从我们唯一被给到的数字说起，那就是：一个都没有。项目经理被引用的原话是系统已全面投用、在正常运行中表现符合预期。我信他，但我也想指一下这句话覆盖什么、不覆盖什么。它覆盖的是中位那一天。而我关心的每一条队列，都是在第十天出问题的，不是在中位那一天。一个在正常运行中表现符合预期的系统，对风向突变的那个下午、对有船在分道通航区里出事、对三条船挤进同两个小时的情况，什么都没告诉我。所以在别的之前，先决定你是为哪种状态在买东西，因为发布稿只讲了其中一种。

下面是模型，每一个假设都是我的，不是他们的。假设这条海峡每天通行 30 条船，假设中位船舶在交通区内停留 6 小时。利特尔法则说系统中的数量等于到达率乘以在系统内的时间，所以系统内的期望数量是 30 乘以 6/24，等于 7.5 条船。这是个小数，而咽喉点上的小数是骗人的，因为一个小的系统里面没有余量。现在再假设某件事让服务速率在 12 小时内腰斩。到港仍按每天 30 条继续，那半天里来了 15 条船，而海峡只放过去 7.5 条。于是积压起 7.5 条船。

排泄这一段是人们最容易搞错的地方。限制解除之后，积压不会消失，它只能按服务超出到达的那部分去清。如果服务恢复到每天 30 条、而到港还是每天 30 条，超出量是零，这条队永远清不掉，就那么待着，直到到港节奏自己稀下来。如果这条海峡能冲到每天 36 条，超出量是每天 6 条，7.5 条船大约要一天半才能清完。这就是通行能力固定的咽喉点的特征：一次 12 小时的事件，后面拖着一到两天的尾巴，而这条尾巴落在排在队尾的那条船上。软件改不了这个算术。软件能改的，是你多早知道。

这就带出了瓶颈，因为瓶颈确实存在，而且不在海峡里。你去问一趟波罗的海到港延误的时间都花在哪儿，几乎总能看到同一个形状：船晚了一天半，卸货泊位是空的，拖车计划三天前就排好了，而没有人重排，因为没有人知道。物理瓶颈是那条航道；运营瓶颈是现实世界发生变化、到你计划系统里改了决策之间的那段延迟。这段延迟以小时计，它是你的，而且它是这张清单上唯一一个更好的信息服务真正能挪动的东西。

现在把它翻译成四本账，因为这类交付要么在这儿赚到点什么，要么什么都没赚到。成本上，VTS 不碰你的运费单、不碰能源、不碰装卸费；钱在你因为到港误差下降而能释放的库存里。时效上，它只碰等待项，所以它的全部价值是降低方差，一点都不是提速。库存上，这才是真正的大数所在，而且只有在信息能到达你用来定库存的那张表时才成立。至于合规那头，这里什么都没变：船舶交通服务不是海关系统，发布稿也没有对单证作任何主张。这四本账里有三本，都取决于数据有没有到达某个有用的地方。

下面是那个收益，量化过，所有假设都写出来，你可以跟假设吵，不用跟我吵。假设你一年有 50 个航次进波罗的海的卸货港，每船有你 60 个箱子，那就是一年 3,000 箱、一天约 8.2 箱。假设你是按“提前三天”的第 90 百分位绝对到港误差来定库存的，再假设这个数今天是 60 小时。一天 8.2 箱下，60 小时等于 2.5 天，也就是 20.5 箱。假设每箱货值 40,000。那就是 82 万营运资金压在到港误差上，在假设 8% 的资金成本下，一年约 65,600 的持有成本。

再假设更好的海峡通行信息，把提前三天的第 90 百分位误差从 60 小时压到 36 小时。这是我的假设，发布稿里没有这个数，而且它是你必须去量、而不是去信的数。库存降到 1.5 天、12.3 箱、49.2 万占款、一年约 39,400 的持有成本。释放出来的是 32.8 万营运资金、一年约 26,200。整个商业论证就这么大，而它活或死取决于一个问题：这些信息到底有没有走到你用来定库存的那张表上，还是停在某个人运营室里的一块屏幕上。我看过的大多数部署就是死在这一个问题上，而且它们都通过了每一轮技术评审。

接下来是可用性这笔账，因为你依赖的数据流是一项服务，而服务有在线率。假设托管服务把这套信息服务的可用性维持在 99.5%。一年 8,760 小时里，那是 43.8 小时的中断。假设你那 50 个航次里，每个航次有一段 12 小时的窗口，海峡信息在这段窗口里才真正影响你的计划。某个窗口撞上中断的概率大约是 12/8,760 乘以 43.8，约等于 6%，也就是说你一年 50 个航次里大约有 3 个，会在你最需要这个数据的那一刻瞎着。三个航次、每船 60 箱，这不是一个可以四舍五入掉的数。这就是要有兜底方案的理由，而且这是一个可以用数字、而不是用感觉来讲的理由。

还有一件事藏在那句生命周期支持里，也是没人写进合同的那件。一个处在生命周期支持下的系统，会在你脚底下变。版本会动，接口会动，你七月做完基线验证的那套配置，不会是三月跑着的那套。这不是缺陷，支持本来就这个意思，但它对你刚花了十二周建起来的基线有一个直接后果：基线有保质期。把你验证过的版本锁死，要求对你消费的任何接口变更给书面预告，每次变更后重跑基线，而不是默认延续。如果你的合同没有把预告期写成天数，那么这个天数就是供应商在事发当天早上决定的那个数，而你的度量体系对此毫无防御。

还有一点要说清楚：信息服务不是什么。如果主管机构发布了限制或通告，而你的箱子照样晚了，你没有任何一方可以就此索赔。这里没有一条朝你方向跑的服务等级，发布稿也没有给出任何这样的东西。你拿到的是一个更好的公共信号，而你要去追究承诺的对象，仍然是你签了合同的承运人。这句话值得在会上说出口，因为我见过团队慢慢把自己的期待，从约束他们的合同，转移到给他们信息的数据流上，然后花一个季度跟错误的一方，去争论一个两方都没造成的延误。

这里还有一个人们会忘掉的杠杆，因为它是唯一一个真正属于你的。你加宽不了航道，但你能影响你的船什么时候到那儿。当到港挤成一堆时，队列比它的平均值所暗示的更糟，而一条挤进堆里的船，要为它前面的船付账，也要为自己付账。去问你的承运人，船期表能不能挪几个小时，让你的船不要和所有人的船落在同一段里。假设——这是我的假设，不是他们的——排在堆积尾部要付 6 小时，再假设你一年 50 个航次里有五分之一目前落在堆积窗口里。那就是 10 个航次、一年 60 小时的可避免方差，代价是一次船期沟通，而不是一个项目。它很小，而且它是这张清单上唯一不花钱、也不需要供应商的一项。

集成是这类交付成或不成的地方，而发布稿在这点上异常具体，所以我要借用它的说法：该方案与既有的雷达和 CCTV 基础设施集成，并由 KONGSBERG 对集成与接口承担全部责任。这一句话比发布稿里所有形容词加起来都值钱。我复盘过的每一个失败的系统项目，都失败在接口上，而且几乎全都是因为两方都以为对方负责。一个具名的主体、拥有接口，是这里可以搬走的经验，而且它直接适用于你：当你把一个外部数据流接进你的计划系统时，把接口的责任人写成一个名字，再把凌晨两点它断了之后会发生什么写下来。

托管服务那部分也该同样处理，也就是说把它当合同读，而不是当软件的某种属性读。软件没有可靠性这回事。一个有可用性目标、有响应时限、有具名负责人的服务，才有可靠性。还有一点值得注意：发布稿说支持是远程提供而不是驻场，这让响应时限更重要而不是更不重要，因为没有人会走过走廊去拍一下机柜。所以你买这一类东西的时候，问同样的三个问题：书面承诺的可用性是多少、按月怎么量；一级故障的承诺响应时间是几个小时、非工作时间适不适用；你跑的那个版本和它的路线图归谁。这三个里任何一个回答是形容词，你买到的就是一种情绪。

把人留在回路里，而且把人具名。VTS 发布信息，船长做决定。发布稿提到的设计目标是高可用性、冗余和安全通信，这些正是一个输出要被人拿去在时间压力下做动作的系统的目标。这意味着告警链比它背后的模型更重要。挑一个你想让这个数据流改变的决策：重排卸货泊位、放拖车、挪截关时间。然后指定那个对这个信号做动作、并且在什么都没发生时承担后果的人。如果答案是“没有明确的人”，这个数据流就会变成一块大家偶尔扫一眼的屏幕，而按我的经验，从上线条到变成那样，大约六周。

先做基线，我从来没有见过这一步浪费过谁的时间。拿你关心的那一条航线的十二周自有日志出来。每个航次，记下你在提前七天、提前三天、提前一天拿到的预计到港时间，再记下实际到港时间，按小时算绝对误差。这就是你的基线，以后任何人对你说的任何主张，都拿它来量。这张表里不许出现任何供应商的数字，每一个缺口都标记为未知，不许填，因为一个被填上的缺口，等它走到商业论证那一步时，已经悄悄变成事实了。

然后是影子模式。让新的数据流和老方法并行跑八周，输出可见，不做任何自动动作，每天对照那份手写的基线打分。在第一周之前，把主指标写成文字，把停止规则写在同页上。我的版本是这样：主指标是提前三天的第 90 百分位绝对到港误差，单位小时，用你自己的航次算；停止规则是这个数如果连续四周没有比基线低至少 20%，或者某个月的在线率掉到 99% 以下，就在 24 小时内退回老方法，并把学到的东西写下来。不接受以路线图、新版本或者“下季度数据会更好”为由的延期。

别让准确率变成目标。准确率只是代理指标。目标是库存周转和服务水平，而一个数据流完全可能平均更准、却在真正要紧的地方更差，因为触发加急、触发溢价运费、触发那通电话的，是误差分布的尾部。去打第 90 百分位的绝对误差，别打均值，并且把这个数和你压着的库存放在同一页上，让这两个数被一起讨论，而不是分开讨论。

趁现在还没有利害关系，把阈值定下来。提前三天的第 90 百分位绝对到港误差，单位小时，目标是从你自己量到的基线出发、两个季度内做到 36 小时。数据流可用性不低于 99.5%，按月用你自己的接入日志来量，而不是看供应商的状态页。通知延迟，即从主管机构发布通行限制、到它出现在你计划系统里的时间，工作时间内 30 分钟，非工作时间 120 分钟。海峡进出两个时间戳的覆盖率，一个季度内至少 90% 的航次要有。还有一个人工否决率：如果你的操作员连续两周否决了超过 40% 的自动告警，先停下来查清楚，再谈扩容。

坑，基本都是我每个季度都能看到的那些。先买看板、后做基线，意味着你永远没法证明这块看板干成了什么。把主管机构的信息服务当成对你的承诺，而它是发布给船舶的，发布稿没有给你任何服务等级。把“在正常运行中表现符合预期”当成对糟糕那天的说法，它不是。把源头系统的可用性当成数据到手里的可用性：他们的冗余不是你的管道，而真正会断的是你的管道。还有让一个季节去教模型，因为二月的海峡不是七月的海峡，一段没有跨过季节变化的基线，等于什么都没量。

还有两件我不会做的事。我不会在一份没有任何数字的发布稿上搭商业论证，而这一份就是没有。我也不会告诉你要买哪一家的东西：这类系统的类别重要，上面写着谁的名字不重要，而你自己那十二周的基线，会比任何一个参考站点告诉你的都多。我也不会跟你说海峡变快了。它没有。航道还是上周那个宽度，桥还是那座桥，再多的海事领域感知，也加不出一条车道。

真正变的东西比标题窄，也比标题有用。一个繁忙的咽喉点，现在被管它的机构看得更清楚了，而观察这件事只有在下游有人因为它改了决策时，才对你值钱。整个机制就是这么回事，而且挺无聊：输入更好，误差更低，库存更少。先量化，再谈优化；量不出来，就别优化。海峡前面那条队没动。你能动的，是你押在“这条队排到哪儿”上的那个赌注的大小，而这也是整件事里唯一带着数字的东西。

↑ 返回核心要点

— 作者 拉维