Executive Seminar med Chris Potts

EA Fellows bringer nu Chris Potts til Danmark, ikke blot for et foredrag, men med et 2-dages intensivt seminar for topledere og virksomhedsudviklere. Det sker den 21-22 januar 2010 i København.

Chris Potts er anerkendt som en af verdens skarpeste, når det gælder forretningsudvikling med IT. Han giver internationale topledere et nyt perspektiv på IT anvendelsen i deres virksomhed, med sit prisvindende executive seminar

Corporate Strategy for IT

How to turn business leaders into experts at exploiting technology

Vores verden er forandret. Forbrugerne, kunderne og samarbejdspartnerne er bedre end nogensinde til at udnytte teknologierne til egen fordel. Men mange virksomhedsledere tænker på IT som en omkostning, i stedet for at bruge teknologien som et værktøj til at udnytte markedets muligheder.

Dette seminar giver deltagerne værktøjer til at udvikle forretningen med systematisk innovation, og demonstrerer hvordan strategiske IT investeringer giver forretningsmæssigt udbytte. Chris vil guide os til at tage det næste trin fremad mod forretningens optimale udnyttelse af teknologien.

Seminaret indeholder ingen tekniske anbefalinger – det handler udelukkende om management. Deltagerne får konkrete værktøjer til at håndtere forandring, mennesker, investeringer, omkostninger og forretningsmæssige beslutninger, så virksomhedens resultater optimeres.

Mange tidligere deltagere har oplevet, at dette seminar har givet dem en helt ny opfattelse af, hvad Strategibetyder. Når man ser verden med strategens briller, i stedet for den tekniske eksperts, er det nemmere at se hvilke praktiske tiltag der har størst effekt.

Chris Potts benytter sine personlige erfaringer fra førende virksomheder over hele verden til at forklare, hvilke metoder, der virker, og hvilke man bør undgå. Seminaret indeholder cases, baseret på konkrete virksomheder, og anbefalinger som direkte kan overføres til deltagernes hverdag.

Om Chris Potts

Chris er forfatteren til ‘FruITion: Creating the Ultimate Corporate Strategy for Information Technology‘. Han har mere end 20 års personlig erfaring med styring af strategi, investeringer og arkitektur i verdens førende virksomheder.

Seminaret afholdes den 21 – 22 januar 2010 i den historiske Admiral Gjeddes Gaard.

ESDH høring igen

ITST har igen sendt specifikationerne for sag og dokumentområdet til offentlig høring, nu i en slankere udgave, hvor bl.a. en del elementer har skiftet status fra obligatoriske krav til optioner. Den arkitekturmæssige tilgang er dog uændret, og ambitionsniveauet for standardiseringen er fortsat meget højt, idet man beskriver grænseflader for alle systemer i den offentlige forvaltning, der vil tilbyde eller benytte dokumenthåndteringsfunktioner i et andet system. Det er altså ikke kun ESDH systemerne, der er målet for den nye standardisering, men hele samspillet mellem den offentlige forvaltnings systemer.

Vi anbefaler alle leverandører af fagsystemer, portaler og infrastruktur til den offentlige forvaltning at holde et vågent øje med de nye dokumentstandarder, for hvis OIO udvalget får magt som de har agt, vil specifikationerne indgå i de fleste offentlige udbudskrav allerede fra næste år.

EA Fellows har tidligere sat fokus på dokument standarderne i et høringssvar. Det blev fulgt op med en omtale af alle indkomne kommentarer.

I dette indlæg uddyber vi det første af vore kommentarpunkter, og bringer en lille vejledning, som fx kan bruges til at prioritere standardiseringsprojektets aktiviteter.

 

Hvad er formålet?

Hvad er det overordnede formål med standardiseringsinitiativet, har vi tidligere spurgt. Det er ikke så let at blive klog på, for der er ikke formuleret et operationel strategi for standardiseringsprojektet. Men læser man referencearkitekturen, og de enkelte specifikationers formål, kan man fornemme, at OIO udvalget for sags- og dokumentområdet har en vision om en mangfoldighed af systemer i den offentlige forvaltning, hvor alle systemer kan bytte roller og tilbyde funktionalitet til hinanden på kryds og tværs. Nøglen hertil er, at alle systemer har fået “monteret” et OIO-standardiseret interface.

Når alle systemer er “plug-and-play”, vil markedskræfterne råde, og hver myndighed kan vælge frit på alle hylder, når det gælder esdh- og fagapplikationer. OIO udvalgets vision synes at være, at en omfattende standardisering kan eliminere behovet for en systemarkitektur, både hos myndigheder og leverandører. Men det er nok et spørgsmål, om den standardiseringsstrategi passer lige så godt på den offentlige sagsbehandling, som den passer på et usb-stik.

Det kan undre, at IT og Telestyrelsen med sit standardiseringsarbejde søger at fremme en strategi, hvor funktionerne kan fordeles ad libitum på mange små systemer, mens Finansministeriet med Statens IT arbejder i den modsatte retning, frem mod en konsolidering af de offentlige kernefunktioner, for at hente stordriftsfordele.

