Et casestudie af sammenhængsledelse i en større offentlig organisation (1)

Dette blogindlæg vil præsentere et casestudie som jeg fik udarbejdet i 2010. Igennem de næste par uger vil jeg præsentere flere forskellige sider af casestudiet set i forhold til, hvordan enterprise arkitektur kunne anvendes til at løse problemstillingerne, som organisationen står overfor.

Den offentlige sektor i Danmark anvender en stor mængde ressourcer på at investere i informationsteknologi med henblik på at effektivisere og levere services til borgerne, men der er ligeledes store udfordringer i forhold til at høste de fordele som implementeringen af informationsteknologi kan lede til. En af årsagerne til en del af de ressourcer som der investeres i de forskellige informationssystemer ikke giver de ønskede resultater . Denne case tager sit udgangspunkt i et casestudie, som jeg gennemførte i 2010 i en større organisation i den offentlige sektor.

Som med så mange andre dele af den offentlige sektor har organisationen kontorer mange steder i Danmark for at kunne levere services til borgere og virksomheder der har behov for dialog om forskellige nye regler der opstår som led af det politiske spil (specifikt i forhold til finansloven), og hvordan de skal være i stand til at overdrage informationer til den specifikke offentlige myndighed.

På grund af behovet for at kunne levere en nogenlunde konsistent service til borgerne har staten samlet en del af de centrale opgaver i et center der er lokaliseret i København. Dette center var genstandsledet for undersøgelsen, da staten bevidst har samlet den tekniske ekspertise i netop dette område.

Caseorganisationen har anvendt informationsteknologi på mange forskellige måder igennem tiden, og organisationen råder over meget store datamængder, og der konstant stilles nye krav i forhold til undersøgelsen af de indkommende data for at finde frem til om disse reelt også stemmer overens med virkeligheden som staten skønner virkeligheden bør være. På grund af de store datamængder gik den offentlige organisation, tidligt i gang med at implementere forskellige former for informationsteknologier for at kunne behandle de enkelte data. Dette er en af grundene til at caseorganisationen har en meget kompleks it-arkitektur.

På grund af der er tale om den offentlige sektor findes der andre myndigheder der kan stille krav til, hvad organisationen egentlig skal foretage sig, og hvor meget det må koste. Caseorganisationen oplever derfor ofte at finansministeriet kommer med helt konkrete krav til, hvilke opgaver organisationen skal foretage sig for at få tildelt den samme mængde ressourcer som året før. Derfor findes der oftest en kamp mellem organisationen og andre offentlige organisationer der er på fx regions – eller kommunalt niveau om at få tildelt opgaver der kan relatere sig til det specifikke ansvarsområde. Der har på grund af denne kamp været en del offentlige skriverier, hvor især de kommunale myndigheder har beklaget sig over situationen fordi, at de mener at ressource tildelingen ikke tilgodeser de behov der findes for dem som helhed.

Denne kamp om opgaver har ligeledes vist sig at have stor indflydelse på, hvordan organisationen kan anvende sin it-arkitektur¹ til at få løst opgaverne. Staten (især de folkevalgte politikere) stilles nemlig krav om, at caseorganisationen skal være i stand til at levere services til individer og virksomheder der ikke har adgang til internettet², og dermed er der et konstant behov for at finde en balancegang mellem at automatisere og fastholde services og rådgivning på andre kanaler fx personlig eller over telefonen. Caseorganisationen kan som sådan heller ikke vælge eller rettere fravælge besværlige kunder, hvormed der trods et udpræget ønske om forandring stadig er visse dele af caseorganisationens eksistensgrundlag er organiseret omkring servicering af disse.

Dette skal dog ikke betyde at der ikke er mulighed for at finde frem til optimeringsmuligheder, da der findes massere af gode muligheder for behandling af data og optimering af brugen af de eksisterende informationssystemer til håndtering af de opgaver som organisationen bliver sat til at løse.

Caseorganisationen er en ældre organisation, og som jeg før har nævnt, og organisationen begyndte tidligt med at anvende informationsteknologiske produkter til at behandle sine data. På grund af den aldrende organisation og de specialiserede arbejdsopgaver så findes der massere af forskellige og stærkt specialiserede informationsystemer der ikke understøtter dataudveksling eller anvendelse af de funktioner der findes i de forskellige forretningsprocesser og systemer.

På grund af at caseorganisationen havde været udsat for en række forskellige ændringer igennem tiden, og det at de forskellige specialiserede løsninger havde stor betydning på udveksling af data og dermed evnen til at håndtere problemstillingerne med analysering og verificering af de enorme mængde data, som organisationens hovedkontor var ansvarlig for at kunne facilitere. På grund af de specialiserede forhold der findes for organisationens forretningsprocesser, så har organisationen forsøgte til udvikle en organisatorisk funktion for håndtering af organisationens forretningsmodel og tilpasningen af organisationens ”forretningsprocesser”, denne funktion har organisationen valgt at kalde forretningsarkitektur.

Forretningsprocesserne tilpasses dog på alle måder hurtigere end it- arkitekturen kan nå at blive tilpasset, og dermed er organisationen i en situation, hvor omverden kræver en hurtigere og mere krævende udvikling på it-arkitekturen end det organisationen reelt er i stand til at tilbyde.

Organisationens enterprise arkitektur gruppe havde heller ikke gjort sig helt klart, hvilket rammeværk, som organisationen ville anvende i forhold til 1) igangsætte processen for modellering af enterprisens arkitektur og 2) enterprise arkitektur gruppen havde ikke gjort sig det klart i forhold til, hvilke artefakter der skulle fokuseres på.

Organisationen havde tilbage i 2010 en chefarkitekt der på grund af de politiske omstændigheder havde et kraftigt syn på omkostningsreduktion, og vedkommende arbejdede med en tilgangsvinkel der primært fokuserede på stabilitet og omkostningsreduktion.

Caseorganisationen har igennem arbejdet med at standardisere sine data og sine systemer arbejdet med SOA (service-orienteret arkitektur) og på baggrund af dette har organisationen oplevet nogle forskellige problemstillinger der har haft betydning for caseorganisationens it-arkitektur og anvendelse af enterprise arkitektur.

Caseorganisationen arbejder med at få styr på sin reference arkitektur, men samtidigt har caseorganisationen (2010) ikke været i stand til at blive enig om en bestemt tilgangsvinkel til implementering af et enterprise arkitektur rammeværk.