Category Archives: DevOps

En hoe nu consultancy versnellen?

In deze reeks over versnelling en complexiteit heb ik gekeken naar het “waarom” van versnelling & complexiteit en het “hoe” van kunnen versnellen. Wat werkt versnelling tegen (complexiteit) en wanneer is versnellen geen goed idee (persoonlijke aandacht). Verder heb ik belicht waarom proces kwaliteit bestaat (het versnelt ons) en welke rol standaardisatie en cloud hierbij kunnen spelen (dat versneld ons ook, mede door complexiteit te verlagen). Dit keer wil ik graag naar ons als IT professionals kijken. Moeten wij ook versnellen, waarom en hoe doen we dat dan?

Business as usual?

Als ons klanten willen versnellen – en die case is wel gemaakt denk ik – dan is de eerste vraag die IT professionals zich moeten stellen, “Kunnen we onze klanten daarbij helpen”? Mij lijkt dat IT instrumenteel is bij het versnellen van bedrijfs – en productieprocessen. Dus ja, daar kunnen we bij helpen. De producten en diensten die we leveren moeten daarom bovenal in staat zijn om onze klanten te helpen versnellen. Dat is ook vaak zo, denk aan Infrastructure as Code (IAC) waarmee we heel snel netwerken en servers kunnen bouwen. Ook kan je hierbij denken aan geautomatiseerde deployment van changes (CICD). Een klant wil vast geen technologie, dat is namelijk maar een middel, maar die wil iets bereiken, een website draaien bijvoorbeeld. Feitelijk wil men een business vraagstuk oplossen en geen nieuwe introduceren.

Low Code wel zinvol dan?

Naast onze klanten direct versnellen, kunnen we ook de complexiteit verlagen. Zoals ik eerder al betoogde is de gang naar de “Cloud” daar een aardig voorbeeld van. Door standaardisatie zijn we beter instaat te begrijpen wat we doen en kennen we de kwaliteit (en beperkingen) beter. Het is als puzzelen met hapklare brokken. Het gevolg is dat de klant dan kan versnellen.

Ook het gebruik van Low Code kan klanten versnellen, door (wellicht tijdelijk) de focus te leggen op de business en wat minder op technologie. In een later stadium kan dat weer anders worden. Misschien wil een bedrijf na verloop van tijd meer aandacht geven aan de technische implementatie. De juiste keuze helpt je dan te versnellen.

Vertragen levert toch meer uren op?

Als IT consultancy klanten helpt te versnellen, waarom zouden we dan zelf moeten versnellen? Dat lijkt contra intuïtief, want we verdienen ons geld aan uren, dus waarom dan sneller?

Als eerste denk ik dat als we relevant willen blijven en succesvol willen blijven concurreren met onze vakbroeders, we moeten versnellen. Ook lijkt mij dat als we onze klanten willen helpen versnellen – en dezelfde technieken gaan gebruiken – we daardoor zelf ook versnellen. En dat heeft alles te maken met het “Hoe” van het versnellen.

Hoe dan?

Zoals ik eerder betoogde, bestaat een kwaliteitsysteem om de snelheid te verhogen. Willen we IT consultancy versnellen, dan is “One Time Right” wel een goede aanpak. Waarom omarmen we in de IT dan het kwaliteitsdenken niet? Laten we een voorbeeld nemen aan Toyota. Door te standaardiseren kunnen we klanten sneller helpen, met voorspelbare resultaten, tegen voorspelbare kwaliteit en kosten. Naar mijn idee sluit dat aan bij wat klanten nodig hebben en willen.

Waarom heeft Max een pits stop?

Daarom lijkt mij dat we de IT consultancy business kunnen versnellen als we zorgen voor een hogere kwaliteit (certificeringen bijvoorbeeld), professionalisering en verdergaande standaardisatie. Klanten vragen niet meer om een “One off”, maar willen liever “Standaard” tegen een voorspelbare doorlooptijd en prijs. Het her-gebruik van software en standaardisatie middels het gebruik van “Standaard bouwblokken” ligt dan ook voor de hand. Dit is niet nieuw, maar wel heel actueel. Dus waarom heeft Max een pits stop nodig? Om daarna sneller te kunnen gaan!

Versnelling en complexiteit, daar draait het om

Snel, sneller, snelst

Bedrijven en organisaties gaan in onze westerse maatschappij steeds sneller. Nergens is dat beter zichtbaar dan in het IT vakgebied. En snelheid is belangrijk, want het houdt de kosten laag en verbetert de concurrentiepositie. Consumenten worden zo eigenlijk verwend met wachttijden die korter worden. We houden dan ook niet van wachten.

