App-ontwikkeling voor bedrijven: waar het meestal misgaat

Een app waar klanten op moeten wachten, waar medewerkers omheen werken of die niets weet van uw bestaande systemen, kost elke werkdag geld. Toch begint bijna elk app-traject bij dezelfde vraag: hoe gaan de schermen eruitzien? Dat is geen domme vraag, maar het is wel de verkeerde om mee te openen.

De vragen die er later echt toe doen, komen in zo'n eerste sessie meestal niet voorbij. Waar komt de data vandaan? Wie past de koppeling aan als het ERP wordt vervangen? Wat gebeurt er als het gebruik verdubbelt? En wie neemt de telefoon op als er op maandagochtend niemand kan inloggen? Precies daar zit het verschil tussen een app die het doet op de dag van de lancering en een app waar uw organisatie over drie jaar nog op draait.

Begin bij het knelpunt, niet bij de functielijst

Een zakelijke app staat zelden op zichzelf. Meestal is het een verlengstuk van uw planning, voorraad, CRM, klantportaal of van een werkwijze die al jaren bestaat. De monteur wil zijn werkbon op locatie afronden. De accountmanager wil zien wat er gisteren met die klant is gebeurd. De klant wil weten waar zijn bestelling blijft, zonder te bellen.

De nuttigste openingsvraag is dus niet welke functies u wilt, maar waar u nu tijd, overzicht of omzet verliest. Zodra dat scherp is, weet u ook voor wie de app bedoeld is en wat er in versie één moet zitten.

Neem een app voor de buitendienst. Foto's uploaden klinkt handig. De echte winst zit alleen ergens anders: dat die foto automatisch aan de juiste opdracht hangt, dat de backoffice de gegevens binnenkrijgt zonder over te typen en dat niemand hetzelfde formulier twee keer invult. Zonder die koppeling is de app een extra handeling erbij. Mét die koppeling vervangt hij werk.

Dat verschil voorkomt de klassieke misser: een rommelig proces netjes digitaliseren. Software maakt een proces sneller, maar verzint geen duidelijke verantwoordelijkheden en repareert geen gegevens die op vier plekken half worden bijgehouden. Soms moet de werkwijze eerst worden opgeschoond. Dat voelt als vertraging en is het niet, want het scheelt later maanden herstelwerk.

Native, web of cross-platform?

Pas als het knelpunt duidelijk is, wordt de techniekvraag interessant. Een native iOS- en Android-app geeft doorgaans de prettigste gebruikservaring en de beste toegang tot camera, pushmeldingen, locatie en offline opslag. Dat weegt zwaar als mensen de hele dag onderweg zijn, als snelheid telt of als de app tientallen keren per dag opengaat.

Een webapp is vaak verstandiger wanneer gebruikers toch al achter een browser zitten, wanneer u snel wilt uitrollen zonder appstore-review, of wanneer de functionaliteit overzichtelijk blijft. Voor de ene organisatie is een responsief klantportaal genoeg. Voor de andere is een combinatie logisch: een webomgeving voor de beheerders, een mobiele app voor de mensen in het veld.

Cross-platform kan ook prima passen. U deelt dan een groot deel van de code tussen iOS en Android, wat ontwikkeltijd en later ook beheer scheelt. Vooral bij apps die draaien om formulieren, gegevens en processtappen werkt dat goed. Bij zware graphics, intensief cameragebruik of strakke prestatie-eisen ligt het anders. De afweging hangt dus af van wat de app moet doen, niet van wat er op dat moment in de mode is.

Een goede technische partner legt dat uit in gewone taal, met de nadelen erbij. Wie zonder die afweging alleen op de goedkoopste route stuurt, betaalt het verschil later terug in beperkingen of in een herbouw.

De koppelingen bepalen of het werkt

De meeste zakelijke apps worden pas waardevol op het moment dat ze betrouwbaar praten met andere systemen: ERP, boekhouding, planning, CRM, betaalproviders, magazijnsoftware of een eigen database. Daar zit ook het grootste risico.

Een app kan er aan de voorkant vlekkeloos uitzien terwijl de gegevens erachter te laat binnenkomen of elkaar overschrijven. Klopt de voorraad niet, loopt een status achter of staat een opdracht er twee keer in, dan is het vertrouwen binnen een week weg. Daarna gaan mensen weer handmatig controleren en is de tijdwinst verdampt.

Breng daarom vóór de bouw in kaart welke gegevens de app leest, wijzigt en terugstuurt, en spreek per gegevenssoort af welk systeem leidend is. De klantnaam komt uit het CRM, de orderstatus uit het ERP, documenten uit het archief. Het klinkt technisch, maar het is vooral een bedrijfskeuze: welke informatie moet op welk moment kloppen?

