Frukostseminarium – Informationsarkitektens roll inom data management

Vi bjuder in till ett frukostseminarium fredag 6 maj från kl 08.00 där vi tittar närmare på rollen informationsarkitekt och vilka områden rollen rör sig inom. Och vi ställer frågan; Var skulle informationsarkitekten kunna bidra mer?

Frukostseminariet är kostnadsfritt. En enkel frukost serveras från kl 08.00 och seminariet pågår 08.30-10.00.

Här kan du läsa mer om frukostseminariet

Följ denna länken om du vill anmäla dig direkt

Om begreppsanalys

Man kan inte göra en informationsmodell utan att analysera och definiera de begrepp som modellen rymmer. Som modellerare gör man egentligen alltid en begreppsanalys, medvetet eller omedvetet, genomarbetad eller slarvig, bra eller dålig. Begreppsanalys är på så sätt alltid en integrerad del av informationsmodellering. Låt oss göra det bra! Denna och följande artiklar ger den grund du behöver. 

Vad är begreppsanalys?

Begreppsanalys behöver inte alls ha något att göra med informationsmodellering. Vi kan göra det när helst vi djupare behöver förstå och definiera de begrepp som förekommer inom ett område. Vi gör det genom att reda ut hur begreppet ifråga förhåller sig till närliggande begrepp. 

Man kan som sagt tänka sig att man analyserar begrepp utan att det har något med en informationsmodell att göra. Men när vi informationsmodellerar är det omvänt, då måste vi alltid analysera och hantera begrepp. Man kan inte tänka sig informationsmodellering utan att det har en kärna av begreppsanalys i sig. Att arbeta med begrepp och språk är centralt för oss som tar fram informationsmodeller. Men det är sällan man behandlar det som ett ämne i kurser och böcker om informationsmodellering. Det är synd. Denna och följande artiklar vill fylla den luckan.

Informationsmodelleringens två perspektiv

Ett sätt att se på informationsmodellering är att vi analyserar och beskriver de företeelser som en verksamhet hanterar och vilken information som behövs för detta. För att göra det behöver vi tillämpa två olika perspektiv:

  1. Begreppsanalys: Vilka är företeelserna och vilka begrepp används för företeelserna och deras egenskaper, relationer och tillstånd? Vad betyder de ord vi använder? Behöver vi andra begrepp eller benämningar?
  2. Informationsanalys: Vilken information har vi, eller behöver vi ha, för att hantera företeelserna? Hur ska vi strukturera informationen på bästa sätt?

Ofta, i teoretiska beskrivningar av verksamhetsmodellering, försöker man hålla isär dessa två perspektiv. Man har då tänkt sig att man först gör en begreppsanalys och sedan, först då denna är klar, en informationsanalys som bygger på begreppsanalysen.

Men det är ett alltför teoretiskt synsätt för att vara gångbart i praktiken menar jag. Det handlar visserligen om olika perspektiv men i vår vardag som informationsmodellerare är dessa så ömsesidigt beroende av varandra att vi behöver jobba med båda perspektiven samtidigt. Vi behöver ständigt och sömlöst växla fram och tillbaka mellan dessa två perspektiv.

Men det hindrar inte att vi här och nu behandlar begreppsanalys som ett ämne i sin egen rätt. Detta för att vi riktigt ska förstå vad det handlar om.

Meningstriangeln

Centralt för begreppsanalys är att på djupet förstå skillnaden mellan termer och begrepp. Den bild som man då brukar visa kallas för meningstriangeln, eller ibland semiotiska triangeln.

Semiotik eller semiologi är studiet av tecken. Med tecken menar man i detta sammanhang inte bara det vi till vardags tänker på när vi säger tecken eller symboler utan också termer. Termer är de ord vi använder och är också att se som ett slags tecken eller symboler.

Tecken är allt det vi använder för att på ett eller annat sätt symbolisera, beteckna eller stå för ett begrepp.

Observera att när man inom semiotiken säger ”begrepp” menar man inte själva ordet (termen) utan det som ordet står för i vårt medvetande.

