Strategisk IT anvendelse

Når man leder og udvikler en moderne virksomhed, er man afhængig af IT hver dag. Men ofte giver IT anvendelsen ikke de ønskede resultater, fordi afgørende forudsætninger ikke holder, eller uforudsete komplikationer støder til.

Det kan være udfordrende at styre virksomhedens IT anvendelse, fordi sammenhængen mellem ny teknologi og forretningsmæssige fordele er svær at gennemskue og kontrollere.

Hvis vi skal sikre et positivt afkast af IT investeringerne, har vi brug for en overordnet styring af IT-anvendelsen, som sammenkæder processerne for strategi, arkitektur og programledelse, og skaber værdi i forretningen. Det handler om forretningsudvikling med IT, ikke om IT-udvikling.

Fokus på strategi

IT investeringerne skal optimeres – både med hensyn til rentabilitet og risiko. Vi ønsker at komme fra usikker satsning til forudsigeligt resultat gennem anvendelse af

  • Strategisk planlægning
  • Styring og kontrol

Begge disse elementer skal bidrage til succesen, men hidtil har man i de fleste virksomheder – ikke mindst i den offentlige sektor – lagt mere vægt på styring og kontrol end på planlægningen: I mange år har vi brugt kræfter på at blive bedre til at gennemføre IT-projekter, og sikre at forløbet og leverancerne fulgte den afstukne plan. Den strategiske planlægning har kun i mindre grad været genstand for en systematisk indsats, og sammenhængen mellem indsatser og resultater har derfor været svær at opnå.

Bedre metoder

Ligesom man har forbedret projektgennemførelsen med rammer og metoder som PRINCE2 og ITIL, kan man opnå langt bedre resultater i den strategiske planlægning ved at benytte systematiske metoder i arbejdet med strategi, arkitektur og programledelse.

Strategien skal være en konkret udmøntning af de politiske og forretningsmæssige mål, og en række beslutninger om, hvorledes man vil nå dem. For at sikre at strategien er realistisk og gennemførlig, er det nødvendigt at gennemføre en række analyser og beregninger, der kan understøtte strategiens beslutninger og anvise hvilke forholdsregler der skal tages, for at sikre strategiens  gennemførelse. Vi taler fx om risikoanalyse, konsekvensanalyse og cost-benefit vurdering.

Arkitekturen skal forklare, hvorledes strategien føres ud i livet. Vi beskriver, hvilke ændringer og nyskabelser der skal indføres i forretningsmodeller, arbejdsgange, informationer og IT-løsninger. Arkitekturens vigtigste formål er at beskrive sammenhængen mellem disse elementer, i form af en ubrudt kæde fra de overordnede mål til alle de beslutninger der skal tages omkring design og implementering. Kæden giver os sikkerhed for, at  alle beslutninger er koordineret i forhold til de overordnede mål, og at alle de nødvendige forudsætninger er opfyldt, for at målene bliver opfyldt. For at udarbejde en fyldestgørende arkitektur, er det nødvendigt at have adgang til både strategien og detaljerede informationer om udgangssituationen. Men derudover har vi også brug for en systematisk metode til at organisere arkitekturarbejdet.

Programledelsen omfatter den overordnede tilrettelæggelse af de ændringer og tiltag som arkitekturen har udpeget som nødvendige for at opnå de opstillede mål. Oftest vil programmet bestå af et antal projekter, som indbyrdes skal prioriteres og koordineres. Også her er det vigtigt at benytte rammer og metoder, som understøtter en løbende optimering af hele projektporteføljen. Det kan fx handle om overholdelsen af fælles arkitekturkrav eller samordning af flere projekter med henblik på at opnå den optimale effekt.

Sammenhæng

De fleste virksomheder anerkender behovet for at skabe sammenhæng mellem forretning og IT. Det betyder i praksis, at beslutningsprocesser og organisatoriske strukturer er gearet til at tage balancerede strategiske beslutninger på en hurtig og sikker måde. Men det betyder også, at forretning og IT råder over et fælles sprog , så de spiller godt sammen, når IT anvendelsen skal tilrettelægges og styres.

