Løsningen på store forretningsproblemer er nogen gange så enkel, at ingen siger det højt af frygt for at fremstå som om, de ikke forstår problemet. 

At samle alle informationer et sted for en kort periode er den mest effektive måde at løse problemer på. 

Etablér et problemanker

Smid anker – stop op – få det løst. Nøglen er at samle alle klager, data og fakta ét sted. Man kunne kalde det problem-ankeret. Det skal være et sted, der analyserer og finder ind til kerneårsagen af hver enkelt klage. Det virker vanskeligt i langt de fleste organisationsdesign, fordi klagerne vil have forskellig kompleksitet og dermed reelt høre til i forskellige lag af organisationen. Derfor stiller det ret store krav til stedets kompetencer, som både skal kunne tænke visionært og være operationel. Så store at mange organisationer overser denne meget enkle problemløsningsteknik.

Der er to klare fordele ved at kanalisere alle fakta om problemet til et sted. For det første bliver kommunikationsopgaven til organisationen lettere. Det eneste, der skal siges, er, at problemet nu behandles, og at der er ét – og kun ét – sted alle klager, observation og data skal sendes til. For det andet kan hvert medlem af organisationen, som påvirkes af problemet, nu bidrage til dets løsning på en let og hurtig måde. De, der bare lader sig irritere, men ikke har tid til at bidrage til løsning, kan blot videresende deres irritation. De, der har ideer og input, og gerne vil bidrage med det, kan gøre det. Der er ingen formkrav – blot en klarhed om at alt – stort som småt – sendes ét sted hen i en afgrænset periode.    

Opret evt. en særskilt mailadresse, som organisation kan bruge til alle problemer og dediker én person til at holde øje med de input, der kommer. Efter ganske få uger vil den rette person kunne se mønstre i data. 

Det kan være én person, der for en kort periode ser alt. Det kan være en mailadresse, der skal bruges til alt, men som tømmes af få personer, der koordinerer tæt. Det kan også være fotos, der samles ét sted. F.eks. i det fysiske kontorrum, hvor der ofte blev klaget over rengøringskvaliteten. Det kan være en fysisk kasse eller en virtuel mappe (Google Docs, Dropbox eller lignende). I en virksomhed af anseelig størrelse var det på ingen måde muligt at lade én person håndtere alt i problemafklaringsperioden. Her valgt man at nedsætte et team af forskellige kompetencer. En person fik opgaven at holde øje med mailboksen og håndtere alt, der krævede her og nu opmærksomhed. Hele teamet mødtes to gang om dagen i en uge og håndterede fra en ende af de ting, der var kommet ind.  

Sådan blev implementeringen af et større IT projekt, som skiftede alt software, håndteret. Efter systemet var gået i luften, var der masser af klager. For det første fik alle at vide, at der ikke ville blive samlet forbedringsforslag ind de første tre måneder, kun driftskritiske problemer ville blive håndteret. Det betød, at alle forandringer, som alene blev kritiseret, fordi de var det – en forandring - forsvandt. Efter tre måneder anvendte man ”et sted – en person – en uge”-modellen til at indsamle klager. Det gav fuldstændig ro overfor organisationen i alle de kritiske måneder efter systemforandringen.   

Find det rigtige sted

Hvis denne meget enkle problemløsningsmetode ikke anvendes, er det oftest fordi, virksomheder har svært ved at finde den rigtige person. Det skal nemlig være en person, der kan skelne vigtigt fra mindre vigtigt og haster fra ikke-haster. Og det skal være en person med et godt overblik over hele organisationen og de eksterne ressourcer, man også trækker på. Derfor vil det typisk være en person, der er højt placeret i organisationen. Men samtidig skal det være en person, der ikke føler sig hævet over detaljer, sådan som nogle højt placerede ledere desværre gør. Mange af de klager, der kommer i perioden, kan være hastesager, som skal løses med det samme, og det må den valgte person ikke føle sig hævet over. Personen skal kunne analysere, dvs. bearbejde og tolke data. Endelig skal personen have tid i dén periode, der er tale om. En rigtig sweitzerkniv.

Har man vanskeligt ved at finde en person med alle disse kendetegn, kan man vælge at sammensætte et team, sådan som den store virksomhed gjorde. Overvej, om der skal en ekstern proceskonsulent med i gruppen, men husk at arbejde ud fra virksomhedens egne data.

Problem-ankerets vigtigste opgave er at analysere. Der vil hurtigt danne sig nogle overskrifter på særlige typer af problemer for den dygtige analytiker. Problemer, der forhindrer drift her og nu, skal løses med det samme. Der er mange måder at kategorisere på. Eksempler er Årsags/virkningsdiagrammer (fiskeben) der grupperer i Mennesker, Metoder, Maskiner, Materialer og Måling (Kaoru Ishikawa (1968)) eller haster/vigtigt (Eisenhower eller bedst kendt fra Covey,1989)

