Historier från dataträsket del 1: Hur jag lärde mig att verksamhetsexperter inte kan allt

Jag tänker att jag i några artiklar ska berätta några historier som jag varit med om, och som man kan reflektera över. Först ut är historien om hur jag på ett ganska brutalt sätt lärde mig grunden i vad det innebär att modellera en verksamhet. Eller snarare vad det inte innebär. Hur man absolut inte ska göra.

Låt mig berätta en historia jag tänker på ibland. Det var en gråkall vårvinter i Stockholm i början av 90-talet. Jag var färsk från universitetets datalinje och hade fått mitt första jobb som systemutvecklare. Ett försäkringsföretag behövde ett administrativt system som skulle fungera som en central punkt i verksamheten. Det fanns redan färdiga informations- och processmodeller som skulle fungera som specifikation. De hade tagits fram i en serie workshops ledda av ett konsultbolag. Så nu var det bara att bygga efter ritning. Det vill säga att de var så det sades.

Men alla som varit med i branschen vet ju att sådana i förväg framtagna specifikationer är tämligen intetsägande. Vanligen är de på samma gång dels alldeles för grova och dels alldeles för detaljerade. Där de går ner lite mer i detaljer blir det nästan utan undantag fel. Orsaken är nog självklar för de flesta idag. Det går inte att i förväg specificera vad som verkligen behövs. Utveckling måste alltid vara iterativ, man måste experimentera sig fram, ställa upp hypoteser, prova vad som fungerar och modifiera alltefter man lär sig.

Men på den tiden, och även långt senare, fanns det en naiv tro på att man kunde specificera saker i förväg. Det var en hel industri, konsultbolag som tog fram hela pärmar av modeller och specifikationer. Det finns det nog fortfarande de som gör, men det är ovanligt.

Det var uppenbart för mig redan efter första dagarna att jag måste ta fram allt från grunden, inte minst en datamodell att basera databasen på. Pärmen jag hade fått i handen var inte till mycket hjälp, annat än att den i varje fall ringade in vilka områden man hade tänkt sig att man behövde it-stöd för.

Nåväl, jag satte igång med ungdomlig energi. Mest handlade det om att se vilka data som hanterades idag och vad man tyckte sig ha behov för framöver. Det gick ganska lätt. Men några begrepp hade jag svårt för. Ett av dessa var det mest centrala begreppet ”Försäkring”. Som alla vet som har sitt boende eller bil försäkrad så får man ju en ny version av försäkringen varje år. Är det då en ny försäkring eller är det samma?

Mitt första möte med en verksamhetsexpert  

När jag besvärade kontorsfolket med denna och andra frågor blev jag hänvisad till Arne, bolagets mest seniora expert. ”Arne kan allt. Han är en legendar i branschen”. Vad bra tänkte jag, nu kan jag få riktigt bra svar på mina frågor. Så här gick min intervju:

Jag: Det som löper över flera år, är det en försäkring?

Arne: Ja.

Jag: Det som jag får nytt varje år, vad är det?

Arne: En försäkring.

Jag: Men du sa ju att det som löper över flera år är det som är en försäkring?

Arne: Jo.

Jag: Men det är ju olika saker?

Arne (nu lite irriterad): Ja, men det är en försäkring.

Och så vidare. Så höll vi på ett tag. Och Arne började nu bli röd i ansiktet.

Då fick jag infallet att passa på att reda ut något annat. Nämligen vad den korrekta termen är för själva det papper man får hem som det står ”Försäkring” på. Det var ingen bra idé. Arne kallade också detta för ”försäkring”.

Nu var jag förvirrad och mina upprepande frågor och påpekanden att vi behövde skilja på de olika men närliggande företeelserna. Det fick till resultat att Arne stod och dunkade försäkringsbrev i skrivbordet, så att askkoppar och aska flög. (Jo, man rökte på kontor på början av 90-talet. Svårt att tro idag.) och upprepande högljutt: ”Det här är en försäkring. Och det här. Och det här.”

Jag lämnade Arnes flotta hörnrum med tanken att det blir nog inte så lätt i den här branschen. När inte verksamhetsexperter kan svara på de mest enkla frågor.

Varför berättar jag denna historia? Jo, jag tycker att i den finns en sensmoral. Men först måste jag bara säga vad jag så småningom lärt mig i själva sakfrågan, vad de korrekta termerna är för de företeelser som jag undrade över. För det första: Inget av det jag nämnde heter formellt sett ”försäkring” även om det används som en vardaglig term. Det man tecknar med ett försäkringsbolag är ett avtal om försäkring, ett ”försäkringsavtal”, även om ingen använder det ordet till vardags. När avtalet förnyas årligen blir det rent juridiskt sett ett nytt avtal. Men i praktiken, ur alla vanliga aspekter, ser man det som en ny version av samma avtal. Man kallar då varje version för ”försäkringsavtalsversion”, om man ska vara korrekt, men oftast bara ”försäkringsversion”. Det dokument som manifesterar avtalet kallas, som alla nog vet, ”försäkringsbrev”.