Denk ook de uitzonderingen door. Wat doet een monteur in een kelder zonder bereik? Wat gebeurt er als een externe API er een half uur uit ligt? Hoe legt u wijzigingen vast, zodat u drie maanden later kunt terugzien wie wat heeft aangepast? Dit is geen werk voor de laatste testweek. Dit bepaalt of de app overeind blijft op een drukke donderdag.

Klein beginnen is iets anders dan klein denken

Een eerste versie hoeft niet alles te kunnen. Een te brede release levert vooral traag overleg op, meer afhankelijkheden en te weinig aandacht voor de kern. Begin bij de functionaliteit die het grootste probleem oplost en waar mensen morgen mee aan de slag kunnen.

De architectuur mag intussen best rekening houden met wat er over twee jaar bij komt. Alleen hoeft dat niet allemaal nu gebouwd te worden. Een planningstool kan starten met opdrachten bekijken, status bijwerken en foto's toevoegen. Rapportages, routeoptimalisatie en een uitgebreid rollenmodel volgen zodra het dagelijkse gebruik staat.

Betrek gebruikers daarbij tijdens de bouw, niet pas op de opleveringsdag. Iemand die het proces elke dag doet, ziet binnen vijf minuten dat een knop op de verkeerde plek staat of dat een term in de app iets anders betekent dan op de werkvloer. Die opmerkingen zijn concreter dan alles wat er in een vergaderruimte wordt bedacht.

Test verder met realistische gegevens en onder realistische omstandigheden. Een app die soepel loopt op tien testorders gedraagt zich anders bij vijftigduizend records, een haperende verbinding of drie mensen die tegelijk dezelfde regel aanpassen. Hoe eerder u dat weet, hoe goedkoper het is.

Wie belt u als het stilstaat?

Na de livegang houdt het niet op. Besturingssystemen krijgen updates, beveiliging vraagt aandacht, API's veranderen zonder dat u erom vraagt en gebruikers verwachten dat een storing binnen een uur is opgelost. Liggen ontwikkeling, hosting en technisch beheer bij verschillende partijen, dan begint bij elk incident hetzelfde spel: de hoster wijst naar de applicatie, de ontwikkelaar naar de infrastructuur, en uw team wacht.

Eén aanspreekpunt is daarom meer dan gemak. Het verkort de weg van melding naar oplossing. Wie zowel de code als de serveromgeving kent, ziet sneller of een probleem in een query, in een koppeling of in de capaciteit zit.

Leg wel vast wie wat doet. Wie bewaakt de updates? Wie kijkt naar de prestaties? Wie maakt back-ups en test ook echt of een herstel lukt? Hoe meldt u een storing buiten kantooruren en hoe snel volgt er reactie? Een contract is daarbij het minste. Belangrijker zijn bereikbare mensen die de verantwoordelijkheid niet doorschuiven.

Bij LJPc zitten ontwikkeling, infrastructuur en support onder hetzelfde dak. Dat scheelt u de rol van scheidsrechter tussen leveranciers, en het scheelt vooral tijd op het moment dat er iets misgaat.

Vragen die u stelt voordat u tekent

Een partij die u een standaardpakket aanbiedt voordat hij uw situatie kent, kunt u rustig laten gaan. Vraag hoe het traject van analyse tot beheer loopt, hoe beslissingen worden vastgelegd en wie u tijdens en na de bouw daadwerkelijk aan de lijn krijgt.

Kijk ook verder dan een portfolio met mooie schermen. Vraag naar integraties, beveiliging, schaalbaarheid en incidenten. Laat uitleggen wat er gebeurt als een koppeling wegvalt, als het gebruik sneller groeit dan gepland of als een nieuwe iOS-versie iets breekt. Aan concrete antwoorden heeft u meer dan aan een mooie belofte.

De prijs telt uiteraard mee, maar vergelijk offertes niet op het aantal schermen of uren. Een goedkope app zonder fatsoenlijk beheer, documentatie en betrouwbare hosting is binnen twee jaar duurder dan een aanpak die vanaf dag één rekening houdt met continuïteit.

Groot hoeft een app trouwens niet te zijn. Als hij één overdracht versnelt, één type fout uitbant of klanten een telefoontje bespaart, is de opbrengst al zichtbaar. Begin bij het knelpunt dat nu pijn doet, kies iemand die technische keuzes in begrijpelijke taal uitlegt, en zorg dat er ook na de livegang een naam en een nummer zijn. Dan is uw app geen los project, maar gereedschap waar u op kunt bouwen.