定量供应链简介

首页 » 资源 » 此处

定量供应链优化（简称定量供应链）是关于供应链的广泛观点，简言之，其宗旨是利用现代计算资源的能力来强化人类智能从而加以充分利用。但是，这种观点并不包罗一切。它不能当成是供应链挑战的最终解决方案，而是作为一种补充方法，并且这种方法几乎总是用于改善各种情况。

定量供应链可以帮助贵公司改善服务质量、减少过多的库存和报废、提高生产力、降低采购价格和运营成本等等。供应链挑战根据情况的不同而存在很大的变化。定量供应链考量了这种多样性，并在面临复杂事务时力求解决。但是，对于习惯采用更传统的方法优化其供应链的供应链从业者而言，定量供应链可能会令他们感到有点困惑。

在下文中，我们将介绍针对供应链充分利用定量观点所需的要素，查看和阐明定量供应链计划的志向所在，以及介绍负责执行该计划的团队的角色和技能。最后要概述与定量供应链相关的方法。

志向所在    项目角色    技术    项目阶段

志向所在

供应链涉及到每天数百万种决策，规模非常小的公司除外。对于库存中的每个单位，公司在做出将此单位保存于何处的决策，而不是将其转移到其他地方。此外，对于可能生产或采购的非现成的库存单位也是同理。什么也不做本身就是一项决策。

定量供应链就是对公司每天需要做出的数百万种决策加以优化；由于我们谈到的决策每天即使不是上亿种，至少也有数百万种，因此计算机在其中发挥着重要作用。这一点不足为奇，因为毕竟供应链是自 20 世纪 70 年代末以来继会计之后最初实现数字化的公司职能之一。但是，定量供应链进一步向前推动了数字化。

有一点我们必须承认：在过去二十年间，时常发生被误导推广“未来的供应链系统”的情形。太多时候，此类系统除了给供应链招致浩劫之外别无任何作用，再加上黑匣子效应和自动化出错，因此生成了如此之多的糟糕决策，以至于无法再经人为介入来修复问题。

某种程度上，定量供应链正是从这些错误中诞生的：它不装作是系统以某种方式比其自身的管理层更了解企业，它的重点需要放在执行管理层所提出的洞察上，而是提供了更高程度的可靠性、透明度和灵活性。软件技术做的对就能赋予能力；但考虑到当前的软件能力，从解决方案中完全剔除人员是不现实的。

这样的志向有一个直接后果：公司跟踪其产品、材料和其他资源所采用的软件与公司需要优化决策的软件不同。此类软件可能是 ERP、WMS、MRP 或 OMS，所有这类软件主要侧重于运营公司的流程及其数据项目流。别误会我们：数据项流化和所有事务性工作自动化存在诸多好处。但是，我们的重点仍是这些任务一点也没有解决这一难题，即以贵公司的供应链所需的尺度提高贵公司执行人类洞察的能力。

不经衡量，就无所谓优化。顾名思义，定量供应链与衡量的关系非常大。供应链决策 – 购买存货、移动存货都会产生后果，此类决策的质量应从合理的商业视角进行“经济上”（例如按美元）的评估。但是，要想让可靠的指标起效果，需要投入巨大精力。定量供应链的目标之一就是帮助公司订立此类指标，这些指标在项目后期评估整个供应链计划的投资回报率 (ROI) 时也发挥重要作用。

最后，如前文所提到的，定量供应链并非包罗一切的典范。它的志向不在于修复或改善公司供应链中的所有方面。它也没有宣称能帮助您找到可以信赖的供应商或可靠的物流合作伙伴。它不会承诺帮助您雇佣优秀的团队和保持他们情绪高昂。但鉴于定量供应链非常独特的重点，因此实际上能够提供切实的成果。

项目角色

定量供应链需要的人力资源惊人地低，即便在处理大规模供应链时也是如此。但是，这样的计划的确需要特定的资源，接下来会在本节进行详细介绍。但在了解不同的角色及其特征前，我们要先提一下定量供应链的一个核心原则：公司应当把握每次人为介入。

