SAP Community - Cloud

Comment SAP MM peut transformer le processus d’achats dans une entreprise

2025-12-05T10:02:11.080000+01:00

Le module SAP MM (Materials Management) est l’un des piliers des systèmes SAP pour la gestion des achats et des stocks. Une bonne utilisation de SAP MM peut révolutionner le processus d’approvisionnement, en le rendant plus rapide, plus précis et plus efficace.

Automatisation des achats SAP MM permet de générer automatiquement les demandes d’achat, les commandes

fournisseurs et les bons de réception, en réduisant les erreurs humaines et en accélérant le cycle P2P (Procure-to-Pay).

Meilleure gestion des fournisseurs

Le module centralise toutes les informations sur les fournisseurs : données de contact, conditions d’achat, historique de commandes, performances, etc. Cela facilite la sélection des meilleurs fournisseurs et le suivi des KPI.

Optimisation des stocks

SAP MM permet de suivre en temps réel les stocks disponibles, les mouvements de matériel, et les niveaux de réapprovisionnement. Cela réduit les ruptures de stock et les surstocks, améliorant la gestion du capital.

Intégration avec les autres modules SAP

Grâce à l’intégration avec SAP FI (finance) et SAP SD (ventes), SAP MM garantit que toutes les transactions d’achats ont un impact direct sur la comptabilité et la chaîne logistique. Cela offre une visibilité complète et un contrôle précis des coûts.

Analyses et reporting avancés

SAP MM fournit des rapports détaillés et des tableaux de bord pour suivre les performances des achats, analyser les écarts de prix et anticiper les besoins futurs. Les décisions deviennent plus rapides et basées sur des données fiables.

En adoptant SAP MM, une entreprise peut transformer son processus d’approvisionnement :plus de rapidité et d’efficacité,

moins d’erreurs,
meilleure visibilité sur les stocks et les fournisseurs,
décisions basées sur des données précises.

SAP MM n’est pas seulement un outil informatique, c’est un véritable levier stratégique pour la performance des achats.

SAP ERP Cloud SAP S/4HANA Cloud Public Edition Sourcing and Procurement

From On-Premise to Cloud: Making the Right SAP ERP Move

2025-12-10T08:19:08.342000+01:00

A comparative representation of SAP Cloud ERP deployment variants

This article presents an overview of SAP’s ERP solutions, outlining available deployment models and providing a comparative representation of the variants. It is designed to support customers in navigating and evaluating options that align with their organization’s digital transformation goals, operational requirements, and existing technology investments. The attention is given to SAP’s private cloud offerings, highlighting the flexibility, scalability, and relevance for enterprise-grade modernization initiatives.

SAP ERP On-Premise

Historically, SAP operated as a software provider focused on licensing and support, while customers and partners took on the challenge of designing, building and running highly customized implementations. This approach offered maximum flexibility but came at a cost - fragmented landscapes, version sprawl, and operational complexity. Additionally, as SAP simultaneously support more than 20 software versions of ERP and countless release variations - it increased the burden of maintenance, made it harder to adopt new features, and slowed innovation. Today, SAP is shifting toward standardized, cloud-based solutions that streamline operations and accelerate the transformation and adoption of change.

Whether you run your SAP ERP systems in your own data center, with a hosting provider or directly with a Hyperscaler, it is considered an on-premise deployment. Moving from here to an SAP Cloud ERP deployment is equally relevant and the strategic direction of SAP.

SAP Cloud ERP

SAP delivers a diverse portfolio of ERP solutions tailored to meet the needs of organizations across industries and geographies, addressing increasing demands for security, compliance, and operational control. While SAP continues to drive standardization and scalable adoption, it recognizes that transitioning to a unified cloud-based ERP is a phased journey for many enterprises. To support this evolution, SAP offers a range of strategic pathways that enable customers to embrace SAP Cloud at their own pace - preserving existing investments, leveraging the latest innovations, and maintaining a flexible operating model aligned with their business priorities.

SAP Cloud ERP sits at the center of SAP’s strategic architecture, serving as a foundational layer for enabling accelerated adoption of AI-driven services and continuous innovation. Its integration with key architectural components - including SAP Business Technology Platform, SAP Business Data Cloud, line-of-business applications, and AI agents - is essential for designing future-ready business processes and operating models. This architectural alignment ensures cohesive data flow, scalable automation, and a unified platform for digital transformation across the enterprise.

SAP's Strategic Architecture Model

Over the years, SAP has been transitioning to a cloud company. SAP Business ByDesign was launched in 2007, and multiple private cloud offerings were launched starting in 2013. SAP’s cloud services have matured continuously ever since, and SAP Cloud ERP is now at the center of SAP’s strategy. The consumption model is modular and scalable. Businesses can start with essential modules and expand as needed.

SAP Cloud ERP is a modern, cloud-based ERP solution that helps businesses manage core operations using intelligent technologies like AI, machine learning, and automation. It’s designed for speed, scalability, and continuous innovation - all while running under SAP’s strong security framework.

Adoption is now more important than ever. There is little to gain if innovation is held back due to technical difficulties, unsupported software and a lack of strong governance in the daily operation. This is one of the reasons SAP has invested heavily in cloud services and adoption programs. Now offering a modern commercial model with user- and metric-based subscription, which is accelerating the architecture design process with modular building blocks, and adoption programs helping customers to a modern ERP through “RISE with SAP” and “GROW with SAP”, focusing on accelerating the digital transformation of customers.

GROW with SAP

GROW with SAP is a program to rapidly implement SAP Business Suite using a standardised framework, tools, and guidance. It is designed for new SAP ERP customers and enables a greenfield/new implementation of SAP Business Suite in SAP Public Cloud.

RISE with SAP

RISE with SAP is a program that helps on-premise SAP ERP customers tailor their transformation to modernise their business with Business Suite. It is designed for existing SAP ERP customers, focused on modernising their existing SAP ERP systems in SAP Private Cloud.

Both journeys lead to the same destination, full SAP Business Suite capabilities, but are tailored to the customer’s starting point.

Public or Private Cloud

SAP has two cloud ERP solutions to choose from:

SAP Cloud ERP (Public): Ready-to-run cloud ERP managed by SAP
SAP Cloud ERP Private: Tailored-to-fit cloud ERP that adapts to your unique business needs while enabling the migration of your on-premises ERP investment from SAP

The first assessment customers need to make is whether their requirements can be met in SAP Public Cloud or if SAP Private Cloud deployment is needed. There are fundamental differences between the two cloud options, which often make the first choice simple:

Comparison Between SAP Public and Private Cloud

This simple table reveals significant differences. The public cloud doesn’t yet offer the full scope of ERP functionalities, and if that doesn’t cover the customer’s requirements, the private cloud is the only alternative.

The SAP code can’t be modified in public cloud and while the SAP recommendation has always been not to modify the SAP standard code, there are certain situations where it can’t be avoided, or changes have already been made in on-premise systems and must be kept. In this case the only possible destination is private cloud.

(*) Direct modification of SAP-delivered standard code is not permitted as a standard practice. The environment is designed to maintain a "clean core," and customers are expected to use supported extensibility options (such as in-app extensions, BAdIs, or side-by-side development on SAP BTP) rather than altering SAP standard objects. Exceptions to this rule are rare and require formal SAP approval, with the customer assuming full responsibility and risk for any such modifications.

In public cloud, mandatory software releases and updates are pushed out by SAP and the changes must be adopted within a limited time period. In private cloud, the updates are included in the service, but the implementation is a customer choice. SAP will not install software updates without consent from the customer.

Finally, the very nature of a SaaS solution can be restricted by some customers or deployment options might be needed, which are not available in public cloud. Typical examples could be stronger segregation of data, the need for a private code base, increased business continuity concepts and distinct security and compliance requirements.

SAP Cloud ERP Public

SAP Cloud ERP Public is a pure Software-as-a-Service (SaaS) cloud delivery model, and it is the preferred deployment model for all customers opting for a fresh new-implementation (greenfield) of SAP ERP and whenever functional, integration, and localisation requirements can be addressed.

Being a SaaS offering, the deployment options are limited, by design, compared to private cloud, and as the focus of this article is private cloud, this deployment model is not described further.

SAP Cloud ERP Private

SAP Cloud ERP Private is a deployment option of SAP ERP software installed specifically for the customer in a private cloud environment.

SAP Private Cloud is technically SAP-managed services and software licenses running in a single-tenant, virtual private cloud environment on subscription. Customer systems run in a dedicated cloud tenant with dedicated capacity and is completely isolated from other customer accounts. SAP is providing managed infrastructure, technical managed services and operations, security, and lifecycle management. Customers access their systems via secure, private network connections (not public internet), retain control over business processes and configurations.

It offers enhanced control, security, and customization compared to public cloud solutions. Private cloud deployments typically offer more robust security measures and compliance capabilities, making them suitable for industries with stringent data protection requirements.

Private cloud deployments are more appropriate for existing on-premise customers who require more customization, whose functional needs can’t be addressed with the public cloud option, or if the investments made in existing on-premise systems need to be retained.

SAP aims to transition all customers using SAP ERP to SAP S/4HANA by 2027. Before the introduction of RISE with SAP in 2021, SAP did not fully meet the needs of customers seeking cloud-based ERP solutions. The primary option available was SAP S/4HANA Cloud Public Edition, which required a new implementation. This was not a viable option for many existing SAP ERP customers who wanted to retain their investment in their current systems, leverage existing data, and carry forward customizations and modifications.

To address this gap, SAP introduced SAP Cloud ERP Private solutions with the launch of RISE with SAP. These single-tenant solutions offer each customer their own dedicated instance of SAP software, hosted on separate infrastructure within a data center operated by one of the major hyperscalers or SAP itself. Existing SAP ERP customers can choose to either lift-and-shift their SAP ERP systems or transition to SAP Cloud ERP Private using a system conversion, selective data transition, or a new implementation approach. SAP Cloud ERP Private comes in two offerings: Packaged and Tailored.

Packaged Option (Private Cloud Edition, “PCE”)

SAP Cloud ERP Private is a packaged deployment option that is fixed, template-based, and uses SAP Reference Architecture. It focuses on core ERP functionality delivered in modular packages for standardised and rapid consumption. Infrastructure sizes and changes are delivered in T-shirt size models via a catalogue-based list of services that covers the user software license, infrastructure, and technical managed services required to run SAP.
This is the strategic choice for providing innovation and cloud value while customers retain investments by converting existing systems.
Standardisation is strict

Tailored Option (Private Cloud Edition, Tailored Option, “PTO”)

The SAP Cloud ERP Private, tailored deployment option is a flexible, individually configured using SAP Reference Architecture and covers the full ERP scope, covering nearly any SAP on-premise product still in maintenance with SAP technical support.
This is the strategic choice for complex architecture, large data volumes, customer-specific requirements, compliance and flexibility.
Standardisation is strict, while offering more flexibility

Both SAP Cloud ERP Private, Packaged and Tailored options can be deployed in different ways, but not all deployment options are available for both types.

Deployment Options

In SAP Cloud ERP Private, customers select their deployment option and specify the data center to use. Each option has its own distinct delivery model designed to cover different needs. Regardless of which option they choose, customers are responsible for the application layer (such as functional configuration, business process design, company authorization concept), and SAP is responsible for the technical managed service, infrastructure management, governance, security & compliance framework, and software and support.

Regardless of which private cloud deployment option is used, customers are in control of functional changes. Some changes are fully managed by customers, like custom code/extension and integration, business consistency and correctness, and SAP transport management. Other changes are initiated by customers and managed by SAP, like release upgrades and patch updates on SAP applications and the database. While updates to the software are included, SAP will not upgrade these components without customer approval.

The technical layers are managed differently, and the responsibilities vary as illustrated below. SAP has overall ownership, provides a generic architecture framework with common tools and a service delivery model, and remains agnostic about which deployment option to use. The end-user experience is designed to be the same regardless of which option is used.

SAP offers the following delivery options:

Hyperscaler

Deployed on Hyperscaler Infrastructure-as-a-Service (IaaS) under SAP's account
The default deployment model with global coverage, enterprise-grade scalability capabilities and the latest features
Often an advantage for customers who already have an active account with the same hyperscaler. Advantages like improved network latency, re-use of existing connections between customer premises and the hyperscaler, pre-approved by the customer’s security department

SAP Data Center

SAP operated data centres in Germany and options in Europe, APJ and North America
Compared to Hyperscaler, the scalability capability is limited and generally reserved for moderate workloads
This option is typically chosen for customers with strict regulatory, security, or technical requirements that cannot be met by Hyperscalers

Customer Data Center

Allows SAP to deliver and operate its managed cloud services directly within a data centre facility owned or leased by the customer
SAP manages the full stack remotely, while the customer retains control over the physical facility and network perimeter
Designed for organisations with strict data residency, regulatory, or integration requirements, but with certain features that may be limited
The data centre facilities must adhere to SAP’s reference architecture principles and security & compliance framework which must be approved by the hardware partner and SAP

Premium Supplier

A delivery framework where selected strategic partners, Premium Suppliers, are responsible for the technical infrastructure build, operation, and day-to-day services
While the Premium Suppliers manage the technical run and operations, SAP retains overall contractual responsibility, governance, and customer engagement
The infrastructure and some operational services are delivered by the Premium Supplier, either in their own data centres or in Hyperscaler environments managed by them
The model has specific rules for technical validation and operational responsibilities, which differ from the other SAP-delivered deployment options

RACI for SAP Cloud ERP Private Deployment Options

Security, Data Protection and Compliance

The packaged and tailored options both share many characteristics and principles as they both run according to SAP’s global Private Cloud concept, Reference Architecture and Cybersecurity and Compliance Frameworks.

The table below shows some of the security, data protection and compliance options available in Cloud ERP Private for the different deployment options. Some are available in both Cloud ERP Private offerings, while others are available for either the packaged offering (core ERP) or the tailored offering (full ERP). This leads to many combinations of options available to meet the requirements of customers, and each option has conditions that need to be assessed individually in collaboration with SAP.

Security & Compliance Capabilities for SAP Cloud ERP Private Deployment Options

SAP Sovereign Cloud

SAP Sovereign Cloud can be categorized as a Cloud ERP Private deployment option. However, in essence, this is a separate offering with distinct features covering both private and public ERP cloud offerings from SAP. This is the strategic choice for increased country-specific sovereignty requirements. All data is stored and operated to maintain compliance with heightened local data protection regulations.

The sovereignty extends beyond the technical infrastructure and must also be operated by security-cleared personnel from government-accredited, security-cleared facilities, according to country-specific data residency regulations and specific audit and regulatory standards.

SAP Sovereign Cloud is relevant if there is a specific need for increased sovereignty that SAP Cloud ERP and SAP Cloud ERP Private cannot otherwise provide. Like SAP Cloud ERP Private, different deployment options are available to cover different requirements across geographies and industries.

Deployment Options

Like SAP Cloud ERP Private, there are choices between which data centres to use, each option with its own distinct delivery model designed to cover different needs. Equal for all is that customers are responsible for the application layer (like functional configuration, business process design, company authorisation concept) and SAP is responsible for the governance, security & compliance framework and the global standard architecture framework.

