Kategoriarkiv: Strategiutvikling

IT ledelse, risikohåndtering av større IT prosjekt, strategiutvikling osv.

Trenger du en IT strategi, så hold det enkelt

Du kjenner vel begrepet «KISS! – Keep it simple stupid!»? Sjelden er ordet mer treffende enn når det gjelder å lage en IT strategi. Du har sikkert lest tekniske IT dokumenter fullspekket med fremmedord og forkortselser. Nå når IT er et allment verktøy, behøves et enklere språk – i alle fall dersom man ønsker at strategien skal brukes i praksis.

Kunsten å skrive enkelt om noe komplisert gjelder ikke bare IT, men IT-bransjen er vel bransjen med suverent flest TBF-er (trebokstavsforkortelser). Utgangspunktet er derfor dårlig. Likevel er det endel enkle grep som kan gjøres for å redusere kompleksitet…

Innholdsfortegnelsen. Allerede her varsler vi jo leseren om hvor vanskelig og omfattende dette er. Klarer du å lage en IT strategi som kan leses som en vanlig «forretningsplan», så har du gjort mye bra. Leseren av en forretningsplan er gjerne et styre eller en investor i en bedrift som ikke trenger alle detaljene, men enkelte ting må være med som for eksempel:

et sammendrag (for ledelsen)
beskrivelse av nåsituasjonen (i vanlig terminologi)
overordnede mål for perioden
styringsprinsipper som gjelder
satsingsområder for perioden
(noen ord om) gjennomføringen
vedlegg (her er det tillatt å gå litt mer i dybden, men hold deg til saken!)

Det å lage en IT strategi kan gjøres enkelt, men dette er jo bare resultatet av en prosess. Når det gjelder prosessen for å komme fram til en IT strategi, så krever dette langt mere av oss.

Medvirkning. En IT strategi bør muligens forfattes av personer med IT kompetanse, men virksomhetsledelsen må eie den – ellers blir den bare et dokument. Det er derfor fornuftig å etablere et diskusjonsgrunnlag med forslag til retning. Her kan man bruke et uttall av innfallsvinkler f.eks. hvor-hva-hvordan (where-what-how) analyse, analyse av styrker, svakheter, muligheter og trusler (SWOT). Man kan kjøre en risiko-analyse med deltakere osv. Å skape enighet om en høynivå målsetting er utkommet av det hele.

Styringsprinsipper. Fundament for all strategi er ressursgrunnlag og ressursforvaltning. Hvilke midler og valgalternativer rår man over? Hvordan samsvarer dette med dagens forvaltningsmodell? Dette er et ganske ofte et undervurdert område. Dersom det er et problem med manglende styring, sier det seg selv at man bør ha dette som et satsingsområde og få det på plass. Det finnes mange gode rammeverk, og innen IT sektoren har man etterhvert ITIL (nok et begrep!) som en slags minste standard for å definere en tjenestemodell (NB! Disse begrepene må forklares for leseren!). Symptomer på sviktende forvaltningsmodell kan være dårlig opplevd service fra IT avdelingen, mangelfulle innkjøpsrutiner og leverandørstyring, eller manglende eierskap til systemer.

Nye satsingsområder. IT strategi skal jo helst innbefatte en endring, men her er det viktig å kjenne virksomhetens rammebetingelser. Står man overfor en vekstfase, så er det andre forhold som gjelder enn om man er i konsolideringsmodus som følge av markedsstagnasjon eller nedgang i virksomheten. Det er også naturlig å peke seg ut hele eller deler av porteføljen av IT systemer. Er det mye gammelt som ikke «snakker sammen» og som gir utfordringer i arbeidsprosessene? Har man behov for fornyelse? Igjen er det viktig å sikre at IT strategien forankres og diskuteres i løpet av strategiarbeidet, slik at man sikrer at IT strategien faktisk kan gjennomføres med gitte ressurser og rammebetingelser. Når det gjelder «nye områder», bør man sikre tilgang på kilder som kan si noe om utviklingen og utfordringer med ulike veivalg. Et tips er Gartner Group. Glem ikke å spørre IT-bransjens fagfolk om hva som kommer og hva det er vi bør ta hensyn til av IT trender og ikke minst på IT sikkerhetsfronten. En workshop på «gapet» mellom dagens og nye satsingsområder vil kunne avsløre om man har for høye ambisjoner.

