Erfaringer med OBIEE(10g ) og Scrum prosjektmetodikk

1. Erfaringer med OBIEE(10g) og Scrum prosjektmetodikk Gabriela Seres, Enterprise Architect

2. Innhold Erfaringer med OBIEE(10g) : • Krav (fort) • Implementasjon (kort) • Arkitekturvalg (kort) • Utvikling, Test og Vediklehold • Bruk (NRK innspil) Prosjekt metoden fulgt - Scrum • Teori (kort) • Hvorfor • Team, produkt eier • Backlog / Sizing • Iterasjoner • Scrum Verktøy • Brukes med fornuft …

3. HW Arkitekturen - NRK HW Arkitekturen består av 3 maskiner m/MS win 2003 64-bit: • 1 database/datavarehusserver for både utviklings- og produksjonsmiljøet • Oracle Database 10g Enterprise Edition (10.2.0.3) • Oracle Warehouse Builder 10g (10.2.0.2) • Oracle Workflow 10g (10.2.0.2) • 1 applikasjonsserver for produksjon • Oracle Business Intelligence Enterprise Edition (10.1.3.3.2) • 1 applikasjonsserver for test/utvikling • Oracle Business Intelligence Enterprise Edition (10.1.3.3.2)

4. Forklaring av ord, uttrykk og begreper • OBIEE Oracle Business Intelligence Enterprise Edition Plus • OWB Oracle Warehouse Builder • OWH/ OVH Oracle Warehouse/Oracle Varehus • WF Workflow • SCD Slowly Changing Dimensions – Versjonering • ETL Extract, Transform, Load • U/T/P Utviking/Test/Produksjon • ODS Operational Data Store

5. I forkant av utlysningen ble det gjennomført et forarbeid • Identifisert rapporterings- og analysebehovet • Utarbeidet forslag til rapportstruktur • Identifisert rapport- og analysedimensjoner • Identifisert datakilder samt mappinger mellom kilde og dimensjoner • Definert prosjektets omfang, avgrensinger og prioriteringer. • Driftsresultat (planleggings-/budsjetteringsverktøy) • Bemanning • Program/marked Usikkerhet rundt dynamiske rapportene. Mye ble byttet ut underveis. Fleksibilitet hos begge part. Nært samarbeid. Prioritering. Dyktige IT/ forretning spesifikke personer. Prosjekt eier med gjennomslags kraft og interesse. Forretning ? ODS?

6. Kritiske suksessfaktorer for en måloppnåelse er at løsningen • Gir god brukeropplevelse og brukervennlighet gjennom intuitive brukergrensesnitt. • Har rask responstid for brukeren. • Er skalerbar. Løsningen må kunne vokse med endret behov. • Er webbasert med gode sikkerhetsløsninger for rollestyrt tilgangskontroll. • Har en arkitektur som kan integreres godt med NRKs eksisterende og fremtidige systemer. • Rask og effektiv implementeringstid. • Komplette data for de områdene datavarehuset skal omfatte • Sterk og god integrasjon med MS Office og andre hyppig brukte programmer i NRK • Kan enkelt tilpasses/skreddersys for ulike brukere og endringer i organisasjonen • Programvare har norsk språk i menyer, skjermbilder, hjelpetekster • Pris

7. Valg av OBIEE • Oracle OBIEE ble valgt da den var produkt som beviste å kunne tilfradstilte alle krav • POC • Både leverandør og kunden var spente • Siebel & Hyperion integrasjon (produkt og foretning) • blandet erfaring med forrige versjon • Ingen andre installasjoner i Norden (sommer2007) ... Og Oracle OBIEE sviktet IKKE

8. Systemskisse og dataflyt

9. BIT krav – OBIEE - Responstider og skalering • Sluttbrukerløsningen - ca 800 brukere der ca 300 er samtidige brukere. • Løsningen - skalerbar. Mulig øke både antall brukere, ERP-systemer og volumer, uten at responstidene endres nevneverdig. • Kort responstid - Standardrapport • Kort responstid - Drille seg fra ett nivå i et hierarki til neste. • Kort responstid - Flytte på en dimensjon i en rapport. ... Og Oracle OBIEE sviktet IKKE

10. BIT krav – OBIEE - Sikkerhet • Autoriserte brukere - tilgang til løsningen, gjennom en singel sign-on. • Systemets med egen tilgangskontroll som styrer hvilke data og hvilke skjermbilder enkeltpersoner eller brukergrupper skal ha tillatelse til å se/endre. • Styring av brukerautorisasjoner - ActiveDirectory eller et annet verktøy. • Brukertilganger - på tvers av rapporteringsdimensjoner

