Slik ser et strukturert system for feilmeldinger ut for forretningsførere

En sak er en enkel registrering. Den er også den viktigste byggesteinen i moderne driftsarbeid, fra kundeservice i et flyselskap til avvikshåndtering på et sykehus og vedlikehold av en bygning.

Denne artikkelen forklarer hva en sak er (i et sameie eller borettslag: en feilmelding), hva som gjør systemet rundt sakene nyttig, og hva som endrer seg når du flytter forvaltningen over på et slikt system.

En sak er bare en registrering med fire egenskaper

Skrell bort sjargongen, og en sak er en oppgave med fire opplysninger knyttet til seg:

1. En identifikator, vanligvis et nummer som #0042. Så du kan vise til den uten at det kan misforstås.
2. En status, hvor i arbeidsflyten den er. Ny, Pågår, Venter på bekreftelse, Løst.
3. En ansvarlig, personen som akkurat nå skal ta den videre.
4. En historikk, hver endring noen har gjort, med dato og klokkeslett.

Det er alt. Alt annet (kategorier, prioriteter, vedlegg, kommentarer) er valgfri pynt. De fire egenskapene over gjør en klage til en oppgave som blir fulgt opp, i stedet for en glemt melding.

Sammenlign med en melding i Messenger. En melding har innhold. Det er alt. Den har ingen identifikator (bortsett fra hvor den ligger i chatten), ingen status, ingen ansvarlig og ingen historikk. Derfor kan du ikke drive en arbeidsflyt oppå den.

Hvorfor hver av de fire egenskapene betyr noe

Identifikator

Når to personer snakker om en feilmelding, må de vite at de snakker om den samme. I en Messenger-gruppe gjør du det ved å sitere: «det med heisen i går» eller «lekkasjen i H0402 som rørleggeren sa var pakningen». Så snart du har mer enn fem åpne feilmeldinger samtidig, blir det uklart.