There are differences in the remaining layers, however, SAP has overall ownership, provides a generic architecture framework with common tools and service delivery model and remains agnostic. The end-user experience is the same regardless of which option is used.

Deployment Options for SAP Sovereign Cloud

Make the right strategic choice

When evaluating cloud deployment options, the many available options SAP provides are often overlooked, perhaps inadvertently ruled out prematurely or not even known as valid deployment options.

The reality is that through the wide range of deployment options, SAP offers the ability to support most industry requirements and regulatory demands for deployment in the cloud:

Cloud ERP – preferred option when:

New or existing customers planning a new (greenfield) implementation from scratch and whenever functional, integration, and localisation requirements can be addressed
Multi-tenancy is a suitable cloud deployment model for your organisation
Your organisation can adhere to a mandatory software lifecycle management process governed by SAP

Cloud ERP Private – preferred option when:

Existing SAP customers looking for innovation and cloud value while retaining investments by converting existing systems
Standardisation and agility are a priority
Standard migration scenarios of your existing systems into SAP cloud are sufficient
Functional requirements can be addressed
Standard Business Continuity and network capabilities are sufficient

Cloud ERP Private, tailored option – preferred option when:

Full functional SAP ERP scope is required
Flexibility in the configuration of the infrastructure
Complex migration scenarios of your existing systems into SAP Cloud are needed
Enhanced Business Continuity and network capabilities are required
Advanced features and capabilities are required
Very large data volumes

SAP Cloud ERP Private, SAP Data Center - preferred option when:

There is a specific need to have SAP as data center owner or controller
Cloud workloads must run according to country-specific data residency regulations
Small to moderate workload

SAP Cloud ERP Private, Customer Data Center - preferred option when:

There is a specific need to have the customer as data center owner or controller
Cloud workloads must run according to country-specific data residency regulations
Customer can provide data centers that are suitable for running SAP Cloud ERP Private
The customer want to manage the physical data center premises
Typically, most relevant for high workload

Sovereign Cloud – preferred option when:

There is a specific need for increased sovereignty that SAP Cloud ERP cannot otherwise provide
Must be operated by security-cleared personnel
Must run from government-accredited, security-cleared facilities
Must run according to country-specific data residency regulations and specific audit and regulatory standards

On-premise / Native Hyperscaler – legacy option when:

Upgrade to a supported version is impossible
The existing system is planned to be decommissioned within a short time frame
Other reasons preventing customers from moving to the cloud. SAP will support with a detailed assessment of the available pathways

A closer examination reveals a wide range of options and combinations that can only be fully evaluated in collaboration with SAP through the mandatory Technical Assessment process. The table below aims to illustrate the wide range of options available to customers that SAP provides to support customers in transitioning to the optimal cloud deployment model.

Comparison of SAP ERP Offerings

Secure your SAP Cloud ERP deployment through a Technical Assessment

The Technical Assessment is a process designed to ensure that customer requirements are met when transitioning to SAP Cloud ERP Private, and to support a successful move to the cloud. This service is included in every engagement and is delivered by SAP Global Cloud Operations (GCO) - the business unit in SAP that is responsible for design, build and operate of Cloud ERP Private. GCO also oversees the service engineering of the included services (read more about that here), and the customer advisory for evaluating cloud deployment options and ensuring successful onboarding to SAP Cloud ERP Private.

Technical Assessment Scope:

SAP Cloud ERP Private Deployment
Technical Architecture
Network & Connectivity
Security & Compliance
Services & Operations
Cloud Onboarding.

The Technical Assessment is defined and led by the SAP Cloud Architecture & Advisory team within SAP Global Cloud Operations. We guide customers through the necessary steps at a pace aligned with each customer’s readiness and transformation journey. Your designated Cloud Architect & Advisor (CAA) is available to guide you through a deeper assessment of the cloud deployment options outlined in this article.

Choosing the right path to Cloud ERP

2025-12-12T05:22:51.264000+01:00

For many SAP-using organizations, moving to Cloud ERP is not a question of if but how. And businesses are feeling the pressure. End-of-support for ECC is fast approaching and many of SAP’s newest innovations are offered only in the Cloud.

Despite the urgency, more than half of SAP users have yet to begin their migration. One of the biggest hurdles is choosing the right path to Cloud ERP.

At first, this might seem like a simple decision between Public Cloud ERP and Private Cloud ERP. Yet, the choice is far more complex. It requires careful consideration of your business priorities, regulatory requirements, and landscape complexity.

Public vs Private

It’s tempting to view Public Cloud ERP as a one-size-fits-all solution, with limited flexibility. Public Cloud ERP is often described as a standardized, SAP-managed solution with a Clean Core – where most customizations move to external platforms like BTP. Private Cloud ERP is seen as the more flexible alternative, particularly for organizations needing to retain legacy customizations.

While there is some truth to that distinction, it oversimplifies the reality for businesses considering shifting to the Cloud. The real difference is less about whether you can customize, but where and how.

In Public Cloud, extensions and customizations, mostly occur outside the core ERP system. Unlike Public Cloud, Private Cloud permits more change to the core ERP system and offers more options that address end-user requirements such as hosting preferences and underlying technology.

The Many Variations of Private Cloud

For larger enterprises, Private Cloud is the likely choice. Yet, that choice is anything but straightforward. Over time, SAP has expanded beyond a single core offering of Private Cloud ERP (formerly RISE), offering numerous options designed to meet distinct needs, whether infrastructure preferences, regulatory compliance, or phased migration timelines.

Some examples of Private Cloud include:

SAP Cloud ERP Private Edition: Classic RISE with SAP option and the right choice for many enterprises
SAP Cloud ERP Private Edition Tailored: Contracted options are customized per unique customer requirements. May include contracted coverage for many responsibilities considered customer concerns in the base offering.
SAP Cloud ERP Private Sovereign Cloud: Keeps all data and processing within a particular jurisdiction or geography. It’s ideal when technical or regulatory requirements make traditional off-site hosting infeasible.
SAP Cloud ERP Hyperscaler: Runs on the customer’s preferred hyperscaler, often leveraging an existing relationship.
SAP Cloud ERP Hyperscaler Tailored: Modified version of Cloud ERP running on the customer’s existing hyperscaler environment. Offers additional flexibility for deployment architecture and may be more suitable for migrating highly integrated or complex existing on-premises implementations.
SAP ERP Customer Datacenter Edition: Brings Cloud architecture into a company’s datacentre when external hosting isn’t feasible.
SAP Cloud ERP Private Edition Transition Option: A commercial offering enabling enterprises to commit to Cloud ERP while keeping ECC supported past 2027 and through 2033.

The number of Cloud ERP options can be overwhelming. Yet, it also means you can choose an offering closely aligned with your strategic goals.

Key considerations for your Cloud journey

There are more options available than many SAP-using organizations realize. The best outcomes come from asking the right questions and focusing on what matters most to your business.

Customization: Do we have significant existing customizations? How critical are these customizations? Is code going to be retained or modernized? Where does redevelopment or customization take place?
Compliance: What compliance or jurisdictional requirements govern where data can reside?
Cloud partnership: How important is leveraging an existing hyperscaler contract or infrastructure investment?
Timeline: Do we anticipate maintaining ECC beyond standard support timelines, and if so, what transition paths exist?

Look beyond Public and Private and focus on business realities. In this way, you can identify an option that balances flexibility, control, and long-term viability. It means businesses can avoid putting operations and compliance at risk as they migrate to the Cloud.

The Bottom Line

The journey to Cloud ERP is rarely straightforward. No two organizations have the same requirements and goals. What’s clear is that there is no universal answer. Public Cloud offers speed, standardization, lower total cost of ownership, automatic SAP updates, and scalability. Private Cloud provides flexibility, with choices built to address distinct business challenges.

The right choice depends on aligning your migration strategy with business outcomes. Focus on your requirements and chart a course that ensures your ERP landscape remains a foundation for growth, innovation, and resilience today and in the future.

Digital Transformation. View of an Enterprise Architect - Conway's Law

2026-01-13T13:07:27.255000+01:00

#GenerativeArt

Out of the Ivory Tower: Architecture, Organization, and the Reality of SAP Transformations

Many SAP transformations today do not fail because of technology. SAP S/4HANA, cloud architectures, and modern integration platforms are mature and powerful. Yet in practice, end-to-end processes often remain slow and inefficient.

The root cause is frequently not the system itself, but the organization that designs, operates, and evolves it.

When SAP Architecture Meets Organizational Silos

In many enterprises, SAP organizations have historically been structured around technical modules such as SD, MM, or FI.
While these modules are technically connected through document flows, they are often organizationally separated.

This leads to familiar challenges:

· high coordination effort across team boundaries

· fragmented ownership along end-to-end processes

· long lead times despite modern platforms

As a result, architecture becomes a reflection of organizational reality.

Conway’s Law: Relevant in Everyday Practice

This pattern can be explained by Conway’s Law:
Systems inevitably mirror the communication and decision structures of the organizations that design them.

For SAP customers, this means that as long as organizations are aligned around technical components, architectures will follow the same structure—regardless of how advanced the underlying technology is. Agile methods alone do not change this as long as structural dependencies remain.

A Realistic Perspective on Organizational Change

Especially in large, established SAP organizations, one thing is clear:
Breaking down organizational silos is difficult and often not fully achievable.

Governance models, reporting lines, and historically grown responsibilities impose real constraints. A radical organizational redesign is therefore rarely feasible in the short term.

Why Awareness Still Makes a Difference

The key benefit already starts with awareness of the relationship between organization and architecture:

· dependencies become visible earlier

· architectural decisions are assessed more realistically

· interfaces are understood as organizational, not just technical, challenges

Even without major reorganization, this awareness enables targeted improvements—for example, clearer end-to-end ownership for critical initiatives or more deliberate team setups where it matters most.

Conclusion

SAP architecture does not emerge in an ivory tower. It is always shaped by the organizational context in which it is created.
Those who understand and consider Conway’s Law make better architectural decisions—even when organizational silos cannot be fully removed.

Architecture is organizational design.

What Does This Mean for Your SAP Transformation?

Taking a conscious look at organizational structures, responsibilities, and communication paths can significantly improve the effectiveness of architectural decisions. Not every organization needs to be redesigned—but every transformation benefits from thinking about architecture and organization together.

Common thread of this blog series:
Introduction
Tasks of an Enterprise Architect
Success Factors for Digital Transformation Projects
Help of an Enterprise-Architecture-Framework
Steps and Tips
Artificial Intelligence Meets Enterprise Architecture
Conway’s Law
From Intelligent to Autonomous

References

Hohmann, M.; Wagner, D.: Architecture Is Organizational Design, iX – Magazine for Professional Information Technology, Issue 1/2026.

Success Pläne - Der neue Support-Ansatz von SAP für die Cloud

2026-02-05T11:26:32.459000+01:00

SAP führt im März 2026 ein neues Support-Modell ein, das die Zusammenarbeit mit Kunden vereinfachen soll. In einer Session im Rahmen der IT Online Konferenz erklärten Dr. Stephanie Lockemann (Head of Premium Engagements and Customer Innovation Services) und Simone Ruprechter (Head of Solution Sales Business Development and Go-to-Market Services) die Neuerungen in einem Interview. Anbei eine Zusammenfassung.

Warum werden die Success Pläne als ein neues Support-Modell benötigt?

Veränderte Marktbedingungen

Die Rahmenbedingungen für Unternehmen haben sich gewandelt. Märkte folgen nicht mehr vertrauten Mustern, sondern verändern sich in kürzeren Zyklen. Wachstumsphasen, Inflation und Rezession wechseln sich schneller ab. Lieferketten geraten ins Stocken, Fachkräfte fehlen, und geopolitische Entwicklungen ändern sich im Tagesrhythmus.

Gleichzeitig entstehen neue Chancen: Daten liefern Erkenntnisse in Echtzeit, künstliche Intelligenz steigert die Produktivität, und neue Geschäftsmodelle werden möglich. Entscheidend ist nicht mehr die Unternehmensgröße, sondern Geschwindigkeit, Transparenz und Anpassungsfähigkeit.

Kundenfeedback als Treiber

Neben den Marktbedingungen war das Kundenfeedback zentral für die Neuausrichtung. Kunden erwarten SAP in einer beratenden Rolle über den gesamten Lebenszyklus ihrer Lösung - nicht nur bei der Implementierung. Sie brauchen vorausschauende Guidance, Unterstützung bei neuen Releases und kontinuierliche Beratung, um den Return on Investment zu maximieren und TCO zu senken.

Die drei Success Pläne von SAP im Überblick

Das neue Modell besteht aus drei aufeinander aufbauenden Success Plänen:

Foundational Success Plan

Der Foundational Success Plan erweitert das bestehende SAP Enterprise Support Angebot und richtet sich an Kunden mit standardnahen Systemen und geringeren Support-Anforderungen. Alle SAP‑Cloud-Kunden erhalten ihn automatisch. Er bietet:

24/7 Support entlang Service Level Agreements
Managed Services für den Cloud-Betrieb
Self-Service-Inhalte für Onboarding und Launch
Begleitung bei der Transformation mit SAP Cloud ALM
Learning Journeys für Schulungen

Advanced Success Plan

Der Advanced Success Plan baut darauf auf und löst SAP Preferred Success sowie SAP Preferred Success expanded edition ab. Er bietet u.a,:

Verbesserte Service Level Agreements
Innovation and Adoption Guidance für neue Releases und Features
KI-basiertes Systemmonitoring mit automatisierten Empfehlungen
Activation and Optimization Services (Microservices mit 8-16 Stunden)
Einen remote Success Expert, der einen Serviceplan erstellt
Kunden können alle Entitlements unbegrenzt nutzen

Max Success Plan

Der Max Success Plan ermöglicht eine strategische Partnerschaft mit SAP. Er kombiniert alle Leistungen aus Foundational und Advanced und ergänzt sie um:

Einen dedizierter Success Plan Manager
Zugriff auf das Premium Engagement Service Portfolio
Services für Business Process Improvement, Complex Transformation und Safeguarding
Maßgeschneiderte, individuelle Services incl. Prototyping
Enhanced Case Management mit dediziertem Ansprechpartner
Vor-Ort-Unterstützung bei Bedarf

Der Max Success Plan integriert das bisherige Premium Engagement Services Angebot.

Was sind Praxisbeispiele der Success Pläne von SAP?

SAP Business AI Nutzung

Bei SAP Business AI sieht es wie folgt aus:

Foundational: Zugriff auf Lösungsdokumentation über help.sap.com, Learning Journeys, Aktivierung von Joule über Self-Services

Advanced: Zusätzliche Leistungen zur Identifikation des Business AI Potenzials, strategische Aktivierung von Anwendungsfällen, fortlaufende Produktberatung, Guidance und Optimierungsempfehlungen

Max: Definition der KI-Strategie, Erstellung einer Daten- und Architektur-Roadmap, Entwicklung von Prototypen für maßgeschneiderte KI-Anwendungsfälle

Business Data Cloud (BDC) - Neues Release

Ein konkretes Szenario bei einem neuen BDC-Release zeigt die Flexibilität durch die Kombination verschiedener Layer:

Foundational: Zugriff auf Lösungsdokumentation über help.sap.com, neue Lerninhalte über Learning Journeys

Advanced bietet:

