Taggarkiv: strategiförinformationsarkitekter

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

Hur kan vi organisera arkitektarbetet?

Hur kan vi organisera arbetet med informationsarkitekturen i en större organisation? Vad är viktigt för att få samverkan med de olika parterna att fungera? Något vi kan vi skippa på en gång är den traditionella toppstyrande arkitektfunktionen.

Men hur kan vi då göra? I denna artikel går jag igenom tänkbara organisationsmodeller samt ger grundläggande förhållningssätt för den samverkan vi behöver få till i våra organisationer.

De finns en traditionell organisationsmodell för arkitekturarbete i en organisation. Man tänker sig att en centralt placerad grupp av arkitekter tar fram en målarkitektur för olika områden och att denna grundritning sedan ska följas av de olika projektteamen. Denna toppstyrning fungerar inte alls. För att ett arkitekturarbete skall fungerar måste det drivas som en organisk och kontinuerlig samverkan med och mellan organisationens olika funktioner och utvecklingsinitiativ.

Så den traditionella toppstyrande arkitektfunktionen är ett alternativ vi kan skippa på en gång. Vilka andra organisationsmodeller kan då fungera? Låt oss gå igenom och jämföra några alternativ.

Organisationsmodell 1: Självorganiserande team

Team som är skickliga på att samverka och kommunicera kan operera utan central auktoritet. Oftast har en eller några få personer i teamet en viss grad av översiktligt ansvar för den övergripande strukturen. Det är viktigt att en sådan person är arkitekt/utvecklare och kommunikatör i samma person. Den personen ska inte ta designbesluten ensam utan behöver kontinuerligt samverka och kommunicera med berörda parter både inom och utanför teamet.

Ofta uppstår en sådan roll spontant. Teamet måste i så fall ha en kärna av ett fåtal personer med tillräcklig kompetens för att ta de större designbesluten. Detta kan fungera, åtminstone i en mindre organisation. Men det kräver som sagt en hel del av teamet.

Organisationsmodell 2: Informell samverkan mellan självorganiserande team

När en övergripande struktur spänner över flera områden börjar team som har beroende till varandra att samarbeta på ett informellt sätt. Varje team gör upptäckter som leder till idéer för den övergripande strukturen. De olika möjligheterna diskuteras av en informell kommitté med representanter från de olika teamen. Teamen rör sig framåt tillsammans som en lös sammanslutning.

Denna ordning kan fungera när det är få team som skall koordineras, när de alla är motiverade att koordinera sig, när deras designförmågor är jämförbara och deras behov av struktur tillräckligt lika för att tillgodoses av en gemensam övergripande struktur.

Det som effektivt saboterar ett sådant samarbete är när incitament att bli klar i tid och på budget övertrumfar nytta och långsiktighet. Vilket tyvärr är vanligt i många organisationer. Då tvingas teamen att var och en köra sitt eget race.

Organisationsmodell 3: Ett centralt arkitektteam

När en strategi skall spänna över många team behöver vissa beslut tas centralt. Då behövs ett centralt arkitektteam.

Ett centralt arkitektteam bör arbeta på ett kollegialt sätt tillsammans med de olika teamen. Man behöver ha inställningen att man stödjer teamen med att koordinera och harmonisera övergripande strukturer och andra frågeställningar mellan teamen.

På ett organisationsschema ser detta ut som det traditionella toppstyrande arkitektteamet, det ökända ”elfenbenstornet”, men det får inte förväxlas med detta. Det är i själva verket ett helt annat sätt att styra, i varje aktivitet. De centralt placerade arkitekterna arbetar tillsammans med projektarkitekterna och utvecklarna i teamen, vilka experimenterar tillsammans med olika team för att få fram bästa övergripande strukturen.
Kort sagt, de centralt placerade arkitekterna gömmer sig inte bakom sina PowerPoint. De är inte rädda för att smutsa ner händerna med riktigt arbete tillsammans med utvecklarna i teamen.

Grundläggande förhållningssätt för samverkan

I det följande listas några grundläggande förhållningssätt för den samverkan som behövs i arkitekturarbetet i en organisation.

1. Arkitekturen för ett visst utvecklingsinitiativ måste ägas av projektteamet självt, inte av ett separat arkitektteam

