En utvecklingsprocess för informationsförvaltning

Bilden ovan är den övergripande modellen av informationsförvaltning så som metodiken på denna webplats beskriver den. Modellen beskriver både hur man kartlägger befintligt läge men även hur man vill hantera verksamhetens utveckling och nya delar, som ett nytt sätt, att täcka in en ny del av verksamheten eller ett nytt system. Den innehåller också många moment av digitaliseringsprocessen  och utvecklingsarbetet och är därför en utgångspunkt för att hitta samverkan mellan informationsförvaltningen och de övriga roller och kompetenser som vi beskriver. 

Bilden ovan illustrerar ett exempel, från en bygglovsprocess, på en delmängd av en tänkt digitaliserad verksamhet. Vi ser till exempel att ‘IT-system’ befinner sig i ett sammanhang med ‘Verksamhetsinformation’, ‘Gallrad’ och ‘Bevarad information’. Dessutom realiserar systemet aktiviteter som pågår i ‘Processer’ som i sig hör till ‘Verksamhetsområden’ och som bygger på ‘Lagar’ och ‘Beslut’. Den visar alltså sammanhanget som börjar i ett uppdrag och som behöver kartlägga processer och information för att sedan få system och arbetssätt på plats.

Detta är därför en utgångspunkt för hur informationsförvaltningen och utvecklingsarbetet kan samverka kring vad som krävs för att nå till att system är på plats och fungerar som avsett.

Det som behövs för att komma vidare är en rad aktiviteter, modeller, specifikationer kring användare och deras behov, designförslag på olika alternativa lösningar, specifikationer för att bygga eller köpa, testfall och testplanering för att kvalitetssäkra och underlag för att lämna över till förvaltning. Detta är fortsättningen på digitaliseringsprocessen, och det vi här kallar ‘Utvecklingsprocessen’. Denna process innefattar även andra delar som genomgångar och granskningar, balans mellan krav och möjligheter i tid och resurser. Organisation, bemanning och verktyg så att det är rätt systemstöd som uppfyller behoven och som fungerar i överensstämmelse med verksamhetens övriga system och informationsflöden, i infrastrukturen och på ett tillgängligt och säkert sätt. 

Denna bild beskriver en digitaliserad arbetsprocess, så som metodiken på denna website tänker sig den. Den visar en generaliserad process för att ta fram stöd i form av arbetssätt och system för verksamhetens informationsförvaltning, alltså det som benämns ‘IT-system’ och som skall hantera ‘Verksamhets’, ‘Gallrad’ och ‘Bevarad information’ i den förra bilden. Det är dessutom en process som måste förstå ‘Process’, ‘Verksamhetsområde’, ‘Lag’ och ‘Juridik’ eftersom det är allt detta som definierar omgivning och förutsättningar för dessa arbetssätt och system. Slutligen måste denna process även adressera behoven hos alla olika användare utifrån vad de skall göra och hur det skall gå till. Detta motsvarar i bilden ovan av ‘Nuläge’ och allt i det undre benet som börjar med ‘Informationsförvaltning – Ramverk och metoder’.

Till det kommer att utvecklingsprocessen måste ha ett uppdrag, vilket utgörs av ‘Problem’ och ‘Behov’ samt ‘Vision, Mål, Önskat resultat’. Detta är vad som går in i processen.

‘Processdesign’ samt ‘Lösning’ är sedan en mycket förenklad bild av de generella utvecklingsstegen som innebär att förstå behov och föreslå en lösning. Längst till höger tillförs det som kallas ‘Icke-funktionella krav’ med säkerhet, tillgänglighet med mera.

En tydlig illustration i bilden ovan är det måste finnas olika roller i en verksamhet som utför en digitaliserings eller utvecklingsprocess. Dessa roller finns inom informationsförvaltning, som arkivarier, verksamhetsutvecklare utför dokumentationsplanering, arkivplanering, värdering osv. Och från det andra benet möter roller som arkitekter, tjänstedesigners, agila coacher och systemutvecklare upp i processen kring en lösning.

Detta är sammanhanget. Själva utvecklingsarbetet beskrivs i bilden ovan av det övre benet som börjar med ‘Verksamhetsutveckling – Ramverk och Metoder’. De roller som möts i detta arbete behöver samverka. Det som görs kring process och informationskartläggning av informationsförvaltande roller behöver förstås av arkitekter och tjänstedesigners. Omvänt så kan arkitektur, tjänstedesigners bidra till informationsförvaltning med metodiker, verktyg, modellspråk. Rollerna behöver alltså lära sig både av varandras domäner och arbetssätt. Det som behöver skapas är samverkan, sammanhang och att dra åt samma håll

Fördjupning

Vi har alltså varit inne på att förstå syfte o vision och vad verksamheten vill. Sedan användare som kan vara medarbetare, kunder osv. Sedan föreslå en lösning som innebär både arbetssätt och de system som skall supportera. Bygga eller köpa applikationer och införa förändrade arbetssätt. Installera och drifta och förvalta. Testa att system, arbetssätt fungerar, rätt produkt och att produkten är rätt.