11. BIT krav – OBIEE - Integrasjon • Integreres med og lagre grunndata fra alle NRKs kildesystemer i ett sentralt datalager. • Innskannede bilag - slå opp og vise dem som er knyttet til en transaksjon, f. eks en innskannet faktura, sykemelding eller lignende. • Logg - All lasting av grunndata fra kildesystemer må loggføres, og en rapport som beskriver lasteprosessen skal genereres • Basert på automatisk lasting av grunndata i form av skedulertebatchjobber, men må tillate manuell lasting. • Data som lastes gjennomgår automatiserte rutiner som kontrollerer datakvaliteten. En logg som beskriver de ulike steg i prosessen, samt evt. feil, skal genereres. • Data som lastes manuelt gjennomgår de samme kontrollrutiner • Integrasjon mot MS Outlook slik at rapporter og analyser kan distribueres til andre brukere • Godt integrert med MS Office • Rutiner som sikrer at samme data ikke lastes flere ganger fra kildesystemene.

12. BIT krav – OBIEE - Dim og strukturer • Operere med flere alternative rapporteringsstrukturer samtidig, innenfor samme rapporteringsdimensjon. • Laste inn og oppdatere nye strukturer i datavarehuset minst èn gang i døgnet (fra kildesystemene) • Superbrukere - endre eller opprette alternative strukturer innenfor en rapporteringsdimensjon • Gjenbruk av dimensjoner • Ubegrenset antall dimensjoner

13. BIT krav – OBIEE - rapportering • Rapporteringsgrensesnittet - webbasert, og fungerer med nettleseren Internet Explorer på PC men ikke Safari på Mac. • Opprette og lagre bruker- og rolletilpassede "arbeidsflater"/portaler som presenterer de viktigste tallene som vedkommende er opptatt av og brukeren skal kunne gjøre dette selv • Drille seg ned i alle hierarkier og strukturer, helt ned på transaksjoner og innskannede bilag, i henhold til brukerens tilgangsnivå. • Kraftige matematiske og logiske funksjoner • Rapporter som er opprettet av en bruker - lett tilgjengelig for andre brukere. • Informasjon presenteres tabellarisk og grafisk med flere dimensjoner • Fargekoding for å vise tall som ligger utenfor / innenfor forhåndsdefinerte verdier for å synliggjøre avvik. • Enkelt å opprette og legge til kommentarer i en rapport som kan leses av andre brukere.

14. BIT krav – OBIEE - rapportering • Systemadministrator og superbrukere ønsket å opprette egne rapporteringskuber. Som er et aggregert utdrag av den sentrale informasjonsplattformen for å støtte spesifikke rapporteringsbehov. • Drille seg fra en rapporteringskube ned i datavarehuset via "Drill-through". • Eksportere rapporter uten kobling til kilden, f. eks til MS Office og til PDF-format. • Kjørte rapporter lagres i kataloger/områder, slik at flere brukere får tilgang til dem. • Legge inn korrigeringer til tallene i rapportene, f.eks ved periodiseringsfeil eller bilag som er feilført. • Legge inn prognose i rapportene, trasaksjons nivå • Rapporter - danner grunnlag for juridiske dokumenter, revisjonsspor i systemet

15. BIT krav – OBIEE - rapportering • Rapporter som presenterer mer enn en dimensjon i samme kolonne • Arbeidsflyt (workflow), for eksempel til bruk i en månedsrapportering der det skal rapporteres gjennom flere ledd fra bunn til topp i organisasjonen og automatisering av kjøringene.

16. BIT krav – OBIEE - Analysering • Ad-hoc analyser – Super- / Sluttbruker • Ad-hoc - Ta vekk og legge til dimensjoner i både rapporter og analyser, samt endre plasseringen av disse • Ad-hoc - Opprette brukerdefinerte kalkuleringer og beregninger i analysen • Ad-hoc - Drille seg ned på transaksjonsnivå, medarbeidere og innskannede bilag • eksportere analyseresultatet både med og uten kobling til kilden, for eks. til MS Office og til PDF-format.

17. BIT krav – OBIEE – Planlegging / budsjettering For å tilfredsstille budsjett , prognose , rapport- og analysebehovene var det ønsket at budsjettverktøy integreres med løsningen, i stedet for å budsjettere i kildesystemene Oracle Hyperion Planning Pris

18. NRKs erfaringer med OBIEE • Ingen feil eller problemer med programvaren • Bra implementeringsteam fra Bouvet • Blandet erfaring med eksterne konsulenter • Vanskelig å spesifisere hva man vil ha uten å kjenne teknologien/mulighetene • Må ha prosjektdeltakere med mandat til raske beslutninger • Må ha tilgang på kildesystemeksperter • Ingen store blundere så langt Ref. Morten Jesen, Direktør Teknologi, NRK og prosjekt eier Ref. Harald Haugerud, Direktør Foretnings Utvikling, NRK og prosjekt eier

