Jernbane001

Systemiske problemer

Der findes en række gode grunde til at gå i gang med at implementere enterprise arkitektur programmet og ikke mindst at vedligeholde og udvikle det. En af årsagerne til dette er ved at identificere systemiske problemer der medføre, at enterprisen ikke vil være i stand til at levere de resultater som beslutningstagerne har defineret.

Symptomer

Symptomer er problemer der opstår som led af et større problem der findes i enterprisen. Aktørerne i enterprisen begynder som oftest at behandle symptomerne, da symptomerne er synlige for forskellige aktører og beslutningstagere i enterprisen. Symptomerne bør behandles for at sikre at de forskellige strategiske forretningsenheder bliver håndteret på den bedst mulige måde set i forhold til de ressourcer enhederne har til rådighed.

Symptomerne kan have betydning for den økonomiske situation, som enterprisen befinder sig i som helhed og er som udgangspunkt vigtige at få behandlet, men årsagerne til at symptomerne opstår bør undersøges, da der kan være et systemisk problem. Det er min opfattelse at det systemiske problem bør prioriteres højere end symptom problemerne, da systemiske problemer kan have større værdi at få løst, da det medføre flere af de symptomer der skal løses.
Det bliver derfor en nødvendighed til at udlede en fremgangsmåde enterprise arkitekterne (og resten af EA gruppen) kan anvende i forhold til at håndtere systemiske problemer, men inden fremgangsmåden bliver udlet vil jeg definere begrebet systemisk problem som det er anvendt i dette blog-indlæg.

Systemiske problemer

Er kendetegnet ved at have mange forskellige symptomer, men på grund af symptomerne og tiden der bør bruges på at løse de systemiske problemer medføre det ofte at problemstillingerne aldrig bliver løst. Det er de systemiske problemstillinger der er skyld i at enterprisen er i en situation, hvor enterprisen ikke kan opnå sine målsætninger, og det systemiske problem vil generere symptomer der samtidigt med håndteringen af det systemiske problem skal løses.

De systemiske problemstillinger kan løses ved at anvende en fremgangsmåde der kan stemme overens med ”wicked problems” fremgangsmåden. Årsagen til at ”wicked problems” fremgangsmåden vil være den rette fremgangsmåde at anvende vil være fordi systemiske problemer kan være svære at opdage, og som udgangspunkt er det svært for analytikerne (enterprise arkitekterne), forretningsarkitekterne, tekniske arkitekter eller andre arkitekt-profiler at finde frem til kernen i problemstillingen, da det systemiske problem oftest manifestere sig ved at der opstår symptomer, altså problemer der opstår over tid og som bør løses i forhold til at tilfredsstille aktører, interessenter osv. De forskellige symptomer vil være en nødvendighed at behandle og dermed finde løsninger på de problemstillinger der opstår. Derudover er ”wicked problems” kendetegnet ved at der er flere forskellige elementer der bliver sat i spil som for eksempel strukturer, organisationer, teknologi (og anvendelsen heraf) og økonomi.
Siden organisationer og virksomheder (enterpriser) findes i en kontekst der er evig foranderlig har tid en enorm indflydelse, hvormed der med sikkerhed skal træffes en række svære valg om, hvordan enterprisens ressourcer bør fordeles i forhold til at kunne levere resultater, hvormed der findes ressource-mæssige problemstillinger ved anvendelsen af ”wicked problems” fremgangsmåden.

Wicked problems

Inden jeg opstiller en potentiel fremgangsmåde for, hvordan enterprise arkitektur programmet kan være med til at løse systemtiske problemstillinger, vil jeg definere konceptet ”wicked problems”.

”Wicked problems” er kendetegnet ved at problemstillingerne virker uløselige for beslutningstagerne, da der ofte vil være mange forskellige modsatrettede faktorer de bliver nød til at tage højde for. Dertil kan ”wicked problems” virker som symptomer på andre problemstillinger i enterprisen. Udgangspunktet for løsningen for ”wicked problems” er ikke at der nødvendigvis findes den rette løsning, men om løsningen der udarbejdes og implementeres er bedre eller ringere end status quo. Problemstillingerne er ligeledes svære at håndtere med blot ved anvendelsen af en type perspektiv.