Release Guidance für Überblick über neue Funktionen
Key Feature Advisory für interessante Features
Best Practice Advisory für Einsatzszenarien
Aktivierung des Features zum Testen
Transformation Advisory für die Implementierungs-Roadmap
Kontinuierliches KPI-Monitoring und Optimierungsvorschläge

Max bietet:

Proof of Concept bei großflächigem Rollout
Begleitung der Implementierung
Safeguarding der Implementierung

Was sind Kernprinzipien der Success Pläne von SAP?

Design Prinzipien sind die Folgenden

Umfassendes, maßgeschneidertes Serviceportfolio für alle Phasen
Einheitliches Front Office und eine Governance
Ein Ansprechpartner über alle Lösungen hinweg
End-to-End Betrachtung der Lösungslandschaft
Individueller Serviceplan je nach Situation

Welche Vorteile bieten SAPs Success Pläne?

Flexibilität: Unlimitierter Abruf von Entitlements ermöglicht schnelles Ausprobieren neuer Features ohne Approval-Prozesse oder separate Angebote
Agilität: Schnellere Innovation durch unkomplizierte Service-Nutzung aus verschiedenen Ebenen
Integrated Delivery: Ein einheitliches Governance‑Modell sorgt für eine optimale Lieferung - unabhängig davon, aus welchem Level oder Portfolioelement die Services kommen
Individualisierung: Lösungsspezifische Wahl des passenden Plans - verschiedene SAP-Systeme können unterschiedliche Success Plans nutzen
Ressourceneffizienz: Einsparung interner Ressourcen und externer Beratung durch SAP-Services

Fragen und Antworten zu SAPs Success Plänen

Für wen ist welcher Plan geeignet?
Die Success Pläne eignen sich für alle Kundengruppen. Durch die drei aufeinander aufbauenden Ebenen findet jeder Kunde das passende Modell - abhängig von Komplexität, Bedarf und strategischer Bedeutung der jeweiligen Lösung.

Wie ist die Verfügbarkeit? Das neue Support-Modell startet am 3. März 2026.

Wie ist der Übergang von bestehenden Verträgen?
Laufende Premium Engagement und SAP Preferred Success Verträge bleiben bestehen und laufen über die gesamte Vertragslaufzeit. Nach Vertragsende erfolgt die Überführung in das neue Modell gemeinsam mit dem Kunden. Ein früherer Wechsel ist nach Absprache mit den bekannten Ansprechpartnern möglich.

Gilt das neue Modell nur für Cloud-Kunden? Ja, die Success Pläne sind für Cloud-Lösungen konzipiert. On-Premise-Kunden können weiterhin Premium Engagement Services in einem revidierten Modell nutzen.

Was passiert mit laufenden SAP Preferred Success oder Premium Engagement Verträgen? Bestehende Verträge laufen über die vereinbarte Vertragslaufzeit. Die Überführung ins neue Modell erfolgt nach Vertragsende oder bei Bedarf früher in Abstimmung mit dem Kunden.

Kann man verschiedene Success Pläne für unterschiedliche Lösungen wählen? Ja, Kunden haben volle Flexibilität. Für jede SAP-Lösung kann der passende Plan gewählt werden. Der Max Success Plan stellt dabei die End-to-End-Beratung über alle Lösungen sicher.

Wann sind Kosten und Preise verfügbar? Aussagen dazu sind ab März 2026 möglich.

Für welche Kundengruppen sind die Success Pläne geeignet? Für alle Kundengruppen. Die drei aufeinander aufbauenden Level bieten für jeden Bedarf das passende Modell.

Wo finden sich weiterführende Informationen? Nach dem Launch im März folgt eine dreiteilige Webcast-Reihe in Deutsch und Englisch mit den Schwerpunkten: Überblick über die Success Pläne/ Deep Dive Advanced Success Plan / Deep Dive Max Success Plan. Die Zusammenfassungen sind hier in der SAP Community Gruppe zu finden.

Was sind Tipps für die Praxis? Hierzu wurden folgende Punkte genannt:

Frühzeitig klassifizieren: Bewerten Sie Ihre SAP-Lösungen nach strategischer Bedeutung, Komplexität und Standardnähe, um den passenden Plan zu identifizieren.
Ansprechpartner kontaktieren: Nutzen Sie bestehende SAP-Kontakte für eine individuelle Bewertung und Empfehlung.
Flexibilität nutzen: Denken Sie lösungsspezifisch - nicht jede Lösung benötigt denselben Support-Level.
Entitlements ausschöpfen: Im Advanced und Max Plan sind Services unlimitiert abrufbar. Nutzen Sie diese Flexibilität für schnelle Innovation.
End-to-End betrachten: Lassen Sie sich vom Success Plan Manager oder Expert einen ganzheitlichen Serviceplan erstellen.
Learning Journeys einplanen: Nutzen Sie die integrierten Schulungsangebote für eine erfolgreiche Adoption.
Webcast-Reihe besuchen: Die geplanten Deep Dives bieten detaillierte Einblicke in Advanced und Max Pläne.

Zusammenfassung

SAP reagiert mit den neuen Success Plänen auf veränderte Marktbedingungen und Kundenbedürfnisse. Das dreistufige Modell - Foundational, Advanced und Max - bietet von Self-Service bis zur strategischen Partnerschaft das passende Engagement für jeden Bedarf.

Kernelemente sind Flexibilität, integrierte Delivery mit einer Governance und die Möglichkeit, für unterschiedliche Lösungen verschiedene Pläne zu wählen. Bestehende Verträge bleiben selbstverständlich weiter gültig. Die Success Pläne bündeln SAPs Cloud‑Support‑Kompetenz in einem klar strukturierten Modell, das Stabilität, Innovationstempo und strategische Beratung vereint.

So begleitet SAP Unternehmen durch den gesamten Lebenszyklus ihrer Softwarelösungen. Mehr Infos gibt es hier in den Webinaren.

Accelerate your transformation to the Cloud with SAP Business AI: Live Session March 5, 2026

2026-02-06T20:38:23.731000+01:00

Unlock Faster, Smarter Cloud Migration with SAP Business AI Are you ready to transform your business with AI-driven efficiency? Join our 45-minute live session on March 5, 2026, and explore how SAP’s intelligent toolchain simplifies migration, integrates seamlessly with tools like Signavio and Cloud ALM, and delivers measurable results. Whether you're a project manager, developer, or architect, this session will show you how to accelerate your cloud journey with confidence.

Key Takeaways:

Unified Platform: Replace disjointed tools with an AI-powered solution for seamless workflows.
Live Demos: See how Signavio, LeanIX, and Cloud ALM integrate for measurable results.
Get Started Today: Learn practical steps to begin your transformation with confidence.

Who Should Attend? Project managers, developers, consultants, and architects looking to accelerate cloud adoption with AI.

Register now

Leading AI-Driven Transformation – A New SAP Enterprise Architect Course

2026-02-18T00:05:31.303000+01:00

Our new course, Leading AI-Driven Transformation as an SAP Enterprise Architect, empowers you to master SAP’s latest Business AI strategies and tools. Designed for enterprise architects, this course equips you to drive technology change, shape AI-enabled landscapes, and position SAP solutions confidently to customers.

You will gain practical knowledge on SAP’s Business AI strategy, AI reference architectures, hybrid design patterns, and effective ways to support customers through their AI transformation journey. Don’t miss the chance to upgrade your skills for the future of enterprise IT.

What You’ll Learn

Understand how SAP’s Business AI strategy shapes the enterprise architect’s evolving responsibilities and opportunities.
Use SAP tools to guide AI exploration, architecture design, and early-stage assessments across SAP landscapes.
Recognize common challenges and blockers in AI adoption, and how to overcome them.
Explore hybrid architectures and best practices for integrating AI into existing SAP and third-party environments.
Learn to position AI value to customers and support their end-to-end transformation journey.

Upgrade your skills and lead with confidence—register today for “Leading AI-Driven Transformation as an SAP Enterprise Architect.”

The Path to SAP Cloud ERP Private –Technical Assessment

2026-02-25T07:08:34.797000+01:00

With SAP Cloud ERP Private, SAP removes the complexity of designing, building, and operating SAP software for customers by offering a user- or metric-based subscription that bundles software and tooling licenses, infrastructure, and technical managed services—everything needed to run an SAP solution. Read more about this here: Understanding the Distinct Scope of SAP Cloud ERP Private

To ensure a smooth transition to the cloud, SAP collaborates with each customer and partner on all design, build, and operational topics relevant to SAP Cloud ERP Private, assessing the technical feasibility of each customer’s requirements and handing them over to the business unit within SAP that is responsible for designing, building and operating SAP Cloud ERP Private.

Moving to a cloud subscription service either from an on-premise datacenter or indeed from public cloud IaaS is not a trivial task. It requires due diligence to ensure that all technical and operational requirements are met, and where deviations exist, a solution is achieved to deliver the same business outcome.

To support our customers’ transition to the private cloud, SAP offers a safeguarding process which covers all the technical and operational requirements. This process, which we call Technical Assessment, is delivered by a unit within Global Cloud Operations called Cloud Architecture & Advisory (CAA).

This document explains the role and value of the Technical Assessment process in the journey to SAP Cloud ERP Private. It outlines how SAP works with customers and partners to achieve the following:

Advise on suitable private cloud options and high-level architecture choices
Assess technical requirements and align expectations across stakeholders
Transition the agreed outcomes into a clear and feasible target architecture before delivery

By providing an overview of the assessment domains, decision points, and outcomes, this document aims to give stakeholders a clear understanding of how the Technical Assessment helps ensure a secure, scalable, and successful transition to SAP Cloud ERP Private.

Figure1 : Technical Assessment Flywheel

Advise the customer on the private cloud offerings within the SAP GCO portfolio

A key factor to ensure a successful transition to SAP’s Private Cloud is to understand the private cloud offering and the details of each technical domain such as:

Technical Domain	Expected customer’s stakeholder
SAP Cloud ERP Private Overview	All key stakeholders
Cloud Technical Architecture	Infrastructure, application, basis, and network stakeholders
Network and Integration	Infrastructure, network, and security stakeholders
Cybersecurity and Compliance	Security, network, infrastructure, application, and basis stakeholders
Cloud Managed Services and Operating Model	All key stakeholders
Customer Onboarding	Infrastructure, application, basis, and network stakeholders

Table 1: Technical Domains and expected participants

These domains provide a structured lens to assess customer needs and requirements as well as position the right GCO services. Depending on the complexity of the requirements, some topics will require deep‑dive workshops to reach a shared understanding and robust solution options. This collaborative approach enables tailored architectures and operating models that align to the customer’s objectives and proactively address potential challenges during the move to SAP Cloud ERP Private.

Assess the technical feasibility of the customer’s requirements

Figure2: Technical Assessment aspects

Aligning the customer’s current and target (“to‑be”) state is essential to define a clear path for their cloud journey. This assessment ensures both sides share the same expectations on scope, timelines, and responsibilities.

Throughout this process, SAP validates that the customer’s business and operational requirements can be implemented within SAP’s private cloud delivery standards. It also confirms that the solution follows GCO best practices for business continuity, operations, and cybersecurity.

Some aspects to be covered during the assessment are the following:

Aspect	Topics to be discussed	Decisions to be taken
Deployment option, platform, and region	As described in the blog From On-Premise to Cloud: Making the Right SAP ERP Move, SAP offers several deployment options for SAP Cloud ERP Private, such as hyperscaler, SAP data center, customer data center, and premium suppliers – each available on different platforms and in multiple regions. It is the customer’s responsibility to choose the deployment model and select the platform and target regions, with support from the SAP CAA team to align with requirements, synergies, and the customer’s cloud strategy.	Deployment option (hyperscaler, SAP data center, customer data center, premium supplier) Cloud provider or hyperscaler for the deployment Regions (main and disaster recovery)
Network and communication infrastructure	Each platform provides different private and internet-facing connectivity options. Based on the chosen deployment option, platform, region, and performance needs, the customer must decide how to connect to SAP Cloud ERP Private, including any requirements for network segregation and DNS integration that should be clarified during the Technical Assessment.	Connectivity options for private and public access Bandwidth required DNS integration method (zone transfer, conditional forwarding, etc.) Load balancing requirements
Application platform and integrations	It’s crucial to clarify which bill of materials, applications, and solutions are in scope for the private cloud, how they are offered in the GCO portfolio (for example, high availability, disaster recovery, and SLAs), and how they will integrate with SAP and non‑SAP systems.	Bill of material and solution’s versions Business continuity options and SLAs Technical elements required for integration with SAP and non-SAP systems
Solution sizing	Solution sizing from the customer or partner must be translated into cloud technical sizing (for example, database and storage), since accurate sizing is key for a smooth transition and optimal performance.The blog Sizing Your Success: A Guide to SAP Cloud ERP Private is a recommended reference for this activity.	Target sizing of the different solutions and tiers Expected growth during the contract’s runtime
Security and regulatory requirements	As explained in the blog RISE with SAP: Comparing the Security of SAP S/4HANA Cloud, private edition Vs SAP S/4HANA Cloud, public edition, SAP applies a multilayered security strategy and a zero‑trust approach across its cloud services, with controls such as encryption, access control, auditing, compliance, logging, monitoring, and secure operations governed by SAP standards and policies. This underpins the SAP Cloud ERP Private security and regulatory framework. Each organization also has its own security and regulatory needs, and where specific requirements go beyond the standard framework, SAP reviews them and designs appropriate measures.	Confirm that SAP’s security framework meets the customer’s requirement in terms of cybersecurity and regulation. Identify any special requirement and find a solution for it.
Best practices and operational model	SAP Cloud ERP Private provides several operating models and SLA levels to suit different customer sizes and requirements. This includes defining backup expectations and reviewing roles and responsibilities (for example, via a RACI matrix) to identify and close any gaps. This blog https://www.sap.com/sea/blogs/erp-cloud-without-surprises explains who really does what is SAP Clud ERP Private.	Operational model Availability SLAs for solutions Customer’s specific backup SLA Review of roles and responsibilities RACI matrix to identify potential gaps

Table 2: Technical aspects to be assessed

The outcome of the technical domain sessions and the customer landscape assessment is a clear and accurate “to‑be” picture of the customer environment, including the transformation strategy. This serves as the blueprint to design and build the final landscape in SAP Cloud ERP Private.

Transition the customer’s requirements to GCO for delivery

SAP Cloud ERP Private is a managed private cloud service delivered by Global Cloud Operations (GCO), requiring a structured handover of customer requirements to SAP.

Early transition planning: Although the formal transition begins after the Cloud ERP Private agreement is signed, preparation should start early to avoid deployment delays that could jeopardize the project timeline.

Support process: The Cloud Architect and Advisory (CAA) team guides customers and partners through this process by collecting onboarding information, coordinating milestones, and ensuring smooth delivery to SAP teams.

The following outlines typical onboarding information to be collected:

Type of Input	Input Needed
Operational	Support user (S-user) Type of deployment (greenfield or brownfield) Planned downtime SAP Best Practices activation Financial relevance Customer contact information Regulatory requirements – GxP, HIPPA, data sovereignty Cybersecurity requirements
SAP-specific	System parameters (SIDs, clients, languages, etc.) Target versions
Network and DNS	Connectivity method Connectivity data Private IP addresses ranges DNS information

