Ruim driekwart van alle transacties wereldwijd komt in aanraking met een SAP-systeem. Het zegt genoeg over het enorme aantal bedrijven dat met SAP werkt. Tegelijkertijd staat SAP niet bepaald bekend om de snelheid waarmee je veranderingen kunt doorvoeren in de software. Daarom vinden veel SAP-gebruikers het een interessante ontwikkeling dat met low-code platforms snel én gebruiksvriendelijk nieuwe functionaliteit kan worden gebouwd.
Focus op het doel en niet op de middelen
Dat is het ook, maar wij zien in onze dagelijkse praktijk dat ze lang niet altijd voldoende stilstaan bij wat dit nu echt betekent en aan welke randvoorwaarden ze moeten voldoen. Ze focussen te veel op Scrum als ontwikkelmethode en op DevOps om nieuwe functionaliteit vervolgens ook snel uit te rollen. Terwijl de methoden en tools misschien wel de minst interessante onderdelen zijn. Het zijn hooguit middelen om een doel te bereiken. Veel belangrijker is het om vooraf voldoende stil te staan bij het doel. Wat ga je voor wie ontwikkelen en wat moet daarvan het resultaat zijn? Daarom op dat vlak enkele adviezen.
📝 ook interessant om te lezen: “myBrand eerste erkende SAP DevOps-partner van Nederlandse bodem“
Wat is de waarde voor de klant?
Eén van de meest gemaakte fouten is dat het Scrum-team te weinig stilstaat bij de waarde die de nieuwe functionaliteit gaat hebben voor de klant. Hoe gaat het de gebruiker helpen in zijn dagelijkse praktijk? Hier kom je alleen achter als je de gebruikers intensief betrekt; als je je verdiept in hun wereld en hun behoeften. Houd ook rekening met de impact van een nieuw te ontwikkelen functie op zaken als bijvoorbeeld de snelheid en stabiliteit van de applicatie. Anders kunnen gebruikers wel eens van de regen in de drup belanden.
Ben sterk en heb geen maatwerk
Een andere valkuil is veel te snel te grijpen naar zelf ontwikkelen, terwijl SAP standaard heel veel best practices aanbiedt die je als uitgangspunt kunt nemen voor de inrichting van je systeem. Ik ken geen IT-manager die niet ergens in zijn strategisch plan heeft staan dat maatwerk tot een minimum moet worden beperkt. Maar toch zie ik in de praktijk dat de mogelijkheid om in low-code te ontwikkelen de focus verlegt van de standaardapplicaties naar de sexy ontwikkeltools. Zo blijven mogelijkheden die kant-en-klaar op de plank liggen onbenut.
Breng eerst de basis op orde
Een derde advies is om eerst de basis op orde te brengen voordat je begint met een DevOps-aanpak. Een IT-landschap renoveren is als een huis verbouwen: het heeft geen zin om een mooie keuken te plaatsen als het dak lekt en de muren nog gestuct moeten worden. Investeer dus eerst in een stabiele omgeving en goede monitoring. Want alleen als er weinig incidenten zijn en de incidenten die zich voordoen snel en eenvoudig kunnen worden opgelost, heeft het DevOps-team tijd en ruimte om met nieuwe functionaliteit aan de slag te gaan.
Overweeg jij om je SAP-landschap te innoveren door in low-code nieuwe functionaliteit bij te bouwen? Of doe je dit wellicht al maar zie je dat er ruimte ligt om te verbeteren? Lees dan onze whitepaper ‘Snel innoveren op je SAP-landschap met een DevOps-aanpak’ en kom alles te weten over de kansen die er liggen en de randvoorwaarden die je moet invullen om succes te boeken.
Wil je weten wat de beste aanpak is voor jouw organisatie? Dan gaan we natuurlijk graag met je in gesprek.
Dennis Bruijns
Vestigingsdirecteur Geertruidenberg
myBrand
Benieuwd wat DevOps in combinatie met SAP voor jouw organisatie kan betekenen?
Download het whitepaper ‘Snel innoveren op de SAP-landschap met DevOps-aanpak’.
Download