Hvis de to initiativer var koordinerede, ville man kunne hente betydelige gevinster til det offentlige, fx ved at Statens IT tilbyder fælles services til sags- og dokumenthåndtering, og ITST definerer for myndigheder og leverandører, hvordan de skal anvendes. Både Statens IT og Finansministeriet er repræsenterede i OIO udvalget, så man har da lov til at håbe, at de selv vil få denne ide. Og den må meget gerne komme, inden leverandørerne tvinges til at implementere en masse funktioner og grænseflader, som kun et fåtal har brug for.

Hvad er det værd?

Hvis vi skal beskrive, hvordan en standardisering af ESDH-grænsefladerne kan skabe værdi i samfundet, vil det være naturligt at bruge klassiske metoder fra EA værktøjskassen: Vi starter med at se på de forvaltningsprocesser, der kan optimeres, og følger derefter sporet til IT løsningerne. Undervejs kan vi optimere de strategiske beslutninger omkring standardiseringens omfang, forløb osv., og hente vigtige input til at opstille en business case for standardiseringsprojektet. Vi kan fx starte med 5 simple spørgsmål som disse:

1. I hvilke scenarier kan standardisering gøre en positiv forskel?

Lad os få sat fingeren på konkrete offentlige opgaver, hvor arbejdsgangen kan lettes, når de underliggende IT løsninger bringes til at spille bedre sammen. Og på de situationer, hvor kørende systemer skal konsolideres, fx i Staten eller i kommunerne.

2. Hvilken konkret værdi vil standardiserede grænseflader bidrage med?

For de valgte scenarier ser vi nu på, i hvilken grad en standardisering af grænsefladen kan skabe værdi. Det kunne være besparelser ved at undgå genindtastning af data, eller bedre muligheder for at finde og sammenstille oplysninger på tværs af flere systemer. Husk , at alle værdielementer skal opgøres i en fælles valuta, DKK.

3. Hvilke investeringer og indsatser skal ydes for at opnå fordelene?

For at standardiseringen kan få den ønskede effekt, skal den jo også implementeres, både teknisk og organisatorisk. Hvad koster det, for myndighederne, for leverandørerne, for borgerne? Og hvordan skal de forskellige parter motiveres til at investere.

4. Hvilke forudsætninger skal være opfyldt for at gevinsten kan høstes?

En række konkrete faktorer skal være på plads for at sikre standardernes effekt, fx bagud-kompatibilitet, certificering af løsninger, implementering i fællesoffentlige registre, finansieringsmodeller, markedsforhold og meget mere. Vurderingen af disse faktorer bør omfatte både omkostninger og risiko.

5. Findes der alternative initiativer, som kunne give en tilsvarende eller større værdi?

Før standardiseringsprojektet iværksættes, skal vi lige sikre os, at den valgte strategi også er den bedste. Det kunne jo tænkes, at en stor del af værdien hidrører fra en lille delmængde af projektet – så man med fordel kunne reducere scopet. Det kunne også være, at eksisterende standarder var bedre end de nye fra ITST? Eller måske kan fordelene bedre nås gennem konsolidering af systemer, i stedet for standardisering?

Disse grundlæggende spørgsmål bør stilles og vurderes omhyggeligt, før man formulerer en strategi for standardiseringen af sags- og dokumentområdet, som jo er en vigtig del af den offentlige administration. Vi kan kun anbefale, at IT- og Telestyrelsen giver de strategiske spørgsmål en høj prioritet.

EA for Innovation

Det er ofte hævdet, at begreber som strategisk planlægning og overordnet arkitektur står i direkte modsætning til innovativ udvikling. Påstanden bygger som regel på en misforstået opfattelse af, at strategisk tænkning altid er en topstyret proces, der skal resultere i et ensartet og forudsigeligt resultat. Men sådan behøver det slet ikke at være.

EA som innovationsmetode

Enterprise Architecture (EA) er en anerkendt metode til at organisere en virksomheds processer, informationer og teknologier, så alle dele af virksomheden fungerer optimalt sammen og skaber de projekterede resultater. Kernen i EA metoden er at udvikle processer og teknologiske løsninger, med udgangspunkt i de strategiske mål. Denne tilgang er ikke blot velegnet ved udvikling af virksomheder, men er også yderst værdifuld ved udvikling af innovative produkter og services. Her sætter vi anvendelsesprocesserne i centrum, og maksimerer den værdi, produktet kan skabe hos kunden. EA metoden relaterer produktets egenskaber til værdiskabelsen, i stedet for at tage udgangspunkt i teknologien. Dermed sikres, at vi tænker “out of the box” og skaber nye løsninger, der opfylder de overordnede behov bedre end de eksisterende produkter og services.

En god strategi kan indeholde et sæt rammebetingelser, som skaber en platform for udviklingen, i stedet for at foreskrive, hvordan alle opgaver skal løses.

Enterprise arkitektur er en strategisk disciplin, der organiserer løsningens elementer, og sikrer at de spiller sammen om at opfylde de ønskede mål. Og det er jo netop hvad vi har brug for, når nye produkter og tjenester skal udvikles.

Hvis strategi og arkitektur formuleres som overordnede principper, bliver de værdifulde redskaber for den kreative opfinder. Her skal vi se på, hvorledes enterprise arkitekturen kan bruges i innovationens tjeneste.

Hvordan får man en god ide?

