30/04/2019
I den moderne forretningsverden står IT-afdelinger over for et konstant pres for at levere værdi, drive innovation og samtidig opretholde stabile og pålidelige systemer. Mange organisationer finder, at deres traditionelle, silo-baserede IT-struktur, ofte kaldet tårnmodellen, ikke længere er tilstrækkelig til at imødekomme kravene om hurtighed og fleksibilitet. Som svar på denne udfordring har en mere procesorienteret tilgang vundet frem: Plan-Build-Run (PBR) modellen. Denne model sigter mod at omstrukturere IT for at skabe klarere ansvarsområder, forbedre effektiviteten og bedre tilpasse sig virksomhedens strategiske mål. Men en vellykket overgang kræver mere end blot en omorganisering; den kræver en dyb forståelse af modellens principper og en omhyggelig implementering.

Hvad er Plan-Build-Run-rammeværket?
Plan-Build-Run-modellen opdeler grundlæggende IT-organisationen i tre adskilte, men forbundne, funktionelle enheder, der hver især fokuserer på en specifik fase af IT-serviceleverancen:
- Plan (Planlæg): Denne enhed er organisationens strategiske hjerne. Ansvarsområderne omfatter udvikling af IT-strategi, enterprise architecture, porteføljestyring og demand management (styring af efterspørgsel). 'Plan'-teamet arbejder tæt sammen med forretningsenhederne for at forstå deres behov, oversætte dem til teknologiske køreplaner og sikre, at IT-investeringer stemmer overens med virksomhedens overordnede mål. De definerer "hvad" og "hvorfor".
- Build (Byg): Når en plan er godkendt, tager 'Build'-enheden over. Denne enhed er ansvarlig for at designe, udvikle og implementere nye løsninger og teknologier. Dette inkluderer projekt- og programstyring, applikationsudvikling, systemintegration og testning. 'Build'-teamets primære fokus er at levere projekter til tiden, inden for budgettet og i henhold til de specificerede krav fra 'Plan'-fasen. De er ansvarlige for "hvordan".
- Run (Drift): Efter en løsning er bygget og implementeret, overdrages den til 'Run'-enheden. Denne enhed fokuserer på den daglige drift, vedligeholdelse og support af alle IT-systemer og -infrastruktur. Ansvarsområderne inkluderer service desk, incident management, problem management, overvågning og sikring af systemernes stabilitet og ydeevne. 'Run'-teamets mål er at levere pålidelige og effektive IT-tjenester til forretningen.
Denne adskillelse står i skarp kontrast til den traditionelle tårnmodel, hvor teams er organiseret omkring teknologidomæner som netværk, servere, applikationer og databaser. I tårnmodellen bliver ansvarligheden for en end-to-end service ofte udvandet på tværs af flere siloer, hvilket komplicerer fejlfinding, forsinker leverancer og gør det vanskeligt at styre leverandører, hvis ydelser spænder over flere teknologitårne. PBR-modellen skaber derimod en klar procescentreret ansvarsfordeling.
Bedste praksis for en vellykket implementering
At skifte til en PBR-model er en betydelig forandring, der kræver omhyggelig planlægning og udførelse. Her er nogle af de bedste fremgangsmåder for at sikre en succesfuld overgang.
Organiser med klar ansvarlighed
Det første og mest afgørende skridt er at skabe organisatoriske enheder med tydelig og ubestridt ansvarlighed for henholdsvis 'Plan', 'Build' og 'Run'. Dette giver klarhed i procesejerskab og ansvar for resultater. Hver enhed skal have en leder, der er ansvarlig for sin funktions præstationer og mål. Dette minimerer overlap og sikrer, at alle ved, hvem der er ansvarlig for hvad.
Styrk planlægningsfasen med forretningsanalytikere
Skab et stærkt korps af forretningsanalytikere og løsningsarkitekter, der er tæt knyttet til 'Plan'-funktionen. Det er vigtigt, at disse roller ikke er organisatorisk placeret under applikationsteams i 'Build'-enheden. Deres opgave er at drive en dyb funktionel viden om forretningsprocesser ind i den indledende afgrænsning af projekter. Ved at gøre dette kan de optimere den nødvendige ændring i applikationslandskabet ved at fremme konsistente forretningsprocesser. Denne tilgang reducerer time-to-market samt de samlede ejeromkostninger (TCO).
Introducer serviceporteføljer
Indfør serviceporteføljer, der understøttes af løsningsarkitekter inden for 'Plan'-funktionen. Disse porteføljeledere skal have et end-to-end overblik over omkostningerne og værdien af de tjenester, de administrerer. De skal også kunne vurdere og planlægge efterspørgslen efter ændringer inden for porteføljen. Dette driver en effektiv udnyttelse og rationalisering af applikationssuiten, herunder pensionering og migrering af mindre anvendte eller dyre applikationer. Resultatet er optimerede omkostninger, øget værdi og reduceret kompleksitet i IT-porteføljen.
Flyt beslutningskraften
En af de mest markante ændringer er at flytte beslutningskraften væk fra applikationsledelsen i 'Build'-enheden og over til 'Plan'-funktionen, som er tæt integreret med enterprise architecture. Traditionelt har applikationsteams haft stor indflydelse på, hvordan nye krav imødekommes, hvilket ofte fører til en konstant udvidelse af IT-applikationsporteføljen. Ved at centralisere denne magt i 'Plan' fremmes platformrationalisering og konsolidering, hvilket reducerer implementerings- og supportomkostninger og samtidig øger hastigheden og kvaliteten af leverancer.
Gå ikke i produktion, før alt er klar
Effektiviteten af PBR-modellen afhænger af, at teams holder sig inden for deres ansvarsområder. 'Build'-teamet har et afgørende ansvar for at sikre, at 'Run'-teamet er fuldt ud klar til at overtage driften af en ny løsning. Det betyder, at alt nødvendigt materiale – dokumentation, træning, supportprocedurer og overvågningsværktøjer – skal være på plads, før overdragelsen finder sted. Kun ændringer, der er fuldt supporterbare, bør sættes i produktion.
Sammenligning: PBR vs. Traditionel Tårnmodel
For at illustrere forskellene er her en sammenligningstabel:
| Aspekt | Plan-Build-Run Model | Traditionel Tårnmodel |
|---|---|---|
| Struktur | Funktionel og procesorienteret (Planlægning, Byggeri, Drift). | Teknologibaseret (Netværk, Server, Applikationer, Database). |
| Fokus | End-to-end serviceleverance og forretningsværdi. | Teknisk ekspertise og vedligeholdelse af specifik teknologi. |
| Ansvarlighed | Klar og tydelig for hver fase af servicelevetiden. | Ofte fragmenteret og uklar på tværs af siloer. |
| Agilitet | Højere agilitet på grund af fokus på processer og hurtigere beslutningstagning. | Lavere agilitet, da ændringer kræver koordinering på tværs af mange siloer. |
| Styring | Strategisk styring fra 'Plan'-funktionen sikrer alignment med forretningen. | Styring er ofte teknologidrevet og reaktiv. |
PBR i en verden med DevOps
Nogle vil måske spørge, hvordan PBR forholder sig til nyere metoder som DevOps, der sigter mod at nedbryde siloer mellem udvikling (Dev) og drift (Ops). Er de i modstrid med hinanden? Ikke nødvendigvis. PBR og DevOps kan sameksistere og endda supplere hinanden. DevOps kan med fordel implementeres inden for 'Build'- og 'Run'-strukturerne for at skabe et tættere samarbejde og automatisere overgangen fra udvikling til produktion. Man kan se PBR som den overordnede organisatoriske ramme, der definerer de store ansvarsområder, mens DevOps er en kulturel og praktisk tilgang, der optimerer arbejdsflowet inden for og mellem disse rammer. Udfordringen er at finde den rette balance mellem den kontrol, som PBR giver, og den fleksibilitet og hastighed, som DevOps tilbyder.
Ofte Stillede Spørgsmål (FAQ)
Hvad er den største udfordring ved at implementere PBR?
Den største udfordring er typisk organisationsændringsledelse. At flytte fra en velkendt teknologistruktur til en procesorienteret model kræver et markant skift i tankegang, roller og ansvar. Det er afgørende at sikre opbakning fra ledelsen, kommunikere visionen klart og investere i træning for at hjælpe medarbejderne med at tilpasse sig de nye arbejdsgange.
Er PBR-modellen egnet til små virksomheder?
Principperne i PBR – at adskille strategisk planlægning, udvikling og daglig drift – er universelle og kan gavne virksomheder i alle størrelser. Dog er en formel opdeling i tre separate afdelinger måske unødvendig for en meget lille virksomhed. I stedet kan små virksomheder adoptere tankegangen ved at tildele klare roller og ansvar for disse funktioner, selvom de samme personer kan have flere roller.
Hvordan måler man succes med en PBR-model?
Succes kan måles gennem en række nøglepræstationsindikatorer (KPI'er). Disse kan omfatte hurtigere time-to-market for nye projekter, reducerede samlede ejeromkostninger (TCO) for applikationer, forbedret servicestabilitet (færre kritiske hændelser), øget projektsuccesrate (leveret til tiden og inden for budget) og højere tilfredshedsscore fra forretningsenhederne.
Konklusion
Plan-Build-Run-modellen tilbyder en robust ramme for IT-organisationer, der ønsker at bevæge sig væk fra ineffektive siloer og hen imod en mere strategisk, agil og forretningsorienteret tilgang. Ved at skabe en klar adskillelse mellem planlægning, udvikling og drift kan virksomheder opnå større gennemsigtighed, klarere ansvarlighed og en stærkere tilpasning til forretningens behov. Succesen afhænger dog af en gennemtænkt implementering, stærkt lederskab og en vilje til at omfavne en ny måde at arbejde på. For dem, der lykkes, kan PBR være nøglen til at transformere IT fra et omkostningscenter til en ægte strategisk partner.
Hvis du vil læse andre artikler, der ligner Plan-Build-Run: Optimer din IT-struktur, kan du besøge kategorien Sundhed.
