(Om: Av någon anledning verkar det inte gå att spara utkast om en sida är publicerad. Eller så fungerar inte utkast över huvud taget, sidor verkar publiceras ändå. Dock, om de inte finns i menyn är det ju inte möjliga att navigera till och man ser dem inte. Om man vet den exakta url’en så kan man ju dock läsa sidan. Därför är detta en kopia under arbete av ’Början på en utvecklingsprocess’ och som indikeras med prefix ’Iteration’  Rent konkret är det otydligt hur man sparar en sida i Elementor. Den rosa rutan med ’Uppdatera’ ger val att ’Spara utkast’ men om man då avslutar Elementor går ändringar förlorade. Man måste ’Publicera’ verkar det som.).

En plats och ett sätt

Syftet med denna sida är en plats och ett sätt där vi gemensamt, skribenter, läsare, fokusgrupp kan kan hitta en utvecklingsprocess för att implementera det som denna site beskriver. Alltså hur utvecklande roller kan bygga digitala produkter som löser de behov deras verksamheter har, inom informationsförvaltning, och utifrån de koncept och ideer som presenteras här. 

För detta krävs ett utforskande arbetssätt utifrån en rad insikter. Insikter som ’vad fungerar för en verksamhet’, ’vad i arkitektur, design, systemutveckling, agilt arbete, är tillämpligt i den domän vi behandlar är, alltså informationsförvaltning och dokumenthantering’ Osv. En rad olika insikter alltså och som behöver utforskas utifrån en designapproachering med insikter, ansatser, experiment och lärande. Sedan behöver arkitektur, design, systemutveckling tillföra kunskap om hur man gär.

För att få igång detta lärande är därför ansatsen att inte beskriva en utvecklingsprocess utan istället skapa en ’engine’ för att tillsammans med fokusgruppen vi etablerar, komma fram till vad det är vi behöver beskriva, i vilken form, som text, modeller, mallar, verktyg. 

Om vad utveckling börjar med

Utveckling börjar alltid med något slags behov, en verksamhet som vill förändra något för att effektivisera eller sänka kostand, eller byta ut ett system, eller att användare har hört av sig och vill ha en förbättring eller ny funktion. Utveckling kan vara större eller mindre, i ena änden av spektrat kan sägas finnas ’innovation’ alltså något helt nytt, och i andra ’funktionstillväxt’, alltså att ett på alla sätt väl fungerande system som behöver kompletteras kanske med bara en mycket liten ändring, låt säga en ny logotyp.

En bra modell som illustrerar utveckling är ’Service Blueprint’

En bra modell när det gäller att förstå vad utveckling av digitala produkter innebär är ’Service Blueprint’. Det finns många sätt att se, arkitekutramverk och andra med detta sätt omfattar på ett tydligt sätt alla olika delar och visar hur utveckling kan ske på många olika nivåer. Det är också lätt att hitta mer information om detta sätt på Internet. ”Service blueprints visualize organizational processes in order to optimize how a business delivers a user experience” och man kan dra detta vidare och säga att ’user experience’ innehåller elelment av användarvänlighet, färg och form men även produkter som utgör ett sammanhang, som är stabila och säkra. 

Illustrationen ovan kommer från ’nngroup.com’ så länge, men kommer ersättas med en egen illustration som är bättre.

Användare i ’Service Blueprint’

Längst upp finns användare och vad de ser, ’Evidence’ och vad de gör ’User Journey’. Det kan vara bra att tydligare illustrera användare än i modellen ovan. Men det viktiga är att det finns en linje ’Line of interaction’ som avgränsar var användare ansluter till verksamheten, där detta sker kallas också ofta ’touchpoints’. Det kan vara en websida, en telefonkontakt, en broscyr. ’Evidence’ handlar om vad användare är, befinner sig, ser omkring sig som ett kontor, att man använder en webläsare och ser en websida eller är på ett kontor. Man kan här också gärna illustrera kanaler, alltså internet, mobilabbonemang, röstsamtal och var användare är, dess situation, på bussen, hemma, på kontoret, hämtar på dagis. Allt detta som ger en kontext och förståelse för användaren.

