APO的全面进化之路（1）：走向S4HANA

而众所周知， APO 这一产品从诞生到如今的几十年间，随着整个 IT 技术的不断发展，更随着 SAP 对 APO 全系产品的重新定位以及在 SCP 领域的不断投资， SAP 不断地推陈出新，诞生了更多全新的、功能也更强大更合时宜的产品，例如基于云平台的 IBP 、 S4HANA 等等。

那么，对于“古老”的 APO 产品，它的各个模块的进化之路是怎样的呢？传统的 APO 与全新的 IBP 、 S4HANA 有何关系？产品迭代对产品架构、数据结构、业务模式甚至操作习惯有何改变？ …

本篇将完全从 个人 在 APO 领域里对包括 APO-DP 、 SNP 、 PPDS 、 GATP 的实际应用的角度阐述个人对这些问题的总结与思考。

限于篇幅，本篇将主要聚焦于 APO 向 S4HANA 的进化之路，而 APO 向 IBP 的进化之路将于后期再进行总结。

同时，需要说明的是，本篇以及本公众号里的观点与思考，都只是个人的经验总结与个人观点，如有错误或纰漏，还望提醒与见谅。

APO - DP

SAP APO-DP （ Demand Planning ）是 APO 中聚焦于需求预测与需求管理的技术模块，从业务上而言，它的输入是预测基础数据例如销售历史数据、其他部门输入等，输出则是最终需要达成共识的预测数据。

它的特点主要有：

• APO-DP 以 BW 数据仓库（ Data Warehouse ）为数据结构技术基础，通过计划区域（ PA ： Planning Area ）及计划对象（ POS ： Planning Object Structure ）来管理基于特征值组合（ CVC ： Characteristics-Value-Combination ）的时间序列数据（ Time-Series data ），依据历史数据与多种预测算法，支持按产品、产品组、客户、区域等各种预测的业务层级，以及促销、残值、生命周期等多种业务场景的需求管理；

• APO-DP 内嵌多种数学层面的预测算法，包括统计学、线性、非线性的需求预测模型；

• APO-DP 无缝集成 APO 其他模块例如直接将预测结果释放到 APO-SNP 、 PPDS 做为其功能的输入，以及 SAP ERP 例如 ECC 形成独立需求 / 预测。

举一个简单的实例来进行简单阐述。

例如如下的初始预测数据，使用统计学预测：

通过不同的算法，比如这里选择的是线性回归算法（ Linear Regression ），对历史数据基于季节性及趋势性模型来进行未来预测：

结果可以看到，预测数据将按设定的模式进行更新：

同时在 DP 里，每一次的需求预测运算都将进行计算本次预测“质量”，例如 MAPE 、 MSE 等评价指标，供用户知晓本次的预测是否满足个人或组织预期。

当然以上仅仅只是一个非常简单的实例，实际上 DP 还有非常多的其他实用功能，例如 PIPO （ Phase In Phase Out ）、促销（ Promotion ）、聚合（ Aggregate ）、分解（ Dis-aggregate ）等等。

整体上而言， DP 是一个功能非常强大的需求预测与需求管理工具，同时其与其他 SAP 产品在原生性上的一脉相承，所以市场上有很多企业就已先前部署使用，例如宝洁（ P&G ）很早年前就已使用 DP 来管理其销售预测数据。

但从上面的实例上也可以看得出来， DP 仅仅作为一个需求预测的工具，从技术上的整体架构、数据结构基础到业务上的数据管理、用户操作上来说， DP 都是一个“非常重”的软件工具，在日常的应用中不可避免地稍显“笨拙”，主要体现在历史数据及预测数据的管理上的不如如今各种工具例如 EXCEL 、云等平台上的那么高效及有序，以及功能应用上对终端用户的也不那么友好及便捷。

那么， APO-DP 的进化呢？

步于新时代， SAP 推出了基于云平台的全新 IBP-Demand （ Integrated Business Planning, for Demand ）已经可以全面取代并超越 APO-DP 。 本文聚焦 S4HANA ，不进行过多的 IBP 的阐述，后续再集中阐述 IBP 。

所以， APO-DP 的进化，以此图做结：

APO - SNP

