Teknologistrategien er vigtig for at begrænse kompleksiteten i organisationernes it-landskaber som på sigt kan være en barriere for forretningsudvikling og dermed en barriere for at organisationen kan opnå den strategiske position som beslutningstagerne ønsker. Du kan bruge forretningsmodellen som udgangspunkt for at ”reverse engineering af forretningsmodellen” til en fungerende teknologistrategi. Dette blogindlæg tager sit udgangspunkt i anvendelsen af artefakterne fra EA 3 Cube rammeværket til at understøtte en teknologistrategi og en transaktionsplan.

Essentielt set kan enhver organisation opdeles i en forretningsmodel. I et forsøg på at illustrere organisationens funktioner og den måde som den skaber værdier for de interessenter som interagere med organisationen. Ifølge Osterwalder & Pigneur kan organisationens forretningsmodel opdeles i ni komponenter. På den måde som Osterwalder omtaler anvendelsen af forretningsmodellen som værende et værktøj som er tiltænkt til at indgå dialog med organisationens interessenter for at afdække den opfattelse som interessenterne har af organisationen og dens måde at skabe værdi. Fordelen ved at anvende Business Model Canvas frem for andre modeller vil være at den er dialog orienteret og den er simpel, hvilket maksimere udbyttet af at anvende den.

Igennem blogindlægget bliver artefakt-identifikationsnøgler anvendt som for eksempel S2 strategisk plan, S3 Konceptuel drift og S5 Performance Measures Scorecard. Identifikationsnøglerne stammer fra EA 3 Cube framework (version 2) og disse har til hensigt at give læseren en mulighed for at anvende artefakterne.

Tegn forretningsmodellen

Modellen tager sit udgangspunkt i at arbejde med at undersøge de ni komponenter hver for sig. Modellens komponenter kan involvere forskellige interessenter og inden de forskellige interessenter engageres for at identificere, hvordan de opfatter forretningsmodellen, så kan det vise sig nødvendigt at enterprisearkitekterne eller anden type arkitekt profil arbejder med at identificere den antagelse som de har af, hvordan organisationens forretningsmodel ser ud.

Til det formål kan der afholdes to workshops. Den første workshop er der hvor de enterprisearkitekterne introduceres til teorien arbejder med simple eksempler. Den anden workshop kommer til at omhandle, hvordan organisationens forretningsmodel ser ud fra deres perspektiver. Med resultaterne fra workshoppen kan enterprisearkitekterne arbejde aktivt med at engagere de forskellige interessenter som arbejder med de specifikke dele af organisationens forretningsmodel og værdikæde. Undersøgelsens omfang har afgørende betydning for de ressourcer som skal allokeres, og hvor lang tid det vil tage at gennemføre undersøgelsen. Derfor skal enterprisearkitekten eller chefarkitekten, hvis en sådan rolle findes i organisationen, tage stilling til hvor mange ressourcer som skal bruges på undersøgelsesfasen. Den absolutte fordel ved at inddrage medarbejderne er der skabes flere nuancer af, hvordan organisationen forretningsmodel hænger sammen, hvilket kan være med til at skabe et mere retvisende ”as-is” billede som kan bruges i forhold til at arbejde med identificere de informationsteknologier som skal bruges for at forandre organisationen mod et ønsket mål, altså det som kaldes for ”business transformation”.

Engager beslutningstagerne

I første omgang kan det vise sig relevant for enterprisearkitekterne at engagere beslutningstagerne, hvilket vil sige direktører, områdeledere og teamledere for et at finde ud af, hvordan de anskuer forretningsmodellen og to for at få accept til at indgå i dialog med medarbejderne. Der kan være store forskelle mellem det medarbejderne oplever og det som beslutningstagerne oplever omhandlende forretningsmodellen.

Inden beslutningstagerne for alvor engageres så skal visse artefakter indhentes så som den eksisterende forretningsstrategi og den eksisterende it-strategi. Disse to er nødvendige i forhold til at kunne indgå i dialog med interessenterne. I denne fase kan det vise sig relevant at arbejde med artefakter som S-2 Strategisk plan, S-3 Koncept for drift – diagram og S-5 Performance Measure Scorecard.

Det kan vise sig relevant for enterprisearkitekterne at udarbejde såkaldte ”play books”. Disse kan vise sig relevante for forberedelsen af beslutningstagerne og deres forståelse af, hvilken opgave som de spiller i den kontekst.

Engager medarbejderne

Medarbejderne kan vise sig at være oplagte engagere for at få et mere nuanceret ”as-is” billede, men på grund af der ofte findes mange medarbejdere i forhold til mellemledere så kan det vise det sig at det ikke er interessant at arbejde videre med på baggrund af ressourcerne som er til rådighed for enterprisearkitekterne.

