Hvordan takler leverandørene et nei?

bad loserEtter å ha gjennomført et anskaffelseprosjekt nylig ble jeg nok en gang minnet på hvor forskjellig leverandørene håndterer et avslag. Som fører til at jeg sitter igjen med veldig forskjellige inntrykk – som ikke bare er påvirket av det tilbudet de ga og den prosessen som ble gjennomført frem til beslutning, men også av deres reaksjoner på et nei. På meg virker det som mange ikke har en bevisst policy i forhold til dette, og det tror jeg de kan tape mye på. Spesielt når konsulenter som meg styrer prosessen, for vi går jo videre til en ny kunde og møter ofte de samme leverandørene mange ganger, i motsetning til kunden som har gjort sitt valg.

I det tilfellet jeg tenker på nå, kan reaksjonene deles i tre grupper:
1. Vennlig og saklig tilbakemelding om at de respekterer avslaget, men at de ser frem til nye muligheter.
2. Kverulering om begrunnelsen for avslaget.
3. Total stillhet.

Den vennlige og saklige gir et profesjonelt inntrykk i sin kundebehandling, selv om tilbudet ikke nådde opp.

Inntrykket av kverulanten kan slå ut i to retninger. I dette tilfellet var de uenige i vår vurdering, men måtte etter hvert innse at grunnen til dette var at de selv ikke hadde klart å formidle et budskap. Formen de valgte var ganske spiss, og det er heller ikke spesielt lurt. Dersom de klart kan påvise en feil, kan det være fornuftig å ta opp dette, men jeg synes leverandørene skal tenke seg litt om før de gjør det.

Den tause leverandøren er kanskje den verste. De er ofte aktive og følger tett opp helt frem til beslutningen, men så blir det helt stille. Ingen e-post, ingen telefon. Hva blir da inntrykket jeg sitter igjen med? Jo, de er sure har tatt seg nær av avslaget, selgeren har kanskje latt det hele bli litt for personlig. Det trenger ikke være slik, men taushet er ikke noen god strategi.

Uansett er en tilbakemelding bedre enn total stillhet. Jeg er overrasket over at ikke flere ga et saklig svar i kombinasjon med et ønske om å lære mer om hvordan de ble opplevd av kunden. Burde ikke det være obligatorisk i selgerens håndbok? Ingen av de som fikk avslag ba om å få et erfaringsmøte. Det innebærer at de går glipp av en fin mulighet for læring.

I dette prosjektet ble 9 leverandører forespurt om de ville tilby. Fem ga tilbud, to informerte om at de ikke ville gi tilbud, mens to hørte vi ingen ting fra. Det er også for dårlig. Det koster dem så lite å gi en rask tilbakemelding dersom de ikke ønsker å tilby. Det blir alltid respektert av kunden.

Totalt sett ga leverandørene et godt inntrykk helt frem til avslutningen. Gode tilbud, løpende oppfølging underveis, bra presentasjoner. Men avslutningen stod ikke i stil. Det gir aldri et godt inntrykk å fremstå som en dårlig taper.

Advertisements

Arkitekturens forbannelse

Du finner ingen IT-folk som ikke mener at arkitektur, på ett eller annet nivå, er viktig. Fra det detaljerte nivået med tekniske arkitekturer for nettverk og servere, til høynivå arkitektur som viser sammenhengen mellom strategi, arbeidsprosesser, informasjon og systemer (enterprise architecture). Det ubehagelige og vanskelige er at arkitekturen på flere nivåer ofte henger sammen. Før jeg tar opp denne tråden igjen, en liten casehistorie.

Jeg kom over et interessant prosjekt forleden. En forholdsvis liten offentlig virksomhet hadde innført en ny løsning for online innrapportering av data om sine brukere. Informasjonen ble benyttet slik at de kunne tilpasse sine tjenester på en meget fleksibel måte, med full oversikt over dagens behov. Dette gjorde de raskt og billig, uten å involvere andre enn sine leverandører. Teknologien er avansert, men løsningen enkel. De valgte helt bevisst ikke å ta hensyn til noen sentrale føringer overhode, enten de kom fra Difi eller andre. Smarte var de også: Det hele ble definert som et prøveprosjekt, noe de fikk aksept for. Løsningen fungerer i dag som planlagt. Egentlig en liten suksesshistorie. Hva er da problemet?

Virksomheten jeg refererer til er en av mange «avdelinger» i en stor offentlig virksomhet som strever med akkurat de samme problemstillingene. De visste veldig godt at dersom de skulle ha ventet på et «konsernprosjekt» som hadde tatt hensyn til alle mulige problemstillinger med valg av teknologi, standarder, og ikke minst arkitekturer, ville de ikke ha gått live i 2013, men kanskje i 2016 –  hvis de hadde kommet i mål overhode. Da er det vel bedre bare å starte? Så får i det minste noen glede av dette. Problemet, sett fra toppen, er når «alle» i innfører ulike løsninger. Da blir det dyrere og selvsagt vanskeligere å trekke ut styringsdata på tvers. Her skyter jeg kanskje meg selv litt i foten (som gammel IT-direktør som alltid var opptatt av synergier på tvers … ), men jeg synes faktisk det er bedre at noen ildsjeler får mulighet til å innovere enn at man skaper store, tunge prosjekter som aldri tar av. Jeg kan tenke meg mange situasjoner, som f.eks. innføring av et ERP-system, hvor det vil være annerledes, men altså ikke her.

