Denne klumme er et debatindlæg og er alene udtryk for skribentens synspunkter.
Når der indkøbes software og it-systemer, udarbejder de fleste organisationer en eller anden form for business case forud for købet for at sikre sig, at der er en fornuftig gevinst, besparelse eller effektivitetsforbedring der kan retfærdiggøre købet.
I min tid som projektleder har jeg set min del af business cases og risikoanalyser.
Noget, der ofte (ikke altid) glimrer ved sit fravær, er følgende risiko: Hvad nu hvis brugerne bare ikke gider tage det i brug?
Det er noget, som langt de fleste, der sidder og brygger på et nyt system, har svært ved at forestille sig.
Man bliver fanget i et ”confirmation bias” og har ikke fantasi til at forestille sig, at det fantastiske system som man er i gang med at udvikle/indkøbe ikke vil blive modtaget i organisationen med kyshånd. Men selvom dit kommende it-system praktisk talt er selvfinansierende og kan punktsvejse under vand, så falder det hele fra hinanden hvis ikke brugerne kan se fidusen.
Risiko nummer 1
Brugerne har ikke bedt om et nyt system, og derfor bliver de heller ikke specielt begejstrede når ledelse/it/forretningsudvikling præsenterer et nyt
Det bedste man kan gøre for at undgå dette er at understøtte en bottom-up kultur i organisationen, lytte til brugernes ønsker og problemer, og hvis ledelsen endelig beslutter, at der er behov for et nyt it-system, så involver brugerne så tidligt som overhovedet muligt.
Og hvis involveringen skal blive til andet end et figenblad, man kan gemme sig bag senere, så er man nødt til at lytte til brugernes mening.
Få ting er så ødelæggende som at blive bedt om at give input og så fem måneder senere opdage, at alle ens guldkorn er arkiveret lodret.
Risiko nummer 2
Der opstår et A- og et B-hold blandt brugerne. Dem, der ønsker forandring, og dem, der kunne lide tingene, som de var.
De fleste systemer har et tipping point ved omkring 70-75 procent.
Det betyder, at hvis mere end 75 procebnt af dem, som systemet er målrettet mod, bruger det, så bliver det standard, og de fleste tager det til sig.
De få, som er modstandere af systemet, vil typisk overgive sig før eller siden og ”se lyset” - eller affinde sig med det nye system, selv om det ikke var deres førstevalg.
Rammer man derimod under 70 procent, er der stor risiko for, at der opstår ”lommer” af andre måder at gøre tingene på, og det kan være en bombe under et nyt system.
Hvis eksempelvis kun 60 procent aaf medarbejderne arbejder i det nye system, så betyder det, at 40 procent af den viden/data/arbejde/historik, som burde være i systemet, i stedet findes andre steder.
Det undergraver systemet og risikerer at skabe et skred, hvor flere og flere ikke stoler på systemet.
Løsningen er at sætte alle sejl ind tidligt i systemets levetid.
Det er som et plaster, der skal rykkes af. Jo hurtigere man gør det og får alle med, jo før kan man komme videre og håndtere de eventuelle valide problemstillinger, der måtte være i forhold til det nye system.
Har man som organisation besluttet at indkøbe et system, så skal man også stå fast og kræve, at alle tager det i brug. Hurtigt.
Hvis man er så usikker på, om man har valgt den rigtige løsning, at man lader enklaver i organisationen fortsætte med at bruge andre systemer/løsninger, så skulle man aldrig være gået i gang.
Det kræver mod at holde fast, når organisationen vrider sig, men det er mangel på lederskab at lade være.
Har man gjort sit benarbejde ordentligt, så står man på sikker grund – og så er det bare med at komme i gang.
Risiko nummer 3
Politisk fnidder risikerer at tage et nyt it-system som gidsel.
Der kan være mange årsager til, at de førnævnte A- og B-hold kan opstå, men et af de mest risikable er, hvis det er funderet i politik.
Især i større organisationer kan der opstå strategiske magtkampe både internt i ledelse, direktion og mellem afdelinger.
Et nyt it-system kan blive fanget i en sådan magtkamp, selv om systemet intet har med sagen at gøre.
Det kan lyde barnligt, men det er ikke desto mindre en risiko, man er nødt til at forholde sig til.
I forbindelse med implementeringer af vores Orbit-system har vi desværre oplevet, at projekter er forsøgt afsporet, fordi nogen i organisationen havde et horn i siden på andre, ikke har følt sig nok involveret i processen eller ganske enkelt har været modstander af beslutningen.
Det er vigtigt, at man internt i sin organisation analyserer, hvem der eventuelt kunne være modstander af en ny løsning, samt hvem der har magt til faktisk at have en negativ indvirkning på processen.
Dertil er man desværre også nødt til at forholde sig til, at især organisatorisk udrulning af et nyt it-system kan blive saboteret grundet utilfredshed med noget helt andet i organisationen end det faktiske system.
Systemet bliver så blot ”collateral damage”. Skulle noget sådan forekomme, vidner det naturligvis om en yderst usund organisationskultur, men derfor er man stadig nødt til at forholde sig til risikoen for at det kan ske.
De fleste ledere ved godt, om noget sådan foregår i deres organisation – løsningen er at få ryddet op, inden man igangsætter nye projekter, da kompleksiteten ellers blot øges, og mængden af risici dermed stiger.
Risiko nummer 4
Medarbejderne har for travlt med andre ting til at tage det nye system i brug.
Systemer implementerer ikke sig selv, og der skal afsættes tid til at få folk i gang med at bruge dem. er tiden den knappe faktor, når nye systemer går i luften.
Der er måske nok afsat noget tid til introduktion, men tit ser man, at der ikke er budgetteret med den effektivitetsnedgang, som må forventes i de første par uger, efter et nyt system er taget i brug.
Er der tale om systemer, hvor der skal indlæses/indtastes data, er det også noget, man skal have lagt en plan for.
Derfor kan man ligeså godt regne med, at det tager længere tid end forventet.
Dertil er det meget vigtigt, at man forventningsafstemmer med organisationen og de enkelte afdelinger på forhånd.
Hvis en afdeling er spændt 105 procent for med deadlines, så kan man ikke med et pennestrøg indregne en time om dagen per medarbejder i ”procestid” til indkøring af et nyt system over en tre ugers periode.
Det eneste man får ud af det er, at den enkelte afdelingsleder siger: ”det der må vente, til vi får tid”.
Og pludselig har man 20-30 procent af organisationen, som er hoppet af ”udrulningstoget” og er efterladt på perronen med frustration, ressourcespild og forvirring til følge.
Igen handler det om, at man som ledelse skal have ro på bagsmækken, få de nødvendige tilsagn rettidigt og når udrulningen går i gang – stå fast på, at det gælder alle.
Alt andet er amatøragtigt og skaber unødig irritation og tidsspilde for alle i organisationen. Samtidig skal man naturligvis være parat til at svare ærligt, når en medarbejder siger: ”fint nok – det klarer vi, men hvad er det så du mener, vi ikke behøver få færdigt til tiden i denne måned?”
Sidst, men ikke mindst skal man være opmærksom på, at hvis man ikke får kørt sin udrulning igennem i et fornuftigt tempo, så åbnes der en kattelem, hvor leverandøren (med nogen vægt) kan placere ansvaret for et dårligt system, på en forpjusket udrulning og for dårlig organisatorisk forankring.
Risiko nummer 5
Brugerne får en Volvo, men ville hellere have haft en elcykel
Når nye systemer køres ind, er der ofte forskellige interesser. Selv hvis der er enighed, om at der er behov for et nyt system, er det ikke givet, at eksempelvis direktion, ledelse og medarbejdere på gulvet er enige om, hvad det skal kunne, og hvad der gør det nye system ”godt” eller ”smart”.
Et eksempel kan være, at forretningen efterspørger et nyt projektværktøj og ledelsen går med på ideen.
Men når systemet går i luften, opdager brugerne, at ledelsen ønskede noget andet af systemet end brugerne.
Brugerne efterlyste en nemmere måde at styre projekter og udveksle filer, men ledelsen var mere interesseret i bedre afrapportering og data til brug i det nye BI-system.
Brugerne står nu og føler, at det nye projektsystem er tungt og omstændeligt at bruge, fordi det i princippet er designet til at opfylde et andet behov, end det de efterspurgte en løsning på.
Her opstår der stor risiko for, at man taber sine brugere, og at de enten ikke anvender systemets muligheder fuldt ud, eller at de direkte undergraver systemet ved at finde andre løsninger på deres problemer.
Mange organisationer kæmper med ”undercoversystemer”, der lever under overfladen, såsom Facebook-grupper, Dropbox, Google Docs m.v., fordi de af brugerne bliver opfattet som nemmere og hurtigere at bruge, men som samtidig er i direkte opposition til organisationens resterende systemportefølje.
Hvis man gerne vil undgå dette, er det vigtigt, at man får afklaret de forskellige interessenters ønsker til systemet på forhånd og at man som ledelse modstår trangen til at ”hijacke” et projekt og vride det til at løse et andet behov, end det der faktisk blev bedt om en løsning på.
Sidst men ikke mindst er det en virkelig god idé at erkende, at ingen systemer kan alt – og at jo større et projekt bliver, jo større er risikoen for, at det kører skævt.
Vælg den løsning som på bedste vis løser det, der efterspørges, og hvis det så indeholder muligheder for udvidelser og skalering, således at ledelsen på et tidspunkt også kan få data til BI-systemet, så er det super – men det må ikke blive det, projektet handler om, for så fremmedgør man sine brugere i forhold til det projekt, de troede var deres.
Risiko nummer 6
Det gamle system havde sådan en smart funktion, hvor man kunne…
De fleste mennesker er vanemennesker, og desværre er mange af os bedre til at finde hullerne i osten, end til at se nye muligheder.
Jeg har desværre ofte oplevet, at brugere har nærmest umuligt ved at få øje på fordele ved et nyt system, fordi de kun kan fokusere på de få steder, hvor det opfattes som anderledes eller dårligere end det gamle.
Og det til trods for at de ofte selv har været med til at identificere manglerne ved det gamle system og definere, hvordan det i stedet skal fungere i det nye system.
Et it-system kan praktisk talt aldrig opfylde alle brugeres behov og ønsker, og især når en løsning udskifter eller afløser allerede eksisterende systemer er der risiko for, at en del af brugerne fokuserer uforholdsmæssigt meget på, hvad den nye løsning ikke kan – i stedet for at rette blikket mod hvad det faktisk kan, og hvorfor systemet er bedre.
Forhåbentlig er der en god grund til, hvorfor man udskifter det gamle system, og hvorfor det nye system er blevet valgt.
Det er nemt at blive nostalgisk, men det er en vigtig opgave i forbindelse med udrulningen af et nyt system at sikre fokus på, hvor og hvordan det nye system gør verden bedre.
Hvis man ikke nærmest i søvne kan opstille en liste med mindst fem punkter over, hvorfor det nye system er bedre end det gamle, har man ikke gjort sit forarbejde godt nok.
Risiko nummer 7
Systemet lever ikke op til forventningerne
En sikker måde at havne med en forsamling utilfredse brugere, som ikke ønsker at investere den nødvendige tid i at få et nyt system op at køre, er hvis den nye løsning ikke lever op til forventningerne.
Virker systemet ikke som aftalt, eller har det ikke den funktionalitet, som brugerne er blevet stillet i udsigt – eller har det ganske enkelt for mange fejl, således at brugerne føler de spilder deres tid, så er det op ad bakke.
Nærmest lige meget hvor meget pisk og gulerod man bruger, kan det være næsten umuligt at få medarbejdere til at bruge et system, hvis der er for mange fejl og mangler, eller det ikke løser den opgave som det var designet til på den måde, brugerne havde forventet.
Her er tommelfinger-reglerne
Der er naturligvis ikke kun én måde at sikre, at man ikke havner her, men der er dog et par tommelfingerregler.
- Vælg standardsoftware, hvis det er muligt, og der findes noget på markedet, der opfylder jeres behov.
Lad være med at tro, at it-afdelingen lige kan banke en løsning sammen ved siden af dens andre arbejdsopgaver. Det går meget sjældent, som man håber.
- Inden man vælger leverandør, så bed om referencer fra sammenlignelige organisationer/virksomheder – og snak med andre, der har stået med samme udfordring og som har anvendt samme leverandør. Gå leverandøren på klingen, og snak eventuelt med andre end lige den ene glade kunde, som leverandøren naturligvis mener, I bør tale med.
- Vælger man at få udviklet en specialløsning, bør man gøre sig klart hvorfor samt sikre sig, at den leverandør man vælger har gjort det før. Med succes.
- Sidst, men ikke mindst skal man sikre sig, at løsningen er specificeret ordentligt. En lang række problemer kan undgås ved at bruge den påkrævede tid til at få udarbejdet en ordentlig specifikation. Når det er sagt, er det vigtigt at huske, at det ganske enkelt ikke er muligt at specificere alt. Nogle ting er nødt til at være implicit, og det kræver, at man har tillid til det produkt- og den leverandør, man vælger.
- Kort sagt - reducer risikoen for at stå med et dårligt system, så minimerer man også risikoen for at brugerne ikke vil tage det nye system til sig.
Afsluttende kommentarer
Det kan lyde lidt hårdt, men når nye systemer ikke bliver rullet succesfuldt ud, eller brugerne ikke får taget dem i brug, er det 9 ud af 10 gange ledelsens ansvar. Ikke ledelsens skyld – men ledelsens ansvar.
Der er stor forskel. Det koster penge at tjene penge, og sådan er det også med it-systemer.
Vil man have gavn af dem, skal der investeres – både i indkøb, men mindst ligeså meget i den organisatoriske forankring. Indkøbet koster kun penge, hvorimod den organisatoriske indkøring også koster menneskelige ressourcer og potentielle konflikter.
Disse skal man være parat til at tage, da alternativet er meget værre – og dyrere. Problemerne og frustrationerne kommer alligevel – de viser sig bare senere og på andre måder.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os noget tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.