Vad jag lärde mig

Men hur var det med sensmoralen i historien? Jo, jag tänker att det jag lärde mig den hårda vägen var att när man vill analysera, förstå och beskriva en verksamhet räcker det inte med att fråga verksamhetsexperter. Man kan inte förvänta sig att experter så där enkelt och rakt ska berätta för en hur deras verksamhet fungerar. Att vara bra på en verksamhet betyder inte att man nödvändigtvis kan beskriva den på ett tydligt sätt. Jag har absolut inga tvivel på att Arne var bland de bästa på området och klart och tydligt kunde skilja på de företeelser jag frågade honom om. Men det betyder inte att han därmed kunde benämna och definiera dessa saker på ett sätt som var användbart för mitt syfte.

Det är mitt jobb, som informationsarkitekt att analysera, beskriva och benämna de begrepp som verksamheten behöver. Inte någon verksamhetsexperts. Jag måste förstås fråga och föra en dialog med olika verksamhetsexperter. Men inte bara det, jag måste forska och tänka själv också. Jag kan aldrig förvänta mig att verksamhetsexperter ska vara bra på att analysera och beskriva de begrepp de använder.

Mitt andra möte med verksamhetexperter

En tid senare, när jag tyckte att jag fått ihop en någorlunda klar databasdesign, så var det en sak som återstod innan jag kunde påbörja konstruktionen. Vi behövde bestämma detaljer som fältlängder, värdeförråd, vad som skulle vara obligatoriska termer etcetera. Jag och datachefen fick då den strålande idén att göra detta i ett stormöte. Det vill säga, vi själva var väldigt nöjda med idén. Representanter från verksamhetens alla hörn skulle få vara med och bidra med sin kunskap. Intresset visade sig emellertid vara lågt, det grymtades att man minsann hade viktigare saker att göra, viktiga kundmöten och nya avtal som man behövde få fram. Men vi trumfade igenom ett stormöte till slut, med många deltagare, allt från chefer och stjärnsäljare till sekreterare och assistenter. Vi började ställa våra frågor. Hur långt kan ett kundnamn vara? Hur stort belopp kan en försäkringspremie vara på? Måste en försäkring alltid ha provisionsprocenten angiven?

Irritationen växte i salen. Varför ska jag var med här tyckte vissa, det här är inte mitt område? Andra: ”Det här är en teknisk fråga, jag har bättre saker att göra”. Varje fråga möttes av vilda gissningar, ointresse, och ifrågasättande av om detta var deras sak. Folk började droppa av. Det gick så långt att vi fick avbryta.

Vad jag lärde mig denna gång

Vad var sensmoralen denna gång? Jo, densamma. Verksamhetsfolk kan inte allt, kan inte i detalj veta vad de behöver, har inte alltid rätt. Och bryr sig ofta inte ens. Verksamhetsexperter är inte kunniga på alla aspekter på sin verksamhet. Det är jag som verksamhetanalytiker som måste använda olika metoder och källor och rätt avväga och räkna ut hur saker hänger ihop.

Då det gäller så enkla saker som, fältlängder och existensregler för olika fält är det enklast att tröska igenom befintligt data efter extremvärden.

Jag tänker ibland på dessa händelser. Jag var oerfaren och naiv. Fast hur skull jag kunna veta att experter inte kan ge vettiga svar på frågor inom sitt område? Just dessa aspekter var ju inte deras område förstås. Borde jag ha förstått det i förväg? Kanske inte, men jag borde i varje fall ha varit mer uppmärksam när jag fick tecken på att så inte var fallet. Inte vara lika envis och mer eller mindre kräva att de skulle kunna svara. Idag hoppas jag att jag är mer ödmjuk när det gäller förväntningar på vad andra ska kunna, även sådana som är experter. Det hela kokar ner till att verksamheter är komplicerade ekosystem och ingen kan vara expert på alla aspekter av något så mångfacetterat.

Jag tycker att det illustrerar något grundläggande om kunskap och hur vi finner den. Vi ska fråga, fast inte förvänta oss att alltid få de svar vi behöver ha. Kanske du tycker att denna historia visade något du redan vet. Och det hoppas jag. Men i så fall kan den kanske tjäna som en påminnelse om vilken naiv bild andra kan ha av vad vi gör, vi som jobbar med modellering, att vi bara frågar och tecknar ner vad experter säger.  

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 7 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