SAP APO SNP （ Supply Network Planning ）是 APO 中聚焦于供应网络的中长期做供应计划的技术模块，功能上它主要包括计划 Planning 及分配 Deployment ，从业务上而言，它的输入是在供应网络上的各级节点上的需求元素例如终端 Customer 、 Retailer 等的预测数据、真实销售订单以及 DC 或工厂里的备库、销售等各类需求，它的输出则是在整个供应网络上对需求元素的补货元素例如不同 DC 间的调拨请求（ Stock-Transfer-Requisition ）、从外部供应商或委外供应商的购买请求（ Purchasing Requisition ），以及生产工厂里的体现为粗产能 RCCP （ Rough Cut Capacity Planning ）或者真实产能 RCP （ Resource Capacity Planning ）的排产订单（ Planned Order ）。

它的特点主要有：

• APO-SNP 主要完成中长期的供应计划即 Planning ，跨工厂、跨 BOM 层级，产生采购（主要是调拨）计划与 Bucket 最小到天的产能计划下的生产计划；

• APO-SNP 还可以完成调拨分配即 Deployment ，完成对计划结果即供应的分配与调拨；

• APO-SNP 提供 Heuristics 启发式、 Optimizer 优化器、 CTM 能力匹配等多种算法及模型来完成基于供应网络的供应计划；

• APO-SNP 无缝集成 APO 其他模块例如将 APO-SNP 的计划结果释放转变为 APO-PPDS 供进一步调度，以及 SAP ERP 例如 ECC 形成调拨、采购等申请订单；

从技术上来说，  APO 标准的 SNP 同 DP 一样，也是以 BW 数据仓库（ Data Warehouse ）为数据结构的技术基础，通过计划区域（ PA ： Planning Area ）及计划对象（ POS ： Planning Object Structure ）来管理数据，不过与 DP 不一样的地方在于， SNP 还可以直接访问并处理系统中的订单数据而不仅仅是在时间序列上的数据，同时除了常规的 SNP 功能之外，还包括 CTM （ Capable-to-Match 能力匹配）模块，更是可以在订单层级的计划应用，所以在 SNP 里，除了管理时间序列（ Time-series ）更还有订单层级（ Order-based ）的数据。

以下将分 3 部分来阐述 APO-SNP 的进化之路，分别为 SNP-Heuristics ， SNP-Optimizer 以及 SNP-CTM 。

（ 1 ） APO-SNP-Heuristics 进化

举一个简单的实例来进行简单阐述 SNP Heuristics 。

例如如下的 SNP 初始数据：

经过 SNP Heuristics ：

或者从计划薄中执行，得到最终的供应计划结果：

可以看出， SNP-Heuristics 作为最“直接”也是最“简单”的供应工具，也即最常所言的“ MRP-Based ”的供应计划工具，它的特点在于其通过“启发式”的数学算法对“需求元素”（ Demand ），“启发性质”地在整个供应网络（ Supply Network ）及 BOM 层级上逐级、逐层地寻找及产生“供应元素”（ Supply/Receipt ），要么调拨、要么外购（含委外）、要么自制，同时对于自制，还可以再进一步结合粗能力做能力平衡（ Capacity Leveling ），最终确保 Heuristics 的计划结果是合理的。

以上仅仅只是一个非常简单的实例， SNP-Heuristics 作为 APO 中供应网络级别的 MRP ，其整体上提供了非常方便也非常直观的计划过程，在实际应用中，具有非常多的应用案例，例如其作为需求传递的工具，将需求或供给沿导运输路径进行传导也即常说的 Demand/Supply Propagation ，在实际客户上，同样例如宝洁（ P&G ）很早年前即使用 SNP-Heuristics 来完成其 DRP （ Distribution Requirement Planning ）中的计划 Planning 过程。

那么， APO-SNP-Heuristics 的进化呢？

但是同 DP 一样，随着 SAP 对 APO 全系产品的定位，以及新产品新技术的推陈出新， SNP-Heuristics 也已全面进化，基于云平台的全新 IBP-Supply and Response （ Integrated Business Planning, for Supply and Response ）中的 Heuristics 也已经可以全面取代并超越 SNP-Heuristics 。 同上面阐述 DP 进化一样，后续再对 IBP 进行详细的阐述。