Gjennomføring. En god IT strategi må kunne gjennomføres, og har man for mange satsinger i flere retninger, vil det vise seg når man forsøker å lage en gjennomføringsplan. En god gjennomføringsplan tar høyde for at målbildet kan endre seg, men sørger for at delmål attid oppfylles underveis. Det er viktig å ha klare delleveranser for første året, slik at man får «øvd seg» på å treffe med ambisjonsnivået. Forutsetninger for gjennomføring må også klargjøres, slik at uforutsette hendelser som påvirker utfallet av IT strategien ikke kommer som en overraskelse. En god risikoanalyse med tilhørende risikoreduserende tiltak er et bra tillegg for en god plan. Den klassiske risikoen er av operasjonell art; At IT prosjekter går utover forvaltningen – eller at IT drift tar fokuset bort fra den strategiske endringen og dermed forsinker gjennomføringen av IT strategien.

Kommunikasjon. Til slutt tilbake til det opprinnelige utfordringen. Når en IT strategi foreligger etter en omfattende IT prosess, kommer behovet for å informere de som ikke har vært med på den interne prosessen. Språk, form og virkemidler er nesten like viktig som innholdet. Det krever mye å lage ting enkelt. Derfor anbefaler vi at selv enkle begreper forklares – gjerne i vedlegg, og at man i minst mulig grad bruker forkortelser.

En IT strategi kan lages vanskelig og den kan lages enkel. Jeg har utelatt beskrivelsen av nå-situasjonen, av den enkle grunn at den er unik for hver virksomhet og veldig avhengig av kontekst. Som en regel bør den begrenses til 1 side, men likevel er det jo den som danner grunnlaget for hvilke satsningsområder som er realistiske å foreslå. Beskrivelsen skal gi en slags «IT status» og bør definitivt inneholde rene tallfakta om IT infrastuktur, forvaltningsprinsipper og dagens bruk av IT-systemer. Og glem ikke fakta om dagens utfordringer.

Problemer er til for å løses. Lykke til med ny IT strategi!

Ny virksomhetsarkitektur – Hvordan prioritere riktig?

Nyere IT løsninger har den fordelen at man endelig kan se fremover og ikke trenger å tenke på fortiden. Eller er det ikke så enkelt? Hvem kan svare på det? Vi snakker ikke om enkle «apper», men komplekse virksomhetskritiske IT-løsninger. Kartlegging bør være første steg på veien. Det er her virksomhetsarkitekten kommer inn.

Eksterne konsulenter er gjerne eksperter på å lage gode business-case som et grunnlag for å foreslå ny IT arkitektur. Enten du har vokst ut av dagens ERP løsning eller vurderer hvordan du skal ta vare på kunden bedre ved hjelp av CRM. Vurderingen av hvor godt systemet passer med bedriftens interne prosesser har imidlertid ingen andre enn bedriften selv forutsetninger for å vite noe om. Her kreves analyse. Konsulenter kan i beste fall være en katalysator for endring.

En konsulentvurdering som ikke tar hensyn til dagens arkitektur hopper gjerne også bukk over muligheten til å intervjue dagens brukere og ledere. Innføring av nytt CRM, ERP eller PLM system uten reell brukermedvirkning er ingen god ide. Man kan ha god avkastning på papiret, men uten reell forankring av nye IT-løsninger vil resultatet fort bli negativt.

