Theorie over softwareontwikkeling is mooi, maar hoe ziet een traject er in de praktijk uit? In dit artikel nemen we je mee in een (geanonimiseerde) case: een groothandel die worstelde met losse Excel-bestanden en e-mails, en die we hielpen aan een eigen planningstool. Van het eerste gesprek tot de livegang — en alles wat daartussen zit.
Het begon met een probleem, niet met een oplossing
De klant kwam niet binnen met "ik wil software", maar met "mijn planning loopt vast". Orders werden bijgehouden in Excel, afspraken stonden in e-mails en de werkvloer wist nooit precies wat er die dag moest gebeuren. Het gevolg: dubbel werk, fouten en frustratie. Onze eerste stap was dus niet bouwen, maar luisteren en analyseren.
In een aantal sessies brachten we het werkelijke proces in kaart — niet hoe het op papier hoorde te gaan, maar hoe het écht liep. Daaruit bleek dat het probleem niet zozeer de planning zelf was, maar dat informatie versnipperd op te veel plekken leefde. Die analyse vormde de basis voor alles wat volgde.
Juist die fase wordt vaak overgeslagen, terwijl het de belangrijkste is. Wie meteen begint te bouwen, automatiseert vooral de bestaande chaos. Door eerst grondig te begrijpen waaróm dingen liepen zoals ze liepen, konden we onderweg meteen een paar overbodige stappen schrappen. De klant kreeg dus niet alleen een digitale versie van zijn oude proces, maar een slimmer proces dat toevallig ook gedigitaliseerd was.
Bouwen in sprints, met de klant erbij
In plaats van maandenlang in stilte te bouwen en aan het eind iets op te leveren, werkten we in korte sprints van twee weken. Aan het eind van elke sprint lieten we een werkend stuk zien, vroegen we om feedback en stelden we de prioriteiten voor de volgende periode bij. Zo bleef de klant continu betrokken en kwamen er geen verrassingen aan het eind.
De aanpak in het kort:
- Sprint 1: de basis — orders invoeren en overzichtelijk tonen;
- Sprint 2: de planning per dag en per medewerker;
- Sprint 3: een koppeling met het bestaande boekhoudpakket, zodat niets dubbel ingevoerd hoefde te worden;
- Sprint 4: een eenvoudig dashboard voor de werkvloer, geoptimaliseerd voor het tablet aan de muur.
Doordat de klant elke twee weken meekeek, konden we vroeg bijsturen. Een functie die we hadden bedacht bleek in de praktijk overbodig, terwijl een klein detail dat we bijna over het hoofd zagen juist cruciaal was. Precies dat soort inzichten haal je alleen naar boven door samen te bouwen.
De livegang en daarna
Voor de lancering kozen we bewust niet voor een big bang, maar voor een rustige overgang. We draaiden het nieuwe systeem eerst een week naast het oude, trainden de medewerkers en losten de laatste kinderziektes op terwijl de oude werkwijze nog als vangnet diende. Toen iedereen er vertrouwen in had, zetten we Excel definitief uit.
Het resultaat? Minder fouten, een werkvloer die 's ochtends in één oogopslag ziet wat er moet gebeuren, en een eigenaar die eindelijk grip heeft op zijn planning. Concreet daalde het aantal misgelopen orders flink, en de tijd die de planner elke ochtend kwijt was aan puzzelen liep terug van ruim een uur naar een paar minuten. Die teruggewonnen tijd ging niet verloren, maar verschoof naar zaken die de klant wél vooruithelpen.
Maar misschien wel het belangrijkste: het systeem is na de livegang blijven meegroeien. Onze pay-off is niet voor niets "van idee tot oplevering — en daarna". We bleven betrokken, hielden het systeem actueel en bouwden in de maanden erna nieuwe wensen in. Omdat we de tool zelf hadden gebouwd en het bedrijf inmiddels goed kenden, konden we die uitbreidingen snel en zonder gedoe realiseren — iets wat met een dichtgetimmerd standaardpakket nooit zo soepel was gegaan.
Herken je iets in dit verhaal? Loop je zelf vast in losse bestanden en handmatig werk? Dan denken we graag met je mee. Plan een vrijblijvende kennismaking — wie weet schrijven we volgend jaar een case over jouw project.
