IT-Strategimodel. Hvordan vil vi udvikle IT-ydelser og leveringsevne? Hvordan vil vi sikre beslutninger og adfærd? Hvordan vil vi opnå succes?

Transkript

1 IT-Strategimodel Executive summary Demand Control Supply Business context IT principles Enterprise architecture Business success IT-governance IT-services Business capabilities IT financial mgmt. People IT contribution Metrics Sourcing Risks and issues Detailed appendicies Hvordan vil vi opnå succes? Hvordan vil vi sikre beslutninger og adfærd? Hvordan vil vi udvikle IT-ydelser og leveringsevne? 1

2 IT-strategi som dynamisk værktøj Tilsigtet strategi Urealiseret strategi Strategisk beslutning Urealiseret strategi Realiseret strategi Tekn. filter Org. filter Ideer Flerårige handlingsplaner holder sjældent. Vi skal arbejde med kort tidshorisont og hyppige justeringer / evalueringer 2

3 Behovssøjlen Business context Business success Business capabilities IT contribution 3

4 Aktuel kontekst Aarhus Universitet er en organisation i vækst. Vi har en ambitiøs forretningsstrategi med en vision om at tilhøre eliten blandt universiteter Udviklingen skal ske på et solidt etisk grundlag, baseret på de europæiske universiteters magna charta om frihed og uafhængighed Universitetet er en selvejende statslig institution og er som sådan underlagt en række nationale myndighedskrav. Universitetets aktiviteter er i stigende grad baseret på internationale projekter med tilhørende krav om detailrapportering og styring. 4

5 Forretningsmæssigt fokus for IT Afsæt i Universitetsstrategien. IT skal bidrage med understøttelse af kerneaktiviteter Fremragende forskning Talentudvikling Rådgivning og videndeling Uddannelser i verdensklasse IT skal desuden bidrage med understøttelse af Effektiv støtte og service Fysisk infrastruktur af høj kvalitet Fra brugerstyret IT-udvikling til forretningsdrevet IT-udvikling Med forretningsdrevet menes baseret på ledelsesmæssige prioriteringer af, hvad der tjener AU s kerneaktiviteter bedst. Ikke i ordets kommercielle betydning Ikke drevet af teknologiske muligheder Ikke drevet af slutbrugernes ønsker om nice to have (men udviklet i dialog med dem) 5

6 Organisatorisk modenhed i forhold til at anvende IT til forretningsudvikling IT på Universitetet kommer fra et klassisk IT-teknisk fokus og en stærkt decentral beslutningskultur. Organisationen har haft meget svært ved at prioritere tværgående projekter på IT området. Der har traditionelt ikke eksisteret nogen klar rollefordeling mellem forretningsorganisationen og IT-afdelingen. Udvikling har være brugerstyret frem for forretningsdrevet. Der er iværksat en række tiltag til at gøre IT på AU forretningsstyret. Der er principiel enighed, men organisationen skal se resultater for at have tillid til principperne De administrative forretningsgange er - malet med den brede pensel ganske manuelt baseret og præget af dobbeltarbejde. Der er potentiale for øget digitalisering, men begrænset tradition for at høste rationaliseringseffekterne af digitalisering gennem omlægning af gamle arbejdsprocesser 6

7 Organisatorisk modenhed i forhold til at anvende IT til forretningsudvikling (fortsat) Fælles IT-infrastruktur er under etablering, men den nødvendige harmonisering af den fælles IT-platform til de tværgående administrative processer (budget- og økonomi, studieadministration, HR og bygningsadministration) er ikke gennemført forventes afsluttet igennem perioden fra medio 2010 til ultimo Drift og service vinduet svarer til normal kontortid. Der er et stigende ønske fra forretningssiden om udvidet drift og support af visse services (mail, web, remoteadgang og en række tekniske overvågninger), men ingen tradition for at afsætte ressourcer til vagtordninger og lignende tiltag, der peger i retning af 24:7- drift 7

