Løsninger på store forretningsmæssige problemer kan identificeres på få uger

IT systemer der driller. Procedurer der ikke bliver fulgt. Opfølgning der ikke sker. Det er eksempler på problemer, som rigtig mange virksomheder har.    

Ofte bliver problemet italesat over frokostbord eller til nærmeste leder, og det er slet ikke ualmindeligt, at der bliver talt så meget om det, at problemet ender med at blive større, end det egentligt er. Der er desværre mange eksempler på, at problemer vokser ud af proportioner og kommer til at styre mellemlederens dagsorden. Pointen er, at inden det når de rette ører, er det blandet med så meget frustration, at det bliver vanskeligt at se klart.

 

Sådan gik det f.eks. på en skole, hvor der konstant var problemer med IT. Det havde stået på så længe, at det blev brugt som årsagsforklaring på alle problemer. Til sidst søgte ledelsen penge til et IT-projekt, der skulle forny alt hardware. Men inden projektet blev bevilliget, blev den metode, der beskrives her nedenfor, anvendt til problemløsning. Det viste sig, at problemet var adfærd. Efter brug blev hardware ikke lukket rigtigt ned. Derfor oplevede den næste bruger problemer. Problemer blev løst gennem instruktion, og på nogle enheder ved at installere software, som sikrede ordentlig lukning. Til en fraktion af økonomien - for ikke at nævne tiden - til det oprindelige projekt.

I en større virksomhed var det ERP-systemet, der over tiden var blevet kilden til alle problemer. Også her viste det sig, at systemet var godt nok, men lappet sammen af en række overflødige ekstrafunktioner som velmenende folk havde tilsat, men som kun blev efterspurgt ganske få gange.    

 

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å. 

Mottoet er: Ét sted, én person, én uge.

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.

For små og for store

En mindre virksomhed havde vanskeligt ved at holde overblik over de regninger, der skulle betales. Langt det meste kørte helt automatisk, men der var regninger, som skulle hentes i e-boks og betales via netbank. Det var forstyrrende, at skulle forholde sig til, når det kom, og det var også forstyrrende at gå og spekulere på, om der var hængepartier. Løsning blev at lave tidsslot: at dedikere to timer om ugen til at tømme mail, e-boks mv. og en dag i kvartalet til løn og moms. Resten af tiden var til kunder og levering. Når der kom en mail, blev det med det samme vurderet, om det var kunderelateret. Var det ikke det, fik mailen et flag og blev behandlet på det kommende tidsslot. For at servicere samarbejdspartnere bedst muligt blev der udviklet en standardmail, der sagde: "Tak for din mail. Jeg er hos kunder, men læser din mail på torsdag, hvorefter jeg vender tilbage."

På disse dage havde ejeren af virksomheden en tjekliste med ting, han skulle igennem. Hver gang han stod overfor en udfordring, tænkte han på, hvordan han kunne imødegå dette indenfor sine ugentlige administrationstimer. Tjeklisten blev længere og længere, og til sidst blev to timer til tre. Men det var stadig ingenting ift. de mange forstyrrelser, han oplevede før. Da tjeklisten blev til en halv dag, ansatte han en person til at løse opgaverne. Han holdt fast i tjeklisten og den blev omdrejningspunktet for kvartalsvise samtaler med medarbejderen. En af opgaverne på listen var i øvrigt "unsubscribe" fra irrelevante newsletters.

I en stor virksomhed oplevede man omfattende problemer i anvendelse af CRM-systemet. Der var ikke økonomi og overskud til at skifte det. I stedet valgte man at etablere en helpdesk, bemandet af teknikere, til opgaver af den type, der forhindrede sælgerens videre arbejde her og nu. Man lavede også en enkelt rapportskabelon og ansatte studentermedhjælpere til at lave data til sælgernes planlagte møder. Efter en tid målte man på, hvad der blev brugt. Det viste sig, at CRM-systemet blot havde for mange valg. Det blev reduceret og systemet anvendt flittigt og uden brok derefter. Helpdesken blev nedlagt og kun en enkelt studentermedhjælper blev tilbage.   

Ofte stillede spørgsmål om metoden:

et sted - en person - en uge

Der er ikke kommet data nok ind på en uge

Måske er problemet i virkeligheden ikke så stort, som man får indtryk af, når man lægger øre til vandrørene. Giv det en uge mere, og er der fortsat ikke kommet meget data, har virksomheden det perfekte grundlag for kommunikation fra ledelsen om dette tema.

Konklusionen blev, at vi skal have nyt IT på salgssiden

Det er et stort projekt. Sørg for, at det har ledelsens bevågenhed hele vejen, og prøv at holde det så enkelt som muligt. Tænk stort, start småt og skaler hurtigt. Dokumentér de typer af klager, der er kommet i den problemafklaringsproces, der ledte op til konklusionen. En dygtig IT partner vil kunne finde meget forståelse for forretningen i dette.

Der er gået to uger, og vi kan ikke finde hoved og hale i de indmeldinger, vi har fået

Der er noget galt med analysen. Fandt du en sweitzer-kniv? Prøv at sætte nye øjne på data.

Vores medarbejdere bruger ikke den mailboks, vi har givet dem

Er det kommunikeret tydeligt nok. Hæng skilte op overalt. Lav pop-ups på skærmen. Har I en intern facebookside eller et intranet, som folk faktisk følger med på, så skrive det der. Bed mellemlederne om at minde om det på møder. Tag fat i to-tre af de mest højrystede medarbejdere, og gør dem opmærksom på, at der nu er én kanal for klager. Giv en synlig gave, som folk, der har givet input, kan have på deres skrivebord. 

Det står helt klart nu, hvordan problemet skal løses, men vi har under ingen omstændigheder ressourcer til det. Nu har vi skabt en forventning.

I har vist, at I har hørt og forstået, at der er et problem, og at I tager det alvorligt. Brug nogle af de data, I har samlet ind, til at sætte mere præcise ord på, hvad problemet er. Lav meget gerne en kobling til virksomhedens strategi, så det bliver tydeligt, at ledelsen oprigtigt har taget problemet på sig. Vær ærlig om, at en løsning er for dyr eller ressourcekrævende. Opfordre meget gerne medarbejderne til at udtænke løsninger i det daglige nærmiljø. Hvis dette problem er forretningskritisk, bør der hentes ekstern konsulenthjælp, men husk at være tydelig om begrænsningerne fra starten. Der findes en løsning!

Problemet er løst, men der er også meget andet, der fylder og som kan løses på samme måde. Hvornår kan vi gå i gang igen?


Man skal ikke lave den slags ting hele tiden. Det er bevågenheden, der skaber resultaterne. Hvis der er et stort behov for problemløsning, var det måske mere relevant at se på, om der er noget i organiseringen og strukturen, der helt grundlæggende skal ændres. Læs mere her.       

Print Friendly, PDF & Email
Share