Enterprise architectureEtter å ha jobbet i denne bransjen to tiår har jeg fortsatt til gode å se noen som virkelig har lykkes med å både lage, følge og oppdatere en helhetlig arkitektur over tid. Det blir med et stunt, så settes det hele bort. Noen gode elementer brukes, resten har ingen verdi.

Så fornuftig i teorien, men så ubrukelig i praksis.

Lærebøker trenger ikke være kjedelige

Lærebøker er kjedelige, hevdet førstelektor Per Bjørnar Grande i en kronikk i Aftenposten en tid tilbake.

Ja, han har dessverre rett. Unntakene finnes, men de er få. Spørsmålet er om profesjonen han selv representerer og ikke minst forlagene er villige til å gjøre noe med det. Det ser ikke slik ut. Jeg har nå gitt ut to bøker, Jerntriangelet og Omstilling, begge er såkalte fagromaner. Her er det to sjangre som kombineres: fagboken og romanen. Jeg forteller en historie med et klart faglig budskap. Men hva skjer når man kommer med et slikt konsept til de tradisjonelle forlagene? Spennende idé, sier de. Men er hva er det egentlig? En roman eller en fagbok? Nei, det passer nok ikke her hos oss. Og hva sier høgskolene? Jeg har sendt boken til fagansvarlige på de fleste høyskoler i Norge. Noen hyggelige tilbakemeldinger har det vært, men så blir det stille. Å ta slike type bøker inn på pensumlisten ser ut til å sitte svært langt inne. Målet er å få studentene til å lære, er det ikke? Da må man ture å tenke litt utradisjonelt.

Jerntriangelet_forside_72dpiFor fagbøker trenger virkelig ikke være kjedelige! I USA er det jo lenge siden bøker som The One Minute Manager, The Goal, Who Move My Cheese og Leadership and Self-Deception viste hvordan en annerledes formidling av faglig materiale kunne gjøres. Det var disse bøkene som inspirerte meg til å skrive på denne hybride formen. Ved å bruke romanens format viste de hvordan man kan fremstille vanskelige og utfordrende temaer på en oversiktlig, leservennlig og underholdende måte. Selve «storyen» må være god nok til at leserne får lyst til å bla om, og ofte kan man benytte må anekdoter for å krydre fremstillingen og underbygge de faglige poengene. Og da blir leservennligheten og – tror jeg – motivasjonen til å lese boken en helt annen!

Finnes det egentlig IT-prosjekter?

Jevnt og trutt leser vi om store kostnadsoverskridelser i forbindelse med innføring av nye IT-løsninger. Prosjektene tar mye lenger tid enn planlagt, kundene og leverandørene skylder på hverandre, fagforeningene raser og brukerne fortviler.  Nå har vi holdt på med å innføre nye datasystemer i over 40 år. Hvorfor butter det slik?

Det innebærer ingen revolusjon å hevde at vellykket innføring av nye IT-løsninger forutsetter et nært samspill mellom teknologianskaffelse, utvikling av arbeidsprosesser og endringsarbeid. Hvor man har sikret at prosjektet støtter opp under eller er en integrert del av virksomhetens strategi. Og at man tar hensyn til organisasjonskulturen når endringsarbeidet planlegges og gjennomføres. Samt at det hele ledes og styres på en profesjonell måte fra starten av beslutningsprosessen til verdiskapningen er realisert. På tross av bevisstheten hos mange om disse sammenhengene, vil jeg hevde at svært få virkelig er gode til å gjennomføre dette i praksis, og dermed sikre at verdiskapningen eller nytteeffekten eller resultatet – kjært barn har mange navn – blir så stort som potensialet tilsier.

innovationAlt for mange kaller fortsatt dette arbeidet for et IT-prosjekt. Navnet gjør at man assosierer prosjektet hovedsakelig med teknologi. Men hvorfor innfører du egentlig et nytt IT-system? Jo, enten er det for å utvikle eller effektivisere organisasjonen, eller så er det for å utvikle tjenestene som leveres til et marked. Teknologien er et middel for å nå et mål. For å klare det må en fokusere på mye mer enn teknologi.

De aller fleste såkalte IT-prosjekter er egentlig forretningsutvikling, mange med en solid grad av nytenkning og innovasjon knyttet til seg.

For: Alle prosjekter skal ha en forretningsmessig begrunnelse og en eier i forretningen. Uansett hvilket teknisk behov man har, vil det alltid kunne vises til en konsekvens for forretningen dersom man ikke gjør det. Enten i form av at noe går langsommere, blir utilgjengelig eller feil. Som igjen har en økonomisk konsekvens. Så alle prosjekter skal ha en forretningsmessig begrunnelse.