De fleste forbinder innovation med nye ideer og opfindelser, som pludselig opstår, når man mindst venter det, fx under en spadseretur i naturen eller mens man tager brusebad. Hvad er den bedste måde at få gode ideer på? Mange mener at omgivelserne er vigtige: Hvis man bevæger sig væk fra dagens rutineopgaver, kan man åbne for inspirationen, og nye indtryk kan give konkrete ideer til nye produkter og tjenester. Men det er meget individuelt, hvad der skal til for at fremme de gode ideer: Mange opfindere er faktisk mest kreative, mens de er i gang med at lave noget helt andet.

De fleste opfindelser starter med opdagelsen af et nyt behov – eller en ny måde at opfylde et gammelkendt behov på. Kravet er, at opfindelsen skal skabe værdi: Man skal kunne se, hvad der kan gøres bedre – eller man skal finde nye forretningsmodeller, der kan skabe et økonomisk potentiale.

Her kan man med fordel benytte begreber og koncepter som findes i EA værktøjskassen: Vi anbefaler ikke at følge en bestemt arkitekturmetode slavisk, men at plukke de relevante elementer efter behov. Fx kan man tage udgangspunkt i den proces, som man ønsker at forbedre, og gennemgå dens deltagere og interessenter, se på deres motiver og spørge, hvorledes processen skaber værdi. Så vil man ofte finde alternative måder at gøre tingene på, eller kunne se et oplagt behov for en opfindelse, der kan hjælpe i processen.

Gode enterprise arkitekter stiller ofte spørgsmålet “hvorfor”, når de skal sikre sammenhængen mellem en løsning, og det behov, den skal dække. Denne nysgerrighed er et af de vigtigste redskaber for opfinderen (og forskeren) , der ønsker at udvikle sine ideer.

Hvordan fører man ideen ud i livet?

Innovation kræver en balance mellem spontanitet og systematik. De vilde ideer skal parres med erfaring og sund fornuft, herunder en afvejning af ideernes værdi og en analyse af hvorledes de kan realiseres på den mest optimale måde. Til disse vurderinger, som gennemføres i de første faser af opfindelsens tilblivelsesproces, er det relevant at inddrage erfaringer med produkter, som er sammenlignelige med den nye ide – eller som bliver dens konkurrenter i fremtiden. Vurderingen kan iscenesættes som en systematisk proces, hvor man bruger klassiske metoder fra EA værktøjskassen. Det betyder fx, at man beregner, hvorledes opfindelsen kan skabe værdi for kunderne, og optimerer dens opbygning herefter. På denne måde kan man sikre at opfindelsen vil stå så stærkt i konkurrencen, at den automatisk bliver det foretrukne produkt for kunder, der har de samme værdibegreber.

En systematisk vurdering på dette tidspunkt kan med stor nøjagtighed beskrive opfindelsens potentiale, og med stor sandsynlighed eliminere de betydelige risici, der ligger i et fejlskøn. Det er som bekendt de fejltagelser, der begås i projektets første faser, der ender med at blive de dyreste.

At realisere en opfindelse kræver dog meget mere end en god og holdbar ide. Her kommer vi til det, der traditionelt kaldes “transpirationsfasen”, som indeholder en masse hårdt arbejde. Der skal endeløse forsøg , vurderinger og sammenligninger af alternative modeller til, for at finde den bedste løsning til at opfylde et konstateret behov. For hver ny løsningskomponent, for hver ny funktion og for hver ny egenskab i løsningen er det vigtigt at relatere den – dels til de kommende kunders behov og præferencer , og dels til de tidsmæssige og økonomiske konsekvenser, det vil have for projektet. Det er en klassisk EA disciplin.

Et vigtigt aspekt i design af løsningen er at identificere de komponenter, koncepter, metoder etc, som gør løsningen unik, og som kan beskyttes mod kopiering gennem hemmeligholdelse, patentering eller andre former for rettighedsbeskyttelse. Den samlede løsningsarkitektur bør udformes sådan, at de overordnede fordele ikke kan opnås af en kunde eller konkurrent, der ikke har adgang til de centrale komponenter.

Især i denne fase er det vigtigt at stille spørgsmålet “hvorfor” gentagne gange. For hvis løsningen ikke er optimeret benhårdt mod det behov, den skal opfylde, er det helt sikkert at dens liv vil blive kort. Det skal den globale konkurrence nok sørge for.

Hvordan sikrer man det forretningsmæssige resultat?

Når en ny ide (eller en forbedret gammel ide) skal omsættes til fordele og økonomisk værdi, er det naturligt at gennemføre en interessentanalyse, hvor man kortlægger hvad opfindelsen kan gøre for alle, der er direkte berørt af opfindelsen, fx kunderne, der skal købe og bruge opfindelsen, producenterne, der skal omsætte ideen til fysiske eller logiske produkter og services, og ikke mindst for opfinderen og eventuelle andre rettighedshavere. Denne analyse bør være grundlaget for de forretningsmodeller, man vælger, og den tilhørende strategi for opfindelsens produktion og udbredelse.

Parallelt med udviklingen af én eller flere prototyper, skal vi i gang med at designe og producere det færdige, salgbare produkt. Afhængigt af opfindelsens art skal der gennemføres forskellige former for koncept- og produktudvikling, teknologiudvikling osv. I denne fase møder vi en stor risiko for, at det endelige produkt ikke vil kunne give de forventede resultater, på grund af forsinkelser, tekniske udfordringer -eller fordi produktet “rammer ved siden af” det markedsbehov, man søger at opfylde.