Vi anbefaler at etablere en strategi- og arkitekturpraksis, som sammenkæder IT investeringerne med de strategiske mål, og giver sikkerhed for, at IT anvendelsen kan levere de projekterede forretningsmæssige resultater. Det er oplagt at benytte anerkendte metoder og rammeværker i processen, for at få et effektivt samarbejde på tværs i organisationen, og hurtigt opnå operationelle fordele.

Skandalerne er tilbage

En gang i 90’erne hørte det til dagens orden at offentlige IT projekter udviklede sig til “IT skandaler”. Definitionen på en skandale var ganske simpelt at tidsplanen og budgettet blev overskredet i væsentligt omfang. Men så fik vi DANSK IT’s Dogmer for offentlige IT projekter og Bonnerup rapporten, som gav gode råd om hvordan man gennemfører store IT projekter. Snakken om skandaler stilnede af, og vi begyndte at tale om ”fine” ting som modenhed og standarder …

Nu er den gal igen

Finansminister Lars Løkke er netop citeret i Computerworld for at han “vil have styr på løbske it-projekter”. Udtalelsen er bl.a. foranlediget af Rigsrevisionens seneste rapport om styringen af 5 statslige digitaliseringsprojekter med udviklingsbudgetter på mellem 20 og 131 mio. kr. Denne rapport var knapt nok udkommet, da Computerworld præsenterede en anden undersøgelse af fire store statslige it-projekter, som viste endnu større budgetoverskridelser og forsinkelser.

Det kunne lyde som om historien gentager sig, men en nærlæsning af de seneste skandalerapporter viser faktisk at det offentlige er blevet bedre til at gennemføre projekterne. Det er i højere grad forudsætningerne og planlægningen, det kniber med. I beretningen fra Rigsrevisionen hedder det således, ”at beslutningsgrundlaget for de fem digitaliseringsprojekter, som revisionen har undersøgt, i flere tilfælde ikke var fyldestgørende”. Også Computerworlds gennemgang indeholder eksempler på projekter, hvor budgettet er eksploderet pga. af ”uforudsete ændringer i eksisterende systemer”.

Planlægningen mangler

De ustyrlige projektforløb er faktisk en naturlig konsekvens af mangelfuld planlægning. Som Rigsrevisionen påpeger, er mange af projekterne igangsat uden en fyldestgørende business case, som viser hvorledes projektets målsætninger konkretiseres og måles. Uden en sådan ”målepind” er både projektleder og styregruppe på herrens mark, når der skal tages store beslutninger i projektforløbet. Og der er en overhængende risiko for, at resultaterne ikke står mål med investeringerne i projektet.

For at skabe sammenhæng mellem det forretningsmæssige behov og løsningens egenskaber, benyttes i de fleste projekter en traditionel kravspecifikation. Som regel opstilles kravene dog længe efter, at budget og tidsplan er fastlagt, og det sker ofte, at specifikke, funktionelle krav nødvendiggør større strukturelle ændringer – eller valg af en ny teknologi. Sådanne overraskelser kan nemt få budgettet til at skride – eller gøre det nødvendigt at skære i de leverede resultater.

En bedre praksis

Vil man undgå skandaleramte digitaliseringsprojekter, må man sikre et solidt styringsgrundlag for det enkelte projekt. Finansministeriet tog i 2008 et vigtigt skridt i denne retning ved at gøre udarbejdelsen af en business case obligatorisk for projekter over 10 mio. kr. Men det er ikke nok at have de økonomiske rammer på plads. Man må også sikre sig, at de leverede resultater lever op til forventningerne. Hertil skal vi bruge en model der sammenkobler de overordnede målsætninger med løsningens konkrete egenskaber. Det hedder en enterprise arkitektur. Her opstilles rammerne for løsningen i principform, lige fra forretningsmodeller og arbejdsgange, til de tekniske systemer og platforme.

