Een verzoek om betere Power BI-rapportages groeide uit tot een onderzoek naar informatie, gebruikersbehoeften en de inrichting van een applicatie. Voor mij laat dit zien hoe applicatiebeheer en Business IT Analysis in de praktijk op elkaar aansluiten.
Het begon met een rapportage
De oorspronkelijke vraag was overzichtelijk: maak betere rapportages op basis van twee SharePoint-lijsten met QIP-meldingen. De gegevens stonden verspreid doordat een oude lijst was overgezet vanuit een eerdere SharePoint-omgeving.
Voor de eerste Power BI-rapportage had ik in beide lijsten een aantal velden gedefinieerd waarop gefilterd kon worden. Zolang de behoefte bestond uit een overzicht van meldingen en enkele taartdiagrammen, werkte dat goed. Mijn uitgangspunt was dat ik een rapportage moest opleveren.
In de gesprekken die volgden, werd duidelijk dat er meer nodig was.
Van inzicht naar opvolging
De QIP-manager wilde goed kunnen rapporteren aan de groep. Daarmee wilde hij ook belangstelling wekken voor de functionaliteit van de applicatie en laten zien hoe ons kantoor deze gebruikte. Voor gebruikers moest het een prettige manier zijn om informatie over problemen binnen projecten terug te vinden.
De QHSES-manager wilde daarnaast meer structuur in de omschrijvingen en meldingen. Hij wilde kunnen zien hoe lang een QIP openstond, bij welke afdeling deze lag en hoe deze kon worden toegewezen aan een andere afdeling die het probleem zou moeten oplossen.
Deze vragen raakten zowel de rapportage als de manier waarop meldingen werden vastgelegd en opgevolgd. Om te begrijpen wat hij precies voor ogen had, heb ik meerdere gesprekken met hem gevoerd.
Onderzoeken waar de grens ligt
Een van de wensen was om vanuit Power BI in de volledige tekst van de SharePoint-pagina’s te kunnen zoeken. Gebruikers moesten op basis van bepaalde omschrijvingen een relevante QIP kunnen vinden.
Ik ben eerst gaan onderzoeken of dat binnen de bestaande opzet te realiseren was. Toen bleek dat de gewenste functionaliteit daarin niet haalbaar was, heb ik dat teruggekoppeld.
Tegelijkertijd onderzocht ik een alternatief. De nieuwe SharePoint-lijst en een bijbehorend Excelbestand waren al gestructureerd opgebouwd. Dat bood aanknopingspunten voor een databaseoplossing waarin de informatie in afzonderlijke onderdelen kon worden vastgelegd.
Daarbij hield ik twee uitgangspunten aan: ons kantoor moest de gegevens lokaal kunnen beheren en de applicatie moest los van de database kunnen worden ontwikkeld. Zo konden we de gegevensstructuur en de gebruikersinterface elk gericht aanpassen.
Een voorstel tastbaar maken
Om mijn voorstel te onderbouwen, bouwde ik een demo met ongeveer twintig QIP-items.
Met Power Apps liet ik zien dat een verbinding met een lokale database mogelijk was. Gebruikers konden gegevens invoeren en een QIP terugvinden op basis van het QIP-nummer. De inhoud had ik verdeeld over afzonderlijke onderdelen, zodat deze niet in één groot tekstveld werd opgeslagen.
Daarnaast maakte ik een PDF-viewer waarmee een QIP als PDF kon worden bekeken en afgedrukt. Power BI koppelde ik aan dezelfde database om te laten zien hoe de gegevens ook voor rapportages gebruikt konden worden.
De demo maakte de voorgestelde inrichting bespreekbaar. We konden aan de hand van werkende onderdelen bekijken hoe invoer, raadpleging en rapportage op elkaar aansloten. De bredere wensen voor zoeken en opvolging vormden daarbij de richting voor verdere ontwikkeling.
Van demo naar verdere ontwikkeling
De reacties waren positief. Vooral de mogelijkheid om wijzigingen eenvoudig door te voeren, werd gewaardeerd. De demo liet zien dat de inrichting kon worden aangepast aan de behoeften die tijdens de gesprekken naar voren kwamen.
Vervolgens werd een consultant ingehuurd om op basis van mijn demo een complete applicatie te bouwen. Daarmee kreeg het voorstel een vervolg buiten de demonstratieomgeving.
De verbinding met Business IT Analysis
Voor mij laat dit traject zien hoe je vanuit applicatiebeheer steeds verder in een bedrijfsvraagstuk kunt komen.
Ik begon bij gegevensbronnen en rapportages. Door gesprekken te voeren, werd duidelijk welke informatie de managers nodig hadden en hoe gebruikers met QIP-meldingen wilden werken. Vervolgens onderzocht ik de technische haalbaarheid, koppelde ik beperkingen terug en vertaalde ik de behoeften naar een alternatief.
De demo hielp om dat alternatief te beoordelen en een besluit over verdere ontwikkeling te nemen.
Juist die combinatie spreekt mij aan: begrijpen wat mensen willen bereiken, onderzoeken wat daarvoor nodig is en een technische oplossing concreet maken. In dit traject werd een vraag om betere rapportages zo het vertrekpunt voor een bredere verbetering van de applicatie.