Mendix 和 SAP 合作伙伴关系

Mendix 自 2017 年以来一直是 SAP 低代码应用程序开发的主要合作伙伴，也是唯一一家 SAP 认可的应用程序合作伙伴 并已通过 SAP 高级认证。这意味着 SAP 已正式认证并认可使用 Mendix 除了 SAP 解决方案之外，

对于将低代码视为对传统 SAP 开发的有益补充的客户来说，SAP Build 是一个有意义的起点，但它的意义不仅仅于此。 Mendix 当客户的目标是用低代码工作方式取代大部分传统开发时，这更有意义，不仅适用于 SAP，也适用于非 SAP 系统和技术（Oracle、Salesforce、Java、.Net 等）。

Mendix 是一个专注于应用程序开发的单一平台，而 SAP Build 则包含四个产品，它们还做其他事情，例如机器人流程自动化 (RPA)。因此，可能会出现以下情况 Mendix 和 SAP Build 的部分功能可以一起使用。很难进行直接比较，但 SAP 和 Mendix 双方都看到了两种产品之间的明显差异，而他们持续的合作意味着客户可以选择最符合他们需求的产品： Mendix、SAP Build，或者两者的结合。

使用案例

Mendix 对于 SAP 客户来说，它就像一把瑞士军刀。当 SAP 缺少某些功能时，可以使用它；当标准 SAP 解决方案无法解决其要解决的问题时，也可以作为 SAP 的轻量级替代方案。

当然，您可以使用 SAP BTP（包括 SAP Build）来填补这些空白，但您可能需要使用传统的高代码来补充或替代低代码。使用 Mendix，特别是如果它们满足以下一个或多个条件：

1. 结合 SAP 和非 SAP 系统的数据和功能： 与其他 ERP 系统或面向营销、销售和服务用户的 Salesforce 类似。 Mendix 具有强大的 SAP 集成功能，但并不固守 SAP 的原则。它不打上 SAP 品牌这一事实也使其很可能被那些使用其他系统和技术的人接受为企业级平台。
2. 将标准工作流程功能与专门构建的应用程序体验相结合： 例如，在财务、采购、主数据管理和行业特定流程中。与 SAP Build 不同，其中工作流管理和低代码开发位于单独的工具中， Mendix 具有嵌入式工作流引擎，可让您在单一平台上享受两全其美的优势。
3. 自定义用户体验： 例如，客户和合作伙伴自助服务应用，这些应用需要公司品牌和消费者级体验。它还适用于销售、服务和其他部门的内部用户，这些部门的生产力受到标准 SAP 用户体验的限制。
4. 移动用户体验： 例如，维护和现场服务中的工单执行、仓库扫描和交货证明应用程序。许多客户传统上很难在移动设备上启用 SAP，但这是我们的强项 Mendix. Mendix 应用程序默认为响应式，但它们也可以转换为渐进式 Web 应用程序 (PWA) 和适用于 iOS 和 Android 的原生移动应用程序。它们还可以离线工作，这对于上面列出的用例通常很重要。

用例满足的这些标准越多，它就越适合 Mendix.

客户场景

自 4 年推出 S/2015HANA 以来，“保持核心清洁”一直是 SAP 自定义代码的口号。我们看到客户在不同程度上这样做， Mendix，从广义上讲，它们分为4个不同的类别或场景。

场景 1：连接到核心

在这种情况下，客户不一定明确提出“保持核心清洁”的策略（目前），但他们正在构建 Mendix 与 SAP 集成的应用程序。

一个好的起点是“SAP 预处理”应用程序，其中需要收集数据和/或由不同的用户批准，然后才能将完整且批准的对象或交易输入 SAP。

示例包括资本支出请求、采购请求、主数据更改等，它们通常通过影子 IT 完成，例如电子邮件、Excel 和 Lotus Notes。 Mendix 是自动化这些用例的理想方式，特别是当它们还需要非 SAP 集成和/或专用应用程序而不是标准工作流工具（如 SAP Build Process Automation）的用户体验时。

随着时间的推移，客户可能会构建许多带有 SAP 集成的应用程序，即使他们没有明确尝试“保持核心清洁”。一个很好的例子是 Siemens, 拥有许多 SAP 实例和 800 多个 Mendix 正在生产的应用程序。

场景 2：包含核心

在这种情况下，客户将 SAP 视为遗留系统，打算在未来某个未指定的时间将其迁移到 S/4HANA 或其他 ERP 系统。

这些客户试图“遏制 SAP”、“将 SAP 放入盒子中”，甚至“冻结 SAP”，以进行所有更改，但安全补丁和法律更新等强制性更改除外。新开发几乎总是在 Mendix但增强和扩展现有的自定义代码取决于变更的规模和范围以及客户的政策。

