Aan en afwezigheid: Maak je niet druk om de inschrijving!

1. Aan en afwezigheid: Maak je niet druk om de inschrijving! Ignace Camps en Roel Griffioen Shared Service Center PeopleSoft voor Alfa-college, ROC van Twente en Noorderpoort

2. Introductie SSC • Shared Service Center PeopleSoft (Campus Solutions) is een samenwerkingsverband van • Alfa-college • Noorderpoort • ROC van Twente • Onderhouden 1 gemeenschappelijke applicatie (maatwerk/rapportageset) CS op • 3 afzonderlijke databases • 2 database platforms (Oracle/SQL Server) • CS 9.0 bundle #12 (upgrading  #22) • PT 8.51.09

3. Introductie Spreker • Ignace Camps, i.camps@noorderpoort.nl • Lid geweest van CC PAG (HEUG) • Senior functioneel specialist • Binnen SSC specialist oa koppelingen • Roel Griffioen, r.griffioen@alfa-college.nl • Binnen SSC specialist BRON/AAR/Educatie/Vavo • Lid van SR PAG (HEUG) • Vertegenwoordiger DEUG in TO BRON (DUO)

4. Agenda • AAR in het BO: uitdagingen • AAR in CS: tekortkomingen en obstakels • Doel van het AAR project • Inrichtingskeuzes / Functionele aanvullingen op CS • Technische hobbels en workarounds • Lessons learned • Toekomstblik

5. AAR in het BO: uitdagingen • Waar staat roosterinformatie? • UNTIS / EduFlex / … • Hoe is er geroosterd? • Per klas, per groep/blok, cartesisch • Vast rooster / dagrooster • Komen de basisgegevens overeen tussen roosterpakket en CS • Zo nee, staan ze uberhaupt aan beide kanten? • Etc.

6. AAR in CS: tekortkomingen en obstakels in core • Top 10 van tekortkomingen in CS op gebied van AAR • Absentieinformatie kan alleen per presentielijst ingevuld worden  veel werk • Roosterpatronen zijn de enige manier om lesmomenten aan te maken  inflexibel • Pagina voor onderhoud rooster is complex en niet gebruikersvriendelijk • Enrollment (oftewel inschrijving op studieactiviteit) kan alleen via self-service of handmatig per blok/klas  veel werk • Geen koppeling tussen blok/klas en deelactiviteit • Bij aanmaak presentielijst wordt iedereen al op aanwezig gezet (keihard in Cobol) • Onduidelijk of en zo ja door wie en wanneer een presentielijst ingevuld is (verantwoording lastig) • Bij welke inschrijving hoort de AAR info? (rapp. Probleem) • Ongeroosterde activiteiten zijn slecht toe te voegen • Ontbreken functionaliteit mbt verzuim

7. Doel van het AAR project • Zo min mogelijk handen aan het systeem • 5 handmatige handelingen: • Deelnemersadministratie houdt samenstelling klas/blok bij • Roostermaker importeert roosterinfo in CS • Callcentre neemt absentiemeldingen aan en legt deze simpel en eenduidig vast • Docent vult presentielijst in, mentor kan redenen bijwerken • Verzuimcoordinator meldt deelnemers die aan de wettelijke criteria voldoen, aan verzuimloket DUO • Al het andere gebeurt volautomatisch!! • Process flow chart

8. Functionele keuzes (absentie) • Absentiemeldingen eenmalig/eenduidig invoeren, automatische verspreiding over presentielijsten  geen handjes • Absentiemeldingen van vandaag zijn real-time bij docenten in beeld • Toekomstige absentiemeldingen gaan via nachtproces • Tevens inzagecomponent absentiemeldingen per klas/campus • demo

9. Functionele keuzes (inschrijving) • Onderhoud docenten gebeurt in HR, nachtelijke interface  geen handjes in CS • Onderhoud samenstelling klas/blok op 1 plek, samenstelling studieactiviteiten moet automatisch volgen  geen handjes • Proces studiedeelblokken gemaakt op basis van aanname code studentenblok = code deelactiviteit • Proces voor automatisch aanmaken enrollment requests (= bulkinschrijving maar dan over alle blokken heen), incl drop requests! • Maakt slim gebruik van eerder gebouwde klas functionaliteit (om studentenblok te voorzien van startdatum/einddatum per deelnemer) met onderscheid klasblok/handblok/autoblok/verwijderblok - demo

10. Functionele keuzes (roostering) • Roosterinformatie staat in roosterpakket, via GRI interface (CY2) import in CS  1 klein handje in CS • Aanpassing GRI door SSC: per roostergegeven (vak/lokaal/docent/groep) 2 a 3 mogelijkheden • 1 default waarde gebruiken (niet voor groep)  geen handjes • Codes zijn identiek tussen roosterpakket en CS  geen handjes • Vertaaltabel aanleggen door roosteraar of FB, …  handjes 

