d)+Analyse

=Arbeidsprosess i Trondheim kommune= Arbeidsprosesser internt i Trondheim kommune utføres på svært mange forskjellige måter. Trolig finnes det like mange måter å løse oppgaver på i Trondheim kommune, som det finnes ansatte. Ser man på tvers av avdelinger, har hver avdeling sitt fagområde. Iallefall i den ideelle teoretiske verden. Men i den praktiske hverdagen i en kommune er det ikke alltid slik. Selv om hvert område har ansvar for en type oppgaver, er det mer eller mindre en flytende skillelinje mellom hvilke avdelinger som løser hva. Det vil si at en arbeidsoppgave som skal gjennom samlebåndet, og få hver sin deloppgave løst på hver sin avdeling, heller blir løst ved at de forskjellige deloppgavene flettes sammen og overlapper hverandre. Ofte kan dette skape problemer i form av uklare rutiner og strukturer. Hvem løser hva? Hvordan blir en arbeidsprosess løst på én avdeling, og hvordan legger dette forutsetninger og premisser for arbeidsprosessen på neste avdeling? Hvordan påvirker forarbeidet på en avdeling, kvaliteten og effektiviteten på arbeidet ved neste avdeling?

eGovernment handler om bruk av IT i offentlig sektor og det som ofte kalles eGovernmentsystemer. Dette er sosiotekniske systemer som betyr at de kombinerer mennesker og teknologi (Heeks, 2006). Et godt utgangspunkt for å forstå hva et eGovernmentsystem er, er ITPOSMO checklist.

ITPOSMO checklist
ITPOSMO modellen (Heeks, 2006) er en forenklet modell for å forstå hva et eGovernment system er. Modellen benyttes for å beskrive og forstå eGovernment system og interessenters organisatoriske sammenheng.
 * Informasjon: Den formelle informasjonen i systemet og den uformelle informasjonen brukt av folk som er involvert i bruken av systemet.
 * Teknologi: Hovedfolkus på digital IT, men kan også omhandle annen informasjonsbehandlings teknologier som papir eller analoge telefoner.
 * Prosesser: Aktivitetene gjennomført av menneskene som systemet er laget for.
 * Mål og verdier (objectives and values): Mål innebærer elementer som egeninteresse og organisatorisk politikk. Dette kan til og med innlemmes i den formelle strategien til organisasjonen. Verdier innebærer kultur, dvs. hva interessenter ser på som rett og galt.
 * Bemanning og kompetanse (staffing and skills): Omhandler brukerne av systemet og deres ferdigheter.
 * Styringssystemer og struktur (managment systems and structures): Styringssystemer som kreves for å organisere drift og bruk av systemet. I tillegg kommer variabelen i forhold til hvordan interessenter er strukturert både formelt og uformelt.
 * Andre ressurser (other resources): Tid og penger som går med for å implementere og drifte eGovernment-systemet.

Tilnærming til styring av eGovernment-systemer
I ”Implementing and Managing” beskriver Heeks (2006) forskjellige metoder å tilnærme seg bruk og styring av IT i offentlig sektor. Det beskrives et samspill mellom data, teknologi, mennesker og prosesser og i denne sammenhengen gjelder tre mulige tilnærminger. Sentralisert, desentralisert og en hybrid av de to nevnte.

Sentralisert tilnærming til eGovernment systemer
En slik tilnærming betyr at man har et system som er sentralt, og som skal håndtere flere avdelingers behov (Heeks, 2006). Dette er gjerne skapt av et team sentrale IT utviklere, eller av innleid eksterne utviklere. Man har gjerne en såkalt referansegruppe som er deltakende i utviklingsprosessen. Opplæring og brukerhjelp er ofte organisert og planlagt ut fra et organisasjonsmessig ståsted.

Fordeler med sentralisert tilnærming
Man får en lavere kostnad pr enhet. Dette på grunn av at data, software, forbruksmateriell, opplæring, systemutvikling, konsulentvirksomhet etc. kan håndteres en gang og investeres i store kvanta. Man server en større gruppe med færre ressurser, enn om man skulle hatt flere små systemer med sine egne behov for støtte. Man unngår dobbeltarbeid og dobbeltlagring. Ved at man benytter kun et system, lagres data kun en gang, og alle har tilgang til samme informasjon. Dette sparer penger og kvalitetssikrer bruken. I tillegg er det en fordel at kompetansen i bruk av systemet kan benyttes på tvers av hele organisasjonen. Organisasjonen har større kontroll med hva som går ut og inn av data og informasjon og en større sikring i forhold til funksjonsfeil. Man har en kvalitetskontroll av at datasikkerheten overholdes. Systemet er tilpasset en stor gruppe mennesker, snarere enn enkeltmenneskers eller gruppers behov.

