Vi tror ledere må lære seg nye og moderne prinsipper for IT-ledelse som svarer på dagens muligheter og utfordringer. Dette tror vi etter å ha jobbet for både private og offentlige IT funksjoner på ulike nivåer.
(Avlæring er en viktig del av læringen, så vi har skrevet en artikkel om det også: 6 gamle prinsipper IT sjefen må glemme)
Vi tror IT funksjoner har to dominante tenkemåter:
Disse to tenkesettene er vanskelig å kombinere i en organisasjon og IT funksjoner må velge. Forutsetningen for å velge å la IT funksjonen arbeide som konsulenter, er at bestiller ivaretar den tekniske integriteten og sikkerheten.
Dersom man har svak bestillerkompetanse, vil konsulentfilosofien kunne gi katastrofale konsekvenser for IT funksjonen. Bestillinger som blir levert med manglende brukerforståelse og manglende teknisk robusthet vil over tid øke forvaltningskostnaden og brukerfrustrasjonen. I slike tilfeller kan IT funksjonen tenke som en produktutvikler og etablere teknologiske tjenester som pasientjournal eller et saksbehandlingssystem. Disse bør ivaretas av interne tjenesteeiere med god merkantil og teknisk forståelse.
Forutsetningen for å lykkes som en produkttenkende IT funksjon er å ha god brukerforståelse, rask leveringsevne og god trendforståelse. IT funksjonen må møte forretningssiden med nysgjerrighet og profesjonalitet og ta alle krav og bestillinger som viktige innspill til å utvikle sine eksisterende produkter og tjenester.
Innovasjon har alltid handlet om kommunikasjon mellom ulike ansvarsområder og IT funksjonene blir stadig oftere utfordret av raske endringer. Mens Ruby On Rails var det store i 2007, er Node.js det store i 2017. Dermed blir utfordringen for IT funksjonene å forstå sine brukere og benytte riktig teknologi. Motsetningen er å lære seg en teknologi og lete etter brukere eller problemstillinger som har nytte av den.
Vi tror organisering i tverrfaglige forretnings- eller tjenesteområder vil gjøre det lettere å diskutere brukerkrav på tvers av teknologiske ansvarsområder. Dermed blir det mindre dramatisk å innføre og lære ny teknologi. I en teknologienhet må du bytte sjef dersom du vil lære deg noe nytt. Jobber du i en forretningsorganisert IT funksjon vil du bli oppfordret til å ta i bruk ny teknologi som gir bedre brukerfordeler.
Teknologi kan være morsomt, men meningsløs dersom den ikke løser kundens utfordringer. Vi har sett store plattformprosjekter til millioner av kroner utført kun fordi de tekniske ansatte vil lære seg noe nytt. Vi har også sett brukerfrustrasjoner som aldri blir løst fordi de tekniske ansatte aldri har lært om brukernes faktiske utfordringer.
Gode teknologer har en tydelig fellesnevner da de forstår brukeren like godt som de forstår teknologien. Dermed blir brukerbehovet en rettleder for teknologen ved tekniske beslutninger.
Forskningen er tydelig på at ledere som gir tillit til sine ansatte får motiverte ansatte som leverer bedre:
Skal ledere kunne gi tillit til den enkelte ansatte, så tror vi at følgende punkter er viktig:
En løsning for å komme i gang med tillit kan være å gi de ansatte tillit i små doser, som en sprint i et scrum prosjekt. Vi har kalt denne lederformen for Tight-Loose-Tight ledelse.
Et stort problem de fleste IT funksjoner sliter med er mye forskjellig teknologi. Mange forsøker å standardisere på en leverandør, som IBM eller Microsoft. Dessverre så finner de fleste ut at leverandører med monopolsituasjon ikke leverer best på alt. Ofte ser vi middelmådige systemer til en alt for høy kostnad.
Vi tror derimot de fleste selskaper bør akseptere sine ulike teknologiske løsninger og heller standardisere kravspesifisering, kodehåndtering, testing, utrulling, driftsautomatisering og overvåkning. Vi kaller denne standardiseringen for Digitalfabrikken™, men mange kaller dette for Application Lifecycle Management.
Slik standardisering vil forenkle forvaltningen av systemene, og gjøre det mulig med kommunikasjon på tvers av systemer og teknologier. Med en felles standard for spesialutvikling får IT sjefen dokumentert kontroll over krav, ulike systemers kvalitetsnivå og kundeerfaringer. Dette gjør det enklere å sette krav til ytelser eller å bytte ut systemer som ikke leverer.
På 90 tallet var den vanlige måten å distribuere programvare på via disketter eller CD-er, noe som førte til at man måtte lage programvaren helt ferdig før man sendte den ut til kunden. Etter kunden hadde installert programvaren kunne man forvente kun små feilrettinger. Dessverre er det mange som arbeider etter denne gamle filosofien.
Det er stadig flere som oppdager at det ikke trenger å være slik. Det eksisterer verktøy og teknologi som muliggjør tidlig lansering av programvare, med tilhørende kontinuerlige endringer. Forutsetningen for å lykkes er å endre prosesser og filosofi rundt lanseringer.
Det å lansere tidlig og ofte krever automatisering, men fører til at hver produksjonssetting blir mindre kompleks og dermed lettere å kontrollere. De beste i bransjen kan lansere nye funksjoner helautomatisk og raskt. Blant annet legger FINN.no ut ny kode 978 ganger per uke. Vi tror at alle bør bestrebe hyppige leveranser, uansett om du baserer deg på egenutvikling eller tilpasning av standardsoftware.
CoWork har utarbeidet en metodikk for å modernisere og styrke IT funksjonen. Oppdraget starter med en foranalyse med tilhørende rapport som oppsummerer funn og legger en ny strategi.
Vi tror virksomheter må vurdere følgende punkter:
Resultatet vil bli en IT funksjon som stadig blir mer effektiv til å håndtere de nødvendige IT-systemene, samtidig som de får frigjort tid til raskere å utvikle de verdiøkende spesialtilpasningene som kan bedre konkurransekraften for resten av virksomheten.
Originally published at cowork.no on October 18, 2017.
------------------------------
6 nye prinsipper IT sjefen må lære seg was also published in
Coworkforce on Medium, where people are continuing the conversation by
highlighting and responding to this story.