8 IT-teknisk og systemmæssig modenhed IT-teknisk infrastruktur (netværk, identitets og rettighedsstyring m.v.). Forandringsprojektets IT-spor igangsatte radikale ændringer, bl.a. transparent produktionsnet Langvarig proces for hovedområderne at tilkoble deres netværk til nyt fælles fysisk net System til identitetsstyring leveres februar 2010 Langvarig proces for hovedområderne at tilkoble deres brugerstyringsprocesser til ny fælles løsning Drift af økonomibærende administrative applikationer relativt umoden Funktionsadskillelse mellem drift og udvikling igangsat Anvendelse af såkaldte Change Management-procedurer for alle ændringer i produktionsmiljøer igangsat Dokumentation af produktionsløsninger igangsat Lavt niveau for IT-sikkerhed Uhensigtsmæssig IT-arkitektur Monolitisk model frem for modulær model Delfi, PØS, selvbetjening, bygningsregister, enhedsregister og gammelt økonomisystem sammenfiltret i stort edderkoppespind. Dekomponering og nedlukning af uaktuelle systemer en meget stor opgave Implementering af integrationsplatform nødvendig og stor opgave 8

9 Figur 1: Systemlandskabet Systemplatform, administrativ IT på AU Ledelsesinfo Biblioteks systemer Bygningsregister lokalestyring Fællesdrev E-learning CPR-register SU KOT DK stat Targit Datamart BI værktøjer AU-EDW Fælles AU Statsbib. DPU ASB Fælles Exchange Exchange DJF FirstClass Oracle Hum NAT/SAM Exchange Exchange DMU DPU Exchange SUN Exchange ASB Studentmail post.audk Syllabus Bygnings ASB m.fl. register filer Decentrale systemer Fil servere AULA 8000c CampusNet ASB Blackboard DPU m.fl. FirstClass Hum Identity Management Økonomi HR Integrationsplatform Studie administration Forsknings registrering Dokument styring Intranet CMS IDM hovedsystem Lokal brugerstyring System Management Navision 3.60 Fælles Navision 3.60 DJF Navision 4.00 DMU ARS DJF ARS DMU Tids registrering SLS - løn PØS 8000c DMU System DJF System UPS ASB UPS DPU Stads ASB FUA Delfi 8000c+DPU Stads HIH UVA CC Pure 8000c Pure ASB Pure DJF Pure DPU Pure HIH Scanjour 8000c Captia DMU Scanjour ASB Captia DPU Captia DJF 8000c intranet ASB intra DPU intra Sharepoint-services AU Hovedsite Søgemaskine Decentrale sites AU - NET PC/OS udrulning Asset management Foto Tlf PDA Citrix Brugere Word Excel Powerpoint Outlook m.fl. Print & kopi WiFi Aarhus Universitet Rev / FB 9

10 Figur 2: Modenhed, 1 trin af gangen Modenhedstrappe for IT-driftsområdet, status primo 2010 = Realiseret = Planlagt / muligt indenfor 1 år = Ikke realiserbart pt Fælles drift videndelingssystemer Fælles drift studieunderstøttende systemer IT-understøttelse af alle administrative processer Fælles IT-indkøb Fælles teknologiplatforme Udvikling styret af forretningen Proaktiv drift af infrastruktur Procesdrevne forretningsgange (ITIL) Service Level Agreements IT-arkitektur strategi Single Point of Contact support 1 Fælles drift af infrastruktur Fælles brugeradministration Fælles drift af økonomibærende applikationer Ensartet drift af faglige applikationer Ø-drift netværk / infrastruktur Ø-drift, brugeradministration Ø-drift, applikationer Overholdelse af DS484 Fælles services på tværs Cost effektiv drift Fælles standarder 10 Fragmenteret Harmoniseret Standardiseret Best practice

11 IT s bidrag, 5 fokusområder Levere basal IT-drift som vand ud af hanen. Kosteffektiv platform, der evner at opfange og supportere medarbejdernes behov, f.eks. i forhold til eksternt samarbejde og mobilitet også internationalt Facilitere tilrettelæggelse af undervisningen Fx. ved at tilbyde velfungerende studenterportaler, selvbetjeningsløsninger, e-læringsværktøjer m.v. Tilbyde at afløfte VIP ernes daglige administrative opgaver Værktøjer, der forenkler og automatiserer administration indenfor forskning og formidling. Fx videomøder fra PC en eller forenklet udførelse af censur og bedømmelse eller mere brugervenlig PURE Løfte kvaliteten i sagsbehandling / myndighedsopgaver generelt Understøtte en sammenhængende og effektiv administration med digitaliserede og sikre workflows, Fokus på datakvalitet og sikkerhed, herunder persondatalovgivning Understøtte AU s branding og image, herunder styrke fusionsidentiteten Møde kunderne, der hvor de er - på hjemmesiden. Transparens og videndeling på intranet 11