Arkitekturen er ikke en detaljeret specifikation, men en overordnet ramme for den løsning, der skal bygges. Den gør det muligt at definere projektet præcist mht. struktur og leverancer, og sikrer moduforudsete vanskeligheder i løsningens samspil med eksisterende systemer.

Opfølgningen

For år tilbage havde det offentlige England problemer med at gennemføre moderniseringsprojekter, derfor udviklede den engelske Office of Government Commerce projektstyringsmetoden PRINCE2. Der var også problemer med IT drift og support, her blev resultatet ITIL. Begge disse metoder er i dag udbredt i hele verden, også i den danske offentlige sektor.

Danmarks Statistik udgiver hvert år en undersøgelse af den offentlige sektors brug af IT. Rapporten for 2008 er netop udkommet, og viser at 57 pct. af myndighederne nu bruger en projektmodel til styring og gennemførelse af digitaliseringsprojekter. De fleste af de myndigheder som har en projektmodel, bruger også en business case. Kun 23 % foretager dog en systematisk opfølgning på projektmålene.

Rigsrevisionen har nu sat fokus på omkostningerne ved de danske digitaliseringsprojekter, og finansministeren har udmeldt, at regeringen vil nedsætte en arbejdsgruppe, der skal se på, hvordan vi kan få bedre styr på de statslige IT-projekter. Vi er spændt på at se, hvilke tiltag ministeren vil iværksætte for at optimere de offentlige IT investeringer.

Vi er også rigtigt spændt på hvad Dorte Toft bringer på banen, nu hvor hun ovenpå IT Factory sagen har kastet sig over offentlige IT-indkøb.

Tilbageblik og fremsyn

Hvad er årets bedste nyhed på arkitekturfronten i det offentlige Danmark? EA Fellows kommer med et bud. Men først skal vi ønske bloglæsere, kunder, venner og partnere en glædelig jul og et fremgangsrigt nytår.

I vores andet blogindlæg om supertankere og optimistjoller langer vi lidt ud efter det offentlige arkitekturarbejde. Der er dog samtidig nogle rigtigt spændende initiativer på banen.

Arkitektur i FORM!

Årets bedste nyhed på arkitekturfronten i det offentlige Danmark mener vi er den fællesoffentlige forretningsreferencemodel FORM, der netop er blevet offentliggjort.

FORM er et redskab til at finde, analysere og udnytte moderniseringsmuligheder i den offentlige sektor, herunder specielt muligheder for fælles offentlig opgaveløsning og digitalisering.

FORM’s opgavekatalog er bygget op om de tre grundlæggende begreber: tjenester, opgaveområder og serviceområder. Et eksempel på et opgaveområde er ”Servicering af lovforberedelse”, der består af tjenester som administration af lovforslag og beslutningsforslag, gennemførelse af høring om lovforslag, udarbejdelse af betænkning, m.v.

FORM er udarbejdet af en ekspertgruppe med folk fra KL, IT- og Telestyrelsen, Økonomistyrelsen og Den Digitale Taskforce. Konsulenter på opgaven har været IBM, hvilket forklarer at FORM trækker heftigt på nogle af IBMs best practices. Den officielle forklaring er vist at man har ladet sig inspirere af nordamerikanske erfaringer fra bl.a. det føderale USA’s FEA-arbejde, men her har IBM også været konsulent, så hvordan man end vender den, så er der malet med blåt henover tingene.

Det med blåt består i, at man læner sig op af et af IBMs favoritakronymer, CBM, Component Business Model, som i al sin enkelthed blot handler om at ”udstille” hele forretningen på en side. Den offentlige forretning Danmark, der udtrykkes i FORM, fylder en A3-side (hvis den skal være læsbar). Andre forretninger passer nok ind på en A5-side, må man antage.

Det gode ved FORM er, at vi med den har et vigtigt redskab for udfoldelsen af en fællesoffentlig arkitektur. FORM giver overblikket over forretningen, og tilgangen kan bruges til at koble politik, strategi, forretning og teknologi – altså, skabe den altid-vigtige alignment.