Triangeln kan också kallas Aristoteles triangel eller Ogden & Richards triangel.

Meningstriangelns tre hörn visar vad vi rör oss med när vi tänker på och benämner företeelser.

Dels har vi företeelserna i verkligheten. Det kan vara djuret katt. Sedan har jag på något sätt lärt mig att det finns något sådant och vad som utmärker det. Jag har bildat mig begreppet katt. Ett begrepp är alltså i detta sammanhang min föreställning, min idé om företeelsen i verkligheten, alldeles oavsett vad jag kallar den för.

Sedan har jag själva namnet eller termen som jag använder för att referera till företeelsen och kommunicera med (som man inom semiotiken ofta kallar tecken eller symbol):  ”katt”.

Dessa tre saker kan röra sig tämligen fritt i förhållande till varandra. Företeelsen i verkligheten finns där vare sig vi kan tänka på den eller har namn för den. Vi kan ha olika föreställningar om företeelsen. Man kan tänka sig att vi blandar ihop olika företeelser och därmed inte skiljer på dem i huvudet.

Framförallt är det viktigt att skilja på termer och begrepp. Vi kan ha olika termer för samma begrepp. Det kallar vi för synonymer. Till exempel ”katt”, ”cat”, ”kattracka”, ”kissekatt”.

Vi kan också ha olika begrepp för samma term. Det vill säga att en term har flera betydelser. Det kallar vi för homonymer. ”Katt” är enligt ordboken inte bara ett djur utan också en piska som använts som straffredskap till sjöss samt en talja varmed skeppsankare säkrades förr.

Den gemensamma förståelsen

Meningstriangeln säger dock bara vad som rör sig i mitt eget huvud, och relationen mellan min förståelse och det jag uppfattar och benämner. Vanligen är vi flera personer som behöver ha en tillräcklig gemensam förståelse (gemensamma begrepp) och ett gemensamt språk (gemensamma termer).

Men jag kan aldrig, i mitt huvud, komma åt förståelsen (begreppen) i ditt huvud, och du kan inte heller helt uppfatta förståelsen i mitt huvud. Det vi kan jobba med för att vara säkra på att vi har en tillräckligt bra gemensam förståelse är definitioner, det vill säga beskrivningar som bestämmer eller avgränsar betydelser, samt att vi hittar användbara termer som är så tydliga som möjligt för att förmedla denna gemensamma förståelse.

Skilj mellan begrepp och term!

Termer är de ord vi använder för att namnge företeelser. ”Katt” är alltså inte ett begrepp utan en term. Själva begreppet, vad en katt är kommer vi åt på ett annat sätt, genom en definition. Definitionen är kanske ”litet smygjagande rovdjur i familjen kattdjur”.

Vid modellering händer det alltid att deltagarna har olika uppfattning om termers betydelse, och vilka termer som är bäst att använda. Ett bra sätt att underlätta den dialogen är att skilja på diskussionen om begrepp och diskussionen om term, det vill säga att vi först säkerställer att vi diskuterar samma företeelse. Det gör vi enklast genom att först diskutera och komma överens om en definition. Om vi först kommer överens om att företeelsen vi diskuterar är ”person eller organisation som vi erbjuder våra tjänster”, så kan vi först därefter diskutera om den term vi ska använda är ”kund”, ”gäst”, ”besökare”, ”användare” eller ”brukare”. Det brukar bli lättare om vi gör på det sättet. Annars riskerar vi att tala förbi varandra.

Definitioner är viktiga. Det är vanligt att det med tiden visar sig att man menar olika saker med en term. Det är kanske den vanligaste orsaken till risker, fel, förseningar, skenande kostnader och strul i största allmänhet i projekt som omfattar integrationer av olika slag.

Kommande artiklar

Följande artiklar i denna serie kommer att handla om detta; Vad begreppsmodellering är, hur vi kan vårda och utveckla vår verksamhets begrepp och språk, hur vi hanterar begrepp och termer i våra informationsmodeller, samt hur vi kan skriva bra definitioner och ge bra namn på saker och ting.     

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 5 maj. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Informationsmodellering: Om hur vi kan representera mängder, sammansättningar och specialiseringar i ER-diagram