En helhetlig virksomhetsarkitektur ser både på dagens og fremtidens behov. Når man planlegger prosjekt og initiativer i forhold til virksomhetens arkitekturbehov, behøves et godt rammeverk – et som ikke er for snevert. For hensikten er ikke å lage et IT-system, men å støtte forretningsmålene og tilhørende forretningsprosesser. Metoden må sikre eierskap til krav – både prosess-, teknologi- og brukerkrav. Teknologi er oftere i seg selv et krav og en egen premissgiver for å sikre bedriftens fremtidige konkurransekraft. Storkonsernet General Electric (GE) sier i sin markedsføring av programvare at enhver produksjonsbedrift må bli en programvarebedrift for å overleve på sikt. Kanskje har de rett?

En god virksomhetsarkitektur beskriver sammenhenger mellom prosess, IT arkitektur og organisasjon. Uten en god forståelse fra eier av forretningsprosessene, får man liten gevinst. Det er derfor viktig at virksomhetsarkitekturen kan beskrives på forståelig vis for alle parter. Tilstrekkelig analyse må også til for bedriftens utgangspunkt. Endringer fra dagens til fremtidens løsninger betinger gjerne en kostnad. Hvilke kostnader finnes det? Definisjonen av begrepet kostnad må omfatte kostnad ved å endre; kostnaden ved å bytte ut dagens operative IT infrastruktur, men også kostnaden ved endring og opplæring i nye prosesser. Likevel kan det lønne seg å investere i nye løsninger, da de ofte er mer brukervennlige enn sine forgjengere.

Kompleksitet koster. Gap ikke for høyt. På bakgrunn av kompleksiteten i dagens virksomhetsarkitektur er det mange som vegrer seg for å gå i gang. Og i mange tilfeller vil bedriften ha for knappe ressurser til f.eks. å kunne løfte seg på en helt ny IT plattform. I andre tilfeller vil det oppfattes som en befrielse å forenkle løsningene som mange ganger er basert på et «lappverk» av overlappende systemer. En enkel analyse vil kunne avdekke hvor kompleks og kostbar en endring kan bli.

Plassering av ansvaret for arkitektur. Forretningssiden bør definitivt forstå viktigheten av eierskap til en helhetlig virksomhetsarkitektur. Den bør ikke for lett delegeres bort, men beholdes på forretningssiden, gjerne under en CIO rolle. Den interne IT avdeling har gjerne en annen agenda som går ut på å forvalte dagens struktur. Her ligger det en mulig konflikt; Å legge arkitektur til Intern IT kan medføre en sammenblanding av roller. Samspillet med forretningssiden bør tillegges vekt, slik at man sikrer prosesseierskap til teknologien. Arkitekten blir da som rolle tilsier – en arkitekt med oppdragsgivere.

Arkitektens egenskaper. Hun bør være mest mulig uavhengig, ha god forståelse for effektive arbeidsprosesser og en god porsjon «mot i brystet». Hvorfor det? Et spørsmål fremover kan være: Skal vi la brukerne styre mer selv og legge til rette for «selvbygging» eller skal vi sentralt styre dette ved hjelp av intern IT? Eller sagt på en mer direkte måte: Trenger du hushjelp når du har alle disse flotte husholdningsmaskinene? Arkitektens rolle blir nok mer og mer å designe og tilrettelegge kjøkkenet basert på aktørenes krav til komponentene som inngår.

Et arkitektur-prosjekt er et planleggingsprosjekt. Da må man kunne diskutere overordnet prioritering – om det er viktigst å vedlikeholde eksisterende «haltende» portefølje, eller tenke nytt og helhetlig om arbeidsprosesser. Med dagens raske utvikling kan det siste være et nødvendig skritt for å overleve. I tillegg bør man spørre hvordan prosessen kan bli mer effektiv med støtte av teknologi. Det må være lov å stille seg hypotetiske spørsmål!

Teknologi som driver i seg selv. Det er viktig at arkitekten spør seg hva ny teknologi kan gjøre for prosessene og hvilke rammebetingelser digitaliseringen gir? Alternativt kan utfallet fort bli et IT prosjekt uten avkastning om man ikke tar hensyn til alle fire sider av diamanten: Prosess, system, teknologi og organisasjon. Og så var det var det å huske på bedriftens evne til omstilling…som allerede nevnt.