En referencearkitektur er det vigtigste redskab til at sikre en sammenhæng mellem ide, koncept og det færdige produkt. Ved at definere rammerne for produktudviklingen som arkitekturprincipper, kan en klassisk EA model sætte rammerne for udviklingen, uden at definere alle detaljer i forløb og design. Det betyder blandt andet, at vi har frihed til at vælge udviklingsmetode og -værktøjer efter opgaven (fx Agile) , og at vi har fleksibilitet til at vælge eksterne underleverancer (sourcing) for at optimere planlægningen. Arkitekturprincipperne vil gennem hele forløbet sikre en velbegrundet sammenhæng mellem de strategiske pejlemærker og den praktiske implementering. På denne måde reducerer vi risikoen for at produktet flopper, og samtidig finder vi den billigst mulige løsning, der kan levere den projekterede værdi til kunderne, producenterne – og til opfinderen selv.

Innovation overalt

Det er ikke kun i små, teknologiske opstartsvirksomheder, at der er behov for en målrettet udvikling af nye ideer og en transformation fra koncepter til produkter. Også store, veletablerede firmaer møder hele tiden nye konkurrenter og nye markedstrends, som tvinger dem til at skrue op for innovationstakten. I den offentlige sektor er der ligeledes brug for fornyelse – her bruges ordet “modernisering” om den stærkt efterspurgte udvikling af nye elektroniske servicetilbud.

I alle situationer er det vigtigt at huske, at ny teknologi sjældent giver fordele alene: Der skal arbejdes med processer, data og IT-funktioner under én hat – og ikke sjældent skal de overordnede mål og regler tages op til revision, for at man kan skabe konkret værdi. Det er her, enterprise arkitekten er en nyttig rådgiver og hjælper for den innovation, virksomheden skal leve af i fremtiden.

Standardisering eller arkitektur? Begge dele, tak!

Efter sommerens høringskonference om de kommende ESDH standarder var deltagerne – og andre interessenter – inviteret til at indsende skriftlige kommentarer til de 5 specifikationer af forretningsservices, som skal supplere – og med tiden afløse – de eksisterende FESD standarder.

De indkomne høringssvar er nu publiceret her. Der er grund til at bemærke høringssvaret fra Region Midtjylland, som stiller spørgsmålstegn ved både Referencearkitekturen for sags- og dokumentområdet og ved selve standardiseringsprojektet. I høringssvaret underbygges kritikken med erfaringer fra en lang række offentlige myndigheders IT-implementering. Tankevækkende læsning!

En anden kættersk tanke er for nylig blevet luftet af Ole Bech på version2. Her debatteres, om vi overhovedet har brug for de store forkromede ESDH systemer i den offentlige forvaltning, eller vi ville være bedre tjent med at rive siloerne ned og lade informationen følge opgaverne.

Måske er det tid at genoverveje standardiseringsprojektets scope, retning og ambitionsniveau i forhold til de overordnede succeskriterier. Erfaringerne viser, at vi kan skabe mere interoperabilitet og effektivitet i de offentlige IT-løsninger, hvis vi lægger vægt på en fælles enterprise arkitektur, end hvis vi standardiserer alle de tekniske detaljer.

Standardisering af ESDH

I sidste uge var der høringskonference om ESDH standarderne. På bordet lå Referencearkitektur for sags- og dokumentområdet -en diger sag på næsten 100 sider, der bl.a. indeholder en nyudviklet begrebsmodel for den offentlige sagsbehandling. På konferencen fremlagde OIO udvalget for Sag og Dokument de (5) specifikationer af forretningsservices, som skal supplere – og med tiden afløse – de eksisterende FESD standarder.

Som nogen vil vide, var erfaringerne med FESD projektet noget blandede – et hovedformål var at skabe konvergens mellem markedets dokumenthåndteringssystemer, så de forskellige dele af forvaltningen kunne arbejde bedre sammen. Med IT- og Telestyrelsen i spidsen blev der standardiseret på livet løs -en lang række af systemernes funktioner og grænsesnit blev beskrevet i finurlige detaljer. Men i praksis var det så som så med kompatibiliteten – og med leverancernes kvalitet.

Nu spiller IT- og Telestyrelsen ud med et nyt sæt standarder. Denne gang er vi ikke begrænset til ESDH systemer, for standarderne skal også dække de mange fagsystemer der indeholder (eller benytter) ESDH funktionalitet. De nye standarder vil altså beskrive, hvorledes en meget stor del af systemerne i den offentlige forvaltning skal spille sammen.

På høringskonferencen var der flere deltagere, der var imponerede over dette meget høje ambitionsniveau. Vi var også nogle stykker, der var lidt bekymrede. For at hjælpe arbejdet lidt på vej, har EA Fellows skrevet en høringskommentar fra enterprise arkitektens synsvinkel.

Fra høringssvaret kan vi referere disse punkter:

1.      Forretningsmæssige begrundelser

