Taggarkiv: arbetssätt

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

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