Traditionellt i user journeys så brukar användare även ha ett mål, något som gör dem glada. Detta kan man gärna komplettera med och om man vill mixa andra format än i modellen ovan, t.ex det format som används i UML eller snarlikt ifrån ’Design Sprint’.

Verksamheten

Här är en svaghet med Service Blueprint och det är att verksamheten inte har någon direkt upplevelse eller mål. Här listas enbart vad verksdamehten gör för att anävndaren skall nå sina mål. Men verksamheter har också mål, som att ha en strategi kring hur kunder skall bemötas, erbjudande och kampanjer osv. Det kan vara bra att komplettera med detta.

Men huvuddelen här handlar om att beskriva vad verksamhetens medarbetare gör, olika roller, vilken teknologi de anävnder och sedan finns en ny gränslinje ’Line of visibility’ alltså vad kunden ser. Bakom detta finns olika typer av backoffice-aktiviteter och system och information som hjälper till att realisera tjänsten. 

Applikationslandskapet och Informationslandskapet

Detta är inte med i bilden utan hämtas från andra modeller. Men det är en viktig del och fungerar bra att komplettera Service Blueprint med. Det är dels applikationer, system och produkter som tillhandahåller, utför de tjänster som vi modellerar. Det andra är den information som behövs för att erbjuda tjänsten.

Vad är det nu vi har

Vi har nu en modell över en tjänst som vi vill realisera. En förbättring eller en helt ny innovation. Den är normalt i ett förstått nuläge så att vi vet var vi är, hur det ser ut, hur olika användare utför olika saker, vilka systemen är vi har osv. Den är grunden för att börja lära sig och för detta behövs ett team som arbetar tillsammans med användare, kunder, leverantörer, beställare – vi kan runt denna modell skapa den dialog och börja ändra, föreslå saker, prova på ett enkelt, snabbt sätt. 

Modellens detaljeringsgrad bör hållas relativt låg och abstrakt. För mycket detaljer gör den svårtydd. Det är bättre att göra flera olika, med olika detaljeringsgrad.

Utöver förståelse av behov och tekniska lösningar så har vi framför allt också sammanhang, interplays mellan användare och olika system och dessa kan vi nu börja diskutera för att förbättra, utveckla nya funktioner, tjänster, upplevelser, bättre tillförliglighet eller säkerhet. Detta kan då ske på olika nivåer.

Vad kan man göra mer med Service Blueprint

En service blueprint är till sin form schematisk men kan med fördel kombineras med andra modeller. Olika användare kan illustreras med olika ikoner. Grafik kan komplettera ’Evidence’ eller andra objekt. Själva modellen kan bli mera av en storyboard eller ett montage, eller moodboard. Alltså olika element och objekt och grafik eller text som tillför något kan läggas till, det viktiga är att experiment följer en linje, alltså att det tillför något till modellen och att man vet vad man är ute efter att tillföra så att kan man prova och lära sig om det också fungerar.

Hur kommer vi vidare med utforskande och lärande

Fånga insikter. Formulera som arbetsbara frågor. Sätt upp ansatser. Prova. Lär 

Nivån att ensa vertikala behov med system och produkter

Detta är kanske på ett sätt det enklaste och mest traditionella i utvecklingsarbete. Att vi förstår vad användare vill ha och behöver och att vi ensar system och produkter så att dessa har rätt funktioner och utför detta. vi kan från denna modell börja fånga krav och skriva specifikationer och testfall så att vi också när vi byggt eller köpt en ny produkt eller funktion och satt in i vår tjänst, kan verifiera att produkten blev rätt, att tjänsten utför det den skall. 

Detta är normalt produktutveckling på mera funktionell, teknisk nivå, eller gränssnitt/UX eller mjukvaruarkitektur.

Nivån och aspekten – Förändra verksamhetens beteende eller användarens beteende