所以， APO-SNP-Heuristics 的进化，以此图做结：

（ 2 ） APO-SNP-Optimizer 进化

举一个简单的实例来进行简单阐述 SNP Optimizer 。

例如如下的 SNP 初始数据：

经过 SNP Optimizer ：

或者从计划薄中执行 Optimizer ，得到最终的供应计划结果：

当然以上是一个很简单的标准的 SNP Optimizer 的过程，实际上 SNP Optimizer 作为使用线性规划 LP/MILP 算法（ Linear/Mixed-integer Linear algorism ）来求解当今数学王冠上其中一种最复杂也是最经典的计划领域的最优解，其功能和复杂性也是 SAP 各类计划工具中的典型，从而从“产能 + 物料”两方面都能满足的情况下去满足需求。在实际项目上我们可能会依据客户需求的不同，对 SNP 标准的 Optimizer 进行大量的修正与增强，以使其功能更加强大。所以，包括诸如晶科能源等在内的很多优秀企业都在使用 SNP Optimizer 。

那么， APO-SNP-Optimizer 的进化呢？

同 SNP-Heuristics 一样，由于 APO 的定位，独立的 SNP-Optimizer 将会进化到新产品、新技术，但是与 DP 与 SNP-Heuristics 不同， SNP-Optimizer 将会有 2 条路进行进化：一条依然是走向云平台的 IBP ，一条是走向 S4HANA （无论是 On P 还是 On Cloud ）。 IBP 中主要是 Response and Supply 中的 Optimizer ，后续在 IBP 中再细说阐述；

而 S4 中，则是新一代的生产计划优化 PPO （ Production Planning Optimizer ）。

在 S4HANA 中通过运行 PPO ，可以看到， PPO 几乎就是 SNP-Optimizer 的“翻版”：

虽然 Optimizer 的引擎以及 Log 等都几乎一致，但是，也可以看到由于 PPO 大大简化了 SNP-Optimizer 的类似于 time-series 的数据结构（比如计划薄 Planning book ），即直接使用 S4 里 APO LiveCache 数据，所以从数据抓取、数据准备，以及最终计划结果创建的过程均有很大的技术差异。

但是作为业务用户，从前台操作以及计划结果解析， PPO 完美地继承并改进原先独立的 SNP-Optimizer 。

所以， APO-SNP-Optimizer 的进化，以此图做结：

（ 3 ） APO-SNP-CTM 进化

举一个简单的实例来进行简单阐述 CTM 。

例如如下的 CTM 初始数据：

经过 CTM 的运行，

计划结果：

当然以上是一个很简单的标准的 SNP-CTM 的过程， CTM 是真正的以“单个需求”为“导向”的深度 N 型搜索策略（当然也可通过配置或多次 Run 实现 Z 型），

所以 CTM 对于像在 Hi-Tech 此类行业里以具体的订单的需求在“产能 + 物料”两方面都同时满足为首要目的的排产应用是非常适合的，包括联想、浪潮等在内的众多优秀企业均在使用 CTM 作为其主计划的首选工具。

那么， APO-SNP-CTM 的进化呢？

同前面几个产品一样，由于 APO 的定位，独立的 SNP-CTM 将会进化到新产品、新技术，但是与 SNP-Optimizer 具有 2 条路的进化不同，在新的 S4HANA 中 CTM 是没有进行内嵌或部署， SNP-CTM 从本质上来说，其目前的进化之路同 DP 是一样的，即走向云平台的 IBP Response and Supply 中的 Priority-based Heuristics ，但是二者之间依然存在非常多的差异，所以可以用“部分进化”。 IBP 的内容，后续在 IBP 中再细说阐述。

所以， APO-SNP-CTM 的进化，以此图做结：

APO - PPDS

SAP APO PPDS （ Production Planning and Detailed Scheduling ）是 APO 中聚焦于单工厂下的基于产能、工艺要求的详细排程与调度的技术模块，从功能上主要包括计划 PP 与调度 DS ，从业务上而言， PP 类似于前面 SNP 一样，它的输入是在特定制造工厂上的需求元素（例如销售订单、预测、调拨需求等），它的输出则是考虑或不考虑各类约束条件的 MRP 计划结果（例如计划订单）；而 DS 它的输入则是计划端例如前面的 PPDS-PP 或 SNP 或 ERP 中的 PP 所产生的计划结果（例如计划订单，生产订单等），输出则是考虑了调度约束条件 (Schedule Constraint) 的调过序的计划结果。