En god arkitekturpraksis har til opgave at levere et velunderbygget beslutningsgrundlag for IT-investeringerne. Det betyder, at alle valg af løsningsmønstre og principper er begrundet i de opstillede mål, og at konsekvenserne er beskrevet, så det fx er muligt at opstille en business case for implementeringen af arkitekturen. Referencearkitekturen, som skal udgøre grundlaget for standardiseringen, har efter vor opfattelse ikke formidlet dette budskab klart nok. Dokumentet indeholder – i overensstemmelse med god praksis – afsnit om mål og visioner, forretningsservices og integrationsmønstre. Men disse afsnit er ikke systematisk kædet sammen, så man kan se begrundelsen for de trufne valg – og dokumentet indeholder i øvrigt ikke mange konkrete krav til arkitekturen. Således er de udmeldte principper henvist til et bilag, og er ikke relateret til hverken Referencearkitekturen eller Strategien for digital forvaltning. Vi anbefaler, at den næste version af referencearkitekturen udvikles til et mere komplet grundlag for ESDH udviklingen.

2.      Komplicerede grænseflader

Når målet er at opnå en bedre interoperabilitet, er det afgørende at der standardiseres på grænseflader i stedet for de indre strukturer, og de fremlagte specifikationer sigter da også i denne retning. Det er leverandørernes valg, i hvilken grad den indre struktur i databaser, programkode, etc. skal svare til det begrebsbillede, som de foreliggende specifikationer præsenterer. En gylden regel for standardisering af interfaces er imidlertid, at man kun skal medtage de parametre, der er nødvendige for at give forretningsmæssig værdi. Det er bekymrende, at specifikationerne ikke følger denne praksis, men i stedet lægger op til at eksponere en lang række interne parametre på grænsefladen. Erfaringerne fra en lang række cases viser, at den tilsigtede tætte integration ikke opnås ad denne vej, fx pga. manglende integritet i de udvekslede data. Desuden repræsenterer den tætte integration et brud på princippet om løs kobling, som det er udtrykt i referencearkitekturen. Vor anbefaling er at benytte de erfaringer, man fx har gjort i Norge, hvor overgangen fra NOARK-4 til NOARK-5 viser en tydelig flytning af fokus fra indre til ydre strukturer, og en simplificering af grænsefladerne, efter at man måtte konstatere at de komplicerede udvekslingsformater ikke gav de ønskede sammenhænge.

3.      Ambitionsniveauet

Både omfanget og antallet af de foreliggende specifikationer synes at være unødigt højt. Erfaringerne fra FESD1 viser tydeligt, at leverandørernes evne og vilje til levere et robust og kundetilpasset produkt vurderes højere af brugerne end muligheden for at få implementeret alle de fællesoffentlige standarder. Risikoen for at skabe et betydeligt gab mellem standarden og de konkrete implementeringer, bliver større jo mere der standardiseres. Vi kan derfor kun anbefale, at den obligatoriske standardisering holdes på et minimum, som kan give sammenhæng på udvalgte, centrale områder, og at de øvrige standarder bliver optioner, der kan tilvælges, hvis myndigheden har et forretningsmæssigt behov for en interoperabilitet, der går ud over der basale niveau. Hvis det høje ambitionsniveau fastholdes, er der risiko for, at myndighederne får en række specialudviklede (men stort set identiske) løsninger at vælge imellem, med dertil hørende negative virkninger for markedssituationen.

4.      Innovation

Flere steder i Referencearkitekturen understreges det, at IT udviklingen skal understøtte forandring i den offentlige forvaltning, og vi kunne ikke være mere enige. Men vi er samtidig bekymrede for, at den udbredte standardisering af arbejdsgange og løsninger på ESDH området vil begrænse moderniseringen af den offentlige sektor. Innovation handler primært om, at man tænker nye sammenhænge og nye processer, i stedet for at sætte strøm til de gammelkendte forvaltningsrutiner. En referencearkitektur der i vidt omfang bygger på eksisterende praksis, kan let komme til at modvirke nytænkningen. Vi kunne ønske os et større fokus på nytænkning og forenkling, og mindre vægt på automatisering af arbejdsgange, der allerede er komplicerede nok. En fremtidsorienteret arkitektur skal være udformet, så den kan understøtte nye og ændrede opgaver uden en større “ombygning”. Det betyder som regel, at arkitekturen skal være simpel og klart kommunikeret. Som et aktuelt eksempel kan nævnes, at en række forvaltningsmæssige opgaver i fremtiden forventes løst i et offentlig-privat partnerskab (OPP). Det ville derfor være hensigtsmæssigt hvis det offentliges ESDH systemer var gearet til at spille sammen typiske systemer i den private sektor, fx Customer Relation Management (CRM), Service Management etc.  En sådan fremsynethed kan opnås, hvis enterprise arkitekten spørger ind til begrundelsen for de udførte opgaver, og måden de udføres på. Det er her, innovationen starter og nye løsninger opstår. Modne organisationer har ofte succes med at orkestrere innovationen, fx ved at udskrive en konkurrence blandt medarbejdere eller belønne ledere der forenkler gammelkendte arbejdsgange eller udvikler nye services.

Læs de øvrige punkter om Privacy, Fællesoffentlig reference, Standardiseret infrastruktur, Scope, Roadmap og Governance her.

En business case for EA

Når der skal opstilles en business case for EA, er omkostningssiden klart den nemmeste af konkretisere: Mandtimer, konsulenter, værktøjer. Men hvordan opgør vi plussiden? Hvilke fordele kan vi opnå, og hvilken værdi skal vi tillægge dem? Her har vi samlet lidt inspiration til enterprise arkitekten, der skal argumentere for at indføre et EA program i virksomheden.

