Een klant zocht een Access-specialist.
Maar zijn echte probleem zat niet in Access.
Onlangs werd ik gecontacteerd door een bedrijf dat op zoek was naar iemand met kennis van Microsoft Access.
Dat leek op het eerste gezicht een puur technische vraag.
Maar tijdens het eerste gesprek gebeurde er iets wat ik wel vaker zie.
Het gesprek ging al snel niet meer over Access.
Het ging over dubbele invoer.
Over informatie die telkens opnieuw uit het bestaande systeem moest worden overgenomen.
Over medewerkers die dagelijks tijd verloren aan dezelfde handelingen.
En over de frustratie die dat met zich meebracht.
Daarom ben ik niet begonnen met programmeren. Ik ben eerst beginnen begrijpen hoe de onderneming werkte.
Ik ben eerst beginnen luisteren.
Ik wilde begrijpen hoe het bedrijf werkte.
Welke informatie echt belangrijk was.
Waar tijd verloren ging.
En vooral: waarom.
Pas daarna zijn we samen stap voor stap beginnen bouwen.
Vandaag worden jaarlijks duizenden orders automatisch verwerkt zonder dat medewerkers dezelfde gegevens opnieuw moeten invoeren.
Productfiches worden automatisch aangemaakt.
En wat vroeger dagelijkse frustraties veroorzaakte, is vandaag gewoon een onderdeel van de normale werking geworden.
Die ervaring heeft mij iets belangrijks geleerd.
De juiste oplossing begint zelden met technologie. Ze begint met begrijpen hoe een onderneming werkt.
๐ต Wij beginnen niet met programmeren. Wij beginnen met begrijpen.
Dat is niet alleen één van de vier hoekstenen van D & P Solutions.
Het is de basis van elk project waar ik met vertrouwen aan begin.
๐๐ฒ๐ ๐ฏ๐ฒ๐ด๐ผ๐ป ๐บ๐ฒ๐ éé๐ป ๐ฝ๐ฎ๐ฝ๐ถ๐ฒ๐ฟ๐ฒ๐ป ๐๐ฒ๐ฟ๐ธ๐ฏ๐ผ๐ป.
Toen ik voor het eerst bij een nieuwe klant over de vloer kwam, lag er geen vraag op tafel om een volledig ERP-systeem te bouwen.
Er lag gewoon een papieren werkbon.
Dat was het eerste probleem dat opgelost moest worden.
We begonnen klein.
Eén proces.
Eén verbetering.
Toen dat werkte, volgde de volgende stap.
En daarna nog één.
Jaren later was er geen verzameling losse oplossingen meer, maar een volledig geïntegreerd systeem dat vandaag de dagelijkse werking van het bedrijf ondersteunt.
Die ervaring heeft mij iets belangrijks geleerd.
Je hoeft geen groot project te verkopen. Je hoeft alleen de eerste stap waardevol genoeg te maken.
Daarom geloof ik niet in projecten die vanaf dag één alles tegelijk willen oplossen.
Ik geloof in kleine stappen.
Elke stap moet vertrouwen geven om de volgende te zetten.
๏ปฟ
๐ข Kleine stappen. Grote doelen.
Dat is niet alleen één van de vier hoekstenen van D & P Solutions.
Het is ook de manier waarop de mooiste samenwerkingen ontstaan.
๐ช๐ถ๐ท ๐๐ถ๐น๐น๐ฒ๐ป ๐ฑ๐ฎ๐ ๐๐ฒ๐ฟ๐ฟ๐ฎ๐๐๐ถ๐ป๐ด๐ฒ๐ป ๐ฝ๐ผ๐๐ถ๐๐ถ๐ฒ๐ณ ๐๐ถ๐ท๐ป, ๐ป๐ถ๐ฒ๐ ๐ผ๐ป๐ฎ๐ฎ๐ป๐ด๐ฒ๐ป๐ฎ๐ฎ๐บ.
Bij softwareprojecten zijn verrassingen niet altijd te vermijden.
Maar het soort verrassing maakt een groot verschil.
• “Dit kan óók?”
• “Dat scheelt ons elke dag werk.”
• “Daar hadden we zelf nog niet aan gedacht.”
Dit zijn het type verrassingen waar we van houden.
• Een factuur die veel hoger uitvalt dan verwacht?
• Een oplossing die technisch perfect werkt, maar niet aansluit bij de praktijk?
• Pas op het einde ontdekken dat een belangrijke situatie over het hoofd werd gezien?
Deze? Liever niet.
Daarom proberen we tijdens een project voortdurend duidelijk te houden waar we staan, wat we aan het bouwen zijn en waarom.
En wanneer we onderweg iets ontdekken dat beter, eenvoudiger of slimmer kan, bespreken we dat.
Want maatwerk mag onderweg evolueren.
Maar de klant zou nooit pas op het einde mogen ontdekken waar hij aan toe is.
๏ปฟ
๐ก
Wij willen dat verrassingen positief zijn. Niet onaangenaam.
Dat is al meer dan twintig jaar één van de principes die onze manier van werken bepalen.
Sommige fouten ontstaan lang voordat de eerste regel software geschreven wordt.
Bij een klant kregen we ooit de vraag om een belangrijk deel van hun bedrijfsproces verder te automatiseren.
De mogelijkheden waren groot.
Maar er was ook één belangrijke onzekerheid.
De oplossing zou alleen kunnen werken als we bepaalde informatie betrouwbaar uit een bestaand systeem konden halen.
We hadden meteen kunnen beginnen programmeren.
Dat hebben we niet gedaan.
Eerst hebben we onderzocht of die cruciale stap technisch mogelijk was. Pas toen we daar zekerheid over hadden, zijn we verder gaan bouwen.
Dat kostte tijd vóór er ook maar iets van de uiteindelijke oplossing zichtbaar was.
Maar het alternatief was veel riskanter: wekenlang software ontwikkelen om daarna te ontdekken dat de basis waarop alles gebouwd was, niet betrouwbaar genoeg was.
Ik heb geleerd dat de grootste opluchting vaak niet komt wanneer een project klaar is, maar wanneer de grootste onzekerheid verdwenen is.
๏ปฟ
๐ด Wij programmeren liever één week later dan één maand de verkeerde oplossing.
Dat is al meer dan twintig jaar één van de principes die onze manier van werken bepalen.
Want soms is niet beginnen met programmeren precies wat nodig is om uiteindelijk sneller tot de juiste oplossing te komen.