12 Styringssøjlen IT principles IT-governance IT financial mgmt. Metrics 12

13 IT-principper IT skal skabe værdi for forretningens primære processer ved at digitalisere standardiserbare end-to-end forretningsprocesser Model for screening og vurdering af nye projektforslag tages i anvendelse Digitalisering af processer forudsætter, at processerne er harmoniserede / ensartede Værdiskabelsen øges, hvis processer tænkes fra start til slut uanset, hvor i organisationen de løses Digitalisering med færrest mulige systemer Præference for standardsystemer. Hvis der ikke findes standardsystemer foretrække universitetsfælles løsninger. Hvis dette ikke findes, kan der laves egenudvikling se evt. bilag om kendetegn ved standardsystemer Systemplatform med 4-5 administrative hovedsystemer fra et begrænset antal hovedleverandører og AU-intern integrationsplatform Vælges efter best of breed (bedst til aktuelle opgave) ikke nogen ambition om best of suite (samlet løsning til alle opgaver, fx som i systemet SAP) Hovedopgaven for intern udviklingsafdeling er integration mellem standardkomponenter Forretningsdreven transformation Behov for skarp prioritering mellem nice to have og need to have som primært en ledelsesopgave. Ikke primært en brugeropgave. Harmonisering af heterogene systemer vil i en overgangsfase medføre reduceret service for enkelte brugere /områder. Ibrugtagning kan ske asynkront. 13

14 IT-principper (fortsat) IT skal bidrage til at effektivisere og rationalisere samt skabe serviceforbedringer i AU s administrative støtteprocesser Standardisering, harmonisering, business cases, projektstyring Effektiv drift og support er ikke rocket science. Lær af, hvordan andre organisationer har skabt resultater. Teknologivalg v. standardsystemer. Sondring mellem producent og implementeringspartner Producent: Krav om stor markedsandel indenfor sektoren og langtidsholdbarhed Implementeringspartner: Skal kunne udskiftes. Krav om overholdelse af standarder og dokumentation. Kommercielt produkt eller open source-produkt. Vælges pr. projekt Fokus på Total Cost of Ownership (TCO), Hvad koster det at anskaffe og holde løsning i stabil og sikker drift over hele levetiden Service level agreements og ydelseskataloger til styring og forventningsafstemning indenfor drift og support. Oppetid, fejlretningstid, åbningstid i support m.v. 14

15 Bilag: Kendetegn ved standardsystemer Med et standardsystem køber organisationen en langtidsholdsbar understøttelse af forretningskritiske processer og begrænser valgfriheden i forhold til at tilrettelægge arbejdsgangene og afprøve nye strukturer. Et standardsystem er bl.a. kendetegnet ved, at det er: Udviklet af ekstern leverandør med solidt domænekendskab Normalt fra en større, markedsledende leverandør med god likviditet Leverandøren er forpligtet til at modernisere systemet løbende (nye myndighedskrav + ny teknologi) Der findes et solidt marked, hvor mange kunder til sammen sikrer ressourcer til videreudvikling Kunden kan vælge forskellige varianter af arbejdsprocesser gennem konfigurering, men ikke udvikle egne varianter eller ændre datamodeller Systemet er forberedt til integration med andre systemer gennem åbne standarder Specialudvikling til systemet skal normalt begrænses, så man ikke falder af leverandørens road map 15

16 IT-styring og -governance IT-principper Infrastruktur Arkitektur Forretningens applikations behov Investering og prioritering Input rettigheder Input rettigheder Input rettigheder Input rettigheder Input rettigheder Beslutningskompetence Beslutningskompetence Beslutningskompetence Beslutningskompetence Beslutningskompetence Rektorat Fælles IT Institutledere / H.O. ledere Admin. chefer + FALK-kreds IT-forum (nyt) Brugere IT-forum foreslås etableret med indstillingsret til rektorat. Universitetsdirektør som formand, 5-6 medlemmer med indsigt i såvel IT som forretningsledelse og som har et tværgående fokus. Gerne 1-2 VIP er. Studerende repræsenteret indirekte via fx fokusgrupper 16

