ZEBRANET

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:

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.

 Download denne artikel som pdf.

Artiklen findes under: Arkitektur, Strategi og ledelse

Tags: Design, Enterprise Arkitektur, Innovation, Modernisering

14. August 2009

Styr sikkert gennem krisen

Finanskrisen er over os, og virksomhedslederne er på jagt efter områder, hvor der kan spares. Men i en moderne virksomhed er der stærke afhængigheder mellem processerne og de IT systemer, der støtter dem. Det er blevet sværere at spare i virksomheden, uden at skade den langsigtede overlevelsesevne.

Hvordan styrkes virksomhedens økonomiske modstandskraft?

I gode tider er det naturligt at der samler sig lidt “fedt” i organisationen: Ikke alle investeringer bliver vejet og vurderet i dybden, når midlerne er til rådighed, og fordelen er åbenbar. Derfor vil det altid være muligt at finde “lommer” i virksomheden, hvor unødvendige omkostninger kan elimineres.

På IT området har de fleste virksomheder opnået væsentlige effektivitetsforbedringer gennem de seneste 8-10 år, gennem styring af applikationsporteføljen, optimering af infrastrukturen, konsolidering af systemer og ved outsourcing af opgaver, der bedre og billigere kan varetages af specialiserede organisationer. Der er med andre ord ikke mange besparelser at komme efter, hvis ellers IT direktøren har løst sine opgaver professionelt.

Samtidig er der sket det, at integrationsgraden er blevet markant større. Gennem mange år har man stræbt efter at få virksomhedens IT systemer til at hænge bedre sammen, og efter at støtte stadig flere forretningsprocesser med IT-løsninger. Det har givet større effektivitet, men det betyder også, at det kan være farligt at tage bestemte IT funktioner ud af drift, fordi en række andre systemer og funktioner er afhængige af dem.

Derfor er det i en moderne virksomhed ikke hensigtsmæssigt at skære ned efter grønthøster-metoden - der skal smartere metoder til.

Skal vi spare eller hvad?

Når virksomheden skal bringes sikkert gennem en markedsmæssig krise, er den oplagte reaktion at skære ned på de faste omkostninger - og herunder at tilpasse arbejdsstyrken. IT omkostningerne regnes traditionelt for administrative omkostninger, og står ofte i skudlinien, når der skal spares.

Men lad os lige se på, hvad IT omkostningerne består af. Overordnet kan man dele IT-budgettet op i 3 dele: 

• Den første del er rene driftsomkostninger, som er forbundet med de systemer som støtter virksomhedens forretningsprocesser
• Den andel del er forvaltningsomkostningerne, som bl.a. indeholder fejlretning og løbende forbedring af de kørende IT løsninger
• Den tredje del omfatter etablering af nye løsninger, ofte organiseret som projekter

Driftsomkostningerne består overvejende af faste omkostninger og allerede foretagne investeringer. En nedskæring her vil som regel medføre ringere serviceniveau og højere risiko for nedbrud. Forvaltningsomkostningerne kan i højere grad justeres efter situationen, idet man kan afveje behovet for “bessermachen” i forhold til omkostningerne. Projekterne, som skaber nye løsninger bør naturligvis prioriteres efter den værdi, de skaber.

Det er langtfra sikkert, at nedskæringer alene er redningen. Måske skal der både spares og investeres på samme tid. Formålet er jo at forbedre bundlinien, og her kan målrettede investeringer give bedre resultater end nedskæringer. Analyser fra anerkendte rådgivere som McKinsey og Gartner, viser at de fleste virksomheder har et stort potentiale for at forbedre effektivitet og indtjening med små, strategiske IT forbedringer.

Når forretningen og IT sammen ser på firmaets processer, vil de finde tiltag med 10 gange større potentiale (virkning på toplinie og bundlinie) end simple nedskæringer. Fx kan man optimere udbyttet af virksomhedens data (om kunder, konkurrenter, markedspriser etc.) ved at sammenkoble eksisterende informationer, så de giver grundlag for bedre indtjening. Eller man kan eliminere flaskehalse og manuelle procedurer i produktion og logistik, så effektiviteten får et hak opad.