Enterprise arkitektur gruppe må indstille sig på at problemet udvikler sig, og problemet kan være være påvirkeligt på grund af de ressourcer, som enterprisen har til rådighed vil det blive besværligt for EA gruppen at kunne udpege problemets præcis omfang, og dermed også problemet præciseløsning.

”Wicked problems” er kendetegnet ved at problemstillingen ikke er kendetegnet ved at have en lineær problemstilling, det der normalt betegnes som et klart definerbart problem, og dermed heller ikke en klart definerbar løsning.

Løsningen betyder at der findes mange forskellige indgangsvinkler til løse problemstillingen med, og når problemstillingen først bliver kendt for EA gruppen er det næsten ensbetydende med at der er ved at være defineret en løsning. Med dette i mente har jeg udarbejdet en fremgangsmåde for anvendelsen af et enterprise arkitektur program til at undersøge enterpriser for, hvad der kunne tænkes at være ”wicked problems”.

Fremgangsmåden

Wicked problem er kendetegnet ved at løsningen der udarbejdes bedømmes ud fra om løsningen medføre noget bedre eller om den føre til noget der er værre end den situation som enterprisen stod i. Jeg er af den opfattelse at en struktureret fremgangsmåde vil være med til at sikre, at chefarkitekten og EA gruppen vil være i stand til at udvikle en bedre løsning, hvormed jeg har opstillet følgende punkter:

  • Undersøg de forskellige problemstillinger der forefindes i enterprisen. Stil spørgsmålet om disse problemer er forbundet eller om disse problemer er løstkoblede. Hvor stor sandsynlighed tror chefarkitekten og resten af EA gruppen der er for at problemerne er forbundet. Desto større sandsynlighed for at der findes en forbindelse mellem problemerne desto større sandsynlighed er der for at der findes et systemisk problem. I denne kontekst er et systemisk problem forstået som et ”wicked problem”, da det med stor sandsynlighed vil være tale om problemstillinger involvere mennesker, struktur, politik, systemer og økonomi.

  • Identificer de aktører og beslutningstagere der er berørt af problemstillingen. Find frem til de standarder der findes i de forskellige hold og økosystemer. I denne forbindelse er standarder forstået som værende måden (code of conduct) de forskellige aktører interagere med hver andre.

  • Kommunikér (og koordinere) med de forskellige aktører der er berørt (det kan være et hold, afdeling, sektion, division eller for den sags skyld hele enterprisen, i dette blog-indlæg vil disse til sammen benævnes som segmenter). Chefarkitekten bør kommunikere med beslutningstagerne. Dernæst følger problemstillinger der er relateret til begrebet at koordinere mellem de forskellige aktører og beslutningstagere der er berørt af det systemiske problem.

  • Identificere de ”evner” de forskellige segmenter af enterprisen besidder, identificere hvilke segmenter af enterprisen der besidder hvilke evner og koordiner mellem de forskellige segmenter i forhold til at finde frem til, hvilken form der findes for at skabe synergier (det vil sige, hvor enterprisens segmenter vil være i stand til at bruge sine evner til at opnå bedre resultater end de enkelte segmenter vil kunne alene).

  • Koordiner viden om ”evnerne” mellem de forskellige beslutningstagere i segmenterne i enterprisen således de vil være i stand til at handle ud fra den verificerede information der er tilgængelig.

  • Scenarie planlægning er en fremgangsmåde chefarkitekten kan anvende i forhold til at skabe bæredygtige planer for, hvordan enterprisens arkitektur kan forandres, således det systemiske problem bliver løst.

Når chefarkitekten og EA gruppen har nået frem til en definition af rammerne for problemet vil det oftest betyde rammerne skal udvides for at finde frem til det eller de systemiske problemer enterprisen lider af. Chefarkitekten vil med en hvis sandsynlighed opleve at der opstår problemer i forhold til ressource allokeringen til enterprise arkitektur programmet, og der i den forbindelse opstår et ekstraordinært behov for at influere de forskellige beslutningstagere der står for tildeling af ressourcer.

Et andet problem der opstår ved, når EA gruppen identificere det systemiske problem, så vil der være et behov for enterprisens beslutningstagere, at tage stilling til, hvem der skal skal lede forandringsprocessen således problemet løses på den bedst mulige måde.

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s