17 Styring og allokering af IT-budgetter Større tværgående systemanskaffelser sker igennem fælles IT-projekter med eget budget, forslag til beløbsgrænse: > kr Mindre, lokale systemanskaffelser finansieres decentralt. AU-IT inddrages i teknologivurdering For alle væsentlige applikationer udnævnes systemejer / dataejer. Budget til licensvedligeholdelse, service og support hos systemejer Budget til drift kan ligge lokalt eller i AU- IT Budget til drift af fælles infrastruktur hos AU-IT. Undervejs i harmoniseringsprocesserne kan der forekomme undtagelser! 17

18 Kort om systemejerbegreb Systemejer s opgaver: Sikre finansiering af anskaffelse og vedligeholdelse af system og licenser Godkende og prioritere versionsopgraderinger og systeminterne udviklingsopgaver Sikre indholdsmæssige support (superbrugere) Varetage opgaver i årshjul for IT-sikkerhed (dataklassifikation, risikoanalyse, beredskabsplan) Nedenstående skema illustrerer foreslået detaljeringsgrad 18

19 Projekt- og programstyring Principperne for styring og gennemførelse af AU s fælles IT-projekter hviler på erfaringerne fra Det Administrative Forandringsprojekt. I praksis er projektmodellen en reduceret udgave af Prince2-modellen, Beslutningsgrundlag baseret på business cases Projektinitieringsdokumenter som startgrundlag Organisering med projektejer, styregruppe og projektgruppe(r) Projekt- og aktivitetsplaner, der synliggør faste milepæle / deadlines Implementering gennem risiko- og afvigelsesstyring 19

20 Figur 3: Porteføljestyring af IT-opgaver 20

21 Figur 4: AU-IT projektmodel Definer overordnede mål for (harmoniserede) to-be processer Beslut Formuler overordnede krav til IT-støtte Undersøg markedet Opstil business case Drift og Vedl. Implementering Integrations projekt Anskaffelsesforretning Standard Egenudvikling Vælg AU udviklingsprojekt Projektetablering Projektledelse og risikostyring 21

22 Figur 5: Rollefordeling i typisk IT-projekt 22

23 Effektmålinger på udvalgte områder Forretningsdrevet IT betyder løbende dialog om ydelsernes kvalitet og effektivitet Ydelseskataloger, der beskriver de services og ydelser, der leveres Service Level Agreements, der beskriver den kvalitet, ydelserne leveres i. Organisationen er uerfaren med effektmålinger. To indikatorer anvendes i starten Brugertilfredshedsmålinger. Fx af tilfredsheden med AU-IT s brugersupport Service Level rapportering (oppetid m.v.). Månedlige eller kvartalsvise statistikker, der fortæller om oppetid og fejlretningstider for de store IT-systemer 23

24 Leverancesøjlen Enterprise architecture IT-services People Sourcing 24

25 Mål-arkitektur: SOA SOA = Service Orienteret Arkitektur En heterogen samling af løst koblede systemer Standardsystemer når der findes egnede på markedet Egenudviklede til specifikke strategiske AU-behov Både centrale fællessystemer og specifikke systemer på hovedområderne Systemer kobles via en integrationsplatform Giver overblik over integrationer (i dag er der fx 84 punkt til punkt integrationer med Delfi som den ene part). Støtter driftsovervågning Integrationsplatformen skal gennem anvendelse af en fælles koncern datamodel bygge bro mellem de forskellige systemers begreber Mål-arkitekturen realiseres trinvist og forretningsdrevet 25

26 Mål for Infrastruktur Når vi ønsker (og er forpligtet til): Basal IT-drift som vand ud af hanen Maksimal automatisering og effektivisering af grundlæggende IT-drift Overholde kravene indenfor IT-sikkerhedsområdet At kunne stille efterspurgte services til rådighed for forskning og undervisning At imødekomme forventning af en grøn profil, herunder energibesparelser Kræver det en infrastruktur, der er Skalerbar og fleksibel Har høj oppetid og kan serviceres hurtigt Anvender standardiserede grænseflader og protokoller Kan håndtere stærkt stigende datamængder I stand til at adskille produktionsmiljøer og eksperimentelle / forskningsbaserede miljøer på samme fysiske infrastruktur 26