Samtidigt behövs projektledning eller linje som leder och styr allt som utförs, samt hanterar resurser, personal, pengar, håller tidplan och att verskamhetens rutiner följs inklusive regelverk och juridik och kvalitet och hela tiden rapporterar till beställare och ledning.

En utvecklingsprocess består alltså av ett antal olika saker. Den består av aktiviteter som skall utföras, medarbetare i olika roller, olika leverabler som skall tas fram och sätt att samverka. Det behövs verktyg och metodiker. Sedan behöver det finnas resurser, en plats i organisationen, ledning och styrning. 

Detta är alltså en bred aktivitet som sträcker sig från hur den skapas och underhålls, precis som alla andra delar av verksamheten. Det arbete som utförs sträcker sig från verksamhetens ledning till IT-avdelning med drift och förvaltning och via en rad olika avdelningar, team, roller. 

Hur utvecklingsprocessen kan utföras

Utveckling och dessa aktiviteter kan också ske på en rad olika sätt, som löpande utveckling i förvaltning eller mera dedikerade projekt och som inköp, upphandling, eller att man bygger själv och som helt nya sätt och system eller vidareutveckling i större eller mindre omfattning. 

Det finns också några olika arbetssätt, eller metodiker, som vattenfall, iterativ utveckling, agil utveckling eller enligt design-thinking principer. Det här är nästan alltid en mix av flera olika av dessa. 

Utveckling av olika typer av produkter och tjänster påverkar också hur utvecklingsprocessen går till, om det är produkt och tillverkning som bilindustri, telekom och som paketerar produkter i tjänsteerbjudande som serviceavtal. Eller offentlig förvaltning där man mera pratar om tjänster istället för produkter och som tillhandahålls till medarbetare och medborgare.

Om olika domäner

Dessa olika typer av verksamheter brukar kallas domäner, som bank eller mera generellt finans, telekom, fordon, försvar, offentlig förvaltning. Till sin hjälp brukar utvecklingsprocesser därför ta domänspecifika standarder, referensmodeller, guider. För informationsförvaltning finns t.ex ISO30300 eller OAIS kring hur verksamheten skall bedrivas och DIRKS eller Recordkeeping by Design kring hur verksamheten skall utvecklas. Vissa metodiker är mera generella och fungerar lika bra i olika domäner, som ’processorienterad analys’. 

 

Den metodik som beskrivs på denna site är ytterligare ett sätt att beskriva både hur verksamheten bedrivs och utvecklas jämte praktiska verktyg som Klassa. Det innebär också att mycket av det som beskrivs här egentligen ingår som en del i en utvecklingsprocess och det som levereras i exempelvis processanalysen, klassificering, informationsanalys och som görs av roller som arkivarier och informationsförvaltare är sådant som alltid görs i en utvecklingsprocess, exempelvis inom telekom, eller annan offentlig förvaltning men som kanske kallas för andra saker och görs av andra personer. 

 

Utvecklingsprocessen behöver alltså därför anpassas och anslutas till verksamheten givetvis och utifrån de förutsättningar, de specifika sätt, termer, roller och leverabler som gäller för domänen i fråga. 

En alltför smal utvecklingsprocess

 

Detta är givetvis bra eftersom det är roller och personer som känner både domän och sin specifika verksamhet. Det finns dock ofta tendenser att verksamheter underskattar komplexiteten det innebär att utveckla digitala lösningar, både arbetssätt och system. Oavsett om det är upphandling eller om man bygger själv. Branschen som sådan kring utvecklingsprocesser generellt eller inom IT och för digitalisering specifikt, har därför identifierat både ett antal sätt, metodiker, leverabler och roller som visar sig framgångsrika, som minskar risken att göra fel, överskrida tid och budget. I många verksamheter finns en övertro på att en bra projektorganisation är tillräcklig eller att en kompetent IT-avdelning räcker för att ta fram eller få en lösning på plats.

 

Erfarenhet från branschen visar dock alltså något annat.

Den bredare utvecklingsprocess vi vill lyfta fram

 

Det är därför ett antal roller, metodiker och arbetssätt som vi vill lyfta fram och som vi kommer att beskriva på ett praktiskt sätt, riktat till domänen som är informationsförvaltning och till de användare/läsare som kommer hit. I vilken form och för vilka läsare vi skall rikta oss vet vi ännu inte utan detta är något vi behöver utforska, förstå, prova men vi vill ändå ge en översikt över vad vi tror det är vi behöver tillhandahålla.

 

Roller och deras arbetssätt

Detta är de typiska roller som brukar ingå i mjukvaruprojekt. Notera att det är roller, det kan vara en person som har flera roller. 

 

