Frågor att ställa här: 

• Kan du som kund redogöra för hur befintliga applikationer och produkter och tjänster ser ut, vilka behov de fyller, hur de driftas, hur de samverkar, vilka förmågor som byggs, vilka användare är, tekniknivå, kostnad, säkerhet osv. – Alas det behövs en arkitektroll. 
• Finns det någon i organisationen som kan fylla denna uppgift, om vi berättar ungefär vad den skulle innebära? Att åtminstone börja adressera är, även om det är en oerfaren icke-arkitketperson är bättre än inget allt – dessutom fullt möjligt hävdar vi.
• Kan du som kund sedan redogöra för effekter när en produkt uppdateras, eller en ny produkt införs i verksamehten och hur flera produkter samverkar?
• Har det någon gång hänt att en säljare kommer och säger att ni måste uppdatera, byta till denna nya produkt, exvis Teams, men du som kund egentligne inte förstår varför. Eller att ni säger att ni redan nu inte har fullt koll på hur ni hanterar dokument/mail/samarbete<insert valfritt här> men att säljaren säger att denna nya produkt kommer att lösa detta och att ni inte behöver oroa er?
• Har du som kund någon gång fått känslan av att liksom vid en rättegång det finns behov av en jurist som kan tolka lagen så skulle ni behöva någon som kunde tolka vad en säljare egenteligen säger och vad det kommer att innebära för er som kund.

För att få alla dessa delar på plats så tror vi att det behövs ett antal olika kompetenser och som består av roller, metodiker och verktyg. Denna bild illustrerar de huvudsakliga förmågor vi ser är nödvändiga. Återigen, de skall ses som en utgångspunkt, eller ett sätt att mäta sina egna förmågor och stärka det som behövs. Eller att hitta sätt där en kompetens utförs av närliggande roller och resurser som redan finns på plats.

Arkitektur handlar om teknisk strategi för verksamhetens mål och syfte och dess användare. Arkitektur sträcker sig från övergripande verksamhetsmål till hur system och produkter byggs. Arkitektur har också mera specialiserade roller som säkerhet eller kvalitet. Samt hur system samverkar med arbetssätt och användare/kunder samt med infrastruktur eller externa aktörer. En typisk förmåga hos arkitektur är också hur de ISO-standarder som Tom nämnde används på ett praktiskt sätt. Här finns också helhetssynen på både andra tjänster och produkter i verksamhet och externt så att vi inte bygger en silo, samt att övergripande mål kring exempelvis prestanda också byggs och levereras, på rätt sätt. Viktiga verktyg är stadsplaner, verksamhetsmodeller, domän och objektmodeller.

Användbarhet handlar också om verksamhetens mål men mera fokus på hur användare och kunder adresseras. Här finns också förmågor och kunskap kring hur man bygger användbara system, adresserar färg och form och designkultur och tillgänglighetsanpassade gränssnitt. Här finns studier och metodiker kring användare och deras behov och som inte bara lyssnar till vad användare säger utan ser vad användare faktiskt gör. Datadrivet designarbete.

Arkitektur och användbarhet arbetar ofta tillsammans och kompletterar och överlappar kring verksamhetens behov och intresse och användarens.

Systemutveckling handlar främst om att bygga eller få på plats de system och applikationer, databaser och infrastruktur som behövs för tjänsten. Men det handlar också om formell metodik kring krav, design och test – något som börjar på arkitektur och användbarhetsnivå men måste hanterar metodiskt så att den ursprungliga visionen, den förändring vi vill åstadkomma också följer med hela vägen, genom alla nivåer och i ett myller av detaljer och inte tappas bort. Här finns också slutligen verifiering och validering, att vi byggt rätt produkt och att vi byggt produkten rätt. Det är också här spårbarhet landar, eller ansvaret finns för att detta kommer på plats, särskilt för reglerade verksamheter men även andra, mera lösa verksamheter har nytta av att kunna följa behov och hur de kravställs och levereras.