Detta är verksamhetsarkitektur men också service design, tjänstedesign.

Nivån och aspekten – Förbättra eller förändra verksamhetens sätt

Detta handlar om att förenkla eller effektivisera hur verksamheten arbetar. Alltså vi kanske inte behöver köpa eller bygga nya system eller produkter utan genom att förstå vad medarbetare gör, vilka processer de har utveckla dessa, ändra aktiviteter, skapa ny eller använda befintlig information på andra sätt. Allt detta ser vi i blueprinten och hur de hänger samman med användare och systemen under, vi rör oss alltså och förändrar, utvecklar, föreslår och provar i mellanskikten. Det behöver alltså inte alls röra sig om teknik utan bara om hur vi förändrar hur vi gör saker. 

Detta är domänen kring verksamhetsarkitektur.

 Nivån och aspekten – Förbättra eller förändra verksamhetens system och information

De underliggande system och den information som dessa har är komplex och i blueprinten har vi en översikt över hur dessa hänger samman, var information finns, hur den rör sig. Detta kan vi använda för att förbättra, så att vi inte bara ensar en användares behov med en produkt och dess funktioner, utan hela verksamhetens inklusive kundens upplevelse, sätt, beteende kan vi modeller, föreslå förändringar, prova genom att förändra och prova och lära oss kring hur de olika systemen och information i applikation och informationslandskapet kan förändras och utvecklas.

Här rör vi oss kring lösningsarkitektur, informationsarkitektur, systemutveckling, devops. 

Två teser att börja med

För att komma vidare med ett utforskande arbetssätt och för att börja någonstans så måste vi utgå från insikter och sätta upp ansatser som vi tror löser de problem, möjlighegter, bevho vi fångat i insikterna. Två sådana teser finns här.

Det som redan står på denna sida är om två fundamentala teser och som förmodligen är sanna och tillämpliga men som är de första att behöva valideras genom lärande. Teserna handlar om ’att offentlig förvaltning och många andra verksamheter inte har erfarenhet eller är riggade för, utveckling’ och går vidare att börja karaktärisera vad en sådan utvecklingsprocess är genom att ställa den mot den mera vanliga processen kring förvaltning och vidmakthållande men som har stora utmaningar att åstadkomma förändring. Den andra tesen är kortare men handlar om vikten av medarbetare och att skapa en kultur av utvecklingsarbete, samt börjar belysa hur man kan gå tillväga, genom att lyfta utmaningar med KPI’er. 

Dessa två teser kan vara ett sätt att vi börjar utforska vad det är vi behöver skriva här. Eller så hittar vi något annat att börja utforska, men hittills är det dessa två som gäller. 

Det vi då behöver börja med är att sätta upp ett arbetssätt, inte att skriva artiklar, utan för ’continous product discovery’, utifrån de best practices som finns i branschen, t.ex från Teresa Torres. Det är förmodligen en blandning av att skriva artiklar, bloggar och sedan prova mot fokusgruppen, diskutera i forumet och tillhandahålla material, i form av förbättrade artiklar, nedladdningsbart material, kanske träffar/utbildning, kanske e-tjänster. Det får det vidare arbetet utvisa. Men första steget är att börja skissa på denna utforskande process, prova den och producera material.

Lite mera detaljerat utifrån t.ex insikten om vikten av team o hur de kan arbeta ihop kring utveckling o hur svårt ett fungerande teamarbete är. Eller insikten om utveckling vs förvaltningsprocess. Är det verkligen så. Är det ett stort problem. Det behöver vi ju lära oss o de som kan lära oss är läsare. Vi kan formulera frågor o läsare kan svara, komplettera formulera arbetsbara frågor o sedan kan vi börja prova.

Sedan ansatser på lösningar o prova dessa. Arbeta utforskande alltså gemensamt med läsare isf att som nedan börja beskriva ngt vi tror är sant, men vi vet ju inte om det är ett problem, om det är stort, ellre ngt om lösning så långt har vi inte ens kommit här.