Analysområden:
referenser
Kritiska framgångsfaktorer (KFF) för ett datalagerprojekt
Vi har funnit att man för att lyckas med ett införande av datalager måste ta hänsyn till sex faktorer: Vision, Struktur, Process, Teknik, Organisation och Individ.
Modellen beskriver väl problemområdet och de samband som råder mellan olika delområden.
Ett datalager stöder beslutsfattande, en verksamhet som till skillnad
från operativa rutiner skiftar efter omständigheterna. I kritiska situationer
där oväntade förändringar skett i omgivningen eller inom organisationen
är styr- och ledningsfunktionerna som viktigast. Man har i dessa situationer
mindre nytta av ett noggrant utformat stöd för den normala situationen.
Operativa system kan byggas med existerande rutiner som förebild. Datalagerbyggaren
måste tillhandahålla de data som potentiellt är viktiga för att
styra och leda verksamheten. För att kunna göra detta måste man veta vart
verksamheten är på väg och varför; vilka ledningens intentioner är - vilka
visioner som styr verksamheten.
| om Vision | rekommendation | skäl |
| Knyt till prioriterade mål och strategier | Introducera datalager på ett prioriterat område som har väsentlig betydelse för organisationen | Det är svårt att utvärdera beslutsstöd. För att nå framgång gäller det att hantera ett område där vinsten är tydlig. |
| Visa omedelbart synliga vinster | Introducera datalager på ett område där vinsten är operationell - mätbar och uppträder nära i tiden och där sannolikheten för framgång är hög | Det kan ta tid innan vinsterna av ett beslutsstödssystem visar sig. Välj ett område där denna tid är så kort som möjlig. |
| Nytta med datalager | Utnyttja möjligheterna att följa upp händelser i detalj, t ex kunder. Öka försäljning till rätt kunder. Höj kvalitet genom att förbättra viktiga produkter. Ekonomisk uppföljning, riskminimering, humankapital, marknadsandelar | Datalager kan stödja olika verksamheter olika bra. Börja med ett område där tekniken har en avgörande påverkan. |
åter till början
Nyckeln till ett effektivt datalager är att rätt kunna strukturera visionen.
En begriplig och riktig struktur har ett värde i sig och blir i ett datalager
det viktigaste verktyget för att analysera verksamheten. Strukturen måste
korrekt spegla verksamheten ur det perspektiv som beslutsfattare ser den.
Den som upprättar ett datalager måste inte bara strukturera data. Man
måste först beskriva - strukturera de mål och processer som datalagret
skall stödja, samt de begrepp som beskriver önskade data.
| om Struktur | rekommendation | skäl |
| Datastrukturen är begriplig | Slutanvändaren måste vara med vid seminarier och i allt kravställande. Strukturen bör vara denormaliserad (ungefär anpassad till användaren) om den skall vara ett verktyg för beslutsfattare. | Datalagret utnyttjas effektivt om beslutsfattare själva kan använda det. Det kan denne om datastrukturen stämmer med beslutsfattarens sätt att se på verksamheten. |
| Övergripande struktur | Försök inte att på kort tid bygga detaljerade
företagsövergripande modeller. Satsa först på standards för begrepp
och data.
Normaliserat datalager som källa för ett antal dataskafferier kan byggas om åtkomstkraven inte är tidskritiska, datavolym- och komplexitet är rimliga och det finns förtroende för en sådan aktivitet inom ledningen. |
Företagsövergripande modeller av hög kvalitet
tar lång tid att bygga. Det finns risk att arbetet inte hinner slutföras
inom resursramen.
En trenivåstruktur med ett normaliserat datalager i mitten innebär att data skall kopieras i två steg vilket kan ta lång tid. I stora datalager kan detta begränsa hur aktuella data kan bli på den tredje nivån (i s k dataskafferier). |
| Detaljer eller summa data | Detaljdata bör i princip alltid väljas. | Möjligheten att analysera data i olika dimensioner begränsas om den lägsta nivån består av summor. Är t ex försäljning ackumulerad per vecka kan dagsförsäljningen för sortimentet inte tas fram. |
| Denormalisering | Slutanvändare bör se en denormaliserad struktur. Detta kan uppnås genom ett denormaliserat datalager, dito dataskafferi, genom views, eller intelligent middleware. | Normaliserade strukturer är komplicerade att förstå och överblicka bl a eftersom antalet tabeller ofta är stort. |
åter till början
Med ordet process vill vi i det här sammanhanget peka ut två viktiga företeelser. Vi vill för det första diskutera processen att bygga upp ett datalager. Åt detta ändamål har vi ägnat hela kapitlet Process. För det andra vill vi diskutera hur man beskriver de processer i verksamheten som ett datalager skall stödja.
Att genomlöpa processen för att bygga ett datalager kan kosta organisationen
tiotals miljoner kronor. De varierande förutsättningarna för ett datalagerbygge
gör att vi avstår från att beskriva någon generell process. Speciellt
viktiga delprocesser för datalager är förankring, kvalitetskontroll, utbildning
och förvaltning. Det är vidare viktigt att ansvaret för förvaltning och
datakvalitet läggs ut i verksamheten.
| om Process | rekommendation | skäl |
| Affärsdriven process | Bör alltid eftersträvas, dvs en beställare finns som ser en intäkt med processen | Dåligt förankrade processer riskerar att stoppas innan de blivit färdiga. |
| Utveckla stegvis | Time-Box metodik rekommenderas. Gruppseminarier med väggrafteknik har visat sig effektiva för detta. |
|
| Top-down eller bottom-up | Både och är bäst. Top-down, dvs man bryter ned övergripande mål. Bottom-up, dvs att utgå från data som finns. | Top-down ger inriktning på verksamhetens mål. Bottom-up fokuserar på de data som existerar för att nå dessa mål. |
| Kvalitetsansvar hos IT-funktionen eller beställare | Beställaren bör ha kvalitetsansvaret. IT-funktionen kan vara operativ kvalitetsfunktion | IT-funktionen har svårare att få beslut om åtgärder mot dålig datakvalitet än linjen. |
| "Datadrivet" eller "tillämpnings-drivet" | Tillämpningdrivet i den meningen att datalagret utvecklas steg för steg med en given datalagertillämpning knuten till varje steg. | Användningen av datalagret skall betala för och styra utbyggnaden. |
Det är vanligt att organisationer som skall införa datalager ägnar alltför
stort intresse åt tekniken jämfört med de övriga fem områdena. Teknik
för datalager är förvisso omfattande och komplex. Ny teknik behövs ända
från det att data fångas vid källan till dess den användes av beslutsfattare.
Data hämtas från operativa system och omvandlas till en lämplig form innan
de lagras. Verktyg specialiserade för detta kallas ibland ETL-verktyg.
Andra verktyg är specialiserade på att jämföra och korrigera data "datatvätt".
Både ETL-verktyg och kataloger behövs för att hantera metadata. Själva
databasens egenskaper är av vital betydelse för framgången med
datalager. Enkelhet, kvalitet och säkerhet är viktiga frågor, men det
är kapaciteten mätt i datavolym, antal och komplexitet för frågor
som ställer störst krav på tekniken.
| om Teknik | rekommendation | skäl |
| Skalbarhet | Använd skalbar hårdvara och mjukvara | Datalager har en tendens att växa snabbt och kontinuerligt |
| MOLAP eller ROLAP | ROLAP om inte volymerna är små och tillämpningen isolerad. | MOLAP är svårt att skala till stora system. OLAP har ett ostandardiserat gränssnitt |
| Uppdatering on-line eller satsvis | Satsvis uppdatering.
Bygger man ett normaliserat datalager och dataskafferier som enda åtkomstsätt kan on-line uppdatering användas för delar av datalagret. |
Jämförande analyser kräver att data inte förändras under analysen. On-line uppdatering ökar också komplexiteten i databashanteringen. |
Datalager är en företeelse som mer än vanliga datasystem är beroende
av individernas acceptans, bl a för att själva syftet med datalagret är
att individerna själva skall kunna använda det. Centrala områden är därför
utbildning och användarstöd.
| om Individ | rekommendation | skäl |
| Slutanvändaren ställer kraven | IT-funktionen skall aldrig vara kravställare, annat än för teknik | Datalager skall anpassas till verksamheten och dess krav |
| Slutanvändaren är knapptryckare utan mellanhänder | Slutanvändaren skall använda datalagret direkt. | Beslutsfattares kreativitet och kunnande skall steg för steg stödjas av data relevanta för analysen. |
| Användaren har tillgång till begripliga metadata | Självständiga användare skall ha tillgång till metadata som de själva kan förstå utan att behöva fråga "specialister". | En användare som inte har tillgång till metadata kan inte göra självständiga analyser. |
| Användarens miljö och stöd är bekväm och begriplig | Rätt användargränssnitt, att alltid kunna få (mänsklig) hjälp, mycket bra felmeddelanden, gränssnittet anpassat till användarens nivå, bra utbildning | En svår och trög miljö kan medföra att beslut fattas intuitivt istället för grundat på fakta. |
Datalager är en resurs för hela organisationen. Denna resurs måste anpassas till organisationens övergripande mål och till målen för de stödda verksamheterna.
Datalagret själv måste också organiseras.
Ett antal funktioner krävs för ett väl fungerande datalager. Dessa skall
inlemmas i den övriga organisationen.
| om Organisation | rekommendation | skäl |
| Förankra alltid före projektstart | Se till att datalagerprojektet inte bara är förankrat på IT-funktionen | Utan förankring i ledningen går det inte att bygga ett fungerande datalager. |
| Förvaltningsansvaret tydligt | Utse en ansvarig för datalagret eller för dess delar. Lägg sedan ut delegerat ansvar för förvaltning och kvalitet i organisationen. Det är viktigt att ansvaret hamnar hos någon som har anknytning till företagets måluppfyllelse. | Dålig kvalitet och andra fel i datalagret kan ha sin orsak utanför datalagret. För att kunna korrigera felaktigheter måste dessa ansvarsområden spänna över berörda delar av organisationen. |
| Nya fasta organisationer | Skall upprättas | Utan en fast organisation kring datalagret kommer detta inte att fungera. |