Table 3: Onboarding information

Outcome of Technical Assessment: baseline and working document

The Technical Assessment process produces the Technical Assessment Report, summarizing all sessions and workshops, the proposed to‑be architecture for SAP Cloud ERP Private, and any assumptions or exceptions from discussions.

This report is shared with the customer for review and sign-off. It serves as the baseline for the commercial contract, delivery onboarding and is a living document throughout the contract lifecycle.

Innovate and grow in SAP Cloud ERP Private

Everything described above represents continuous engagement throughout the entire contract lifecycle, not a one-time effort.

For new customer requirements, the GCO team supports the customer and partner through a renewed technical assessment process. Depending on the requirement, relevant assessment domains and onboarding details will vary, but GCO provides full guidance—advising on goals and value drivers, identifying innovation opportunities, and extending the Cloud ERP Private scope via the change request process.

IaC for SAP BTP: Automating Environment Management with Terraform and CI/CD

2026-02-27T06:03:58.154000+01:00

Introduction

In our previous blogs, we introduced the concept of Infrastructure as Code (IaC) for SAP BTP using Terraform, and how it can help organizations manage their environments in a consistent, repeatable, and automated way.

For Cloud Engineers working outside the SAP ecosystem, this approach is already well established. Running Terraform through CI/CD pipelines, managing remote state, and promoting changes across DEV, QA, and PROD environments is a common DevOps pattern in modern cloud-native architectures.

With SAP BTP, the same principles can now be applied consistently within the SAP landscape. This opens up new possibilities for:

Cloud engineers who are new to SAP and want to apply familiar DevOps and IaC practices.
Experienced SAP administrators who are modernizing their landscape management using Infrastructure as Code and CI/CD automation.

While this article demonstrates the approach using a classic 3-tier landscape (DEV, QA, PROD), the architecture is by no means limited to that scenario. In fact, it becomes even more valuable when applied to medium and large enterprise landscapes, where multiple subaccounts, regions, teams, and services must be provisioned and maintained in a consistent and governed way. Automating these environments through CI/CD significantly reduces operational overhead and improves scalability.

There are multiple options when it comes to integrating Terraform into your automation workflows. For example:

CI/CD platforms to execute: Jenkins, GitLab CI, GitHub Actions, Azure DevOps.
Store state of managed landscape: SAP BTP Object Store, HashiCorp Vault, AWS S3, and more.

In this article, we will focus on a concrete implementation: Jenkins as the CI/CD platform and SAP BTP Object Store as the remote store for the Terraform state file. I'll also demonstrate how to structure the pipeline for a multi-environment landscape (DEV, QA, PROD).

Why This Matters: Key Use Cases

1. Consistent Landscape Provisioning

Organizations often need to provision and update identical landscapes (for example, DEV, QA, and PROD) for multiple development teams or applications. Doing this manually is time-consuming, error-prone, and not scalable.

Certainly, Cloud Engineers and BTP Admins can execute Terraform commands ona local machine or laptop, as we discussed in a previous blog. But of course, in the real world, such operations need to be automated via CI/CD pipelines and embedded in processes.

With CI/CD and Terraform, we can:

Deploy and update environments automatically and consistently.
Manage infrastructure from an external system, not manually.
Enforce corporate policies and naming conventions.
Minimize the workload for Ops teams.
Scale quickly when new teams or projects need their own BTP environments.
Ensure full transparency and auditability through the pipeline.

2. Automated BTP Landscape Management

Beyond provisioning, enterprises need centralized, automated control of SAP BTP environments. This includes:

Provisioning subaccounts, service instances, entitlements, and roles.
Enabling self-service deployments for development teams.
Enforcing governance and segregation of duties across environments.
Reducing time-to-market for new services and solutions.
Integrating seamlessly with existing DevOps processes.

Provisioning of new and updating of existing subaccounts should be a part of the new application deployment, mainly to have a consistent environment across landscape.

Architecture Overview

In our scenario, we would like to automate the provisioning of a 3-tier landscape, with a similar configuration inside, follow the naming convention, and also save the states of our subaccounts in an external S3 bucket. At the moment, via CI/CD pipeline, without governance(I will cover it in the next blog).

The setup described here is based on:

GitHub repository to store our Terraform configuration files.
We will use Terraform providers from SAP to manage SAP BTP resources.
Jenkins CI/CD platform for pipeline orchestration.
SAP BTP Object Store for storing the Terraform state (terraform.tfstate file).
Multiple environments (DEV, QA, PROD) managed via dedicated state files.

A high-level flow looks like this:

Cloud Engineer/Basis Admin commits Terraform configuration to Git.
Jenkins triggers pipeline execution. Basically, it can be triggered by GitHub webhook, or run by schedule, via API from an external system, or manually.
The state file is stored in SAP BTP Object Store.
Depending on the selected parameters (apply, show, destroy), a different subset of operations will be executed.
Changes are applied to the targeted environment (DEV, QA, or PROD), also based on the input parameters for pipeline execution.

Remote State Management

Terraform uses the state file (terraform.tfstate) to track the current infrastructure, and calculate changes in case of update or destroy. For multi-team, multi-environment setups, storing this state remotely is critical.

In our case, I'll use SAP BTP Object Store as the store for state files separated per subaccount:

Each environment (DEV, QA, PROD) has its own path and state file.
Remote state ensures collaboration without conflicts.
Access is controlled through Object Store policies and Jenkins credentials.

This provides consistency, security, and scalability when our Jenkins pipeline interacts with multiple BTP subaccounts.

Multi-Environment Strategy

There are two common approaches to managing multiple environments:

Terraform workspaces
Separate state files per environment (our case).

In our setup, Jenkins pipelines are parameterized by environment.

A pipeline may run for Dev, QA and Prod.
Each environment has its own state stored in Object Store.
Promotion of changes follows the lifecycle DEV → QA → PROD, ensuring controlled rollout.

CI/CD Pipeline with Jenkins

Our pipeline for provisioning and manage BTP landscape in Jenkins includes the following steps:

Terraform Init. Basically, pipeline pulls data from GitHub and initialize terraform config, dowload providers and etc.
- Terraform plan. On this step, Terraform(in a container, I described this part in the previous blog) calculates what should be done based on the tfstate file(in case of update or destroy), or the deployment plan in case of a new deployment.
Terraform apply. Deployment execution based on the calculated plan.
Terraform destroy. Destroy the subaccount in case of decommissioning. Would be more relevant for the temporary subaccount deployed for test purposes
Send Request to SAP CALM(I'll skip this step in this blog.)

An important note.

Terraform init.
- Configure Terraform to use SAP BTP Object Store as the store for tfstate files and provide a naming convention for tfstate files.

Based on the configuration of my pipeline in Jenkinsfile, when we run the Jenkins pipeline manually, we can see the input window where we can choose what and where we want to execute.

Uses Jenkins parameters to choose the environment. In the future, we will automatically pass these parameters via API
Loads credentials securely.
Runs the full Terraform cycle from init to apply/destroy.
Stores the state file with information of provisioned/updated landscape in BTP Object Store bucket.

Below result of execution with the log of what was provisioned.

Conclusion

By combining Terraform, Jenkins, and SAP BTP Object Store, organizations can build a scalable and repeatable automation framework for managing SAP BTP environments.

This approach enables:

Faster and more reliable provisioning of landscapes.
Reduced manual effort and operational risks.
Clear separation of environments with controlled promotion paths.
Integration into broader DevOps and compliance processes.

In the next blog, we will explore how to integrate Terraform-driven automation with SAP Cloud ALM, extending Infrastructure as Code to the operational lifecycle of BTP landscapes.

Let's Talk: Transformation (Webinar Series)

2026-04-03T11:04:03.873000+02:00

We invite you to participate in these engaging roundtable sessions. It’s your chance to:

- Share your organization’s experiences and learn from industry peers.

- Explore best practices in transformation programs.

- Gain actionable insights to propel your organization forward.

Together, let’s drive impactful changes and ensure your journey with cloud solutions is both rewarding and successful.

Let's Talk Transformation - Session Calendar 2026

Virtual roundtable sessions for H1 2026 (HR Connect in-person events excluded). All sessions are live via Teams/Zoom.

Session Title	Date	Time	Region	Registration Link
Sustaining your Cloud Solution	April 9, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	April 15, 2026	7:00 PM UTC / Apr 16 2:00 AM AEST	APJ	Register Here
Modelo de Gobierno / Governance Model	April 21, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Sustaining your Cloud Solution	April 21, 2026	7:00 PM UTC / Apr 22 2:00 AM AEST	APJ	Register Here
Efficient Data Management	April 22, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	April 23, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Gestion de Partners / Partner Management	April 27, 2026	9:00 AM UTC / 11:00 AM MEX / 4:00 PM CHILE	LATAM	Register Here
Efficient Data Management	April 28, 2026	8:00 PM UTC / Apr 29 3:00 AM AEST	APJ	Register Here
Sostenimiento de la Solucion de Nube / Sustaining your Cloud Solution	April 29, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Managing Continuous Change	May 6, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Transforming HR with AI	May 7, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	May 11, 2026	7:00 PM UTC / May 12 2:00 AM AEST	APJ	Register Here
Transformando RH con IA / Transforming HR with AI	May 12, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
How Future to Present Focused HR is Shaping Cultures	May 14, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
How HR is Future to Present is Shaping Mindsets	May 18, 2026	8:00 PM UTC / May 19 3:00 AM AEST	APJ	Register Here
Gestion de Partners / Partner Management	May 19, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Efficient Data Management	May 20, 2026	8:00 PM UTC / May 21 3:00 AM AEST	APJ	Register Here
Value Management	May 21, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Transforming HR with AI	May 24, 2026	6:00 PM UTC / May 25 1:00 AM AEST	APJ	Register Here
Sustaining your Cloud Solution	May 26, 2026	7:30 PM UTC / May 27 2:30 AM AEST	APJ	Register Here
Modelo de Gobierno / Governance Model	June 2, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
AI Adoption & Activation – Getting the most from SuccessFactors AI –Session 2	June 4, 2026	9 am CT US 4pm CET Europe	EMEA/AMS	Register Here
Sostenimiento de la Solucion de Nube / Sustaining your Cloud Solution	June 9, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Managing Continuous Change	June 9, 2026	7:00 PM UTC / Jun 10 2:00 AM AEST	APJ	Register Here
Sustaining your Cloud Solution	June 11, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Sustaining your Cloud Solution	June 16, 2026	7:30 PM UTC / Jun 17 2:30 AM AEST	APJ	Register Here
Efficient Data Management	June 18, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
AI Adoption & Activation – Getting the most from SuccessFactors AI –Session 2 (Spanish)	June 24, 2026	6:00 PM UTC / Jun 24 1:00 AM AEST	APJ	Register Here
Managing Continuous Change	June 25, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Transforming HR with AI	July 2, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	July 20, 2026	8:00 PM PDT/ 3:00 AM UTC/ 4:00 AM CET	APJ	Register Here
AI Adoption & Activation – Getting the most from SuccessFactors AI –Session 3	July 23, 2026	9am CT US 4pm CET Europe	EMEA/AMS	Register Here
AI Adoption & Activation – Getting the most from SuccessFactors AI –Session 3 (Spanish)	July 28, 2026	10 am MEX 12 pm CHILE	LAC	Register Here

Introducing Architecture Switching in SAP Solution Scout

2026-04-08T18:00:00.021000+02:00

See the Right Solutions with Ease

Cloud Architecture: Dynamically showcase public cloud solutions centred around “SAP S/4HANA Cloud Public Edition,” for unmatched scalability and speed.

Hybrid Architecture: Effortlessly explore a blend of public cloud components with private cloud or on-premises elements via “SAP S/4HANA Cloud Private Edition,” or “SAP S/4HANA.”

Unlock These Benefits

Precision Filtering - See only the most relevant solutions based on your chosen architecture.
Faster Decisions - Save time by focusing on the best-fit options for your specific needs.
Strategic Readiness - Ensure your chosen solutions align with your long-term business goals.

Empower your digital transformation journey with SAP Solution Scout’s enhanced flexibility, making it easier than ever to find the perfect solutions tailored just for you.

Start Navigating Your Ideal Solutions with SAP Solution Scout Today!

Build BTP CAP App with Fiori Integration – Part 2: Implementing End to End App

2026-04-09T10:05:19.668000+02:00

A quick Recall - So far we have completed the Pre-Requisites and set up the BTP Environment for creating/Deploying CAP Application. BTP Trail Account has been created and within Trail sub-account necessary cloud related roles have been assigned. Post that SAP HANA Cloud instance has been created and BAS Set up has been done.

PART 1 Link - Building a CAP App with Fiori Integration – Part 1: Environment & HANA Cloud Setup

As a part of second episode in this CAP Application blog series, we are about to develop an end to end CAP Application with layers of validation of security in a detailed way. This blog helps beginner to build end to end CAP Application.

Flowchart giving overview for complete Process

Ever struggled to deploy a CAP app with HANA + XSUAA + App router?.

I did. After multiple failures, here is a complete working guide 👇

BACKEND BUILD :

1. Navigate to BAS->Dev Space and Create new project from Template.

After creating CAP Project Run these Below terminal Commands which has unique operation.

a. This below terminal command to be added which will prepare the CAP project for a real-world cloud environment i.e. SAP BTP. add hana will switch database from SQLITE to HANA Cloud & add xsuaa will enable authorization for the project. Also When we ran the command cds add xsuaa --for production then CAP automatically generates the security folder xs-security.json.

cds add hana,xsuaa --for production

b. Below terminal command will add blueprint for deployment.

cds add mta

c. Below terminal command will install libraries.

npm install

2. Select CAP Project Option and name the project and select options as below.

3. Click on Finish after selecting all the options.

4. Once Project is created it will be available in the Workspace.

5. We can view the path of the project created using below Terminal command. ( Note : Use Ctrl + ~ to open terminal ).

user: CRUDApp $ pwd

Once this Terminal command is entered the response will come as /home/user/projects/CRUDApp.

6. Now the Project is created. The Aim is to create service instance in Cloud Foundry space dev which I shown in PART 1 and through the service instance the linkage to HANA Cloud central DB Instance will be triggered with runtime HDI Container created. Through this HDI Container the Deployment data will be mapped to runtime DB.

Before getting into next point. Let me give a quick overview on different folder paths/ files in CAP Project that has been created. ( Refer to the workspace image from Point 4. )

a) db/ - This is database schema where we will create CDS Entities/tables and it's relationships. It’s is the source of data structure.

b) app/ - In this folder the front end Fiori Generator App will be mapped which has further navigations to Controllers and views. From here only we will write front end logic.

c) srv/ - This is service folder where api services will be created from backend and if required custom logic can be enabled using node js in js file.

d) .vscode - This is a hidden folder containing configurations specific to Visual Studio Code or BAS. It stores things like your launch configuration and recommended extensions for the project.

e) mta.yaml - Multi-Target Application file is the provides instruction to cloud. It tells SAP BTP how to package and deploy your app, which database to create, which security services to bind, and how much memory to use.

f) package.json - This is the Project Meta data which holds libraries to run project.

Now let's continue with further steps from Backend.

