Detta är en bakgrund till varför vi vill adressera digitalisering och vad det innebär kring utveckling, utifrån av vad vi tror behövs för att få digitalisering på plats och med fokus på några egenskaper vi ofta ser saknas, eller är underrepresenterade i verksamheter. Vi tror att verksamheter ofta är rätt bra rustade, men vi ser återkommande mönster på vad som saknas. Det som fungerar adresserar vi inte direkt, kanske indirekt och emellanåt och allmänt, men vi koncentrerar oss på vad vi tror behöver stärkas. 

<Den här sidan beskriver vad vi sett kring att digitaliseringsprojekt ofta har utmaningar. Det kan vara att projekt misslyckas och då i bred mening där misslyckas kan vara allt från mindre annoyances till att det löser helt fel problem eller inte funkar alls. Och allt däremellan. Det finns en rad exempel. Gartners 70%. Att leverantörer inte håller vad de lovar i en upphandling. Att användare inte upplever att det är användarvänligt. System som inte passar ihop eller där man får mata in information flera gånger i olika system. T.ex Kajsa D i Studio Ett den 23 juni 2022, c:a 59 min in i programmet. (Beskriv fler exempel här och kanske mera ifrån just informationsförvaltningens domän)
Men det kan också vara förseningar, att projekt drar över kostnad, eller att det bara finns en osäkerhet inom organisationen hur projektet egentligen går, om det verkligen löser rätt problem som då inte visar sig förrän vid release. Eller att det är svårunderhållet, eller svårt att lägga till nya funktioner.


Vi menar att detta inte har några enkla, tydliga orsaker utan är ett komplext problem. Det är sällan eller aldrig enskilda medarbetare eller team utan nästan alltid ett systemiskt problem. Vi menar också att det går att beskriva några typiska scenarios C-formade organisationer, Gapet mellan Verksamhet och IT, X/Timglas/Martini-organisationen. Dessa är på samma sätt lika och på samma sätt unika orsaker. 

Vi menar dock att det finns en rad olika mindset, metodiker, verktyg och kunskap att hämta från branschen som nu ändå hållit på sedan 60-talet och där just denna typ av problematik uppmärksammades redan i mitten på 60-talet, med Brooks och Conway t.ex. Vi tror att dessa olika metodiker och verktyg kan göras användbara, erbjudas till egentligen vilken verksamhet som helst, och fås att fungera i dessa verksamheter. Det kräver dock några steg som dels beror på oss som leverantör och som tillhandahåller paketering, anpassning av dessa metodiker och verktyg. Också en modell där verksamheter kan skatta sin egen förmåga och därifårn se vad de behöver stärka, och hur de kan prioritera dessa insatser. Detta arbete är gemensamt med verksdamheten och en slags guide eller mentor-roll.

Det vi också menar oss se är att när verksamheter vill förbättra sig på dessa områden så är ofta alternativen färdiga, ofta stora, ramverk, ofta från en leverantör med 'sin' metodik och ramverk, omfattande omorganisationer, nya roller och kompetenser som skall hamna på plats. Detta har flera problem. Dels att dessa ramverk har en tendens att fokusera på ett område, att de inte helt förstår vad det bakomliggande problemet egenltigne är, eller de specifika omständigheterna i en viss organisation. De kan också vara för smala och bara adressera att problemområde nrä det nästan alltid finns flera. Det finns flera nackdelar. Men givetvis också fördelar och vi vill använda det som fungerar och väljer aboslut inte bort något.

Det vi dock tror är en bättre väg är att vara oberoende från stora, specifika ramverk eller metodiker eller att bara adressera vissa områden. Istället vill vi försöka tillhandahåller informaiton om vad de olika områdena som man behöver adressera är, och hur man gör, förslag på mindset, metodiker, vekrtyg. Sedan guida verksdamheten i hur de smidigast kan stärkas. Genom att ta in nya medarbetare och roller, kanske. Men förmodligen finns redan kompetens osm kan stärkas, det är inte alltid man behöver förstå all teori bakom en teknik utan kan anävnda verktyg som löser behovet ändå.

Vi vill därför också använda oss av dessa sätt och metodiker när vi hjälper verksamheter, och hämtar därför inspiration från arkitektur, den agila rörelsen och designrörelsen. Och med vissa specifika metoder, som Lean Startup, arkitekturramvker, User och Participatory design.

Vilka specifika metoder och verktyg som en verksamhet sedan väljer och hur de väljer att lära sig är upp till dem. Vi vill vara agnostiska där och mera fungera som guider. Det vi dock kan göra är att bidra med erfarenhet hur man bör eller inte bör göra, t.ex vad som krävs för att få en Design Sprint att fungera eller Design Thinking som ofta presenteras på ett lättvindigt sätt men som kräver en rad saker på plats för att fungera i praktiken. 