En företeelse kan ha ett nära beroende till en annan företeelse på ett eller annat sätt. Ofta vill vi se det som att den beroende företeelsen är underställd den andra. Det är viktigt att vi kan förmedla detta tydligt med grafiken i ett ER-diagram. Hur gör vi detta?

I ER-diagram uttrycker vi ju beroenden mellan entiteter med relationslinjer. Men vissa typer av relationer är annorlunda än andra. De innebär en tätare bindning. Jag tar upp dessa och diskuterar hur vi kan representera dem i ett ER-diagram.

Mängd (aggregation)

Det är ofta så att förekomsterna av en entitet ingår som en medlem i förekomsten av en annan entitet. Ett exempel kan vara böcker i en boksamling. En viss bok kan vara medlem i en viss boksamling.

I UMLs klassmodeller kallas det för en mängd (aggregation).
Medlemmen i en mängd har en egen oberoende existens. Det betyder att medlemmen (en bok) finns kvar då en förekomst av huvudentiteten (den boksamling den tillhör) upphör att existera. En medlem av en mängd kan också byta tillhörighet och bli medlem av en annan mängd, det vill säga lämna en boksamling för en annan.

Medlemmen (boken) kan visserligen sägas vara underställd mängden (boksamlingen) men bindningen är inte permanent. Den är inte existentiell. De vill säga att boken kan existera utan att den tillhör en boksamling, den kan byta boksamling och den kan fortsätta att finnas efter det att boksamlingen läggs ner.

Som jag tidigare har nämnt i artikeln ”Saker jag stjäl från UML” så finns det ingen mening med att se den typen av relation som någon som utskiljer den från andra typer av relationer. Martin Fowler ägnar en hel uppsats till att avfärda att ”mängd (aggregation)” skulle vara en form av relation som behöver markeras särskilt i ett klassdiagram. Självaste Jim Rumbough, en av grundarna till UML, liknade den särskilda symbol som UML använder för mängd, en ofylld romb, vid placebo. En mängd är helt enkelt inget annan än en vanlig association med en kardinalitet min 1 – max 1 , och därför är det tämligen meningslöst att ha en särskild symbol.

Men trots att bindningen inte är permanent så finns det ändå ett beroende som säger att boken är underställd boksamlingen. Jag tycker att det är viktigt att uttrycka det på något sätt och gör det genom att placera den underställda entiteten (bok) under den andra entiteten (boksamling) i ER-diagrammet.

Sammansättning (composition)

Det finns samlingar av förekomster som skiljer sig mot mängd på så sätt att en förekomst inte kan ha en egen existens. Det vill säga att medlemmen aldrig kan existera för sig själv, oberoende av den samling den tillhör, samt att den aldrig kan byta samling. Ett typiskt exempel är hur en fakturarad hänger ihop med en faktura. I UML kallas den konstruktionen sammansättning (composition) och markeras i UMLs klassdiagram med en fylld romb. (Observera att jag använder en ofylld romb, eftersom Microsoft Visio saknar fylld romb som standard för start eller slut på linje.) 

Observera att det är en helt annan typ av relation än en vanlig association, och också annorlunda än en mängd. Jag tycker att det är en så pass annorlunda relation att den behöver markeras särskilt i en informationsmodell. Jag är inte ensam om detta. De flesta notationer för ER-diagram har sina egna sätt att markera detta.
Jag kör UMLs variant med en romb, men eftersom en fylld romb inte finns med som standardalternativ i MS Visio brukar jag ta mig frihetet att använda en ofylld romb i stället.

Vanlig layout av hierarkier