Giv ikke mere end en uge

Allerede efter den første uge, skal de første løsninger identificeres. Meningen er ikke at implementere disse, men at skabe hypoteser, som næste uges dataindsamling skal være med til at be- eller afkræfte. Husk kun at lave én ændring ad gangen og at undersøge snarest muligt, om det havde den forventede effekt. Hvis du laver flere forbedringer, vil du ikke være i stand til at sige, hvad der løste problemet og dermed hvad der skal skaleres og udbredes.

Eksperimenter for at finde ind til problemets kerne

Tænk på et enkelt problem – printeren udskiver ikke hver gang. Prøv at tænde og slukke strømmen til enheden. Afinstallér og geninstaller på PC. Print fra en anden enhed. Hvis det er en kopimaskine, så tjek om den kan lave en kopi. Bag hver af disse handlinger ligger en hypotese om, hvad der kan være galt. Og for hver handling samles vigtig ny viden, som efterhånden indsnævrer problemet. Bliv ved med at justere og ændre på små ting, indtil fejlen er fundet. I dette eksempel var det et bestemt program, som medarbejderne downloadede, som satte printerne ud af drift. Og når det står klart, hvad der er kerneårsag til problemet, kommer det næste store spørgsmål. Kan det ske igen? Ja, når som helst kan en anden medarbejder hente programmet. Hvis det kan, må det indarbejdes i de daglige rutiner eller månedlige kontroller, at håndtere dette. Ved dette konkrete simple eksempel var der flere løsninger, og det er kulturen og virksomhedens art, der definerer, hvad der er den rigtige. Lige fra total forbud mod at downloade software, til træning i hvad man siger ja og nej til, når software hentes. I denne konkrete virksomhed blev det indarbejdet i den elektroniske IT helpdesk at spørge ”Har du software X installeret på din PC” og hvis svaret var Ja – ”afinstaller det og geninstaller med disse optioner”. Pointen i dette eksempel er at løse problemer ved at prøve sig frem. Det er en metode, som virker i mange sammenhænge.

Skab hurtigt de første løsningshypoteser

Efter en uge skal al dataindsamling være fokuseret på at kvalificere løsningshypoteser. Så hurtigt som muligt skal man nå frem til de mere gennemgribende løsninger, der skal implementeres.      

Det første svar vil næsten altid være kompetenceudvikling. Via kurser, videoer, instruksplakater mv. kan håndtering af de enkleste fejl klares. Jo mere den enkelte kan løse selv, jo bedre er det. Selve implementeringen fra design til ændret adfærd kan være lang og lykkes kun, hvis den understøttes ledelsesmæssigt.   

Næste greb er organisering. Driftskritiske fejl skal klares med det samme, de opstår, og her kan en helpdesk eller en hel afdeling være løsningen. Sådan bliver en controllerafdeling til, en salgsafdeling, en dataafdeling etc. Pas dog på, at denne afdeling ikke begynder at leve på egne præmisser. Alt for mange stabe er blevet alt for store ad den vej. Under organisering kan også være at lægge ansvaret for denne proces hos ét bestemt medlem i ledergruppen. Eller lave et tværgående udvalg, der mødes jævnligt udelukkende for at tage strategiske skridt på dette område, der indtil nu har været så stort et problem.   

Ofte opdager man, at der er fejl, der forekommer, men ikke hver gang. Til denne type kan det give mening at indføre jævnlige kontroller hos én person eller én enhed, som har kompetence til at rette det. I en virksomhed har den månedlige rapport nogen gange, men langt fra altid, indeholdt fejl. Der blev derfor taget stikprøver hver måned.  Man undgik et totalt redesign af rapporten, men man opnåede samtidig fuld tillid til dens indhold.

Der vil også være fejl, som er vanskeligt at få hold på. De kræver mere data. Det kan være nødvendigt at bede alle personer i en afdeling udfylde et ølkasseregnskab hver dag i en periode, dvs. på et papir notere, hvor mange gange en bestemt begivenhed har indtruffet. Herefter kan man estimere på konsekvensen for kunder og på omkostninger og beregne effekt og i hvilken grad, det betaler sig at løse den.

Igen kan løsning være kompetenceudvikling, disciplin, opfølgning eller helt nye processer. Overvej det i dén rækkefølge. Problemer løses næsten altid bedst med adfærd før systemer.

Husk at ingen mennesker går på arbejde for at skabe dårlige resultater. Processer er opstået af en grund, og selv om de måske kan blive mere LEAN på et papir, kan der være et ejerskab, der går tabt ved at gøre det.