Detta vill vi adressera genom dessa inledande sidor om hur man framar problemet. Det finns sedan referenssidor kring hur vi tror att man skall gå tillväga, och fördjupningar i de olika områdena kring metoderna och verktygen. Men framför allt så beskriver vi detta utifrån Informationsförvaltningens perspektiv, även om mycket är allmängiltigt, så är det detta som är kontexten på denna website. Och vi utgår därför också för det som bäst beskriver hur man närma sig digitalisering inom denna domän genom att utgå från DIRKS och beskriva löpande i texterna som behandlar den övergripande ledning och styrningen av informationsförvaltning.

Det kan givetvis också vara så att alla projekt faktiskt alltid lyckas och är framgångsrika. Men isåfall så kan det vara läge att förbättra och optimera och även då kan det vi beskriver här vara till hjälp.>

Helhet

Detta är vad som beskrivs i positioneringen, det som ‘Lilla Magellanska Molnet’ och ‘Stora Magellanska Molnet’ beskriver i modellform. Samt Stora magellanska som vcisar att en org har flera sådana här. Alltså, det är konturer av allt som behövs, från ledning ner till drift och leverans. Detta går att förenkal och förstå för att också kunna hantear och göra bättre. Denna modell är inte komplett, eller särskilt detaljerad men räcker för nu. Och. Det finns ett temporalt. Vi har arv, skeende, framtid och detta missar vi ofta. Detta är perspektiv som främst IT-arkitektur adresserar coh vi hämtar ifrån.

Utvecklingsmässiga timglas

Detta är ett annat perspektiv som brukar benämnas ‘the gap between business and IT’ och handlar om överbyggnad och bas men en del brister och kompetenser däremellan som för att verksamhet och IT pratar förbi varandra, bland annat.

En annan bild är av ett ‘C’ där det finns en överbyggnad i form al Ledning, styrning och som beställer men som bara har en väg, eller huvudsakligen en väg, ner till de som skall utföra, IT-avdelningen och att denna väg är via produktledning, projektstyrning. Förmåga att fånga behov brister. Men projektledning, produktchefsskap finns ofta på plats. Likaså IT, drift, förvaltning och i viss mån utveckling/upphandling. Detta blir alltås en slags C-format organisation. Detta ansluter också till Conways lag som talar om vilka kommunikationsvägar som finns i en organisation och hur utveckling och digitalisering beror på detta.

En annan bild är av ett timglas. Löst och vagt formulerade nyttor, effektmål skickas ner till IT, utvecklare, drift och förvaltning. Detta yttrar sig typiskt som spräckta tidplaner när utvecklare börjar försöka att själva förstå vad som menas, upptäcker att det finns oklarheter osv. och allt tar tid. Detta leder till system och applikationer som blir felaktiga, stressas ut och blir buggiga eller dåligt genomförda upphandling som missar viktiga funktioner. På lite annan nivå, system som inte pratar med varandra, eller tvärtom har ohanterade beroenden som orsakas systemfel, plötsliga driftsstopp. På ännu en annn nivå skapa det frustration när system inte hänger ihop, information blir olika, hamnar fel eller inte hamnar där den skall eller samma sak måste göraas på flera ställen. På ännu en nivå – vi bygger eller köper fel system, arbetssätt, produkt. Vi löser fel behov. Därför att vad behovet egentligen var inte har förståtts.

Att det blir så här har många olika orsaker, som omedvetenhet, att man underskattar problemet, i viss mån benägenhet och personliga egenskaper, kanske en viss avsaknad av självinsikt. Givetvis också kostnad. Och kanske framför allt, en mänsklig egenskap eller brist som handlar om att vi tenderar att bara se en typ av problem – men det finns i grunden tre problemtyper som kräver radikalt olika sätt att adressera o som det står mera om i kap X (– ’enkla problem’ av typen fixa en läckande vattenkran.)

Detta adresseras med flera roller. Arkitektur i nära samarbete med Tjänstedesign/UX/Användbarhetexperter. Roller som av olika skäl inte får genomslag i organisationer. Organisationen byggs då inte heller med kommuniaktionsvägar för dessa roller och kan därmed inte heller skapa system och arbetssätt enligt de linjer som dessa roller och kompetenser tillför. Det står mer om detta i Organisation och utifrån Conways Lag.

V-modellen

IT-branschen i någorlunda modern tappning har funnit på plats sedan mitten av 60-talet. Då började också personer att engagera sig i att förstå varför det inte är så enkelt att ta fram digitala system som fungerar och är användbara. Sedan dess har V-modellen funnits på plats i branschen, på andra håll finns precis samma mekanism men med andra namn, på andra sätt.