Enterprise arkitekturen giver virksomheden en række fordele, som alle rammer bundlinien – på kortere eller længere sigt. Hvis vi vil opstille en business case for EA programmet, som harmonerer med den traditionelle budgetstruktur, kan det være hensigtsmæssigt at opdele fordelene i to overordnede kategorier:

 Forretningsfordele

  • Bedre opfyldelse af strategiske mål
  • Forbedret forretningsmæssig performance

IT-fordele

  • Bedre IT understøttelse af forretningen
  • Reducerede IT omkostninger

I de næste afsnit ser vi på, hvorledes en god EA praksis kan resultere i direkte besparelse, ekstra fortjeneste eller andre forretningsmæssige fordele som kan bogføres under disse overskrifter.

Bedre opfyldelse af strategiske mål

Især når virksomheden står over for betydelige forandringer, vil en velkørende arkitekturproces have stor værdi: Når den overordnede styring af virksomhedens projektportefølje baseres på vedtagne arkitekturprincipper, får vi sammenhæng mellem strategiske mål og de konkrete initiativer. I praksis bidrager EA til

  • at foretage en hurtig justering – på et sikkert grundlag – af projekter i forhold til ændrede succeskriterier eller nye begrænsninger, fx ved skiftende markedsforhold
  • at opnå synergier mellem projekterne, fordi de bygger på fælles platforme, mønstre og kompetencer
  • at udnytte eksisterende erfaring med kendte komponenter og processer i stedet for at eksperimentere med ukendte løsninger
  • at standse eller afvise de projekter, som ikke understøtter de strategiske mål eller ikke er en god investering

Forbedringer som disse kan som regel mærkes som besparelser på udviklingsbudgettet, men den største værdi kommer helt sikkert fra virksomhedens forbedrede evne til at kunne navigere sikkert gennem skiftende udfordringer og realisere det forretningsmæssige potentiale som strategien indeholder.

Forbedret forretningsmæssig performance

I den daglige drift er der brug for en systematisk visualisering og analyse af virksomhedens forretningsinitiativer, så man løbende kan følge op på resultaterne. En god arkitektur sikrer, at det forretningsmæssige udbytte af virksomhedens produkter og services kan sættes i relation til deres underliggende komponenter. Med denne indsigt kan man træffe hurtige og sikre beslutninger om hvilke ændringer der skal til i systemer og processer for at optimere de forretningsmæssige resultater. En god arkitektur giver fx mulighed for:

  • Eliminering af dublerede funktioner og løsninger, fx fakturering, CRM, mm
  • Identifikation af flaskehalse og afhængigheder mellem systemer og processer
  • Håndtering af forretningsmæssige muligheder og problemer tidligere i forløbet
  • Nemmere projektstart ved brug af overordnede EA principper i projektbeskrivelsen
  • Optimering af virksomhedens produktportefølje med konsoliderede erfaringer fra alle komponenter

Når kravet er at skabe resultater på bundlinien, er det vigtigere end nogen sinde at resultaterne direkte kan henføres til de beslutninger der tages i den daglige drift, og at udbyttet løbende optimeres ved at anvende  de bedste løsninger, metoder og værktøjer.

Bedre IT understøttelse af forretningen

Effektiviteten af IT anvendelsen skal måles gennem de forretningsmæssige resultater. En af de vigtigste faktorer er her, hvor godt IT komponenterne leverer værdi i de forretningsmæssige arbejdsgange, og det er er netop dette forhold, enterprise arkitekturen står for at optimere. Med en god alignment (tilpasning) mellem forretning og IT opnår vi det største udbytte af IT-investeringerne. I virksomheder der har en god praksis for IT understøttelse, finder man disse positive virkninger:

  • Færre ændringer i de kørende systemer som følge af oversete eller ændrede behov
  • Sikkert valg af komponenter der matcher veldefinerede operationelle krav
  • Systemer med standardiserede grænseflader reducerer behovet for special udvikling af integrationer
  • Hurtigere designcyklus for nye løsninger til forretningen ved genbrug af IT-komponenter
  • Reduceret risiko for fejl og nedbrud ved brug af velkendte services og komponenter

Den samlede effekt er ikke blot positiv i IT afdelingen, hvor man opnår hurtigere udviklingstid og færre rettelser. Forretningen oplever, at gevinsterne ved IT understøttelsen kan høstes tidligere, fordi IT-komponenter og arbejdsgange passer sammen fra starten. I tilgift får vi en større omstillingsevne (agilitet) for forretningsudviklingen, fordi udvikling og udbygning af modulære systemer er en langt hurtigere vej end “at starte fra bunden”, når et nyt forretningsprodukt skal understøttes med IT.

Reducerede IT omkostninger

En vigtig faktor i omkostningerne til udvikling og drift af IT løsninger er kompleksitetsgraden. Det er en velkendt sandhed, at organisationer som driver en portefølje af komplicerede IT løsninger, belastes af ekstra omkostninger, både til udvikling, drift og vedligehold, og har samtidig en forøget risiko for ustabilitet og nedbrud. Hvis man derimod satser på konsolidering af IT-infrastrukturen og udvikling af fælles standardiserede IT services, kan man opnå fordele på følgende punkter:

  • Reducerede udviklings- og test omkostninger ved at implementere fælles IT- komponenter
  • Højere driftsstabilitet, og nemmere fejlretning med færre forskellige platforme
  • Reducerede omkostninger til systemforvaltning, pga. af lavere kompleksitet
  • Eliminerer behovet for vedligehold af dublerede data, systemer og services

