Når prosessdefinisjonen din er feil

Funnet

Revisjonen leser de registrerte intervallene for hvert steg i organisasjonen. For hvert steg rapporterer den hvor mange intervaller som ble målt, median antall minutter i steget, SLA-timene for det steget, og hvor mange intervaller som varte lenger enn disse timene. Stegene listes opp med de tregeste først, slik at det første funnet er det som betyr mest.

Funnet presenteres i et enkelt språk i forslaget: steget tok så mange minutter i median og ble brutt så mange ganger. Det er ingen poengsum å tolke; hvert tall i setningen er en opptelling eller en median over rader du kan åpne.

Forslaget

For et steg med en SLA går forslaget ut på å flytte disse timene til steget revisjonen navngir. For et steg helt uten SLA er forslaget å måle det før du setter en, fordi et tall som settes uten historikk er akkurat det denne funksjonen er laget for å fange opp.

Forslaget lagres som en forslagsrad, i likhet med en automatisering kompilert fra en setning: beskrevet i et enkelt språk, simulert, og inaktivt til en person godkjenner det. Å generere forslaget koster ingenting og krever ingen modell; det er ren aritmetikk over intervaller.

Simuleringen

Før du bestemmer deg, kjører revisjonen den foreslåtte regelen over de siste 30 dagene og rapporterer hva som ville ha skjedd. Den teller brudd under gjeldende regel og brudd under den foreslåtte, og deler forskjellen inn i tre tall: sanne positive, bruddene begge reglene fanger opp; falske positive, de den foreslåtte regelen ville lagt til; og falske negative, de den ville sluttet å fange opp.

Det er denne setningen planen for denne funksjonen ble bygget rundt: så mange reelle brudd fanget opp i stedet for så mange falske alarmer. Hvis den foreslåtte regelen fanger opp færre reelle problemer enn den fjerner falske, kan du se det før den rører noe som helst.

• Brudd før: under gjeldende SLA.
• Brudd etter: under den foreslåtte plasseringen.
• Sanne positive, falske positive, falske negative: forskjellen, navngitt.

Godkjenning oppdaterer malen, og kun malen

Når du godkjenner, skrives de korrigerte SLA-timene til det navngitte steget i arbeidsflytmalene dine, og oppsummeringen viser hvor mange maler som ble berørt. Fra det øyeblikket starter hvert nye prosjekt av den typen med de korrigerte timene. Ingenting på en tavle i drift endres, og oppsummeringen sier dette eksplisitt.

Dette er den sikre, reversible halvdelen. En redigering av en mal påvirker prosjekter som ikke eksisterer ennå; den kan ikke føre til at en oppgave som var i rute i går, plutselig har brutt fristen i dag.

Tavler i drift, én etter én, revidert

Etter godkjenning viser gjennomgangsskjermen de aktive prosjektene der det gjeldende steget fortsatt har de gamle timene, med prosjektnavn, nåværende og foreslåtte timer, samt antall åpne oppgaver på det steget. Du velger hvilke som skal oppdateres. Å oppdatere ett prosjekt oppdaterer prosjektets steg og oppretter én revisjonshendelse; å ikke oppdatere noen er et gyldig valg.

Skriving til et aktivt steg is begrenset: det endrer SLA-timer, navn, farge eller roller, og nekter å endre et stegs nøkkel eller type mens det er oppgaver på det, fordi det å endre et stegs type under en oppgave endrer om det kreves en godkjenning.

Historikken blir ikke omskrevet. Hvert registrerte intervall beholder SLA-timene som var gjeldende da det ble opprettet, så en revisjonskjøring neste måned vil fortsatt rapportere forrige måned under forrige måneds regel.

Hvorfor det ikke skjer automatisk overalt

Den mest åpenbare løsningen ville vært ett klikk som fikser malen og alle tavler i drift. Men det blir feil, og beslutningsloggen for denne funksjonen forklarer hvorfor: Å endre en SLA på en aktiv tavle omdefinerer det produktet allerede har fastslått. En oppgave som var innenfor sine 48 timer blir plutselig markert med brudd, en eskalering som aldri ble utløst ser ut som om den burde ha blitt det, og en kunde som fikk beskjed om at prosjektet var i rute, har fått informasjon som produktet nå motsier.

Derfor gjøres utrullingen gradvis, og den er valgfri per prosjekt, med en egen revisjonsrad for hvert. En organisasjon som ønsker at tavlene i drift automatisk skal holdes i tråd med malen, kan ikke få dette som en innstilling, og denne begrensningen er bevisst.