Huidige situatie

Laatst bijgewerkt op 1404 dagen geleden door Marcel Ziemerink

Om te kunnen plannen wat er moet gebeuren, moeten u eerst weten hoe het nu is. Daarvoor moet u de huidige situatie beschrijven. Vanuit die beschrijving kunt u vervolgens de gevolgen van de verandering bepalen (zie Migratiepad#Gapanalyse). Verderop in de tijd moet u kunnen bepalen wat het effect van de verandering is geweest (zie ook Vergelijking resultaat met ontwerp). Let daarbij op dat u zich niet laat verleiden tot eindeloze detailbeschrijvingen. Een valkuil waar u gemakkelijk in kunt vallen.

Bij het vaststellen van de huidige situatie gaat u vooral uit van die onderdelen van organisatie en ICT waar u verwacht dat veranderingen nodig zijn. Hierbij kunt u het best gebruik maken van een risicogedreven aanpak: die dingen die de grootste risico’s voor het verandertraject opleveren, zoekt u het eerste en beste uit. Kies voor een "just in time, just enough" benadering om zo het gevaar van "analysis paralysis" te vermijden.

De beschrijving van de huidige situatie is, samen met het bestemmingsplan (onderdeel van de langere termijn architectuurvisie), input voor de volgende stap in het ontwikkelproces: het plannen van een migratiepad.

Waar wilt u iets veranderen?

De scope van de verandering is het belangrijkste criterium. Wat bepaalt wat u moet beschrijven in de huidige situatie? Dat zijn natuurlijk de organisatiedoelen en de kanaalconfiguratie die u wilt realiseren. Iets wat niet verandert, hoeft u niet (of hooguit als context) te beschrijven. Concentreert u zich op die plekken waar de beoogde verandering het diepste ingrijpt. Daar moet u het meeste inzicht in de huidige situatie hebben. Gebrek aan scope vergroot de kans dat er brokken gemaakt gaan worden.

Waar verwacht u nog meer impact van die verandering?

Een verandering heeft vaak neveneffecten op andere onderdelen van de organisatie of techniek. U zult moeten vaststellen waar u dergelijke veranderingen verwacht. Ook dat zijn aspecten die in de beschrijving van de huidige situatie meegenomen moeten worden. Denk daarbij niet te smal: veranderingen hebben soms onverwachte gevolgen. Wanneer het om grote verandertrajecten gaat, is een COPAFIJTH-brede scan aan de orde.

Stel knelpunten vast

Vanzelfsprekend zijn de organisatiedoelen en de (eventueel veranderende) omstandigheden en randvoorwaarden leidend bij het vaststellen van de knelpunten. Veel knelpunten zijn vaak wel bekend in de organisatie. Maar ze worden door verschillende stakeholders verschillend ervaren. Zo kan de leidinggevende een andere mening hebben over de benodigde mate van klantgerichtheid dan de medewerkers. En burgers kijken er nog weer anders tegenaan.

Voor het vaststellen van de knelpunten moet uw indruk van de situatie voldoende breed zijn. Praat daarom nooit met één maar altijd met meerdere (groepen) stakeholders. Dat hoeft geen heel zware exercitie te zijn. Een paar korte interviews met verschillende geledingen in de organisatie en onder burgers (of burgerpanel) geven al vaak een goede eerste indruk.

Natuurlijk moet een dergelijke indruk sterker onderbouwd worden als het bijvoorbeeld gaat om ingrijpende veranderingen met hoge kosten. Dat kan met kwantitatieve klantonderzoeken, meetgegevens uit de operationele praktijk van de organisatie (bijvoorbeeld doorlooptijden van processen, belasting van de technische infrastructuur, etc.). Bij zulke analyses kunnen architectuurmodellen behulpzaam zijn.

Stel kansen vast

Richt u in een verandertraject niet alleen richten op de dingen die slecht gaan en beter moeten. Kijk ook naar de nieuwe kansen die een verandering biedt. Soms is zo’n kans de aanleiding zelf voor de verandering. Maar soms kunt u ook een (al geplande) verandering aangrijpen om een andere kans te benutten. Denk bijvoorbeeld aan een verhuizing naar een ander gebouw wegens ruimtegebrek, waarin meteen een nieuw balieconcept wordt meegenomen. Of aan de vervanging van een legacy-applicatie die te duur is geworden in onderhoud. Bij die vervanging kan meteen de applicatiearchitectuur worden verbeterd door een interne kernregistratie voor klantgegevens in te voeren.

Kloppen bestaande architecturen nog?

Veel organisaties hebben in eerdere verandertrajecten al wel eens architecturen beschreven. Hergebruik daarvan verdient natuurlijk de voorkeur boven het opnieuw beschrijven. Helaas worden die architecturen na afloop van een project vaak niet actueel gehouden (zie ook de verantwoordelijkheden van het architectuurteam). Ondertussen is er in de organisatie of techniek al het nodige veranderd. Voordat u bestaande architecturen hergebruikt, moet u deze daarom eerst op hun kwaliteit beoordelen. Dat kan bijvoorbeeld door de betrokken architecten of ontwerpers te interviewen, of door het steekproefsgewijs toetsen of de werkelijke situatie nog overeenkomt met de architectuurbeschrijving.

Modellen als hulpmiddel

Bij het beschrijven van de huidige of toekomstige situatie kunnen architectuurmodellen nuttige diensten bewijzen. Niet alleen om vast te leggen wat de situatie is of wordt, maar ook om de gevolgen van de verandering te kunnen analyseren.

Reageren is alleen mogelijk voor aangemelde gebruikers