Gode verktøy nødvendig. Bruk av strukturerte modeller og verktøy kan overdrives. Likevel skal man ikke undervurdere organisasjonens behov for en god visjon eller et godt «konsept» for å beskrive arkitekturutfordringen – et bilde sier mer enn 1000 ord. Vi forstår alle arkitektens utfordring i overført betydning når det er snakk om fysisk infrastruktur f.eks. hvor komplisert det er å bygge veier eller høyhus. Vi glemmer imidlertid at informasjonsstrukturer er kompliserte – og lite konkrete for de uinnvidde. Derfor kreves detaljerte planer eller programmer for endring av «informasjonsveien» i bedriften.

Til slutt. Det er viktig med felles mål og felles begreper; Et steg kan være å etablere felles referansemodell for virksomheten, slik at flere forstår helheten og kan diskutere begreper, retning og innsatsfaktorer. Ved å forstå sammenhengen mellom prosess, systemer, teknologi og organisasjon kan man bedre prioritere de riktige arkitektur-prosjektene. Dette krever imidlertid at man investerer i å få eiere av prosessene og teknologien på banen i en felles diskusjon om lønnsomme veivalg. På den måten unngår man i overført betydning å lage ubrukelige veitrasseer som ikke viser seg liv laga som pressen ynder å omtale det som – «unngå flere myslykkede IT prosjekter» som det jo allerede er for mange av.

Del gjerne dine erfaringer med virksomhetsarkitektur og kommenter på CIO bloggen.

Like barn leker best

Når man leter en partner for outsourcing, er det mange ting å ta hensyn til. Noen liker mora, andre liker dattera. Outsourcing som fenomen har eksistert i tiår. Det er derfor mange som har ulik erfaring. Noen vil si «vi angrer ikke et sekund»; andre ville aldri gjort det samme om igjen.

Etter å ha observert og implementert flere IT prosesser ved hjelp av outsourcing er det klart at det finnes mange tilnærminger til temaet. Det er likevel slående hvor mange likheter det er; Alle snakker om kulturelle utfordringer, at det ble dyrere enn først antatt. Kvalitetsutfordringer finnes jo, men også den økonomiske gevinsten av å samordne og oppnå stordriftsfordeler.

Hva er kriteriet for vellykket Outsourcing? Som for mange andre tjenester er det nok klart at man får hva man betaler for. Likevel vil man sikre at kvaliteten er god nok. Det går jo utover dine IT brukere til syvende og sist. Mange på IT brukersiden har nok lenge tålt så altfor mye i forhold til uprofesjonell IT helpdesk og så videre. Men erfaringene stikker også dypere. Det handler om å finne den riktige IT partneren.

Konsern har sine behov og mindre bedrifter og entreprenører helt andre behov. Er kravet lavest mulig kost, eller krav til rask responstid for en rimelig penge? Vi ser veldig ofte at man velger feil partner; Enten at man blir for liten som kunde av en stor leverandør (det er noen leverandører som også fikser det å ha mindre kunder!), eller at man har valgt en leverandør som er for god til å være sant – altså at leverandøren ikke klarer å levere varene.

Kulturforskjeller spiller også inn – ikke bare ved valg av land man outsourcer til, men også din egen bedrifts verdier, kultur, sjargong, organisasjonens omgangsformer spiller inn. I gode relasjoner må man snakke ofte sammen. Like barn leker best, og de leker ofte. Dette blir ofte glemt i kunde-leverandørforholdet. Man er jo så opptatt og undervurderer behovet for oppfølging. En Outsourcings kontrakt uten jevnlig oppfølging er nemlig bortimot bortkastet.