它的特点主要有：

• APO-PPDS ，支持离散制造、重复制造、流程制造等各业务形态下的生产计划排产，提供到工厂级、车间级、线体级甚至工位级以及时间上分秒级的生产计划与排序；

• APO-PPDS 提供 Heuristics 启发式、 PPDS Optimizer 优先器遗传算法等多种优秀的算法及模型，支持订单排序、订单调度、有限无限产能、订单关系、工序关系、换模切换、线体布局网络等多种生产排产限制因素；

APO-PPDS 无缝集成 APO 其他模块例如 GATP 做 CTP （ Capable-to-promise ），以及 SAP ERP 例如 ECC 形成生产订单开始生产执行。

从技术上来说，  PPDS 与 DP 、 SNP 在技术架构上不再一样，它脱离了基于 CVC 的时间序列（ Time-series ）数据，而是直接使用 LiveCache 的 order-based 的订单数据。

举一个简单的实例来进行简单阐述 PPDS 。

在运行 PPDS 前的初始数据，

运行 PPDS 的 PP-Heuristics ：

产生生产计划 MRP 结果：

但是可以看出此种初始的生产计划还是很“混乱”，比如没有考虑产能约束：

做 PPDS-DS 的调度 Heuristics ：

最终生产计划结果调度为：

此时便不再有超产能。

当然以上是一个非常简单的介绍 PPDS 的例子，实际上 PPDS 在详细排程与计划调度上具有相当多的功能，在本公众号中，记录了大量的 APO-PPDS 的应用场景、技术实现等，可以知晓 PPDS 作为在 PC 领域中最精细的高级排产工具，在包括 Auto 汽车、 IMC 装配制造、 Chemical 化工等各行业中具有广泛的客户及应用。

那么， APO-PPDS 的进化呢？

同前面几个产品一样，由于 APO 的定位，独立的 PPDS 将会进化到新产品、新技术，但是与 SNP-Optimizer 具有 2 条路的进化不同， PPDS 其进化之路目前主要体现在 S4HANA 中的内嵌 PPDS （ embedded-PPDS ）。

在 S4HANA 中， ePPDS 的功能几乎就是 PPDS 的完整 COPY 版本，甚至包括 PPDS 的一些行业解决方案包，例如 Auto 行业的 IS-AUTO 解决方案，除了一些细微的技术点、以及 S4HANA 对功能的调整的差异外，从技术架构、数据结构、前台操作，甚至可以认为在 S4HANA 一套系统中就是以 ERP-CORE 与 APO-CORE 这两套“系统”来构架，所以此处的“ APO-CORE ”里的 ePPDS 就几乎是 Standalone 的 APO-PPDS 。 当然在 S4HANA 下， ePPDS 提供了更多的访问或处理工具，例如 Fiori 端的 PPDS 相关 App 。

所以， APO-PPDS 的进化，以此图做结：

APO - GATP

SAP-APO-GATP （ Global Availability-to-promise ）是 APO 中聚焦于可以产生需求的订单元素（例如成品层级的销售订单、交货单、调拨单，半成品或原材料层级的其上层计划订单、生产订单等）的物料可用量及可承诺量的检查并对相应的订单进行承诺的技术模块，从业务上而言， GATP 类似于前面 SNP 、 PPDS 一样，它的输入是在各类需求元素（不仅限于成，它的输出则是考虑了各种可用性检查规则后的物料可用量对需求订单的承诺（例如对销售订单的交货行 Schedule Line 的处理）。

它的特点主要有：

• APO-GATP 提供最全面的物料可用性检查，可跨工厂、跨物料地对订单需求进行检查、可用性满足；

• APO-GATP 提供包括物料可用性检查、物料分配、依据规则 Rule-based 的可用性检查、对生产能力的响应 CTP 、全 BOM 层级 Multi-level  ATP 的多层物料检查与确认，并可直接集成生产模块，产生生产计划；

