首页 »
知识库 » 此处
作者：Joannes Vermorel，2016 年 11 月Lokad 在处理任何新供应链优化项目时，80% 的精力放在
数据准备上面。数据准备，有时也称为
数据整理、
数据清理或
数据预处理。但即便是经验丰富的供应链专家，也鲜有理解需要投入如此之多精力这一点。根据我们自身的观察，数据方面的问题可能是从生鲜食品到航空航天的各行各业几乎所有垂直市场中导致供应链优化出现问题的第一大原因。本页面向供应链从业者和企业高管之类的人士，旨在帮助他们深入洞察欠缺了解但对于实现成果非常关键的方面。
惊人的失误率
供应链优化项目经常失误。根据 Lokad 客户群提供的一些事件，在大部分垂直市场中，由软件驱动的供应链优化计划的失误率可能超过 80%。但很少有供应商会承认失误对于其客户而言是一种“正常”的结果（参阅
预测供应商的十大谎言)）。
关于现代供应链的一种谬论是：将仓库存货从一个大洲搬到另一个大洲的风险，比将仓库数据从一台计算机移到相距仅一米远的另一台计算机的风险要低。
而当出现问题的时候，客户和供应商都缺乏动力去揭露原因。
因此，绝大部分失误被巧妙的忽略，不再提及。
但时不时地，有些失误太大以至于上了新闻：
尽管此类失误并不只有一种解释，但每次都是数据出了很大的问题，得到的供应链决策最终异常糟糕。
但通常来说失误的后果不会太轰动。供应链从业者倾向于对据称更好的新供应商系统提供的数据持适当的不信任态度，坚持用旧式但却出色的 Excel 表，数月过后，系统关闭。尽管没有对企业造成严重的损害，但浪费了时间和精力。
了解数据的意义很艰巨
历史业务数据错综复杂。这些方面相当反直观，因此容易使人误解。根据我们的经验，这种误解可能是供应链计划中频繁遭遇数据灾难的关键根本原因之一。
来看一个简单的销售历史记录的例子：有一个表列出了每种产品在过去几年内每天的销售量。这个销售历史记录按理应当能够表明该公司的经营状况。
但情况并非如此，因为：
- 历史记录可能包含捆绑包，即一种产品捆绑其他产品，因此在业务增长时数量可能会下降。
- 历史记录可能包含收益，可能占据了销售额中的很大一部分，因此业务可能看似增长，实则下滑，因为收益在快速变化。
- 历史记录可能包含促销，为了清理库存，可能会牺牲利润，并且产生的需求不代表全价商品的需求。
其次，在我们提到与特定日期相关的
每天数量时，日期本身便带有诸多不确定性。此日期可能表示下列日期：
- 客户下单之日
- 客户确认预订之日
- 产品发货给客户之日
- 订单条目最终录入 ERP 之日
- 订单条目在 ERP 中最后修改之日
- 收到客户付款之日
- 等等
每个变体都是正确的，但每种变体对业务也存在自身的扭曲。但太多时候，我们很容易这样想：这只不过是一个
普通的时间久远的销售历史记录而已。但在涉及历史销售时，（几乎）没有哪一项是
普通的。
此外，如果这样的扭曲结合在一起，那么产生的影响就会呈指数级放大。没有什么比高估销售同时低估库存量而导致库存过剩的危害更大了。
根据经验，Lokad 经常会发现，好的数据文件往往会在每个表中的每一列写上几乎一页的说明。但幸运的是，在项目初期时，我们只需处理每列（每个数据栏）的 1 行描述。
但即便有数据文件存在，也常常完全不得要领。OrderDate 列包含日期，这一点毫无疑问。另外一个名称为
StatusCode 的列包含简短的代码列表，这也毫无疑问。大部分技术文件侧重于 IT 方面，完全摒弃了所有业务问题。而从优化角度来说，这些方面正是最关注的方面。
在计算机科学领域有句古话：“无用输入，无用输出”。如果输入数据没有意义，结果也没有意义。因此，在 Lokad 接管任何供应链计划时，分解数据并记录所有结论是一个关键的目标。我们的大部分客户在审视我们客户的系统、数据和流程时，都会惊讶于 Lokad 生成的文件量之大。但我们的经验表明，我们一次也没有因为文件量太大而感到后悔过。
两种数据准备不可能完全相同
我们回答得最多的问题之一就是：
Lokad 兼容XYZ 吗？ 如果简单一点回答，我们的答案就是
是的；如果详细一点回答，答案就是
是的，但要付出若干努力。数据移动相当简单：FTP（文件传输协议）已存在数十年之久，即便是网速适中的网络连接，也可以移动大量数据。但是，Lokad 真正的挑战在于完全了解所提供数据的意义。公司并不会轻易的就懂得他们的 IT 系统真正有多灵活。尽管在其从业者看来公司系统看似坚如磐石，其实鲜少是这样的。
当然，软件供应商数十年来一直在灵活性功能方面进行竞争，但真正将工作流整合到单独一种途径的解决方案少之又少。大部分解决方案提供了无数种不同的途径来实现相同的结果，因此，即便数据源自同一个软件，数据准备也很少能保持相同。实际上，数据准备高度依赖于公司已在实施的作法和工作流，而相同的数据记录无法在两个不同的公司以完全相同的方式解读。这样的差异最初可能看似轻微，但从供应链优化角度来看，它们常常会导致优化逻辑和实际业务需求之间明显失准。
定性优化也离不开数据准备
关于计算机，好的是它们会按你的指令操作，
坏的也是它们会按你的指令操作。 Ted Nelson
大部分企业高管都会理所当然地相信他们的团队会贯彻业务战略，即便战略尚未成型甚至尚未撰写。但是，定性优化没有为隐含的目标留空间：输入数据生成的数据完全反映了已实施的数字框架。因此，定性优化解决方案产生的初始结果可能会令人迷惑不解：探明了许多方面，但很大程度上也忽略了其他许多方面。
由于起初很少指明了确切的业务目标，因此常常是利用定性优化给出的最初结果来了解缺失的方面。这些缺失的方面可能是：
- 某些客户为 VIP，需要提供高得多的服务水平
- 某些产品处于过时的边缘，承担着更大的库存风险
- 某些供应商拥有 SKU 的 MOQ，也拥有每个订单的 MOQ
- 某些仓库近乎满了，需要减小再订货
- 等等
解决此类挑战要求具备其他数据，而公司一般也开始意识到，相关数据也许除了可以从公司到处散布的众多 Excel 表中找到，别无其他地方可以找到。但 Excel 表本身也往往并未受到特别的重视，许多归档在电子邮箱中。
因此，不仅交易数据（例如从 ERP 提取的数据）需要进行准备，所有塑造业务战略的高级数据同样需要处理。但雪上加霜的是，高级数据往往也更难准备。当然，与交易数据不同的是，目前来说通常只需要稍加处理便可保持此类数据在公司范围内完全一致。因此，在开始处理这类数据时，很少会意识到公司的高级业务战略一部分可能对某些边缘案例行不通。
要想统合优化逻辑和业务，最直截了当的方法通常就是以欧元或美元（或其他任何相关货币）重新表示所有项目。这并不是因为从财务立场看待事物的某些固有的优越性，而纯粹是因为它们是在一个公司的各个团队之间只需略微协调或无需协调即可保持一致的计数单位。实际上，如果公司已习惯于处理非财务指标，那么这种财务观点容易导致摩擦；或者更糟糕的情况是，导致根本无法处理任何指标。
文件再多也不为过
所有出色的数据准备的秘诀就是有好的文件。这个秘诀很简单，但几乎总是作为非紧急和不重要的任务而被忽略或忽视。但根据 Lokad 的经验，理想的数据文件既紧急又重要。
具体而言，文件需要回答每个数据源的问题，甚至回答每个数据栏的问题。记录数据的意图对于确保后续正确处理此数据非常关键。当文件实际上并不存在时，往往可能其意图只是解释字段名称的意义。
不好的文件示例
ORDERS.DATE：日期关联订单行。
较好的文件示例
ORDERS.DATE：客户首先表现出购买此商品意图的日期；表示核心需求信号。此日期可与
ORDERS.DELIVERYDATE 相比较，来从客户角度评估初始订货和交货之间经历的时间。
记录输入数据不宜视为 IT 要素，而应当视为业务相关的资产。不论为 IT 部门提供怎样的激励和支持，IT 团队通常不会进行深入了解数据所需的业务洞察。
鉴于所有这些因素，当 Lokad 在处理任何新客户计划时，我们倾向于在早期花时间编写文件；每次与客户（由他们向我们提供对其业务知识所需的洞察）对话后，通常一次只编写若干位。这个过程所提供的价值起初一般不太明显，因为开始时其他方面看似更紧迫。但过去数周后，一些与数据有关的微妙细节被淡忘，编写的文件成为避免再次发生相同问题的唯一途径。