Vier eisen voor een technische partner die doorpakt bij storingen

Je campagne loopt, de bezoekers stromen binnen en de webshop wordt steeds trager. Of de koppeling met je voorraadsysteem valt stil terwijl de orders blijven komen. Je belt de ontwikkelaar, die naar de hosting wijst. De hostingpartij ziet aan haar kant niets vreemds. Dat is het moment waarop je merkt welke eisen voor een technische partner ertoe doen. Het portfolio en de scherpe offerte waarop je ooit koos, helpen je nu weinig.

Bij veel bedrijven is de techniek in de loop der jaren over meerdere partijen verdeeld geraakt: een ontwikkelaar, een hostingprovider, een bureau en nog een specialist voor de koppelingen. Zolang alles draait, merk je daar weinig van. Bij een storing begint de discussie over wie het oplost.

Hieronder staan de vier eisen waarop ik een partner zou beoordelen, in de volgorde waarin ik ze zou toetsen. Schaalbaarheid staat bewust achteraan. Daar mag je het mee oneens zijn.

Een ongeteste back-up telt niet mee

Bouwen kunnen veel partijen. De vraag is wie ervoor zorgt dat het blijft werken. Continuïteit zit in hosting, monitoring, back-ups, updates, beveiliging, documentatie en herstel na een incident. Niemand kijkt ernaar zolang alles draait. Op de dag dat het niet draait, bepaalt juist dit hoe lang je stilligt.

Vraag door op de details. Worden storingen automatisch gesignaleerd? Heeft je partner zicht op prestaties, schijfruimte, foutmeldingen en beveiligingsrisico's? Hoe vaak worden back-ups gemaakt en waar staan ze opgeslagen?

De vraag die het meeste zegt: wanneer is er voor het laatst een back-up van jouw omgeving teruggezet om te controleren of herstel werkt? Een back-up die nooit is getest, is vooral een aanname. Blijft het antwoord vaag, dan weet je genoeg.

Let ook op of je partner vooruitkijkt. Verouderde softwareversies, verlopen certificaten en servers die tegen hun grenzen aanlopen, komen voor een partij die actief beheert zelden als verrassing. Mijn vuistregel: hoor je eerder van een klant dat je certificaat is verlopen dan van je partner, dan wordt er niet actief beheerd.

Eigenaarschap begint als niemand de oorzaak kent

Bij losse leveranciers wordt de oorzaak van een storing al snel onderwerp van discussie. De hostingpartij wijst naar de applicatie, de ontwikkelaar naar een API en de leverancier van die API naar de configuratie. Jouw organisatie wacht ondertussen.

Een partner die ontwikkeling en infrastructuur samen beheert, kan sneller vaststellen waar het misgaat. Ook die partner neemt niet elke externe oorzaak weg. Wel is er dan iemand die de analyse coördineert, de juiste partijen erbij haalt en de voortgang bewaakt. Als je bedrijf elke dag op die systemen draait, is dat verschil groot.

In een offerte herken je eigenaarschap slecht. Je ziet het in de samenwerking. Er wordt doorgevraagd voordat er gebouwd wordt. Een risico wordt benoemd, ook als die boodschap ongemakkelijk is. En na een incident wordt de fout hersteld en daarna gekeken hoe herhaling te voorkomen is.

Het sterkste signaal vind ik een partner die zegt dat een verzoek technisch kan, maar bedrijfsmatig weinig oplevert. Die laat werk liggen om jou geld te besparen.

Leg daarna vast wat je kunt vastleggen: wie verantwoordelijk is voor hosting, releases, beveiligingsupdates, monitoring en het contact met externe leveranciers, welke systemen kritiek zijn en welke reactietijden daarbij horen. Spreek ook af wie binnen jouw organisatie de besluiten neemt. Hoe scherper dat op papier staat, hoe sneller er gehandeld wordt.

Ontwikkeling en hosting bij één partij onderbrengen heeft een prijs: je wordt afhankelijker van die partij. Die afhankelijkheid houd je beheersbaar met uitlegbare technische keuzes, goed geregelde toegang en kennis die ergens op papier staat in plaats van in één hoofd. Controleer vandaag of je zelf de inloggegevens hebt van je hosting, je domeinnaam en de plek waar je code staat.

