Leverandørmøde 31/3-2016

Transkript

1 Leverandørmøde 31/ Aino Olsen og Mai-Britt Brun Schor Indsæt note og kildehenvisning via Header and Footer Side 1

2 Dagsorden 1. Morgenmad fra 9:15 2. Velkomst: 10:00-10:10 3. Principper for markedsgørelsen, v. Aino Olsen: 10: Status på projektet, planer v. Mai-Britt Brun Schor: :50 5. Indlæg fra Danske Gymnasier v. Dorte Fristrup: 10:50 11:00 6. Kaffepause 11:00-11:15 7. Arkitektur-overvejelser, sammenhæng til BPI, v. Mai-Britt Brun Schor: 11:15-11:25 8. Oplæg fra DE v. Anne Hyrup Madsen og Poul-Erik Andersen: 11:25-12:10 9. Generel drøftelse og spørgsmål fra salen: 12: Side 2

3 Principper for markedsgørelsen Det bærende princip i markedsgørelsen er følgende: At uddannelsesinstitutionerne sikrer it-understøttelsen af de lokale studieadministrative arbejdsprocesser, hvor der ikke er behov for fælles, nationale løsninger. At uddannelsesinstitutionernes adgang til at købe studieadministrative løsninger på markedsvilkår reguleres ved bekendtgørelse og instruks, hvorved der fastsættes standarder Side 3

4 Principper for markedsgørelsen Leverandører: Overholde kravene vedr. de i bekendtgørelsen beskrevne grænseflader og udvekslingsstandarder Varetage sikker opbevaring af data Sikre en sikker adgang til og omgang med data Overholde den til enhver tid gældende persondatalovgivning Tilrette systemet til gældende lovgivning Indgå databehandleraftaler med kunderne Side 4

5 Principper for markedsgørelsen Uddannelsesinstitutioner: Indkøbe godkendte systemer, jf. ministeriets godkendelsesprocedure Indgå en kommerciel kontrakt med leverandøren, som bl.a. sikrer ejerskabet til data og dermed muligheden for at skifte leverandør på et senere tidspunkt Indgå databehandleraftaler med leverandørerne Side 5

6 Principper for markedsgørelsen Ministeriet: Udelukkende stille krav til institutionernes kommende IT-systemer og leverandører via offentlige tilgængelige myndighedskrav, der publiceres på stil.dk Ligebehandle leverandører, så alle får samme vejledning og indsigt i området Udvikle ensartede grænseflader mod MBULs nationale systemer, som stiller alle leverandører lige og ikke favoriserer fx et særligt teknologivalg Side 6

7 Systemrevision Ændres sjældent og kun med formel høringsproces Bekendtgørelse Bilag (kontrolmål) Vejledning Grænsefladebeskrivelse Grænsefladebeskrivelse Grænsefladebeskrivelse Ændres ihht årshjul, fx hvert kvartal. Uformel høringsproces Side 7

8 Eksempler Formelle krav (ex fra DVH/statistik) Uformelle ønsker Kompatabilitet med øvrige gængse produkter/løsninger Modulopbygning Ensartede processer understøttes ensartet Side 8

9 Plan og status Side 9

10 Plan Første skole på nyt system Sidste skole på nyt system Udarbejdelse af bekendtgørelse Høring Frit valg af studiesystemer Beskriv af grænseflade Dialog med leverandører Etabl. af punkt-punkt integrationer Sluk Easy Systemrevision af nye systemer Pilotforsøg, rådgivning af skoler... Ensartning af grænseflade Analyse+ kravspec Integrationsplatform Indfasning randsystemer Januar 2016 Marts 2016 August 2016 August Side 10

11 Plan for centrale systemer Side 11

12 Integrationsplatform Formål: Gøre det nemmere for nye og kommende leverandører at tilgå MBULs krævede grænseflader Understøtte at MBUL ensarter nationale tjenester og hermed effektiviserer arbejdsgange internt i MBUL og på uddannelsesinstitutioner Understøtte ensartethed på tværs af grundskole, ungdomsuddannelse og voksen/efteruddannelse. Status: Indkøb af basis software er igang. Indfasning af grænseflader er under planlægning Side 12

13 DANSKE GYMNASIER Dorte Fristrup, rektor Århus Statsgymnasium Informationsmøde for leverandører, 31/3-2016