7. Create a file schema.cds as below to /db folder and create Entity bookshop. This Entity is designed to store Book details. The same will be created as table in SAP HANA Cloud.

namespace my.bookshop;

entity Books {
  key ID    : Integer;
  title     : String;
  stock     : Integer;
  author    : String;
}

8. Create a file schema.cds as below to /srv folder. In this Service folder we are adding annotation @requires: 'Admin' which indicates Role required for Authorization.

using { my.bookshop as my } from '../db/schema';

service CatalogService {
    @requires: 'Admin'  // XSUAA Role Required
    entity Books as projection on my.Books;
}

FRONT END BUILD:

1. Click Ctrl + Shift + P and select Open Fiori App Generator as shown below.

2. Since this is a basic app and henceforth Select List Report Template as below.

3. Now select Data source as Local CAP Project and select CAP Project and OData service. After this select on Next button.

4. Give Name to App and Module.

5. Then Deployment configuration should be auto-picked as cloud foundry and If required fill Destination. For this app Im not creating Destination and henceforth selection the option as None. After this select Finish option which will create Fiori App in Project Folder.

VALIDATION :

1. Create a file cat-service.js as below to /srv folder.

const cds = require('@sap/cds')

module.exports = cds.service.impl(async function() {
    const { Books } = this.entities;

    // Logic: Validation BEFORE creating a record
    this.before('CREATE', 'Books', req => {
        const { title } = req.data;
        if (!title || title.length < 3) {
            // This is like an 'E' message in ABAP
            req.error(400, 'Title is too short! Minimum 3 characters required.');
        }
    })
})

2. As per above logic, we are adding some validation before SAVE using Node JS Function. As per this validation if Title length is less than 3 then error will be thrown. Similarly we can use other functions as well to perform business operation which triggers during save, After save etc.

SECURITY:

1. When the Environment was set up in BACKEND BUILD->1.a), we ran the command cds add xsuaa --for production which in turn created the folder xs-security.json.

2. Now the aim is to deploy the app to production and create HTML5 App in BTP. So here we are adding a security layer which tells only Authorized user can access the data. While defining the service in BACKEND BUILD->8. where Admin role is annotated to books entity.

3. Lets create Approuter now and configure JSON to add necessary roles.

4. There are two options for adding Approuters.

a. Right click on mta.yaml file and select Create MTA Module From Template and then select Managed Approuter.

b. If Managed Approuter option is not showing, then below terminal command is a reliable 'Reset' button. It cleans up the MTA configuration and sets up a standalone router that works independently of external BTP subscriptions.

cds add approuter

5. Currently Im going with 4.b) with manual terminal command for adding Approuter. Once that is done then approuter will be added as below in app/ folder.

6. Add below JSON to folder xs-security.json in project which will define the role which is binded in service and yaml.

{
  "xsappname": "my-bookshop",
  "scopes": [
    {
      "name": "$XSAPPNAME.Admin",
      "description": "Admin"
    }
  ],
  "role-templates": [
    {
      "name": "AdminRole",
      "scope-references": [ "$XSAPPNAME.Admin" ]
    }
  ],
  "attributes": [],
  "authorities-inheritance": false
}

DEPLOYMENT:

1. So till now we have built this CAP Application in "Vertical Stack" (Database → Logic → Security → Routing → UI).

2. Now before final deployment lets test the things done till now is correct. Use below terminal command. If everything is fine then You see your database schema, custom logic, approuter config, and Fiori manifest listed.

ls -R | grep -E "schema.cds|cat-service.js|xs-app.json|manifest.json"

3. Now compile all the files to check if any error occurs. Use below terminal commands.

cds compile db/
cds compile srv/
cds compile srv/ --to xsuaa

Note: All these commands should not throw error to proceed with next steps.

4. After Sanity checks, run below command to login to terminal. Note: It will ask for Api Endpoint for first time during login. It can be found from BTP Cockpit -> Overview -> Cloud Foundry Environment -> API End Point.

cf login

5. Now run Deployment command in terminal. This is done to test the app locally. Once testing is completed the app needs to be deployed to Production.

cds deploy --to hana --profile hybrid

6. If cds deploy is not working properly then define step by step process of creating service instance, HDI Containers etc. through terminal commands below. Note: cds deploy will create everything by default so dont use these in combination. use these terminal commands only if cds deploy is not working.

cf create-service hana hdi-shared my-cap-app
cds bind --to my-cap-app
cds env get requires.db --profile hybrid
cds deploy --to hana --profile hybrid

7. Run below commands to deploy the app to production.

mbt build

8. When finished, a new folder named mta_archives/ will appear as below containing Project file.

9. Now do a login again with below command. Give appropriate API Key and user details.

cf login

10. Run below command to Complete final HTML5 App deployment.

cf deploy mta_archives/CRUDApp_1.0.0.mtar

Note: Sometimes Deployment will fail. To avoid these common pitfalls, "Only include essential resources (HANA, XSUAA, Destination, and HTML5) in your mta.yaml and ensure your xsappname in xs-security.json is consistent throughout the project to prevent service plan unavailability and identity mismatch errors on Trial accounts." If something fails, make these changes and delete the service and redeploy. After redeployment dont forgot to add role collections again to make sure Approuters will not cause auth errors.

TESTING

1. Run below Terminal command to test the app locally.

cds watch --profile hybrid

2. After this the app will open in next screen to test it from web level. Note: Make sure your HANA DB Instance is running in HANA Cloud Central which will create entry in DB Level.

3. Now while testing this app we can see the user login screen which will ask for mail and password for login. This is happening due to XSUAA and Approuter. While trying to make entry to the app it will show error forbidden as below.

4. Now run this command below to create service Instance first. Even after cds deploy this is required because cds deploy only talks to the Database (HANA). It does not talk to the Security Service (XSUAA). In SAP BTP, the database (CRUDApp-db) and the security (XSUAA) are two completely separate buildings. This terminal logic is required to enable link.

cf create-service xsuaa application CRUDApp-auth -c xs-security.json

5. Post this navigate to BTP Cockpit -> SubAccount -> Security -> Role Collections and click on Create Button as below.

6. Create Role collection Bookshop_Admin_Group with its Description as below.

7. Now Navigate to the Role collection Bookshop_Admin_Group and click on Edit. Open value help of Role and select the App name from Application Identifier dropdown. After selecting Role Admin which enables Authorization, click save. Follow below images sequentially.

8. After saving, the role will be available in Role collection as below.

9. Now refresh the app and try running, It will work !. Note: Sometimes Auth error will still occur if you test locally. In that case assign your URL to user Alice or deploy and test the app.

10. Also once deployed to HTML5 Apps or Dev space, the app can be directly tested from there as well.

FINAL APP EXECUTION🔥:

1. Now, lets open the app as below.

2. Lets create some incorrect entries as below.

3. Validation Error occurs as per Node js logic for incorrect inputs.

4. While creating valid records, Data gets created as below without any auth error/Forbidden as the custom role collection created and mapped to Admin Role. Note: Unique UUID will be generated for each record as per CAP Entity definition made. The UUID can be viewed in Cloud DB.

5. Now navigate to SAP HANA Cloud and click on ... dots. select option "OPEN IN SAP HANA Database Explorer".

4. Once SAP HANA Database Explorer opens then login to cloud foundry Environment from there.

5. Now select the "+" icon and select HDI Containers options and then select app container specific to app name.

7. From CRUDAPP-db HDI Container, Navigate to Tables and select open data.

8. The Data created from Fiori App is available in Cloud Table as below along with UUID auto-generated.

CONCLUSION:

Hence the overall flow looks as below.

Fiori UI
↓
App router
↓
CAP Service
↓
HANA DB (HDI Container)

With this blog series we learned how to set up environment, enable cloud instance, create end to end CAP Full stack application which has capability to communicate with SAP HANA Cloud instance and create entries over there, enable App routers to CAP App and Enable validation while creating entries.

I hope this blog will be helpful for enthusiasts who are learning CAP !. In future I will create add-on series with steps to deploy this app to SAP Build work zone.

SAP Success Pläne - Der Guide zum neuen SAP Support und Service Modell 2026

2026-04-13T17:41:45.822000+02:00

Dieser Blog ist eine Zusammenfassung verschiedener Quellen zu den Success Plänen von SAP. Stand: April 2026. Zudem verlinke ich zunehmend Details wie vertiefende Informationen zu den Success Plänen.

Inhaltsverzeichnis

Das Wichtigste in Kürze
Warum SAP sein Support-Modell umstellt
Die drei SAP Success Pläne im Überblick
3.1 Foundational Success Plan
3.2 Advanced Success Plan
3.3 Max Success Plan

Vergleich: Foundational vs. Advanced vs. Max
Was sich gegenüber dem alten Modell ändert
Continuous Transformation und Business AI
Entscheidungshilfe: Welcher Plan passt?
Migration
Häufige Fragen (FAQ)
Weiterführende Artikel und Deep Dives
Fazit

1. SAP Support in der Cloud - Die Success Pläne von SAP

SAP hat am 3. Maerz 2026 ein neues Service- und Supportportfolio für Cloud-Kunden eingeführt. Das bisherige Nebeneinander aus Enterprise Support, Preferred Success und Premium Engagement weicht einem klar gestaffelten Modell aus drei aufeinander aufbauenden Success Plänen:

Foundational Success Plan - automatisch in jeder SAP-Cloud-Lösung enthalten. Deckt Onboarding, technischen Cloud-Betrieb, präventiven 24/7-Support und Self-Service-Ressourcen ab.
Advanced Success Plan - ergänzt spezialisierte Expertise, KI-gestützte Guidance, proaktive Risikoerkennung, verbesserte SLAs und einen Success Plan Advisor.
Max Success Plan - die strategische Partnerschaft. Enthält alle Advanced-Leistungen plus dedizierte Success Plan Manager, lösungsübergreifende Prozessoptimierung und kundenspezifische KI-Prototypenentwicklung.

Das Modell gilt ausschließlich für SAP-Cloud-Lösungen. On-Premise-Kunden behalten ihren bestehenden Support. Bestehende Verträge werden zum Laufzeitende oder auf Wunsch früher überführt.

2. Warum SAP sein Support und Service Modell umstellt

Enterprise Support, Preferred Success, Expanded Edition, ActiveAttention, MaxAttention, Premium Engagement Services - die Bezeichnungen waren vielfältig, die Abgrenzungen nicht immer ganz trennscharf. Für Kunden sollte es einfacher sein in Zukunft, das passende Support-Paket zu identifizieren.

Gleichzeitig erfordern Cloud-Lösungen einen anderen Service & Support: automatisiertes Monitoring, KI-gestützte Empfehlungen und kontinuierliche Innovation statt Fokus auf einmaliger Implementierung. SAP reagierte daher mit einer Vereinfachung.

With our renewed SAP Services and Support portfolio, we provide [customers] a clearer path to adopt innovation, apply AI responsibly, and run their landscape with confidence. - SAP Executive Board Member Thomas Saueressig (SAPNews)

Die zentralen Treiber:

Vereinfachung: Drei klare Stufen statt ein Flickenteppich aus Einzelangeboten
Cloud-Fokus: Support für automatisiertes Monitoring und kontinuierliche Updates
KI-Integration: Joule und intelligentes Monitoring als fester Bestandteil
Transparenz: Klar definierte Leistungsstufen mit nachvollziehbaren SLAs
Kontinuierliche Transformation: Vom einmaligen Projekt zur fortlaufenden Partnerschaft

3. Die drei Success Pläne von SAP im Überblick

Die drei Pläne bauen aufeinander auf. Kunden können für unterschiedliche SAP-Lösungen unterschiedliche Pläne wählen.

“Like a car, I can strategically steer the engagement in the direction that will serve our needs.”
- Vinci Energies CIO Dominique Tessaro

3.1 Foundational Success Plan - Die Basis für alle Cloud-Kunden

In jeder SAP-Cloud-Lösung ist dieser Plan ohne zusätzliche Kosten enthalten. Er baut auf Enterprise Support auf und erweitert ihn um Cloud-spezifische Komponenten. Er ist für Unternehmen geeignet mit erfahrenen internen Teams, die ihre SAP-Umgebung weitgehend eigenständig betreiben.

Enthaltene Leistungen:

Präventiver 24/7-Support für geschäftskritische Systeme mit definierten SLAs
SAP Cloud ALM: Guidance und Monitoring für den gesamten Anwendungslebenszyklus
Self-Service-Ressourcen: Lösungsdokumentation, kuratierte Inhalte, Learning Journeys
Joule: KI-Assistent fuer Echtzeit-Unterstützung
SAP for Me: Zentrales Kundenportal fuer Support-Cases und Systemstatus

>> Deep Dive: die Success Pläne im Überblick

3.2 Advanced Success Plan - Proaktive Guidance

Dieser Plan löst SAP Preferred Success und SAP Preferred Success Expanded Edition ab. Er eignet sich für Unternehmen mit komplexeren Landschaften und höherem Innovationsbedarf.

Zusätzlich zu allen Foundational-Leistungen:

Verbesserte SLAs: Beschleunigte Reaktionszeiten
KI-gestütztes Monitoring: Intelligente Qualität- und Performance-Überwachung
Proaktive Risikoerkennung
Aktivierungssessions für neue Funktionalitäten und Releases
Gezielte Product Release Guidance
Success Plan Advisor als persönliche Ansprechpartner
Business AI Guidance: Potenzialanalyse, Aktivierung, Optimierungsempfehlungen

>> Deep Dive: Advanced Success Plan im Detail (Summary eines Webinars zum Thema)

3.3 Max Success Plan - die Strategische Partnerschaft

Dies ist SAPs umfassendstes Engagement-Angebot und integriert die bisherigen Premium Engagement Services. Für komplexe Transformationsprojekte und eine enge strategische Partnerschaft mit SAP.

Zusätzlich zu allen Advanced-Leistungen:

Dedizierte Success Plan Manager fuer ganzheitliche Betreuung
Lösungsübergreifende End-to-End-Prozessoptimierung
Kundenspezifische KI-Prototypenentwicklung
Strategische Roadmap: KI-Strategie, Daten- und Architekturplanung
Vor-Ort-Support bei kritischen Projekten
Viele weitere inkludierte Services, z.B. rund um die integrierte SAP Toolchain

>> Deep Dive: Max Success Plan im Detail (Summary eines Webinars zum Thema)

4. Vergleich: Foundational vs. Advanced vs. Max

Hier ist eine Gegeüberstellung der drei Varianten:

5. Was sich gegenüber dem alten Modell ändert

Die Umstellung betrifft ausschließlich SAP Cloud-Kunden.

Vorher: Ein fragmentiertes Portfolio

Enterprise Support: Basis für alle Kunden
Preferred Success / Preferred Success Expanded Edition: Erweiterter Cloud-Support als Abonnement
ActiveAttention / MaxAttention / Premium Engagement: verschiedene Premium-Angebote

Nachher: Drei klare Stufen

Foundational = erweitert Enterprise Support (Cloud)
Advanced = loest Preferred Success ab
Max = integriert Premium Engagement Services

6. Kontinutierliche Transformation und Business AI

Hinter den Success Plänen steht ein Paradigmenwechsel: weg von punktuellen einzelnen Projekten, hin zu kontinuierlicher Transformation. Support greift nicht erst bei Problemen, sondern agiert proaktiv, durchgängig und KI-gestützt.

