Hvordan får du med deg alle de ansatte i bedriften når nye interne arbeidsverktøy skal innføres eller erstattes? Her får du noen tips til hvordan du kan innføre nye verktøy uten å skape masse støy og friksjon
Innføring av nye interne arbeidsverktøy i en bedrift kan ofte være en kilde til frustrasjon blant ansatte. Dette vil spesielt være tilfelle hvis de ansatte vegrer seg for endring. De ansatte mener at systemene de har i dag fungerer og hvis de tenker at slik det alltid har vært gjort fortsatt fungerer.
I en stadig mer digitalisert verden vil det være prosesser i en bedrift som kan få et nytt liv ved digitalisering og tekniske løft. Hvordan passer du på å få med deg både de tekniske kjepphestene i bedriften, samtidig som de ansatte som misliker endring også skal bli med? Kommunikasjon! Har du en god strategi for hvordan du skal kommunisere ut endringer, og samtidig en god plan for hvordan du skal ta i mot og bearbeide tilbakemeldinger underveis så vil du stå godt rigget for å gjøre de nødvendige endringene som skal til for at du får med deg alle brukerne.
Forklar veikartet for brukerne dine
Når du som produktleder, team lead, prosjektleder eller annen tittel vet at det vil komme større endringer til ansatte så er det en gylden anledning til å inkludere brukerne i bedriften fra starten av. Ikke vent med å lansere løsningen i et big bang. Få inn noen betabrukere tidlig og lytt til verdifull innsikt fra de som til slutt skal bruke systemet.
Jo tidligere de ansatte føler at de er en del av utviklingsprosessen jo mindre støy vil det generere og mer forståelse vil brukerne kunne gi deg. Selv om teamet jobber med kontinuerlige leveranser så kan man fint forklare overordnet når teamet skal jobbe med ulike deler av løsningen i det store bildet.
Det trenger ikke være så avansert å komme i gang. Inviter de mest entusiastiske ansatte og gi de tidlig tilgang. Ofte vet ikke brukerne helt hva de ønsker seg, men gi dem noe konkret tidlig og du vil som regel få mye og god innsikt i hva brukerne ønsker seg på sikt. Det er til syvende og sist brukerne som faktisk skal bruke løsningen, og bedriften er godt tjent med å ha fornøyde ansatte som liker de nye verktøyene de skal bruke.
Gjør det enkelt å gi tilbakemeldinger
Når man sitter i et utviklingsteam er det lett å glemme at kommunikasjonen må gå begge veier. Teamet må enkelt kommunisere endringer, spørsmål og få avklaringer fra brukerne, og samtidig må brukerne ha en enkel måte å kontakte teamet. Ikke la det være vanskelig for brukerne å gi tilbakemeldinger, da går du glipp av mye god innsikt fra de som til syvende og sist skal bruke systemene dere utvikler. La brukerne kontakte teamet direkte på Teams/Slack/osv. Sett opp et skjema i løsningen som brukerne kan melde direkte til teamet. Akkurat hvilken teknisk rigg dere går for er ikke så farlig. Det viktigste er at det er enkelt å gi tilbakemeldinger.
Kommuniser alle endringer i relevante kanaler
Det vil skje endringer i løsningene man utvikler hele tiden. Når utviklerne leverer ny funksjonalitet kan man enten samle opp en post i uken som forklarer det viktigste som har kommet og dele det på Teams/Slack/osv., eller la utviklerne selv dele funksjonalitet de har levert. Utviklerne vil da få et større eierskap til levert funksjonalitet og bli bedre kjent med brukerne.
Vær ærlig når teamet tar feil
Noen ganger tar teamet feil. Det er i stor grad essensen av å drive kontinuerlig utvikling der man hele tiden måler effekten av det man gjør, og er åpen for tilbakemeldinger hele veien under utviklingsløpet. Når teamet lærer at de har bommet må man ikke prøve å skylde på brukerne, men være helt ærlig på at man har bommet, takke for ny og verdifull innsikt og så implementere de relevante endringene som må på plass. De ansatte vil da forstå at det nytter å komme med tilbakemeldinger og de vil føle at de blir tatt på alvor under utviklingsprosessen.
L øs noen lavthengende frukter også - Skaff deg goodwill
Det er viktig å ha fokus på de store linjene og fremtidig uthenting av gevinst, men ikke la det bli det eneste dere fokuserer på. Dersom man migrer seg bort fra et gammelt system, så ta dere tid til å lytte til hvilke utfordringer brukerne har i dag. Ikke bare fokuser på hvordan det nye systemet skal løse alle brukerens problemer i fremtiden. Prøv å identifisere noen lavthengende frukter som vil være enkle for teamet å implementere med ny løsning og vis at dere tar brukerens tilbakemeldinger på alvor. Et par lavthengende frukter kan være det som skal til for å få med seg de brukerne som er averse for endringer, og det vil gi teamet mye goodwill når vanskeligere prioriteringer må tas i fremtiden.
Konklusjon
Ved å ha en god strategi for kommunikasjon med brukerne vil man kunne få mye god innsikt, redusere friksjon og skape et godt grunnlag for samarbeid når nye IT-løsninger skal lanseres for de ansatte i en bedrift. Ikke vent til man er "ferdig" med å kommunisere at nå kommer det endringer. Få med dere de ansatte tidlig i prosessen, la dem ta eierskap til løsningene de selv skal bruke og la dem være med i utformingen av dem. Lytt til den innsikten de sitter på, guide dem hvis teamet ser nye og mer effektive måter å løse et problem på, og vær en lagspiller i alle faser av implementasjonen av nye løsninger.
Da vil du stå godt rigget for fornøyde brukere som tas på alvor og det vil være enklere å få med seg alle ansatte når nye IT-løsninger skal innføres i bedriften.