Datavarehus for uddannelsessektoren Delrapport 2 - Best practice og cases 19. maj 2010
Denne rapport er udarbejdet af Devoteam Consulting i samarbejde med Zangenberg & Company for Finansministeriet, Undervisningsministeriet, Ministeriet for Videnskab, teknologi og Udvikling samt Økonomi- og Erhvervsministeriet. Rapporten består af en hovedrapport og fire delrapporter. Opgaven har været at undersøge mulighederne for at etablere et fælles statsligt datavarehus for uddannelsessektoren, baseret på de data, som allerede findes i de administrative systemer. Undersøgelsen har omfattet de selvejende uddannelsesinstitutioner under Undervisningsministeriet (ungdomsuddannelser og professionsbacheloruddannelser samt produktionsskoler), under Videnskabsministeriet (universiteterne) og under Økonomi- og Erhvervsministeriet (de maritime uddannelser) Hovedrapporten sammenfatter og perspektiverer vores observationer og anbefalinger. Delrapport 1 beskriver resultatet af vores kortlægning af data i de fælles administrative systemer, herunder også den nuværende indsamling af data til brug på ministerieniveauet. Delrapporten munder ud i vores vurdering af dataparatheden, dvs. af muligheder og barrierer for indsamling af data fra de fælles administrative systemer til brug i et fælles datavarehus for uddannelsessektoren. Delrapport 2 beskriver best practice for opbygning og drift af datavarehuse, master data management mv., samt et udvalg af relevante eksempler på andre datavarehuse (cases) Delrapport 3 beskriver de erfaringer, der er gjort med opbygning af en prototype på et datavarehus, baseret på indsamling af data fra to af de administrative systemer. Delrapport 4 beskriver vores forslag til indretning og opbygning af et fremtidigt datavarehus for uddannelsessektoren. 1 9 0 5 2 0 1 0 1
Indholdsfortegnelse Indholdsfortegnelse... 2 1. Indledning... 3 2. Best Practice... 4 2.1. Enterprise datavarehus arkitektur... 4 2.2. Datavarehus governance best practice... 7 2.3. Master data management best practice... 8 2.4. Organisering: Ét centralt kompetence center (BICC)... 10 2.5. Datavarehus worst practice... 15 3. Cases... 17 3.1. Indledning... 17 3.2. TEA (Texas Education Agency)... 17 3.2.1. Beskrivelse af casen... 17 3.2.2. Relevans... 18 3.2.3. Begrænsning... 18 3.3. TPEIR og PREP (Texas)... 18 3.4. HESA (Higher Education Statistics Agency)... 19 3.4.1. Beskrivelse af casen... 19 3.4.2. Relevans... 20 3.4.3. Begrænsning... 20 3.5. Københavns Kommunes Koncern Service Ledelsesinformation (KS- LIS) 20 3.5.1. Beskrivelse af casen... 20 3.5.2. Relevans... 21 3.5.3. Begrænsning... 21 4. Litteraturliste... 22 1 9 0 5 2 0 1 0 2
1. Indledning Virksomheder har etableret datavarehuse og anvendt business intelligence teknologier i over 20 år. Der er tale om et veletableret produktområde med produkter fra markedets største leverandører som IBM, Oracle, SAS, Microsoft og SAP og med en lang række niche-leverandører, der leverer mere specialiserede analyseprodukter. Der findes en righoldig litteratur om business intelligence og datavarehuse. De førende it-researchvirksomheder følger de dominerende spillere og publicerer løbende anbefalinger og opsummering af best practice både i forhold til strategi, arkitektur, organisering, drift governance og projektgennemførelse. I denne delrapport opsummerer vi de aktuelle best practice anbefalinger fra en række kilder. De enkelte elementer i denne delrapport er ikke anført med specifikke kildehenvisninger, men i slutningen af delrapporten har vi vedlagt en litteraturliste med bøger og artikler, der behandler datavarehus best practice i detaljer. Vi har desuden medtaget et antal praktiske cases, der skal tjene som perspektivering i forhold til det foreslåede projekt. 1 9 0 5 2 0 1 0 3
2. Best Practice 2.1. Enterprise datavarehus arkitektur Begrebet Enterprise Datavarehus beskriver en arkitekturpraksis, hvor man etablerer et enkelt centralt datavarehus for hele virksomheden. Data indsamles, standardiseres og valideres centralt og opbevares centralt. Derfra fordeles de til grupper af brugere, som har etableret analysemiljøer (kaldet data marter ) med forskelligt fokus, detaljeringsgrad osv. Der har efterhånden etableret sig en konsensus om de enkelte lag i en klassisk datavarehus-arkitektur. Vi har sammenfattet dette i figuren herunder: Figur 1 Illustration af målarkitektur for et Enterprise Datavarehus Kildesystemer: Inkluderer såvel interne som eksterne systemer. Målarkitekturen lægger op til, at der skal være løst koblede dataudvekslinger/integrationer mellem kildesystemer og DV løsninger. Kildesystemer omfatter de operative databaser og registre, stamdata og Master Data Management systemer. IT-infrastruktur: Sikrer modtagelse og videredistribuering af kildedata. Infrastrukturen kan tilbyde en Servicebus komponent, der dels sikrer en løs kobling og dels muliggør brug af certificerede services mellem kildesystemer og DV løsningen. 1 9 0 5 2 0 1 0 4
Data Staging Area (DSA et): Er ét fælles miljø, hvor data mellemlagres. Al datagrundlag for ledelsesinformation i DV databasen (og senere i datamarter) kommer udelukkende fra DSA et. ETL jobs (generelt): Varetager udtræk og evt. konvertering af data. Er udviklet i et ETL værktøj, som ofte kommer fra platformsleverandøren. ETL job (for opdatering af data i DSA): Er dedikerede ETL jobs, som har til opgave at modtage kildedata og indlæse i data i DSA et. DV Database: Udgør en slags datahub for alle datamarter og tilhørende datakuber. Ingen brugere har direkte adgang til data i DV databasen, formålet er udelukkende at udgøre grundlaget for at danne dataindhold i datamarter og tilhørende datakuber. DV databasen skal være den konsoliderede sandhed om den forretningsmæssige tilstand af data. ETL job (for opdatering af data i DV databasen): Er dedikerede ETL jobs som har til opgave at opdatere DW databasen på basis af data fra DSA et. Datamarter: Udgør det direkte ledelsesinformations-datagrundlag, hvorfra de forskellige BI front-ends henter deres data. Datamarter og deres datakuber skal kunne understøtte de valgte BI front-ends i brugermiljøerne. Datamarter er tilstedeværelsen af udvalgte dele af ledelsesinformations-grundlaget, optimeret til den specifikke anvendelse. ETL job (for opdatering af data i datamarter): Er dedikerede ETL jobs, som har til opgave at udtrække dele af data fra DV databasen og lægge dem til rette i datamarter. Metadata: I den udstrækning, som valgte udviklingsværktøjer og platforme tillader det, skal alle metadata samles ét sted, og anvendelse af metadata i diverse programkomponenter skal ske så automatiseret som muligt. BI front-ends: Dækker den del af målarkitekturen, hvor slutbrugere får præsenteret rapporter, analyseresultater m.v. Styring af adgangskontrol til alle BI-outputs skal ske gennem én fælles brugeradministrationsløsning herfor. Gartner opstiller seks generelle krav til en datavarehus arkitektur: 1 9 0 5 2 0 1 0 5
1. Forberedt for udvidelse. Det skal være muligt at tilføje nye datakilder og ændre på integrationen af eksisterende datakilder. 2. Fleksibel. Datavarehuset skal være modeleret til et abstraktionsniveau, der gør det muligt at justere datamodellen, efterhånden som flere begrebsområder tilføjes. 3. Performanceoptimeret. Et datavarehus skal optimeres, så det giver konsistente og forudsigelige samt acceptable svartider. For at sikre dette skal der introduceres det nødvendige omfang af redundans. 4. Genbrugelig. Data i datavarehuset forventes at kunne anvendes af forskellige interessenter og brugergrupper i en række forskellige analyse-kontekster. Dette forudsætter dels et passende abstraktionsniveau, dels at data transformeres, renses, konsolideres og sammenstilles i forhold til de forskellige brugergruppers behov. 5. Skalérbar. Datavarehuset skal være forberedt for en vækst i den samlede datamængde, og dette skal afspejles i infrastruktur og arkitektur samt i strategier for arkivering og sletning af data. 6. Tilgængelig. Det vil typisk være krav om høj tilgængelighed for datavarehuse med begrænsede vinduer for dataoverførsler, rekonfigurering, backup og optimering. Datakvalitet er det mest udbredte problem i forbindelse med datavarehusprojekter. Det er derfor en generel anbefaling, at man anvender automatiserede datakvalitetsværktøjer (kaldet data profilering) for at kunne identificere problematiske områder og udarbejde en strategi for håndtering af problemet. 1 9 0 5 2 0 1 0 6
2.2. Datavarehus governance best practice Etablering af datavarehuse kræver tværorganisatoriske initiativer, der ofte skal tilgodese forskellige interessenter, og som kræver aktiv deltagelse af en række forskellige systemejere. Netop derfor er det vigtigt at have fokus på governance; hvordan styrer vi den løbende udvikling af datavarehuset og hvordan træffes der beslutninger om datavarehuset? Et datavarehus anvendelighed afhænger i vid udstrækning af den underliggende datakvalitet. Jo højere og mere ensartet kvalitet, jo mere komplette data, desto mere præcise analyser, kan man lave. Nøglen til at opnå dette er organisatorisk modenhed hos, og på tværs af de institutioner, der anvender kildesystemerne. Der skal etableres et mindstemål af fælles datadisciplin og politikker vedr. håndtering af data, og disse skal være accepteret i de forskellige organisationer. IBM har opstillet følgende 12 anbefalinger 1 : 1. Fælles forståelse ( awareness ) er nøglen. Alle parter skal forstå væsentligheden og acceptere de krav, der gælder for datakvalitet samt konsekvenserne, hvis data ikke lever op til mindstekravene (forkerte analyser og dermed potentielt set forkerte beslutninger). 2. Ansvar for kvalitetskontrol ( Stewardship ). Der skal placeres ansvar for det konstante fokus på kvaliteten af data, herunder forbedringer. Den ideelle data-steward har en væsentlig domæneviden. 3. Data politik der skal være nedskrevne politikker vedr. adfærd i organisationen i forhold til håndtering af data. 4. Værdi fra data i processen vedr. håndtering af data skal der være konstant fokus på, om data i datavarehuset rent faktisk bliver anvendt til analyser om man får værdi af sine data. 5. Data Risk Management der skal være defineret en klar metode i forhold til at definere, kvalificere, kvantificere og imødegå risici i forhold til data. 6. Sikkerhed der skal være defineret politikker og praksis vedr. datahåndtering for at imødegå misbrug af data og regelbrud. 7. Data arkitektur der skal være defineret en klar arkitektur, der sikrer tilgængelighed og distribution af data til relevante brugere. 8. Data kvalitet der skal være defineret metoder til at måle, forbedre og certificere kvaliteten af data i produktion, test samt arkiverede data. 1 The IBM data governance blueprint: Leveraging best practices and proven technologies. ftp://ftp.software.ibm.com/software/data/pubs/papers/data-governance-best-practices.pdf 1 9 0 5 2 0 1 0 7
9. Metadata (data om data) Der skal være metoder og værktøjer til at skabe og bruge fælles definitioner af data, så både IT og organisationen forstår definitionerne og kan anvende dem. 10. Information Lifecycle Management der skal være en systematisk og veldefineret tilgang til dataindsamling, anvendelse af data, opbevaring samt sletning af data 11. Audit og rapporter der skal være defineret processer for overvågning og måling af værdien af data, risikohåndtering samt styringseffektivitet. 12. Kontrol og styring af stamdata i et Master Data Management (MDM) 2 værktøj. Det anbefales at tage alle stamdata og samle dem ét sted, hvor fra de enkelte organisationers anvendelse og opdatering af stamdata styres. Dette sikrer konsistens, entydighed og effektivitet. Og så gør det det mere enkelt at implementere et datavarehus efterfølgende, da en række data allerede er afstemt og vasket. Det er vigtigt ikke at forveksle et datavarehus med MDM. Data i et MDM er kildedata, der anvendes direkte i organisationens applikationer, mens data i et datavarehus er data kopieret fra kildesystemer alene til analysebrug. Etablering af kontrol og styring af stamdata i et MDM værktøj kan anvendes som et stærkt datakvalitetsforbedrende initiativ på tværs af de forskellige enheder, som er ansvarlige for kildesystemerne. I næste afsnit gives derfor en kort beskrivelse af de grundlæggende elementer i en MDM løsning. 2.3. Master data management best practice Som det er beskrevet ovenfor, er sikring af datakvalitet en væsentlig forudsætning for en velfungerende datavarehusløsning. Til dette formål, og i øvrigt til data governance og datavedligeholdelse, anvendes ofte Master Data Management værktøjer. Master Data Management dækker over en fælles harmonisering af data med udgangspunkt i fælles begrebsdefinitioner, brug af datakvalitets- og dataharmoniseringsregler (omhandlende dataprofilering, datastandardisering, datamatch og datarens) gennem implementering af et fælles master data repository. Dette suppleres med fokus på data governance der dækker ejerskab, forankringsansvar og vedligeholdelsesopgaver for data og datakvalitet. 2 Se eventuelt: An Evolutionary Approach to Master Data Management af Claudia Imhoff og Colin White fra BeyeNetwork. 1 9 0 5 2 0 1 0 8
Virksomheder, der har arbejdet med datavarehuse i flere år, etablerer typisk en praksis for Master Data Management (MDM) fordi: MDM er tæt knyttet til optimering af forretningsprocesser, da MDM hjælper med at benytte fælles data på tværs af hele organisationen MDM er tæt knyttet til integrationsprojekter og tilhørende SOA (Service Orienteret Arkitektur) implementeringer, da implementerede udstillingsservices bør tage udgangspunkt i begrebsmodeldefinition og governance strategi Indsats til vedligeholdelse af master data minimeres løbende, f.eks. minimeres dobbeltregistrering af masterdata Serviceorienteret udstilling af opdaterede masterdata minimerer behovet for punkt-til-punkt integrationer ( spaghetti-integration ) MDM har, med sine fælles begreber og standarder, indflydelse på design af DV systemer, lige fra kildesystemer til selve ledelsesrapporteringen MDM bruges aktivt i forbindelse med governance opgaver, fx således at business-cases for projekter er betinget af anvendelse af MDM data og definitioner. MDM er ofte en stor hjælp til datamigreringsprojekter, der ofte forekommer ved fusioner. Gevinsterne ved fuldt implementeret MDM er bl.a.: En begrebsmodel, der dokumenterer alle væsentlige virksomhedsbegreber, og at disse benyttes på tværs af alle mennesker, projekter og systemer At alle definerede og implementerede masterdata respekterer virksomheden begrebsmodel At masterdata vedligeholdes én gang (og opbevares ét sted) og efterfølgende udstilles til relevante systemer på tværs af hele virksomhedens systemportefølje At eventuelle masterdata, der forefindes i kopi, grundet (standard) systemers struktur og implementering, vedligeholdes mest optimalt med master data repository som centrum for de nødvendige dataintegrationer herfor At løbende data governance fokus er med til at sikre, at masterdata benyttes i alle relevante projekter og andre initiativer At data governance ligeledes sikrer relevante rammer for ejerskab, forankringsansvar og vedligeholdelsesopgaver. Den centrale rolle for en MDM løsning illustreres i figuren nedenfor. 1 9 0 5 2 0 1 0 9
Figur 2 Den centrale rolle for Master Data Management Realisering af en MDM løsning indenfor Undervisningssektoren vil således være til stor hjælp ved etablering af DV løsningen, men det er ingen forudsætning. Findes der ingen MDM løsning, skal DV løsningen i stedet implementere langt flere datakonverteringer, med eventuelt lavere datakvalitet til følge. 2.4. Organisering: Ét centralt kompetencecenter (BICC) I dette afsnit vil vi gennemgå de dominerende tendenser, når det gælder retningslinjer for organisering og fastlæggelse af roller i forbindelse med etablering og drift af datavarehuse i større organisationer. Datavarehuse, der opstår i en enkelt forretningsenhed, har ofte begrænset anvendelighed. Ønsker en virksomhed, som består af flere forretningsenheder, et samlet overblik, skal der etableres en central løsning, som tilgodeser virksomhedens strategiske perspektiv. Strategiske datavarehuse giver typisk mulighed for at samle og analysere data på tværs af organisatoriske enheder. Over de sidste 5-8 år har der udviklet sig en praksis for at etablere en central organisatorisk enhed, der har ansvaret for den løbende udvikling og drift af datavarehuset og business intelligence beredskabet i virksomheden. Denne enhed går ofte under betegnelsen et Business Intelligence Competency Centre (BICC). Der findes en righoldig litteratur og research, der behandler netop denne organisatoriske konstruktion og kravene til enhedens opgaver, kompetencer og roller. 1 9 0 5 2 0 1 0 1 0
Baggrunden for at etablere en egentlig organisatorisk enhed er, at behovet for tværgående koordinering og styring typisk overgår, hvad man kan rumme i en enkelt rolle i f.eks. it-afdelingen. Samtidig er det vigtigt at have en stærk forretningsmæssig forankring, idet det jo er forretningsmæssige problemstillinger, som skal analyseres. Derfor kan det være en fordel at rykke et sådant kompetencecenter ud af en it-afdeling, og give det et forretningsmæssigt fokus (hvad kunne vi tænke os at vide mere om?) i stedet for et overvejende teknisk fokus (hvilke data kan man faktisk samle og analysere på?). Kompetencecenteret har på den ene side en stor berøringsflade mod ejerne og forvalterne af de systemer, hvis data man ønsker at overføre til datavarehuset (i det følgende kaldet kildesystemerne og kildesystem-forvalterne ). På den anden side har kompetencecenteret en berøringsflade i forhold til alle brugerne af datavarehuset de analytikere i de enkelte forretningsområder, der vil bruge datavarehuset og business intelligence-værktøjerne til at gennemføre forretningsmæssige analyser. Dette er kompetencecenterets kunder vi kalder dem for brugerne og brugerorganisationerne. Typisk gives kompetencecenteret en række opgaver indenfor følgende områder 3 : (Medvirke til at) definere vision og strategi for den forretningsmæssige anvendelse af datavarehuset og Business Intelligence værktøjerne i organisationen sætte standarder specificere og udvælge teknologi definere arkitektur og sikre overholdelse heraf prioritere projekter uddanne brugere af datavarehuset sikre kommunikation på tværs af forretning og it i forhold til dannelse og anvendelse af data skaffe bevillinger til drift og udvikling af BICC sikre forretningsmæssig optimal fortolkning af den indsigt, som data på tværs giver. Kompetencecenteret skal bemandes med såvel forretnings-orienterede personer som it-specialister. På denne måde sikrer man, at kompetencecenteret på den ene side bygger noget, der er relevant og brugbart, og på den anden side designer noget, der kan bygges. Desuden giver kombinationen den anden mulighed, at it- 3 Gloria J. Miller: Business Intelligence Competency Centers A team approach to maximizing competitive advantage. 1 9 0 5 2 0 1 0 1 1
specialister viser forretnings-analytikerne nye tekniske muligheder, hvilket kan lede til at man gennemfører helt nye analyser og opnår ny indsigt. Navnlig teknologier til data-mining har givet denne type indsigt. Kompetencecenteret skal råde over personer med robuste datavarehus- og BIkompetencer. Desuden vil man tilknytte eksperter med viden om kildesystemerne og analytikere i forretningsenhederne, der skal anvende varehuset. Disse personer vil ofte have en løsere tilknytning typisk vil de have allokeret en del af deres tid til arbejde i kompetencecenteret. Kompetencecenteret har ansvaret for med faste intervaller at vurdere, hvilke ændringer, der skal foretages, for at datavarehuset løbende tilfredsstiller interessenternes behov: Nye datakilder, justering af begrebsmodel, optimering af infrastruktur, nye kuber etc. Kompetencecenteret har også ansvaret for at vedligeholde et Master Data Repository. Der skal være en klar placering af beslutningskompetencen i forhold til prioriteringen af kompetencecenterets projektportefølje samt en tydeliggørelse af mandatet i forhold til systemejere og systembrugere. Figur 3 Rollerne i et BICC Business Sponsor Mindre teknisk BICC Manager Uddannelsesansvarlig MDM administrator Forretningsanalytiker/ Data Steward Dataarkitekt BI Platform Ansvarlig Datavarehus arkitekt Integrationsansvarlig (ETL) Report writer Database Administrator teknisk kildesystemer data BI applikationer Kompetencerne i et BICC bør dække over roller beskrevet i det følgende for at dække forretningsbehov, viden om organisation og processer, viden om værktøjer 1 9 0 5 2 0 1 0 1 2
og applikationer samt viden om data integration og management 4. I Figur 3 er rollerne illustreret sådan, at man kan se, hvor teknisk rollen er, samt hvor i dataindsamlings- og behandlingsflowet rollen har en opgave. Business Sponsor: Sponsoren er typisk en del af virksomhedens eller brugerorganisationens direktion det kan være en person, der er ansvarlig for et eller flere områder, eller det kan være en direktør med tværgående ansvar. Sponsoren har ansvaret for BICCs succes, og for at sikre, at de forretningsmæssige mål i organisationen omsættes til brugbare metrikker og analyser heraf. Business Sponsoren har samtidig et ansvar for, at analyserne anvendes forretningsorienteret i organisationen. Desuden sørger sponsoren for, at der tilføres midler og for, at der defineres vision og mål for BICC, som afspejler organisationens vision og mål. Sponsoren er ikke en del af selve kompetencecenteret. BICC Manager: Skal sikre værdien og potentialet i datavarehuset og være ansvarlig for at det høstes. Ansvarlig for at datavarehusets strategi er på linje med brugerorganisationen og at kravene herfra honoreres. Skal definere og overvåge KPI er 5. Desuden skal BICC manageren lede medarbejdere, underleverandører og komitéarbejde. Sidstnævnte typisk ved uddelegering til den i BICC teamet, der dækker pågældende komitéarbejdes ansvarsområde. Datavarehus arkitekt: Denne rolle har det overordnede tværgående ansvar for arkitekturen undervejs i hele processen fra dataindsamling i kildesystemerne til dannelse af rapporter. Det kræver en omfattende forståelse for både teknisk arkitektur og de forretningsmæssige mål og processer. Gartner sammenligner det med rollen som en CTO (Chief Technology Officer). Projektledelse hører også under denne rolle, men rollen kan ikke erstattes med en ren projektleder, der ikke har den tekniske og forretningsmæssige indsigt. 4 Gartner: Tactical Guideline: Comparing Business Intelligence and Data Warehouse Staffing Levels 5 Key Performance Indicators 1 9 0 5 2 0 1 0 1 3
Data Arkitekt: Denne rolle har ansvaret for opbygningen af logiske datamodeller og design af de fysiske datamodeller. De bedste til at mestre denne roller har omfattende erfaring med at foretage forretningsanalyser og omsætte disse til abstrakte modeller. Integrationsansvarlig: Rollen som integrationsansvarlig kan deles i to - en leder/arkitekt og en udvikler - alt efter størrelse af BICC. Den integrationsansvarlige skal dels kunne kode ETL (Extract, Load, Perform) scripts. Dels skal rollen besidde en indgående forståelse for datakvalitet og kildesystemernes opbygning. Forretningsanalytiker/Data-steward: Denne rolle har en indgående forståelse for brugerorganisationens krav og mål. Typisk kommer personer, der har denne rolle, fra forretningen. Data-stewarden kan kommunikere med organisationen og omsætte det til de rette analyser. Samtidig kan personen vurdere datakvaliteten i kildesystemerne. Master Data Management (MDM) administrator En rolle, som spænder over ansvar for en fælles harmonisering af data med udgangspunkt i fælles begrebsdefinitioner, brug af datakvalitets- og harmoniseringsregler (omhandlende dataprofilering, datastandardisering, datamatch og datarens) og ikke mindst implementering af fælles master data repository. Desuden skal rollen have fokus på data governance dækkende ejerskab, forankringsansvar og vedligeholdelsesopgaver for data og datakvalitet. Report Writer: Denne rolle kræver en person, der mestrer de værktøjer, der anvendes i rapportdannelsen. Typisk er de gode til at udforme SQL (Structured Query Language) og efterfølgende bygge en rapport op baggrund af et analyseønske fra organisationen. BI Platform Ansvarlig: Denne rolle dækkes bedst af en, der har en indgående viden om den BI teknologi, man har valgt. Personen skal kunne overvåge og støtte al aktivitet, brugerorganisationerne har i det valgte analyseværktøj. Personen skal kunne forstå et analyseønske og kunne forme de rette databasequeries samt præsentere dem i en rapport, der kan forstås af brugerorganisationen. Han skal kunne præsentere de dimensioner og mål, organisationen har defineret et behov for i et sprog, der forstås af organisationen. Desuden har denne person ansvar for sikkerhed og performance i onlineværktøjet. 1 9 0 5 2 0 1 0 1 4
Database Administrator: Denne rolle dækkes typisk af en klassisk databaseadministrator, der sørger for overvågning og optimering af diskplads, den fysiske datamodellering samt arkiverings- og sletteregler. Uddannelsesansvarlig: Denne rolle har ansvaret for at træne brugerne i brugerorganisationerne i at anvende BI-værktøjerne. Desuden vil denne rolle også typisk være en ambassadør for BICC, der skal sørge for, at kendskab til og nytten af BICC når rundt i hele brugerorganisationen. Iflg. Gartner er denne rolle ofte undervurderet, hvilket kan betyde, at BICC bliver isoleret uden den nødvendige sammenhæng til brugerorganisationerne. 2.5. Datavarehus worst practice Ligesom der har etableret sig best practice, når man skal bygge etablere og drive et datavarehus, er der også gjort en del dårlige erfaringer worst practice som er mindst lige så lærerige. Nedenfor listes en række faldgruber, man skal undgå. Faldgrube 1 For meget Organisationer falder ofte i den fælde at forkøbe sig på hardware og software af flere årsager. For det første er it-leverandører ofte gode til at overbevise organisationer om det fordelagtige i at købe ind i så store mængder, at der kan opnås mængderabat. For det andet er organisationer ofte overoptimistiske i forhold til udrulningsplaner, hvilket betyder, at man typisk får købt for mange licenser i forhold til, hvor mange brugere, der realistisk set kommer til at anvende datavarehuset. Erfaringerne viser, at man udover indkøb også betaler for vedligeholdelse og opgraderingsmuligheder, og at dette opgøres pr. licens, uanset om den er i brug eller ej. Fejlindkøb er også sandsynligt, hvis indkøbene ikke er koordineret med indkøb af BI 6 -værktøjer. Denne afhængighed bør afklares, når den tekniske arkitektur fastlægges i datavarehuset. Faldgrube 2 Urealistiske økonomiske forudsætninger Et datavarehus bør betragtes som en vigtig infrastruktur-komponent. Dette betyder ikke, at man bare skal kaste sig ud i et datavarehus-projekt uden et budget. Men at forsøge at lave en beregning af tilbagebetalingstiden for datavarehuset giver typisk ikke mening. Man skal i stedet se på alternativerne, som vi også har 6 Business Intelligence 1 9 0 5 2 0 1 0 1 5
gjort i denne analyse. Analyser uden et datavarehus er ressourcekrævende og langsommelige, og fordelene ved at anvende forskellige analytiske værktøjer uden et datavarehus er begrænsede. Så i stedet for at vurdere, hvad man kan tjene på et datavarehus, bør man vurdere, hvad et datavarehus giver mulighed for at analysere. Værdien består i, hvad værktøjerne genererer, som f.eks. tværgående koncernrapporter, analyser samt muligheden for data mining 7. Faldgrube 3: Modellering af alt Når datavarehuse ikke tilfører den forventede værdi, skyldes det typisk, at man vælger at modellere alle data, som brugerorganisationerne 8 kunne tænkes at ville bruge, inden man begynder leverance fra datavarehuset. Dette tager alt for lang tid, og risikoen for at levere analyser, der ikke tilfører forretningsmæssig værdi, er stor. Det er vigtigt at vælge sig et delområde, der forventes at tilføre brugerorganisationen værdi hurtigt. Derfor skal man definere en skarp prioriterings- og kravproces. I analysen skal både den forventede forretningsmæssige gevinst og omkostningerne i form af ressourcetræk og hyppighed indgå. Med hyppighed menes en vurdering af forretningsmæssig værdi ved hyppige rapporteringer sat i forhold til omkostningerne ved samme. Faldgrube 4 Manglende fleksibilitet Et datavarehus bør aldrig betragtes som færdigt. Forretning og organisationer ændrer sig, og derfor ændrer behovene sig også. Et datavarehus bør være fleksibelt og konstant tilpasse sig ændrede analysebehov og ændrede datamuligheder. Organisationer bør være ekstra opmærksomme på at kunne håndtere dimensioner, der kun ændrer sig langsomt. Selvom vedligeholdelse af det organisatoriske eller forretningsmæssige indhold som regel ikke udgør det store problem, skal man være opmærksom på, at vedligeholdelsen af den organisatoriske eller forretningsmæssige kontekst (relationer og strukturer over tid) kan ændre sig og måske endda så langsomt, at man ikke bemærker det, med risiko for stigende negativ effekt på troværdigheden af data. At sikre en dynamisk datavarehus livscyklus kræver en change management proces, som fokuserer på iterativ udvikling, implementering og vedligeholdelse. 7 Data mining er analyse af egne informationer. Populært kan man sige, at data mining går ud på at få "vredet" alt det, der ligger gemt i eksisterende internt talmateriale, for anvendelige informationer. Gennem data mining søges efter skjulte mønstre i en stor gruppe af data. 8 Brugerne defineres her som de, der er aftager af analyser. 1 9 0 5 2 0 1 0 1 6
3. Cases 3.1. Indledning Vi har gennemgået en større mængde datavarehus-cases for at finde eksempler, der kunne være relevant for dette projekt. De er identificeret dels igennem researchmateriale og dels gennem en række interviews med de førende globale leverandører på Business Intelligence og Datavarehus markedet. Disse interviews har givet adgang til de største reference-kunder, hvoraf nogle af dem beskrives nedenfor. Vi har udvalgt fire cases, som vi mener, har en vis relevans for dette projekt. Ingen af de udvalgte cases har samme detaljeringsgrad (granularitetsniveau) som det foreslåede datavarehus. Til gengæld har vi fundet datavarehuse indenfor uddannelsesområdet, der behandler store elevpopulationer og meget store datamængder. Disse beskrives kort nedenfor med links, hvis der ønskes yderligere information. 3.2. TEA (Texas Education Agency) 3.2.1. Beskrivelse af casen TEA driver et datavarehus, der understøtter den nationale kampagne No child left behind, hvor man i en række stater har iværksat programmer til at måle og på den måde fange elever, der ellers ville droppe ud af skolen (1-12 klasse) og/eller få en mangelfuld grund- og ungdomsuddannelse. I Texas er denne funktion samlet i TEA, som er en offentlig organisation, der samler information ind og rapporterer vedr. skolernes elever, skolernes økonomi og skolernes lærere. Organisationen er ansvarlig for 1.200 uafhængige skoledistrikter med 4,6 mio. elever, som bliver teknisk serviceret af 20 Educational Service Centers. TEA administrerer over 20 milliarder dollars om året. De overvåger også statens statewide curriculum samt "compliance" i forehold til de føderale retningslinjer. Derudover administrerer de staten Texas assesment program. TEA laver også benchmarking mellem de enkelte skoler, hvor de blandt andet distribuerer rapporter vedr. best practice på skoleområdet 9. Endelig fordeler TEA økonomiske midler fra staten Texas og det føderale niveau. Der er typisk ½ mio. brugere, der trækker data (politikere, forskere og skoleadministratorer) og der er offentlig adgang til ikke-personfølsomme oplysninger. TEA anvender IBM Cognos efter også at have overvejet Information Builders og SAP Business Objects. 9 http://ritter.tea.state.tx.us/bestprac/bpc_resources.html 1 9 0 5 2 0 1 0 1 7
TEA er ved at udvikle et datavarehus, der kan håndtere data på tværs af staten for alle uddannelsesområder, som giver viden om frafaldsårsager, beskæftigelsessammenhænge osv. osv. 10 3.2.2. Relevans TEA løsningen er en klassisk datavarehus-løsning i stor skala på skoleområdet. Der er fokus på både performance, optimering samt kvalitet af elevernes skolegang, hvilket er særdeles relevant for de berørte ministerier i Danmark. Samtidig er det en løsning, der dækker mange skoledistrikter, som styringsmæssigt er uafhængige. Data er på individniveau, og der er en kobling mellem økonomiske, administrative og elev-relevante data. 3.2.3. Begrænsning Dette datavarehus omfatter alene 1-12 klasses elever, og dækker således ikke videregående uddannelser. 3.3. TPEIR og PREP (Texas) TPEIR (Texas P-16 Public Education Information Resource) og PREP (profile Report Electronically produced) er to relevante datavarehuse, da der indsamles data på individniveau på højere læreanstalter på tværs af distrikterne samt udarbejdes forløbsanalyser, og da systemerne (formodentlig) anvender standardiserede databaseværktøjer. Og så er det meget store mængder data, der indsamles og analyseres. Desuden er PREP interessant som et værktøj, der online kan producere queries for folk, der ikke kan programmere. TPEIR - Texas P-16 Public Education Information Resource TPEIR, Texas P-16 Public Education Information Resource, er et samarbejde mellem Texas Higher Education Coordinating Board, Texas Education Agency og State Board for Educator Certification. Dette Datavarehus drives af Texas Education Agency og indeholder forløbsanalyser med person-orienteret information herunder studenter-, kandidat-, lærer- og fakultetsdata 11. 10 http://www.tea.state.tx.us/index2.aspx?id=7639&menu_id=938. 11 Se mere på http://www.texaseducationinfo.org/tpeir/ 1 9 0 5 2 0 1 0 1 8
PREP - profile Report Electronically produced PREP er et andet datavarehus, som indeholder data for Texas højere læreanstalter. Det er blandt andet data vedrørende den studerende, kandidater, ansøgere, lærere og klasserelaterede data. Der er også (dog ikke fuldt ud) data vedr. arbejdsmarkedet. Det er muligt at lave online forespørgsler og danne rapporter via deres hjemmeside 12. 3.4. HESA (Higher Education Statistics Agency) 3.4.1. Beskrivelse af casen HESA er en national organisation for opsamling af statistik på tværs af alle offentlige universiteter og andre højere læreanstalter i Storbritannien i alt 167. HESA blev dannet i 1993 i samarbejde med de relevante ministerier og de højere læreanstalter. HESAs øverste ledelse er en direktion bestående af udpegede fra de højere læreanstalter. Organisationen, som er selvejende, leverer på kontrakt til staten de data, denne måtte ønske sig. Finansieringen af organisationen sikres af de højere læreanstalter, der har status af at være medlemmer, som betaler medlemskontingent. Data anvendes af universiteterne selv, men staten anvender også data i forbindelse med finansiering. Desuden er uddannelsespolitikken formuleret på baggrund af data fra HESA. Som eksempel på dette kan nævnes, at der blandt andet produceres analyser af beskæftigelsesrater og frafaldsrater. Desuden registreres der en række KPI er 13. HESA registrerer data på individniveau i størrelsesordenen 2,3 mio. studerende og 0,5 mio. medarbejdere. HESA opbevarer data tilbage fra 1994. Indsamling af data foregår via inddatering i XML-skemaer (defineret af HESA), der uploades digitalt på en website. HESA mener, at det er for komplekst at have en automatisk ETL proces pga. mange forskellige datakilder. Teknologisk har HESA valgt at udvikle deres egne applikationer til datahåndtering og analyse. Infrastrukturen er virtuel med en LINUX/Oracle database og Mi- 12 Se mere på http://www.txhighereddata.org/interactive/prep_new/ 13 KPI er en forkortelse for Key Performance Indicators 1 9 0 5 2 0 1 0 1 9
crosoft-baserede kontorapplikationer. På HESAs hjemmeside 14 kan man finde diagrammer, der illustrerer relationerne mellem data. 3.4.2. Relevans De data, HESA registrerer, og de analyser, de foretager, er relevante for nærværende projekt. Governance er også interessant, da vi har med tværgående data at gøre. 3.4.3. Begrænsning Der anvendes ikke standard datavarehusteknologi, ligesom der ikke foretages en automatiseret ETL proces. 3.5. Københavns Kommunes Koncern Service Ledelsesinformation (KS- LIS) 3.5.1. Beskrivelse af casen Københavns kommune har 520.000 indbyggere, 45.000 ansatte samt 10 bydele. Desuden administrerer kommunen et budget på 31 mia. kroner. Kommunen er organiseret i 7 forvaltninger med hver deres borgmester. Hver forvaltning har et selvstændigt ansvarsområde med en borgmester, der refererer direkte til borgerrepræsentationen og altså ikke til overborgmesteren, hvilket gør tværgående initiativer komplicerede. Kommunen udviklede i 2008 et datavarehus, der konsoliderer data på tværs af forvaltningernes forskellige systemer indenfor områderne fravær, økonomi og personale for at sikre, at der fremover træffes beslutninger på baggrund af retvisende og ensartet data på tværs af forvaltningerne. Datavarehuset er under løbende udvikling. Lige nu er etableret et pilotprojekt, hvor et datavarehus i en af fagforvaltningerne er koblet på koncerndatavarehuset som et kildesystem. Hensigten er, at der primo 2011 er fuld integration af forvaltningernes egne datavarehuse i et stort koncerndatavarehus. KS-LIS (Ledelses Informations System) har valgt en Oracle løsning, som kostede dem 15 mio. i udviklingsomkostninger, og som løbende koster 5 mio. i drift. Ud- 14 http://www.hesa.ac.uk/index.php 1 9 0 5 2 0 1 0 2 0
viklingsomkostningerne er finansieret af Koncern Service (KS), mens driften finansieres af fagforvaltningerne. Koncern Service ejer de tværgående kildedatasystemer (økonomi og personale), mens data i fagforvaltningerne ejes af fagforvaltningerne. Organisatorisk er KS- LIS forankret i et centralt kompetencecenter med 10 medarbejdere og egen lokal hosting. De, der har domænespecifik ekspertise (datastewards), har organisatorisk reference ud i fagforvaltningerne, mens de fysisk sidder i kompetencecenteret. Beslutningskompetencen for så vidt angår udvikling og anvendelse af koncerndatavarehuset ligger i den interne koordinationsgruppe, som består af en chef for hvert af områderne: HR, Økonomi, Fravær samt it-platform. Ved uenighed løftes problemet helt op på borgmester/direktør niveau. Gevinsten er foreløbig, at man pga. overblik over fravær har sparet mellem 50 og 60 mio. kr. i hidtil manglende sygedagpengerefusion. Desuden har man fået standardiseret data og fået defineret metadata meget grundigt, så man rent faktisk kan sammenligne informationer. 3.5.2. Relevans Her er et klassisk datavarehus, som har samme udfordring som nærværende projekt vedr. governance. Dvs. en række selvstyrende forvaltninger, hvor der kræves enighed og buy-in. Samtidig er KS-LIS et eksempel på oprettelse af et centralt kompetencecenter. 3.5.3. Begrænsning Data vedrører ikke uddannelsesområdet, ligesom omfanget af datamængden ikke matcher. 1 9 0 5 2 0 1 0 2 1
4. Litteraturliste 1. Kimball, Ralph (2008). The Data Warehouse Lifecycle Toolkit, 2nd. ed., Indianapolis, Indiana: Wiley Publishing Inc. 2. Kimball, Ralph (2002). The Data Warehouse Toolkit, 2nd. ed., Indianapolis, Indiana: John Wiley and Sons, Inc. 3. Inmon, William H. (2005). Building the Data Warehouse, 4th. ed., Indianapolis, Indiana: Wiley Publishing Inc. 4. Miller, Gloria J., Bräutigam, Dagmar (2006). Business Intelligence Competency Centers, 1st. ed.,hoboken, New Jersey: John Wiley and Sons Inc. 5. Davis, Jim (2006). Information Revolution, 1st. ed., Hoboken, New Jersey: John Wiley and Sons Inc. 6. Davenport, Thomas H. (2007). Competing on Analytics, 1st. ed., Boston, Massachusetts: Harvard Business School Press. 7. Moss, Larissa T., Atre, Shaku (2003). Business Intelligence Roadmap 1st. ed., Crawsfordville, Indiana: Addison Wesley 8. Gartner: Best Practices in Data Transformation and Loading Architecture (2009) 9. Gartner: Data Warehouse Architecture Best Practices and Guiding Principles (2009) 10. Gartner: Overview of Data Warehouse Project Delivery in 2009 (2009) 11. Gartner: Tutorial: Basics of Data Warehouse Governance (2008) 12. Gartner: Tactical Guideline: Comparing Business Intelligence and Data Warehouse Staffing Levels (2009) 1 9 0 5 2 0 1 0 2 2