Blogginlägg -
Varför göra samma misstag som andra?
Läsare av föregående blogginlägg fångade upp problematiken gällande kommunikationen mellan IT och kärnverksamheten. Med utgångspunkt i affärsmålen kommer vi till nästa utmaning i form av att kravställa och formulera leveransen av IT-förmågor.
Här finns en uppsjö av modeller, metoder och verktyg som kan vara till hjälp. Det är förvånande att många organisationer inte ”vågar” dra nytta av dessa. Eller anser sig ”kunna” dra nytta av på grund av sin unikhet. På detta sätt så begår man sannolikt samma misstag som andra istället för att dra nytta av andras erfarenheter, snedsteg och lärdomar.
En bild säger mer än tusen ord
Min erfarenhet är att alla människor har en egen mental bild av ett problem och dess lösning. I ett möte mellan exempelvis fyra personer kan vi utgå ifrån att det finns minst fyra versioner av problemet/behovet och dess lösning. Den normala instinkten är att beskriva det man ser med ord vilket inte sällan leder till förvirrande möten och frustrerade deltagare. Oftast tyvärr med utgången att man fortfarande inte har en enad bild på problemet, kravet eller behovet.
Det är då betydligt mer effektivt att kommunicera i bilder, diagram eller modeller. En bild säger mer än tusen ord sägs det och det är ingen slump att många beprövade modeller har sin utgångspunkt i just ett bildspråk.
För att tillgodose ett krav krävs kompromisser
Första prioriteten är alltså att etablera en gemensam bild av verkligheten. Utifrån denna kan problem- och lösningsområden beskrivas och kompromisser mellan olika intressenters kravställning uppnås. Att förstå hela IT-landskapet är inte minst viktigt i IAM-lösningar då dessa spänner över helheten. För att tillgodose problem A så uppstår kanske problem B vilket är viktigt att berörda intressenter kan se, förstå och besluta kring.
Rätt lösning kräver insikt och styrning
Den första rekommendationen på en enkel och bra modell, som kan användas för att identifiera behovet av integration och standardisering av verksamhetsprocesser/informationskällor, är MIT Sloan Institute – ”Business Operating Model”. All identitets- och behörighetshantering (IAM) har ju dessutom normalt sin utgångspunkt i standardisering och kvalitetsförhöjning via integration och automation.
Rätt IAM-lösning för ett enskilt behov/problem är subjektivt om man inte fastställer vilken typ av Operating Model som man totalt sett vill förhålla sig till. Det finns ingen rätt eller fel kvadrant att sträva efter men valet bör vara vägledande för de lösningar som utformas.
Naturligtvis kan en organisation välja att strategiskt byta Business Operating Model. Dock är detta en lång och mödosam resa där vi pratar år innan förändringen fått genomslag.
En kort introduktion till modellen
Process integration – Definierar hur väl kund/leverantörs databaser samt tjänste- och produktkataloger behöver vara tillgängliga inom organisationen. Ett lågt integrationsbehov innebär att databaser/kataloger främst används lokalt inom en organisation. Högt integrationsbehov betyder att informationen behöver delas och vara tillgänglig för hela organisationen.
Process standardization – Definierar hur ”lika” arbetsprocesser inom organisationen skall vara. Låg processtandardisering innebär att varje verksamhet definierar sina egna processer. Hög processtandardisering innebär att alla arbetar i samma process, oavsett geografisk eller organisatorisk tillhörighet.
Valet av kvadrant har alltså stor inverkan på kraven på IT-förmågor och påverkar även vad som är rätt IAM-lösning i allra högsta grad. Låt oss titta på två exempel:
Unification
| Gemensamma globala/lokala kunder som erbjuds globala tjänster/produkter |
|
| Globalt överlappande funktioner eller verksamheter med liknande verksamhet |
|
| Central styrning av verksamheten |
|
| ”Economies of scale” |
|
| Låg förändringstakt |
Diversification
| Få gemensamma kunder inom organisationen | |
| Decentraliserad styrning, exempelvis där varje bolag sköter sig själv inom en koncern |
|
| Hög förändringstakt |
Generellt kan man säga att det enda som man kan sträva efter i diversifierings-kvadranten är att standardisera kring teknologier och plattformar. För att uppnå det man vill med en unification-modell så krävs insatser och investeringar som går långt bortom teknologierna och plattformarna som sådana.
Var inte rädd för att ta hjälp
Samlat i en hög så är modeller, metoder och verktyg avskräckande och kan uppfattas som generellt sunt förnuft på molnfri höjd. Med vetskapen om hur man kan använda verktygen så får de däremot ett värde som är omedelbart. Är övergången mellan krav- och lösningsformulering en utmaning för dig idag? Kontakta oss gärna så ser vi till att ni inte begår samma misstag som andra.
Dan Andersson, Enterprise och IAM Arkitekt, Enfo
Läs mer inlägg skrivna av Dan Andersson här:
Ämnen
- Datorer, datateknik, programvaror
