Een verstandige manager houdt daar rekening mee, maar in de praktijk komt daar dikwijls bar weinig van terecht. Verschillende ict'ers worden gemakshalve op één hoop gegooid.

Vaak is dat onterecht. “Vraag iemand wat voor type mensen rondlopen op een ict-afdeling, en het antwoord is altijd: 'dat zijn allemaal bèta's”, zegt Niels Loader, principal consultant bij Quint Wellington Redwood. “Tot op zekere hoogte klopt dat ook wel. Maar wie iets beter naar zo'n afdeling kijkt, ziet dat bijvoorbeeld programmeurs en anderen die aan de applicatiekant werken eigenlijk ook een soort kunstenaars zijn.”

Creatief

Immers, zo redeneert Loader, deze ict'ers zijn aangewezen op hun creativiteit om problemen op te lossen en taken uit te voeren. Dat is anders dan de ict'ers die zich met de infrastructuur bezig houden, omdat deze juist heel systematisch en volgens standaardprocedures te werk moeten gaan.

“Het resultaat is dat je binnen een organisatie alfa's hebt die op een bèta-manier worden aangestuurd”, zegt Loader. “De vraag is dan: haal je zo wel het beste uit deze mensen? Alfa-mensen hebben de neiging om iets minder gestructureerd te zijn, hanteren misschien ietwat andere werktijden en je krijgt andere soorten interacties.”

Regels en ITIL

Dat terwijl de andere groep ict'ers meer volgens een 'één en één is twee'-manier werken en systemen aan elkaar moeten koppelen, aldus Loader. “Dat is allemaal configuratiewerk, en dat werkt volgens vaste regeltjes.” Als iemand die gewend is uit het niets iets te creëren door een aantal zinnetjes bij elkaar te programmeren, ineens volgens hetzelfde stramien moet gaan werken, dan krijg je te maken met een mismatch, zo waarschuwt Loader. “Je ziet het binnen vrijwel alle ict-organisaties gebeuren: de applicatie-mensen en de infrastructuur-mensen zijn als water en vuur. Ze werken volstrekt langs elkaar heen en spreken niet dezelfde taal.”

“Een techneut aan de infrastructuur-kant vindt ITIL bijvoorbeeld geweldig, omdat het structuur aanbrengt in hun werkzaamheden. Maar een applicatie-persoon walgt ervan, omdat hij helemaal geen behoefte heeft aan die structurering,” vervolgt Loader, die als voorbeeld een klant neemt waar hij recentelijk op bezoek was. “Aan de infrastructuur-kant werd daar altijd gesproken over een change, en dat deden die technici heel gestructureerd ongeacht waar de wijziging vandaan kwam.”

Twaalf woorden voor een 'change'

“Maar op de ontwikkelingsafdeling hebben we twaalf verschillende woorden geteld die werden gebruikt om een change mee te beschrijven, afhankelijk van waar de change vandaan kwam of waar het over ging. De ene keer was het een 'project', de andere keer een 'wijziging, in weer een ander geval was het een 'bugfix' of een 'patch'. Ze wilden het absoluut niet op een grote hoop gooien, en de infra-mensen werden daar he-le-maal gestoord van.”

“Stiekem zit daar vanuit de applicatie-mensen ook een soort ijdelheid achter, vergelijkbaar met wat je in de financiële wereld ziet”, omschrijft Loader. “Ook financiële professionals hebben allerlei prachtige constructies bedacht. Maar ook in de financiële wereld is het een kwestie van twee-min-één-is-één. We hebben het met elkaar lekker moeilijk gemaakt.”

Vereenvoudig de taal

Wat betreft de gebezigde taal, is het volgens Loader het beste als je wat tegemoet komt aan de 'bèta's' door het eenvoudig en eenduidig te houden. Dat betekent niet dat je de 'drang' die applicatie-mensen hebben als manager gewoon naast je neer kunt leggen. “Maar de rol van het management is om het goed uit te leggen waarom dat noodzakelijk is”, betoogt Loader. “Natuurlijk zullen sommigen lastig blijven, maar de meeste ict'ers snappen de noodzaak ervan echt wel. Zolang je maar met een goed verhaal komt.”

Meten en doelen verschuiven

Een tweede element is dat je de werkzaamheden, ongeacht de 'bloedgroep' van de technici, moet meten zonder daar een waardeoordeel over de hebben. “Laten we verstoringen, incidenten dus, nemen. Die heb je zowel op een applicatie als op de infrastructuur”, noemt Loader als voorbeeld. “Je meet hoeveel tijd het kost om de incidenten op te lossen: de applicatie-mensen doen het in zoveel tijd, en de infrastructuur-mensen doen het in zoveel tijd. Dat giet je in een index, en die kun je als nulmeting nemen.”

“Vervolgens is de clou: hoe kun je tot minder incidenten komen, en hoe zorg je ervoor dat incidenten sneller worden opgelost?”, legt Loader uit. “Dat doe je voor beide bloedgroepen apart. Het gaat om het neerzetten van de berekeningen en de openheid van de metingen, en hoe je ermee om gaat.”

Daarbij moet je volgens Loader geen norm neer proberen te zetten, iets waar de infrastructuur-groep naar neigt. “Die willen nog wel eens concluderen dat de doelstelling wordt: 90 procent van de incidenten op tijd oplossen.”

“Dat is een verkeerde meting, want ze moeten 100 procent van de incidenten op tijd oplossen”, meent Loader. “De meetlat wordt juist dat de gemiddelde oplostijd gaandeweg terug wordt gedrongen. Daarbij kom je er bijvoorbeeld op uit dat we dit jaar nog 7 uur over een incident mogen doen, en het volgende jaar 6 uur.”

“Op die manier blijven je mensen op zoek naar manieren om het beter te doen, en dat is waar je de manager op kunt afrekenen.”