Et saksnummer (#0042, #0089) løser det for godt. Enhver beboer, forretningsfører eller håndverker kan vise til en feilmelding med nummeret, uten tvil. Det høres ut som en bagatell. Det fjerner rundt 15 prosent av all forvirringen i en typisk arbeidsflyt for forvaltning.

Status

Statusen gjør en fri samtale om til en tilstandsmaskin:

Beboeren trenger ikke å spørre «noe nytt?». Beboeren ser statusen. Forretningsføreren trenger ikke å huske hvilke feilmeldinger som står stille i påvente av rørleggeren. Forretningsføreren filtrerer på status. Og den som leder selskapet, trenger ikke å lese 200 meldinger for å vite hvor mange feilmeldinger som er åpne denne måneden. Tallet står der.

Statusen er også der automatiseringen bor. Når statusen endres, skjer det ting: varsler sendes, beboerne får beskjed, håndverkere blir tildelt. I en Messenger-gruppe er det umulig, fordi chatten ikke vet hva en status er.

Ansvarlig

Hver feilmelding har, i hvert øyeblikk av livsløpet sitt, nøyaktig én person som er ansvarlig for å ta den videre. Når beboeren melder fra, er den ansvarlige forretningsføreren for bygningen (eller en håndverker den er sendt direkte til). Når forretningsføreren tildeler den til en håndverker, blir håndverkeren ansvarlig. Når håndverkeren melder at jobben er gjort, blir beboeren ansvarlig, og må bekrefte eller gjenåpne.

Det er denne ene funksjonen som bryter «noen andre tar det»-mønsteret i en Messenger-gruppe, der alle ser feilmeldingen og ingen tar seg av den.

Historikk

En fullstendig logg over hver statusendring, hver tildeling og hver kommentar. Den er avgjørende av tre grunner:

1. Ansvarlighet. Når årsmøtesesongen kommer, kan du legge fram en presis tidslinje for hvordan hver feilmelding ble fulgt opp.
2. Å se mønstre. Etter et halvt år oppdager du at 40 prosent av VVS-feilmeldingene dine kommer fra det samme borettslaget: et tegn på at rørfornying bør opp som sak på neste generalforsamling.
3. Opplæring. Når en ny forretningsfører begynner hos dere, kan vedkommende bla tilbake i historikken for en hvilken som helst bygning og forstå hva som foregår.

Hva «systemet rundt sakene» tilfører

En sak alene er en registrering. Et system for feilmeldinger legger arbeidsflyten rundt den:

• Fordeling. Når en feilmelding opprettes, hvem går den til? De fleste systemer bruker regler: «kategori = VVS → tildel rørlegger X». Forretningsføreren trenger ikke å bestemme.
• Varsler. Når statusen endres, hvem får beskjed? Den ansvarlige, den som meldte fra, og noen ganger en som følger saken.
• Filtrering. «Vis alle nye feilmeldinger i Thereses gate 14, ikke tildelt, eldre enn 24 timer.» To klikk.
• Handlinger på mange samtidig. «Lukk de 30 feilmeldingene som har ventet på bekreftelse i mer enn to uker.» Én handling.

Ingenting av dette finnes i en arbeidsflyt bygd på Messenger. Det finnes ingen måte å «filtrere alle åpne feilmeldinger i fire sameier» i Messenger, fordi ingenting i Messenger vet hva en «åpen feilmelding» er.

Den minste arbeidsflyten for feilmeldinger som fungerer i en bygning

Du trenger ikke en bedriftsplattform med 200 funksjoner. Den minste nyttige arbeidsflyten for feilmeldinger i forvaltningen har:

• Tittel + beskrivelse + valgfri kategori + valgfritt bilde. Selve meldingen.
• Et statusfelt med høyst 5 verdier. Ny, Pågår, Venter på bekreftelse, Løst, Gjenåpnet. Alt utover det er å gjøre det for komplisert.
• Tildeling til én av tre roller. Forretningsfører, håndverker, beboer.
• Pushvarsler ved tildeling og statusendring. Så ingen trenger å åpne appen for å få vite at noe har skjedd.
• Skille per bygning. Hver feilmelding hører til en bygning, og hver bruker ser bare bygningene vedkommende er med i.

Det er hele kjernen. Hvis et verktøy gir deg dette, med et grensesnitt beboerne kan bruke uten opplæring, har du det du trenger.

Innvendingene som alltid dukker opp

«Beboerne våre kommer aldri til å bruke dette.»

Rundt 70 prosent gjør det. De andre 30 prosentene skriver til en nabo som bruker det, og naboen legger inn feilmeldingen. Du trenger ikke at 100 prosent av beboerne er med for å få gevinsten i driften. Du trenger nok til at innboksen for feilmeldinger blir den ene sannheten.

«Vi prøvde dette med e-post, og det fungerte ikke.»

E-post er ikke et system for feilmeldinger. E-post har ingen status, ingen felles innboks, ingen tildeling, ingen filtre og ingen fordeling. Å behandle e-post som et system for feilmeldinger slår feil, fordi e-post ikke er det.

«Vi har allerede et Excel-ark for dette.»

Et Excel-ark ligner mer på et system for feilmeldinger enn en Messenger-gruppe gjør. Det har identifikatorer og en slags statuskolonne. Men det har fortsatt ingen varsler, ikke noe samarbeid i sanntid, ingenting beboerne kan se, og ingen automatisering. Det er en logg over arbeidet. Det er ikke en arbeidsflyt.

Endringen i tankesett

Det vanskeligste med å gå over til et system for feilmeldinger er den mentale overgangen fra «systemet er meg» til «systemet er systemet, og jeg holder oppsyn med det». Forretningsførere som tar det inn over seg, vokser langt forbi porteføljen de hadde. De som ikke gjør det, fortsetter å være et menneskelig sentralbord til de blir utbrent.

Den første uken føles rar, fordi du ikke svarer på meldinger hele tiden. Så innser du at sameiene går sin gang uten at du griper inn i sanntid, og grunnen er at arbeidsflyten selv gjør jobben som før lå i hodet ditt.