这项原则与传统供应链解决方案中的做法是相背离的：解决方案会消耗人为工作，而不是把握人为工作。为了保持生成永不停歇的决策流，解决方案需要永不停歇的手工项目流。这些项目可能采取多种形式：调整季节性资料、处理异常和警告、修复奇怪的预测值等等。

定量供应链的视角与此相反。倒不是说人工昂贵，而是因为供应链技术结合敏锐的商业洞察太过珍稀宝贵，因此不能浪费在重复性的任务上。手工介入的根本原因应当予以解决：如果预测值中断，那么修改这些值本身就毫无意义了，需要解决的是输入数据或预测算法本身。解决症状才是永不停歇地解决相同问题的良方。

实施定量供应链计划所需的团队规模因供应链本身的规模而异。从少的方面来说，对于一个营业额低于 2000 万美元的公司，通常其团队规模可以少于一名 FTE（全职员工）。从多的方面来说，可以有十多个人；但在这种情况下，价值数十亿美元的存货通常会处于危险当中。

供应链领导者：定量供应链是对范式的变化。推动变更离不开最高管理部门的领导和支持。太多时候，供应链领导层认为没有时间直接涉足一个解决方案的“技术细节”。但是，定量供应链关系到大规模地执行战略洞察。不与负责该计划的团队分享战略洞察就是失败的原因所在。管理层不需提出所有相关的指标和 KPI – 因为这需要大量精力才能将这些整合起来，但是管理层肯定应当对这些指标和 KPI 提出质询。

供应链协调员：尽管定量供应链计划本身非常依赖于工作人员，但大部分供应链没有或者说根本没有这么依赖。如不将所有人带动起来可能会导致计划混乱和延缓。因此，协调员的使命就是收集所有必要的关于此计划的内部反馈，并传达给参与的各方。协调员要阐明所需进行的过程和所要做出的决策，并获取关于指标和 KPI 的反馈，以用于优化这些决策。他还要确保解决方案涵盖公司的工作流，同时保留在计划后期修订这些工作流的可能性。

数据官：定量供应链非常依赖于数据，每个计划都需要从批处理视角来可靠地访问数据。实际上，计划并不只是读取公司系统中的若干行而已，而是要读取整个销售历史记录、整个采购历史记录、整个产品目录等等。数据官通常由 IT 部门委派，其职责是支持该项计划。他负责所有数据提取逻辑的自动化，以及安排每天提取此逻辑。实际上，数据官的工作大部分集中在计划伊始时。

供应链科学家：供应链科学家采用技术（下文将详细介绍）来结合协调员收集到的洞察与数据官提取的数据，从而将生成决策的过程自动化。科学家刚开始是准备数据，这是一项异常艰难的工作，需要得到协调员的大力支持，此人需要与第一时间生成此数据的许多人互动，以明确任何不确定的地方。供应链科学家要正式指定战略，来用于生成决策 – 例如建议的再订货量。最后，供应链科学家还要为整个数据流水线配备仪表板和 KPI，以确保明确性、透明度和控制。

对于中等规模的公司，要同一人身兼协调员和数据官的职责可能会非常高效。但这要求具备多种技能，不易在单独一名员工身上具备。但是，如果公司中的确存在这样的人，那么他将会是加快计划速度的一项宝贵资产。而对于规模较大的公司，即便协调员在计划伊始时不太熟悉公司的数据库，如果他能够随着计划的推进而对数据库达到一定程度的熟悉，那也是极好的。IT 版图在不断变化，预计变化对于计划的影响对于确保持续顺利执行大有裨益。

技术

至此，我们仍对支持定量供应链所需的软件技术十分模糊。定量供应链严重依赖于用于实施定量供应链的技术堆栈。从概念上说，软件的每个部分可以从零开始重新实现，供应链科学家需要从其堆栈获取大量支持才能实现适当的生产性。诸如预测和数值优化等某些功能要求前期做大量研发工作，而这超越了供应链科学家在计划期内所能交付的范围。

