EC onderzoekt SAP vanwege concurrentiebelemmerende on-premonderhoudscontracten

De Europese Commissie is een antitrustonderzoek gestart naar softwaremaker SAP. Het bedrijf zou onterecht afdwingen dat klanten met on-preminstallaties bij SAP terecht moeten voor ondersteuning. Dat levert ook weer andere problemen op, waardoor SAP mogelijk concurrentie door andere bedrijven belemmert.

De Europese Commissie zegt dat zij een onderzoek begint naar SAPs licentiemodel. Het gaat specifiek om ondersteuningslicenties voor klanten die SAPs Enterprise Resource Planning-softwarepakketten afnemen en dan voornamelijk als ze dat on-premises doen in plaats van op SAPs cloud. Er zijn bedrijven die zulke ondersteuning ook aanbieden, soms tegen betere prijzen, maar volgens de Europese Commissie dwingt SAP het bij klanten af om bij SAP zelf een onderhoudspakket af te sluiten. Bovendien, zegt de EC, zijn die pakketten altijd hetzelfde. Klanten hebben daardoor weinig opties om zelf te kiezen wat de beste ondersteuningsaanbieder is voor wat zij nodig hebben.

Daar komen nog drie andere problemen uit voort. Zo kunnen klanten niet kiezen om bepaalde ondersteuning niet af te nemen, waardoor ze regelmatig te veel betalen voor hun onderhoudscontracten. Ook hebben klanten geen mogelijkheid een contract voortijdig op te zeggen en moeten klanten nieuwe inschrijfkosten betalen als ze tijdelijk geen ondersteuning meer hebben afgenomen.

Volgens de EC is er een mogelijkheid dat SAP daarmee concurrentie met alternatieve ondersteuningsaanbieders de kop in heeft gedrukt. Ook zou SAP klanten daarmee onnodig veel geld hebben gevraagd voor diensten.

Reacties (13)

[rescue]

Het werd tijd dat SAP wordt aangepakt, in meerdere opzichten een verschrikkelijk bedrijf.

Enerzijds biedt het, mits je de standaardoplossingen volgt, een volwaardig pakket voor processen en rapportages. Anderzijds worstelen veel bedrijven met:

• Strikte licentievoorwaarden
• Verplichte migraties en subscriptions
• Hoge onderhouds- en integratiekosten

De licentievoorwaarden van SAP blokkeren externe koppelingen zodra je afwijkt van hun referentie-architectuur. Daardoor kun je niet zomaar innovatieve of goedkopere alternatieven naast SAP draaien zonder functionaliteit te verliezen.

SAP heeft klanten in fases gedwongen over te stappen:

S/4HANA ter vervanging van legacy-Oracle-omgevingen

HANA als ‘in-memory’ database, terwijl performancewinst vaak tegenviel

SAP RISE, een subscriptionmodel dat exclusieve functionaliteit aan abonnementsgeld koppelt

Wie niet op RISE instapt, verliest toegang tot belangrijke modules en updates.

Voor bedrijven die binnen de SAP-best practice blijven, zoals sommige winkelketens (De Action!) blijft het een werkend platform, ondanks een verouderde gebruikersinterface en forse onderhoudskosten. Maar zodra je afwijkt van SAP’s denkkader:

• Lopen projecten snel vast
• Stijgen de integratie- en consultancykosten
• Wordt innovatie afgeremd

Aldi is hier een voorbeeld van.

Een grote Nederlandse bank ontwikkelde een oplossing waarmee zij jaarlijks ruim €4 miljoen zouden besparen. Door bindende lock-in en de onmogelijkheid om in de eerste drie jaar van SAP af te stappen, ging dit project echter de ijskast in.

SAP’s wereldwijde salesorganisatie weet niet-technische CEOs en bestuurders te overtuigen met verhalen over:

• Data warehouse / lakes
• Real-time processing
• AI-integratie

Hun commerciële presentaties stemmen echter zelden overeen met de dagelijkse praktijk van eindgebruikers en IT-afdelingen.

Niet alleen SAP zelf, maar ook de hele keten aan consultancypartners profiteert van deze lock-in. Zij adviseren vaak dure maatwerktrajecten in plaats van kostenefficiënt standaardgebruik, puur omdat daar de hoogste marges liggen.

De enorme geldstroom rondom SAP is een bijzonder verdienmodel, gevoed door :