I grunden handlar det om en kadens av hur man bryter ner problem och löser dem. Samt hur man gör detta metodiskt. Samt att all mänsklig aktivitet som skall utföras kvalitettsäkrat behöver uppföljing och påföljd. V-modellen har därför två spår – <illustrera med bild.>

Återigen, att detta ibland saknas helt, inte är riktigt fungerande beror på ungefär samma orsaker som timglaset. Detta adresseras återigen med roller som arkitekter på flera nivåer, tjänstedesign/UX men också klassisk systemutveckling med roller som lead- developer, testroller, projekt/team-ledarskap.

Materialkunskap

Med materialkunksap menar vi att digitalisering per definition handlar om ’digitization’, alltså hantering av information i digitalt format och med tekniska system. Alla verksamheter måste ha en medvetenhet, en insikt om vad det är för möjligheter och begränsingar i de produkter de tillverkar och tillhandahåller. Inte minst när det gäller digitalisering är detta svårt eftersom det är ett på många sätt abstrakt, osynligt, svårgreppbart material. Det finns många exempel på hur detta både fungerar och inte fungerar. Vasaskeppets holländska skeppsbyggare som beordrades av beställare att lägga till ett kanondäck. Apples VD från Coca Cola som var bra på marknadsföring men inte förstod produkterna. Organisationer som har som princips att alltid hämta ledande roller från tekniska avdelningar.

Med detta menas inte att alla i en verksamhet skall kunna utveckla system. Men, det måste finnas en insikt och en medvetenhet i hela organisationen om vad som faktiskt krävs av utvecklare att ta fram produktionskod. Denna kan förmedlas på olika sätt, att som P-G Gyllenhammar regelbundet besöka det löpande bandet i Torslandafabriken och som utvecklas i Toyotamodellen. Roller som IT-arkitekter, tjänstedesigners som kan förmedla, ta tillvara, ställföreträda. Lead Developers som har en mera aktiv del i verksamhetens ledning. Det finns olika sätt men oavsett hur är detta fundamentalt.

Här finns också en rad företeelser som både kan belysa, som behöver adresseras. Att vissa begrepp får ett eget liv i en verksamhet och kan styra på gott och ont. Exempel på detta är ’api’ som emellanåt används av roller som inte alls förstår vad det egentligen innebär, men kanske hört och tror de förstår, och som sedan blir till krav typ ’Systemet skall ha api’…

Sammantaget

Idag är lite av en patentlösning att ’bli mera agila’. Men agilitet handlar i grunden om saker som vi ofta ändå gör, vi bara sätter begrepp, talar om det, framför allt experimenterar i mycket stor omfattning. I grunden löser dock agilitet inte någonting som vi inte redan har lösningar på. Och, agilitet löser inte alla de problem som arkitektur, tjänstedesign eller teknisk kompetens tillför. Även om dessa roller ofta har lättare att komma fram och få en plats i agila organisationer.

På 90-talet skrevs boken om Ratioonal Unified Process, RUP och som fortfarande är synnerligen läsvärd. Den blev dock i viss mån fel tolkad och var kanske en direkt avgörande orsak att den agila rörelsen startade i böjran av 2000-talet. Vi skall inte gå in på detta här, det är alltför laddat ämne men det viktiga är att bheålla perspektivet. Skall vi gå på djupet här så måste vi gå tillbakaa till det grekiska tänkande före Platon, det som kallas ’fronesis’ och hör ihop med ’techne’ och ’episteme’ men detta går vi inte in på här. Våra insikter och vår ansats är uppbyggd kring en kadens av ’mindset’-’metodiker’-’verktyg’-’skills’. Vi bygger alltså på grundläggande mindset men som vi inte alltid utvecklar, dock försöker referera till när det behövs. Vi tar sedan fram metodiker, där vi inte alltid beskriver hur dessa fungear heller. Denna webplats skall vara en praktiskt resurs coh vi fokuserar därför på att beskriva och tillhandahålla verktyg och att läsarna och användare skall skapa färdigheter.

För den som är intresserad vill vi dock nämna en bok som sammanfattar både innovataion, designtänkande, arkitektur, problemförståelse och användbarhet – Design Way av Stolterman, Nielsen

Så. Detta adresserar vi genom att:

• Positionera gentemot IT i stort, domänen Informationsförvaltning.
• Beskriva en matris av egenskaper och förmågor, från roller till arbetssätt som vi anser är där det brister mest. Övriga delar adresserar vi som sagt bara för referens.
• Tillhandahålla en metodik, ett verktyg där verksamheter kan skatta sin egen uppfyllnad, sina brister och börja en praktisk, metodik/leverantör/konsult-agnostisk utvecklings-envelope
• Utgå från ett T-shape tänkande. Dvs adressera en vertikal, dvs helheten men genom en specifik.

Läs vidare om hur vi positionerar det vi vill adressera kring digitalisering: Digitalisering – Positionering