Je hoeft niets uit te leggen aan een pakket
Bij een standaardpakket pas jij je proces aan. Op een bouwdag kijken we naar hoe het bij jullie gaat, met de uitzonderingen erbij.
Er is een proces dat al jaren knelt. Iedereen weet welk, iedereen weet ongeveer hoe het beter kan, en er is niemand die het uitzoekt. Niet omdat het niet mag, maar omdat er geen IT'er in huis is en de mensen die het wél zouden kunnen bedenken al vol zitten met hun eigen werk.
Zonder iemand die de vraag vertaalt, koop je wat de verkoper aanbiedt.
Wie geen eigen IT'er heeft, koopt software op basis van een demo en een gesprek. Dat gaat vaak goed en soms grondig mis, en het verschil zit meestal in één ding: of iemand vooraf heeft uitgezocht wat er in jouw situatie werkelijk moet gebeuren. Die vertaalslag is precies wat er ontbreekt, en het is niet iets waarvoor je iemand in dienst hoeft te nemen.
Wat het extra lastig maakt: je kunt zonder die vertaalslag ook geen offertes vergelijken. Drie leveranciers noemen drie bedragen voor drie verschillende dingen, en je hebt geen manier om vast te stellen welke het dichtst bij jouw probleem zit.
Een bouwdag draait die volgorde om. Er ligt aan het eind van de dag iets werkends dat jullie zelf kunnen proberen. Werkt het, dan weet je wat je wilt en kun je gericht inkopen. Werkt het niet, dan heb je dat geleerd voordat je een jaarcontract tekende.
Bij een standaardpakket pas jij je proces aan. Op een bouwdag kijken we naar hoe het bij jullie gaat, met de uitzonderingen erbij.
De code komt in je eigen repository. Ook als je daarna met een andere partij verder wilt, ben je niet vastgeklonken.
Je hoeft geen kwartaal vrij te maken. Eén dag, met één of twee mensen van jullie kant erbij, is genoeg om een antwoord te krijgen.
Welke handeling kost nu het meeste tijd of gaat het vaakst mis? Daar begint de dag.
Niet in een beschrijving maar bij degene die het doet. Daar zit de helft van het antwoord.
Niet het hele proces, maar de handeling die er het meest uithaalt.
Binnen tien minuten weet je of het klopt.
De opmerkingen van die tien minuten zijn waardevoller dan een week vooronderzoek.
Zodat je een gericht gesprek kunt voeren met wie het ook bouwt.
Vertel welk proces bij jullie knelt en wie het nu met de hand doet. In een korte intake bepalen we of daar in één dag een werkend deel van te bouwen is.
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Nee. Wat je wel nodig hebt, is iemand die het werk kent: degene die het proces nu met de hand doet. Die persoon beantwoordt op een bouwdag meer vragen dan een technisch profiel, omdat de uitzonderingen bij hem zitten en niet in de beschrijving.
Na een bouwdag niemand, en dat is bewust. Wat er staat is een prototype: het draait, maar er zit geen beheer, geen storingsdienst en geen back-upafspraak op. Wil je het echt in gebruik nemen, dan is dat een vervolgtraject en dat bespreken we vooraf.
Dat kan. De code staat in je eigen repository en het logboek beschrijft de keuzes van die dag. Een andere partij kan daarmee verder zonder dat er kennis bij ons blijft hangen. Dat is een van de redenen dat we het zo leveren.
Vaak wel, en dan zeggen we dat. Voor standaardprocessen als verlof, urenregistratie of facturatie bestaan goede abonnementen. Een bouwdag is interessant als jouw proces net anders is en je dat niet in een demo kunt uitleggen.
Eén dag van één of twee mensen die het werk kennen, plus een korte intake vooraf. Meer niet. Dat is bewust: als de voorbereiding meer tijd kost dan de bouwdag zelf, is het geen bouwdag meer.
In een korte intake kijken we naar het knelpunt en of daar in één dag iets werkends van te maken is. Wil je het daarna echt in gebruik nemen, dan doet Appfront dat traject.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.