14 DANSKE GYMNASIER ØNSKER et frit marked for studieadministrative systemer med sund konkurrence og valgfrihed for den enkelte institution et bredt udbud af administrative systemer, som understøtter et bredt spektrum af måder at organisere undervisningen på åbne grænseflader med mulighed for integration mellem forskellige systemer og delsystemer at udbydere underlægges klare og rimelige krav f.eks. i forhold til integration ved dataindberetning og omkring datasikkerhed klare juridisk bindende aftaler mellem dataejer og databehandler sikkerhed for korrekt håndtering af persondata løbende udvikling af administrative systemer med ny relevant funktionalitet og tilpasning til understøttelse af aktuelle behov S. 14

15 DANSKE GYMNASIER STØTTER MARKEDSGØRELSEN FORDI Vi støtter en yderligere åbning af markedet for studieadministrative systemer på ungdomsuddannelsesområdet Det er vores forventning, at processen omkring markedsgørelsen på sigt munder ud i: øget valgfrihed i forhold til leverandør tydeligere krav og ansvarsplacering konstant fokus på udviklingsmuligheder ift. digitalisering S. 15

16 ZOOM TIL SKOLEPERSPEKTIVET - 1 Brugere: Elev, lærere, administration og ledelse Formål: Understøtte elevernes læring Understøtte planlægning, gennemførsel og evaluering af undervisningen for lærere, administration og ledelse Understøtte samarbejde og kommunikation Understøtte datainformeret pædagogisk praksis og ledelse Sikre sikker levering af data til eksterne myndigheder (MBUL) S. 16

17 ZOOM TIL SKOLEPERSPEKTIVET - 2 Vi har derfor brug for blandt andet: sikker og brugervenlig administration af den enkelte elevs data fra start af forløbet og til slut - oprettelse, karaktergivning, aflevering af og feedback på skriftlige opgaver, eksamenshåndtering, bevishåndtering osv. dagligdags information om skoledagen og fagenes indhold; skema, lektier, uploadede dokumenter mv. udbygget evalueringsmulighed og -synliggørelse og sagshåndtering omkring den enkelte elev mulighed for dialog omkring undervisningen mellem lærer og elever (fx gennem konferencer, beskeder) mulighed for tidsregistrering (lærere) videndelingsmulighed

18 ZOOM TIL SKOLEPERSPEKTIVET - 3 moderne og fleksibel håndtering (og visningsmulighed) af dokumentationskrav; offentlighedslov, ministerielle krav mv.; studieplaner, undervisningsbeskrivelser, studierapport, forløbsoversigter mv. integrationsmulighed af skema med ekstern, personlig brugerkalender (fx Google, Outlook) løbende i realtid levering af data til eksterne moduler løbende i realtid ubegrænset adgang til egne data, herunder til fleksible, selvdefinerede udtræk af sammenhænge, statistikker, rapporter mv 24/7/365 og helpdesk

19 Kaffepause Side 19

20 Arkitektur mv Side 20

21 Lokale vs centrale processer Side 21

22 Arbejdsdeling Marked STIL Side 22

23 Modulopbygning af løsninger Grundskole Gymnasial uddannelse Voksen/efteruddannelse Erhvervsuddannelse Videregående uddannelse Læring Læring Læring Læring Læring Grundlæggende administration Grundlæggende administration Grundlæggende administration Grundlæggende administration Grundlæggende administration Selveje Selveje Selveje Selveje Praktik AMU Side 23

24 Systemlandskab To-Be Side 24

25 Spørgsmål Side 25

26 Præsentation af behovskortlægning Poul Erik Andersen Anne Hyrup Madsen

27 Baggrund Udgangspunkt: En udviklingsopgave må baseres på en beskrivelse af behovene for et moderne studiesystem. Men: Der fandtes ingen samlet beskrivelse af et studiesystem, som skolerne har behov for. Derfor besluttet: Udarbejde en samlet behovsopgørelse til et moderne studiesystem som understøtter effektive og digitale arbejdsgange.

28 Arbejdsgruppen Arbejdsgruppens sammensætning: 1) Medlemmer af skolernes øverste ledelser med ansvar for økonomi og administration 2) Blev bistået af nøglemedarbejdere med stor faglig viden Garanti for realistisk ambitionsniveau men også et klart krav om effektiv og digital understøttelse af arbejdsopgaverne Professionel bistand til beskrivelsesarbejdet for sikring af anvendeligt materiale

29 Projektet Beskrive behov til det nødvendige system for en skole: som ikke vil betinge køb af 3. parts produkter som er fuldstændigt og dækkende for en mindre skole Kortlægningen skal holdes på et højt abstraktionsniveau med respekt for de operationelle opgaver.

30 Processen Fokus på behovsafdækning det handler om hvad - ikke hvordan Kortlægning af behov for de udvalgte områder Analysefase - workshopdage Konkretiseringsfase Ny version/første version af rapport og behovsmatrix x6 Forstå-fase Materiale der skal bruges som grundlag for workshopdagene