Da Lars Frelle og Kristian Hjort-Madsen fremlagde FORM på aEAs gå-hjem-møde, talte de om at en af anvendelserne af FORM vil være at identificere områder, hvor der med fordel kan sættes ind med arbejdskraftbesparende teknologi. Altså skal FORM ultimativt bruges til at skrue på varme/kolde hænder-ratioen.

FORM kan og skal selvfølgelig ikke stå alene. I FEA-termer er en ”komplet EA referencemodel” foruden en forretningsreferencemodel (BRM) også fire andre referencemodeller for hhv. performance (PRM), servicekomponenter (SRM), data (DRM) og teknologi (TRM). Den danske ”oversættelse” vil svare til at FORM er BRMen, FOKUS er PRM, OIOXML/ISB er DRMen og OIO-kataloget er TRMen. Vi mangler således blot en SRM, servicekomponentreferencemodel, kunne man fristes til at sige. Men der mangler i den grad også sporbarhed mellem de forskellige referencemodeller.

Tillykke, Taskforce! Nu ser vi frem til at se de offentlige parter komme i FORM.

PS: OIO-kataloget er forresten under revidering, og indtil jul er 20 tekniske standarder i høring. Vi har med interesse gennemlæst høringsmaterialet, men ser ingen grund til at indsende et høringssvar, da der er tale om en rutinemæssig og ustrategisk ajourføring, som vi trygt overlader til bureaukraterne i Holsteinsgade. ”Nothing here, move on”.

Disclaimer: En del af de heromtalte organisationer er/var kunder hos EA Fellows.

At være eller ikke være enterprise arkitekt

Både i den videnskabelige litteratur, hos analyse institutter, og på blogs “i den virkelige verden” er der en rimelig enighed om hvad betegnelsen enterprise arkitektur (EA) står for. Men samtidig er der en klar tendens til, at stadig flere IT professionelle får betegnelsen “arkitekt” føjet til deres visitkort.

Det kan være en udfordring at få øje på enterprise arkitekten blandt alle de andre typer af arkitekter som vi møder: infrastruktur-, sikkerheds-, applikations-, løsnings-, informations-, database arkitekter – og der kommer stadig flere til!

Alle disse gode mennesker er utvivlsomt kompetente og effektive til at planlægge, designe og implementere IT-løsninger, men det kan nok diskuteres, om de alle beskæftiger sig med arkitektur. For arkitektur handler om at organisere på et overordnet niveau, i modsætning til at udforme løsningens detaljer.

I forbindelse med de konkrete opgaver, som EA Fellows løser for større kunder, er vi stødt på flere af de ovennævnte arkitekter, og mange tankevækkende beskrivelser af arkitektur. Derfor vil vi her give vores bud på, hvad arkitektur er, og – måske lige så vigtigt – hvad det ikke er.

Arkitektur er ikke tomme ord

“Arkitektur” er ikke en ny og opgraderet version af “bullshit-bingo” hvor det gælder om at kunne benytte flest akronymer og frameworks, på en måde så al tale bliver sort for dem som lytter. Hvis det er oplevelsen, så er det en sælger der taler – og ikke en arkitekt.

Arkitektur er ikke en konsulentydelse

“Arkitekter” er ikke en titel der er forbeholdt konsulenter, der er også en stor andel arkitekter i forskningsmiljøet og blandt de ansatte i offentlige og private virksomheder.

Arkitektur er ikke programmering

“Arkitektur” er mere end udvikling af ny software. Programmører og projektledere er ikke arkitekter, det er personer der har til opgave at skrive kildetekst, lave applikationer og styre implementeringen. Arkitektur handler om at organisere løsningens elementer på et overordnet niveau, og tage de principielle beslutninger for løsningens udformning.

Arkitektur indeholder mange discipliner

Der er mange discipliner indenfor arkitektur, og de har hver til sin tid en berettigelse. Hvis discipliner udelades, det være sig tekniske, organisatoriske eller procesmæssige, så bliver resultatet ensidigt og ukomplet. Alle discipliner må balanceres efter opgave, organisation og modenhed, for et skævt fokus vil føre til bristede illusioner og gode spildte kræfter for alle involverede.

