Student­bestellingen beheren

Rol
Product Designer
Team
  • Product Owner
  • 2 ontwikkelaars
  • Financiële afdeling
  • 2 systeembeheerders
Omvang
84 Nederlandse mbo-scholen · circa 9.000 studentbestellingen per jaar

Het resultaat

81%minder bestellingen met een verkeerd pakket
71%minder beheertijd per bestelling
77%minder tijd voor btw-rapportages
70%minder hulpvragen over toegang

*De sterkste vergelijking komt uit de drukste periode van het schooljaar. Dan zijn er de meeste schoolbestellingen en bijbehorende hulpvragen.

Het probleem

Bestellingen kwamen op drie manieren binnen. Elke manier zorgde voor handmatig werk voor systeembeheerders.

De oorspronkelijke bestelprocessen via systeembeheer en de financiële afdeling.

Bestellingen van scholen

Scholen mailden studentenlijsten. De systeembeheerder controleerde accounts, maakte ontbrekende accounts aan, stuurde inloggegevens en zette de bestelling in een spreadsheet voor de financiële afdeling.

Bestellingen van boekhandels

Boekhandels mailden hun bestellingen. De systeembeheerder verwerkte deze en stuurde vouchers terug.

Bestellingen van studenten

Studenten bestelden via LearningBox. Met iDEAL kregen zij direct toegang. Als een werkgever betaalde, moest de betaling handmatig worden gecontroleerd voordat de toegang kon doorgaan.

Dit project begon omdat één van onze twee systeembeheerders met pensioen ging. We moesten het handmatige werk verminderen, zonder alleen de functie opnieuw in te vullen.

Als enige ontwerper werkte ik aan het onderzoek, de indeling van informatie, de gebruikersstromen, de prototypes en de uiteindelijke interface.

Onderzoek

Ik interviewde de inkoper van de boekhandel en de financiële afdeling. Ook liep ik twee weken mee met beide systeembeheerders. Ik legde 211 taken bij 64 bestellingen vast.

Een bestelling kostte een beheerder gemiddeld 14 minuten. 38% van die tijd ging naar het controleren van informatie. Bijvoorbeeld: hoort dit pakket bij deze school, of heeft deze student al een account?

Ik bekeek ook 60 hulpvragen en groepeerde de problemen die vaker voorkwamen.

De grootste problemen waren verkeerde pakketten, toegangsproblemen, dubbele accounts en verkeerde cursussen.

Geobserveerde taken en terugkerende hulpvragen.

Richting van het product

Ons eerste idee was een aparte applicatie voor administratie.

Ik koos een andere richting na gesprekken met twee schoolbeheerders van kleinere scholen. Op beide scholen gaf dezelfde persoon les, beheerde accounts en bestelde materiaal. Eén van hen had zelfs een geprinte lijst met inloggegevens voor vijf verschillende tools.

Een extra applicatie zou nog een systeem betekenen om te beheren.

Daarom stelde ik voor om LearningBox uit te breiden, met navigatie en schermen per rol. Schoolbeheerders konden dan lessen, studenten en bestellingen in hetzelfde platform beheren.

Hiervoor moest de bestaande database worden aangepast. Dit kostte twee sprints extra ten opzichte van een aparte applicatie. Na overleg met de Product Owner besloten we dat het eenvoudigere dagelijkse beheer die extra tijd waard was.

Werkprocessen ontwerpen

Systeembeheerders verwerkten bijna elke bestelling. Daardoor was er onnodig veel overleg heen en weer.

Ik verplaatste de juiste stappen naar de mensen die de nodige informatie al hadden. Systeembeheerders konden zich zo richten op uitzonderingen.

Scholen zelf laten bestellen

Een school kan nu in ongeveer 4 minuten een bestelling voor een klas afronden. In drukke periodes wachtte de school eerder tot 2 dagen op verwerking door een systeembeheerder.

Boekhandels zelf vouchers laten bestellen

Bij een verkeerd gekozen pakket moest de systeembeheerder de bestelling van een boekhandel aanpassen. Ik maakte het proces minder gevoelig voor fouten. De inkoper kiest de school en het lesprogramma, waarna het systeem automatisch het juiste pakket kiest. Ongebruikte vouchers kunnen ook direct worden teruggegeven.

Studenten 14 dagen toegang geven

Studenten van wie de werkgever betaalde, moesten eerst wachten op de betaling en een handmatige controle. Samen met de financiële afdeling voerden we een toegangsperiode van 14 dagen in, in afwachting van de betaling van de factuur.

Eén overzicht voor systeembeheerders

Systeembeheerders verwerken nog steeds facturen, retouren en herinneringen. Dat doen ze nu vanuit één overzicht, in plaats van via aparte werkprocessen.

Dankzij het ene overzicht kon ook de financiële afdeling makkelijker btw-rapportages maken. De rapportagetijd daalde van 6,5 uur naar 1,5 uur.

Testen

Ik testte de belangrijkste stappen met 3 schoolbeheerders en 1 inkoper van een boekhandel, met een klikbaar prototype.

Samen met de Product Owner, ontwikkelaars en de financiële afdeling testten we ook uitzonderingen:

  • Scholen met meerdere lespakketten en verschillende regels
  • Een combinatie van aankopen via vouchers, schoolbeheerders en studenten
  • Bestellingen voor meerdere klassen
  • Retouren en creditfacturen
  • Bestellingen betaald door werkgevers en de toegangsperiode van 14 dagen

Het doel was te controleren of het model ook werkte bij ingewikkelde schoolsituaties, en niet alleen als alles volgens plan verliep.

Terugblik

Dit project leerde me dat ingewikkelde B2B-producten niet altijd om een eenvoudigere interface vragen. Vaak is de moeilijkere vraag wie welke beslissing moet nemen, en op welk moment in het werkproces.

Ik ging ook bewuster om met uitzonderingen. Het is makkelijk om voor elke uitzondering een functie toe te voegen. In dit project wilde ik de gewone stappen eenvoudig houden en zorgen dat minder gebruikelijke situaties veilig konden worden afgehandeld.