Mängder och sammansättningar bildar ofta hierarkier i flera nivåer. Här är ett exempel på hur detta kan gestaltas i ett ER-diagram. Lägg märke till att skiv- och boksamlingar är mängder, det vill säga att CD-skivor och böcker existerar oberoende av om de finns med i några samlingar eller inte. De är alltså vanliga mängder och behöver därför ingen särskild symbol. Detta till skillnad mot spår på en CD-skiva eller kapitel i en bok. De försvinner då man raderar skivan eller boken. De är således sammansättningar (compositions) och relationen är därmed av en helt annan natur och förtjänar att märkas ut särskilt. Vilket jag som sagt gör med en romb.

Det är vanligt att man gestaltar hierarkier i ER-diagram som exemplet visar, i vertikala kolumner. Men jag använder ofta en annan layout, som jag presenterar i det följande.

Alternativ layout av hierarkier

Här är exakt samma hierarki som i föregående exempel men där entiteterna placerats med indrag i förhållande till de entiteter de är underordnade. Detta sätt att rita ger fördelar menar jag, speciellt i lite mer omfattande ER-diagram.

Dels kan det ofta bli en mer kompakt layout, och dels kan det ge en tydligare ordning. Speciellt då man behöver dra många relationslinjer från entiteterna i hierarkin till andra delar av ER-diagrammet. Entitetsrutorna blir då inte lika mycket i vägen för varandras relationslinjer som då de ligger ordnade i kolumner och rader. Fördelen framgår kanske inte så tydligt i detta exempel, men jag har funnit det användbart. Att kunna ha många olika alternativ till hands för hur man kan placera entiteter i förhållande till varandra ökar vilken uttryckskraft vi kan få till för att förmedla hur sake och ting hänger ihop.

Specialisering (subtypning)

De finns en helt annan typ av relation mellan entiteter. Det är när en entitet (subtyp) är en mer specialiserad variant av en annan entitet (supertyp).

Ett exempel kan vara att faktabok och skönlitterär bok (subtyper) är två specialiseringar av bok (supertyp).

I UML markeras det med en ofylld triangelformad pilspets i änden på associationslinjen i riktning mot supertypen. Jag använder den symbolen när så är lämpligt. (När jag inte använder notationen att subtypen är inskriven i supertypen.)

Specialisering kan som exemplet visar ritas med indrag på samma sätt som jag visat ovan för mängd och sammansättning.

Exempel från verkliga informationsmodeller

Här har vi två exempel på hur hierarkier med indrag kan se ut i verkliga diagram.

Hur gör du?

Det här är ju till stor del mina egna idéer om hur man i ett ER-diagram kan representera olika vanliga strukturer hos företeelser i en verksamhet. Du har säkert andra idéer. Berätta gärna!

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 28 april. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Historier från dataträsket del 3: Hur jag lärde mig ”Non-invasive Data Management”

När man bygger upp en förmåga i en verksamhet bör man inte forcera utan låta förmågan mogna fram.

För femton år sedan hade jag en roll som informationsarkitekt på ett finansföretag. Där fanns det mycket att hugga tag i. Företaget hade slagit ihop företag i olika länder och hade i och med det flera olika system och produktportföljer.

Problemområdet

Ett problemområde på detta företag var produktdata. Om man tog ut en lista på alla produkter de hade sålt så blev det över tusen.

Eller var dessa egentligen inte produkter? Kanske var det olika varianter av ett något mindre antal produkter. Vad var det egentligen som bestämde ifall två olika tjänster man erbjöd kunderna skulle ses som två olika produkter eller två varianter av en och samma produkt? Och kunde man samla produkter i olika produktprogram? Kunde man klassa dem som olika produkttyper enligt något kriterium?

Och vilken livscykel kunde en produkt ha? Man behövde ju kunna skilja på produkter som erbjöds och sådana som inte längre erbjöds, samt de som av någon anledning tillfälligt var ur spel. Och vilken standard skulle man ha för att ge produkter namn, både interna och externa namn?

Det fanns ingen ordning på allt detta, eller i varje fall ingen gemensam överenskommen ordning. Det var därför svårt att analysera hur produkterna presterade, och att över huvud taget överblicka och hantera produktportföljen.

