… og det er løgn!

Titlen dækker over et citat jeg hørte for kort tid siden. Blodtrykket steg og det krævede stor viljestyrke hos undertegnede at finde en passende grimmase og tilhørende svar. Citatet stammede ikke engang fra en IT-udvikler; ærlig talt kom det fra en person der slet ikke har tilknytning til IT-udvikling. For at være helt møjsommelig: Sætningen blev sagt af en håndværker og blev udbrudt da jeg ville forklare min arbejdsfunktion på helt almindelig dansk.

Definition

”En proces er et forløb, hvor noget sker.” – Wikipedia

Ud fra ovenstående definition, så er det svært at argumentere for at man ikke følger en proces. En minimal proces kunne være:

1. Opgave modtaget (Todo)
2. Opgave udføres (Doing)
3. Opgave afleveret (Done)

Alt efter kontekst kan ovenstående proces være tilstrækkelig, for omfattende eller for uspecificeret. Det essentielle er dog at anerkende at der er en proces.

Den opmærksomme læser har gennemskuet at de 3 nævnte procestrin kan mappes direkte over i et Scrum Board der typisk arbejder med opdeling i Todo, Doing og Done.

Problem

Mange har en målsætning om at der skal ske kontinuerte forbedringer i organisationen, men det er svært at forbedre en proces hvis man ikke anerkender man følger en.

“You cannot fix a problem that you refuse to acknowledge.” – Margaret Heffernan

Løsning

Jeg har ad flere omgange faciliteret både value-stream workshops samt opbygning af Kanban boards for teams der i udgangspunktet enten ikke anerkender at de anvender en proces – og hvis de gør; så er det bestemt ikke samme proces. Disse seancer giver ofte deltagerne en ”aha” oplevelse i det der skabes fælles forståelse for den måde der arbejdes med opgaver – og der dannes et overordnet procesrammeværk som kan bruges når der skal findes flaskehalse i det daglige.

Der kan være et hav af rationaler bag det at erkende og betro sig til en fælles proces. Dem jeg møder tiest og som jeg synes giver mest værdi er:

• Fælles overblik og forståelse over proces i et team
• Mere synlighed omkring hvilke arbejdsgange i en proces der skaber flaskehalse
• Mulighed for prioritering af opgaver og arbejdsgange
• Klarhed over hvilke arbejdsgange i en proces der kræver ekstern involvering (f.eks. beslutning fra ledelse eller materiale fra kunde/leverandør)

For at det hele ikke forbliver rosenrødt, vil jeg gerne advare mod anvendelse af følgende rationaler:

• Måling af individuel performance
• Tvinge en standard proces ind i et team
• Arbejdsdeling på tværs af kompetencer

For at vende tilbage til min håndværker fra indledningen: Senere på aftenen talte jeg med ham om hvordan jeg så en proces og hvorfor jeg mente at netop han også anvendte processer i hans virksomhed. Jeg brugte mine bedste spørgeteknikker for at høre nærmere om hvad der skete fra ”kunde henvender sig” til ”arbejde udført hos kunde”. Efter lidt smalltalk fik jeg reduceret det til at de faktisk følger en meget stringent og slavisk proces der primært drives fra deres regnskabsprogram:

1. Tal med kunde om opgave, lav evt. opmåling
2. Indhent priser på materiale og beregn ca. timeforbrug
3. Send tilbud til kunde
4. Afvent accept af tilbud
5. Bestil materiale
6. Afvent materiale
7. Udfør arbejde
8. Send faktura til kunde
9. Afvent betaling

Udover ovenstående proces i forbindelse med håndtering af de kundevendte funktioner, så viste det sig at han rent faktisk også havde en daglig planlægningsproces for kortlægning af hvilke arbejdsopgaver hans medarbejdere skulle udføre på hvilke tidspunkter, der var en proces for udskiftning af firmabiler og sidst men ikke mindst – en proces for rotation af indkøb af rundstykker og kage til morgenbordet.