Software bouwen gaat veel verder dan alleen maar software bouwen op zich. Tuurlijk, ergens kom je op het punt dat je moet gaan “codekloppen”, om het maar een oneerbiedig te zeggen. Maar daar gaat vaak een proces aan vooraf dat vrijwel niets te maken heeft met het ontwikkelen of programmeren van Access-oplossingen. En juist in die fase, waarin we het vraagstuk van de klant van alle kanten grondig bekijken en analyseren, zonder daarbij overigens verstrikt te raken in die analysefase, zit negen van de 10 keer de echte waarde van een softwareontwikkelproject.
Oké, hoor ik je denken. Allemaal leuk en aardig, maar waar moet ik dan precies aan denken? Wat kunnen jullie als databasespecialisten met diepgaande technische kennis en knowhow op het gebied van Microsoft Access nou dan eigenlijk in dat proces voorafgaand aan de ontwikkelfase beteken?
Eerlijk gezegd is dat te veel om op te noemen. We doen dit immers al een tijdje (iets van 25 jaar of zo) én bovendien bouwen we maatwerk, dus elke klantvraag is anders en uniek. Laat ik daarom volstaan met een paar voorbeelden van wat we zoal voor klanten uitdokterden in opmaat naar c.q. ter voorbereiding op het ontwikkelen van een stukje software in Microsoft Access.
Boekingsgang voor een bancaire instelling
Wij werken als sinds jaar en dag enkele dagdelen per week voor een grote bancaire instelling. Deze instelling meldde zich een jaar of 10 geleden bij ons met de vraag of wij een portefeuillebeheersysteem voor hen konden ontwikkelen met koppelingen naar hun boekhoudsysteem. De instelling in kwestie beheert portefeuilles voor honderden verschillende klanten. En dan is het natuurlijk wel handig als je dan beschikt over een systeem waarmee klanten direct mutaties, waarden, etc. van hun portefeuille kunnen inzien en waarmee mutaties van de bank zelf direct juist op de balans en naar de resultatenrekening worden geboekt. Maar welke boekhoudkundige mutaties moeten dan op welk moment worden gemaakt? Een kolfje naar de hand van één van onze Access-experts met de zwarte band boekhouden.
Planningssystematiek voor een productiebedrijf
Toen deze opdracht, nu zo’n 15 jaar geleden, bij ons binnenkwam, moesten we denken aan het boek “Noodzakelijk, maar niet voldoende” van dr. Eli Goldratt. In dat boek werkt Goldratt in romanvorm met essayachtige elementen uit waarom een ERP-systeem in gebruik hebben leuk is (“noodzakelijk”), maar ook waarom ERP-systemen vaak falen als het gaat om het toevoegen van echte bedrijfswaarde (“maar niet voldoende”). Met de meeste planningssystemen is namelijk hetzelfde aan de hand: uit het planningssysteem blijkt klip en klaar welke persoon of machine wat wanneer moet doen, maar of de voor het in elkaar zetten van de planning in bedrijfseconomische zin nou de meest winstgevende oplossing is gekozen is maar de vraag (het antwoord is vaak nee). Dus gingen we voordat we ook maar iets bouwden aan het goochelen met grootheden als omsteltijden, voorraden, tussenvoorraden (belangrijk!), levertijden, leverbetrouwbaarheid, etc. Het resultaat: een ultraslank planningsalgoritme waarmee menig productieplanner bij wijze van spreken wel een nachtje door wil brengen. ;-)
Moraal van het verhaal
Moraal van het verhaal is, om Bill Gates losjes te citeren, dat het geen zin heeft om over softwareontwikkeling te praten als je niet ook over het onderliggende bedrijfsproces kunt praten. Bij ons zijn dat in ieder geval twee flanken van dezelfde berg. Twee flanken die je beide moet kunnen beklimmen om resultaat te boeken voor je opdrachtgevers. En dat is vaak: meer resultaat onderaan de streep.
Keer brainstormen
Heb jij een vraagstuk binnen jouw bedrijf waar je nu al een tijdje mee worstelt? Plan dan een gratis brainstorm in, zodat we het probleem eens van alle kanten en vanuit verschillende disciplines kunnen belichten. Dat kan hier: https://mraccess.nl/contact