Arkitektur kræver samarbejde og governance

En “stærk ledelsesforankring” eller anden form for “stærkt lederskab” bliver ofte nævnt som et element i arkitekturen, men det vil i sig selv aldrig løse opgaven for forretningen. Arkitekturen er en “opskrift”, som forretningsorganisationen sammen med ledelsen kan bruge til at løse de konkrete problemer og udfordringer, men det kræver at organisationen er i stand til at tage beslutninger og handle, for at realisere opskriften.

Arkitektur starter i forretningen

“Arkitektur” der ikke tager udgangspunkt i service til forretningen, krav eller ønsker fra forretningen, er ikke arkitektur, men elementer i en løsning. En “rigtig” arkitektur er en udmøntning af forretningsstrategien, og indeholder elementer som forretningsmodel (business case), nøgleprocesser og forbedringspotentiale (benefit realization), som definerer løsningens succesparametre.

Arkitektur er ikke en akademisk øvelse

Arkitekturarbejde som ikke er operationaliseret eller kan operationaliseres af andre, kan ikke betegnes som arkitektur. Det er akademiske øvelser, henstillinger, visioner eller dokumenter, som med stor sandsynlighed har størst værdi for forretningen i anden sammenhæng. “Rigtig” arkitektur giver grundlag for en praktisk implementering.

Arkitektur skal ikke være smuk – den skal være rigtig

Når vi taler om god arkitektur, er det altså ikke et spørgsmål om smag, men om løsningerne er hensigtsmæssigt struktureret i forhold til de opgaver de skal understøtte, og opfylder de overordnede målsætninger for den forretning, der skal bruge løsningerne.

Arkitektur giver ingen gevinster i sig selv

“Arkitektur” er ingen “silver bullet” eller frelsende Yourdon projektmodel, som giver løfte om umiddelbart målbare gevinster. Til gengæld er arkitekturarbejdet en god metode til at binde forretning og IT sammen på en måde, der sætter det positive samspil i fokus og giver mulighed for at høste nye fordele.

Disciplinen “arkitektur” er inde i en udvikling, hvor der er utrolig stor efterspørgsel, men få klare og entydige definitioner, endnu færre målepunkter for kvalitet og succes. I samarbejdet med vores kunder sætter vi fokus på at få defineret arkitektur i kundens kontekst og i forhold til organisationens modenhed. Vi bidrager også med konkretisering af arkitektur funktionens mandat og rolle, så arkitekturprocessen placeres rigtigt i forhold til de eksisterende forretnings og IT-funktioner i kundens organisation.

Principper eller sagsbehandling

De fleste kender eksempler på, at der i en styregruppe, bestyrelse eller en anden form for topledelse, bliver brugt alt for megen tid på praktisk sagsbehandling. Et eksempel kunne være, at en kommunalbestyrelse bruger timer på at diskutere om en bestemt grundejer skal have dispensation til at bygge en carport, og hvor tæt på vejen den må opføres. Sådan kan det gå, hvis reglerne er uklare, eller hvis der er tradition for, at man vurderer hver enkelt sag for sig.

På IT området kan der på samme måde gå lang tid med at diskutere konkrete løsninger, produkter og leverandører i hver enkelt anskaffelsessag, hvis man ikke på forhånd har taget stilling til, hvilke generelle krav og standarder, de nye systemer skal leve op til. Naturligvis kan man bare uddelegere beslutningen til en fagmand, som fx IT chefen. Men kan man nu være sikker på, at han vælger, som ledelsen ville have gjort? Eller vil han lade sine egne præferencer spille ind?

Så er det måske bedre at sætte sagen i udvalg, og bede om en indstilling fra en gruppe af interessenter? På den måde vil det helt sikkert koste endnu flere ressourcer, før beslutningen er truffet.

Hvis man vil økonomisere med ledelsesressourcerne, og sikre at beslutningerne bliver taget til tiden, er det nyttigt at være “på forkant”. Det betyder, at man i ledelsesgruppen formulerer (og godkender) principper, som definerer den “normale” afgørelse af ofte forekommende sager.

