IT-operaties automatiseren hun eigen remmen weg

Twee kampen in IT kondigen op dit moment hetzelfde uitvaartfeest aan, en geen van beiden lijkt de andere te hebben opgemerkt.

In observabiliteit is het argument dat de menselijke lezer klaar is. Het geval, herhaaldelijk de afgelopen jaar gemaakt, is dat de hele geschiedenis van het vakgebied een poging is geweest om enorme hoeveelheden telemetrie samen te voegen tot iets dat een persoon in één oogopslag kan zien, en dat AI de behoefte aan die compressie wegneemt. Commentatoren beweren nu rechtstreeks dat observabiliteit is gebouwd voor mensen en dat AI-agents iets anders nodig hebben. Corey Quinn gebruikte een keynote op O11yCon, een conferentie gewijd aan het onderwerp, om de kamer te vertellen dat de primaire lezer van hun telemetrie niet langer in de stoel zit.

In servicemanagement is het argument dat het ticket klaar is. Industrievoorspellingen voor 2026 houden in dat ticketloze operaties ticketautomatisering zullen overtreffen, en het onderscheid wordt scherp getrokken: ticketautomatisering vermindert menselijke inspanning, terwijl ticketloze operaties ernaar streven om die inspanning te elimineren. Leveranciers in de hele categorie beloven nu servicedesks waar problemen worden gedetecteerd, gediagnosticeerd en gecorrigeerd voordat iemand denkt om een incident aan te kaarten.

Beide kampen hebben gelijk over wat ze doden. Wat geen van beiden heeft opgemerkt, is dat ze de tegenovergestelde helften van dezelfde structuur afbreken, en dat sommige van de dingen die ze verwijderen gewicht droegen.

Twee disciplines, één beperking

Overweeg wat observabiliteit eigenlijk bestaat uit, onder de tooling.

Steekproeven bestaan omdat niemand elke spoor kan lezen. Aggregatie bestaat omdat niemand elke metrische waarde kan lezen. Dashboards bestaan omdat een persoon naar een systeem moet kijken en een indruk moet vormen in een paar seconden. Alarmdrempels bestaan om een continue stroom van staat om te zetten in een binaire signaal, zodat een mens alleen wordt onderbroken wanneer onderbreking gerechtvaardigd is.

Elk van deze is een compressiemechanisme. Observabiliteit, structureel, is de praktijk van het rantsoeneren van informatie tot wat één persoon in zijn hoofd kan houden.

Overweeg nu servicemanagement.

Ernstniveaus bestaan om te beslissen wie eerst aandacht krijgt. Wachtrijen bestaan om werk te houden dat niemand nog vrij is om te doen. Escalatieladders bestaan omdat deskundigheid schaars en duur is. Change-advisory boards bestaan omdat je niet iedereen alles kunt laten beoordelen. Servicelevelovereenkomsten zijn, in wezen, een belofte over hoe snel een beperkt aantal mensen bij je zal zijn.

Elk van deze is een allocatiemechanisme. IT-servicemanagement, structureel, is de praktijk van het rantsoeneren van menselijke aandacht over meer eisen dan er mensen zijn.

De twee disciplines lossen dus dezelfde beperking op vanuit tegenovergestelde richtingen. Observabiliteit rantsoeneert informatie die naar een persoon gaat. Servicemanagement rantsoeneert aandacht die uit een persoon komt. De persoon in het midden is de reden waarom beide vakgebieden de vorm hebben die ze hebben.

Twee disciplines, één beperking.

Geen van beide disciplines heeft zich ooit zo beschreven, en dat is precies waarom geen van beiden duidelijk kan zien wat ze op het punt staan op te geven.

De industrie heeft besloten dat de beperking verdwenen is

Het argument voor het verwijderen van de mens uit het midden is sterker dan zijn critici toegeven, en ik wil het eerlijk stellen.

