Waar gaan we voor: webshopmodel ROC6

Onderstaand het definitieve plan van eisen dat gaat gelden voor de bestelomgeving-showcase van ROC6 voor saMBO-ict. Al eerder is een voorlopig plan van eisen besproken in mijn blog.

Cursief bij enkele eisen wat op- en aanmerkingen.
De showcase wordt door Deltion College en Threeships in twee fases gerealiseerd:
A. In januari 2011 een showcase met koppelingen met een beperkt aantal uitgevers.
B. In maart eindoplevering met een werkende backoffice (betalingen en distributie) en koppelingen met meerdere uitgevers.

Daarnaast loopt op het Horizon College een soortgelijk traject, maar wordt bekeken in hoeverre een bestaande dienstverlener (LWG) de webshop op onderstaande manier kan voeren. Voor de duidelijkheid: de webshop is geen landelijke bestelomgeving, naar eigendom van de school. Elke school kan haar eigen bestelomgeving (laten) creëren!
  1. De gebruiker benadert de webshop vanuit de schoolomgeving. De school bepaalt met welke ID de student de keten in gaat.
    Studenten moet al een account hebben in de webshop. Mogelijkheid om single sign-on (sso) te koppelen met schoolomgeving is in de webshop aanwezig. 
  2. De ID van de student moet uniek zijn binnen de school en daarbuiten.
    Voldoet de huidige standaard van Kennisnet binnen Entree mbt de unieke ID?
  3. Via de webshop kan per organisatie-eenheid een leermiddelenlijst (LML) aangemaakt worden. Student kan desgewenst uit meerdere leermiddelenlijsten kiezen. Er wordt in eerste instantie niet op groepniveau gekoppeld, maar een niveau hoger. Teams of een aan te wijzen dienst kunnen zelf de leermiddelenlijst aanmaken in de webshop en hebben zelf autorisatie op publicatie van de leermiddelenlijst in de webshop. 
  4. De webshop is gekoppeld aan de catalogi van uitgevend Nederland met alle isbn/EAN-nummers. Samenstellers van de LML kunnen gekozen materiaal per LML materiaal aanvinken. Hiervoor ligt er al een basis. Er is echter nog steeds geen standaard gedefinieerd. Zit wel in ECK2 project.
    Niet opgenomen in het PvE, maar wel wenselijk op langere termijn: koppeling van leveranciers van gratis materiaal (WikiWijs bv). Teams kunnen dan een soort macro-arrangement opzetten voor een opleiding welke uitgewerkt wordt in deelarrangementen in bv de ELO.
  5. Prijzen van leermiddelen kunnen door een aan te wijzen beheerder zelf ingevoerd worden. Deze prijs kan afwijken van de adviesprijs, bijvoorbeeld na onderhandeling met een leverancier.
    Te bepalen beheerder kan afwijkende prijs invoeren, doorwerkend in alle daarnaar verwijzende LML-en 
  6. Gratis leermiddelen uit bv Wikiwijs moeten opgenomen kunnen worden in de lijst.
    Niet opgenomen in het PvE, maar wel wenselijk op langere termijn: koppeling van aanbod van leveranciers van gratis materiaal (bv WikiWijs). Teams kunnen dan een soort macro-arrangement opzetten voor een opleiding welke uitgewerkt wordt in deelarrangementen in bv de ELO.
  7. Naast de artikelen moeten er ook tekstvelden kunnen worden opgenomen. Hierin kan uitleg gegeven worden of bv gevraagd worden zelf voor een map en potloden te zorgen.
  8. Een school moet zelf een object kunnen toevoegen, ook al is de webshop in beheer bij een externe partij (VDE, LSW oid). Denk aan kosten voor een schoolreis of excursie.  
  9. Het systeem moet betaalbewijzen kunnen opleveren: studenten kunnen deze (al dan niet digitaal) laten zien als toegangsbewijs voor te bepalen diensten (als bv voor de genoemde excursie.
  10. Een school moet willekeurig welke leermiddelendistributeur en financiële dienstverlener kunnen contracteren voor afhandeling van de backoffice. Het bestelhuis, het distributeurschap en de financiële afhandeling moeten dus ontkoppeld kunnen worden. De keuze voor partners wordt door de school gedaan. 
  11. Betaling van de bestelde middelen moet op diverse manieren kunnen gebeuren. Ideal, creditcard of welke andere digitale manieren dan ook, maar ook via een betalingsregeling (acceptgiro of eventueel betaling in termijnen).
  12. Het te betalen opgetelde eindbedrag moet geoormerkt naar kostenplaats op één rekening komen, waarna vanaf hier de leveranciers betaald worden.
    Deze rekening kan door een nader te bepalen partij beheerd worden. Speler moet door leverancier vertrouwd worden! Denk bv aan stichting derdengeld. 
  13. Na betaling of acceptatie van de regeling zet de WS de toegang tot digitale leermiddelen in de ELO vrij.
    Vanaf dat moment moet de student (of medewerker) via de ELO direct (dus drempelloos) bij de leermiddelen kunnen. De route wordt aangegeven, het vrijgeven doet uiteraard de uitgever.
  14. Na betaling geeft de WS de IDgegevens van de student door aan de betrokken uitgevers hun licentiekantoren.
    Op dit moment maatwerk per uitgever, daardoor een drempel voor snelle invoering. Cruciaal: standaardkoppeling van de bestelomgeving met de licentiekantoren van de uitgevers
  15. Naast betaling door de student moet ook de mogelijkheid worden geboden dat werkgever en ouders kunnen betalen. Bij die betaling moet niet de identiteit van de betaler in de keten terecht komen, maar die van de student.
    Dit is essentieel voor een goed werkende keten. Hierop loopt het nu vaak fout. Oplossing wordt gezocht in vouchersysteem. Als werkgevers bestellen en betalen voor student krijgt de student een code, voert die in webshop in en zijn schoolID is gekoppeld aan de betreffende bestelling.
  16. In de WS moet er een printknop komen om de LML uit te printen. 
  17. De WS moet Single Sign-On (drempelloos) toegankelijk zijn vanuit de gebruikelijke schoolomgevingen.
  18. Op de leermiddelenlijst moeten de volgende materialen opgenomen kunnen worden:
    Folio
    Digitale leermiddelen
    Extra zaken als koksmutsen e.d.
    Excursies e.d. 
  19. Webshopprocessen volgen de interne processen van de school.

Reacties

  1. Naast betaling door de student moet ook de mogelijkheid worden geboden dat werkgever en ouders kunnen betalen. Bij die betaling moet niet de identiteit van de betaler in de keten terecht komen, maar die van de student.
    Dit is essentieel voor een goed werkende keten. Hierop loopt het nu vaak fout. Oplossing wordt gezocht in vouchersysteem. Als werkgevers bestellen en betalen voor student krijgt de student een code, voert die in webshop in en zijn schoolID is gekoppeld aan de betreffende bestelling.

    Ik zou accounts gaan mergen (dit zou kunnen op basis van id's) en zoveel mogelijk proberen vouchers te voorkomen.

    BeantwoordenVerwijderen
  2. Kun je dan de werkgeversaccount mergen met telkens andere id's?

    BeantwoordenVerwijderen
  3. Waarom moet worden gespecificeerd wie er moet kunnen betalen? Als ik iets op het internet koop en betaal via bijv. iDeal, dan kan mijn oma de iDeal betaling doen terwijl de spullen bij mij worden afgeleverd.Het gaat erom dat wanneer de uitgever zijn geld heeft, er een logica is dat een student vervolgens gebruik kan maken van het aangeschafte goed.

    BeantwoordenVerwijderen
  4. Overigens, de uitgever dient de voucher aan de juiste student te leveren en that's it toch. Want die voucher zou weer kunnen worden ingeleverd door een ander..
    Als ik een pre-paid tegoed koop kan ik dat aan iemand anders geven die het gebruikt.

    BeantwoordenVerwijderen
  5. Martin,

    1. We wilden juist van de vouchers af. Voor elk product een code van 15 cijfers invullen gaat niet lukken. Vouchers kwijt, fouten, etc.
    2. voor digitale middelen moet bekend zijn wie de student is, juist gezien de steeds hechtere koppelingen tussen content en leeromgeving van de school. Resultaten behaald op de site van de uitgever zullen ook in de schoolsystemen zichtbaar moeten zijn. Maw: de syetemen moeten van dezelfde IDgegevens uitgaan, anbders valt er niets te koppelen. Met onze voorstellen zal dat geen probleem meer opleveren.

    BeantwoordenVerwijderen

Een reactie posten

Bedankt voor jou bijdrage aan dit blog.

JaapJan Vroom