På den måde reduceres behovet for sagsbehandling i ledelsesgruppen, fordi mange spørgsmål kan afgøres administrativt udfra principperne. Men det udelukker jo ikke muligheden for, at den enkelte sag kan forelægges ledelsesgruppen, hvis der er grund til at fravige princippet – eller hvis princippet skulle trænge til en justering.

Mange principper kan defineres på baggrund af vigtige beslutninger, man tidligere har taget (og investeret mange kræfter i). Det er en udbredt praksis i den offentlige administration. Så hvorfor ikke bruge den samme metode, når vi taler om IT ?

Fordelen ved at benytte principper, er at man undgår at diskutere de samme problemstillinger igen og igen. Det betyder, at ledelseskræfterne kan frigives til ledelse.

Governance – hvad er det?

Den skærpede konkurrence i det globale marked stiller nye krav til virksomhederne. Hvor det før var nok at drive en sund forretning med gennemprøvede forretningsgange, er det nu nødvendigt at levere konstante forbedringer af effektiviteten og løbende fornyelse af produkterne.

Governance

Governance er populært sagt rammen for, hvem der bestemmer og hvem der skal betale.

Der er en stigende erkendelse af, at virksomhedens evne til forandring er tæt knyttet til IT systemernes fleksibilitet og evne til at understøtte de optimerede arbejdsgange på en effektiv måde. Derfor er ikke blot arkitekturen, men også styringsmodellerne for IT beslutningerne kommet i fokus.

IT-governance handler om at etablere en klar styringsmodel for IT beslutningerne, så de er koordineret med de forretningsmæssige beslutninger. IT-governance er en integreret del af virksomhedens corporate governance, og det er den øverste ledelses ansvar.

En velfungerende governance er en forudsætning for, at de gode intentioner i virksomhedens strategiske planlægning vil blive efterlevet i praksis. Virksomheder med en stærk governance er karakteriseret ved:

  • Topledelsen forstår, hvorledes IT skal bruges som strategisk værktøj i virksomhedens udvikling.
  • IT strategien er integreret med forretningsstrategien og afspejler de forretningsmæssige mål.
  • De overordnede principper for IT styring (fx arkitektur, sikkerhed og projektstyring) er vedtaget af firmaets direktion og kommunikeret til alle relevante ledere.
  • Virksomheden har lagt den overordnede styring af IT i hænderne på en styregruppe, hvor både forretningsledelsen og IT ledelsen er repræsenteret.
  • Der er etableret klare og effektive procedurer for planlægning, gennemførelse og opfølgning på resultaterne af alle større IT investeringer.

En stærk governance er en forudsætning for at opnå de forretningsmæssige fordele, som en god arkitektur giver. Mindre bøvl – mere bundlinie!

Levende arkitektur

Alt for mange arkitekturdokumenter samler støv på en hylde, selvom der er investeret betydelige ressourcer i at udarbejde dem. Den mest almindelige grund til at dokumenterne har mistet interesse, er at de ikke ajourføres tit nok, og at de derfor ikke er velegnede til at styre virksomhedens IT anvendelse i en omskiftelig verden.

Det er bekosteligt at udarbejde strategiske planer, og det kræver et betydeligt ledelsesengagement at føre dem ud i livet. Mange virksomheder (både offentlige og private!) har derfor fundet det tilstrækkeligt at udarbejde en ny arkitektur (eller en IT strategi) hvert femte år. Resultatet er desværre ofte, at planerne får en begrænset værdi, fordi virksomheden over en femårsperiode har udviklet sig betydeligt, mens nye IT standarder og produkter er kommet til.

Hvis arkitekturdokumenterne skal undgå at samle støv, skal de opdateres løbende i takt med de nye forretningsmæssige og tekniske trends.Det kan man opnå ved at koble dem til Standardkataloget, som giver online adgang til de seneste anbefalinger om åbne standarder. Og til  Principkataloget, som hele tiden er opdateret med Best Practice Principper for arkitektur og strategi.