En arkitekt tog fram hela listan med produkter (eller om det nu var produktvarianter?), och började sortera dessa i Excel för att försöka finna någon ordning. Han gav dock upp efter några dagar och jag fick ta över.

Min första idé: En tentativ produktkatalog

Men hur skulle jag nu få ordning på detta? Hur skulle jag gå till väga? Vem skulle kunna ge mig kriterierna för att bygga upp den produktstruktur som behövdes?

När man ska utreda något komplicerat är ett bra sätt att påstå något på prov, komma med en hypotes, som man låter sakkunniga kritisera. Det är lättare än att utifrån ett blankt papper fråga hur det ska vara. Ty sakkunniga kan ofta inte förklara hur de vill ha det, i varje fall inte så jag kan förstå. Men de kan alltid, när det jag presenterar för dem, se vad som är rätt eller fel. 

Jag skapade därför något som jag kallade för Product Catalogue vilket bara var ett Word-dokument med ett kapitel för varje produkt och med listor av varianter under dessa. Det vill säga vad jag förmodade, eller snarare killgissade, kunde ses som produkter.

Min andra idé: Produktcheferna är de viktiga intressenterna

Med denna katalog gick jag så till de jag trodde borde kunde ha intresse av detta, nämligen produktcheferna. Så här gick det:

Jag: Det borde vara viktigt för dig att förstå vad din produkt är för något.

Produktchefen: Nej, inte ett dugg.

Jag: Nu förstår jag inte alls. Varför inte?

Produktchefen: Så här går mitt jobb till. Jag ser ett behov hos kunder. Om vi inte har en produkt som möter det behovet, och finner det intressant att erbjuda någon sådan, så vi fram det som behövs. Och jag struntar fullständigt i om ni vill kalla det för en ny produkt, en variant av en befintlig produkt eller något annat.

Jag blev lite chockerad över svaret, men mest över hur fel jag tänkt. Hur skulle jag då göra? Vem var det som behöver ordning och reda i produktstrukturen, och kan hjälpa mig med hur denna ordning skulle se ut?

Min tredje idé: Affärsanalytikerna

Efter lite trevande hittade jag de som verkligen var intresserade av ordning och reda i produktstrukturen. Det var affärsanalytikerna, de som gjorde analyser och tog fram rapporter om hur olika produkter presterade. De hade idéer om vad en produkt borde vara, och allt annat runt klassificering och indelning av produkter.

Då fick jag ett spår att hålla mig till. Jag visade dem min tafatta indelning, de pekade ut vad som såg fel ut, och jag gjorde om strukturen och namngivningen. Så höll vi på ganska många vändor tills det såg riktigt bra ut. Ur detta kunde jag härleda vilka karakteristika som definierade en unik produkt, samt en massa andra regler för att styra produktstrukturen.

I katalogen tog jag även med gamla och för länge sedan utgångna och ofta exotiska produkter, och många undrade varför. Jag tyckte att det var viktigt för att förstå hur produkter kunde variera. Den struktur vi tog fram behövde vara hållbar över tiden. Den skulle ju även kunna härbärgera framtida produkter och vi måste därvid ta höjd för alla tänkbara variationer.

Vem skulle äga produktstrukturen och produktkatalogen?

Utöver affärsanalytikerna var det inte just någon som visade intresse. Arbetet flög under radarn. Det var ingen som hade beställt det. Tanken från min sida var att få någon som kunde vara ägare och förvaltare av produktstrukturen, inklusive namngivning etcetera. Det vill säga någon att gå till då man ville ha en ny produkt. Någon som kunde säga: ”Men då blir det inte en ny produkt utan en variant av den här produkten.” Och ”namnet på produkten ska följa den här regeln”, och så vidare.

Samt förstås att i längden skapa ett digitalt produktregister.

Vi fick själva agera som ägare tills vidare

