12 slechte gewoontes die IT gruwelijk vertragen
01-09-2017
De weg naar bottleneck-hel is geplaveid met goed bedoelingen. Bepaalde gewoontes moeten leiden tot goed IT-beleid - commissies, kijken naar TCO, formeel blijven met ITIL - maar zorgen voor een traag zootje. Dit zijn de kenmerken van een trage IT-organisatie - roei ze een voor een uit!
Wanneer is de IT-afdeling te traag? Nou, als mensen moeten wachten tot iets wordt afgeleverd; dat is een aardig teken dat er iets niet klopt. Managers praten over 'time to value', maar de echte meting is hoe je je verhoudt op concurrenten. Als IT een vertragende factor is waardoor de concurrenten je inhalen, dan raakt het bestuur zijn geduld kwijt en zijn de rapen gaar.
Wil je weer soepeler worden? Dan moet je als eerste kijken naar de factoren IT zo traag maken, de organisatorische of pragmatische bottlenecks. Heb je een afdeling waar het qua oplevering en afhandeling stukken beter kan? Lees dan vooral verder, want hier volgen twaalf plekken om eens kritisch naar te kijken de komende weken.
1. 'Death by committee'
Toezicht bepaalt grotendeels het tempo van IT en als commissies alles waar ze zich mee bezighouden vertragen met hun vergaderingen, weet je dat IT gedoemd is zo traag te worden als dikke snert door een trechter zodra overlegstructuren het middelpunt worden van het beleid.
Begin door de grootte aan te pakken. Elk aanvullend commissielid vertraagt het beslissingenproces met input en vragen. Meer dan vijf leden zorgt voor een dodelijk trage pas, omdat het lastig is om consensus te bereiken in zo'n groep.
Het is nog erger als dit geen IT-verantwoordelijken zijn, maar als leden zichzelf zien als afgevaardigde van een groep of afdeling die het beste resultaat moet hebben. Met zulke leden wordt een commissievergadering een gevecht om invloed in plaats van om problemen waar de organisatie mee worstelt op te lossen.
Dan is er nog de frequentie van de bijeenkomsten. De planning is de metronoom die de pas van het project bepaalt. Als een groep maandelijks bijeenkomt om te vergaderen, duurt het uiteraard een maand voordat een beslissing genomen wordt over bijvoorbeeld een wijzigingsverzoek. Hoeveel projecten denk je dat je op tijd kan afleveren met zo'n bottleneck?
Hoe dit oplost? Maak de bedrijfscultuur het toezicht: als iedereen begrijpt wat belangrijk is en waar hij of zij zich primair op moet richten, is toezicht door een beleidscommissie bijna overbodig. Zie zo'n cultuur als de strepen op de weg die iedereen leiden, en de commissie is enkel de vangrail die ervoor zorgt dat de wagen niet van de baan schiet.
2. IT'ers meervoudig inzetten
Er is één simpele regel voor het meervoudig inzetten van werknemers, zodat ze verschillende taken tegelijk uitvoeren, en dat is: doe het niet!
Dat geldt vooral voor softwareontwikkelprojecten. Onderzoek toont aan dat elke onderbreking een verlies is van een kwartier van programmeerproductiviteit. Dit werk vereist een niveau van opperste concentratie waarbij de ontwikkelaar steeds moet overschakelen naar een abstracte denkwijze. Maar hetzelfde geldt voor vrijwel elke IT-taak waarbij serieus moet worden nagedacht.
De uitdaging ligt niet zozeer in het weten dát je dit soort multitasken moet verwijderen, maar hoe je dat doet. De oplossing ligt puur in management: een project mag niet van start gaan als ze geen volledige bezetting hebben. Dat is een bezetting die op geen enkel moment hoeft te wachten op een vliegende keep die vrij moet komen. De projecten worden niet alleen sneller met die vuistregel; de hele IT-implementatie wordt er soepeler door.
Â
3. Projecten
Technologie wordt gebouwd in projecten. Hoe complexer de tech, hoe groter het project. Maar met die grootte wordt de kans op falen steeds groter naarmate de vertraging toeneemt. Vandaar dat IT-ontwikkeling zich tegenwoordig minder richt op het alomvattende eindproduct, maar werkt naar itererende releases toe met stapsgewijze functionaliteitverbetering.
Daarmee ku je verbeteringen voor regressie, stresstests en uitrol beter uitvoeren en het grote voordeel is dat je omgaat met een van de zekerheden van IT-management: verbeteringen worden met succes afgeleverd; projecten falen toch. Dat hoeft geen radicale omslag te zijn. Noem het scrum en de toezichthoudende organisatorische laag is tevreden.
Maar houd daar nog niet meteen op: met releases zul je nog steeds vertragingen ondervinden. Een doorsnee sprint duurt een maand, wat dus een maandelijkse pas oplevert voor veranderingen in de bedrijfsvoering en dat is nog los van het vergaderen over wijzigingsverzoeken (weer een stukje Death by Committee als je niet oppast).
Ga er dus helemaal voor met continue integratie en uitrol. Met andere woorden: devops. Automatiseer testen, zorg dat elke wijziging voldoet aan het idee van continue integratie van een devops-strategie en zorg ervoor dat elke kleine wijziging vrijwel direct in productie kan worden genomen. Met kleine wijzigingen worden wijzigingsvergaderingen minder relevant. Vertrouw op IT. Dit zijn niet meer de dagen dat een verkeerd gezette komma de boel stillegt.
4. Handmatige provisioning
Ontwikkelteams kunnen een hele omgeving in de cloud in enkele minuten provisonen, of ze vragen het aan IT-operaties en krijgen hetzelfde in enkele maanden. Dat is een behoorlijke beperking en een keuze tussen on prem en cloud: er is een reden dat cloudproviders zo populair zijn en dat is omdat ze de ontwikkelopstarttijd zo verkorten. De betere keuze voor projecten is dus duidelijk.
Begin met dit soort automatisering en laat je ontwikkelaars vrij om hun eigen omgeving op zeer korte termijn in te regelen, in plaats van dat ze moeten wachten op de bureaucratische werking van de processen zoals ze nu nog zijn.
Â
5. Kiezen voor interfaces in plaats van integratie
We hebben het hier de laatste tijd regelmatig over een issue dat veel IT-afdelingen parten speelt: de integratie van een immer uitdijend aantal applicaties en de bijbehorende interfaces. Als je meer dan een bedrijfsunit overziet - en zelfs dan is het lastig - is het vrijwel onmogelijk om overlap te vermijden en al snel heb je een organisatorisch web van point-to-point batch interfaces.
Meer interfaces vertragen de systemen en IT als geheel, omdat ze onderhoud vereisen. Daar ben je weer IT'ers aan kwijt die op een waardetoevoegend project hadden kunnen zitten. Een goed ontworpen integratiesysteem maakt projecten sneller, testen kost minder tijd en uitrol is vereenvoudigd geworden.
Ga daarna nog een stapje verder. Tover Information Technology om tot Integration Systems, waarbij het de taak is om toegang te ontsluiten tot kernapplicaties via gestandaardiseerde API's die data en functionaliteit leveren als beveiligde, goed gedefinieerde diensten.
6. Vechten tegen Schaduw-IT
Nog een punt dat we hier op Computerworld vaker behandelen en een onvermijdelijk aspect van IT vandaag de dag: Schaduw-IT. Dan hebben we het vooral over middelen die door het bedrijf worden ingezet buiten de IT om. Eilandjes die worden gebouwd op zwakke fundamenten door eigen beslissingen zijn nu de regel, niet de uitzondering.
Maar Schaduw-IT bestaat omdat het iets doet wat het bedrijf nodig heeft. Iets wat blijkbaar niet kon of te lang duurde voordat het door de bureaucratie van logge IT-structuren kwam en direct waarde oplevert voor het bedrijf. Zie het als outsourcen van applicatieteams met briljante bedrijfsanalisten, maar verschrikkelijke architecten.
Je moet het daarom ook zeker niet negeren. Maar probeer het niet te bevechten en bied ondersteuning en hulp. In ruil daarvoor heb je meer ruimte op het interne netwerk en levert het je winst op, zelfs als je rekent dat het tijd kost om de figuurlijke riolering van die diensten aan te sluiten op het fundament van het IT-gebouw.
Als je IT hebt omgezet in Integration Systems, zoals we stelden bij bottleneck nummer vijf, kun je de API's die je hebt ook beschikbaar stellen voor Shaduw-IT-teams. Zo los je het probleem van losse eilandjes op.
Â
7. 100 procent eisen
Het is tweede natuur voor IT'ers om alles kogelvrij te willen maken. Maar het programmeren van een uitzondering die zich elke 1000 tranacaties voordoet, duurt even lang als het programmeren voor een geval dat zich honderden keren per dag voordoet.
Een old-school IT-aanpak werkt hiervoor het beste. Vroeger keken we naar de grote gevallen die we automatiseerden en de uitzonderingen werden dan afgehandeld door mensen. Computers zijn namelijk goed in de grote gevallen; mensen zijn goed in uitzonderingen.
8. Data-structuren bepalen
Er is één kenmerk van een doorsnee project om een datawarehouse aan te maken en dat is: achter op schema. Deze projecten zijn notoir en chronisch laat voordat ze worden opgeleverd omdat het lastig is om OLAP-datastructuren te optimaliseren om antwoorden te geven op vragen waarvan niemand van tevoren weet welke vragen dat zijn.
Daar komt NoSQL bj kijken. Het handelt niet alleen grote hoeveelheden data af, maar is in staat om data nu te verwerken om analisten later te laten kijken naar hoe het georganiseerd moet worden. Het vermijden van het weten welke query's je gaat krijgen is een enorme meerwaarde en het structureren aan de hand van de vraag achteraf is de reden dat Hadoop zo populair en snel is.
9. Total cost of ownership voorop stellen
Vergeten je beslissers dat kosten baten opleveren? Elke halve zool kan bezuinigen. De truc zit 'm in het snijden in de kosten, zonder dat het een negatieve impact heeft op oplevering. Hier komt Total Cost of Ownership (TCO) bij kijken en dat levert vaak slechte plannen op.
TCO maalt niet om functionaliteit, maar alleen om het verminderen van het kostenplaatje. De makkelijkste manier om dat plaatje financieel aantrekkelijker te maken is door spullen te leveren en te ondersteunen die minder functioneel en nuttig zijn. Minder gebruik staat gelijk aan lagere kosten. Dat is onvermijdelijk als je TCO het beleid laat bepalen, omdat het meetinstrumenten heeft die abstracte waardetoevoegingen niet kunnen bepalen.
Als je het niet kunt meten, krijg je het niet. Dat is dus ook de waarde die IT toevoegt. En als je de focus legt op het snijden in de kosten, kijkt niemand naar hoe je zaken kunt versnellen. Als snelheid geen prioriteit is - laat staan dat het dé prioriteit is - zal IT niet sneller worden.
Â
10. Innovatie in het IT-systeem dwingen
Bedrijven keken vroeger vooral naar behoud van status quo, maar dan met sterkere systemen. Een IT-systeem dat altijd de juiste oplossingen bood en nooit data verloor. Dat is nog steeds een belangrijke eis, maar innovatie is niet zo belangrijk. Het is de nabije toekomst: hoe je een competitief voordeel behaalt.
Dwing innovatieve mensen niet naar het IT-systeem, bijvoorbeeld werknemers die uit de voeten kunnen met hun Schaduw-IT. Geef ze eerder een hoekje waar ze zelf kunnen werken aan de manieren waarop ze innoveren en het bedrijf toekomstbestendig maken. Als ze slagen, is er later tijd genoeg om ze in het IT-systeem op te nemen.
11. Durf verliezen
Zelfs goed gerunde IT-afdelingen kunnen inschikkelijk worden, vooral in bedrijven waar mensen 'verantwoordelijk worden gehouden' als een innovatief plan niet goed uitpakt, in plaats van dat mensen worden aangemoedigd risico's te nemen.
Zo'n cultuur levert trage IT op, omdat niemand zijn kop boven het maaiveld probeert uit te steken om zaken te versnellen. Dat is de cultuur waar het mantra 'maar zo hebben we het altijd gedaan' is. Als dat de situatie is, is het hoog tijd om de beuk erin te gooien. Anders gaan IT'ers ten onder aan gezapigheid en verveling.
12. Formeel werken
Wat denk je dat sneller werkt? Een formeel gesprek waarin een SLA wordt vastgesteld en 'klanten' requirements en specificaties goedkeuren of een informele waarin je begint met: 'Wat probeer je te bereiken en hoe kunnen we helpen?'
De formele aanpak wordt door veel deskundologen als 'best practice' aangemerkt. Negeer dat advies. Ga voor beter dan best practice. Kweek sterke, informele banden en onderhandel niet. Onderhandelen is namelijk voor twee partijen die tegenovergestelde kanten hebben ingenomen. Business en IT moeten aan dezelfde kant staan.
ComputerWorld Bob Lewis
Â
Â
Â
Â