为什么保持 SAP 核心清洁很重要

在维护核心记录系统(如 SAP)时,大家一致认为,组织应尽量保持其标准化。任何为使系统适应组织需求而添加的自定义和增强功能都应删除。
但为什么保持核心整洁如此重要?组织如何才能提供适合其特定业务需求的解决方案,并适应其独有的细微差别和细节?低代码应用程序开发平台如何让两者兼而有之? 标准化和定制化您的 SAP 核心 那么容易吗?
首先,我们来看看 为什么你的核心需要清洁。
当组织实施核心系统时,开箱即用的功能绝不可能满足所有需求。因此,开发人员必须对系统进行添加、增强和调整,以应对特定 IT 环境的复杂性。
定制的其他原因包括:
- 与第三方系统集成
- 合并或收购后合并多个实例
- 创建独特的用户体验或本地化要求
- 满足监管要求
- 通过差异化获得竞争优势
30,000 个自定义扩展
经过一系列并购,跨国健康和营养公司 帝斯曼-芬美意 因缺乏 IT 标准化和监督而陷入困境。
结果是:
- 影子 IT 解决方案激增
- 快速提供增强功能的能力有限
- 由于本地化实施或并购活动导致系统分散或不一致
“从支持角度来看,我们的历史格局变得很难维护。每个解决方案都有自己的技术,没有内部知识,”DSM-Firmenich 技术开发专家 Wouter Vijverberg 表示。
类似的故事发生在 科森甜菜(CBC), 欧洲领先的糖生产商。自 1989 年以来,CBC 一直是 SAP 客户,已在两个领域创建了大约六百个自定义程序和组件。在过去 40 年中,这些构建和维护耗费了大约 20 人年的努力。
据 ASUG 称,平均 SAP ECC 系统 拥有超过 30,000 个自定义扩展 增强 SAP 标准功能。ASUG 数据库中的系统自定义代码量达 100 亿行或更多,其中 40%–60% 的代码甚至不再使用。
那么为什么不删除定制呢?
自定义代码支持(甚至不包括更改和增强)可增加33% 在公司的 SAP 成本之上。
在核心系统的生命周期中,各种不同的开发人员和团队成员会添加自定义代码。团队成员不可避免地会继续前进,并带走这些自定义代码背后的原因和方法。
确定哪些代码不再使用以及其依赖项以便安全删除,这非常复杂且成本高昂。许多组织根本没有足够的带宽或资源来这样做。
Enexis 是一家荷兰公用事业供应商,过去一直依赖定制的现成 (COTS) 软件。当 Enexis 无法从 COTS 选项中获得所需内容时,他们便引入了第三方开发人员。
这些开发人员会使用 .NET、Java 或 C++ 创建临时解决方案,但这些解决方案都缺乏公司范围内的标准化或治理。此外,Enexis 对第三方解决方案和开发资源的依赖导致其 IT 团队缺乏相关领域的知识,从而导致安全挑战和扩展问题。
为什么不直接进行定制呢?
高度定制的系统有什么缺点?最大的挑战之一是升级或迁移 SAP(例如迁移到 S/4HANA)的复杂性增加。随着复杂性的增加,维护成本也显著增加。除了这些困难之外,维持内部技能以了解更新任何已进行的定制的影响也十分困难。
瑞士飞机制造商, 皮拉图斯飞机有限公司 非常熟悉定制 SAP 解决方案的挑战。“当我们审视日益增长的遗留环境时,我们发现许多定制 SAP 解决方案和口头流程没有记录在案,”数字运营和维护产品负责人 Luca De Simoni 表示。
多年来,皮拉图斯的遗留环境导致了影子 IT 解决方案的产生。“您会发现公司内部存在许多不同风格的解决方案开发。Excel 经常被误用。我们的整个遗留内联网都基于 PHP。我们有许多 .NET 应用程序、大量 SAP ABAP 编码和许多其他定制软件。您会发现很多非标准解决方案,”De Simoni 说道。
随着 SAP S/4HANA 升级即将到来,Pilatus 需要找到一种方法来应对他们的挑战。
时间就是生命
SAP 已宣布 SAP ECC 的维护支持将于 2027 年底结束。但对于增强包 5 或更早版本的用户,大约一半的 ECC 客户,主流支持将在 2025 年底结束。因此,SAP 的建议是升级到 S/4HANA。
即使您是 37% 不打算在未来两年内升级到 S/4HANA 的组织之一,如果有的话,清理核心对于以下方面也至关重要:
- 降低维护成本
- 降低复杂性
- 提高业务敏捷性
- 实现更大创新
低代码方法是答案吗?
采用低代码方法是保持核心清洁的最简单解决方案。低代码可以帮助组织快速扩展其核心系统并在核心系统之外重新开发定制。SAP 自己建议客户使用他们的低代码工具 SAP Build 来应对挑战。
SAP Build 显然与 SAP 产品套件紧密集成,因此它在这方面为用户带来了好处。然而,当被问及他们的首要任务时,ASUG 成员将“SAP 和非 SAP 系统之间的集成”列为 他们的主要关注点.
SAP Build 是一款出色的 SAP 开发工具。但它能否用于集成 SAP 和非 SAP 系统?
这是哪里 Mendix 擅长。 Mendix 可以提供更全面的方法来帮助组织扩展和现代化其核心系统。
Mendix SAP 的 仅由 获得低代码认证的应用合作伙伴,并已通过 SAP 高级认证。 同 Mendix,SAP 团队可以减少导致 SAP 变更困难的时间、成本和风险障碍——无论是收购后集成、合并实例还是迁移到云中的 S/4HANA。
Mendix 与 SAP 高度集成。客户可以直接在 SAP HANA Cloud 上构建应用程序,将其直接部署在 SAP Business Technology Platform 上,并将其与任何 SAP 应用程序集成。
与许多 SAP 客户一样,Enexis 多年来对其 ERP 系统进行了大量定制,但现在正在迁移到 SAP S/4HANA,目的是保持核心的清洁。SAP 和 Mendix 使这成为可能。Enexis 可以避免在 SAP 中进行定制开发,因为他们将依赖 Mendix。此外,Enexis 还可以扩展关键 SAP 系统,例如以可重复使用的组件的形式来集成项目、客户或员工数据。
- Forrester TEI 报告 Mendix 对于 SAP 客户由 SAP 委托进行的一项研究发现,与使用 SAP ABAP、SAPUI5、Java 和 JavaScript 等传统开发的用户相比, Mendix 用户意识到:
- 开发成本降低 8 倍
- 价值实现时间缩短 8 倍
- 不到三个月就能收回成本
使用 Mendix
许多组织正在使用 Mendix 通过清理核心来降低系统的复杂性。
DSM-Firmenich 拥有一个由多个实例组成的复杂 SAP 环境,使用许多不同的工具和技术。该公司现在拥有一个全球技术开发团队,支持所有定制开发 Mendix、AWS 和 SAP。
DSM-Firmenich 的 Vijverberg 表示:“我们并没有使用最新版本的 SAP。因此,我们的架构师给出的指导是将 SAP 放在一个盒子里。我们不想再对 SAP 进行太多更改。相反,我们可以使用 Mendix 作为合并附加功能的补丁。”
DSM-Firmenich 已开发了 150 多种 Mendix 应用程序。其中约 50% 与一个或多个 SAP 实例交互。通过使用 Mendix 作为多个系统之上的一层,用户可以通过一个简单的单一入口点访问多个系统。DSM-Firmenich 发现,使用 Mendix.
Cosun Beet 的开发人员也发现使用 Mendix 低代码比构建 SAP 用户界面更划算。到目前为止,他们已经整合了 250 个客户 SAP 解决方案中的 600 多个。仅使用一个应用程序,即他们的 Dock Planner 解决方案,它允许员工和外部供应商预订 CBC 码头的时间段,他们每年可节省 XNUMX 个工作日。
飞机制造商 Pilatus 能够通过以下方式交付数字化工作订单 (DWO) 概念验证: Mendix 仅用 14 周时间。“DWO 的目标是列出所有需要根据 SAP 构建的内容,以及相应的图纸、文档、3D 模型和需要采取的步骤,”Holz 说。“当任务和订单在应用程序中完成时,它们会反映回核心系统并在 SAP 中实时更新,这样 Pilatus 就可以轻松查看特定飞机的进度以及距离交付还有多远。”
保持干净
无论您是想升级核心系统还是优化当前实施,毫无疑问,维护自定义代码的成本很高,并且会阻碍您的效率、生产力、敏捷性以及创新和竞争能力。
无论您的战略重点是什么,努力打造干净的核心都是关键。低代码方法可以让您更快地实现这一目标。正如 Guido Zeelen 所说, 矽比科 也就是说,“从商业角度来看, Mendix 帮助我们标准化了业务的非标准部分。S/4HANA 正在标准化我们大部分的业务流程。那些不适合的部分可以使用低代码进行标准化,这真的很强大。”
如果您想了解更多有关如何 Mendix 可以帮助你保持核心清洁, 联系我们.