Het roer moet om als het gaat om het salesproces van SAP-projecten. Een boud statement van een doorgewinterde SAP-consultant, maar wel iets om eens over na te denken. Op dit moment verloopt het als volgt: op het moment dat een organisatie overweegt om SAP, of een SAP-product, te implementeren of een upgrade uit te voeren, wordt contact gezocht met de softwareleverancier of een dienstverlener. Er wordt door hen een projectplan opgetuigd – passend bij de klantbehoefte – om SAP te installeren, implementeren en in gebruik te nemen. Alle belangrijke beslissingen rondom gebruikers worden al in het begin genomen: wie zijn het, waar zijn ze en van welke functionaliteiten maken ze gebruik? Dit heeft gevolgen voor de architectuur van het landschap. Worden hier dus verkeerde prognoses gemaakt of wordt er onvoldoende over nagedacht? Dan heeft dat als gevolg dat het project moet worden herzien. Het project kan daardoor duurder uitvallen of de livegang komt zelfs in gevaar. Risico’s die niemand graag neemt.
De basis? Dat komt later
Ongeveer op driekwart van het selectieproces komt in de meeste gevallen de techniek pas om de hoek; de software is gekozen, de bedrijfsprocessen zijn in kaart gebracht, maar waar gaat het systeem eigenlijk op draaien? Opvallend, want de techniek vormt de basis voor de IT-architectuur. Tot op heden zag de situatie er altijd zo uit dat er een bedrijfsnetwerk bestond waarbinnen SAP draaide én de gebruikers opereerden – allen met dezelfde rol en dus met dezelfde functionaliteiten tot hun beschikking. ‘Klinkt als een prima constructie’, hoor ik je denken. Maar dat geldt niet langer.
S/4HANA zorgt voor verandering
Met de komst van S/4HANA gaat een nieuwe inrichting van rollen en functies in SAP gepaard. Neem bijvoorbeeld een inkoopproces. Stel dat er binnen een organisatie is afgesproken dat wanneer er materialen worden ingekocht voor meer dan €50.000, een manager goedkeuring moet geven. Voorheen had de manager dan net zo veel rechten binnen het SAP-systeem nodig als de inkoper, terwijl hij slechts akkoord moet geven. In S/4HANA kan de medewerker de inkooporder volledig voorbereiden, en hoeft de manager slechts akkoord te geven. Dit kan door middel van een pop-up op zijn telefoon. Hierdoor wordt niet alleen het goedkeuren een veel simpelere actie, maar hoeft hij tevens niet meer het bedrijfsnetwerk te gebruiken. ‘Simpel SAP’, noemt men het ook wel: alles eenvoudiger en overzichtelijker.
Begin (eerder) bij de basis
Om te definiëren welke functionaliteiten en rechten een gebruiker moet hebben, is het van belang te begrijpen hoe hij SAP gebruikt. Een controller heeft voor zijn functie inzicht nodig in complexe processen op grotere schermen, niet alleen in een app. Palletscanners in een magazijn zijn geholpen met een simpele keuze tussen ‘wel of niet het juiste artikel’ op een tablet. Managers die sporadisch gebruikmaken van SAP zijn geholpen met een app, daartegenover staan de zware gebruikers die hun kernwerkzaamheden in SAP uitvoeren. Die twee typen en alles daartussen bepaalt hoe de architectuur eruit moet zien. Een technisch consultant weet het best hoe hij dit in kan richten. Zaak dus om hem tijdig in het proces te betrekken; niet pas vlak voor de eindstreep.
Er is een omslag nodig in de mindset. Vragen als hoe SAP gebruikt wordt, welke typen gebruikers er zijn en welke processen zij nodig hebben zijn cruciaal voor de inrichting van de architectuur. Hoe eerder dit bekend is, des te beter dit is voor het verloop van het project. In de bouw wordt het fundament immers ook eerst gelegd, dat zou bij SAP-projecten niet anders moeten zijn. Mijn oproep luidt dan ook: ‘Think big, maar laat techniek niet te lang links liggen; begin bij de basis.’
 |
Andre van Dijk | Technology Consultant bij myBrand Conclusion |
|---|