27 Mål for Infrastruktur (fortsat).. og som anskaffes og implementeres efter en række principper: Anvendelse af markedsledende og velafprøvede teknologier til produktionsmiljøer Udbredt anvendelse af virtualiseringsteknologier indenfor serverdrift Modulært baseret hardware til bl.a. netværk, storage og backup Valg af et mindre antal strategiske hardwareleverandører men mere end én Beskyttelse af allerede afholdte investeringer 27

28 IT driftsydelser Administrativ IT er mere end Navision, Delfi og PØS og netværk. Snitflade mellem administrativ og faglig IT lægges på det smalleste sted Fælles IT I spil Faglig IT Infrastruktur - Netværk & telefoni - Identitetsstyring - Integrationsplatform - Licensaftaler Økonomibærende syst. - Navision, HR, Stads m.fl. Fælles CMS Kontorløsning (HUM, ADM) - Standard PC m. Office - Mail og kalendersystem - Fil & print Fælles fysiske datacentre Kontorløsning øvrige H.O Fælles admin. applikationer - Intranet - ESDH - Learning Management AU standard PC Fælles backup & arkivering Indkøb Forskningsnær IT IT I laboratorier Projekter med IT-indhold Faglig IT for HUM 28

29 Fra flere decentrale løsninger til fælles løsning Der vil findes både valgfrie og obligatoriske systemer. Valgfrie løsninger fx drift i fysiske datacentre AU s fælles IT-afdeling opbygger skalerbare løsninger, der kan varetage fælles driftsopgaver Hovedområderne kan, hvor det er økonomisk eller kompetencemæssigt fordelagtigt vælge at flytte ind. Obligatoriske systemer, fx administrative hovedsystemer. Projektforløb omkring fx nyt HR-system eller STADS-studieadministrativt system sikre, at alle væsentlige og blivende krav fra forretningen er implementeret i løsningen Implementering sker typisk gradvist, fx med ét hovedområde ad gangen. I migreringsfasen opretholdes sikker drift af de eksisterende systemer. 29

30 IT supportydelser Single Point of Contact som pejlemærke for teknisk hjælp Fælles telefonnummer, fælles sagsstyringssystem Spredt geografi, fysisk nærhed er væsentlig Fælles ledelse og retningslinier Systemejer har ansvar for indholdsmæssig / faglig support. 30

31 Organisering og kompetencer Gradvis etablering af koncernfælles IT-afdeling, efterhånden som systemharmonisering skrider fremad Ansvar for løsning af driftsopgaver placeres entydigt, udførelse kan distribueres internt og/eller eksternt Robust organisationsmodel med geografisk tolerance Medarbejdere i fælles IT-organisation på flere lokationer. Kompetenceniveau Support: Højt serviceniveau, allround faglighed Drift: Højt fagligt niveau, spidskomptence tilkøbes efter behov. Udvikling: Højt fagligt niveau, spidskompetencer tilkøbes efter behov Projektledelse / konsulenter: Højt fagligt niveau, Spidsbelastningskapacitet tilkøbes Skift i IT-organisationens kultur Fra forskningsinspireret, eksperimentel driftskultur med quickfixes til kultur præget af standardiserede processer og planlagte. gennemtestede ændringer, Fra firefighters til piloter 31

32 Sourcing af IT-drift Præference for egen drift af systemer med bred brugerkreds og hvor kendskabet til forskningskulturen har betydning. Behov for datacenterkonsolidering som værksted for egen drift drevet af sikkerhedshensyn, økonomi og grøn it AU-IT har kontraktmæssigt ansvar for drift af fælles administrative systemer Interne kompetencecentre kan varetage drift af dele af platformen for hele AU, fx CMS hos Naurvidenskab eller ESDH hos Jordbrugsvidenskab Partiel outsourcing / midlertidig outsourcing Systemer uden kompliceret integration kan med fordel driftes eksternt Systemer, hvor AU ikke har tilstrækkelig kompetence kan driftes eksternt i interimperiode- 32

33 Principbeslutninger i Universitetsledelsen IT området er forretningsstyret. Ikke brugerdrevet eller teknologidrevet Standardsystemer foretrækkes, processerne de understøttes tænkes end-to-end, uanset organisatoriske enheder Styringsmodel med IT-forum, der prioriterer større tværgående projekter Systemlandskabet skal forenkles. Harmoniseres og standardiseres Respekt for, at ting tager tid. 33