Att hitta ägare till produktstrukturen och produktdata var svårt. Jag och en medarbetare bland informationsarkitekterna tog till slut själva ansvar och agerade som ägare tills vidare. Vi berättade vad vi gjorde och varför, så fick den som hade något att invända protestera. Sedan gick tiden. Affärsanalytikerna fick så småningom förtroende för allt vi gjort, inte bara med produktstrukturen utan också allt annat vi modellerat, och hur det gav ordning åt det BI-program som vi stödde. Från början hade de varit både ointresserade och skeptiska. Detta då de inte haft någon vidare bra erfarenhet av it-sidan över huvud taget. De tyckte inte att de fick tillgång till de data de ville ha. Men när de såg vad vi gjort och att det gick framåt blev de intresserade.

Produktkatalogen blev prioriterad

En händelse inträffade som gjorde produktkatalogen till något prioriterat. Företaget fick en ny produktchef. På ett möte med hela företaget sa han att han låg och studerade produktkatalogen på kvällarna, för att förstå vilka produkter vi hade. Genast fick produktkatalogen uppmärksamhet och prioritering hos både it-ledning och verksamhetsledning.       

Vi fick ägarskap

Och plötsligt en dag fick vi en ägare till produktstruktur och produktdata. Det var en av informationsarkitekterna som på ett möte med verksamheten sagt att vi behövde en ägare. Och de flesta på mötet förstod inte alls vad hon pratade om. Mötesledaren började fråga runt bordet om någon förstod det hela. Vad var det som skulle ägas, vad innebar ett ägarskap och varför var det viktigt?

Chefen för affärsanalytikerna var den som inte såg ut som en fågelholk i ansiktet och sa: Javisst, det är klart vad det är. Och det är viktigt. Raskt blev hon utsedd till ägare.

Det var precis rätt person och på rätt plats i organisationen. Och vid rätt tidpunkt. Vi hade inte forcerat fram detta utan låtit detta mogna fram. Det löste sig på så sätt naturligt då organisationen och personerna blev mogna för den rollen.

Vad jag lärde mig

Sensmoralen i denna historia är enligt mig:

  • Be inte om lov för att göra det du vet behöver göras. Gör det ändå.
    Ingen hade bett mig om att ta fram en produktkatalog. Ingen trodde att det var möjligt eller att det skulle ge någon nytta. Ingen förstod vad det var och att det var möjligt att skapa något sådant. Ändå var det precis vad de behövde och förmodligen hade det inte kunnat göras på något annat sätt. Att skapa något nytt kräver envishet och att man vågar tro på det man gör, trots motgångar.
  • Forcera inte fram ägarskapsroller och befattningsbeskrivningar. Låt det mogna fram i organisationen. Men gå före och visa vägen, på ett konkret och praktisk sätt.
    Det är inte bra att bara utnämna någon till informationsägare. Det behöver mogna fram. Bob Seiner, en auktoritet inom Data Management kallar den strategin för ”Non-invasive Data Management”. Egentligen behöver allt mogna fram när det handlar om verksamhetsutveckling. Man ska aldrig forcera fram saker. Det blir inte bra om organisation och människor inte hänger med i svängarna. Man får då en organisation på papperet men som aldrig kan fungera på riktigt. Men inget mognar fram utan att man är där och går före, sår frön, vattnar, gödslar och binder upp det som spirar.
  • Vänta tills turen dyker upp, men förbered dig så att du är beredd när den kommer.
    En ny produktchef gjorde att produktkatalogen fick prioritet. Men det hade aldrig hänt om jag inte tagit fram den innan, utan egentligt lov och utan egentligt mandat.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 21 april. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Historier från dataträsket del 2: Hur jag lärde mig vad som är viktigt i ett dataintensivt projekt

Vad är egentligen viktigt i ett projekt som involverar data i stor mängd?
Det här är en historia jag brukar dra ibland. Den handlar om banken som gick vilse och hittade rätt igen.

Det var 00-tal och jag hade ett uppdrag på en större bank. Jag fick då en förfrågan från en annan del av banken om jag kunde ta ett annat litet uppdrag vid sidan om.

Bakgrunden