Ulemper med en sentralisert tilnærming
Det kan være tidkrevende prosesser i et sentralt eGovernment system. Informasjon og beslutningsgrunnlag bruker lang tid på å bli ferdigbehandlet og forsinker prosesser. I tillegg ser man at system som ikke er skreddersydd for å møte brukerbehov på den enkelte avdeling/brukergruppe, kan skape problemer og forsinkelser. Om design ikke svarer til virkelighetens behov, påvirker dette produksjon og kvalitet. Tungrodde byråkratiske systemer påvirker også motivasjonen til ansatte. Sentraliserte systemer vanskeliggjør håndteringen av forskjellene mellom avdelinger. Når en stor organisasjon er avhengig av et system, er dette veldig sårbart for systemfeil, da det vil påvirke hele organisasjonen.

Desentralisert tilnærming til eGovernmentsystem.
Heeks (2006) beskriver en fullt ut utviklet desentralisert modell som at hver avdeling eller til og med hver ansatt benytter seg av den teknologien som passer dem best. Enten det er i forhold til kompetanse eller behov i forhold til arbeidsoppgavene.

Fordeler med desentralisert tilnærming
Ved en at enheter i en offentlig organisasjon jobber såkalt desentralisert, med egenutviklede systemer oppnår man mange fordeler (Heeks, 2006). Den viktigste er kanskje at systemet er skreddersydd for å løse oppgaven best mulig. I tillegg har man et tett forhold til utviklingssiden, og man bruker derfor liten tid på å utvikle en løsning som passer til behovet. Kanskje har man til og med utviklet systemet på egen hånd. Man ser behovet og skaper en løsning selv eller ved hjelp av en utvikler. Det kan også argumenteres for at en desentralisert tilnærming er kostnadsbesparende på grunn av mindre gap mellom design og virkelighet, raskere systemutvikling og mindre feilkommunikasjon.

Ulemper med desentralisert tilnærming
Barrierer i forhold til å dele data. Dette kan skape problemer i forbindelse med alt fra å fremskaffe finansiell informasjon, til store problemer i bedriftens struktur. Menneskelige ressurser/kunnskap kan ikke deles enkelt på tvers av avdelinger i forbindelse med bruk av system, da hvert system krever egen opplæring. Man kan heller ikke utnytte hardware/software på tvers av avdelinger på samme måte som om man har et sentralisert system. Det risikeres også at det skapes dupliserte data, med varierende kvalitet. Det reduseres stordriftsfordeler som eksisterer ved sentral tilnærming.

Hybrid tilnærming (push og pull)
Om man lykkes i å kombinere en sentral løsning og en desentral løsning, kan dette gi stor gevinst. Dette forutsetter at man lykkes å hente ut fordelene fra de to løsningene, og unngår ulempene. Fordeler kan høstes ved å forsone påtrykk fra sentralt hold kombinert med utdrag fra lokalt hold - push og pull (Heeks, 2006). Dette gjøres ved å forene disse to i en enhetlig integrering. Begge innlemmes og avgrenses på hver sin måte slik at man sitter igjen med en hybrid som høster de positive effektene av hvert system. For at en slik løsning skal fungere er det svært viktig at det håndteres riktig. Ellers risikerer man å sitte igjen med en løsning som gir det verste fra begge verdener.

Qlickview
Et eksempel på programmer som henter ut informasjon fra andre programmer er Qlickview. Dette programmet kan knyttes opp mot mange forskjellige typer systemer og så hente ut statistikk etter pull-prinsippet. Slik fjerner Qlickview noen av ulempene ved en desentralisert tilnærming. Dette gjør at man får den informasjonen man søker fra de riktige kildene. På Qlickview.com skriver utviklerne at “Vi tror at informasjon kan forandre verden, og at hver enkelt forretningsbruker kan bidra til dette. Med QlikViews Business Discovery plattform kan alle enkelt analysere data og gjøre egne oppdagelser”.