Når vi ser på de fordele, der kan hentes i IT driften, har en god arkitekturpraksis et stort potentiale. Men også i forbindelse med udvikling og opgradering, er der penge at hente, fordi en standardiseret infrastruktur, og faste principper for brug af standardsystemer og egenudviklede systemer, giver hurtigere implementering og mindre risiko. Her er de punkter, hvor en fælles arkitektur kan give fordele:

  • Konsolidering af platforme og værktøjer sparer omkostninger til drift og overvågning
  • Standard mønstre giver hurtigere og nemmere opbygning af nye driftmiljøer
  • Velstrukturerede platformskrav giver mulighed for selektiv outsourcing

Både ved intern drift og ved outsourcing, bør en løbende forbedring af price/performance være en del af driftsaftalen. Det kan realiseres, hvis IT miljøet opbygges efter moderne arkitekturprincipper, hvor en stigende automatisering af driftsrutinerne er et af de overordnede principper for samarbejdet.

Sådan sikres gevinsten

Ved opstilling af business casen, skal potentialet for hvert punkt vurderes individuelt i den enkelte virksomhed. Som bekendt skal forbedringen altid måles ud fra det aktuelle niveau, og her kan en uvildig vurdering være til stor nytte.

Ved realiseringen af de potentielle gevinster spiller det en stor rolle, at virksomheden tager hensigtsmæssige beslutninger gennem hele processen. EA er jo kun en metode til at tage gode strategiske valg – EA kan ikke garantere at virksomhedens ledelse omsætter anbefalingerne til action. Det er jo det, der skal til for at høste gevinsten.

For at virksomheden kan styre hurtigt og sikkert, på et solidt, strategisk grundlag, skal beslutningsmekanismerne være velfungerende. God governance er karakteriseret ved, at de rigtige personer (interessenter) er involveret i beslutningsprocessen, og at de har et fælles værdisæt at arbejde ud fra. Når de får et solidt beslutningsgrundlag, som EA programmet kan levere, er det faktisk ikke så svært at tage rigtige og sikre beslutninger.

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.

Digitalisering på tværs

Når den offentlige sektor skal arbejde bedre sammen, spiller teknologien en væsentlig rolle. Det gælder om at dele informationer og at samordne brugen af IT. I arkitektursammenhæng betyder det at rive siloerne ned og skabe en fælles infrastruktur, som fundament for forvaltningens fagsystemer.

Staten har taget et væsentligt initiativ i denne retning med dannelsen af den nye organisation Statens IT. Der er defineret et scope for Statens ITs opgaver men vi har endnu ikke et klart billede af, hvilken grad af harmonisering og konsolidering af systemer og infrastruktur, der er på tegnebrættet.

I mellemtiden har virksomheden Informi GIS givet et bud på, hvad den fælles infrastruktur bør indeholde. Geografisk information udgør en værdifuld fællesnævner i mange offentlige og private forretningsprocesser. Virksomheden illustrerer i et whitepaper Geografisk information i en enterprise arkitektur, hvorledes en geografisk tilgang kan fungere som løftestang for effektivisering, kvalitetsforbedring og styrket samarbejde i den offentlige sektor.

GIS systemer har traditionelt været betragtet som et fagsystem, som mest anvendes i tekniske forvaltninger til administration af veje, kloakker og byggetilladelser. Men ved at gøre de geografiske informationer tilgængelige som en infrastrukturservice, kan de bruges i mange andre sammenhænge, fx ved dynamisk styring af energi og offentlig transport. Det giver store perspektiver for tilrettelæggelsen af den offentlige service, og ikke mindst for samarbejdet mellem offentlige og private organisationer.

Vi venter spændt på at se, hvilke værdiskabende services der i fremtiden skal indgå i den fælles offentlige IT infrastruktur. GIS er et godt bud – hvem kommer med det næste?

Disclaimer: EA Fellows har bidraget med inspiration til publikationen fra Informi GIS.

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.

Supertanker eller optimistjoller?

I lyset af den skare af nyheder om offentlige it-projekter, der forsinkesfordyres eller på anden måde forringes, vi for tiden får nys om, så er det vel naturligt, at spørge sig selv om den måde vi planlægger og udfører vores store offentlige IT-projekter overhovedet er i tråd med hvordan man bedst udvikler løsninger? Og hvad med det samlede billede? – er der tænkt på hvordan man går fra strategi til specifikation af de byggeklodser der skal indgå i løsningskomplekset ?

For at starte i omvendt rækkefølge, så er der desværre noget der tyder på at vi endnu ikke har lært af Amanda og alle de andre dødssejlere der er blevet søsat i tidens løb.

Nye udbud dukker hele tiden op, hvor digitale supertankere ladet med et utal af komplekse teknologier skitseres og kastes i hovedet på de forsvarsløse leverandører, der føler sig forpligtede til at byde uanset hvor ækel den digitale mutant ser ud.