定量供应链的第一个要求是具备编程能力的数据平台，自然而然，访问为处理供应链数据和供应链问题而量身定制的数据平台是一大优势。我们之所以提到数据平台，是因为虽然台式工作站如今虽然可以存储很多太字节，但并不表示这个台式工作站就能提供实施计划所需的其他任何特征：防范硬件故障的可靠性、所有访问的审计能力、与数据导出的兼容性等等。此外，由于供应链数据集往往较大，因此数据平台的扩展性应当更高，或者换言之，应当能够在短时间内处理大量数据。

数据平台要求具备编程能力，也即能够实现和执行大量任意数据的处理逻辑。此类能力通过一种编程语言来实现。编程被认为是一项技术性含量极高的技能，许多供应商利用必须应对解决方案需要“编程”这一念头的害怕心理，来向用户推送包含按钮和菜单的简单用户界面。但是，任何时候供应链团队的编程能力被否定，则可以改为使用 Excel 表，这正是因为 Excel 提供了编程功能，能够编写任意复杂度的公式。编程能力远非小配件，而是一项核心要求。

最后，为供应链量身定制数据平台有诸多好处。实际上，对某种数据平台的需要很难特定于供应链：由银行和基金执行的量化交易有着类似的需求。但是，供应链决策不像高频交易一样要求达到亚毫秒延迟。数据平台的设计关系到工程折衷以及软件生态系统，后者始于受支持的数据格式。这些工程折衷和软件生态系统应当顺应供应链挑战本身。

定量供应链的第二个要求是概率预测引擎。这部分的软件负责分配概率给未来每种可能的情形。尽管此类预测起初有点令人混乱，因为它与对未来预测的直觉是相背离的， “捕获”的可能性实际上蕴藏在不确定性当中：未来是不确定的，单独一种预测肯定是错误的。传统预测视角否定不确定性和变化性的存在，因此，公司最终陷入被认为准确其实非也的预测当中。概率预测引擎通过解决概率问题，直面这一问题。

供应链中的概率预测通常分为 2 个阶段，先是预测交付周期，接着预测需求。交付周期预测是一种概率预测：即为所有可能的交付周期持续时间分配一种概率，通常按天表示。需求预测同样属于概率预测，这种预测建立在作为输入提供的交付周期预测的基础上。实际上，需求预测所涵盖的范围必须与本身不确定的交付周期相一致。

由于概率预测引擎提供了成组的概率分布，相较于传统预测引擎的输出，其预测输出涉及到更多的数据。这本身并非妨碍性的问题，但为了避免在处理大量概率时面临太多摩擦，所以需要在数据平台与预测引擎之间进行高度协作。

项目阶段

定量供应链深受软件工程研发和数据科学最佳作法的启发。这种方法高度迭代，不强调之前的规范，而是强调从异常问题和/或异常结果恢复的灵活性和能力。因此，这种方法容易让未深植于软件行业本身的公司感到相当惊讶。

第一阶段是确定范畴阶段，即定义计划所要涵盖的供应链决策。在这个阶段也要诊断决策过程中涉及的预期复杂度和相关数据。

第二阶段是数据准备阶段，包括确定自动化准备，将所有相关数据从公司系统拷贝到独立的分析平台，以及准备此数据用于定量分析。

第三阶段是试行阶段，包括实现初始决策逻辑以生成决策，例如建议的采购量，这一点本身就已超越了公司以前流程的表现。此逻辑预计将实现完全自动化。

第四阶段是生产阶段，包括带动计划以正常速度执行，并监控和维持绩效，并针对供应链模式本身合乎需要的改进程度来达成共识。

确定范畴阶段最为简单直接，包括识别定量供应链计划要涵盖的日常决策。这些决策可能涉及多种限制：MOQ（最小订单量）、装满集装箱、最大仓库容量等等，应密切审视这些限制。决策也与这些经济驱动因素相关联：仓储成本、缺货成本、毛利润等等，这些经济驱动因素也应当进行研究。最后，还要一并对相关历史数据以及提取这些数据的系统进行识别。

