Voedselbank
Louwerens Jan (iisschots) 
Elmer de Looff (Elmer) 
Met dit project helpt Frack de Voedselbank Leeuwarden. De huidige applicatie (en database) om het klantenbestand en de pakketstroom te beheren bevat een aantal knelpunten die groei beperken, iets dat gegeven het huidig economisch klimaat voor problemen zorgt. Kortom, genoeg reden om ze een opfrisbeurt met technieken anno 2012 te geven.
Contents
Inleiding
Het zal niemand ontgaan zijn: de kredietcrisis. Deze is onder andere te merken in de inkomens en werkloosheid onder de al zwakkere groep in onze samenleving. Mensen beginnen het moeilijk te krijgen om hun hoofd boven water te houden en doen daarom aanspraak op voedselbanken. De hoeveelheid mensen die gebruik maken van de voedselbank is laatste maanden sterk gestegen, ook in Leeuwarden.
Dit betekent ook dat er meer vrijwilligers nodig zijn om deze (not-for-profit) organisatie draaiende te houden. Gezien de afhankelijkheid van donaties en vrijwilligerswerk is het er de afgelopen jaren bij ingeschoten op ICT gebied. De bestaande database kan slechts door een of twee mensen bewerkt worden, wat zorgt voor grote vertragingen en onnauwkeurigheid in de verwerken. Dit omdat deze vrijwilligers slechts eens per week aanwezig zijn en systemen berust op post-it notes zelden betrouwbaar werken. Bovendien creert deze afhankelijkheid op 1 persoon een groot risico: wat als deze voor langere tijd niet beschikbaar is?
CodeHunger 
CodeHunger (CodeHunger) Rol: niet-deelnemer Deskundig met: Arduino, HTML, Javascript, Mustache, Programmeren, Python, Sammy Werkt aan: Geen projecten :( en
Lijnenspel 
Jelle (Lijnenspel) Rol: niet-deelnemer Deskundig met: Arduino, Programmeren, Sammy Werkt aan: Geen projecten :( zijn langsgeweest bij de Voedselbank Leeuwarden en hebben daar een rondleiding gekregen en gesproken met de directeur. Deze ziet de bovenstaande problemen als het grootste risico voor de goede verstrekking van de voedselpakketten. Er is naar aanleiding van dit bezoek bij de Voedselbank een tegenbezoek gedaan door Hendrik Bijma. Henk is bij de Voedselbank betrokken in de procesverbetering en in onderling gesprek is duidelijk geworden dat Frack een zeer waardevolle rol kan bijdragen in het maken van een nieuwe applicatie voor beheer van klanten en de pakketstroom.
Projectgerelateerde activiteiten
| Naam | Datum en tijd | Omschrijving |
|---|---|---|
| Voedselbank kennismaking | 14 juni 2012 om 20:00 | De voedselbank zou graag kennis willen maken met Frack. Hiervoor komen ze donderdag 14 juni langs. |
| Klantendatabase werkdag 1 | 17 juni 2012 om 13:00 | Een eerste hackdag waar we een eerste schets maken van de database opzet voor het nieuwe klantenbestand voor de Voedselbank. Dit aan de hand van de functionele eisen zoals die gecommuniceerd zijn met Henk. |
| Klantendatabase werkdag 2 | 24 juni 2012 om 14:00 | Bespreken van FSO met Henk en aan de hand van de laatste specificaties het databasemodel updaten. Tevens zal er een start gemaakt worden aan de front-end |
| Klantendatabase werkdag 4 | 8 juli 2012 om 14:00 | Tijdens deze vierde projectdag zullen we de voortgang op het project bespreken met Klaas en Henk, de ontwikkelde voorbeeldschermen doorspreken, en een goede planning opzetten voor het verloop van de rest van het project. |
| Klantendatabase werkdag 5 | 15 juli 2012 om 14:00 | Jacko en Coen gaan werken aan de realisatie van de front-end mockups en Elmer gaat verder werken aan de import van de bestaande database. |
| Klantendatabase werkdag 6 | 22 juli 2012 om 12:00 | Henk zal weer aanwezig zijn om samen met Frack de tot zover bestaande applicatie te bekijken en bespreken. Belangrijk is dat de interactie staat, de database-koppeling bestaat dan nog niet. Database import zal ook grotendeels bestaan. Rapportages zoals aangegeven door Klaas zullen ook gerealiseerd worden. |
| Klantendatabase werkdag 7 | 5 augustus 2012 om 12:00 | Doorspreken van de applicatie zoals die tot dan gerealiseerd is. De verwachting is dat de mocks geheel zijn uitgewerkt, en een goed deel van de applicatie staat. Ten aanzien van de import is de verwachting dat deze geheel gerealiseerd is. |
| Klantendatabase werkdag 8 | 26 augustus 2012 om 13:00 | Bijeenkomst om de gerealiseerde front-end te evalueren. |
| Klantendatabase werkdag 9 | 16 september 2012 om 13:00 | Meeting met de Voedselbank Leeuwarden om de voortgang in de front-end te laten zien. Beschreven hieronder zijn de onderdelen die we willen demonstreren. |
| Klantendatabase werkdag 10 | 7 oktober 2012 om 13:00 | Deze dag wordt de volledige workflow voor het uitgeven van pakketten geteste met de mensen van de Voedselbank. Dit in voorbereiding op een on-site test medio oktober. Hiervoor zal de JSON API grotendeels gereed zijn en ook de front-end zich in een vergevorderd stadium bevinden. |
| Klantendatabase werkdag 11 | 14 oktober 2012 om 13:00 | Vervangende meeting voor de geannuleerde werkdag van vorige week. Henk en Klaas uitleg en demonstratie gegeven van het pakketuitdeelproces gegeven en aan de hand hiervan een aantal nieuwe actiepunten opgesteld voor de volgende werkdag. |
| Klantendatabase werkdag 12 | 4 november 2012 om 13:00 | Volledige functionele test van het uitdelen van pakketten en het klantinformatiezicht. Verificatie van de import database en zoekfuncties. |
| Klantendatabase werkdag 13 | 25 november 2012 om 13:00 | |
| functioneletest uitgifte | 9 december 2012 om 10:00 | Pakket uitgifte bij voedselbank testen. |
| Voedselbank werkdag 14 | 16 december 2012 om 13:00 | Debriefing implementatie |
Actiepunten uit werkdagen
| Bron | Actiepunt | Eigenaar |
|---|---|---|
| functioneletest uitgifte | Pakketten verlplaatsen met kalender vanuit gebruiker scherm | CodeHunger |
| functioneletest uitgifte | Meerdere dieeten mogelijk maken per pakket en ook in tabel | CodeHunger |
| functioneletest uitgifte | Knop terug naar overzicht na pakket actie | CodeHunger |
| functioneletest uitgifte | Aantal pakketen resterend API implementeren bij klant info | CodeHunger |
| functioneletest uitgifte | klanten lijst bullet status. rood: niet opgehaald‚ grijs: geen actie ondernomen‚ groen: pakket gegeven | CodeHunger |
| functioneletest uitgifte | Notities aanmaken bij klant in front-end mogelijk maken | CodeHunger |
| functioneletest uitgifte | Duidelijkere kleuren toekennen aan ophaalcycle | CodeHunger |
| functioneletest uitgifte | Abbomenent data weergeven | CodeHunger |
| functioneletest uitgifte | barcode genereren in frontend uit klantcode | CodeHunger |
| functioneletest uitgifte | Kleuren voor uitgiftecycli uit API lezen | CodeHunger |
| functioneletest uitgifte | Abbomenent stoppen | CodeHunger |
| functioneletest uitgifte | Print functie pasjes voor klanten lijst | CodeHunger |
| functioneletest uitgifte | pakket informatie met kleur en stickerinformatie weergeven | CodeHunger |
| Klantendatabase werkdag 10 | Onverwerkte pakketten van dag + locatie ophalen | CodeHunger |
| Klantendatabase werkdag 10 | Klant ophalen aan de hand van klantcode | CodeHunger |
| Klantendatabase werkdag 10 | JSON API: Klanten inladen vanaf klantcode ipv alleen vanaf database-ID | Elmer |
| Klantendatabase werkdag 10 | Huidig onverwerkt pakket van klant ophalen | CodeHunger |
| Klantendatabase werkdag 10 | Database: Klantcode in base32 communiceren ipv in base64‚ om hoofdlettergevoeligheid teniet te doen | Elmer |
| Klantendatabase werkdag 10 | API pakket.status.opgehaald implementeren om pakketten te markeren als opgehaald | CodeHunger |
| Klantendatabase werkdag 10 | Database: Wanneer een pakket als verwerkt wordt aangemeld‚ zorgen dat er een nieuw pakket wordt gepland | Elmer |
| Klantendatabase werkdag 10 | Kalender ophalen -> datepicker vullen | CodeHunger |
| Klantendatabase werkdag 12 | In de kalender (per dag) het aantal op te halen pakketten vermelden | CodeHunger |
| Klantendatabase werkdag 12 | Ophalen van pakketten niet mogelijk maken op een dag waarop het pakket niet gepland staat (planning aanpassen kan dan wel) | CodeHunger |
| Klantendatabase werkdag 12 | Permissies in de database koppelen aan API methoden ipv database tabellen | Elmer |
| Klantendatabase werkdag 12 | Aantal uitgegeven pakketten tov totaal laten zien in front-end | CodeHunger |
| Klantendatabase werkdag 12 | Bij aantal resterende pakketten < 3 dit duidelijk weergeven | CodeHunger |
| Klantendatabase werkdag 12 | In de kalender de maandselectie realiseren | CodeHunger |
| Klantendatabase werkdag 12 | JSON-API: Aantal uitgegeven pakketten op een dag ook tonen tbv voortgangsindicatie | Elmer |
| Klantendatabase werkdag 12 | Feedback over aantal resterende pakketten wanneer een pakket wordt uitgedeeld | CodeHunger |
| Klantendatabase werkdag 12 | Locatieselectie voor de kalender werkend maken | CodeHunger |
Wensen en voorwaarden ten aanzien van de applicatie
Locaties en momenten van pakketuitgifte
Pakketuitgifte geschiedt op een tweewekelijkse cyclus. Voor de te ontwikkelen applicatie wordt de eerste week gezien als de week die begon met 1 januari 2001. Een maandag die een even aantal weken na deze datum valt, is dus het begin van een eerste week; een maandag die een oneven aantal weken na deze datum valt, is het begin van een tweede week.
Ter voorbeeld, maandag 16 juli valt 602 weken na de peildatum. Deze maandag is het begin van een eerste week.
- Leeuwarden
- Dinsdag eerste week (rood)
- Vrijdag eerste week (blauw)
- Dinsdag tweede week (geel)
- Vrijdag tweede week (groen)
- Boarnsterhim
- Dinsdag tweede week
- Stiens
- Donderdag eerste week – Ferwerderadeel (blauw)
- Donderdag tweede week – Leeuwarderadeel (groen)
Soorten pakketten
De Voedselbank heeft pakketten voor de volgende diëten:
- Normaal
- Diabetisch
- Halal
- Vegetarisch
Tevens zijn de pakketten geschikt voor de volgende hoeveelheden (volwassen) eters:
- Pakket A: 1-persoons
- Pakket B: 2 t/m 4 personen
- Pakket C: 5 t/m 7 personen
- Pakket D: 8 of meer personen
Brieven
Op een aantal momenten in het systeem moeten er brieven verstuurd worden naar klanten. Frack zal hiervoor een simpel systeem aanleveren waar brieven geplaatst, opgehaald en bijgewerkt kunnen worden. Dit wordt geen uitgebreid documentbeheersysteem, maar een rechttoe-rechtaan documentopslag. De brieven zullen dan ook door de gebruikers zelf moeten worden aangepast op de specifieke klant waar ze naar verstuurd moeten worden.
Voor de volgende situaties zijn er brieven (en vanuit deze stappen in het proces zal er een link naar het brievenoverzicht moeten komen):
- Afspraak voor intake
- Resultaat intake: akkoord
- Resultaat intake: afgewezen
- Eerste pakket niet opgehaald
- Tweede pakket niet opgehaald (en stopzetting van abonnement)
- Bericht over afloop van het abonnement (1 maand bericht)
Variabele (globale) ophaaldata
- Beheerders moeten kunnen aangeven dat bepaalde ophaaldata (in het gehele systeem) vervangen moeten worden door andere
- Zo zullen dinsdag 1 jan 2013 geen pakketten uitgedeeld worden, dit zal een dag later gebeuren. Een tabel met datum -> datum vervangingen is voldoende
- Bij aanmaken van zo'n datum moeten bestaande geplande ophaalmomenten verschoven worden
- Bij verwijderen moeten ze teruggezet worden, dit om de integriteit te beschermen
- Ophalen dat gepland staat op dinsdag moet kunnen doorgeschoven naar vrijdag ERNA
- Ophalen dat gepland staat op vrijdag kan worden verschoven naar de dinsdag ERVOOR
Plannen volgende pakket
Het plannen van het volgende afhaalmoment zal op de volgende momenten gebeuren:
- Bij acceptatie wordt het eerste pakket ingepland op de eerste ophaaldag op of na de ingangsdatum van het abonnement)
- Bij ophalen van pakket wordt het volgende pakket ingepland (+2 weken, bij ophalen op de 'verkeerde' dag (bv vrijdag) wordt de volgende ophaaldatum op de 'juiste' dag (bv dinsdag) gepland). De klant kan hier automatisch een mail krijgen met bevestiging van volgende ophaalmoment, is dat gewenst?
- Bij niet ophalen wordt het volgende pakket gepland bij versturen van de brief/email. Hierbij wordt automatisch bijgehouden dat het pakket niet is opgehaald, en dat hier communicatie over verstuurd is.
- Bij aangeven van versturen tweede "pakket niet opgehaald" worden de stappen hierboven herhaald, met als toevoeging: de status van de klant wordt automatisch op ex-abonnee gezet (het abonnement zal ook gestopt worden).
Stroomlijning van de uitgifte
- Klant komt aan, klantnummer wordt ingevoerd door medewerker (of gescand van nieuw te produceren klantenkaarten). Wanneer het klantnummer niet beschikbaar is kan de klant worden opgezocht op basis van andere persoonsgegevens.
- Medewerker krijgt op scherm te zien of er een pakket opgehaald mag worden vandaag
- Indien er een pakket klaar is om opgehaald te worden geeft de medewerker aan dat het pakket opgehaald is en wordt het pakket overhandigd.
- Ook zichtbaar op het scherm: een overzicht van aantal pakketten die nog opgehaald worden die dag (A,B,of C Pakket en daarnaast de dieetsoort), zodat de inpakkers weten hoeveel er nog klaargezet/klaargemaakt moet worden indien er te weinig is
- Aan einde van de dag via hierboven genoemde overzicht een lijst krijgen van mensen die de pakketten niet hebben opgehaald. Vanuit dit overzicht kunnen de "pakket niet opgehaald" berichten worden verstuurd/geprint.
- Bij de laatste 2 (kan aangepast) pakketten die de klant ophaalt zal ook automatisch een mail verstuurd worden dat het laatste pakket over 4/2 weken opgehaald kan worden. Op deze manier kan de klant waar gewenst een aanvraag tot verlenging indienen. Deze informatie zal ook op het scherm getoond worden wanneer de klant niet over een emailadres beschikt (dit laatste zal er ook bij staan, zodat duidelijk is dat de informatie verteld moet worden).
Rapportages
Over klanten
- Aantal klanten, totaal als per locatie
- Leeftijdsverdeling van klanten
- Leeftijdsverdeling van alle gezinsleden
- Recidivisme onder klanten (klanten met 2+ abonnementen)
- Gemiddelde duur van ondersteuning van klanten
- Verdeling van klanten over Leeuwarden (op basis van postcode)
- Klanten met ondersteunende instantie (aantal en per soort instantie)
- Afvloei en aanvoer van klanten
- Percentage en absolute aantallen van afgewezen intakes
- Aantal afgewezen maar doorverwezen klanten
Over pakketten
- Verstrekking per locatie per maand
- Verdeling van pakketsoorten en grootten
- Uitgiftelijsten - Pakketten die in de komende twee weken volgens planning worden opgehaald
De nieuwe database
Voor het ontwikkelen van de nieuwe database krijgt Frack in principe een carte blanche:
- Het uitleverproces is beperkt gestructureerd en ook andere processen hangen aan elkaar vast Post-It notes, het is Frack vrij hierin (in samenspraak met de Voedselbank) goede structuren te bedenken en uit te voeren.
- Van de bestaande database moet tenminste het huidige bestand aan klanten worden overgezet, inclusief NAW gegevens en informatie betreffende de abonnementen. Verdere informatie is niet kritisch, maar wenselijk.
Gebruikers en accounts
Alle gebruikers krijgen een persoonsgebonden account, en een of meer beheerders (zie hieronder) bij de Voedselbank (initieel Henk?) kunnen voor nieuwe medewerkers accounts aanmaken. Deze beheerder zal uiteraard worden uitgelegd hoe het systeem en het beheren werkt.
Frack identificeert voor de applicatie vier soorten gebruikers:
- Beheerders – beheren het systeem en maken nieuwe gebruikersaccounts, en wijzen rollen toe aan de bestaande gebruikers. In een vergevorderd stadium beheren ze ook de mogelijkheden aan soorten voedselpakketten en dergelijke.
- Administratief medewerkers – Kunnen gegevens van klanten aanpassen, klantstatus updaten etc.
- Uitgevers – Beheren het proces van voedselpakketten uitgeven. Delen het juiste pakket uit aan de klanten die langskomen, tracken dit in het systeem, sturen mails uit naar mensen die de pakketten niet opgehaald hebben.
- Inpakkers – Stellen de voedselpakketten samen, en geven per batch aan welke (en hoeveel) producten er in een pakket gaan.
Informatie van klanten
Het hoofdobject in de database is de klant. Alle andere gegevens vloeien hieruit voort. Hieronder is een vereenvoudigde boomstructuur van de database weergegeven:
- Klantnummer (op dit moment op basis van postcode + huisadres (incl toevoeging)
- Gezinssamenstelling
- Om de gezinsstructuur en informatie op te slaan. Per gezinslid de volgende informatie:
- Naam (in 1 veld zonder splitsing)
- Geslacht
- Geboortedatum
- VoedselpakketAbonnement
- Dit komt in een andere tabel te staan, omdat niet alle klanten voedselpakketten krijgen (sommige komen nooit voorbij de intake-fase). Een klant kan in theorie meer dan een abonnement hebben.
- PakketDieet (zie #Soorten pakketten)
- PakketGrootte (zie #Soorten pakketten)
- Uitgifteinformatie (zie #Locaties en momenten van pakketuitgifte)
- Datum ingang
- Aantal pakketten (met standaardkeuzes voor 4 en 12 pakketten, of handmatig in te vullen); Einddatum wordt automatisch bepaald op basis van het aantal pakketten; Gemiste pakketten worden (in principe) niet alsnog verstrekt
- Pakketgeschiedenis
- Hier wordt per pakket bijgehouden welke pakketten wanneer zijn klaargemaakt en opgehaald
- Pakket+Abonnement (een koppeling naarr het juist pakket en abonnement)
- UitgifteDatum – geplande datum van uitgifte
- Verwerkt – Geeft aan dat het pakket verwerkt is, het komt dan niet meer in de applicatie als 'wachtend' te staan
- Opgehaald – Geeft aan of het pakket opgehaald is of niet
- Malus – indien het pakket zonder goede reden niet is opgehaald
- Tijdstip van update – Bij elke wijziging wordt bijgehouden wanneer deze plaatsvond, zodat de historie inzichtelijk is
- Contactgegevens
- Dit ook in een aparte tabel, daar er naast de natuurlijke persoon zelf (de klant) ook een contactpersoon kan zijn (een curator, bewindvoerder etc)
- Type contactpersoon (hoofd- / alternatief-)
- Aanspreektitel
- Naam (opgesplitst in voor+achternaam met los tussenvoegsel)
- Leeftijd
- Geslacht
- Telefoonnummer
- Emailadres
- Adresgegevens
- Klantstatus
- Statusgeschiedenis wordt net als VoedselpakketAbonnement opgeslagen in een aparte tabel. Op deze manier zijn de historische statusen waar mensen doorheen gaan bij te houden. Bij elke statusverandering kan ook een notitie opgeslagen worden. Notities kunnen uiteraard ook gemaakt worden zonder statuswijziging.
- Status (aangemeld, intake, afgewezen, klant, ex-klant, ex-klant met reden)
- Opmerking
- Datum van wijziging
- Medewerker
- Tijdstip
Interface mockups
In het programma Balsamiq Mockups heeft
interface mockups gemaakt voor de verschillende acties die men kan uitvoeren in het administratiesysteem, aan de hand van originele schetsen van
CodeHunger CodeHunger (CodeHunger) Rol: niet-deelnemer Deskundig met: Arduino, HTML, Javascript, Mustache, Programmeren, Python, Sammy Werkt aan: Geen projecten :( . De originele mockup bestanden (.bmml) en de PNG exports kunnen via deze link gedownload worden. Niet alle mockups worden hier dus getoond, omdat de mockups nogal hoog zijn en dus niet passen in de pagina layout.
Inlogscherm
Toegangverschaffer voor de medewerkers die werken met het administratiesysteem.
Dashboard
Iedereen komt binnen op het overzichtsscherm met daarop een groot invoerveld om naar een klant te gaan en een overzicht van de pakketten die die dag uitgedeeld dienen te worden. Aan de linkerkant is een menu aanwezig waarmee men direct naar een actie kan springen als het inschrijven van een nieuwe klant en het beheren van de verschillende diëten.
Klantbeheer pagina
De pagina waar klantgegevens ingezien en gewijzigd kunnen worden, alsmede gecheckt kan worden of een klant een pakket mag ophalen of niet, wanneer laatste uitgifte was en wanneer de volgende zal zijn.
Nieuwe klant aanmaken pagina
Om een nieuwe klant van de voedselbank aan te melden.
Dieetbeheer pagina
Aanmaken, bewerken en verwijderen van diëten als halal, vegetarisch.
Medewerkersbeheer pagina
Aanmaken, bewerken en verwijderen van medewerkers die in kunnen loggen in het administratiesysteem.
Backend JSON Interface
De hierboven beschreven web-interface is aangesloten op een RESTful JSON API. Via deze API worden alle acties uitgevoerd. Dit begint bij het inloggen, maar ook alle acties om informatie op te halen, bij te werken en toe te voegen zullen via deze API worden gedaan. De website wordt ook op deze server gehost. Het front-end hiervan is te vinden op /frontend op de webserver.
De volledige beschrijving van de Backend JSON API staat op een eigen pagina.
Klantenpasjes
heeft de mogelijkheden voor het aanschaffen / maken van pasjes onderzocht. De resultaten van dit onderzoek zijn hier te vinden: Mogelijkheden klantenpas.