• Strikte contractuele belemmeringen
• Felle verkoop- en marketingpraktijken
• Belangen van consultancyketens

De EU heeft SAP lang de hand boven het hoofd gehouden. Hopelijk een eye opener voor de beslissingmakers.

[DeMaffias]

Ik begrijp je punt wel, het is inderdaad een kluwen bij SAP. Anderzijds kan je toch ook bijvoorbeeld geen Windows security updates bij een derde paretij aankopen? Lijkt mij nogal logisch dat dat via de originele ontwikkelaar verloopt.

Persoonlijk vind ik de S/4HANA evolutie toch een enorme prestatieverbetering opleveren tov ECC met Oracle. Je moet dan uiteraard wel je legacy crap code aanpassen.

[-Elmer-]

Dat updates via de leverancier komen is inderdaad volstrekt logisch. Maar als je vragen of andere hulp nodig hebt moet je toch ook gewoon bij elke SAP expert in Nederland of daar buiten aan kunnen kloppen?
Het zou wat zijn als Microsoft zou vereisen dat je voor vragen en hulp altijd bij hun aan moet kloppen, en nooit meer naar de 'lokale computerboer' zou 'mogen'. En wanneer je dat wel doet je bijvoorbeeld geen Windows updates meer ontvangt.

[supertheiz]

Voor een groot deel met je eens, maar wel een paar kanttekeningen:

Het moderne cloud platform zorgt wel voor meer mogelijkheden en de aansluiting van een monoliet als de ERP op moderne Dev-Ops en aanverwante diensten. Met Kyma kan je microservices ontsluiten en je kan redelijk eenvoudig een van de grote platformen (Azure, GCP, AWS) koppelen voor gebruik van standaard en specifieke services. Hierdoor zit je dus minder vast in de best practices.

HANA is echt wel een heel mooi stuk techniek, performance problemen waren architectuur problemen aan de applicatiekant.

Dat gezegd hebbende: De licentie structuur is inderdaad schandalig. En het zijn kosten over kosten over kosten. Als je een licentie hebt, met het verplichte support contract, kan het bijvoorbeeld zo zijn dat SAP je verteld dat het probleem in hun software alleen kan worden opgelost door het kopen van premium engagement. Daar kan dan uitkomen dat je consultancy uren bij SAP moet gaan afnemen.

Of ze hebben licentiemodellen die gebaseerd zijn op een percentage van de omzet, en dan gaan ze er vanuit dat het je core business is als klant. Maar als je dat dan krijgt voor Transport Management (2% omzet), en voor Warehouse management (2% omzet), maar je bent bijvoorbeeld fabrikant van Melk of Cement, dan wordt er zo dus al 4% van de omzet afgesnoept door bijzaken.

Dit fenomeen is overigens niet alleen voor SAP relevant. Als je een middelgrote organisatie bent, dan is het ook echt wel heel lastig om een goed platform te bouwen bij een Azure, AWS of GCP. Je bent dan als klant gewoon niet interessant genoeg, en je betaalt dan dus de hoofdprijs zonder dat je de ondersteuning krijgt die eigenlijk wel nodig is.Of juist andersom dat je een oplossing krijgt, maar daardoor wel 10 jaar vast zit aan een veel te dure service.

Met AI wordt het allemaal nog weer complexer, want hier gaan de platformen ook weer zorgen dat je niet een andere AI tool kan gebruiken. SAP heeft Joules, en die zullen er echt wel voor gaan zorgen dat niets anders kan worden gebruikt op je SAP systeem.

[Kaastosti]

Tjah het licentiemodel van SAP hebben meer mensen een mening over.

Aanpassingen en maatwerk kun je prima bij een derde partij neerleggen, ook zonder onderhoudscontract bij SAP. De optie die dan wel per definitie wegvalt, is het aanpassen van code van SAP zelf. En ik weet ook wel dat die onderhoudscontracten niet goedkoop zijn, maar voor een dubbeltje op de eerste rij willen zitten met een enterprise pakket als SAP is gewoon onverstandig. Daar hoort een stuk investering in onderhoud ook bij.

Maar goed, het gaat hier dus om het dwingen van het afnemen van zo'n contract en het ontbreken van flexibiliteit. Da's niet netjes... terecht dat ze daar onderzoek naar doen. Benieuwd wat eruit komt.

[Honbrifcl]