数据准备阶段是最难的阶段，大部分问题出现在这一阶段。实际上，获取对数据的访问以及理清数据的意义几乎总是一道被低估的难题。运营系统（例如 ERP / MRP / WMS / OMS）的宗旨是运营公司，保持公司运作。历史数据是此类系统的副产物，因为所记录的数据并非起初实施这些系统的原因所在。因此可以预见在此阶段会碰到许多困难。令人遗憾的是，在面对困难时，大部分公司会选择习惯性思维：后退一步，写下完整的规范。但不幸的是，一种规范只能涵盖已知或预期的难题。但是，在此阶段遇到的几乎所有主要问题都是不能规划的元素。

实际上，当有人真的开始使用数据进行生成数据驱动型决策的测试时，问题通常才会暴露出来。如果逻辑合情合理时决策出错，那么问题可能出在数据上。数据驱动型决策对数据问题十分敏感，因此这对于质疑公司对自身数据控制程度是一种很好的方式。另外，这个过程质疑数据的方式对公司也很有意义。数据质量和对数据的了解只意味着一种结果：为公司创造有价值的事务。将精力放到对数据驱动型决策有重要影响的数据问题上是非常合理的。

试点阶段是指将供应链管理付诸测试的阶段。通过概率预测纳入不确定性是相当反直观的。同时，许多传统做法，譬如每周或每月预测、安全库存、存货保证期、存货警告或 ABC 分析其实弊大于利。这并不意味着定量供应链计划应当松散地进行。其实完全相反，因为定量供应链完全关乎于可以衡量的绩效。但是，许多传统供应链作法在框定问题时，倾向于以不利于解决相关问题的方式来进行。因此，在试点阶段，供应链领导层的一大关键挑战就是开放思想，不要往计划中注入导致后续阶段效率低下的元素。你不能在怪罪结果的同时却对原因置之不提。

之后，供应链科学家和技术也都会投入测试中，前提是必须实施一种逻辑，从而在相对较短的时间内生成决策。最初的目标只是生成从业者认为合理的决策，这些决策完全不需要手工修正。我们建议不要低估生成“合情合理”的自动化决策的难度。传统供应链系统需要进行大量手动修正才能运作：新产品、促销、缺货……定量供应链确立了一条新原则：不允许在平常的操作中进行手工录入，所有因素都应当内置在逻辑中。

供应链协调员将收集应当整合到决策逻辑中的所有因素、工作流和特征。接下来，供应链科学家实施与决策相关的第一批 KPI。引入这些 KPI 的目的是避免使用高级数字法时出现黑匣子效应。KPI 是与确保测量结果契合公司战略的供应链领导者共同制定的，注意到这一点很重要。

生产阶段将保持计划稳定并以正常速度运作。由逻辑生成的决策会被活跃使用，相关结果会受到密切监控。由于涉及到交付周期，因此通常需要几周到几个月的时间来评估任何特定供应链决策所产生的影响。基于此，在生产阶段计划本身的变化速度会减慢，这样就可以可靠地评估自动生成的决策的绩效。计划将进入持续改善阶段。尽管进一步的改善总是合乎需要的，但必须在逻辑改进所带来的效益与这些改进的相应复杂度之间达到平衡，才能维系整个解决方案。

供应链协调员现在不参与平常的数据录入工作，而是专注于供应链管理层提出的战略洞察。在试点阶段确定的合乎需要的供应链过程变更通常会暂缓，目的是避免因同时进行所有变更而导致运营中断。但是，既然决策逻辑的变更速度放慢，就可以逐步修正流程，以便实现绩效提升，而这需要具备更好的日常决策。

供应链科学对 KPI 和数据质量的重视度越来越高，由此可以保持不断细调逻辑。他还要负责修正逻辑，因为细微的缺陷或限制（通常与不常见的情形有关）会随着时间的变化而暴露出来。随着流程的变化，决策逻辑也会加以修正，以便保持完全契合工作流和战略。另外，即便内部流程没有变化，总之一般 IT 和商业形势是保持不断变化的：供应链科学家必须确保行情不断变化时，将决策逻辑保持在最新状态。