Applicatielandschap gebouwd vanuit verleden is geen garantie voor toekomst

Beperkte flexibiliteit en innovatieruimte

Veel organisaties kampen met een te complex

applicatielandschap. Onnoemelijk veel koppelingen en

interfaces maken het landschap eigenlijk één groots

generiek systeem. Het is daardoor erg kostbaar

geworden dit geheel ordentelijk te beheren en

onderhouden.

Ook is hierdoor de kracht om te innoveren steeds kleiner geworden. Zowel innovaties van de

organisatie zelf als op technisch gebied vergen dusdanig veel vermogens van ontwikkelaars,

projectmanagers etc. dat deze innovaties maar mondjesmaat en traag tot stand komen. Ook

falen mede door deze houdgreep teveel projecten. Het ontbreken van maximale

innovatiekracht beperkt dan ook de flexibiliteit van de organisatie om als geheel in te spelen

op continu veranderende (markt-)omstandigheden. Bij het geheel moet je dan denken aan

alle ingrediënten van de SCOPAFIJTH principes.

Definitie SCOPAF(I)J(T)H:

SCOPAFIJTH is een acroniem voor de ondersteunende processen van een organisatie.

Ondersteunende processen houden de organisatie in stand en leveren mensen en middelen

voor het uitvoeren de kerntaken van de organisatie. Ondersteunende processen worden ook

wel aangeduid met 'bedrijfsvoeringsprocessen' of 'instandhoudingsprocessen'.

Het woord SCOPAFIJTH is een acroniem voor: Security, Communicatie, Organisatie,

Personeel, Administratieve organisatie, Financiën, Informatievoorziening, Juridisch,

Technologie, Huisvesting.

Versnipperd IT beheer Beheer en onderhoud van applicaties en ook van infrastructuren is veelal belegd bij externe

organisaties. Op basis van het verleden (wie heeft de applicatie of infrastructuur

ontwikkeld?) heeft een bepaalde leverancier het beheer en onderhoud op zich genomen. De

samenhang tussen deze leveranciers bepaalt de efficiency van het totale beheer, maar deze

samenhang blijkt erg moeilijk te regisseren/managen vanuit de eigen gebruikersorganisatie.

Toch blijft deze “constructie” in tact. Kennis van in beheer zijnde voorzieningen is immers

schaars en een risico bij migratie.

Dit is één van de voorbeelden die illustreren dat er een steeds groter wordende mismatch is

tussen de flexibiliteit van het beheerde applicatie- en infrastructuur portfolio (IT) en de

overige SCOPAFJH (van de gebruikersorganisatie).

Verstikkende contracten

Een ander in het oog springende beperking in beheer zijn de verstikkende contracten,

afspraken en procedures welke nog (te) vaak zijn gebaseerd op het in stand houden van het

bestaande. De afspraken zijn onvoldoende gericht op het daadkrachtig realiseren van

veranderingen. Ook hierdoor wordt onvoldoende ruimte overgelaten voor noodzakelijke

innovaties.

Op zich is er natuurlijk niets mis met het vastleggen van afspraken met de IT dienstverleners

in contracten (SLA’s OLA’s), maar steeds vaker ondervinden organisaties meer hinder dan

gemak van deze afspraken. Dergelijke contracten zetten organisaties steeds verder in

juridische houdgrepen. Discussies gaan vaak niet meer over het oplossen van problemen,

maar vooral over wie er verantwoordelijk of aansprakelijk is voor het ontstaan ervan. Dit

komt de benodigde tijd en energie voor het daadwerkelijk oplossen van het probleem

uiteraard niet altijd ten goede.

(H)erkenning van het probleem Het probleem is gelukkig al lang (h)erkend. Veel organisaties hebben de

complexiteitsreductie hoog op de management agenda’s gezet. De oplossing wordt vooral

groots gezocht. Een paar voorbeelden:

Programma’s voor totale applicatie rationalisatie; Enterprise architecturen worden opgesteld;

Budgetten voor beheer worden geknepen en beschikbaar gesteld aan innovatieprojecten;

Gewenste (eind/doel) situatie wordt helder en weloverwogen in kaart gebracht;

Rubricering hanteren in zogenaamde business domeinen of processen om hier vervolgens

applicaties aan toe te wijzen.

Deze grootschalige aanpakken zijn vaak top down. Hoewel noodzakelijk en goed, vergeet

men vaak ook een bottom-up benadering na te lopen. Met als gevolg: resultaten laten lang

op zich laten wachten en de initiatieven blijken een soort permanent karakter te krijgen, als

onderdeel van het reguliere werk.

Tips om complexiteit bottom-up te reduceren Om de complexiteit sneller te reduceren en de innovatiekracht te vergroten kunnen vele tips

gegeven worden. In dit blog deel ik er twee waarmee je direct kunt starten, zonder (of naast)

grootse plannen en programma’s. Onderneem de kleinst mogelijke stap, welke direct een

zichtbare reductie in complexiteit oplevert, op een agile werkwijze. Breng mensen bij elkaar

vanuit de “silo’s” en stuur op het opleveren van direct zichtbaar en tastbaar resultaat. Kleine

sprints leveren vaak snel rendement op, waarop vervolg kan worden gegeven. “Zien eten,

doet eten”.

Tip 1: Verbrand de beklemmende contracten (betonnen zwemvesten). Het is noodzakelijk het

proces van samenwerken tussen business en IT leveranciers te verbeteren. Dit kan door de

energie te richten op het daadwerkelijk oplossen van problemen en verstoringen. En het

vereenvoudigen van het doorvoeren van veranderingen. Om dit te kunnen realiseren stel ik

voor de huidige procedures om te komen tot contracten (SLA’s) en de contracten zelf ritueel

in de vuurkorf te gooien. Daarna opnieuw beginnen met het maken van afspraken met als

doel een antwoord te geven op dé vraag:

“Welke afspraken moeten we maken om ervoor te zorgen dat business en IT optimaal op

elkaar afgestemd zijn? Met gedeelde doelstellingen en gezamenlijk belang?”

Een significante bijdrage leveren aan het verhogen van de flexibiliteit zou hierbij één van de

meest belangrijke belangen moeten zijn.

Tip 2: Haal de stofkam door je bestaande applicaties en infrastructuur. Zet applicaties écht uit als

ze niet meer gebruikt worden. Haal alternatieven uit de beschikbaarheid. Eén van onze

klanten heeft hiervoor een mooie term bedacht: Appruimen!

Als je het gewenste applicatielandschap in kaart hebt gebracht, is het belangrijk om direct de

applicaties die daar niet meer toe behoren ook daadwerkelijk te gaan verwijderen. Doordat

deze applicaties weinig tot geen (management)aandacht meer hebben, staat dit vaak niet

meer op de actielijst!

Maak afspraken over het daadwerkelijk uitzetten van applicaties welke zijn “afgeschreven”.

Hiervoor hebben wij een standaard aanpak beschikbaar, welke in de praktijk bewezen is als

laagdrempelig en succesvol. In ons volgende blog zullen we hier dieper op ingaan. Je kunt

uiteraard altijd contact met mij opnemen om hierover van gedachte te wisselen.

Auteur: Jeroen Eijskoot