Zo kiest u een softwarepartner die bij uw bedrijf past

Vrijdagmiddag, de campagne loopt twee dagen en de webshop wordt stroperig. Ergens in de keten blijft de voorraadkoppeling achter, dus klanten bestellen artikelen die vanmorgen al uitverkocht raakten. Op zulke momenten merkt u wat uw softwarepartner waard is. De presentatie uit het verkooptraject speelt dan geen rol meer. Wat telt is of iemand opneemt, uitzoekt waar het misgaat en u vertelt waar u aan toe bent.

Leunt uw bedrijf dagelijks op software, platforms en koppelingen, dan verdient de keuze van een partner meer aandacht dan een gewone inkoopbeslissing. De verkeerde partij kost u omzet, en op termijn ook het geduld van uw eigen mensen. Hieronder staan de vragen die in de praktijk het meest verraden over hoe een samenwerking gaat lopen.

Begin bij het probleem, niet bij de techniek

Een lijst met programmeertalen en frameworks zegt in deze fase weinig. Dat gesprek komt later, zodra duidelijk is wat uw organisatie eigenlijk nodig heeft. Een goede partner wil eerst begrijpen welk bedrijfsprobleem achter uw technische vraag zit.

Wilt u handwerk uit een proces halen? Moet een klantportaal sneller worden? Lopen medewerkers vast doordat systemen niet goed gekoppeld zijn? Of groeit het platform harder dan de huidige hosting kan bijbenen? Wie zonder die vragen al een oplossing en een ureninschatting op tafel legt, neemt een risico namens u.

Vraag dus hoe een partij een traject start. Worden processen, gebruikers en afhankelijkheden in kaart gebracht? Is er aandacht voor wat er al staat, inclusief externe systemen en keuzes die jaren geleden om goede redenen zijn gemaakt? En durft iemand te benoemen wat u juist niet hoeft te bouwen? Maatwerk verdient zich terug als het een concreet knelpunt wegneemt. Zodra het oude rommel vervangt door nieuwe rommel, bent u alleen verhuisd.

Let op begrip van uw dagelijkse operatie

Software staat zelden op zichzelf. Een wijziging in een webshop raakt voorraad, betalingen, klantenservice en marketing. Een intern systeem raakt afdelingen, rollen en werkafspraken die nergens zijn opgeschreven. Een partner die alleen naar het scherm kijkt, mist de helft.

Leg een scenario uit uw eigen praktijk op tafel. Een leverancier levert te laat. Een API reageert twintig seconden niet. Een medewerker voert dezelfde order twee keer in. Vraag hoe de partij dat technisch zou opvangen, en hoe uw mensen er intussen mee verder kunnen. Het antwoord laat snel zien of u met uitvoerders praat of met iemand die over continuïteit nadenkt.

Eigenaarschap weegt zwaarder dan ontwikkelcapaciteit

Software bouwen kunnen veel bureaus. Betrokken blijven als het systeem in productie staat, gebruikers vragen gaan stellen en een extern systeem zonder aankondiging verandert, dat kunnen er minder. Daar zit het verschil tussen een leverancier voor een project en een partner voor de jaren erna.

Eigenaarschap betekent niet dat iemand buiten u om beslist. Het betekent dat een probleem niet wordt doorgeschoven. Als een applicatie, server, koppeling en externe dienst elkaar beïnvloeden, moet voor iedereen duidelijk zijn wie de analyse trekt en wie de oplossing in de gaten houdt tot het echt stabiel is.

Dat weegt extra zwaar als u geen eigen development- of DevOps-team heeft. U wilt niet zelf gaan bemiddelen tussen een ontwikkelaar, een hoster, een domeinpartij en de leverancier van een API die allemaal naar elkaar wijzen. Elke overdracht kost een dag en levert nieuwe onduidelijkheid op.

Wanneer ontwikkeling en hosting onder één dak horen

De vraag is niet of u alles bij één partij onderbrengt. De vraag is wie de hele keten overziet. Een ontwikkelpartij zonder zicht op de productieomgeving kan een fout moeilijk reproduceren. Een hoster die de applicatie niet kent, ziet een piek in de CPU en niet de query die hem veroorzaakt. Zolang iemand die twee kanten aan elkaar knoopt, kan het werk prima over meerdere partijen verdeeld blijven.

Heeft u een intern platformteam dat die rol pakt, of een gespecialiseerde cloudomgeving met eigen beheer, dan past een aparte ontwikkelpartner uitstekend. Ontbreekt die laag, dan wordt de scheiding duur op het slechtst mogelijke moment. Ontwikkeling en infrastructuur onder één dak is dan meestal de rustigste keuze, simpelweg omdat er niemand overblijft om naar te wijzen.

Kijk in beide gevallen kritisch naar de afspraken rond hosting, monitoring en back-ups, updates, beveiliging en incidenten. Vraag wie u belt bij een storing, wat er om tien uur 's avonds gebeurt en binnen hoeveel tijd een melding wordt opgepakt. Een service level agreement legt dat netjes vast. In de praktijk maakt het vaak meer verschil dat u iemand te pakken krijgt die uw omgeving uit zijn hoofd kent.

Kijk naar het proces voordat u naar de prijs kijkt