Steekproeven zijn echt een compromis dat onder dwang is gesloten. Het gooit data weg die een machine kan gebruiken, om een volume te produceren dat een persoon kan overleven, op een moment dat opslag duur was. Machines hebben geen dashboard nodig. Ze kunnen meer van een systeem in het werkgeheugen houden dan elke ingenieur, en ze worden niet moe om drie uur ‘s nachts. Een wachtwoordreset heeft geen wachtrij nodig. Het heeft een API-aanroep nodig. Als de meeste servicedeskvolume bestaat uit een handvol routineaanvraagtypen, dan is een servicedesk die is gebouwd om die aanvragen te routeren en te triëren een monument voor een probleem dat niet langer op die manier hoeft te worden opgelost.

Alles is waar, en het meeste is over tijd.

Maar hier is de zet die de industrie maakt zonder het te onderzoeken. Naar aanleiding van het feit dat menselijke traagheid beide disciplines heeft gevormd, is geconcludeerd dat alles wat traag is in beide disciplines er was vanwege menselijke traagheid.

Dat volgt niet. Wanneer je een beperking verwijdert die elke ontwerpbeslissing in een vakgebied heeft beïnvloed, kun je niet aannemen dat elke ontwerpbeslissing alleen maar over die beperking ging. Sommige waren over iets anders, en het feit dat ze toevallig traag zijn, is incidenteel.

Niet alles wat traag is, was een flessenhals

Sommige dingen in deze disciplines zijn een flessenhals. Het bestaat alleen omdat een persoon traag is, het produceert niets behalve vertraging, en het moet zonder ceremonie worden verwijderd.

Steekproeven zijn een flessenhals. Handmatige correlatie over drie tools om twee uur ‘s nachts is een flessenhals. Categoriseren van een binnenkomend ticket met de hand is een flessenhals. Routeren naar de juiste wachtrij is een flessenhals. Eerstelijns triage van een wachtwoordreset is een flessenhals. Geen van deze stappen voegt iets toe. Ze zijn belasting.

Maar sommige dingen in deze disciplines zijn een rem, en een rem is een heel ander object.

Ernstniveauclassificatie is geen vertraging. Het is een forcerend mechanisme. Het dwingt een genoemde persoon om op het rapport te verklaren wat hij gelooft dat de bedrijfsimpact van deze gebeurtenis is. De output is niet het label. De output is de toezegging.

Een change-advisory board is niet traag omdat de mensen erin traag zijn. Het is traag omdat overleg het produceert. De vergadering is niet overhead die aan het besluit is gekoppeld. De vergadering is het besluit.

Een postmortem is traag met opzet. Reflectie is geen latentie. Een organisatie die in vier seconden van falen leert, heeft niets geleerd.

Deze zijn remmen. Ze bestaan om opzettelijk wrijving te introduceren, precies op de momenten waarop snelheid niet het gewenste resultaat is.

En van buitenaf zijn een rem en een flessenhals bijna onmogelijk te onderscheiden. Ze zien er hetzelfde uit in een procesdiagram. Ze produceren dezelfde klacht in een enquête. Ze komen allebei tot uiting als een kloof tussen wanneer iets had kunnen gebeuren en wanneer het daadwerkelijk gebeurde.

Ze zien er allebei uit als wachten.

Flessenhals of rem? Beide zien eruit als wachten.

Wat het verwijderen van een rem echt kost

Dit is waar het argument ophoudt een kwestie van smaak te zijn, omdat er nu bewijs is.

Google’s DORA-onderzoek heeft twee jaar gemeten wat er gebeurt met softwarelevering naarmate de adoptie van AI toeneemt. De bevindingen van 2024 schatten dat verhoogde AI-adoptie gepaard ging met een daling van de leveringsstabiliteit van ongeveer zeven procent. Het volgende jaar verbeterde het doorvoerbeeld, maar de negatieve relatie met stabiliteit bleef bestaan. Google’s eigen samenvatting was dat AI de ontwikkeling versnelt en dat versnelling zwakheden stroomafwaarts blootlegt.

Het voor de hand liggende verweer is dat snelheid de schade betaalt. Sneller verzenden, meer breken, sneller repareren, vooruitkomen. DORA heeft dit getest. De onderzoekers controleerden of de doorvoergewinsten van AI de schade van de toegenomen instabiliteit compenseerden, en de gegevens ondersteunden de hypothese niet. De instabiliteit werd niet gecompenseerd door de snelheid. Het werd gewoon elders geabsorbeerd.

