随着我们全新的SAP实施，我们有了一个公司难得的机会—一个新安装的SAP实例。可以理解的是，我们希望从编码的角度确保我们"做正确的事情"。

我们的方向是不遗余力地消除和避免定制代码–将标准与定制的比率保持在90%/10%。

定制代码使得很难将收购快速集成到我们的业务流程中。自定义代码使我们的生产环境不太稳定。自定义代码需要太多的支持。

来自SAP世界之外，这一切听起来都很合理，这些都不一定是正确的。

并非所有的自定义代码都是平等创建的

我想说的是，SAP中有两种类型的自定义代码：自定义（大写‘C’）代码和自定义（小写‘C’）代码。

自定义代码

SAP非常擅长让用户创建销售订单或采购订单。SAP不擅长的是为用户提供创建一千个销售订单或一千个采购订单的能力。

这就是小写字母"c"自定义开发的用武之地。

创建允许用户（或界面）创建、更新、发布、，最重要的是，纠正错误的事务。

SAP不能提供这种功能。因此，定制代码可以解决这些问题。

从小型报表到大型交互式应用程序……这正是我们在SAP中拥有全功能开发环境的原因。

定制代码

我们确实应该更严格、更具挑战性和限制性地检查定制代码，是要求我们打开标准销售订单或采购订单以在BADIs或用户出口中插入自定义业务逻辑的类型–这些类型的增强会中断标准SAP文档创建和业务流程。

但是如果操作正确，数据分析和大数据，即使是引入的风险也可以通过智能开发实践来减轻，例如划分增强代码和使用表驱动原则来驱动代码路径。

每当我看到一个有300多行代码的用户直接退出时，我都会畏缩。这是一个坏的自定义编码的主要例子，大数据中心是什么，它引入了不稳定性，并且不能长期支持。这就是我们的重点所在。

后果

因此，公司会选择购买第三方应用程序来取代真正应该包含在SAP内部的功能，没有意识到，为了让这些应用程序正常运行，采购返利，大数据分析过程，通常需要集成。

我见过的应用程序最多需要11个（！）接口，以便与SAP集成，只需将FI过账单发送回SAP。

我重复。我见过10个基于云的应用程序的出站接口，在用户交互后，它会掉头，并将FI文档发送回SAP。

最糟糕的是，这些接口中的每一个都必须是定制开发的，增加了他们最初试图减少的定制代码库！

疯狂。

最后，每个接口都是潜在的故障点。随着我们引入更多的数据交接，复杂性也随之增加。随着复杂性的增加，需要更多的支持人员，纠正问题的时间也在增加。

结论

总之，大数据库，定制代码确实不错。而且，没有神奇的比率。将其从标准SAP流程中抽象出来一步，您就没事了。

使用自定义代码启用新功能，并简化和自动化标准流程，而不是更改它们。

如果您将机密销售和客户数据发送到某个基于云的应用程序，以便将文档创建返回SAP为了避免实例中出现额外的自定义代码，您可能做错了什么。