11. Functionele keuzes (roostering) • Voorbeeld: docent • Default docent (alle lessen worden gegeven door N.N.), GRI interface kan dit out of the box, je raakt wel informatie kwijt • Campus-ID in CS is identiek aan code in roosterpakket, GRI interface is hiervoor geschikt gemaakt, bypass vertaaltabel, alle informatie blijft aan boord • Vertaaltabel aanleggen tussen codes gebruikt in (lokaal) roosterpakket en campus-ID in CS, dit is de standaard GRI aanpak, maar onderhoudsgevoelig (toevoegen/verwijderen docenten) • Analoog voor elementen lokaal/vak/groep

12. Functionele keuzes (presentielijsten) • Aanmaken van presentielijsten geen omkijken naar, gebeurt in de automaat ‘s nachts 7 dagen vooruit geen handjes • Invullen presentielijsten: row-level security per team (= verzameling docenten die het team zelf kan onderhouden)  handjes - demo • Docent moet eenvoudig les kunnen vinden en leerling op presentielijst kunnen toevoegen (maar niet verwijderen) • Bij gebruik van buitenring moet docent deze info kunnen zien en er handig gebruik van kunnen maken • Docent moet bewuste keuze maken aanwezig/afwezig (standaard staan beide uit) maar intelligente bulk-knop aanwezig • Of docent afwezigheidsreden mag vullen is per loopbaan configurabel, ook het keuzelijstje zelf is configurabel • Ter identificatie is een foto van elke deelnemer 1-click-away - demo

13. Functionele keuzes (BPV) • BPV aanwezigheid telt mee voor uren norm, moet dus vastgelegd worden, maar dit gebeurt meestal niet per lesuur/dag • Keuze: niet in aan- en afwezigheidstabel vanwege teveel beperkingen • Vastleggen van gerealiseerde BPV uren moet kunnen per deelnemer per contract en per (deel van) schooljaar • Rapportage 850 urennorm telt BPV-AAR en les-AAR op • Nieuwe component gebouwd - demo

14. Functionele keuzes (verzuim) • Verzuim = ongeoorloofde afwezigheid die ‘te vaak’ voorkomt, wettelijke verplichting tot melden DUO • Gebouwd: platte tabel AAR met daarin verwerkt de status van het verzuim per deelnemer (diverse categorieën) • Elke dag wordt geconstateerde verzuimsituatie per deelnemer weggeschreven in verzuimtabel; naast AAR historie ligt nu ook verzuim-historie vast in CS • Verzuimcoordinatoren krijgen elke ochtend mail welke deelnemers gemeld moeten worden aan DUO • Verzuimcoordinator kan in maatwerkcomponent het (handmatig) melden van het verzuim vastleggen • In de toekomst uiteraard XML koppeling met verzuimloket (druk op de knop in CS) • demo

15. raportages • Diverse presentieoverzichtenwaaronder 5-minuten rapportage • Bellijst • Docent compliance • Verzuimoverzichten per team/mentor/deelnemer • NEDAP rapportages • Exports naar MIS

16. Technische hobbels • Bij gebruik van default element, en door wijze van roosteren in roosterpakket kunnen tellers uit hun voegen gaan lopen. • Bijvoorbeeld: aantal bijeenkomstenpatronen <= 99 • Workarounds: • Meerdere sessies per jaar • Rooster over de kop: nieuw default vak • GRI interface ondersteunde nog geen EduFlex • Oplossing: EduFlex export aangepast richting GP_UNTIS • Mouseover op presentielijstpagina (helaas, kan nog niet in grids)  toch maar ouderwetse knop

17. Lessons learned • In korte tijd is veel gebouwd (door diverse bouwers, intern/extern). Gevolgen: • Complete module-FO loopt (mijlenver) achter • tientallen deel-FO’s (addenda) die wel up-to-date zijn • Bouwwerk van stuk A doet soms stuk B omvallen • Voornemen: voor nieuwbouw voortaan eerst FO up-to-date hebben • Koppeling tussen AAR data en inschrijving is nog niet ideaal • In roosterpakketten kan meer dan je eigenlijk wil … goede afspraken over hoe er geroosterd wordt zijn belangrijk! • In CS kan minder dan je eigenlijk wil … maatwerk bijbouwen biedt soelaas maar is nooit de enige oplossing, hier en daar is Oracle toch nodig! • Audit op AAR data is nuttig voor troubleshooting

18. toekomstblik • SR Oracle: geef ons een bypass voor de roosterpatronen-tabel (class_mtg_pat) • Nieuwe versie GRI interface die gebruik maakt van dagroostering • Lesmomenten-tabel (campus_mtg) wordt de basis en niet meer de roosterpatronen (die zijn alleen bestemd voor handig vullen) • Ongeroosterde activiteiten ondersteunen • SR Oracle: geef ons een XML koppeling met het verzuimloket • Verzuim verder uitbouwen met interne processen, deels opnemen in core? • SR Oracle: vinkje ‘aanwezig’ van boolean naar drie-keuze! • Betere koppeling aanleggen tussen les en inschrijving (via team wellicht?)

19. cliqview • demo

20. Q&A • Vragen? ?

21. Roel Griffioen Senior applicatiespecialist, SSC T 050-5958169 E r.griffioen@alfa-college.nl W www.alfa-college.nl Ignace Camps Senior functioneel specialist, SSC T 050-5958172 E i.camps@noorderpoort.nl W www.noorderpoort.nl