Durchgängig: Begleitung des gesamten Kundenlebenszyklus
Proaktiv statt reaktiv: KI-Monitoring erkennt Risiken vor Geschäftsauswirkungen
Skalierbar: Pro Lösung kann man den passenden Plan wählen und bei Bedarf wechseln

Die Futurum Group kommentierte: "SAP hat sein Portfolio erneuert, um Unternehmen den Übergang von episodischen Transformationsprojekten zu einem Modell des kontinuierlichen, messbaren Fortschritts zu ermöglichen."

7. Entscheidungshilfe: Welcher Plan passt für mich?

Die Wahl hängt von Komplexität, internen Kapazitäten und Innovationsbedarf ab.

Foundational:

Erfahrenes internes SAP-Team vorhanden
Sehr standardnahe Cloud-Landschaft
Self-Service-Ressourcen ausreichend

Advanced:

Komplexere Landschaft mit mehreren Cloud-Lösungen
Proaktive Release- und Innovationsbegleitung nötig
Kürzere, bessere SLAs und KI-Potenzialanalyse gewünscht

Max:

Grosse, heterogene, hybride Landschaften mit lösungsübergreifenden Abhängigkeiten
Komplexe Transformation oder strategische KI-Partnerschaft
Dedizierter Manager gewünscht

Tipp: Für unterschiedliche Lösungen koennen verschiedene Pläne kombiniert werden - z. B. Advanced für SuccessFactors, Max für SAP Cloud ERP.

8. Migration und Preise

Übergang zum neuen Modell

Neue Cloud-Verträge ab 3. Maerz 2026 direkt im neuen Modell
Bestehende Verträge: Überführung zum Laufzeitende oder auf Wunsch früher
Entscheidung ist lösungsbezogen - nicht pauschal für die gesamte Landschaft

Nächste Schritte für bestehende SAP Kunden:

Bestandsaufnahme: Welche Cloud-Lösungen und welchen Support-Vertrag haben Sie?
Leistungsvergleich: Deckt Foundational Ihren Bedarf, oder brauchen Sie mehr?
Budgetplanung: Advanced und Max sind kostenpflichtig.
Kontakt: Sprechen Sie mit Ihrem SAP Account Executive oder Services Kontakt.

9. Häufige Fragen (FAQ)

Was sind die SAP Success Pläne?

Das neue, dreistufige Service- und Supportmodell von SAP für Cloud-Kunden: Foundational (in der Cloud-Lösung enthalten), Advanced (erweiterter Support mit KI-Guidance) und Max (strategische Partnerschaft mit dedizierten Experten). Eingeführt am 3. Maerz 2026.

Wann treten die Success Pläne in Kraft?

Seit dem 3. Maerz 2026. Neue Cloud-Verträge werden im neuen Modell abgeschlossen. Bestehende Verträge werden zum Laufzeitende oder auf Wunsch vorzeitig ueberführt.

Was kostet Advanced bzw. Max?

Vertragsabhängig - SAP veröffentlicht keine Listenpreise. Konkrete Preise über Ihren SAP Account Executive.

Muss ich als Cloud-Kunde etwas tun?

Kurzfristig nein - Foundational ist automatisch enthalten. Prüfen Sie frühzeitig, ob Advanced oder Max zu Ihrem Bedarf passt.

Gilt das Modell für On-Premise?

Nein. Die Success Pläne gelten ausschließlich für SAP-Cloud-Lösungen.

Kann ich verschiedene Pläne pro Lösung wählen?

Ja. Volle Flexibilitaet - z. B. Advanced fuer SuccessFactors, Max fuer die KI-Strategie oder Cloud ERP.

Was passiert mit Preferred Success?

Wird durch den Advanced Success Plan abgelöst. Migration zum Vertragslaufzeitende oder auf Wunsch früher.

Advisor vs. Manager - was ist der Unterschied?

Der Advisor (Advanced) ist persönlicher Ansprechpartner für die strategische Ausrichtung. Der Success Plan Manager (Max) ist dediziert, kennt Ihre Landschaft im Detail und beratet Sie lösungsübergreifend.

Welche Rolle spielt Cloud ALM?

Teil des Foundational Plans für alle SAP Cloud-Kunden: für Monitoring, Change Management, Operations. Im Advanced um KI-Monitoring erweitert.

Wie helfen die Pläne bei KI Einführungen?

Foundational: Zugriff auf Lösungsdokumentation über help.sap.com, Learning Journeys, Aktivierung von Joule über Self-Services.
Advanced: Zusätzliche Leistungen zur Identifikation des Business AI Potenzials, strategische Aktivierung von Anwendungsfällen, fortlaufende Produktberatung, Guidance und Optimierungsempfehlungen.
Max: Definition der KI-Strategie, Erstellung einer Daten- und Architektur-Roadmap, Entwicklung einer Strategie und von Prototypen für maßgeschneiderte KI-Anwendungsfälle.

10. Weiterführende Artikel und Deep Dives

Weitere Infos s.o. in den Deep-Dives.

11. Fazit

Die SAP Success Pläne vereinfachen in ein über Jahre gewachsenes Service und Sport Portfolio. Foundational bietet allen Cloud-Kunden eine solide Basis ohne Zusatzkosten - mit Cloud ALM, Joule und 24/7-Support. Advanced und Max liefern abgestufte Upgrades für Unternehmen mit höherem Bedarf an SLAs, proaktivem Monitoring oder strategischer Partnerschaft.

Die Frage ist, welchen Plan Ihr Unternehmen braucht, um das Maximum aus seiner SAP-Cloud-Investition herauszuholen.

Wo finden sich weiterführende Informationen? Im März folgt eine dreiteilige Webcast-Reihe in Deutsch und Englisch mit den Schwerpunkten: Überblick über die Success Pläne/ Deep Dive Advanced Success Plan / Deep Dive Max Success Plan. Die links zu den Zusammenfassungen incl. Folien finden sie oben unter 3.2 und 3.3.

Zusätzlich ist am 25.06. ein Vor-Ort Event geplant in Walldorf – Details finden Sie hier.

Quellen

SAP News (DE): SAP entwickelt Service- und Supportportfolio weiter, 3. März 2026
SAP News: Orchestrating Continuous Transformation, Thomas Pfiester, März 2026
SAP Community: SAP Success Plans - Der neue Support-Ansatz fuer die Cloud, 05.02.2026
CIO.com: SAP shakes up its service and support portfolio, März 2026
Computerwoche: SAP stellt Support-Portfolio um, März 2026
Futurum Group: SAP New Services Portfolio, März 2026

An SAP Enablement Story: How Elementar and Cideon Reduced Friction in Product Development

2026-05-04T16:59:45.838000+02:00

Welcome to this blog post! In today's edition, I want to share a practical SAP enablement story from the German-speaking SAP community – featuring Elementar Analysensysteme GmbH and their implementation partner Cideon. This story originally aired as a special German-language episode of the Inside SAP HANA Cloud podcast.

No time to read? Listen to the full episode on https://url.sap/941u5n Spotify or https://url.sap/bq5 x0x Apple Podcasts.

In this blog, you will find out how a mid-sized, owner-managed manufacturer:

Replaced a fragmented ERP/PDM landscape with a unified, SAP-native approach
Used SAP Engineering Control Center (ECTR) to eliminate synchronization overhead between product development and logistics
Chose a single implementation partner to reduce coordination friction and avoid the classic "blame game"
Built the data quality and process discipline needed to scale adoption step by step
Laid the groundwork for mechatronics integration and AI-enabled automation

This story is relevant for any engineering or manufacturing organization that is grappling with the handoff between product development and SAP S/4HANA – and wondering how to make that transition stick.

Meet the Participants

Dr. Sebastian Schmitt – Head of Product Development, Elementar Analysensysteme GmbH
Peter Vandrey – Head of SAP Solution Management, Cideon (SAP and Autodesk partner, specializing in PLM integrations)

Company Snapshots

Elementar Analysensysteme GmbH is an owner-managed company headquartered in Langenselbold near Frankfurt, with around 320 employees worldwide and a second production and engineering site in Manchester. The company develops and manufactures analytical instruments for elemental analysis, stable isotope analysis, and optical emission spectrometry – built for long service lives of ten to twenty years. Their customers range from contract laboratories and pharmaceutical companies to wastewater treatment plants, food analytics operations, and research institutions. Elementar does not operate as a project business. They develop series products – which means data consistency, lifecycle traceability, and smooth handoffs between engineering and production are not optional: they are central to the business model.

Cideon has been an SAP development partner since 1996 and an Autodesk partner in parallel – covering software sales, consulting, and training. In the SAP space, Cideon's focus is on PLM integrations: specifically, the interfaces between engineering environments and SAP S/4 HANA, spanning on-premise, private cloud, and public cloud scenarios.

The Starting Point: A New ERP, No PDM, and Many Moving Parts

In 2021 and 2022, Elementar rolled out SAP S/4HANA (private cloud) – a major transition for the entire company. They were coming from a small ERP system with no clearly defined PDM system in place. In the legacy environment, data exchange between product development and the rest of the business relied on a web of manually maintained interfaces and synchronizations.

The go-live decision was deliberate: rather than waiting until every process was perfect, the team went live with SAP S/4HANA first – and then immediately launched a follow-on project to define how product development data would flow into SAP going forward. As Dr. Sebastian Schmitt puts it: "We needed to create awareness in my area around data: data quality, data management – how you handle data overall. Those are just a few of the challenges, and they shouldn't be underestimated." This step-by-step approach – stabilize first, then improve – turned out to be one of the key success factors of the entire engagement.

Success Factor #1: Listen First, Understand the Process, Then Decide on Standard

When Cideon came on board, the first priority was not to configure software. It was to understand how things actually worked. As Sebastian describes it, Cideon's team "sat down at one table and talked through: how do workflows and processes work today, and how should they improve? Then they listened a lot at first, which I personally appreciated – because we could describe the current situation and where we had seen gaps and problems with the old systems."