Kijk nu naar de scherpste voorspelling in de agente markt. In juni 2025 voorspelde Gartner dat meer dan 40 procent van de agente AI-projecten zou worden geannuleerd tegen het einde van 2027. Het getal wordt overal genoemd, meestal zonder datum, en meestal als een oordeel over de technologie.

Het getal is niet het interessante deel. De oorzaken zijn. Gartner noemde drie: escalerende kosten, onduidelijke bedrijfswaarde en onvoldoende risicobeheersing. Modelcapaciteit staat niet op de lijst. Geen van deze drie mislukkingsmodi zou worden opgelost door een beter model.

Lees dit als een operationsdiagnose en het wordt veel scherper. Gartner beschrijft organisaties die de remmen loslaten.

De oorzaken die Gartner noemde, en de ene die het niet deed.

“Een observatie uit het veld. De ideale vorm is een geval waarin een team een stap automatiseerde die belastbaar bleek te zijn en dat later ontdekte, of een klant die een trage proces tegen advies in handhield en daar terecht toe besloot. Het hoeft niet dramatisch te zijn. Het moet specifiek en waar zijn.” 

De sorteeroefening die niemand uitvoert

Als het argument standhoudt, is de taak van de komende jaren in IT-operaties niet snelheid. Het is sorteren.

Neem elke trage stap in beide disciplines en stel één vraag. Is dit traag omdat een mens traag is, of is het traag omdat oordeel tijd kost?

De eerste categorie moet zonder sentimentaliteit geautomatiseerd worden. Niemand zou handmatige ticketcategorisatie moeten verdedigen op grond van ambacht. Niemand zou sampling moeten verdedigen zodra de economie het niet langer vereist. Deze stappen zijn niet heilig. Ze waren nooit iets anders dan een belasting op schaarste, en de schaarste neemt af.

De tweede categorie heeft iets zorgvuldigers nodig dan verwijdering. Het punt is niet om een persoon in de lus te houden voor de lol, wat meestal de manier is waarop menselijke toezicht verslechtert tot een rubberen stempel. Het punt is om te veranderen wat de persoon wordt gevraagd.

Stop met het vragen om het werk uit te voeren. Begin met het vragen om op het rapport te verklaren. Niet “bekijk deze wijziging”, maar “verklaar wat u gelooft dat de blast radius is”. Niet “triëreer dit incident”, maar “zet uw naam op deze ernstige oproep”. De machine kan het onderzoek doen, het bewijs verzamelen, de actie voorstellen en uitvoeren. Wat het niet kan doen, is verantwoordelijk zijn voor het, en verantwoordelijkheid is geen trage versie van een snelle zaak. Het is een andere zaak.

Het ticket was de rem

Dat brengt me terug naar de begrafenis.

De industrie heeft besloten dat het ticket sterft. Ik denk dat het tegenovergestelde dichter bij de waarheid ligt.

Verwijder alles rond het ticket dat een flessenhals was. Verwijder de routering, de categorisatie, de wachtrij, de ladders, de handmatige triage, het wachten. Alles was een steiger gebouwd rond een trage mens, en alles kan weg.

Wat overblijft, is de enige onvermijdelijke functie van het ticket. Het is het artifact waar een genoemde persoon de verantwoordelijkheid voor een resultaat aanvaardde. Dat is geen workflow-stap. Dat is het verslag van een beslissing, en het is het enige in de hele apparatuur dat niet sneller wordt als de machines sneller worden.

De servicedesk wordt geautomatiseerd. Het dashboard wordt optioneel. De wachtrij verdwijnt. En het ding waar iedereen het meest naar uitkeek om te begraven, blijkt het enige onderdeel te zijn dat nooit over snelheid ging.

Dus de vraag die ik zou stellen aan elk team dat op het punt staat een trage stap uit hun operaties te verwijderen, is eenvoudig. Weet je welk type traag het was?