Wanneer je procesdefinitie niet klopt

De bevinding

De audit leest de geregistreerde intervallen van elke fase in de organisatie. Voor elke fase rapporteert deze hoeveel intervallen er zijn gemeten, het mediaan aantal minuten in de fase, de SLA-uren voor die fase en hoeveel intervallen langer duurden dan die uren. Fases worden gesorteerd van langzaam naar snel, dus de eerste bevinding is de belangrijkste.

De bevinding wordt in duidelijke taal in het voorstel vermeld: de fase nam mediaan dit aantal minuten in beslag en werd zo vaak overschreden. Er is geen score om te interpreteren; elk getal in de zin is een telling of een mediaan van rijen die je kunt openen.

Het voorstel

Voor een fase met een SLA is het voorstel om die uren te verplaatsen naar de fase die de audit noemt. Voor een fase zonder SLA is het voorstel om deze eerst te meten voordat er een wordt ingesteld, want een getal dat zonder historie wordt bepaald, is precies wat deze functie probeert te voorkomen.

Het voorstel wordt opgeslagen als een voorstelrij, net als een automatisering die is opgebouwd uit een zin: beschreven in duidelijke taal, gesimuleerd en inactief totdat iemand het goedkeurt. Het genereren van het voorstel kost niets en roept geen model aan; het is puur rekenwerk over intervallen.

De simulatie

Voordat je beslist, voert de audit de voorgestelde regel uit over de afgelopen 30 dagen en rapporteert wat er gebeurd zou zijn. Het telt de overschrijdingen onder de huidige regel en de overschrijdingen onder de voorgestelde regel, en verdeelt het verschil in drie getallen: true positives (de overschrijdingen die beide regels detecteren), false positives (de overschrijdingen die de voorgestelde regel zou toevoegen) en false negatives (de overschrijdingen die niet langer gedetecteerd zouden worden).

Dat is de zin waar het pakket voor deze functie omheen is geschreven: zo veel echte overschrijdingen gedetecteerd in plaats van zo veel vals alarm. Als de voorgestelde regel minder echte problemen detecteert dan het aantal valse meldingen dat ermee wordt voorkomen, zie je dat al voordat er iets wordt aangepast.

• Overschrijdingen vooraf: onder de huidige SLA.
• Overschrijdingen achteraf: onder de voorgestelde plaatsing.
• True positives, false positives, false negatives: het verschil, benoemd.

Goedkeuring past de template aan, en uitsluitend de template

Wanneer je goedkeuring geeft, worden de gecorrigeerde SLA-uren weggeschreven naar de betreffende fase in je workflowtemplates, en de samenvatting geeft aan hoeveel templates zijn aangepast. Vanaf dat moment start elk nieuw project van dat type met de gecorrigeerde uren. Er verandert niets op een actief bord, en dat wordt expliciet vermeld in de samenvatting.

Dit is het veilige, omkeerbare deel. Een bewerking van een template heeft alleen invloed op projecten die nog niet bestaan; het kan er niet voor zorgen dat een taak die gisteren op tijd was, vandaag plotseling is overschreden.

Actieve borden, één voor één gecontroleerd

Na goedkeuring toont het reviewscherm de actieve projecten waarvan de live-fase nog de oude uren heeft, inclusief de projectnaam, de huidige en voorgestelde uren, en het aantal openstaande taken in die fase. Je kies zelf welke je wilt bijwerken. Het bijwerken van een project past de fase van dat project aan en registreert één auditevent; niets bijwerken is ook een prima optie.

De wijziging van een live-fase is beperkt: deze past de SLA-uren, naam, kleur of rollen aan, maar weigert de sleutel of het type van een fase te wijzigen zolang er taken in staan. Het veranderen van het fasetype terwijl er een taak in staat, heeft namelijk invloed op de vraag of er een goedkeuring vereist is.

De geschiedenis wordt niet met terugwerkende kracht aangepast. Elk geregistreerd interval behoudt de SLA-uren die golden op het moment dat het interval startte, zodat een audit volgende maand de gegevens van de afgelopen maand nog steeds rapporteert volgens de toen geldende regels.

Waarom dit niet overal automatisch gebeurt

Het meest voor de hand liggende ontwerp is één klik die de template en elk actief bord herstelt. Dat is echter onjuist, en het besluitvormingsdocument voor deze functie legt uit waarom: het wijzigen van een SLA op een actief bord heretiketteert wat het product al heeft gecommuniceerd. Een taak die binnen de 48 uur viel, is plotseling overschreden, een escalatie die nooit is geactiveerd lijkt achteraf wel nodig te zijn geweest, en een klant die te horen kreeg dat het project op schema lag, krijgt nu tegenstrijdige informatie van het product.

Daarom is de uitrol optioneel, per project, met een eigen auditregel voor elk project. Een organisatie die wil dat haar actieve borden automatisch synchroon lopen met de template kan dit niet als instelling inschakelen, en die beperking is een bewuste keuze.