Det kan tale for denne model, hvis enterprisearkitekterne har behov for at kende så meget til forretningsprocesserne som muligt for at kunne udarbejde it-løsninger som understøtter organisationens behov.

Dekonstruktion af forretningsmodellen

Forretningsmodellen består af ni komponenter. De ni komponenter behandler forskellige dele af det som skal til for at få organisationens værdiskabelse kan leveres til organisationens behov.

De ni komponenter har alle forretningsprocesser som er knyttet til dem for at de kan virke på en fornuftig måde. De forskellige forretningsprocesser kan gå på tværs af de forskellige komponenter. Processerne kan deles op i det som kaldes for ”delprocesser”. Forretningsprocesserne består af en række aktiviteter og aktiviteterne kan på en række måder opdeles i mindre opgaver. I denne fase kan det vise sig relevant at anvende artefakter som B-1 Business Process Diagram, B-1.1 Business Process / Product Matric, B-2 Business Operating Plan, og B-5 Use Case Narative and Diagram.

It-systemer

Aktiviteterne har ofte en konstruktion, hvor data udveksles mellem en eller flere individer. Data udveksles også mellem individer og it-systemer, hvilket betyder at arbejdet med at have de rette it-systemer til at understøtte udveksling af data bliver vigtigere og vigtigere.

Det er nødvendigt at udarbejde en såkaldt ”As – Is” opstilling af, hvordan forretningsprocessen understøttes af de logiske applikationer. Se på den grafiske opstilling nedenfor.

I denne fase kan artefakter som A-1 Application Interface Diagram, A-2 Application Communications Diagram, A-2.1 System Data Flow Diagram, A-8 Enterprise Service Bus diagram, A-9  Application Maintenance Procedure og A-4 Application Data Exchange.

Find der hvor skoen trygger

Der findes ofte problemstillinger med de problemstillinger med de forskellige tekniske løsninger fordi der oftere sker ændringer i forretningsprocesserne og i forretningsmodellen end der gør i de logiske applikationer. Årsagen til dette er ofte den omkostning som software-udvikling medfører ofte er meget stor set i forhold til de ændringer som finder sted i forretningsprocesserne. På grund af denne asymmetri vil der ofte være en uheldig forskel mellem behovene i forretningsprocesserne og de logiske applikationer.

Der findes forskellige måder at komme dette til livs på og det kan blandt andet indføres jævnlige møder mellem beslutningstagerne i forretningsenhederne eller det som kan kaldes systemejerne. Møderne vil primært omhandle de strategiske problemstillinger og hvordan de forskellige forretningsenheder understøtter udviklingen i organisationen. Ledelsesbeslutninger er vigtige, men det er meget sjældent de alene kan bruges til at udlede udviklingen af nye it-løsninger som understøtter forretningsprocesserne og forretningsmodellen. Derfor er det vigtigt at udbygge udviklingsmodellen så software-leverancer bliver leveret ofte og at interessenterne og i særdeleshed slutbrugerne bliver involveret i hvilke features som skal udarbejdes. En fremgangsmåde til implementering af en udviklingsmodel som understøtte denne fremgangsmåde er SCRUM.

En anden fremgangsmåde som kan vise sig nødvendig at arbejde med for at dele de logiske applikationer op i forskellige forretningsdomæner som igen understøtter de forskellige forretningsmodeller.

Modellen kan bruges som et fundament for allokering af ansvar for arbejdet med de forskellige applikationer. Modellen kan bruges i forhold til at definere brugerindgange og de interfaces som applikationslandskabet har. Modellen, som kan kaldes for H-modellen, kan bruges til at udvikle teknologistrategien overtid.

Essentielt set så er det interessant for enterprisearkitekterne at identificere elementer som:

1. Identificere lovgivningen på området og sæt den i kontekst af S-3 Concept of Operations Diagrammet.
2. Identificer mangler i eksisterende informationssystemer og andet it.
3. Identificer eksisterende matricer som bruges til at måle tilstanden for de eksisterende it-løsninger.

Identificer interessenter

Det er vigtigt at de rette interessenter bliver identificere og at de rette interessenter bliver involveret. Det kan betale sig at have interesse for to specifikke interessenter som kan have stor indflydelse på opfattelsen af informationsteknologier i organisationen. Den første interessent som vil være interessant at arbejde med vil være den interessent som står for at styre cashflowet for administration, håndtering og udvikling af it-løsningerne som udgør organisationens it-landskab. Vedkommende vil typisk have stor betydning for at definere, hvad der vil være realistisk at kunne implementere og det vil typisk være denne interessent som skal håndteres for at få flere ressourcer tildelt udviklingen. Et eksempel på en sådan interessent vil være finans- og økonomidirektøren. I mange mellemstore virksomheder vil det typisk være denne interessent som it-direktøren rapporterer til.