Begrensninger knyttet til endring av eGovernment-systemer
Om man benytter ITPOSMO modellen som utgangspunkt, kan man analysere begrensningene knyttet til innføring av et nytt eGovernmentsystem. Om man allerede har et system som er ”oppe og går,” innebærer dette at man må endre organisasjonens informasjonsstruktur. Man får nye måter å behandle informasjonen på, nye formater, hardware og software. Beslutningsgrunnlag blir endret. Dette kan medføre motstand blant ledelse. Informasjonen oppfattes som så viktig og unik for den enkelte leder, at organisasjonen ikke kan endre systemet og strukturell oppbygging. Systemendringer innebærer endring av ressursflyt; penger, mennesker og teknologi. De lederne som ser seg selv som potensielle tapere, vil naturlig nok yte motstand mot en slik endring. Ledere kan ofte ha et eieforhold til ”sine data” og derfor ikke se på det som organisasjonens data. Spesielt ser man dette i offentlige organisasjoner hvor det er kamp om knappe ressurser mellom forskjellige avdelinger. Endring av systemer krever ressurser som tid og penger, mennesker og ferdigheter. Da dette er knappe ressurser i offentlig sektor, kan dette legge begrensninger på en eventuell endring av systemer. Av og til er kompetansen til å se behovet for endring tilstede i organisasjonen, men ikke bestandig på de rette stedene (ledelsen). Forskjellige eksisterende ansvarsområder og strukturer kan skape begrensninger på endringsprosesser.
 * Informasjon, teknologi og prosessbegrensninger.
 * Mål og verdier
 * Bemanning/kompetanse og andre ressurser
 * Styringssystemer og struktur

Arbeidsprosesser
Som beskrevet i innledningen blir organisasjoner ofte beskrevet og analysert utifra en hierarkisk organisasjonsstruktur. Denne måten og se en organisasjon på har imidlertid en del begrensninger (Iden, 2005). Den tar blant annet ikke hensyn til hvem som har ansvaret for det som skjer mellom avdelingene eller hvordan samspillet mellom medarbeiderne er. Som en konsekvens av dette har det blitt stadig mer fokus på arbeidsprosesser når man skal beskrive organisasjoner. Her tar man mer hensyn til arbeidet som gjøres og samarbeid mellom ansatte og sluttbrukere enn det man får til i tradisjonelle organisasjonskart. Prosessorientering betyr å fokusere på hvordan medarbeidere fra ulike enheter samarbeider om felles oppgaver (Iden, 2005). Man fokuserer altså på hva de ansatte gjør, ikke hvor de er organisert.

I denne oppgaven vil vi benytte RIS-metoden for å analysere arbeidsprosesser i Trondheim kommune. RIS står for "roller i samarbeid" og er en metode utviklet av Jon Iden for å kartlegge, analysere, forbedre og styre prosessene i en virksomhet (Iden, 2005). Siden vi benytter oss av denne modellen er det også nødvendig å ha den samme begrepsforståelsen som ligger til grunn her. Jon Iden (2005) hevder alle prosesser består av tre elementer. Det er styring, arbeids- og informasjonsflyt og ressurser. Styring handler om at en person må være prosesseier og ha ansvaret for hele prosessen, på tvers av avdelinger og organisasjonsstruktur. Dette er viktig for å kunne klare å se prosessen som helhet og ha oversikt fra start til mål. Har man ingen, eller eventuelt flere, prosesseiere er det fort gjort å miste oversikten. Arbeids- og informasjonsflyten er det som i praksis utgjør strukturen i en prosess, og det er den man lager modell av. Det er her man beskriver hvilke aktiviteter som utføres, hvem som utfører dem, og hvordan en sak flyter fra rolle til rolle fra begynnelse til slutt (Iden, 2005). Arbeidsflyt og informasjonsflyt kan ofte være adskilt, men det er viktig å ha innblikk i begge i prosessmodelleringen. Ressurser består av mennesker og hjelpeverktøy. Gode ressurser er en forutsetning for å få til en god prosess. Det må være klare og entydige roller, og hensiktsmessige hjelpeverktøy. Med utgangspunkt i disse tre dimensjonene definerer Jon Iden (2005) en prosess som "en samling roller som samarbeider om å nå et mål". Det er også denne definisjonen vi jobber ut i fra i denne oppgaven.