• APO-GATP 提供可以按各业务需求灵活改变的 BOP （ Back-order processing ）操作，从而对订单承诺进行灵活的重计划、重确认；

• APO-GATP 无缝集成 APO 其他模块例如 APO-PPDS ，以及 SAP ERP 例如 ECC-SD 或 PP 模块的订单承诺。

从技术上来说，  GATP 从基础数据来说，其同 PPDS 一样是直接使用 LiveCache 里的 Order-based 订单数据，但是 GATP 中的部分功能，例如可用性检查的聚合及数据保存、 PAL 功能等依然也会使用基于时间序列 Time-series 的数据。

由于 GATP 提供了很多的可用性检查工具，如 PAC （ Product-Availability-Check ）、 PAL （ Product-Allocation ）、 RBA （ Rule-Based-Availability ）、 CTP （ Capable-to-promise ）、 MATP （ Multi-level ATP Tree ）等，每一项都有很多的应用场景。

限于篇幅，本篇就只举在实际项目中应用的最多的 PAL （ Production Allocation ）为例。

GATP-PAL 主数据：

比如是 30 的需求数量，做可用性检查：

- 那么确认数量即为 30

如果是 80 的需求数量，做可用性检查：

- 那么确认数量将以上面 PAL 分配的数量为基准

以上是一个很简单的 APO-GATP 的过程，正如上面所说，实际上 GATP 内具有相当多的功能强大的可用性检查功能，合理地组合应用，以及在实际项目中经常所做的各类增强调整后， GATP 在可用性检查方面能够很好地满足各类业务场景应用。所以，包括诸如宝洁（ P&G ）等在内的很多优秀企业也都在使用 GATP 。

那么， APO-GATP 的进化呢？

同上述 APO 其他产品一样，由于 APO 的定位，独立的 APO-GATP 将会进化到新产品、新技术，其进化之路同“ APO-SNP-OPTMIZER ”一样，也走向了 2 条路：：一条是走向云平台的 IBP ，一条是走向 S4HANA 。 IBP 中主要是 Response and Supply 中的 Response ，后续在 IBP 中再细说阐述；

而在 S4 中，其与 PPDS 一样， SAP 在 S4HANA 中也内嵌了功能更丰富的 ATP 称之为 aATP(Advance-ATP) 。但是无论是从技术上还是功能上，其并不同于 PPDS 到 ePPDS 那样几乎是翻版的在 S4 中存在，在当前， aATP 与 GATP 几乎可以视为独立的产品而存在，或者说二者之间的关系更像是一种“借鉴”，即 aATP 大量借鉴了 GATP 中的功能来形成新的功能。

比如，上面举了 GATP 中的 PAL ，在 S4HANA 中的 aATP 中， PAL 的技术架构、数据结构、操作模式简化了非常多，通过几个 Fiori App 就完成全部的 PAL 。

例如 PAL 计划数据如下：

那么在对应的 Planning object 下的订单可用性检查就体现为：

从而完成订单可用性检查：

除 PAL 之外， aATP 下的 ABC （ Alternative-Based Confirmation ）借鉴 GATP 的 RBA （ Rule-based-availability check ）：

但目前还缺少一些功能，例如 GATP-RBA 还可按规则的对物料替代、对特定工厂的替代等等；

同时 , aATP 也不具有 GATP 下的 CTP 、 MATP 的部分功能。但反过来， aATP 也引入了一些新功能，例如供应预留（ Supply Protection ）可以在其他 Available Check 的基础之上再考虑其被其他场景所预留的可用数量：

同时对于 BOP 操作，也是更加直接便捷：

所以， APO-GATP 的进化，以此图做结：

结语

在云的时代，特别是随着兄弟产品 IBP 与 S4HANA 的不断推陈出新，独立部署的 APO 的应用越来越少，无论是上述介绍的 DP 、 SNP 还是 PPDS 、 GATP ，越来越多的客户都选择了 SAP 的 IBP 及 S4HANA ，我们完全有理由相信，作为全新一代的 SCP （ Supply Chain Planning ）工具，无论是 IBP 还是 S4HANA ，都势必将会以更多全新的功能、全新的体验给我们的用户、企业带来更多的实用价值，以及更大的经济价值。