Systemen bewaken op beschikbaarheid en snelheid, en afwijkingen signaleren voordat gebruikers er last van hebben, is een taak die grotendeels is over te nemen. Niet omdat AI ineens verstand heeft van infrastructuur, maar omdat de taak zelf al jaren is opgebouwd rond meetwaarden, drempels en herhaling. Dat is een andere conclusie dan bij taken waar oordeel of onderhandeling de kern vormen.
Drie assen geven hier de doorslag: volume, gestructureerdheid en foutkosten.
Het volume is hoog. Monitoring loopt continu, dag en nacht, over honderden of duizenden meetpunten. Een mens die dat handmatig zou bijhouden, kijkt met tussenpozen naar dashboards en mist wat daartussen gebeurt. Een systeem dat elke seconde meet en vergelijkt met een drempelwaarde, mist dat niet.
De gestructureerdheid is hoog. De taak bestaat uit: meten, vergelijken met een norm, en bij afwijking een signaal afgeven. Dat is een vaste procedure, geen open vraagstuk. Vergelijk dat met het beantwoorden van een gebruikersvraag over software, waar de vraag elke keer anders geformuleerd is en context nodig heeft.
De foutkosten zijn laag tot gemiddeld. Een gemiste of te late melding is vervelend, maar meestal herstelbaar: het systeem stuurt een nieuwe waarschuwing zodra de afwijking aanhoudt, en de meeste drempelwaarden zijn met marge ingesteld. Dat is anders dan bij een taak waar één gemiste stap direct een gebruiker zonder werkende applicatie oplevert, zoals bij het oplossen van een eerstelijns IT-incident.
Twee assen remmen het beeld af: oordeelsruimte en creativiteit staan op respectievelijk 2 en 1.
Het signaleren van een afwijking is iets anders dan begrijpen wat die afwijking betekent voor de organisatie. Een piek in geheugengebruik kan onschuldig zijn, of het begin van een probleem dat over twee uur de webshop platlegt. Het bepalen van die betekenis, en het besluit om op te schalen naar een engineer die ingrijpt, blijft mensenwerk. AI signaleert de afwijking; een persoon met kennis van de omgeving beoordeelt wat die afwijking waard is.
Dat is meteen ook waarom deze taak niet op zichzelf staat. Het signaal dat een monitoringtool afgeeft, moet ergens landen: als geregistreerd incident met de juiste urgentie. Hoe dat verder gaat, staat beschreven bij IT-incidenten registreren en prioriteren, een taak die net iets minder is dichtgetimmerd dan het monitoren zelf.
De inschatting is: een agent. Geen los script dat één drempelwaarde controleert, maar een systeem dat continu meet, meerdere signalen combineert, en zelf bepaalt of een patroon een melding waard is voordat een mens het ziet. Dat is een stap verder dan alleen alerting, en een stap terug van volledige autonomie: de agent signaleert en categoriseert, een beheerder besluit wat er met het signaal gebeurt.
Twee randvoorwaarden bepalen of dat werkt. Er moeten ingerichte drempelwaarden zijn, afgestemd op wat normaal is voor die specifieke systemen: een drempel die voor de ene applicatie streng genoeg is, kan voor een andere constant vals alarm slaan. En er moet geautomatiseerde alerting staan die het signaal ook daadwerkelijk bij iemand aflevert. Zonder die twee is er niets om over te nemen: geen norm om aan te toetsen, geen kanaal om het door te geven.
Bij een bedrijf met een paar servers en een vaste kantoortijd is monitoring vaak nog een kwestie van af en toe kijken. De volumewinst van automatisering is er dan beperkt, simpelweg omdat het volume laag is. Bij een bedrijf met veel systemen, klanten die op elk moment van de dag toegang verwachten, en een historie van incidenten die 's nachts zijn ontstaan, is het beeld anders: daar loopt de fte-capaciteit die vrijkomt met continue geautomatiseerde bewaking snel op, omdat het alternatief een mens is die permanent stand-by moet staan.
Ook de foutkosten-as verschuift per bedrijf. Bij een interne testomgeving is een gemiste melding zonder gevolgen. Bij een systeem dat direct aan betalingsverkeer of aan medische gegevens raakt, ligt de compliance-lat hoger, en dat duwt de as compliance, die hier al op 4 staat, nog verder in de richting van verplichte vastlegging en aantoonbare opvolging.
Dit is geen uitspraak over personeel. Of en hoe een organisatie de vrijgekomen capaciteit van een systeembeheerder anders inzet, is een keuze van de werkgever, met eigen wettelijke vereisten waar dat aan besluiten over functies raakt. Deze pagina beschrijft alleen het werk, niet de mensen die het nu doen.
Monitoring is zelden een geïsoleerde taak. Ze hangt samen met back-ups uitvoeren en controleren, met incidentafhandeling, en met de planning van wie wanneer beschikbaar moet zijn voor opvolging. Wie een breder beeld wil van wat AI in de IT-functie als geheel kan overnemen, vindt een vertrekpunt op de pagina over werk en planning.
Deze pagina geeft een inschatting op basis van de taak in algemene vorm. Hoeveel dat in een specifiek bedrijf betekent, hangt af van het aantal systemen, de ingerichte drempelwaarden en de gevolgen van een gemiste melding. Een indicatie voor de eigen situatie is te krijgen met de gratis quickscan: twaalf vragen, zonder account, met een indicatie welk deel van de uren in dit profiel vandaag door AI is over te nemen. De volledige werkscan, die het werk van een heel bedrijf in taken uiteenlegt, is nog in aanbouw.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.