Det finnes mange måter å analysere prosesser på. RIS-teknikken er en av dem. RIS fokuserer på hvilke roller som er involvert i prosessen, hva hver enkelt rolle utfører og hvilke relasjoner det er mellom de ulike rollene (Iden, 2005). Hensikten er å visualisere arbeidsprosessen slik at den blir enklere å forstå og å analysere. Teknikken bruker et sett faste symboler for å beskrive prosesser. De ulike symbolene med forklaring er presentert i figuren under. Som eksempel på arbeidsprosess har vi valgt ut en prosess som involverer tre interne enheter i Trondheim kommune, samt en ekstern aktør. Dette er også en arbeidsprosess som tidligere har skapt mye frustrasjon, både internt i organisasjonen og hos samarbeidspartnere. Det er også en arbeidsprosess som gjentas mange ganger i løpet av et år, og effektivisering av prosessen vil derfor gi store gevinster i løpet av et år. Arbeidsprosessen som vi skal analysere tar for seg søknad og utbetaling av refusjon for barn som er plassert i fosterhjem i andre kommuner enn hjemkommunen. I dette tilfellet vil det si barn fra Trondheim som er plassert i fosterhjem i andre kommuner (vertskommuner). Her må da Trondheim kommune betale refusjon til vertskommunene etter vertskommunene sine satser. Her er det få retningslinjer å forholde seg til. Det betyr at satser og praksis varierer mye fra kommune til kommune. Det vanskeliggjør selvfølgelig også prosessen med å få til ryddighet i arbeidsprosesser og samarbeid. I tillegg til at det kan være vanskelig å holde oversikten er det et område hvor det er snakk om såpass mye penger at det er viktig med en viss forutsigbarhet. For Trondheim kommune er det årlig snakk om et sted mellom 20 og 30 millioner som skal utbetales i refusjoner til andre kommuner. Arbeidsprosessen slik den er i dag kan beskrives på følgende måte:



Det er totalt fire roller i denne arbeidsprosessen. Selv om alle er nødvendige er det naturlig å fokusere på Oppvekstkontoret og Økonomitjenesten. For det første er det her det er flest aktiviteter som foregår og sannsynligvis er det da også her det er størst muligheter for effektivisering. Dessuten har Trondheim kommune liten grad av påvirkningsmuligheter for hvordan vertskommunen opererer, så her er det vanskelig å gjøre endringer. Det er sendt brev med ønsker om standardisering og presisert hvor refusjonskrav skal sendes, og det er egentlig det man får til å gjøre. Ser vi på aktivitetene under Oppvekstkontoret og Økonomitjenesten ser vi at det er mange manuelle oppgaver og også en del parallelle aktiviteter. For begge rollene ser kanskje rekken med aktiviteter mer fornuftig ut når vi ser de hver for seg enn når vi ser de under ett. Da virker plutselig parallelle aktiviteter, som at begge registrerer krav i hvert sitt regneark, litt merkelig. Dette er et eksempel på hvorfor det er viktig å se hele arbeidsprosessen under et, og ikke bare innenfor hvert enkelt team. Slik det er i dag er også et godt eksempel på desentralisert tilnærming, hvor....alle har sine egne løsninger og arbeidsmetoder. Siden ingen helt har oversikten over hele arbeidsprosessen høster man ikke alle gevinstene med at verktøyene er godt tilpasset oppgaven. Det er nemlig ikke klart for alle hva oppgaven faktisk er. Man får derimot en god del av ulempene ved desentralisert tilnærming, ved at det blir vanskelig å dele data og man da kan få dupliserende data med dårlig kvalitet.

Som nevnt er gode hjelpeverktøy viktig for å få til en god prosess (Iden, 2005). I en organisasjon som Trondheim kommune er mange av hjelpeverktøyene gitt av andre enn de som innehar rollene i en arbeidsprosess. Dette gjør derimot ikke hjelpeverktøyene mindre viktige. I prosessen som vi har beskrevet betyr hjelpeverktøy stort sett software. I store organisasjoner er man ofte bundet til software knyttet til fakturering, økonomi, arkivering og andre oppgaver som foregår i hele organisasjonen. Noen ganger er det bra software, andre ganger er den mindre bra. I tillegg til slike omfattende og pålagte programmer har man som regel også mange mer eller mindre valgfrie programmer. Dette innebærer for eksempel bruk av tekstbehandling og regneark, programmer for notater, løsninger som Dropbox til å dele filer, og så videre. Man kan si at selve effektueringen av prosessen utføres av et sentralisert system, mens vurderingsgrunnlaget for avgjørelsene og handlingene skapes i forskjellige desentraliserte systemer.