Løsningerne har ændret form over de seneste år fra de let forsimplede “strøm på blanketterne” udbud til de mere gennemgribende ændringer i arbejdsgangene ved indførelse af digitalisering, med en øget grad af automatisering via straksafgørelser mv. som følge.

Dette koblet med input fra mange fantasifulde konsulentfirmaer, der frit fortolker begreber som “åbne standarder” og OIOs hvidbog på hver deres kreative måde. Dette resulterer ofte i et væld af erklæringer om, at den intetanende leverandør skal leve op til snart sagt alle gældende standarder indenfor sikkerhed, Web Services og workflow.

Læg hertil et forhåndskrav fra kunden/konsulenten om, at leverandøren SKAL benytte en given proprietær infrastruktur til at implementere en fleksibel og åben løsning, og resultatet bliver den største selvmodsigelse man kan forestille sig.

Deadlines og økonomi er ofte også stramme, men man kan sige at det ligger i projektformens natur at man skal blive enige om disse ting ved starten, i stedet for at arbejde iterativt frem mod at løse det faktiske behov . Vi ser mange kontrakter, der indgås på et urealistisk grundlag. Hellere søge tilgivelse for forsinkelser end fortabe sig i forhandlinger, virker være logikken.

Nytænkning tak

Der er behov for nytænkning af den måde vi beslutter hvilke både vi vil have sat i søen i det offentlige digitale rum. Det nytter ikke noget at bygge en supertanker, hvis man blot skal krydse Gudenåen! Man skal måske tænke mere i brug af optimistjoller, hvis vi nu skal fortsætte på (dybt) vand – og så løse problemerne i små isolerede klumper i stedet for udfra en veltilrettelagt sejlrute og letfattelige samspilsregler.

Det kræver betydelige arkitektur-skills hos opgavestilleren, når man skal “hjemtage ansvaret for arkitekturen”. Og den kompetence findes sjældent hos kunden eller hans konsulenter i vore dage. Når de alligevel prøver, bliver det ofte en svær opgave for leverandøren – og en dårlig løsning.

Der er brug for en opsang. To gange endda: Først og fremmest til kunden for at stille krav om noget han ikke har forstand på. Men dernæst også til leverandøren for at byde på noget han ikke kan/bør levere, hvis han skal stå inde for løsningen med sin faglighed.

Men det er jo ikke blot fordi begge parter er dumme. Problemet opstår tit når de ikke kan finde deres plads i arkitekturprocessen, og at partnerne ikke kan finde ud af at fokusere på det de er bedst til: Dybest set at kunden kan sin forretning, og leverandøren kan sine løsninger og teknologi. Vi plejer at kalde det for “Danske Bank-modellen”: Hver part gør, hvad de er bedst til.

Det er ikke kundens opgave at stille detaljerede tekniske krav, for det er ikke her, han har sin styrke. Og det bør tilsvarende ikke være leverandøren rolle at definere kundens vision og målsætninger. På hvert niveau skal der være en arbejdsdeling, der svarer til parternes forudsætninger (og interesser), og en tilsvarende ansvarsfordeling.

Hvis kompetencerne som udgangspunkt er anderledes fordelt blandt parterne, så er det det der skal rettes op på – fx med styrkelse af kundens proces-udviklingsevne. Men det ville da også være forfriskende med en leverandør, der afslog at afgive bud med henvisning til at den ønskede tekniske arkitektur er uegnet, men at man gerne vil hjælpe med at udvikle et bedre alternativ …

Udfordringen er at få sigtelinierne fra strategien til at ramme rigtigt på de konkrete implementeringer i virkelighedens verden. Der er desværre ofte en tydelig “missing link” mellem strategien og projekterne. Kunden stiller nemlig ikke krav (især til sig selv) om, at projekterne reviewes med fokus på alignment, hverken før, under eller efter implementeringen.

Og hvad kan vi så gøre ved det? Tja, man har jo længe forsøgt sig med trylleformularen “business case”. Men det opfattes vist af de fleste myndigheder som en teoretisk tvangsøvelse, man skal igennem for at kvalificere et projekt til at få en bevilling, ikke som et aktivt styreredskab. Vi har i hvert fald endnu ikke mødt et offentligt projekt, hvor strategi, business case, udbudsmateriale og kontrakt hænger logisk og økonomisk sammen.

Et bedre udbud

Det er på tide at gøre op med de traditionelle fejltagelser, som silotænkning, proprietær infrastruktur, specialudviklede standardløsninger, osv. Vi har brug for et rammeværk for udbudsprocessen, der følger god EA praksis, og lægger vægt på randbetingelser, sigtelinier, risikostyring og økonomi. Det skal selvfølgelig passe sammen med K1 og K2, ITSTs arkitekturkrav, B103 standarderne og den digitale strategi. Idéen er at hjælpe opgavestilleren til at besvare en række spørgsmål som afgrænser opgaven, definerer forudsætningerne og beskriver de succeskriterier, som samarbejdet med leverandøren skal opfylde.

Hvis en sådan model blev obligatorisk for udbud over en vis størrelse (og for systemer med en central placering i digitaliseringen), kan der skabes overblik over de mange projekter, enten gennem tvungen rapportering opad, eller bare ved gennem åbenhed at synliggøre, om de lokale projekter er alignet med strategien.