I skrivende stund har jeg aldri opplevd at en Outsourcing avtale er perfekt. Det er alltid behov for justeringer i samtale med IT partneren. Man er i det for det lange løp og ikke ute etter kortsiktig vinning. Noen outsourcer til og med deler av kjernevirksomheten for å oppnå skalerbarhet, selv om det nok tilhører unntakene. Det handler jo også om hvor mange fokus din egen organisasjonen kan ha for å lykkes i markedet.

Del dine erfaringer og kommenter på CIO bloggen.

Governance i global IT forvaltning

Det er grunner til at rammeverk som ITIL (ISO 20000) med flere har sin berettigelse. IT prosessen i en bedrift er av natur en kompleks sammenblanding av prosess, informasjon, systemer og infrastruktur. Når man i tillegg skal styre og levere IT globalt, er det langt flere faktorer som spiller inn. I konsern vokser kompleksiteten nærmest eksponentielt om man ikke benytter et rammeverk for prosess standardisering. Forenkling kan nemlig først skje etter at man har standardisert.

Konsern er i utgangspunkt en samling av enheter over flere lokasjoner internasjonalt. Uansett bransjen er det fornuftig med en grad av samordning mellom brukerorganisasjonene i en global organisasjon. Men noen ganger kan man lure på om anarkiet bare må aksepteres – det blir for vanskelig å styre.

I alle tjenesteleveranser handler det om at kvalitet kommer av gode standarder. IT har også sine standarder som ITIL som er med på å strømlinjeforme leveranser av IT infrastruktur og applikasjonstjenester. Vi på IT kan fort beskyldes for å være for innadvendte ved å benytte et språk som ingen forstår. Likevel er det fornuftig å finne et språk som man kan forstå på tvers av landegrenser og kulturer. Slike rammeverk er uvurderlige når man skal ha en sunn forvaltning av global IT. Det være seg både IT driftstjenester og applikasjonstjenester.

Hva er alternativet? Alternativet heter brukerstyrt systemutvikling for applikasjoner – og BYOD (Bring Your Own Device) eller «BYO IT» for IT enheter som PC, Laptop, mobiltelefoner, nettbrett. Det finnes heldigvis grader av «frislipp» på slike tilbud av IT tjenester. Du kan selve hvilke enhter du vil ha i din produktkatalog – hvis du bestemmer deg for dette. Og selv BYOD kan det etableres global IT governance rundt, men det er ikke alltid BYOD oppfattes like positivt av alle IT brukere.. Utfordringen blir når man i utgangpunktet har latt dette utvikle seg helt av seg selv.

Utfordringene med å jobbe internasjonalt blir veldig ofte undervurdert. Mange har erfart at globale IT organisasjoner støtter på vekst- og standardiseringsutfordringer, med mindre man etablerer governance i form av et rammeverk som ITIL eller liknende. Andre sverger til verktøy som er bygd over lesten av rammeverk. Det kan fungere like bra – og da slipper man å bli akterutseilt og overveldet av byråkratiet ved å styre rammeverket manuelt og i vanlig dokumentdelingstjenester. Uansett tilnærming tar det tid å oppnå god governance globalt. Her kan et rammeverk som ITIL gi deg tilgang til kompetente ressurser over hele verden, slik at du slipper å sende dine senior IT ansatte over hele verden. Det finnes snart ikke den som har jobbet med IT infrastruktur og IT serviceledelse som ikke har hørt om ITIL.

Globalt IT samarbeid er kommet for å bli. IT må gå i bresjen for å vise hva globalt samarbeid kan være. For å få til dette må vi opptre profesjonelt og innse at kultur og geografi må tas hensyn til. Eierskapet til rammeverk i form av globalisering av ITIL må sitte sentralt og styres sentralt. Governance-ansvaret ikke kan distribueres, med mindre man er i åpen kildekode eller i crowdsourcing kontekst. I sistnevnte miljøer er det helt andre mekanismer som gjelder, men det temaet får bli en annen gang…

Del gjerne dine erfaringer med global IT og kommenter på CIO bloggen.