Den anden interessent som er vigtig at få inddraget for at skabe en større værdi for organisationen er slutbrugeren. Slutbrugernes mening har ofte stor betydning for hvordan it-afdelingens ry opfattes af de forskellige interessenter og det påvirker it-afdelingens evne til at kunne påvirke den strategiske udvikling af organisationen. It-løsningerne bør i størst mulig grad støtte op om slutbrugerne og støtte op om de behov som de end måtte have.

Enterprisearkitekterne og løsningsarkitekterne bør i høj grad være ude blandt slutbrugerne og observere deres brug af it og samle observationerne i et samlet bibliotek, så observationerne kan knyttes til de enkelte applikationer og processer senere i processen. Senere hen vil det vise sig nødvendigt at koble flere informationer om applikationer og processer sammen med komponenterne fra forretningsmodellen så der skabes et strategisk overblik over, hvordan de forskellige informationer kan anvendes til at skabe et strategisk overblik. I samme database kan det vise sig nødvendigt at arbejde med at oprette objekter som beskriver, hvordan interessenterne faktisk anvender informationsteknologierne, hvilket vil sige efter at kravspecifikationerne er blevet udarbejdet og sidenhen implementeret så er det nødvendigt at undersøge, hvordan de enkelte applikationer og informationsteknologier anvendes. Det bliver nødvendigt at arbejde med hvilke data som udveksles mellem de systemer som bruges i del processerne og i end-to-end processerne. Data kan udledes ved at interviewe interessenterne om deres anvendelse af informationsteknologierne som de har til rådighed eller igennem observation. På grund af forandringer i forretningsprocesserne, så kan det vise sig relevant for enterprisearkitekterne og informationsarkitekterne at arbejde videre med at opdatere metrikkerne (Identificere som artefakt D1.1) jævnligt. Ligeledes kan det vise sig nødvendigt at opdatere data dictionaries (D-6) og data flow diagrammer (D-4).

Det kan vise sig nødvendigt at undersøge it-infrastrukturen. It-infrastrukturen kan i mange virksomheder vise sig at være et problem fordi hardware, netværket og middleware viser sig at være en begrænsning, da disse kan være udateret. Under alle omstændigheder kan infrastrukturen betragtes som standarder som kan være en vigtig del af en teknologistrategi. Enterprisearkitekterne kan med fordel observere, hvilke enheder slutbrugerne gør brug af til at udføre deres arbejde et eksempel kan være de typer af PC’ere (eller Macs) som anvendes, deres specifikationer og tilbehør. Et andet eksempel kan være de steder, hvor slutbrugerne gemmer deres data er der tale om en cloud løsning eller er der tale om et centralt placeret netværksdrev. I denne kontekst kan følgende artefakter vise sig relevante at arbejde med I-4 Technology Forecast og I-3 Technical Standards Profile være relevante at anvende.

Teknologistrategien

It-strategien består af forskellige elementer så som en oversigt over strategiske it-projekter som organisationen skal sætte i gang for at få flyttet organisationen til den foretrukne strategiske position.

En it-strategi kan deles op i efterspørgselsside og en udbudsside. Begge er vigtige, men i udgangspunktet bør være størst. Teknologistrategien er en kombination mellem ”forecasting”, standarder og de overordnede valg af applikationer og infrastruktur til at understøtte forretningsprocesserne. Teknologistrategien er ligeledes bygget op omkring valg af fremgangsmåde for optimering af applikationslandskabet til at understøtte den situation, som organisationens beslutningstagere kan lide. Teknologistrategien opstiller også referencer til den fremgangsmåde som vælges til at administrere applikationer.

Teknologistrategien har også til hensigt at reducere kompleksiteten som nye it-løsninger kan medføre for organisationen. Derfor kan teknologistrategien også omhandle hvilke leverandører som kan vise sig relevante at anvende når informationsteknologier skal indkøbes.

Konklusion

Forretningsmodellen kan vise sig relevant at arbejde med for at finde frem til den rette teknologistrategi, som organisationen skal anvendes. Teknologistrategien kan bruges i forhold til at mindske kompleksiteten i organisationens it-landskabet. Ligeledes kan EA 3 Cube (version 2.0) anvendes i forhold til at beskrive udarbejde teknologistrategien ud fra forretningsmodellen.