– IT-arkitektrollen är en av de roller som fungerar på samma sätt som en byggarkitekt, som både kan ansvara för helheten och detaljerna. Vi utgår fårn den definition som Sveriges IT-arkitekter tagit fram och som beskriver ’Arkitektroller för den digitaliserade organisationen’ i form av fem kompetensroller ’Enterprise’, ’Verksamhet’, ’Lösnings’, ’Mjukvaru’ och ’Infrastruktur’-arkitekter. För dessa beskrivs förmågor som rollerna behöver samt en korsreferens mot andra förekommande rollbeteckningar. Dessa roller arbetar typiskt med att stötta informationsförvaltare, verksamhetsutvecklare att hantera komplexitet i att förstå processer och användare, och att formulera behov och krav på spårbart och kvalitetssäkrat sätt samt översätta till lösningsförslag och även agera tolk och brygga mot systemutveckling eller leverantörer. Arkitekter ingår ofta i projektteam och samverkar med beställare, projektledare, produktägare, tjänstedesigners och fungerar ofta överbryggande mot utvecklings och leveransteam. Arkitektur ingår också ofta portfölj och programteam för att stötta med risk, beslut och planeringsuppgifter. Typiska arbetssätt är metodiker och ramverk som Zachman, TOGAF, Archimate-modeller, modeller över hela verksamheter, dess system och information. IT-arkitketur arbetar mer och mer gränsöverskridande med designtänkande och agila metodiker där både arbetssätt och leverabler tjänar på principer som kontinuerligt utforskande och praktiska experiment snarare än mycket dokumentation. Syfte är både för förståelse av behov och för att föreslå lösningar i form av behov, krav 

 

– Tjänstedesign och UX-design. Detta är roller som ofta samverkar med arkitektroller och som delvis har samma syfte och arbetssätt men specifikt kring behov, process och förmågor och användare och deras behov. Dessa roller arbetar också ofta ihop med projektledare, de olika arkitektrollerna, beställare och givetvis användare och även mot systemutvecklare kring användbarhet och grafisk form. Även dessa roller kan ingå i olika ledande grupperingar som program och projektteam. Dessa roller arbetar med designmetodiker som användarresor, användar-studier, informationsarkitektur, upplevelse, designspråk.

 

– Agila roller som ’Agile coach’, ’Produktägare’. Dessa arbetar både tillsammans med eller istället för traditionella projektledare och coachar team utifrån agila sätt att tänka kring smidighet, värde och nyttoorientering och kontinuerlig förbättring av både utvecklingsprocess och metodik, samt av själva produkten eller tjänsten. Detta ansluter alltså till både arkitektur och tjänstedesign-rollerna och dessa arbetar ofta tillsammans. ’Produktägarrollen’ närmar sig kontinuerlig utveckling av produkten snarare än utvecklingsprocess och team och är givetvis även denna nära ihop med arkitekt och tjänstedesignrollerna. 

 

– Systemutvecklarroller som ’Lead Developer’, ’Testledare’ och som typiskt arbetar i agila tema enligt Scrum/Kanban och i processer som DevOps med kontinuerliga leveranståg och där gränsen mellan systemutveckling, test och drift suddas ut. Dessa roller arbetar med programmering i olika programspråk, utvecklingsmiljöer och plattformar och använder applikationer som databaser och operativsystem. De tar fram testfall och testplaner och driftsätter, validerar. 

 

Andra delar som drift, infrastruktur är roller som normalt finns på plats på ett bra sätt och ofta väl utvecklade processer på plats. Vi kommer inte täcka in dessa lager förutom att beskriva vad vi tror är viktigt för ett bra fungerande samarbete. 

 

Hur vi vill hjälpa verksamheter att nå ett steg i sin utvecklingsprocess

Vi tror att det är just dessa roller, deras arbetssätt, det värde de tillför som behöver lyftas fram, för att visa dels hur verksamheter kan stötta och rusta sina egna medarbetare men också ta in resurser som inte redan finns på plats. Vi tror också att det är viktigt att visa på varför och hur man kan göra för att stärka utvecklingsprocessen utifrån vad de områden och sätt vi beskrivit här. Återigen genom tat använda det som finns men rusta och utbilda och förändra åt rätt håll, och där det behövs göra mera genomgripande förändringar. Vi vill också därför visa på praktiska sätt hur man kan gå tillväga, mallar, guider och verktyg. Inte minst vill vi tillhandahålla sätt där verksamheter kan skatta sin egen förmåga och prioritera utifrån möjligheter, vad som är viktigast och ger mest värde. Vi vill inte rekommendera några specifika sätt, metodiker, roller utan det beror på omständigheter som verksamheterna själv är bäst på att förstå och tolka. Vi kommer att rekommendera vad vi sett fungerar men kommer inte att binda oss till någon särskild leverantör utan vill vara agnostiska och utgå från vad som fungerar bäst.

 

Vad vi har gjort så här långt är att beskriva omfattning och inriktning. Det vidare arbetet tar sin början här och i dialog med läsare och användare av denna website samt med i takt med hur professionen kring informationsförvaltning utvecklas och innehållet på denna site utvecklas.