Initiativer, hvor begrænsede IT investeringer hurtigt kan forbedre indtjening og effektivitet, findes ofte på disse områder:

• Dynamisk styring af salg og prissætning
• Optimering af produktion, indkøb og sourcing
• Forbedring af supportprocesserne for at få mere loyale kunder
• Erstatning af langsigtet styring med mere direkte opfølgning på resultater

Ikke mindst beslutningsprocesserne er vigtige: Hvis virksomheden har en velfungerende governance struktur for styring af forvaltningsaktiviteter og projekter, er der ingen grund til at sætte den ud af kraft i krisetider. Her er det yderst relevant at kunne tage hurtige og sikre beslutninger, og at benytte opdaterede kriterier for prioritering af de enkelte investeringer. Og hvis man ikke allerede har en god beslutningsmekanisme for IT investeringer, så er det på høje tid at få den etableret! 

Hvad skal ledelsen gøre?

Se på virksomhedens processer og vurder hvor IT kan skabe større værdi ved at

• finde og eliminere kostbare flaskehalse i produktion og logistik
• finde manuelle rutiner som kan let kan automatiseres
• finde fejlkilder som kan elimineres gennem it-kontroller
• stille bedre informationer til rådighed for processens deltagere
• reducere kompleksiteten af procesforløbet og de behandlede data
• etablere nye processer til at systematisere “tilfældige” opgaver

 Analyser virksomhedens data for at finde muligheder for

• at forøge indtjeningen uden at hæve priserne
• at skabe større kundetilfredshed og loyalitet
• at styrke salget med værdibaserede bonus-modeller
• at få et bedre grundlag for strategiske og taktiske beslutninger
• at optimere forretningsmodeller og policies til den nye situation
• at sammenkoble datasiloerne for at skabe ny viden
• at finde dublerede og unødvendige informationer

Finanskrisen varer helt sikkert ikke evigt - men det er afgørende for virksomheden at komme godt igennem denne periode, hvor de gamle markedsmekanismer er erstattet af et nyt sæt spilleregler, hvor tilpasningsevnen er sat i højsædet. De virksomheder, som kan justere forretningen til de nye tider, vil komme styrket ud af krisen.

 Download denne artikel som pdf.

Artiklen findes under: Strategi og ledelse

Tags: Besparelser, Effektivitet, Finanskrise, Investering

2. Marts 2009

Netværket er livsnerven

I gamle dage var det mest de verdensomspændende analysefirmaer, der gennem deres kunde- og leverandørforbindelser samlede viden fra nær og fjern. Og tog sig godt betalt for at formidle denne viden videre. I dag er det blevet nemmere at finde opdateret viden - og relevante personer - takket være de mange internetbaserede tjenester. Det betyder at de mindre rådgivere kan matche de store, når det gælder strategisk rådgivning. Hvis de vel at mærke forstår at udnytte deres netværk.

I Zebranet har vi en mangeårig tradition for at netværke med institutioner, virksomheder og enkeltpersoner. Det giver os mulighed for at levere balancerede og ajourførte anbefalinger til vore kunder. Vores aktive netværk omfatter bl.a. følgende organisationer:

• RISKnet - et netværk af nordiske eksperter i IT sikkerhed
• PEP-NET - et stort europæisk netværk for udvikling af e-demokrati
• EA Fellows - en tænketank for Enterprise Arkitektur
• Privacyforum.dk - et websted med holdninger og fakta om privacy
• Rådet for Organisation og IT - en uafhængig tænketank for god IT praksis

Læs mere under Netværk i menuen til højre…

Artiklen findes under: Netværk

Tags: e-Demokrati, Enterprise Arkitektur, Privacy, Sikkerhed

15. Januar 2009

Arkitektur for agile projekter

Agile udviklingsmetoder har været i brug i mere end et halvt århundrede. Men i 1990′erne accelererede anerkendelsen af den iterative softwareudvikling, og en række forskellige agile “opskrifter” blev udviklet, fx Extreme Programming, SCRUM, DSDM og mange andre. Det er et fællestræk for disse metoder, at software løsningens egenskaber specificeres og implementeres løbende i tæt samarbejde mellem forretning og udviklere, og at udviklingsforløbet er opdelt i korte trin, som hver resulterer i levering af konkret funktionalitet.
 

