ZEBRANET

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.

2. March 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.

6. January 2009

Desktop Arkitektur betaler sig godt

De fleste organisationer er omhyggelige med at vælge en hensigtsmæssig arkitektur for de centrale servere og systemer. Men i den modsatte ende af netværket – ude hos brugeren – får IT arkitekturen ofte mindre opmærksomhed. Det er en udbredt opfattelse, at pc’er er en forbrugsvare, der blot skal købes, tilsluttes og startes.

Men en standardiseret konfiguration af brugerens pc spiller faktisk en væsentlig rolle for IT systemernes forretningsmæssige værdi. Der er nemlig her, at tiden går til spilde, og data går tabt, når teknikken svigter, eller brugeren mister overblikket.

Standardisering

Først og fremmest  bør alle pc’er være konfigureret ens – eventuelt opdelt i 2-3 arkitekturtyper. Den ene type kan fx være en traditionel Windows pc med alle kontorapplikationer installeret lokalt, mens en anden kunne være en tynd klient, fx baseret på Citrix. Mange organisationer har desuden brug for en tredje type for mobile brugere. For hver standardtype er det vigtigt at følge fælles konfigureringsregler, fx for hvilke versioner og opdateringer der skal installeres af operativsystemet og de fælles applikationer.

Forretningsapplikationer

En del virksomheder benytter forretningsorienterede applikationer, fx fagsystemer som afvikles på centrale servere, men kræver en særlig klient på brugernes pc. Det stiller som regel meget specifikke krav til pc konfigurationen, ikke blot hvad angår installationen af speciel klient-software, men også når det gælder tilhørende lokale sw komponenter som fx Java, .NET eller lokale database systemer. Selv når forretningsapplikationerne er web-baserede, vil der være mange lokale browser indstillinger, der skal standardiseres.

Managed Client

Hvis man vil undgå at IT-support medarbejderne bruger masser af tid på at betjene de brugere, der har problemer, skal den standardiserede pc konfiguration indeholde en række værktøjer, som understøtter fjernstyring og opgradering af pc’en fra et centralt helpdesk. Her kan man spare rigtig mange supportkroner, men betingelsen er altså, at installationen er standardiseret, og at brugerens muligheder for al lave lokale ændringer i forhold til standarden begrænses.

Innovation og effektivitet

Der tales meget om, at innovationen i fremtidens virksomheder skal komme fra brugerne, som selv udvikler nye måder at løse deres opgaver på. Men det behøver ikke at stå i modsætning til standardisering af pc-arkitekturen. Opgaven er at give brugeren adgang til en samling robuste og velfungerende værktøjer på pc’en, uden at styre hvorledes brugeren skal arbejde.

 Download denne artikel som pdf.

30. May 2007

En business case for standarder

Strategiske standarder

Valget af standarder er forbundet med mange centrale beslutninger i udviklingen af arkitektur og strategi, fx hvad angår behovet for interoperabilitet mellem systemer, og ønsket om konsolidering af IT-infrastrukturen.

De fleste er enige om, at åbne standarder er grundstenen for en tidssvarende IT udvikling. Men for den enkelte virksomhed kan det være en stor udfordring at vælge de rigtige standarder, både når man selv planlægger at udvikle løsninger, og når man skal opstille kravene ved anskaffelse af standardsystemer.

Der er mange ting at tage hensyn til: Først og fremmest er det vigtigt at vælge standarder for teknik, data og processer, som både er modne, bredt understøttet af markedets produkter, og som kan forventes holde denne position i lang tid fremover. Der findes mange eksempler på standarder, som fik et kort liv, fordi markedets store spillere valgte dem fra: Se fx X.400 protokollen for email, som i 1996 blev valgt som standard for Statens E-post. Den har ikke mange tilhængere idag.

Ved standardvalget er det også vigtigt at se på, hvilket samspil, der er behov for mellem virksomhedens systemer og i forhold til eksterne samarbejdspartnere. Sådanne beslutninger er tæt koblet til virksomhedens enterprise arkitektur, altså den overordnede organisering af processer, informationer og it-løsninger. Standarderne skal ikke vælges fordi de er “rigtige”, men fordi de medvirker til at opfylde virksomhedens forretningsmæssige mål. Begrundelsen kan fx være, at en teknisk standard medvirker til at gøre infrastrukturen simplere og mere robust, eller at den logiske sammenhæng mellem systemer reducerer behovet for genindtastning af data og andre besværlige arbejdsgange.

Business Case

De fleste beslutninger om anvendelse af standarder, er kompliceret af, at der er så mange at vælge imellem, og at de økonomiske konsekvenser er svære at overskue. Her kan det være en hjælp at opstille en business case, hvor fordele og ulemper (omkostninger) belyses med et eller flere scenarier, så standardiseringen og det konkrete valg af teknologier og løsninger kan begrundes med tørre tal.

Arkitektens katalog

Som en hjælp til at koble principper og standarder i IT planlægningen har vi i EA Fellows Kataloget samlet og kommenteret en række af de mest anvendte IT standarder, og eksempler på konkrete arkitekturprincipper.

Business casen behøver ikke at komme ud af den blå luft. Den kan opstilles på grundlag af virksomhedens arkitekturprincipper, der fortæller, hvor en standardisering er hensigtsmæssig, og peger på de standarder, det er bedst at følge i den konkrete situation. Arkitekturprincipperne skal naturligvis være velbegrundede, hvilket betyder at de kan henføres til virksomhedens overordnede mål, og at konsekvensen af at efterleve principperne er beskrevet i praksis.

Når vi på denne måde kobler principper og standarder, får vi en IT-planlægning med de to egenskaber, som virksomhedens ledelse sætter allerhøjest: For det første er udviklingen forudsigelig og giver ingen ubehagelige overraskelser, og for det andet er den optimeret i forhold til virksomhedens behov.

 Download denne artikel som pdf.

10. September 2006