Bra1 STUDENTMOBILITEIT informatieanalyse Andre Brands – december 2014

2 Project studentmobiliteit Inhoud  Scope (wat)  Stakeholders (wie)  Dienstverlening (waarom)  Implementatie (hoe)

3 Scope (1) Wat moeten we meenemen?  Inkomende buitenlandse studenten (Master en Bachelor)  Exchange studenten (inkomend en uitgaand)  Stage- en afstudeeropdrachten (binnen- en buitenland)  Aspirant studenten (van informatie tot aanmelding)  PhD studenten

4 Scope (2) Wat moeten we niet meenemen?  Aanmelding nederlandse studenten  Alumni  Medewerkers

5 Stakeholders Wie heeft belangen?  Studenten  CES: IO, AO, BOZ  Fainco’s  Stage en mobiliteitscoördinatoren  Management (CES, Faculteiten, S&B, College)

6 Dienstverlening Waarom?  Dienstverlening aan student  Visa, Beurs, Huisvesting, Begeleiding, Informatie, Reisverzekering, …  Management  Rapportages: statistieken, trends, calamiteitenoverzicht, …  Contractenbeheer  Student, sponsor, partner; project- en financiële administratie  Informatieverstrekking derden  Overheid (Den Haag, Brussel), VSNU, 3TU, Nuffic, voorlichting

7 Implementatie Hoe gaan we het doen?  Analyse huidige situatie (interviews)  Knelpunten in kaart brengen  Oorzaak vinden  Voorstellen oplossing / verbetering (3 modellen)  Analyseren modellen  Advies.

8 Top 3 van problemen 1.Ondersteuning van processen op de werkvloer is zeer inefficiënt Problemen studentmobiliteit nu

9 Top 3 van problemen 1.Ondersteuning van processen op de werkvloer is zeer inefficiënt 2.Management informatie is onvoldoende beschikbaar Problemen studentmobiliteit nu

10 Top 3 van problemen 1.Ondersteuning van processen op de werkvloer is zeer inefficiënt 2.Management informatie is onvoldoende beschikbaar 3.Het proces van aanmelding voor een internationale student duurt te lang Problemen studentmobiliteit nu

11 Kijk naar de huidige architectuur! Architecture: Overall design of a system System: A set of interacting or interdependent components forming an integrated whole Oorzaak?

12 Grafische weergave van relatie tussen processen en applicaties (Zie volgende slide …). Current architecture

13

14 Ondersteuning van processen op de werkvloer is zeer inefficiënt Dit is een onmiddellijk gevolg van het grote aantal applicaties. Medewerkers die zowel in- als uitgaande mobiliteit coördineren moeten mogelijk met 8 (acht!) verschillende systemen werken om alle benodigde gegevens te kunnen registeren of op te vragen.. Probleem nr 1.

15 Management informatie is onvoldoende beschikbaar Ook dit is een gevolg van het grote aantal applicaties. Omdat elke applicatie voor de opslag van gegevens zijn eigen database gebruikt is het nagenoeg onmogelijk een integrale rapportage te maken waarbij gegevens uit alle systemen benodigd zijn.. Probleem nr 2.

16 Het proces van aanmelding voor een internationale student duurt te lang Omdat bij de beoordeling (admission) ook weer diverse systemen geraadpleegd moeten worden (informatie over individuele student, maar ook informatie over land/universiteit van herkomst) is het een tijdrovend proces.. Probleem nr 3.

17 Een nieuwe architectuur! Mogelijke oplossingen (modellen) 1.Eén nieuwe centrale applicatie 2.Integratie bestaande applicaties rond een centrale bedrijvendatabase 3.Osiris als centraal informatiesysteem. Oplossing?

18 Target architecture 1: Eén centrale nieuwe applicatie

19 Target architecture 2: centrale bedrijven database

20 Target architecture 2: gebruik bestaande systemen

21 Target architecture 3: Osiris als centraal SIS

22  Resultaat (Lost dit de problemen op)?  Haalbaar (kosten, doorlooptijd, implementatie, opleiding)?  Voordelen?  Nadelen? Beoordelingscriteria

23  Het aantal applicaties moet verminderen  Het aantal interfaces moet verminderen  Bij voorkeur één logische applicatie voor de gebruikers  Gebruiksvriendelijk Aandachtspunten (1)

24 Contractbeheer moet verbeterd worden  Centrale opslag en inzage van alle contracten  Informatie op elk moment hoeveel en welke plaatsen voor studenten nog beschikbaar zijn. Aandachtspunten (2)

25 Inrichten van een kennisdatabase van instellingen. De ervaringen uit het verleden van studenten afkomstig van een bepaalde instelling kunnen de beslissing over toelating van nieuwe studenten van dezelfde instelling aanzienlijk versnellen. Aandachtspunten (3)

26 Model 1 (aanschaf pakket) heeft de voorkeur Voorwaarden:  Het pakket moet minstens bij één andere instelling succesvol draaien, bij voorkeur in Nederland.  Het interface met Osiris moet zonder extra maatwerk mogelijk zijn.  Invoering op de UT (van aanbesteding tot en met implementatie) moet binnen een redelijke tijd (zeg 1 jaar) mogelijk zijn. Resultaat analyse (1)

27 Model 3 (Osiris centraal) moeten we eigenlijk niet willen.  We worden te afhankelijk van één leverancier (CACI)  Extra functionaliteit Osiris veelal onbekend (wel onderzoeken!) Resultaat analyse (2)

28 Model 2 (centrale bedrijvendatabase + hergebruik) scoort toch goed  Resultaatgericht  Haalbaar (gefaseerde invoering mogelijk)  Realisatie van de “kennisdatabase” hier goed mogelijk Resultaat analyse (3)

29 Vervolgactiviteiten in deelprojecten: 1.Requirements o services, processen (wat i.p.v. hoe) 2.Onderzoek commercieel pakket 3.Beschikbare functionaliteit Osiris 4.Systeemintegratie o Data integratie (centraal informatiemodel) o Userinterface (Eén centrale user view op alle componenten) Hoe nu verder?

30 Zie verslag voor de resultaten Grootste dreiging:  Groot aantal gerelateerde projecten rond mobiliteit  Centrale regie hiervan ontbreekt SWOT analyse