På den tiden hade alla banker gjort vad de kunnat för att uppfylla kraven för regelverket Basel 2.
En anpassning till Basel 2 krävde omfattande analys- och rapporteringsmöjligheter och därmed en mycket genomgripande integration och analys av data från många olika källor. Att inte uppfylla de hårda kraven, att bli underkänd av Finansinspektionen, skulle bli mycket mycket dyrt för banken.

Banken hade genomfört ett mycket trassligt Basel 2-program och klarat kraven men endast nätt och jämnt, och med många anmärkningar. Finansinspektionen hade en dryg lista på åtgärder vilka man krävde att banken skulle åtgärda omedelbart, för att inte sänka bolaget.

Ledningen var nervös och hade skapat ett särskilt team, en ”special task force”, för att hantera problemen. Men tiden gick och de hade inte kommit någon vart. Teamet, som bestod av olika mellanchefer, förstod varken problemen eller vad man kunde göra. Av någon anledning vände man sig till mig, och bad mig att utreda saken. Jag tyckte inte att jag hade tid och tackade nej. Men de återkom efter några veckor och bad mig på nytt om jag i varje fall kunde göra en snabbutredning. Denna gång kunde jag inte tacka nej.

Mitt uppdrag

Det var bara att börja. Jag fick namn på några nyckelpersoner jag kunde intervjua. Både sådana som varit med om själva Basel 2-projektet och som hade tagit fram lösningen, och de som ingick i det förvaltningsteam för lösningen som jobbade med att försöka komma till rätta med bristerna.

Vad jag fick reda på om det genomförda Basel 2-projektet

På så sätt fick jag så småningom reda på hela historien, utifrån olika synvinklar. Projektet visade sig ha varit något av en mardröm. Det här var en bank med en stor och kompetent it-avdelning, väl rustat för ett sådant stort projekt. Man hade egenutvecklade system som fungerade bra, och utvecklade nya lösningar i god takt.

Men när det kom till Basel 2 hade något gått snett mellan verksamhet och it. Jag fick inte klarhet i precis vad som hade hänt. Det gick rykten och det hela var ett känsligt ämne. Kanske att it-sidan inte fick den budget de tyckte att de behövde för att genomföra den stora förflyttningen. Kanske att it-folket då upplevdes som krångliga att jobba med. Verksamhetsledningen vände sig i stället till en it-leverantör som sade sig ha ett standardsystem som hade en färdig lösning för Basel 2. Leverantörens säljare påståstod att de skulle genomföra projektet på tre veckor. En vecka för dataanalys, en vecka för att konfigurera systemet och en vecka för att ta fram de rapporter som krävdes. Jag tror att det kan ha varit detta som fick it-avdelningen att helt och hållet ta sin hand från allt som hade med Basel 2 att göra.

Det tog såklart lite längre tid än tre veckor. Leverantörens folk hade mycket dålig kunskap om hur man genomför ett sådant stort projekt. Och de fick nog inte mycket hjälp från it-sidan, skulle jag tro. Ryktet sa till exempel att leverantörens folk först ett år in i projektet förstod att bolaget hade verksamhet i fler länder än Sverige.

Men efter två års arbete fanns det inte mycket att göra, alla tidsfrister hade gått ut och man fick med knapp nöd godkänt av Finansinspektionen, fast med en lång restlista.

Vad jag fick reda på om Basel 2-lösningens ursprungliga förvaltningsteam

Efter driftsättningen hade man skapat ett särskilt förvaltningsteam som skulle beta av problemen. Det verkade som om it-avdelningen fortfarande inte ville ta ansvar på riktigt utan bemannade med folk från lite olika håll, bland annat från ett uppköpt bolag. När jag kom in i bilden hade detta pågått till ganska nyligen och upplevelsen var att de inte kom framåt, trots en stor bemanning. Och Finansinspektionen låg återigen på och hotade med stränga åtgärder.

