Tim Scheffer
Het ontwikkelen van applicaties voor je business is veel makkelijker geworden met de komst van SAP Fiori. Met Fiori beschik je over een breed portfolio aan bestaande apps, die je kunt bewerken en aanpassen. Maar het platform biedt je ook tools en functionaliteiten om zelf je businessapplicaties te bouwen. Dat klinkt misschien heel makkelijk, maar als je begint met ontwikkelen zijn er toch altijd dingen waar je op moet letten. In dit artikel deel ik vier lessen die ik leerde tijdens het bouwen van een Fiori-app voor Nationale Nederlanden.
Laat ik eerst even toelichten waarom ik een applicatie ontwikkel. Binnen de IT-afdeling van Nationale Nederlanden (NN) onderscheiden we twee typen bedrijven: life en non-life. Life gaat over de verzekeringen waarbij je dekking opbouwt, bijvoorbeeld een levensverzekering of je pensioen. Non-life gaat over het beschermen van materiële en financiële zaken in het dagelijks leven, zoals voertuigen, inboedel en financiële verliezen. Binnen non-life is er een team van NN verantwoordelijk voor het contact met gevolmachtigde agenten. Dit zijn financiële dienstverleners die – binnen vooraf afgesproken kaders – als tussenpersoon van NN optreden. Een gevolmachtigd agent neemt bijna alle werkzaamheden van Nationale Nederlanden over. Denk aan het offreren, accepteren en muteren van verzekeringen, het voeren van de polisadministratie, de schadebehandeling en de ex- en incasso. Dit doen ze voor rekening en risico van Nationale-Nederlanden. Veel van deze agenten werken overigens voor meerdere verzekeraars tegelijkertijd.
De afdeling van NN die deze volmachten beheert, levert soms ook extra diensten die niet vooraf zijn opgenomen in de overeenkomst met de gevolmachtigde agenten. De kosten die ze daarvoor maken, moeten ze in rekening brengen. De afdeling voert deze kosten handmatig in in SAP. Dat deden ze voorheen door een Excelsheet als hulpmiddel te gebruiken om bepaalde boekhoudkundige informatie op te halen. Daarin moesten ze bij iedere nieuwe boeking handmatig tientallen velden invullen. Vervolgens kopieerden ze al die velden vanuit Excel in onze SAP-omgeving. Daarna moesten ze nog een brokerrapport aanmaken, sluiten en boeken. Dit proces duurde gemiddeld zo’n 15 à 20 minuten per boeking. Een tijdrovende klus, maar ook niet gebruiksvriendelijk en vooral erg foutgevoelig. Als iemand data foutief invoert, is er na afloop veel werk om dat te corrigeren.
Daarom besloten we om met SAP Fiori een webapplicatie te bouwen om dit proces zo ver mogelijk te automatiseren en veel eenvoudiger te maken. Voor degene die Fiori niet kennen: SAP Fiori is een collectie van applicaties voor veelvoorkomende bedrijfsprocessen zoals goedkeuringsprocessen, het opvragen van informatie en selfservice taken. De applicaties zijn gebouwd voor smartphones, tablets en desktops. Fiori biedt daarnaast ook functionaliteit om zelf applicaties te bouwen of bestaande Fiori apps aan te passen en uit te breiden. Wij besloten om voor de volmacht-app een nieuwe applicatie te bouwen. Dit was voor mij de eerste Fiori-app die ik zelfstandig ontwikkelde. Tijdens de ontwikkeling leerde ik een aantal wijze lessen over development met het framework van Fiori, SAP UI5. Die deel ik graag met je.
Les 1: De eindgebruiker is je beste vriend
Betrek de eindgebruiker. Dit lijkt zo vanzelfsprekend, maar als IT’er heb je vaak de neiging om vooral in technologie te denken. Uiteraard probeerde ik vanaf het begin mijn kennis van user experience design toe te passen. Ik overlegde met eindgebruikers, vroeg ze wat ze precies wilden en waar vaak dingen fout gingen. Net als een goede journalist moet je voortdurende door blijven vragen. Dat leerde ik nadat ik de eerste versie van de app had gebouwd. Die versie maakte het invoeren in Excel, het kopiëren van de gegevens en het plakken in SAP overbodig. Eindgebruikers hoefden alleen nog een documentdatum, de mutatiesoort, de kosten en een omschrijving in te voeren. Alle andere informatie was compleet geautomatiseerd. Was dat voldoende? Niet helemaal. Nadat ik de eerste versie van de applicatie had getoond aan de eindgebruiker, kwamen we gezamenlijk tot het idee verder te kijken dan deze stap. Om het proces boekhoudkundig volledig af te ronden, is ook een broker rapport nodig en de eindgebruiker vroeg of dit ook was te realiseren. Daarom gingen we weer samen aan de tekentafel zitten. Dankzij onder andere deze feedback begreep ik het proces veel beter en kwamen we tot een nog beter eindresultaat. Zo leverde het automatiseren van het brokerrapport nog 10 minuten minder werk op.
Les 2: Niet alle informatie is even belangrijk
Mijn collega’s hadden me erop gewezen: bedenk eerst goed hoe je applicatie eruit moet zien, voordat je begint met bouwen. Wat is de informatie die je nodig hebt om een applicatie te bouwen? En bepaal welke informatie écht belangrijk is voor de eindgebruiker om te zien en te gebruiken. In theorie is dat makkelijk, maar de praktijk bleek toch weerbarstiger. Het Excelsheet waarmee ze werkten stond vol met cijfers, regels en andere informatie die ik niet direct begreep. Bovendien kan ik alleen niet bepalen welke informatie echt van belang is. Door in gesprek te gaan met eindgebruikers, kwam al snel naar voren dat sommige informatie eigenlijk overbodig was. Ik leerde ook dat bepaalde informatie wel in SAP moest komen, maar niet per se getoond moest worden in de applicatie. Denk bijvoorbeeld aan bepaalde boekhoudkundige informatie van de gekozen mutatie. Zo kwamen we voor het ontwikkelen van de app tot een schema met informatie die we echt nodig hadden om de applicatie te bouwen.
Les 3: Denk net even een stapje verder dan de eindgebruiker
De input van eindgebruikers is cruciaal, maar als developer ben jij uiteindelijk degene die de vertaalslag maakt van input naar de inrichting van de applicatie. Hoe komen eindgebruikers de applicatie binnen? Hoe ziet de userinterface eruit? Welke functies – zoals filters, zoek- en drop-downvensters – biedt je eindgebruikers? Kortom, je moet nadenken hoe je data wilt presenteren. Daarin mag je soms best een suggestie doen om dingen net even anders aan te pakken. Dat zit soms in de kleinste details. Bijvoorbeeld in de datum die eindgebruikers bij iedere boeking moeten invoeren. Dit is niet de datum van invoering, maar de laatste dag van het huidige kwartaal. Gebruikers moesten dat voorheen altijd zelf opzoeken en invoeren. Daarom besloot ik in de achtergrond wat extra logica te bouwen. Nu hoeven gebruikers alleen maar in een drop-downvenster het juiste kwartaal te selecteren. Het venster is ook dynamisch, dus in 2021 worden de data automatisch aangepast. Simpel, maar het scheelt eindgebruikers toch weer een minuutje werk. Zo heb ik meer slimmigheden ingebouwd, waardoor eindgebruikers alleen de voor hen tastbare en duidelijk informatie in hoeven te vullen, zonder alle technische variabelen die SAP van ze vraagt.
Les 4: Ben je bewust van de impact van wat je doet
De grootste stap die ik heb gezet tijdens dit project, is dat ik veel kritischer ben geworden. Ik merkte in het begin dat er veel processen speelden waar ik geen flauw benul van had. Als een eindgebruiker een volmacht-boeking maakt, dan hangen daar veel (administratieve) processen en afhankelijkheden aan vast. Het feit dat mijn userinterface werkte, betekende bijvoorbeeld niet dat het op de achtergrond ook goed ging. Ik werd op mijn vingers getikt door een collega IT’er van Finance toen ik het belang van een kleine code over het hoofd zag. Die ene code bleek van cruciaal belang te zijn voor onze grootboekrekening. Er waren meer van dit soort processen waar ik me onvoldoende bewust van was. Die kennis doe je ook niet op in een boek, maar door veel te praten met collega’s, het laten zien van demo’s bij verschillende afdelingen, te testen en vooral door te doen. Ik beweer niet dat ik nu alles weet, maar ik snap nu veel beter wat ik aan het doen ben.
Als organisatie de grootste winst behaalt door een proces echt onder de loep te nemen en met je eindgebruikers samen te werken.
Laat je gebruikers zelf uitvinden of de app goed werkt
Inmiddels staat er een volledig functionerende volmacht-app. Eindgebruikers gebruiken een zoekvenster om de gevolmachtigde agent te selecteren. Alle aanvullende gegevens van de volmacht worden vervolgens automatisch ingevuld. De eindgebruiker hoeft alleen nog het kwartaal en de mutatiesoort te selecteren en het bedrag en eventueel een omschrijving in te vullen. Na akkoord krijgen ze een controlescherm te zien, om de boeking definitief te bevestigen. Alle andere processen zijn volledig geautomatiseerd. Daarmee brengen we een proces van 15 tot 20 minuten terug naar 2 minuten. Wekelijks wordt de app ongeveer twintig gebruikt, dus dat scheelt eindgebruikers al gauw 4 uur werk per week.
Ik besef me nu dat je als organisatie de grootste winst behaalt door een proces echt onder de loep te nemen en met je eindgebruikers samen te werken. Heb je een eerste versie gebouwd? Laat eindgebruikers vooral zelf uitvinden hoe alles werkt en begrijpen wat ze in de applicatie zien. Als dat goed gaat, dan heb je een goede applicatie gebouwd.