I 2001 mødtes skaberne af mange forskellige agile udviklingsmetoder, og definerede et fælles grundlag for agil udvikling i Manifesto for Agile Software Development. Her fremhæves værdien af den personlige interaktion i teamet, demonstration af konkrete funktioner, samarbejde med kunden, og evnen til at håndtere forandring i udviklingsforløbet. Manifestet suppleres af en række principper for agil softwareudvikling, som primært adresserer værdier, processer og roller i samarbejdet.

De agile udviklingsmetoder blev opfundet i erkendelse af, at den traditionelle vandfaldsmodel let kommer til kort, når opgavestilleren ikke er i stand til at specificere løsningen ved projektets start, eller når forudsætningerne ændrer sig, så de stillede krav - og løsningen- må justeres. Vi bliver jo alle klogere i projektets forløb, og de agile metoder tager hensyn til dette ved at sætte tilpasningsevnen i højsædet, en lille smule ligesom Darwin gjorde det.

Når et projekt følger en agil udviklingsmodel, er den væsentligste fordel, at man kommer hurtigere i gang med at programmere, og dermed på et tidligt tidspunkt får indhøstet nogle af de erfaringer, der manglede ved projektets start. Dermed tackler man risikoen for at spilde ressourcer på at lave noget der ikke er holdbart - eller som der slet ikke er brug for.

Men til gengæld har den agile udvikling andre indbyggede risici: Når man fx vælger standarder og teknologier, inden den samlede løsning er beskrevet, kan man nemt komme ud for, at det bliver svært at opfylde de stillede krav på den valgte platform. Og når løsningen kun i meget begrænset omfang dokumenteres, kan det blive besværligt at drifte og vedligeholde softwaren, efter at udviklingsteamet  er draget videre til nye, spændende projekter.

Derfor kan det være hensigtsmæssigt at kombinere en agil udviklingsmetode med en række principper, som definerer rammerne for udviklingsprojektet. Her tænker vi først og fremmest på de overordnede arkitekturprincipper, som beskriver de forretningsmæssige og tekniske rammer, man har valgt at arbejde inden for. Det kunne fx handle om:

1. Forretningsmæssige forudsætninger og mål, herunder målbare succeskriterier
2. Hvordan løsningen indgår i forretningsprocesserne, og hvilke fordele den skal give
3. Hvilke data der skal behandles i løsningen og hvordan de skal være organiseret
4. Løsningens funktionelle afgrænsning i forhold til andre systemer i virksomheden
5. Hvilke teknologiske platforme skal løsningen køre på og hvorledes skal den indpasses i infrastrukturen

Ved at fastlægge rammerne i principform, giver man frihed til den kreative iteration, som bærer udviklingsprocessen. Men samtidig sparer man også en masse tid til fx afprøvning af alternative teknologier eller til at diskutere scope og integration i forhold til omgivelserne. Arkitekturen er en fælles referenceramme, der understøtter hurtig udvikling, netop fordi den definerer frihedsgraderne i hittepåsomheden, og hjælper til at opfylde nye krav med allerede eksisterende praksis og komponenter.

Foruden arkitekturprincipperne kan det være nyttigt at fastlægge andre rammebetingelser for udviklingsprocessen, fx budgetmæssige krav, og krav til den dokumentation der skal følge med løsningen ved aflevering og idriftsættelse. Der kan også være behov for at koordinere projektets forløb i forhold til dets omgivelser - her kan man med fordel se i retning af PRINCE2 for at hente inspiration.

Men til syvende og sidst er valget af projektmodel et spørgsmål om at afveje virksomhedens behov for agilitet mod behovet for styring og kontrol. Og at indregne både virksomhedens og projektets forudsætninger i overvejelserne.

Hvad taler for valget af agile metoder/elementer

• Projektet er ikke kritisk for virksomheden
• Udviklere med høj erfaring
• Kravene til løsningen skifter ofte
• Antallet af udviklere er lavt
• Virksomhedskulturen trives med kaos

Hvad taler for valget af planlagt/styret metode

• Projektet er kritisk for virksomheden
• Udviklerne er nye eller uerfarne
• Kravene er velkendte og faste
• Projektet involverer mange udviklere
• Virksomhedens kultur er baseret på orden