Tenzij daar sinds kort iets drastisch veranderd is, kun je de code van SAP volgens mij naar eigen wil en inzicht aanpassen op je eigen systemen. Uiteraard heeft dat wel invloed op de support van SAP om bugs in de originele software te rapporteren en opgelost te krijgen, je zult dan moeten "aantonen" dat de bug ook bestaat in ongewijzigde code.

[smesjz]

Daar heb je een repair key voor nodig als je iets wil aanpassen. Beter is gewoon om de sap standaard process te gebruiken en met OSS notes te werken. Of te werken met badi, user exits, enhancement points. Of lekker in je eigen namespace of Z namespace je dingen te doen. Sap standaard is er met een reden.

Los van support, dit gaat anders problemen opleveren met updates.

[Kaastosti]

Klopt, een SSCR key, die je niet meer kunt krijgen zonder support. Neemt inderdaad niet weg dat je dat helemaal niet moet willen, maar oude(te) systemen zitten vol met dergelijke aanpassingen.

OSS gaat ook niet meer werken zonder contact.

In S/4 werkt dat anders. Dan kun je er bij, maar word je direct gemarkeerd als 'ontwikkelaar'. En na een paar maanden komt SAP een ontwikkelaar account afrekenen

[Flex-Able]

Het was inderdaad te verwachten dat er een antitrustonderzoek door de Europese Commissie naar SAP zou komen, gezien de zorgen die al langere tijd bestaan over de complexe licentievoorwaarden, het afdwingen van onderhouds- en ondersteuningscontracten en het moeilijk maken voor klanten om over te stappen naar concurrerende aanbieders. SAP is marktleider in ERP-software en er waren al klachten over concurrentiebeperkende praktijken. SAP heeft zelfs concessies aangeboden om een diepgaand onderzoek en mogelijke boetes te voorkomen, wat erop wijst dat het bedrijf de risico's van een dergelijk onderzoek zelf ook inzag. De Europese Commissie had al signalen ontvangen over mogelijke marktverstoringen door SAP en richt zich nu expliciet op het behoud van concurrentie en keuzevrijheid voor klanten, vooral bij on-premise ERP-licenties.

[kdekker]

Ik ken SAP onvoldoende, maar heb zelf vroeger ook bij een ERP boer gewerkt. Ook toen waren er andere partijen die zeiden 'wij doen onderhoud voor minder'. Wat ze er dan niet bij zeggen is dat ze alleen onderhoud kunnen (en mogen) doen op eigen maatwerk.

De bronbestanden (voor zover aanwezig) van de ERP leverancier zijn doorgaans closed source en copyright beschermd. Die mag of kun je niet aanpassen (executables kun je niet eens aanpassen). Dus vanuit dat oogpunt is het niet meer dan logisch dat je voor dat soort updates een licentie of onderhoudscontract hebt bij de leverancier.

Nogmaals, ik ken SAP onvoldoende om te weten hoe de scheiding ligt tussen wat je wel en niet mag aanpassen, maar zoals het hier nu in het artikel staat, verbaast het me dat er op dit terrein de EU over gebrek aan concurrentie spreekt. Bij de meeste closed source bedrijven is onderhoud, support of licenties door een concurrent mogelijk. Kennelijk vind de EU dat er hier wel een reden moet zijn om dat mogelijk te maken.

[bluebug]

Misschien dat ze daarna ook eens naar de niet-door-te-komen license guides van Microsoft, met name voor het Power Platform, kunnen kijken... Elke paar maanden verandert er wel iets, maar niemand begrijpt hoe alles precies samen past, zelfs bij Microsoft Nederland kan je geen eenduidig antwoord krijgen. En nu willen ze ook nog met agentic AI gaan enforcen 🤦‍♂️

[Rhaegar1]

Ah gelukkig pakt de EC eindelijk eens de grote Europese techreuzen aan. Ik moet er niet aan denken dat we een fractie te duur uit zijn omdat die arme Amerikaanse bedrijfjes geen voet aan de grond krijgen.

Klinkt voor mij wel weer als een typisch geval dat de EU zijn interne marktregels weer flink gebruikt worden om Europese bedrijven dwars te zitten.

[E!Ma0RB7]

"concurrentiebelemmerende on-premonderhoudscontracten"

Kanjers! Deze kan zo in het Groot Dictee der Nederlanden