Projektledning o agila metodiker. Här tror vi det är viktigt att adressera både mera traditionell projektledning och agila sätt, eftersom det är en verklighet att agila metodiker ofta fungerar bra på teamnivå men är en utmaning att skala upp och att den mera traditionella synen därför nästan alltid behövs. Det vi vill bidra med är som vi hela tiden lyft, helheten och förståelsen av vad olika kompetenser bidrar med och varför de är nödvändiga och sätt för projektledare att ta tillvara på dessa.

Drift förvaltning o infrastruktur. Här tycker vi det återigen är viktigt att både adressera mera traditionella förvaltningsformer och de framväxande tankarna kring devops från den agila rörelsen. Även här vill vi bidra till förståelse mellan verksamhet och IT att underlätta för samarbete mellan kompetenser och visa på sätt hur vi får till detta praktiskt.

Product Management ser vi handlar om en delvis framväxande förmåga inom branschen. Det handlar delvis om traditionell produktledning men också om ’produktägarrollen’ och hur man kan hitta utforskande sätt att förstå kunder och hur verksamheten kan möta dessa behov. Det är en delvis ny förmåga som både behöver förstås och provas, och vad den kan ge kring informationsförvaltning. Här finns också översikten hur tjänster och produkter marknadsförs, hur behov fångas från användare och verksamhet och hur tjänster och produkter levereras till användare. Sammantaget kan sägas att dessa förmågor gemensamt först skapar bilden av vilken förändring det är vi vill åstadkomma i verkligheten – här är tonvikten på produktstrategi, arkitekt och användbarhet/tjänstedesign tillsammans med verksamhetens intressenter. Sedan skapar dessa förmågor gemensamt den kunskap som behövs för att bygga och leverera denna förändring – med tonvikt här på systemutveckling, projektledningsförmågorna.

Team

Detta hör ihop med att organisationen ofta ser ut som ett C eller ett timglas. O-managerat i mitten. O-tillsatt. O-informerat om vad som behövs för att gå fårn verksamheten, kunder och användares behov ner till fungerande lösning. När org ser ut som ett timglas så är det övertungt på ledning, styrning, projlekt och i viss mån produkt/tjänste-manageringc/chefsskap men det är ett stort gap däremellan.

Digitalisering i en omgivning

Den här bilden förtydligar också ett par andra aspekter:

• Dessa förmågor adresserar alltså unika förmågor, kompetenser. Det är också viktigt att se att dessa kompetenser i sig kan delas in i ledande och styrande och mera operativa nivåer. De oranga kompetenserna har tonvikt på ledning och styrning, de gröna på mera operativa delar. Men, även inom arkitektur, användbarhet och systemutveckling finns ledande och styrande nivåer, t.ex fastställa arkitketurprocess och bestämma metodiker, ta fram designsystem och driva en designkultur och att ta fram formella utvecklingsprocesser, kravprocess osv. Och omvänt, i de oranga kompetenserna finns mera operativa nivåer som aktivt deltar i utvecklingsarbetet.
• (Kompetenser har också olika nivåer, styrande, ledande, operativt. Arkitektur har till exempel övergripande, styrande funktion för att sätta process, principer, bestämma verktyg och metodiker. Ledande nivå för att driva granskningar och hjälpa till med resurssättning. Och operativt med att praktisera arkitektur på olika nivå och i olika roller, verksamhet, information, mjukvara, säkerhet.)
• Andra kompetenser har motsvarande nivå som att etablera designkultur och designsystem, eller en formaliserad metodisk kravprocess eller devops i systemutveckling.
• Kompetenser behöver också samarbeta och arbeta mot samma mål. De behöver vara likvärdiga, alla behöver bidra, alla behöver få utrymme, alla behöver få mandat.

Samtidigt rör sig digitalisering och utveckling av tjänster i ett sammanhang och konkurrerar med resurser från den övriga verksamheten vilket också är kopplat till mål och vision och prioriteringar. Utveckling får ibland stå tillbaka för att säkra den löpande verksamheten och vice versa.

Tillbaka https://informationsforvaltning.com/digitalisering-metodik/