Het telkens verder versnellen van organisaties en bedrijven lijkt daarmee een logische keuze en dat is het ook. Er is nooit een bedrijf gestart om productie of diensten te vertragen. Bovendien, versnelling van productie leidt tot lagere kosten, want hoe minder tijd je kwijt bent, hoe lager de kostprijs. Dus ook vanuit een bedrijfseconomisch perspectief is versnelling een goed idee.

Complexiteit

Maar er werkt ook iets tegen de versnelling in. Een tegenkracht, zo je wilt, en dat is complexiteit. Als een situatie complexer wordt, kan je minder snel. Dus versnellen kan je ook door de complexiteit te verlagen. Complexiteit kan je bijvoorbeeld verlagen door te standaardiseren. Als iets standaard is, kan je het sneller leveren en met minder verliezen en dus goedkoper. Een aardig voorbeeld hiervan is Infrastructure as Code. Dit is het bouwen van infrastructuur middels een script (code). Dat bouwt netwerken en systemen volgens jouw recept en specificaties, telkens opnieuw, zo vaak als jij dat wil.

Concert op dubbele snelheid?

Maar moeten we dan alles altijd maar versnellen? Dat is zeker niet zo. Er zijn wel degelijk uitzonderingen. 

In een ziekenhuis of verzorgingshuis kan je de aandacht voor patient en bewoner niet versnellen, daar is juist vertraging nodig om het contact waardevol te maken. Persoonlijke aandacht is echt een belangrijke uitzondering.

Een andere uitzondering is, iets leren. Wanneer je iets wil leren en het echt wilt doorgronden, dan heb je daar aandacht voor nodig, je moet hiervoor vertragen. Je zou kunnen stellen dat alles wat te maken heeft met “Het beleven” tijd vraagt. Je wilt een massage toch niet versnellen? of een concert? Kortom, niet alles laat zich versnellen

Fouten maken mag, mits sneller

Kijk met dit perspectief eens naar kwaliteitssystemen of standaardisatie. Vanuit de automotive weten we dat een fout in processtap 1, tien keer meer inspanning kost om die in stap 2 te fixen. Fouten maken is dus kostbaar. Dubbel eigenlijk, want de inspanning die je daaraan besteed kan je niet gebruiken om (de productie) te versnellen. Je wil fouten daarom zo vroeg mogelijk in het proces identificeren en corrigeren.

Ik denk dan ook dat standaardisatie en (proces) kwaliteit ons direct helpen te versnellen. Ik denk zelfs dat hun bestaansrecht daarin gelegen is. In de IT kunnen we daarom leren van de automotive.

IT gaat snel, IT’ers zijn langzaam

Maar we kunnen zelfs een stap verder gaan. We worden al jaren overspoeld met methoden als ITIL, Prince2, Agile, Scrum en DevOps. Blijkbaar is er telkens iets nieuws nodig om het doel te bereiken. Ik denk dat de rode draad ook hierin versnelling is. Telkens proberen we met nieuwe methodes meer grip te krijgen op IT (projecten) en resultaten. En wat willen we dan bereiken? Waarschijnlijk sneller resultaten bereiken en voorspelbaar worden. Ook hier gaat het dus  om snelheid, want voorspelbaarheid verhoogt de snelheid. Hoe meer grip men op projecten (en de uitkomsten daarvan) heeft, hoe sneller het gaat.

Zoeken naar de balans

Ik denk dat de grote uitdaging van bedrijven en organisaties vandaag de dag is: “Wat kan ik versnellen, maar wat moet ik vertragen?”. Interessant hierbij is dat we met versnelling tijd, ruimte en geld kunnen creëren om andere processen te vertragen. Bijvoorbeeld, als ik het beantwoorden van 80% van alle helpdesk vragen kan automatiseren (chatbots e.d.) dan krijg ik tijd om klanten die dat nodig hebben te woord te staan. Daarmee verbetert mijn dienstverlening en mijn concurrentiepositie.

Een ander mooi voorbeeld hiervan is Coolblue. Het overgrote deel van de verkoop verloopt via de website – lekker snel, maar voor klanten die daaraan behoefte hebben zijn er de Coolblue winkels. Daar krijg je persoonlijke, 1 op 1 , aandacht van een medewerker die je helpt met al je vragen rond de producten die je wil kopen.

Versnelling en complexiteit zijn in mijn ogen bruikbare perspectieven om ons handelen in de IT te begrijpen. Ik zou zelfs willen voorstellen het actief als criterium te gaan gebruiken.