Bij LJPc komen maatwerkontwikkeling, hosting en technisch beheer samen. Daardoor kan LJPc een applicatie of koppeling opleveren en verantwoordelijk blijven voor de omgeving waarin die elke dag moet presteren.

Goede support zegt wanneer de volgende update komt

Een algemeen ticketsysteem met lange wachttijden schiet tekort als klanten niet kunnen bestellen of je platform onbereikbaar is. Je wilt iemand spreken die weet welke systemen er draaien en hoe ze samenhangen.

Een harde reactietijd van vijf minuten zou ik als eis laten liggen. Complexe fouten vragen onderzoek, testen en soms overleg met externe leveranciers, en dat gaat niet sneller omdat het in een contract staat. Toets liever de communicatie. Je hoort snel wat er bekend is, welke actie loopt en wanneer de volgende update komt, in taal die je zelf niet hoeft te vertalen naar je bedrijfsvoering.

Stem je verwachtingen af op je bedrijfsritme. Een B2B-portaal vraagt iets anders dan een webshop met piekbelasting in de avond. Een uitgever kan niet wachten als het publiceren stokt, terwijl een SaaS-platform vooral leunt op constante beschikbaarheid en voorspelbare releases. Vraag naar de werkwijze bij incidenten en, als jouw bedrijf ook 's avonds draait, naar de bereikbaarheid buiten kantooruren.

Zit de fout in maatwerksoftware, dan moet degene die de melding aanneemt direct kunnen schakelen met degene die de code kent. Zijn hosting, beheer en ontwikkeling niet met elkaar verbonden, dan kost ook een klein probleem onnodig veel tijd.

Bouw voor de groei die je ziet aankomen

Dit punt staat achteraan omdat een partner die de eerste drie eisen haalt, meestal ook eerlijk is over wat je nodig hebt om te groeien. Over een jaar heb je misschien meer gebruikers, een extra verkoopkanaal of een handmatig proces dat geautomatiseerd moet worden. Daarvoor hoef je nu geen ingewikkeld enterpriseplatform neer te zetten. Wat je wel vraagt, is dat de keuzes van vandaag die groei niet blokkeren.

Een goede partner stelt daarom vragen die verder gaan dan je aanvraag:

• Welke data moet beschikbaar zijn?
• Welke andere systemen moeten koppelen?
• Waar zitten nu de handmatige handelingen?
• Welke pieken verwacht je, en wat gebeurt er als het aantal transacties verdubbelt?

De antwoorden bepalen of een eenvoudige integratie volstaat of dat een flexibelere architectuur verstandiger is.

Dezelfde nuchterheid geldt voor maatwerk. Standaardsoftware is een prima keuze als het proces algemeen is en je organisatie zich aan het pakket kan aanpassen. Maatwerk loont waar jouw onderscheid zit, bijvoorbeeld in de manier waarop je klanten bedient of gegevens verwerkt. Te veel maatwerk maakt beheer duurder dan nodig. Te veel standaard dwingt mensen tot omwegen, spreadsheets en dubbele invoer.

Soms is een kleine interne tool de beste oplossing. Soms volstaat een API-koppeling tussen bestaande systemen. En soms moet een kernapplicatie opnieuw worden opgebouwd, omdat repareren duurder wordt dan vernieuwen. Een test die ik graag doe: vraag een partner welk deel van je wens ze juist niet op maat zouden bouwen. Wie alles als maatwerk wil maken, heeft die afweging nog niet gemaakt.

Toets de eisen voor je technische partner vandaag

Je hoeft niet eerst al je techniek te vervangen om meer grip te krijgen. Kies het proces waarvan de gevolgen het grootst zijn als het stopt: bestellen, plannen, publiceren, klantcontact of gegevensuitwisseling. Schrijf op welke systemen daarbij horen, wie ze beheert en waar de afhankelijkheden zitten.

Leg dat overzicht voor aan je huidige partner, met deze vragen:

• Wanneer is een back-up van deze omgeving voor het laatst teruggezet?
• Wie coördineert als de oorzaak tussen twee leveranciers in ligt?
• Wie neemt de melding aan, en kent die persoon de code?

Krijg je snel een concreet antwoord, dan zit je goed. Moet je partner het eerst uitzoeken, dan heb je je eerste verbeterpunt te pakken.