Dersom et prosjekt kan gjennomføres uten involvering fra forretningen, er det et teknisk prosjekt. Hvis ikke, er det er forretningsprosjekt med en teknisk del. Så kan man alltid diskutere hvor den grensen går. Det finnes noen rene IT-prosjekter. En oppgradering av nettverk (WAN, LAN, WLAN) er tekniske prosjekter med en forretningsmessig begrunnelse (får ikke gjort jobben skikkelig uten mer båndbredde). Grensen for når det er et rent IT-prosjekt kan variere, men bør etter mitt syn være meget høy. Det vil si at prosjekter der den tekniske delen utgjør over f.eks. 90 prosent blir definert som et teknisk prosjekt og styrt deretter. Men ellers er det forretningsutvikling!

Syv grunnregler for å få mer igjen fra IT-investeringene

Hvem kjenner seg ikke igjen her: Som beslutningstager blir du bedt om å godkjenne en IT-investering på et alt for tynt grunnlag – Forankringen hos nøkkelpersoner er svak, fokus er på teknologi istedenfor endring av arbeidsprosesser og atferd, og kostnadsoversiktene er mangelfulle. I tillegg er ofte de potensielle nytteeffektene diffuse, med svak kobling til forretningens mål og strategi. Analyse av risiko mangler ofte, og relevante alternativer til investeringen blir sjelden presentert. I det hele tatt ganske omfattende mangler! Er det da rart at bare rundt 30% (i følge Gartner Group) av IT-prosjekter blir betegnet som vellykket?

I rettferdighetens navn må det sies at stadig flere har blitt dyktige til å beslutte, gjennomføre og implementere IT-løsninger slik at den forventede gevinsten oppstår. Men fortsatt legges etter min mening for mye ansvar på IT-direktøren, mens andre ledere slipper lettere unna. Noe av grunnen til dette, tror jeg, er at mange ledere mangler kompetanse om og interesse for de totale utfordringene man møter, og fortsatt mener at dette har mest med teknologi å gjøre. Men: Jo større teknologifokuset blir, desto flere vil føle seg fremmedgjort.

success failureLedere trenger noen få, gode knagger å bruke når IT-investeringer besluttes, prosjekter gjennomføres og løsninger skal tas i bruk slik at gevinstene kan realiseres. Teknologibasert endring er jo mye mer enn en dyr teknologisk oppgave. Det dreier seg om å skape verdi gjennom organisatoriske og forretningsmessige endringer, muliggjort ved smart og riktig bruk av teknologi.

Utgangspunktet er at endring av teknologi, arbeidsprosesser og mennesker henger sammen og gir premisser for hverandre, og må forstås innenfor rammene av virksomhetens strategi, styringssystemer og organisasjonskultur. Disse elementene henger ubønnhørlig sammen. Jeg liker å oppsummeres dette i 7 grunnregler:

  1. Strategi: Sjekk det nye initiativet mot virksomhetens reelle og planlagte strategi.
  2. Portefølje: Sjekk det nye initiativet mot porteføljen av andre initiativer, prosjekter og applikasjoner.
  3. Ledelse: Sørg for at det foreligger riktig beslutningsgrunnlag (business case).
  4. Prosjektstyring: Sørg for rask og dynamisk prosjektgjennomføring.
  5. Arbeidsprosesser: Sørg for løpende vekselvirkning mellom prosessforbedringer og den tekniske realisering.
  6. Individ: Bruk aktivt endringsledelse for å sikre forståelse og engasjement.
  7. Verdi:   Bruk og tilpass beslutningsgrunnlaget helt til nytteverdien er realisert.

Er man bevisst på dette øker sannsynligheten for at IT-innføringen blir vellykket. Men enkelt er det ikke, for det er massevis av utfordringer og fallgruver under veis …

Nå er jeg i gang

Endelig har motivasjonen kommet for å skrive en blogg om faglige ting som opptar meg. Har alltid vært glad i å skrive, og siden høsten 2012 har jeg hatt mye glede av å forfatte små innlegg på min ølblogg (henning58.wordpress.com). Etter at jeg ga ut min andre bok «Omstilling» i 2012 følte jeg mest for å tone ned skriveaktiviteten om det som er mitt «ordentlige» fagfelt, nemlig styring av IT-funksjonen. Men nå er lysten tilbake. Ikke til å skrive om teknologi i seg selv, men om alt det viktige som må på plass samtidig for at man skal kunne utnytte teknologiens muligheter på en optimal måte. Slik at man får mest mulig verdi fra de investeringene som gjøres. Dette er et stort tema med veldig mange innfallsvinkler, noe jeg synes er veldig spennende, men samtidig betyr det at jeg nok kommer til å skrive mest om det som ligger mitt faghjerte nærmest. Uansett: Jeg gleder meg til å dele mine tanker og betraktninger med så mange som mulig her på denne bloggen!