Ser vi på arbeidsprosessen og antall tilfeller hvor noe registreres i et regneark, er det naturlig å starte her. Slik det er i dag brukes Microsoft Excel som software og filene som brukes lagres på 3-4 forskjellige steder av like mange personer. Filene er opprettet av forskjellige personer på ulike avdelinger og regnearkene deler ikke mye mer enn at de er en del av den samme arbeidsprosessen og at de inneholder noe av den samme informasjonen. Oppbygging, utseende og bruk er veldig forskjellig. Oppvekstkontoret følger opp hver enkelt sak i sine regneark, og Økonomitjenesten gjør det samme i sine. Selv om ikke all informasjonen er den samme, er det essensielt at grunninformasjonen er oppdatert i alle regneark. Alle saker og oppdatert status må være registrert i samtlige regneark. Når man opererer med flere versjoner med samme type informasjon, er det en reell risiko for at data dupliseres og er av variabel kvalitet. Om informasjonen ikke er samstemt med andre versjoner av tilsvarende data, skaper dette koordineringsproblemer og kan gå på bekostning av kvalitet på sluttproduktet. Informasjonsflyten mellom disse regnearkene foregår i dag på forskjellige måter. Noe sendes på e-post, noe formidles muntlig og noe skrives ned på post it-lapper. Noe informasjon formidles dessverre ikke i det hele tatt, før det eventuelt oppdages mer eller mindre tilfeldig at det er noe som mangler. Konsekvensen av alt dette er mye frustrasjon blant de ansatte og at arbeidet ikke blir gjort med den kvaliteten og effektiviteten som det kunne ha blitt. Dette skaper også merarbeid og behov for korrigeringer. Så hva kan gjøres?

Når man startet med dette arbeidet var det litt andre rammebetingelser med tanke på teknologi og programvare. For ikke så altfor mange årene siden satt man med hver sin stasjonære pc hvor man hadde lagret sine dokumenter. Den gang var hele arbeidsprosessen langt mer optimal en den er nå. Et alternativ i dag er å bytte ut mange regneark i Microsoft Excel med et felles regneark i Google Drive, eller lignende løsninger. Her vil alle kunne jobbe i samme dokument i samtid, og på den måten alltid ha oppdatert informasjon. Man slipper mye av den kommunikasjon som i dag foregår muntlig eller via e-post, rett og slett fordi alle er oppdatert til enhver tid. Slik fjerner man mange feilkilder, sparer tid og kan fjerne flere aktiviteter i arbeidsprosessen. Vi ser også at flere aktiviteter i arbeidsprosessen kun er fysisk flytting av papirer. Det er for eksempel ingen grunn til at oppvekstkontoret ikke kan levere refusjonskravet direkte til skanning hos regnskapstjenesten, i stedet for at det skal innom Økonomitjenesten først. Dette er sannsynligvis mer en gammel vane enn et bevisst valg. Dette fjerner enda en aktivitet fra arbeidsprosessen.

Etter disse tiltakene sitter vi igjen med en arbeidsprosess som gir de samme resultatene, men har færre aktiviteter. Ny arbeidsprosess ser slik ut:



Vi ser at vi har fått vesentlig færre aktiviteter i ny arbeidsprosess enn i gammel. Vi har også beveget oss bort fra desentralisert tilnærming og mer i retning av sentralisert. Istedenfor at alle har utarbeidet hver sine arbeidsverktøy og rutiner, har man nå et arbeidsverktøy som er utviklet for at det skal brukes av alle som er involvert i arbeidsprosessen. Nye digitale verktøy åpner for nye muligheter, men det kan også føre til nye utfordringer. Et av de områdene hvor det er størst skepsis i forhold til digitale verktøy er i hvilken grad de ivaretar sikkerheten. Ofte er det ubegrunnet skepsis, men det kan heller ikke uten videre overses. I vårt eksempel er det snakk om mye personsensitiv informasjon. Slik det har vært tidligere, hvor alle har hatt sine egne rutiner og verktøy, har ikke alle hatt tilgang til denne typen informasjon. Når alle nå skal bruke samme verktøy blir dette en utfordring. I tillegg sier norsk lov at sensitive data skal være lagret innenfor Norges landegrenser. Dette er ikke tilfelle dersom man bruker Google sine løsninger. Man kan argumentere for at lovverket er utdatert og at det ikke er noen lavere sikkerhet om data er lagret i andre land, men man må likevel forholde seg til loven slik den er i dag. RIS-metodikken gir en god beskrivelse av arbeidsprosessen, men det er også elementer og konsekvenser som ikke kommer så godt frem. For eksempel kommer det ikke frem hvilke konsekvenser det får dersom det gjøres feil underveis i prosessen. Feil vil selvfølgelig ha påvirke den beskrevne arbeidsprosessen, men det vil også ha konsekvenser utover dette. Tidlig på året blir blant annet data som Økonomitjenesten sitter på om fosterhjemsplasserte brukt til prognoser for å anslå hvordan man kommer til å ende opp ved årsslutt. Dette forutsetter korrekte tall. Det samme gjør budsjettering og utbetalinger til vertskommuner.