For mange virksomheder vil det være relevant at inddrage elementer fra både de agile modeller og fra de traditionelle, kontrollerede forløb, som scorer højt på Carnegie Mellon Universitetets CMMI model. For en virksomhed med flere (mange) projekter er det oplagt at følge en projektmodel, som er fleksibel. Det kan fx realiseres med tilvalg/fravalg af de enkelte elementer, baseret på de konkrete behov i det enkelte projekt.

 Download denne artikel som pdf.

Læs mere her:

Kelly Waters blog: All About Agile.

Software Engineering Institute: CMMI or Agile: Why Not Embrace Both.

Craig Larman & Victor R Basili: Iterative and Incremental Development: A brief History.

Artiklen findes under: Arkitektur, Strategi og ledelse

Tags: Agile, Effektivitet, Enterprise Arkitektur, Innovation

6. Januar 2009

Fra strategi til projekter - med PMO

Projekter findes i de fleste virksomheder - for det er meget almindeligt at organisere afgrænsede opgaver på denne måde, hvad enten det handler om udvikling af et nyt produkt, anskaffelse af en ny IT løsning eller en uddannelseskampagne for virksomhedens medarbejdere.

Formålet med projektformen er at gennemføre aktiviteterne i det enkelte projekt i en hensigtsmæssig orden, og med styr på tid, kvalitet og risiko. Det kan opnås ved at bruge en anerkendt projektmodel som fx PRINCE2 til at definere rammerne for projektets gennemførelse, og ved at engagere en projektleder, der forstår at benytte modellen i praksis.

Men sammenhængen mellem strategi og projekter kommer ikke af sig selv. Vi ser desværre mange eksempler på organisationer, der har en fin og pompøs strategi for virksomhedens udvikling (og IT anvendelse), men alligevel søsætter projekter på stribe, uden at demonstrere hvorledes de understøtter strategien.

The Missing Link

I sådanne tilfælde er der en missing link mellem strategiens højtflyvende målsætninger og succeskriterierne for det enkelte projekt. Det kunne være fordi strategien ikke indeholder en konkret vision for virksomhedens udvikling. Men i de fleste tilfælde er det faktisk fordi styringen af de mange projekter ikke er koordineret i forhold til de overordnede prioriteter.

Det er organisering, der skal til - på flere fronter: 

• For det første skal vi sørge for at strategien er forbundet til virkeligheden, ved at virksomhedens budget og økonomistyring afspejler de strategiske mål. Hvis der skal investeres i ny udvikling, skal der være penge til det. Og når projekternes resultater skal gøres op, fx som effektivisering eller mersalg, skal det indgå i den økonomiske opfølgning.
• For det andet skal den overordnede styring af projektporteføljen, også kaldet programstyringen, være lagt i hænderne på en ledergruppe på topniveau, som har kompetence til at prioritere indsatsen og tager ansvar for at styre porteføljen af projekter frem mod de fælles strategiske mål.
• Programstyringens opgave er at omsætte strategiens mål til konkret handling, herunder at iværksætte korrigerende handlinger, hvis forløbet af et enkelt projekt ikke er alignet med de strategiske mål. Styregruppen skal derfor have adgang til et retvisende billede af den aktuelle situation, med hensyn til ressourcer, fremdrift, kvalitet og risiko i det enkelte projekt. Det kræver at virksomheden har en fælles metrik for disse nøgleparametre - og en proces for rapporteringen.

Mange virksomheder har allerede valgt at oprette et Program Management Office (PMO), som har til opgave at understøtte de 3 nøgleopgaver ovenfor. Det betyder at PMO konsoliderer projekternes rapportering, fungerer som sekretariat for styregruppen, og ser til, at beslutningerne føres ud i livet.

Hvis organisationen har behov for at udvikle sin modenhed i projektudførelsen, kan PMO desuden have som opgave at bistå projekterne med metoder, værktøjer og review af projektforløbet. På den måde kan man opnå både et strategisk løft og en bedre praksis i udviklingen.

 Download denne artikel som pdf.

Artiklen findes under: Strategi og ledelse

Tags: PMO, PRINCE2, Projektledelse

27. Juli 2008