可以在核心中进行较小的更改，但较大的更改可能是将整个功能转移到 Mendix。此类客户包括健康、美容和营养公司 帝斯曼-芬美意 以及能源零售商 Enexis.

场景 3：清理核心

在这种情况下，客户正在系统地从其核心中删除自定义代码，并使用 Mendix.

人们误以为他们正在一模一样地重建相同的功能，但当然，他们也借此机会通过新功能和更好的用户体验对其进行现代化改造，例如包括全面的移动支持。从这个意义上讲，清理核心不仅仅是一个减少技术债务的 IT 项目，而且还为企业提供了真正的价值。

SAP 在一份名为“SAP S/4HANA 实施中的自定义扩展 - 高级 IT 领导实用指南”的文档中提供了有关如何清理核心的详细指南。该文件的日期为 2021 年，但它仍然是 SAP 提供的最详细指南，并且与继续使用 SAP ECC 的客户以及迁移到 S/4HANA 的客户相关。虽然它不是分步指南，但它确实概述了您必须采取的关键步骤：

• 开始提升 SAP 架构师的技能 如果您尚未这样做，请尽快向开发人员和开发团队介绍您想要使用的新技术。本文档假设您正在使用 SAP BTP 技术，但 Mendix 在这方面要简单得多，因为它是一个单一的平台、技术和技能组合。
• 删除所有过时的代码 来自您的 ERP 系统。SAP 表示，这通常占总数的 30%，有时甚至高达 50%。要找出哪些代码已过时，您可以激活内置的 SAP 功能以进行自定义代码使用情况监控，如文档中所述。
• 忽略将会过时的代码 如果您迁移到 S/4HANA，因为它可以被标准功能取代，因此重建毫无意义。此步骤需要 SAP 的功能和技术知识，因此您可能需要与 SAP 合作伙伴合作才能完成此操作。SAP 表示，完成此步骤后，您可能只需要从核心中清除 10% 的原始自定义代码。
• 使用名为 SAP Custom Code Analyzer 的工具 分析剩余代码的复杂性，并确定清理和重建的优先级。除了业务优先级之外，SAP 建议客户首先优先处理复杂代码和“孤立代码”。复杂代码会导致最多的问题和更改，因此维护成本最高，而“孤立代码”没有适当的文档所有者，这意味着它对业务构成风险。

对于您需要重建的每项修改，请使用本文档第 4 部分中的详细指导按优先顺序评估选项：

• 应用内扩展（仅适用于 S/4HANA）
• 新平台上的并行扩展
• 堆栈扩展（仅适用于 S/4HANA）
• 不执行任何操作（继续使用您当前的 ABAP 代码，现在称为“经典扩展”）

系统地清理 SAP ECC 系统核心的一个很好的例子是农业企业 Cosun甜菜公司他们推出了一项名为“SAP 2 Standard”的计划来清理他们的 ECC 系统，并重新培训现有的 ABAP 和 Fiori 开发人员使用 Mendix。结果，他们的开发能力提高了一倍，实现了比以前多 7 倍的成果，甚至帮助公司每年的农作物产量提高了 1.8 万欧元。

场景 4：保持核心清洁

“保持核心清洁”意味着您的核心一开始就是清洁的，要么是因为您已经清理过它，要么是因为您正在进行绿地重新实施，或者您对 SAP 完全是新手。

从某种意义上说，如果你是 SAP 新手，这会更容易，因为你可以直接让你的架构师和开发人员加入 Mendix 无需先让他们放弃旧的 SAP 技术。采矿公司就是此类客户的典型例子 矽比科 以及暖通空调、浴室和厨房批发商 凡马克.

更多客户使用示例 Mendix 与 SAP 结合，请参阅我们的 SAP 的客户案例.

联合伙伴

Mendix 有顾问可以帮助您构建应用程序，但他们不是 SAP 顾问。如果您还需要 SAP 领域专业知识，我们可以帮助您找到既具备 SAP 领域专业知识又具备 SAP 领域专业知识的合作伙伴 Mendix 和 SAP 经验。这可能是一个既拥有 Mendix 这可能是一个规模较小的合作伙伴，专门从事 Mendix 和 SAP。我们有很多这样的产品，很乐意帮助您在您所在的地区找到一家。

支持策略 Mendix 和 SAP BTP

Mendix 应用程序开发并部署到 SAP BTP 上运行，使用 Mendix Cloud Foundry 构建包。我们的客户有时可能会遇到不必要的问题。作为我们 SAP 的一部分Mendix 合作伙伴关系，我们有一个明确的支持策略，详见我们的 支持指南.