我在SAP担任的售前人员提供了各种有趣的客户服务，正如我之前在本博客频道上所分享的，在最佳情况下，我们和我们的客户都能学到东西。

在最近的一次经历中，世界人工智能，我带领一个团队使用一个客户提供的数据集。

我们不总是这样做，甚至不经常这样做。需要一个双赢的结果来证明相互投资的合理性。

在这种情况下，我们有一个客户经理，有着丰富的需求规划经验，但刚加入公司时，他经历了这一点，足以让他有点"证明它"，还有几个新的团队成员在我们这边，我希望能够进入我们的工具的细节。所以我们同意。

通过工作过程中强调了一些关键的价值驱动IBP，并提供了一些教训…在这篇文章中，我将分享这两个。

配置和数据加载：

这是一个自定义演示，而不是一个概念证明（POC）。我专业地关注差异，这对我来说意味着对现有SAP样本规划领域没有重大变化，对供应链结构也没有重大变化（如果IBP for supply在范围内）。在本例中，我们发现样本计划区域SAP3（库存优化）提供了所需的主数据结构。了解提供的数据。在我们准备和演示的时间有限的情况下，这一点至关重要。我们的输入数据集包括MS Access数据库中包含的超过25K个活动项目的详细装运记录。我们很幸运，团队中有一位具有可靠访问技能的同事，他能够在加载之前定义连接以验证数据，这是非常宝贵的，尽管提供的数据"相当不错"。他还从Access数据中创建了相关的.csv文件进行加载。与几乎所有的演示和大多数早期实现一样，我们使用IBP中的数据集成过程来加载数据。了解你的时间安排。在本例中，我们利用了已经为SAP3定义的Technical Week构造，但是使用了一个新的时间序列概要文件。技术周允许对日历月进行适当的汇总，同时允许在日历周级别进行计算和报告。这在需求规划中至关重要。确保你的计划水平正确。我在书中和其他博客文章中都注意到了这一点。幸运的是，这不是一个问题，因为SAP3中的结构正好符合我们的需要。这是很重要的一点–SAP在标准样本规划领域投入了大量工作，对于初始阶段，大数据和数据分析区别，如果没有全面实施，几乎所有的努力都可以利用这里完成的工作。不要试图存储每日数据。一开始，我是这样做的。如果你读过我以前的博客，你就会知道"早早失败，经常失败"是我的信条之一。我有同事会说"准备，开火，瞄准"是另一种说法，特别是在这样的项目中。但是我知道用IBP重新开始是多么简单，所以我觉得不需要一个完全详细的计划。把以前的顾问逼疯了。在本例中，我最初认为在提供的每日级别上存储历史记录并让IBP/Hana聚合是很有趣的。是的，效果不错。但在小型服务器上（我们的演示系统配置的配置比最小的客户实例小得多），这被证明是个坏主意。我发现我需要将预测运行范围限定到数据的一个子集，即使这样，性能也不是我想要的。当然，让我们好好想想。我仍然可以在不到30分钟的时间里预测出数百个零件和数百万个数据点。但关键的经验教训是：如果您没有配置需求感知（我们没有配置），云服务器怎么用，则让加载过程将每日数据聚合到技术周。

初始过程

我们首先做的事情之一是对提供的数据进行A-B-C分析。IBP配置和实现ABC的能力对理解数据的范围有很大的帮助。我们得到的数据集包括有规律需求的项目（包括趋势性和季节性）和有间歇性需求的许多项目。虽然可以在包含所有算法的数据集上建立一个最佳拟合模型，然后让模型计算出来，但我们希望测试各种参数，因此寻求使用不同的模型来满足间歇和连续需求。ABC分类提供了一个工具，使我们能够定义一个KF来测试任何特定单元格中是否存在需求，并设置一个0/1值。然后，我们添加了一个item master属性（间歇标志），并使用计数器键数字作为输入来运行ABC进程。结果为运行预测模型提供了一个过滤器。作为参考，人工智能工作，以下是计算结果：

我们还想测试不同粒度级别的预测值-产品/位置，或产品/客户（本例中为集团）/位置。IBP能够很好地处理任何问题，聚合级别是在执行时指定的。因此，我们创建了一个版本来存储一组预测和预测错误结果，作为与基线（产品/位置/客户组）进行比较的备选方案（产品/位置）。正如预期的那样，我们发现——一般来说——更高水平的聚合产生了更好的结果。有经验的读者会发现聚合方法存在一个问题。如果我们在产品/位置级别进行预测，由于没有一组现有值，IBP将在平等分布的基础上分解为客户群级别。这是错误的。因此，我们创建了一个新的KF，使用复制操作符将装运历史向前移动一年（1/16-1/17…），并使用此新KF作为分解到客户组级别的基础。与此同时，一位同事正在加载IBP库存所需的主数据。当然，由于我们利用了相同的基本主数据，返利购，所以只需要一小部分额外的数据。因此，一旦我们有了一个基本的预测锥，我们就可以使用Copy操作符来加载IO需求和变化关键数据，并启用了库存计划。

结果