Samarbeid internt i Trondheim kommune
På mange måter kan man si at de forskjellige avdelingene i Trondheim kommune ofte jobber etter en desentralisert modell. Samtidig ser det ut til at kommunen stadig vekk forsøker å etablere en mer sentralisert løsning som skal løse de fleste arbeidsprosesser. Hvorfor skjer det? Er det etablert en grunntanke i organisasjonens kultur om at en sentralisert løsning er svaret? Er det viktigere med stordriftsfordeler, styring og kontroll, enn skreddersøm og kvalitet? Skaper individuelle systemer for store samarbeidsproblemer? Og i hvilken grad har man gått i dybden på disse problemstillingene når man har tatt avgjørelser om endring av system-oppbyggingen? Erfaring indikerer at prosessen før etablering av prosjekter som endrer IT-struktur, ikke har vært grundig nok. Trondheim kommune startet prosessen med å utvikle et sentralt system som skulle løse så og si alle administrative oppgaver i 2005. Fem år etter konkluderte kommunen med at løsningen som forelå, langt fra løste de forskjellige arbeidsprosessene og oppgavene på en tilfredsstillende måte. Resultatet ble at kommunen måte bryte avtalen med leverandøren, og gå bort fra illusjonen om at alt kunne sentraliseres. Det vil alltid være behov for desentraliserte løsninger i en så stor organisasjon som Trondheim kommune. Å tro at man kan håndtere alle mulige prosesser med et system, virker som en illusjon. Dog finnes det forskjellige løsninger på forskjellige plan. Og hva er egentlig en desentralisert modell, og hva er en sentralisert? Hvor går skillet? Trolig gjelder det å ikke henge seg for mye opp i hvor grensen går. Det viktigste er i utgangspunktet at systemet er tilpasset virkeligheten. Selvfølgelig er man avhengig av en viss form for kompromiss fra alle parter om man skal gå for en sentralisert løsning. Men om man begrenser sentraliseringsperspektivet til å bare gjelde kanskje to eller tre avdelinger, isteden for hele organisasjonen er det naturlig å tro at man unngår flere av ulempene ved sentralisering, men høster fordelene. Om man skal gå for en såkalt sentralisert løsning for eksempelvis tre avdelinger, er det ikke nødvendigvis slik Heeks (2006) beskriver det i //Implementing and managing eGovernment//, at dette behøver å være dyrt. En sentralisert løsning kan også være en løsning, beskrevet som disruptiv teknologi av Arne Krokan i “Den digitale økonomien” (2010). Disruptiv teknologi er systemer/programmer som er utviklet for å løse oppgaver enkelt og er gjerne tilrettelagt for samarbeid. Disse fungerer og ofte bedre enn mer etablerte og dyrere løsninger.

Sentralisert eller desentralisert, hvor går grensen?
Som nevnt under kapittelet om prosessmodellering, benyttes Microsoft Excel i svært utvidet grad i Trondheim kommune. På mange måter kan man si at innenfor Excel har man egne teknologiske modeller og system som fungerer svært desentralisert og løser mange av oppgavene som den enkelte ansatte sitter med. Mye av denne informasjonen og dataene er svært nyttig også for andre enheter. Men da det ikke er etablert systemer eller rutiner for hvordan dette skal kommuniseres, ser man ofte duplisering av informasjon, dobbeltlagring og større risiko for informasjon som skal samsvare med annen informasjon, ikke gjør det på grunn av manglende kommunikasjon mellom systemene og modell-eierne. Resultatet kan være at sluttproduktet fremstår av dårligere kvalitet enn nødvendig. Ved å innføre bruk av eksempelvis Google Drive eller Microsoft Skydrive regneark, har man plutselig løst en svært stor problemstilling som mange ansatte i Trondheim kommune sliter med. Disse ville på mange måter fungere som en sentralisert løsning, dog helt uten kostnad i motsetning til Heeks sin teori i //Implementing and managing eGovernment// fra 2006. Disse verktøyene har vi allerede tatt i bruk på Økonomitjenesten i Trondheim kommune, med svært godt resultat. Nå kan man naturlig nok si at dette ikke er en sentralisert løsning på grunn av at den ikke håndterer nok oppgaver. Dog er slike løsninger mer sentralisert enn eksisterende desentraliserte systemer som nevnte Excel-systemer. Man bør uansett ikke henge seg for mye opp i disse skillelinjene. Men å konkludere med at sentraliserte systemer vanligvis er kostnadskrevende, er en utgående teori som ikke behøver å være gjeldende i dagens digitale samfunn.