Centrala arkitektteam har vanligen en officiell auktoritet. Men de ignoreras ofta eller kringgås. Orsaken är följande: När det som arkitektteamet tar fram skall tillämpas i projekten fungerar det inte så bra. Arkitektteamet är då vanligen inte så mottagligt för återkoppling. De är avskärmade från den praktiska verkligheten och har sällan de praktiska kunskaperna som skulle behövas för att kunna engagera sig. Fenomenet är så vanligt att det fått ett namn: ”Ivory Tower Architects”. Därmed har utvecklare ofta inget annat val än att ignorera eller kringgå det centrala arkitektteamet.

Om den strategiska designen i stället växer fram inom projektteamet når den ut mycket mera effektivt, förutsatt att teamet kommunicerar och samverkar med sin omgivning på ett bra sätt. Designen blir då relevant för projektet och får den naturliga auktoritet som följer med ett genomtänkt community-beslut. De centrala arkitekterna är mindre av poliser och mera av facilitatorer, kommunikatörer och coacher för att stödja projektet. De hjälper teamen med att se och beakta de bredare och långsiktiga perspektiven i verksamheten.  

För att skapa en övergripande struktur måste man ha en djup förståelse för projektet och för domänen. De enda som kan nå det djupet av förståelse är medlemmarna i teamet. Det förklarar varför en projektarkitektur skapad och ägt av ett separat arkitektteam sällan fungerar.

2. Arkitekturen måste tillåta ständig utveckling

Om arkitekturen är låst i onödan så får inte teamet den flexibilitet de behöver för att lösa det problem det har ansvar för. En överordnad harmoniseringsprincip kan behövas, men arkitekturen måste kunna utvecklas och förändras i takt med att projektet lever sitt liv.

3. Arkitektteamet måste undvika att suga upp alla de bästa och smartaste utvecklarna

Ledningen brukar vilja överföra de skickligaste utvecklarna till arkitektteamet. De vill få en hävstångseffekt på deras talang. Utvecklaren själv är tilltalad av möjligheten att få ett bredare inflytande och/eller arbeta med ”mera intressanta” problem. Det är också prestigefyllt att vara medlem i det som upplevs som ett elitteam.

Problemet blir då att bara de mest oerfarna utvecklarna blir kvar för att bygga och vidareutveckla applikationerna. Men att bygga och förvalta en bra applikation kräver erfarenhet.
Ett annat problem är att utvecklare med mest kunskap om domänen sällan blir medlemmar av arkitektteamet.

Båda teamen, både det centrala arkitektteamet och utvecklingsteamet, kräver utvecklare med designförmåga och domänkunskap.

4. Strategisk design kräver minimalism och ödmjukhet

Destillering och minimalism är viktig för all design, men mest av allt för den strategiska designen. Det är en kärna i arkitekturarbetet. Men allra viktigast är ödmjukheten, att inte låsa fast sig, utan lyssna, ompröva och fördjupa designen kontinuerligt.

Akta dig för masterplanen!

Till sist vill jag citera Christopher Alexander, byggnadsarkitekten och designteoretikern, fadern till idén om mönster inom design:

The master plan attempts to set down enough guidelines to provide for coherence in the environment as a whole – and still leave freedom for individual buildings and open spaces to adapt to local needs.

…in practice master plans fail—because they create totalitarian order, not organic order. They are too rigid; they cannot easily adapt to the natural and unpredictable changes that inevitably arise in the life of a community.

… The attempt to steer such a course is rather like filling in the colors in a child’s coloring book…. At best, the order which results from such a process is banal.

…Thus, as a source of organic order, a master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough.

… the existence of a master plan alienates the users [because, by definition] the members of the community can have little impact on the future shape of their community because most important decisions have already been made.

Från: The Oregon Experiment (Alexander et al. 1975) 

                                      

Alexander och hans kollegor förespråkar i stället en uppsättning principer som alla medlemmar av en community ska tillämpa för varje steg i den gradvisa framväxten av det man utvecklar.
Då växer det fram något av en organisk ordning, som är väl anpassad till omständigheterna.

/Peter Tallungs, IRM

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