Een strak voorstel met een scherp bedrag zegt weinig over hoe de samenwerking zal verlopen. Kijk eerst hoe zorgvuldig er naar uw vraag is geluisterd. Staan de aannames er zichtbaar in? Worden risico's benoemd in plaats van weggelaten? Begrijpen zowel de beslisser als de medewerker die er straks mee werkt wat er gaat gebeuren?

Een betrouwbaar traject heeft duidelijke momenten voor onderzoek, ontwerp, bouw, testen, oplevering en nazorg. Daar hoort geen stapel projectdocumenten bij. Het moet alleen voorkomen dat een essentiële koppeling of een vergeten gebruikersrol pas twee dagen voor livegang boven komt drijven.

Let ook op hoe wijzigingen worden behandeld, want er verandert altijd iets. Nieuwe inzichten, verschoven prioriteiten, een extern systeem dat anders blijkt te werken dan de documentatie beweerde. Een goede partner rekent de gevolgen voor en legt die naast elkaar: planning, budget, techniek en wat het betekent voor het beheer op termijn. Dan neemt u een besluit op basis van feiten, in plaats van achteraf te schrikken.

Technische kwaliteit beoordelen zonder zelf code te lezen

U hoeft geen ontwikkelaar te zijn om hier goede vragen te stellen. Een professionele partij kan in gewone taal uitleggen hoe kwaliteit wordt geborgd, met concrete keuzes in plaats van jargon.

Vraag hoe er wordt getest voordat iets live gaat. Vraag hoe fouten worden gelogd en wie ze daadwerkelijk onder ogen krijgt. Vraag hoe u terug kunt als een release onverwacht problemen geeft, en hoe lang dat duurt. Vraag hoe toegangsrechten zijn ingericht en wat er met privacygevoelige gegevens gebeurt. Bij koppelingen is de interessantste vraag wat er gebeurt als het andere systeem er even uit ligt. Verdwijnen er gegevens, ontstaan er dubbele orders, of wordt de verwerking later veilig opnieuw aangeboden?

Documentatie hoort daar ook bij, en dan niet als handboek dat niemand opent. Een werkbaar overzicht van koppelingen, beheertaken, accounts, afhankelijkheden en de manier waarop een release wordt uitgerold is genoeg. Zit alle kennis uitsluitend in de hoofden van twee mensen, dan bent u kwetsbaar zodra een van hen op vakantie gaat.

Vergelijk kosten op gelijke uitgangspunten

Het laagste uurtarief is zelden de laagste totale kostenpost. Een lage startprijs kan duur worden zodra de scope onduidelijk blijkt, technische schuld zich opstapelt of ondersteuning na oplevering ontbreekt. Een hoger tarief is overigens ook geen bewijs van kwaliteit. U betaalt terecht meer als daar aantoonbaar minder risico, een snellere reactie of een kortere doorlooptijd tegenover staat.

Zet offertes daarom naast elkaar op dezelfde punten. Wat valt onder analyse, ontwerp, testen en projectmanagement? Zitten hosting en beheer erbij of komt dat apart? Welke kosten zijn eenmalig en welke keren elke maand terug? Wat is de afspraak bij extra werk? En wie bezit de broncode, de configuraties en de toegang tot de infrastructuur? Die laatste vraag wordt vaak vergeten, tot het moment dat iemand wil overstappen.

Wees ook eerlijk over de omvang van uw vraag. Voor een klein en duidelijk afgebakend project kan een specialistische freelancer uitstekend werk leveren, vaak sneller en goedkoper dan een bureau. Zodra het gaat om een platform met meerdere integraties, groeiende gebruikersaantallen en de verwachting dat er altijd iemand bereikbaar is, weegt teamcontinuïteit zwaarder dan het tarief van één persoon. Die persoon wordt namelijk ook ziek.

Begin klein en test de samenwerking

De beste voorspeller van een goede samenwerking is een eerste, overzichtelijke opdracht. Een technische audit bijvoorbeeld, of een hardnekkig performanceprobleem dat al maanden meeloopt, een afgebakende koppeling of een proof of concept. U ziet dan hoe snel er wordt geschakeld, hoe helder de communicatie is en of afspraken worden nagekomen als het even tegenzit.

Gebruik die eerste opdracht en de gesprekken eromheen om vijf dingen te toetsen:

• Begrijpt de partij uw bedrijfsdoel, en niet alleen de technische vraag?
• Krijgt u antwoord van mensen die inhoudelijk kunnen meedenken?
• Worden risico's en beperkingen eerlijk op tafel gelegd?
• Is duidelijk wie verantwoordelijk is voor beheer en incidenten?
• Voelt de communicatie praktisch en voorspelbaar?

Dat laatste punt klinkt zacht, maar operationeel is het misschien wel het belangrijkste. In elk softwaretraject komen keuzes en onverwachte situaties voorbij. Op die momenten wilt u geen accountmanager tussen u en de mensen die het werk doen. U wilt binnen een kwartier iemand aan de lijn die uw omgeving kent en direct iets kan veranderen.

Een goede partner belooft u niet dat er nooit iets stukgaat. Die zorgt ervoor dat u het snel weet, begrijpt wat er aan de hand is en ziet dat er al aan gewerkt wordt. Kies dus de partij waarvan u na het eerste inhoudelijke gesprek denkt: als dit morgenochtend hapert, nemen zij op en gaan ze aan de slag.