Regelverk vs den digitale utviklingen
Likevel har dagens regelverk i de fleste kommuner ikke åpnet for full utnyttelse av de tilgjengelige, helt klart kostnadsbesparende og effektiviserende hjelpemidlene og systemene som ligger der ute. Å forvente at man skal henge med i utviklingen og være konkurransedyktig og samtidig operere med industrisamfunnets kontrollerings behov, er også en utopi. Nettopp denne typen regelverk setter hinder i vegen for at man skal kunne utnytte disse verktøyene fullt ut. Da ender det opp med byråkratiske tungrodde systemer, som har høye etableringskostnader. Trolig har Google et mye høyere sikkerhetsnivå enn brannmuren til Trondheim kommune. Men denne kunnskapen ser ut til å ikke ha fått fotfeste helt enda. Hverken i Trondheim kommune eller andre kommuner for den saks skyld. Men hva skal så til for at man ser gevinsten ved bruk av “alternative” systemer? Svaret er implementering og gartnervirksomhet. Om man som sentrale aktører tar i bruk verktøyene slik at alle i utvidet grad ser effekten av dette, har man trolig begynt å rulle denne lille snøballen. Å fortsette å produsere resultater, samt vedlikeholde interessen ved involvering av andre vil forhåpentligvis gjøre snøballen større og større.

ITPOSMO og innføring av en sentralisert modell i Trondheim kommune
Trondheim kommune kan ikke bestå av bare desentraliserte systemer eller delvis desentraliserte systemer. Noen systemer bør være helt sentraliserte. Men da fortrinnsvis i forhold til oppgaver som er gjennomgående like for alle. Om enheter må gå på akkord med seg selv og sine arbeidsoppgaver for å bli presset inn i et sentralt system som absolutt skal implementeres, vil man møte sterk motstand og sansynligvis ende opp med en dårlig løsning. Trondheim kommune forsøkte som nevnt å utarbeide en hel-sentralisert løsning som skulle omfatte de fleste administrative oppgaver, med prosesstart allerede i 2005. Om vi ser på ITPOSMO-modellen opp i mot denne prosessen, kan man beskrive litt av de effektene som spilte inn. I utgangspunktet hadde kommunen flere desentraliserte systemer som hver var skreddersydd for å løse nettopp sin oppgave. Fakturasystemet var kun utarbeidet for å behandle faktura, timeregistreringssystemet skulle håndtere kun timeregistrering, lønn skulle sørge for lønnsutbetalinger og informasjon om lønn etc. Dette var bare noen få deloppgaver som skulle inn i samme system. Dette medførte at man måtte gå bort fra prinsippet om skreddersøm. Til gjengjeld fikk man tyngre prosesser med mer krevende arbeidsaktiviteter. Informasjonen skulle behandles annerledes og resultatet ble at den ble vanskeligere å fremskaffe. Dog skulle man unngå at man måtte benytte manuelle løsninger for å få systemene til å kommunisere sammen. Det var i alle fall intensjonen. Overgangen medførte endring av ressursflyt, penger, mennesker og teknologi. Mange av enhetslederne så at prosessene ble tyngre og mer tidkrevende, og skapte massiv motstand mot det de mente var et tungrodd, byråkratisk system. Veldig mange så seg selv som tapere, mens noen få så seg selv som vinnere. Argumentene inneholdt blant annet at på grunn av knappe ressurser og i så måte knapphet på tid, var konsekvensene av et system som var mer tidkrevende enn hva som var tilfellet tidligere, svært uheldig. Et så omfattende system og total endring av arbeidsstruktur medførte selvfølgelig store kostnader knyttet til behov for ekstra bemanning og opplæring. I tillegg har vi kostnader knyttet til operasjonalisering. Med tanke på at resultatet ble som det ble, kan man si at dette ble svært dyrt for Trondheim kommune. Det er likevel deler av systemet som fungerer og er i bruk. Økonomisystemet fungerer, selv om det måtte bli en hybridløsning kombinert med diverse andre desentraliserte system som lønnsystem og tidligere regnskapssystem. Så noe valuta for pengene ble det. Vi ser også at Trondheim kommune har en stor fordel når det gjelder å kunne benytte kompetanse på tvers av avdelinger i bruk av systemet. Drift og bruk av systemet medførte en svært stor organisatorisk strukturell endring. Det måtte opprettes en helt ny avdeling som håndterer operasjonalisering. Det måtte opprettes egne nye lokaler skreddersydd for å håndtere det enorme kursbehovet knyttet til det nye systemet. Bare for å håndtere kursvirksomheten, ble det organisert en opplæringsenhet med leder og ansatte kursholdere. Alle som skulle jobbe med systemet måtte gjennom samme opplæring, løpende over flere dager. I tillegg til månedlige workshops. Med andre ord, store strukturelle endringer som både var tid og ressurskrevende. Ved bruk av ITPOSMO-modellen til å analysere utviklingen og innføringen av dette sentrale systemet, ser vi at man gapte rett og slett over for mye. Ved å forsøke å få alle prosesser i et sentralt system, gikk det for mye på bekostning av funksjonaliteten og skreddersøm. I tillegg var endringen så stor at strukturelle endringer ble svært omfattende og kostnadskrevende. Hadde man konsentrert seg om å få kanskje to eller tre sentraliserte systemer som var mer skreddersydd for sine oppgaver, ville det sannsynligvis gått bedre. I alle fall kunne man konsentrert seg om en ting av gangen, og brukt ressursene til å få dette til å fungere optimalt.
 * ===Informasjon, teknologi og prosess===
 * ===Mål og verdier===
 * ===Bemanning/kompetanse og andre ressurser===
 * ===Styringssystemer og struktur===