31 Udvalgte fokusområder Områder som er blevet behandlet som en del af behovsafdækningen Studieadministration Eksamen Praktikadministration Læring Gennemførelsesvejledning støtte IT Kommunikation Økonomi og HR Bygningsdrift og service Tværgående opgaver, krav og behov Skolehjem Studieadministration Udbudsgodkendelse Tilmelding Afklar optagelse Registrer optagelse Indkaldelse af elever Opstart Udstedelse af bevis Løbende aktiviteter Fremmødekontrol Opfølgning på manglende fremmøde Løbende evaluering Tilgang- og afgang af elever Løbende ændring af elevers tilknytning til læringsaktiviteter Aktivitetsindberetning Indberetninger f.eks. Danmarks statistik Statistik muligheder f.eks. frafald med årsager Skemaplanlægning

32 Kronologisk tidslinje for studieadministration

33 Løbende aktiviteter for studieadministrationen

34 Behandling af et område Fokus på behovsafdækning det handler om hvad ikke hvordan

35 Resultat

36 Behovsafdækningen I alt 419 behov - Alle behov er beskrevet som user stories - Afdækningen er holdt på et højt abstraktionsniveau, derfor vil behovsanalysens user stories typisk være på et abstraktionsmæssigt højere niveau end man typisk ser i f.eks. i et udbudsmateriale

37 Behovsmatrix

38 Udgangspunkt for modulisering Introduktion fra projektoplægget Oplægget til dette forprojekt påbegyndte en stillingstagen til, hvad det kunne give mening at tale om som moduler. Helt konkret var forestillingen omkring modulisering beskrevet således med figur og tekst: Udviklingen af nye applikationer tager således udgangspunkt i, at der skabes en fælles platform for alle skoler, som uanset skolernes størrelse kan anvendes af alle. Det fælles centrale system udbygges med særlige moduler til de forskellige uddannelsesområder, så der kan skabes skoleløsninger der tager hensyn til de forskelligheder, der er i skolernes behov for systemunderstøttelse af deres opgaver.

39 Modulisering af behov

40 Modulær opbygning Systemarkitekturen for systemet er fastlagt ud fra en erkendelse af, at software skal eksistere og løse problemer i en kompleks og omskiftelig virkelighed. Systemet er derfor nødt til at kunne tilpasses løbende efter behov, efterhånden som virkeligheden ændrer sig og kravene til systemet ændres. Arkitekturen tillader, at systemet enten udvikles af en enkelt leverandør eller - som ditmer anbefaler - af flere leverandører. Med udgangspunkt i den anbefalede arkitektur, med en række forskellige systemer, der kommunikerer via et centralt system, er det vigtigt, at det sikres, at systemerne er afkoblet bedst muligt, således at de enkelte komponenter kan skiftes ud, uden at det kræver store ændringer til de øvrige systemer. På figuren er der vist et forslag til en arkitektur, hvor en integrationsplatform er den centrale komponent til at sikre afkobling. Bevisfremstill ing Eksamensbev is-system UVM Prøver og eksamen Time og aktivitetsplan lægningen Skolemøde Lønfordeling Tidsregistreri ng LMS Skemaplanlæ gning Registrering af fremmøde Personale Censur Virksomheds kontakt praktik Lokaleressour cer KERNE Forretningslogik Fælles datagrundlag FÆLLES SYSTEM Centralt WebAPI Konfigurationsservice Autoriseringsservice Notifikationskomponent Facility management

41 Modulisering og kategori - 1 af 3

42 Modulisering og kategori - 2 af 3

43 Modulisering og kategori - 3 af 3

44 Aktører

45 Udsnit af integrationer UVM/webservice RKV-værktøj fra STIL Tilbagemelding.dk emu.dk E-boks US2000 Mail KUU-portalen Navision stat rejseplan.dk Exchange CØSA XPRS viskablitet.dk Mobil app AUB/AER netprøver.dk Skemaplanlægning EASY-P Ungedatabasen Mobil app SLS Plagiatkontrol system Silkeborg løn optagelse.dk Excel Nemlogin UU brobygning.net Danmarks statistik efteruddannelse.dk Ny UVM-praktikportal (elevplan + EASY-P) Skolens hjemmeside

46 Udsnit af generelle krav

47 Spørgsmål til leverandører Hvad skal der til, for at der på baggrund af materialet indgås samarbejder med skoler om at udarbejde (nye) systemer til sektoren?

48 Spørgsmål fra salen

49 Afrunding og spørgsmål Side 49