Jag intervjuade några som varit inblandade. De vittnade om att arbetsprocessen för förvaltningen hade varit mycket byråkratisk. Den leddes av personer som inte hade det pragmatiska sättet att samarbeta som de var vana vid. Verksamheten, som till största delen var bankens riskanalytiker, var frustrerade. De var tvungna att komma in med en skriftlig begäran om vad man ville ha gjort innan teamledaren initierade åtgärd. Riskanalytikerna visste sällan själva vad som var felet och hade därför svårigheter att ens specificera vad de ville ha gjort. Och att föra en dialog med förvaltningsteamet var tydligen helt uteslutet. Förvaltningsledaren ville ha en tydlig och kontrollerad inkanal och en process som förhindrade vad han upplevde som smitvägar.

Den överraskande vändningen

Så här hade det varit fram tills ett par månader innan jag blev inkopplad. Bolagsledningen och den särskilda utredningsgruppen var vid det läget stressade. Kraven från Finansinspektionen tycktes vara omöjliga att uppfylla av förvaltningsteamet, trots en stor bemanning och skenande förvaltningskostnad.

Men det hade just då hänt något som ännu inte nått deras öron. Något som i ett slag förändrade bilden. Jag fick reda på det hela från riskanalytikerna.

Teamledaren från förvaltningsteamet hade gått hem på föräldraledighet. It-ledningen hade då passat på att ändra bemanningen. Man hade tillsatt en förvaltningsledare som var mycket mera smidig, samt skickat in två erfarna män i teamet för att leda arbetet rent praktiskt. Då förändrades allt i ett slag.

Det intressanta var vad de två garvade männen kunde och vad de gjorde. Och än mera intressant vad de inte kunde. De hade inte alls den kunskap man kanske skulle kunnat förvänta sig ge resultat. De hade inte kunskap om vare sig Basel 2-regelverket, Basel 2-lösningen eller Business Intelligence, som det ju i mångt och mycket handlade om.

Men i stället kunde de något annat, vilket visade sig vara det viktiga. De hade god kunskap om bolagets alla operativa system, och de källdata som fanns där och som födde Basel 2-lösningen. Och de visste vem de skulle ta en snabbfika med för att reda ut det de inte visste. Och framför allt, de hade ett helt annat arbetssätt än förvaltningsteamet hade haft fram till dess. I stället för att vänta på en beställning på exakt vad verksamheten ville ha gjort, förde de en dialog med de viktiga verksamhetsanvändarna, det vill säga riskanalytikerna. De ställde sig framför en whiteboard tillsammans med verksamhetsanalytikerna och diskuterade problem och lösningar. Riskanalytikerna jublade över skillnaden. Att det inte längre handlade om en envägskommunikation där en part ställde krav och den andra parten levererade lösning. Utan att man tillsammans diskuterade problem och möjliga lösningar och prövade dessa i små steg.

Dessa två medelålders män hade inte gått någon Agile-kurs. Jag är osäker på om de ens hade hört talas om moderna agila arbetssätt. Men de visste av erfarenhet att ett tätt och kontinuerligt tvär-funktionellt samarbete var det som krävdes.  

Så allt gick helt plötsligt åt rätt håll nu. Det fanns mycket att göra, men man betade av saker och ting i en stadig takt.

Min rekommendation till ledningen

För mig var det bara att avsluta utredningen och skriva rapport. Jag föredrog för utredningsteamet och it-ledningen vad jag kommit fram till. Det är nog det trevligaste jag någonsin rapporterat. För jag rekommenderade att man bara hade att fortsätta på samma sätt. Det fanns mycket att göra framöver, men det hände saker, och allt var på väg åt rätt håll. Fast mitt budskap att man inte fick skära ner budgeten förrän man kommit längre i att beta av problemen fick några pannor i församlingen att rynkas.

Vad jag lärde mig

Sensmoralen tycker jag är följande: Kunskap om data är avgörande, viktigare än annat, i alla satsningar som är dataintensiva. Och kanske ännu viktigare är ett nära och informellt och interaktivt arbetssätt.

Allt annat väger ganska lätt. Samt: Lita inte på standardsystem-säljare. De vet sällan vad de talar om.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 14 april. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se