Utfordringen ved mange forskjellige systemer og samarbeid.
Sentraliserte og desentraliserte system har naturlig nok hver sine egenskaper som man er avhengig av i en organisasjon. Ofte kan det være en fordel ha en fungerende hybridløsning som henter ut det beste fra begge verdener. Dette kan være svært utfordrende å få til. Om man lykkes med kombinasjonen påtrykk fra sentralt system, samtidig med pådrag fra desentraliserte system, kan dette gi positive effekter. I Trondheim kommune eksisterer det pr dags dato, flere sentrale system. Det er ikke disse som skaper problemer i kommunikasjonen mellom avdelinger som Oppvekstkontoret, Regnskapstjenesten og Økonomitjenesten. Men det er alle de desentraliserte løsningene som skaper forvirring og dobbeltarbeid. Og det er her mye av beslutningsgrunnlaget i forskjellige saker ligger. Som nevnt tidligere kan en eventuell løsning her være å operere med systemer som er delvis sentraliserte. Det vil si løsninger som sentraliseres kun for enkelte enheter der dette er nødvendig. Å unngå å tenke at sentralisering er noe som skal involvere hele organisasjonen. Disse tre nevnte enhetene er avhengig av hverandre med tanke på uthenting av informasjon (pull.) Men likevel sitter hver avdeling på sin tue, uten å tenke mye på at informasjonen de sitter på også skal/kan benyttes av andre. Hvorfor ikke? Man kan legge noe av skylden for dette på dårlig kommunikasjon eller kanskje dårlige rutiner på samhandling på tvers av avdelinger. Men noe av ansvaret ligger også på at det ikke eksisterer en felles plattform for samarbeid på tvers av disse avdelingene. I og med at man er avhengig av desentraliserte system, finnes det måter å løse dette på. Et alternativ er som nevnt å benytte programvare mer tilrettelagt for deling av informasjon. Et annet alternativ er å eksempelvis ta i bruk en software som Qlikview. Med dette verktøyet kan man hente ut relevant informasjon fra flere forskjellige system og presentere dette i en applikasjon. På denne måten åpner man en ny arena for samhandling. Systemet automatisk henter ut den informasjonen som trengs og når den oppdateres (pull). Dette er et etablert verktøy og utviklingskostnader er derfor ikke et tema. Men kostnaden gjelder for hver installerte lisens. Det er heller ikke nødvendig at hele kommunen skulle ha behov for dette, men ansatte som sitter med arbeidsoppgaver som er avhengig av informasjon fra andre lokale systemer operert av andre avdelinger kan gjøre seg nytte av dette. Spesielt om man ser på samarbeidet mellom Oppvekstkontoret, Regnskapstjenesten og Økonomitjenesten, hadde dette vært en nyttig løsning. Dette krever selvfølgelig at de riktige menneskene ser nytten av det. I tillegg kreves det noe kompetanse i bruk og tidsressurser til opplæring.