19. Implementasjon • Dedikerte servere • Oracle – DWH, Bouvet – OBIEE • Etablert versjon mot beta versjon / 0 versjon • 64-bits utfordring • Totalinntrykk

20. Arkitekturvalg • KimbalvsInmon • 3NF mot mer generiske strukturer • Oracle standpunkt? • MDM - referanse DB • SCD • dynamiske hierarkier • Total inntrykk

21. Utvikling, Test og Vedlikehold (OWB og OBIEE) • Hetrogene kilder • OWB - Kraftig men krever dyktige utviklere, Erstattes av ODI (Sunopsis) • WF - Erstattes av ODI (Sunopsis) • OBIEE – Administrator verktøy • Slutt– & Superbruker kurs • Hva kommer – EPM = BI + PM • Siebel, • Sunopsis, • Sigma dynamics • Hyperion

36. Så ….Kompleksiteten rundt BI løsninger er krever en kombinasjon av investering, kunnskap og tid • Utvikle en detaljert forståelse av datakildene (dyktighet) • Hensiktsmessig design av datavarehuset i forhold til fokusområdene • Fleksibelt ETL verktøy trengs for å flytte data (dyktighet) • Forstå behovene til alle brukergruppene (tid) • Bygge rapporter er respektive behov (dyktighet) • Utvikle grafisk sammendrag av de viktigste tallene (dyktighet) • Regler for sikkerhet og tilganger (tid) • QA og ytelse (tid) • Feilretting og oppgraderinger (tid)

42. Prosjekt metodikk – Scrum /Agile /Smidig Fosefall vs Agile metoder • Kjennetegn • Iterative – utviklingisykluser • Inkrementelle – funksjonalitetkommertillittetterlitt • Selvorganiserende team • Adaptive – tilpassersegendringer • Manifest for smidigsystemutvikling • Individer og interaksjon over prosesser og verktøy • Fungerende program over fullstendigdokumentasjon • Samarbeid med kunden over kontraktsforhandlinger • Å svare på endringer over å følge en plan Selv om vi ser at det er verdi i elementene til høyre, verdsetter vi elementene til venstrehøyere

43. Kort om Scrum: • Planlegging 1d Backlog, estimere (bilder) • Gjennomføring 2-8 uker Daglig scrum • Avslutning 1d Demonstrasjon • Når Passer Scrum?

44. Ressurser, ansvar og oppgaver Viktigheten : • Produkteier – suksess faktor no 1– en eier med gjennomslag – foretnings orientert – IT ansvarlig for gjennomføringen - Kunde • Styregruppen – tverrfaglig – felles mål -Kunde • Referansegruppen – Foretning • Chickens – IT spesialtister : konsulent – Test : Kunde • Fasilitator – Arkitekt (Kunde/konsulent) • Team –BI fokusert – 2: 20 – Milles kognitiv kapasitet – Kunde/konsulent

45. Estimering • Iterasjoner • Loddrett : Per kildesystem? Dataobjekt? KPI? Kundegruppe? • Fortere men krever mer forhandsdefinering • Vannrett : Ver. 1, 2…. Ferdigstille del av løsningen. • Best ved mange ukjente variabler • Verktøy : Tavle, Jira, produkter: avhenger av størrelsen, kompleksitet og grad av usikkerhet • Demo : Driver innovasjon

46. When to use… Target Price Pure Agile Reports Planning modeling Scorecard processing Why .. Features not clear Development Flexibility System installation Base BI environment Why .. Shared risk Tender requirements

47. Myter og empiri(og hvorfor vi aldri vil få svaret på om smidige metoder virker) MagneJørgensenSimula Research Laboratory

48. MYTE:Gjennomsnittlig kostnadsoverskridelse i IT-prosjekter er på 189% (Standish Group: 1994-studie, mest referert “software crisis” dokumentasjon) , estimat ganges 2,9 • MYTE: 45% av funksjonaliteten brukes aldri (The Standish Group, igjen) • MYTE : Det optimale antall elementer (f eks i et brukergrensesnitt eller kall fra en rutine) er 7 pluss/minus 2, dvs mellom 5 og 9 • MYTE :“Addingmanpower to a late software project makes it later" The MythicalMan-Month (Brook’s lov) • MYTE: Forskjellen mellom dårligste og beste programmerer er 10:1.

49. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kontrollspørsmål: • Hva betyr utsagnene? Har de noe presist innhold? Er det mulig å falsifisere utsagnene? • Hvorfor har manifestet slått an? • Dette er ”verdier”. Gjør det noen forskjell på om det hadde vært påstander?