De fleste chefarkitekter, enterprise arkitekter, løsningsarkitekter og andre arkitekttyper vil med tiden opleve at interessenter i organisationen på den ene eller anden måde vil stille spørgsmål til, hvordan enterprise arkitektur programmet bidrager med værdi. I sådanne situationer er det ofte en god idé at have et fælles sprog at udstille viden om de forskellige sektioner af organisationen.
Dette blogindlæg vil komme ind på muligheder for at tilpasse en klassisk forretningsmodel til at vise, hvordan enterprise arkitektur skaber værdi som en intern service i organisationen. Modeller er i sagens natur en reduktion af den kompleksitet som verdenen består af, og styrken er at måden at kunne afgrænse og reducere kompleksiteten på en måde der gør det muligt beslutningstagere at kunne træffe bedre beslutninger.
Forretningsmodeller
Der findes mange forskellige modeller der kan anvendes til at vise flowet af værdi, og hvordan værdien skabes og leveres til dem der efterspørger disse produkter eller services, men den form model der giver mest mening at anvende (ud fra mit synspunkt) vil være ”The Business Model Canvas”. Der findes andre bloggere og forfattere der har udarbejdet mere specialiserede modeller som for eksempel en model som Tom Graves har udarbejdet. Årsagen til at jeg fravalgte Tom Graves model skyldtes, at jeg havde behov for at kommunikere med interessenter der har en forudforståelse af forretningsmodeller og i udgangspunktet hurtigt ville være i stand til at sætte sig ind i modellen. Der er i sagens natur tale om situationer, hvor der er meget kort tid til at kunne kommunikere med interessenten fx ved et elevator pitch overfor interessenter der er ikke har ret megen tid til at sætte sig ind i modeller og detaljer. Jeg nævnte tidligere, at modeller har en værdi i sådanne sammenhænge, men modellen skal samtidigt være let genkendelige og simple nok til at kunne vise data på en måde der vil kunne give modtagerne de data de har behov for.
”The Business Model canvas” er en model der kan bruges til at vise, hvordan begrebet enterprise arkitektur leverer services internt i en it-afdeling. Enterprise arkitektur afdelingen leverer produkter og services internt til organisationen. Derfor blev jeg nødt til at tilpasse modellen således den kunne anvendes på en fornuftig måde, men samtidigt være tilpas konsistent således kommunikationsværdien ikke forringes. Min hypotese omkring modellens struktur var at beslutningstagerne har behov for at se, hvilken værdi enterprise arkitektur programmet levere ved hjælp af viden om behov der kan dækkes af udvikling af it-baserede forretningsprojekter.
Modellen består af elve faser. I tabellen nedenfor er de elve faser opstillet og beskrevet.
|
Fase |
Beskrivelse |
|
Fase 1: Key Internal Partners. |
Fasen omhandler at få udstillet de interne partnere der har stor interesse set i forhold til at bidrage med ressourcer for at enterprise arkitektur programmet kan bidrage med værdi. |
|
Fase 2: Key Activities. |
Fasen omhandler de kerneaktiviteter der skal udføres for at enterprise arkitektur programmet bidrager med værdi. |
|
Fase 3: Key Resources. |
Fasen omhandler nøgle ressourcer der skal bruges i forhold til at kunne udarbejde de produkter eller services som it-afdelingen har behov for. |
|
Fase 4: Value Proposition. |
Fasen omhandler den værdi som it-afdelingen efterspørger. Det vil sige at der findes en antagelse om at enterprise arkitektur programmet og it-afdelingens beslutningstagere er bevidste om, hvad de vil have ud af enterprise arkitektur programmet. Under alle omstændigheder må det forventes at organisationen kan levere resultater. Typisk er det denne fase som kan være svær at få defineret i forhold til enterprise arkitektur programmet eller den service-orienterede arkitektur. |
|
Fase 5: Team Relationships. |
Fasen beskriver forholdet til de teams som enterprise arkitektur programmet servicerer. Det vil sige fokus på forholdet til de teams og mennesker der kommer til at anvende produkter og services som programmet vil medføre. |
|
Fase 6: Channels. |
Fasen viser, hvordan enterprise arkitektur programmet leverer resultater til it-afdelingen. |
|
Fase 7: Segments. |
Fasen segments omhandler it-afdelingen som helhed, om hvilke afdelinger der modtager inputs til at kunne tilpasse systemer. |
|
Fase 8: Enterprise IT Investment Structure. |
Fasen omhandler afklaring af hvordan organisationens nuværende it-arkitektur ser ud, og hvordan organisationens økonomiske ressourcer er bundet op på investeringerne. Dermed sagt er der tale om undersøgelser af return on investments og aktivitetsbaserede omkostninger (ABC) analyser. |
|
Fase 9: Scenario Planning. |
Fasen omhandler planlægning af hvordan it-investeringerne kan forbedres i organisationen fx ved omlægning af forretningsprocesser og tilpasning af systemer. |
|
Fase 10: Improved IT Investment Structure. |
Fasen omhandler omhandler optimering af it-investeringerne i organisationen set i forhold til implementering og forankring. Min bedste forståelse af organisatioenr og socio-tekniske systemer er at intet er statisk. |
Modellen er som sagt tilpasset så den viser værdiskabelsen som enterprise arkitektur programmet levere til sine modtagere i it-afdelingen. Viden om værdiskabelsen er ikke statisk, og det bliver i udgangspunktet en nødvendighed for enterprise arkitekterne og ikke mindst chefarkitekten at kommunikere viden om værdiskabelsen ud til interessenterne (især til de interessenter der sidder på pengekassen).
Modellen er udgivet under creative commons (share alike), og i udgangspunktet bør modellen henvise til BusinessModelGeneration.com. Hvis du har et ønske om at tilpasse min udgave af modellen skal du være velkommen til at gøre det under den betingelse, at modellen og referer til EnterpriseArkitekten.com
CoherencyArchitect
EnterpriseArkitekten.com 