Only after that listening phase did the team begin mapping what could stay close to standard – and where adjustments were genuinely necessary. This approach avoided two common failure modes: over-customizing too early (before understanding the real process) and under-delivering (implementing a generic solution that doesn't fit the actual workflow). The principle here is broadly applicable: the best SAP implementations start with process transparency, not feature deployment.

Success Factor #2: One Partner, One Accountability

A recurring theme in Elementar's story is the conscious decision to work with a single implementation partner – one who could cover both the CAD/Autodesk side and the SAP side. In Sebastian's words: "In the past we always had many partners we had to work with, connect with each other, or who communicated with each other through us. We didn't want those friction losses anymore."

From Cideon's perspective, this structure also changed the dynamics of the project itself. Peter explains: "The kind of blaming no longer happened. So it wasn't 'the other partner from the CAD side is to blame,' or 'no, it's SAP.' None of that." Instead, both sides worked from a shared understanding of the target process – and took joint ownership of outcomes.

For organizations evaluating implementation partners, this is a practical point worth taking seriously: the coordination overhead of managing multiple vendors is not just an administrative burden. It creates real technical risk, because nobody has a complete picture of the end-to-end process.

Why SAP Engineering Control Center (ECTR) Made the Difference

The concrete tool at the center of this story is SAP Engineering Control Center. For Elementar, ECTR addressed a specific and fundamental challenge: moving data between product development and SAP without running it through external interfaces. In the legacy world, engineers worked in a PDM system and then "transferred things into an ERP system" – a phrase that covers a large amount of manual effort, synchronization logic, and potential for error. With two engineering sites (Langenselbold and Manchester), harmonizing versioning rules, release workflows, and data structures across that landscape was especially complex.

The insight that changed the picture came when the team stopped thinking of ECTR and SAP as "two separate systems talking to each other" – and started recognizing that they share one data foundation. Sebastian describes the practical result: "When you want to release a material, in the end it's one click, not a synchronization via complex interfaces." Engineers no longer notice the automation running in the background – which is exactly the point. The system supports the process without adding visible overhead.

This shift – from interface-heavy synchronization to a shared data foundation – is the core of what ECTR enables. And it has downstream effects: fewer integration points to maintain, less manual reconciliation, and more time for the actual work of product development.

What's Next: Mechatronics, More Automation, and AI

Both Elementar and Cideon are clear about the direction of travel.: he next frontier is mechatronics: bringing mechanical and electrical engineering data together in a unified model. As Peter puts it, "Engineering Control Center is well suited for that, because it allows me to connect multiple systems and link data from both systems." For a company like Elementar – which builds highly complex analytical instruments where "one doesn't work without the other" – this is a natural next step.

Sebastian adds a broader point about automation: the goal is to reduce the time engineers spend manually assembling and searching for information. "Now we can say: the system supports us, and we can focus much more on the tasks we actually need to do as a company."

AI is also on the horizon – specifically, the ability to run analyses against data that already exists in the system. Rather than treating AI as a separate capability to be added later, both speakers frame it as a natural extension of the data discipline and system foundation already being built.

One important principle that Cideon emphasizes for organizations just starting this journey: don't try to do too much at once. "First you should make sure that, on the customer side, users can cope with the system – learn to work with it – rather than implementing so much from the start that nobody knows what the system is doing in the background. First really learn to work with the system, then bring in improvements step by step."

This is enablement as a practice, not a one-time event.

Enablement Takeaways

Start with understanding, not features. Listen to the current process, make gaps visible, and only then decide what can stay standard and what must be adapted.
Reduce friction through clear accountability. A single partner who covers the full scope eliminates the coordination overhead and blame dynamics that derail complex implementations.
Data quality is a prerequisite, not an afterthought. Product data needs ownership, shared definitions, and active governance – or the processes built on top of it won't scale.
Use integration to eliminate synchronization. The value of ECTR becomes tangible when approvals and releases happen directly in the system – not through interfaces.
Enablement is iterative. Build user confidence first. Then expand capability step by step, especially in complex engineering and logistics scenarios.

I hope you liked this summary of our special German-language episode of the Inside SAP HANA Cloud podcast.

Stay curious and keep tuning in! Follow me on LinkedIn and stay up-to-date with our latest enablement assets: https://www.linkedin.com/in/annette-garcia-lorenzo.

Working with Git commands

2026-05-06T07:04:06.420000+02:00

Introduction:

Git is a decentralized version control system, which assists developers to follow the evolution of their code and cooperate effectively with other developers. It runs on a series of basic instructions like git init, git add, git commit, and git push that enables the user to manipulate versions of his or her code. With such commands, developers are able to have a full history of changes, work on multiple branches, and merge updates without any problems.

Body:

To create repository and sync it with Visual Studio , Please refer my blog https://community.sap.com/t5/artificial-intelligence-blogs-posts/ai-steps-to-setup-python-programming/ba-p/14381631

Open a new terminal in VS code

Create Python1.py in VsCode

Get into your repository folder.

cd {fodlername}

List all items with “”

git status

Add my folders into local repository

git add *

Commit the changes to Git staging area

Git commit -m {Tag}

Cross check with Github repository. Nothing added

Move from staging area to Github repository

git push

Content added to Github repository

Remove file

git rm {filename}

Changes staged

git commit -m {Tag}

Move to Github repository

git push

Empty folder not shown in Git

Summary:

Git is the distributed version control program which helps trace the alterations in the code and allows effective co-operation of the developers. It has easy to use commands to govern versions, maintain history, and allow easy branching and merging.

A Practical Approach to Automating External Parameter Changes in SAP Integration Suite

2026-06-04T08:40:50.937000+02:00

Introduction

As SAP Integration Suite developers, we regularly need to adjust external parameter values throughout a project’s lifecycle. This is more than a good practice: it helps ensure that interfaces remain tenant-agnostic and easier to maintain across environments.

In many projects, these adjustments are only required during transport between environments. In more complex landscapes, however, what appears to be a simple task can quickly become a major operational challenge for any CPI specialist.

Example Scenario

Imagine you have built multiple interfaces and your project also includes SAP standard packages such as Cell and Gene Therapy Orchestration (CGTO) or SAP Digital Manufacturing (DM). In addition, SAP Event Mesh is being used as the event broker for CGTO.

Although this setup may appear straightforward, complications often arise at the architectural level. For reasons such as budget constraints or time pressure, the DEV and QA landscapes in this example include not only the standard systems but also hotfix systems dedicated to specific testing activities.

In the DEV scenario described above, SAP Integration Suite acts as the central backbone for all communication flows. While there may be two instances of SAP CGTO, two of SAP S/4HANA, and so on, there is only one SAP Integration Suite tenant responsible for connecting these systems correctly.

Once this landscape is defined, SAP Integration Suite must be adjusted accordingly to ensure that all communication channels function correctly. This becomes especially critical when the hotfix testing window is extremely limited and the parallel system remains offline. These adjustments can involve hundreds or even thousands of configuration values, making it unrealistic to update them manually within such a short period without a significant risk of error.

To illustrate the scale of the challenge, nearly 200 external parameters may be affected in a scenario like this, for example, SAP clients, queue paths, and system endpoints.

Solution Overview

A practical way to address this challenge is to leverage SAP Integration Suite itself, more specifically, the integration content available through SAP Business Accelerator Hub.

This approach makes it possible to extract the affected external parameters, maintain them in a spreadsheet, save them as a CSV file, and submit the update through an external tool such as Postman. The effort of preparing the configuration files is done only once; after that, switching between environment-specific configurations can be completed in just a few minutes by uploading the appropriate file.

Soft Configurations Framework

The concept is straightforward: this interface provides a controlled way to manage external parameters in SAP Integration Suite through an external client such as Postman.

The goal is to reduce manual configuration effort across multiple environments while improving traceability and lowering the risk of human error.

How the Solution Works

Below are the iFlows included in this solution scope.

Get iFlows

This iFlow retrieves the external parameters of iFlows within the selected SAP Integration Suite packages and returns the result in either JSON or CSV format.

Options:

ignorePackages

Because of the large number of packages involved, this option was created to exclude any packages that fall outside the scope of the hotfix, for example, sandbox packages used for testing or other interfaces that are completely unrelated to the hotfix process.

returnPackage

If you only need to query a specific package, this option is much simpler, and significantly faster, than downloading every package available on the tenant.

Csv

By default, the interface returns the results in JSON format, which is convenient for inspection and integration. For SAP standard packages or large-scale parameter updates, however, CSV is often the most practical option because it allows all parameters to be reviewed and maintained efficiently in Microsoft Excel.

csvDelimiter

The user can also select the delimiter to be used in the CSV output.

Update Soft Config

This iFlow reads a JSON or CSV payload and updates the corresponding iFlows within the defined scope. It returns a full JSON report in Postman showing the affected external parameters, the previous and updated values, and the response status for each change.

Options:

Email

Because a full JSON report of the affected external parameters is generated, the interface can also send this report to a designated email inbox. This is particularly useful for traceability and audit purposes.

Deploy

This option allows the affected iflows to have their changes saved or saved and deployed.

iFlow Design and Processing Logic

Get All iFlows

Bellow are all the steps for this interface development.

Integration Process

Headers – Content Modifier: Reads all header parameters sent by a third-party application, such as Postman.
Read CSV Header – Groovy Script: Checks whether a CSV file has been requested.
Get Packages – Process Call: Invokes the local Get Packages process.

Get Packages

Get Packages – Request Reply: Retrieves all packages from SAP Integration Suite for the specified tenant (defined directly in the URL).
Read Packages – Groovy Script: Processes the returned payload and performs the following actions:
- If returnPackage is enabled, filters the payload based on the packages specified in the client request.
- If ignorePackages is enabled, returns all packages except those specified in the client request.
- Creates a clean internal JSON structure containing the package ID, Name, and ShortText.

// Part of the script 
// Full script can be found on the link of the bottom of the article

def slim = results.collect { r ->
        [
            Id        : r?.Id ?: "",
            Name      : r?.Name ?: "",
            ShortText : r?.ShortText ?: ""
        ]
}

Total Packages – Router: If no packages are returned, the process terminates.
Get Integrations – Looping Process Call: Invokes the Get Artifacts from Package process for each package.

Get Artifacts from Package

Header – Content Modifier: Resets the current iFlow count.
Get Actual Package – Groovy Script: Since the next step requires the package ID for the request, this script retrieves the current package ID from the internal JSON message.
Get Artifacts from Package – Request Reply: Retrieves all iFlows associated with the selected package ID.
Get iFlows – Groovy Script: Processes the returned payload and appends the iFlow ID, Name, and ShortText, along with the current package ID, to the internal JSON message.

// Part of the script 
// Full script can be found on the link of the bottom of the article

found = false

jsonAll.each { item ->

	if ((item instanceof Map) && String.valueOf(item.Id) == targetPackage) 
	{
		item.Iflows = slim
		found = true
	}
}

Empty? – Router: If no iFlows are returned, the process ends and proceeds to the next package.
Get Soft Configurations – Looping Process Call: Invokes the local Get Soft Configurations process.

Get Soft configurations

Get iFlow – Groovy Script: For the package currently in scope, retrieves each iFlow ID required to request its soft configurations in the next step.

// Part of the script 
// Full script can be found on the link of the bottom of the article

if(resultValue)
{      
	message.setProperty("iflowID", resultValue)
	message.setProperty("currentCountIflow", targetIflowIx + 1)
}

Get iFlow Soft Configs – Request Reply: Retrieves all soft configurations for each iFlow.
Get Soft Configs and Update – Groovy Script: Processes the retrieved information by cleaning the message, filtering out soft configurations defined directly within the iFlow, and appending the remaining entries to the internal JSON message.

// Part of the script 
// Full script can be found on the link of the bottom of the article

Message processData(Message message) {

    def body       = message.getBody(String) ?: '{}'
    def parsed     = new JsonSlurper().parseText(body)
    def results    = parsed?.d?.results ?: []

    def slim = results.collect {
        [
            Parameter   : it?.ParameterKey   ?: "",
            Value       : it?.ParameterValue ?: ""
            //Description : it?.Description    ?: ""
        ]
    }

    ...

    def pkg = jsonAll.find { it?.Id == packageID }

    // Ignore list
    def ignoreList = ignore.split(",")
                        .collect { it.trim() }
                        .findAll { it }

    // remove from list
    slim = slim.findAll { r -> !(r?.Parameter in ignoreList) }    

    if (pkg?.Iflows) {
        // Find the iflow
        def flow = pkg.Iflows.find { it?.IdIflow == iflowID }
        if (flow) {
            flow.SoftConfig = slim
        }
    }
...
}

Integration Process

Return Message – Content Modifier: Loads the internal JSON message into the message body.
isCSV? – Router: Checks whether a CSV output was requested. If not, the process ends and returns the internal JSON message.
CSV Convert – Groovy Script: Converts the JSON message into CSV format using the specified delimiter.

// Part of the script 
// Full script can be found on the link of the bottom of the article

// HEADER
    StringBuilder csv = new StringBuilder()
    csv.append(["PackageID","PackageName","IdIflow","NameIflow","Parameter","Value"].join(separator))
       .append(nl)

    // Clear escapes
    def esc = { v ->
        if (v == null) return ""
        def s = v.toString()
        def needsQuotes = s.contains(separator) || s.contains('"') || s.contains('\n') || s.contains('\r')
        s = s.replace('"', '""')
        needsQuotes ? "\"${s}\"" : s
    }

    // packages
    json.each { pkg ->
        def pkgId   = pkg.Id
        def pkgName = pkg.Name
        def iflows  = pkg.Iflows ?: []

        // iFlows
        iflows.each { iflow ->
            def iflowId   = iflow.IdIflow
            def iflowName = iflow.NameIflow
            def softCfgs  = iflow.SoftConfig ?: []

            // SoftConfig
            softCfgs.each { cfg ->
                def param = cfg.Parameter
                def value = cfg.Value

                csv.append([
                    esc(pkgId),
                    esc(pkgName),
                    esc(iflowId),
                    esc(iflowName),
                    esc(param),
                    esc(value)
                ].join(separator)).append(nl)
            }
        }
    }

Header – Content Modifier: Updates the Content-Type header to text/csv.
End: Terminates the process.

Update Soft Configurations

Bellow are all the steps for this interface development.

Integration Process

Count – Content Modifier: Reads all configurations and header parameters sent by a third-party application, such as Postman.
Validate JSON Message – Groovy Script: Checks whether the incoming message is in JSON or CSV format, validates its structure, and transforms the payload into an internal JSON message.

// Part of the script 
// Full script can be found on the link of the bottom of the article

Message processData(Message message) {

    ...
        
    // is JSON?
    try {
        parsed = slurper.parseText(body)
        if (parsed instanceof Map || parsed instanceof List) {
            isJson = true
        }
    } catch (Exception e) {
        isJson = false
    }

    // if its json, end
    if (!isJson) 
    {
        ...
    }
    else
    {
        /////////////////////////////////////////
        //json
        /////////////////////////////////////////
        
        try 
        {
            json = new JsonSlurper().parseText(body)
        } catch (e) {
            error = "Invalid JSON format."
        }

        // array?
        if (!(json instanceof List)) {
            error = "JSON must be an array at root level."
        }

        json.eachWithIndex { item, idx ->

            // IdIflow
            if (!item?.IdIflow || !(item.IdIflow instanceof String)) {
                error = "Element at index ${idx} missing valid 'IdIflow' (string)."
            }

            // SoftConfig
            if (!(item?.SoftConfig instanceof List)) {
                error = "Element '${item.IdIflow}' missing valid 'SoftConfig' array."
            }

            // config
            item.SoftConfig.eachWithIndex { cfg, cidx ->
                if (!cfg?.Parameter || !(cfg.Parameter instanceof String)) {
                    error = "Invalid 'Parameter' in '${item.IdIflow}' at SoftConfig index ${cidx}."
                }
                if (cfg.Value == null) { // allowed empty, but not null
                    error = "Missing 'Value' in '${item.IdIflow}' at SoftConfig index ${cidx}."
                }
            }
        }
    }
    def deploy = properties.get("deploy")
        
    if(!deploy)
    {
        message.setProperty("deploy", 'NO')
    }
    else
    {
        if( deploy.toUpperCase() != 'YES')
            message.setProperty("deploy", 'NO')
        else
            message.setProperty("deploy", 'YES')        
    }
...
}

All Good? – Router: Verifies whether the message is valid. If validation fails, the process ends and returns an error message.
iFlow – Looping Process Call: Invokes the local iFlow Logic process.

Iflow Logic

Get iFlow – Groovy Script: Reads information for each iFlow from the internal payload.
Get SoftConfigs – Request Reply: Retrieves the existing soft configurations for the iFlow currently in scope.
Store Previous Configs – Content Modifier: Stores the response payload for later use.
Fetch Token – Process Call: Invokes the Fetch Token local process.

Fetch Token

Header – Content Modifier: Configures the request to fetch the X-CSRF token header required for the next call.
Fetch Token – Request Reply: Retrieves the token through a GET request.
End: Terminates the local process and returns control to the iFlow Logic process call.

Iflow Logic

Soft Configs – Looping Process Call: Iteratively invokes the local Soft Configs process for each configuration item.

Soft Configs

Get Soft Config – Groovy Script: Processes each soft parameter individually for the iFlow currently in scope.

// Part of the script 
// Full script can be found on the link of the bottom of the article

if (configIndex < 0 || configIndex >= obj.SoftConfig.size()) 
{
   message.setProperty("currentParameter", "")
   message.setProperty("currentParameterValue", "")
}
else
{
   def value     = obj.SoftConfig[configIndex]?.Value?.toString()
   def parameter = obj.SoftConfig[configIndex]?.Parameter?.toString()

   message.setProperty("currentParameterValue", value)
   message.setProperty("currentParameter", parameter)
}

Prepare Body – Content Modifier: Configures the request body in the expected format for the next call and sets the required CSRF token headers.
Update Config – Request Reply: Updates the current soft parameter through a PUT request.
Read Response – Groovy Script: Reads the HTTP response code and message, while also retrieving the previous value that was cached earlier in the process.

// Part of the script 
// Full script can be found on the link of the bottom of the article

Message processData(Message message) {

    def body         = message.getBody(String)
    def jsonPrevious = message.getProperty("jsonPrevious")?.toString()
    def parameterKey = message.getProperty("currentParameter")?.toString()
    def head         = message.getHeaders();
    def httpCode     = head.get("CamelHttpResponseCode");

    def json         = new JsonSlurper().parseText(jsonPrevious)

    def results      = json?.d?.results
    def node         = results.find { it?.ParameterKey == parameterKey }
    def value        = node?.ParameterValue?.toString()

    message.setProperty("beforeParameterValue", value)
    message.setProperty("responseMessage", body)
    message.setProperty("responseCode", httpCode)

    return message
}

JSON Final Message – Groovy Script: Updates the internal JSON message with the new values obtained from the previous step.

// Part of the script 
// Full script can be found on the link of the bottom of the article

def newCfg = [
        Parameter      : parameter,
        ValueBefore    : valueBefore,
        ValueUpdated   : valueUpdated,
        ResponseCode   : responseCode,
        ResponseMessage: responseMsg
]

def existingIdx = node.SoftConfig.findIndexOf { it?.Parameter == parameter }

if (existingIdx >= 0) 
{
   node.SoftConfig[existingIdx] = newCfg
} 
else 
{
   node.SoftConfig << newCfg
}

End: Once the loop finishes, control returns to the iFlow Logic process and execution continues.

iFlow Logic

Deploy? – Router: Checks whether deployment was requested by the user.
Deploy – Request Reply: Sends a POST request using the iFlow ID currently in scope to trigger deployment.
Update JSON – Groovy Script: Updates the internal JSON message with the deployment result.
End: If no additional iFlows remain, control returns to the Integration Process.

Integration Process

Final Payload – Content Modifier: Loads the internal JSON message into the message body.
Monitor – Groovy Script: Attaches the payload to the MPL.

// Part of the script 
// Full script can be found on the link of the bottom of the article

if (messageLog != null) 
{
   messageLog.addAttachmentAsString('Soft config report', body, 'text/plain')
}

Has Email – Router: Checks whether an email request was provided. If not, the process ends.
Send Email – Send: Sends an email with the payload attached.

Iflow configuration

Get all iflows

Receiver

Parameter	Value
Receiver	Get_Soft_Configurations
Adapter Type	HTTP
Address	https://[ CPI tenant ]/api/v1/IntegrationDesigntimeArtifacts(Id='${property.iflowID}',Version='active')/Configurations
Proxy Type	Internet
Method	GET
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept

Parameter	Value
Receiver	Get_Iflows
Adapter Type	HTTP
Address	https://[ CPI tenant ] /api/v1/IntegrationPackages('${property.packageID}')/IntegrationDesigntimeArtifacts
Proxy Type	Internet
Method	Get
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept

Parameter	Value
Receiver	Get_Packages
Adapter Type	HTTP
Address	https://[ CPI tenant ] /api/v1/IntegrationPackages
Proxy Type	Internet
Method	Get
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept

More

Parameter	Value
Change1	Test 1
Change 2	Test 2
Change 3	Test 3
IgnoreParameter	SAP_ProfileID

Change1-3: Dummy external parameters for testing. Have no effect on the iflow.

IgnoreParameter: Add parameters that should not be returned on the response.

Change Soft Configs

Receiver

Parameter	Value
Receiver	Deploy
Adapter Type	HTTP
Address	https://[ CPI tenant ] /api/v1/DeployIntegrationDesigntimeArtifact?Id='${property.IdIflowExtracted}'&Version='active'
Proxy Type	Internet
Method	POST
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept, X-CSRF-Token, Cookie

Parameter	Value
Receiver	GetToken
Adapter Type	HTTP
Address	https://[ CPI tenant ] /api/v1/IntegrationDesigntimeArtifacts(Id='Get_all_iflows',Version='active')/Configurations
Proxy Type	Internet
Method	GET
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept, X-CSRF-Token

Parameter	Value
Receiver	UpdateSoftConfigs
Adapter Type	HTTP
Address	https://[ CPI tenant ] /api/v1/IntegrationDesigntimeArtifacts(Id='${property.IdIflowExtracted}',Version='active')/$links/Configurations('${property.currentParameter}')
Proxy Type	Internet
Method	PUT
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept, X-CSRF-Token, Cookie

Parameter	Value
Receiver	GetSoftConfigs
Adapter Type	HTTP
Address	https://[ CPI tenant ] /api/v1/IntegrationDesigntimeArtifacts(Id='${property.IdIflowExtracted}',Version='active')/Configurations
Proxy Type	Internet
Method	GET
Authentication	Basic
Credential Name	[cpi credential]
Request Headers	Accept

Parameter	Value
Receiver	EmailNotification
Adapter Type	Mail
Address	[email address]
Proxy Type	Internet
Protection	[email protection]
Authentication	[email auth]
Credential Name	[email credential]
From	[email from]
To	${property.userEmail}
Subject	Integration Suite \| Soft configurations change \| ${property.tenant}

More

Parameter	Value
Tenant	[cpi tenant]

Tenant: used for the email subject only.

Example of a call through Postman

In this case, I’m returning the SoftConfigurations package.

JSON file format

CSV, with ; as delimiter

Now, let us move forward with the following change:

[
    {
        "IdIflow": "Get_all_iflows",
        "SoftConfig": [
            {
                "Parameter": "change1",
                "Value": "It works from Postman 1"
            },
            {
                "Parameter": "change2",
                "Value": "It works from Postman 2"
            }
        ]
    }
]

Call Change Soft Configs using the payload above, requesting both deployment and email notification.

Email report

And the attachment

[
    {
        "IdIflow": "Get_all_iflows",
        "Deploy": {
            "Required": "YES",
            "ResponseCode": 202,
            "ID": "---"
        },
        "SoftConfig": [
            {
                "Parameter": "change1",
                "ValueBefore": "Test 1",
                "ValueUpdated": "It works from Postman 1",
                "ResponseCode": "202",
                "ResponseMessage": ""
            },
            {
                "Parameter": "change2",
                "ValueBefore": "Test 2",
                "ValueUpdated": "It works from Postman 2",
                "ResponseCode": "202",
                "ResponseMessage": ""
            }
        ]
    }
]

If I go to the iflow configuration, I can see that the update was done.

Applicability

Interface Connection Management

This was the primary motivation for creating the interface. Even with strong controls in place, manual configuration always carries some risk. Storing configurations in separate files not only saves time, but also provides a more reliable and resilient operating model. Teams can maintain environment-specific configurations independently and apply them when needed.

Technical Documentation

Documenting external parameters and their values is rarely a pleasant task. With this interface, parameters can be exported as a CSV file, refined in Microsoft Excel, and then reused in technical documentation with far less manual effort.

Configurations After Transport to Another Environment

From a governance perspective, managing critical parameters in a controlled format can be preferable to maintaining them directly in a web interface. CSV files reduce the risk of mistakes, especially in scenarios where SAP CTMS transports interfaces with incorrect external parameters.

They also make it easier to identify patterns and provide a broader, more structured view of the configuration landscape.

Final thoughts

I created this tool to address a highly time-consuming challenge in day-to-day delivery work. As a result, it was designed with enough flexibility to evolve and support additional use cases over time. Potential enhancements could include AI-based support for technical documentation or simplified access for non-technical colleagues and clients who need a clearer view of active integrations.

Unfortunately, time, or more precisely, the lack of it, has been the main constraint preventing further development of these additional capabilities.

I hope you find this tool as useful as I found the process of creating it. There are, of course, many ways to solve the same problem; this is simply one approach that I enjoyed designing and implementing.

Groovy scripts

All groovy scripts found on this article can be downloaded from the following GitHub page.

Sap CPI softConfigs

Meet the AI Layer in SAP Solution Scout

2026-06-08T14:23:34.788000+02:00

SAP Solution Scout lets you navigate the SAP portfolio by industry value chain—from Business Priorities down to individual Solution Capabilities—and the capability detail view now includes the supporting AI offerings that come with each capability. This means that when you evaluate a capability, you see not only the value proposition, value drivers, and related innovations, but also which AI Assistants and AI Agents are embedded. That’s how Enterprise AI delivers real value—not as a roadmap, but as deployed capability.

This integrated view changes the exploration question from "does this capability cover my requirement?" to "does this capability cover my requirement, and how intelligent is it?"

SAP Solution Scout is self-service and available to SAP customers, partners, and employees—explore at your own pace and build a collection of relevant capabilities and AI offerings. Start exploring at https://solutionscout.sap.com.

SAP Meetup Tbilisi

2026-06-09T11:19:02.694000+02:00

The recent SAP Community Meetup provided a valuable opportunity for SAP professionals, transformation leaders, architects, consultants, and technology enthusiasts to come together and engage in meaningful discussions about the future of enterprise technology.

One of the greatest strengths of the SAP community is its commitment to collaboration and knowledge sharing. Events like these provide a platform for professionals to exchange ideas, discuss emerging trends, and learn from real-world transformation experiences. They remind us that successful SAP transformations are not defined solely by technology, but by the people behind them—their expertise, collaboration, continuous learning, and willingness to share insights that drive meaningful business outcomes.

Throughout the meetup, participants explored a wide range of topics, including SAP S/4HANA transformations, cloud adoption strategies, AI-driven innovation, business process optimization, and the evolving role of technology in delivering sustainable business value. What made the discussions particularly valuable was the openness with which participants shared lessons learned, challenges encountered, and practical approaches to delivering successful transformation outcomes.

The event once again demonstrated the strength of the SAP ecosystem and the importance of creating opportunities for professionals to connect, learn, and grow together. The quality of the conversations and the diversity of perspectives highlighted the collaborative spirit that continues to drive innovation across the SAP community.

A special thank you goes to our partners and sponsors — New Vision University, EPAM, PBD Experts, AgentPark LLC, and Synora Consulting — for their support and commitment to fostering professional development, innovation, and knowledge sharing. Their contribution was instrumental in making this event possible and creating an environment where meaningful connections and valuable discussions could take place.

Appreciation is also extended to the organizers, speakers, and volunteers whose dedication and hard work ensured a successful and engaging experience for all participants.

As organizations continue to navigate increasingly complex digital transformation journeys, community-driven initiatives such as this become more important than ever. They provide a platform not only for learning about emerging technologies and industry trends but also for building relationships, exchanging best practices, and strengthening the network of professionals driving transformation across industries.

Thank you to everyone who contributed to making this meetup a success. I look forward to continuing these conversations, sharing experiences, and collaborating with the SAP community at future events.

#SAPCommunity#SAPGeorgia#Tbilisi#Georgiatech #SAPS4HANA #DigitalTransformation #CloudTransformation #EnterpriseTransformation #Innovation #SAPConsulting #Leadership #Technology #Networking

SAP BusinessByDesign Roadmap

2026-07-16T06:02:12.990000+02:00

Updated : July 2026

This roadmap provides a forward-looking view of the product’s priorities, direction, and expected areas of investment over the coming year.

Disclaimer: The information presented in this roadmap reflects our current plans and intentions and is provided for informational purposes only. Features, timelines, and priorities are subject to change without notice and should not be relied upon as a commitment or guarantee of future delivery.

Product road map overview: Process enhancements and cross-function capabilities

Product road map overview: Legal and compliance

From clicks to intent: Why SAP SuccessFactors gets stronger in the agent era

2026-07-23T10:00:00.018000+02:00

There's a phrase making the rounds in customer meetings and blog posts that's worth taking seriously: "death by AI." The argument goes that as AI agents learn to do the work, the software underneath them becomes a commodity — the SaaS suites we've used for years and keep expanding quietly lose their reason to exist.

So it's a fair question to put on the table: does that apply to SAP SuccessFactors?

I've been living with this question for a while, and my answer is a confident no. But I don't want to wave the concern away, because it points at something real — and the response it demands from us is more urgent than "relax, we're fine."

The good, the bad, and the ugly

The good news first: AI doesn't kill SaaS as a category. What it does kill is undifferentiated, UI-centric software — tools that live or die by the screens you navigate and lack three things: depth of data, authority over the process, and gravity within a larger platform. SAP SuccessFactors has all three, so it isn't threatened at the level of existence.

The bad news is that the pressure is still real, and it lands somewhere specific. It's not about functionality. It's about how people interact with the system — and that's the part that's changing fastest.

The ugly part? The work to be ready for it exposes every shortcut we've taken with our data and processes over the years. More on that later.

From clicks to intent

Think about how HR software has worked for the past decade. You log in, you find the right module, you navigate to the right screen, you fill in the right fields. The interface was the product. Mastering the clicks was the skill — even if WalkMe helped you navigate.

That model is changing in front of us. People increasingly want to state a goal, not learn a menu. Instead of navigating three dashboards to find flight risks, a manager asks: "Show me the high-potential employees at risk of leaving my team." Natural language in, business outcome out.

This is exactly what Joule now brings to SAP SuccessFactors. The intent-based, conversational layer isn't a concept on a roadmap anymore — it's how the work gets done. And that reframes everything underneath it. The screens become less important. The system of record beneath them becomes more important, because it's what makes the intent trustworthy.

Why SuccessFactors doesn't just survive — it compounds

Here's the part the "death by AI" narrative misses. An agent is only as good as what it can reason over and act on. Strip away the interface, and the value doesn't disappear — it concentrates in the layer that most people never see.

Data depth. Agents need context to be useful, and useful HR context isn't a snapshot — it's years of employee history, compensation and performance data, and organization-specific structures. SAP SuccessFactors owns that longitudinal record, now grounded and made machine-readable through the SAP Knowledge Graph. An agent without access to this data is confidently wrong. An agent with it is genuinely helpful.

Process authority. SAP SuccessFactors doesn't just recommend — it approves, audits, documents, and proves compliance. A general-purpose AI tool can draft a suggestion. It can't stand behind a co-determination decision in a German works council, and it can't produce the audit trail your regulators expect. That authority is not a feature. It's the foundation of trust.

Platform gravity. The real advantage isn't any single agent — it's the ground they're built on. With SAP Business Technology Platform and a low-code environment for building and governing agents, the platform becomes the place where AI experiences are created, not just consumed. And because the approach is model-agnostic, you're not locked into one vendor's reasoning engine. You can bring the model you prefer, while the governance, the data, and the process control stay exactly where they belong.

That last point matters more than it first appears. SAP isn't asking you to bet on one frontier model winning the race. The moat was never the model. It's the governed data and the process authority around it.

The winning condition: governed autonomy

The Autonomous HCM vision doesn't mean full autonomy. It means governed autonomy — enough freedom for agents to drive real efficiency, and enough control to keep trust, compliance, and accountability intact.

The clearest way to make that concrete is to be explicit about boundaries. In an HR context, agents may assess risk, justify a recommendation, prepare options, and simulate outcomes. Agents must not finalize compensation, terminate employees, bypass works councils or co-determination, or make legal HR decisions on their own.

Those aren't limitations that hold the technology back. They're the guardrails that make it deployable in the real world — especially in Europe, where the compliance reality your teams live with every day is a genuine competitive advantage, not an obstacle. Generic AI can't honor those rules. A governed HR system can.

The next frontier: governing the agent workforce

Here's where this gets genuinely interesting for those of us in HR. The conversation so far has been about agents doing HR work. The next chapter is HR governing an agent workforce.

As agents scale across your organization, they start to look a lot like a new kind of workforce — one that needs to be mapped into your HR operating model, tied to org units and business functions, and understood in terms of which human skills are affected as the agents take on more. And this reshapes the operating model itself. You don't just need HR business process owners anymore. You need roles that own both the process and the agents that run it — accountable for how the two work together.

Who owns which agent? Which team relies on which capability? How does the workforce shape change as this rolls out? Answering those questions is squarely an HR job. It's the natural extension of everything HR already does well.

So what should you do about it?

If the agent era rewards depth of data, process authority, and platform gravity, then the work to get ready is refreshingly concrete. None of it is exotic. Most of it is discipline.

Move to the cloud — if you haven't already. The agent capabilities described here run in the cloud, and cloud makes everything that follows much easier and faster. If parts of your core HR still runs on-premise, this is the moment to commit to the move. Everything else builds on it.
Fix your data model and your data. Agents amplify whatever they're given. Feed them messy, inconsistent, incomplete data and they'll amplify the mess — faster and more confidently than any human ever could. But clean data starts with a sound model beneath it: clear organizational structures, consistent position management, and a coherent metadata model for how HR data is defined. Get the model right, then get the data clean. That combination is the fuel agents run on.
Build a skills and job architecture foundation. Talent and workforce agents reason over skills. If your skills taxonomy and job architecture are vague or inconsistent, the insight the agents produce will be too.
Standardize and document your processes. Process authority only helps if the processes are actually defined. Agents act on well-designed workflows, not tribal knowledge. Now is the time to capture and standardize how HR work really flows.
Define your autonomy boundaries early. Don't wait for a governance question to become a governance incident. Decide up front what your agents may do, what they must not do, and where a human stays in the loop. Write it down. Involve your works councils.
Invest in AI literacy and change management. The shift from clicks to intent is a shift in how people work. Your teams need to learn to lead agents, not just use software. That's a people challenge before it's a technology one.

The organizations that treat this readiness work as foundational — rather than something to bolt on later — will be the ones that turn the agent era into an advantage instead of anxiety.

What's your take?

Where do you land on this. Are you seeing "death by AI" pressure in your own HR landscape? And here's the question I'd most like your take on: where would you draw the line on what an HR agent is allowed to do?