Eigen beheer of technisch partnerschap: wie houdt het draaiende?

De ontwikkelaar die je klantportaal en de koppelingen bouwde, heeft opgezegd. In de weken van de overdracht blijkt hoeveel er alleen in diens hoofd zit, zoals hoe een release live gaat en waar de back-ups staan. Op dat moment wordt de vraag eigen beheer of technisch partnerschap opeens heel concreet.

Bij veel bedrijven groeit de techniek ongemerkt. De website kreeg een klantportaal, systemen moesten gegevens uitwisselen en medewerkers kregen interne tools. Ergens onderweg werd die techniek een voorwaarde om omzet te draaien en klanten te helpen, en de vraag wie ervoor verantwoordelijk is, groeide mee.

Eigen beheer of technisch partnerschap: tel de taken

Eigen beheer klinkt als een vacature. Je neemt een ontwikkelaar aan en de kennis zit in huis. Zet daar het werk naast dat bij een draaiende applicatie hoort:

• architectuur
• security
• testen
• releases
• cloud- of serverbeheer
• monitoring
• incidenten
• documentatie

Een goede ontwikkelaar dekt daar een deel van. Wie sterk bouwt, is daarmee nog geen systeembeheerder, DevOps-specialist of security-expert.

Zet achter elke taak een naam. Staat achter de helft dezelfde naam, dan weet je hoe die overdrachtsweken eruit gaan zien.

Kijk in je businesscase verder dan het salaris. Werving, inwerken, kennisoverdracht, tooling en vervanging bij ziekte kosten geld, net als de uren beheerwerk die nooit op de roadmap verschijnen.

Intern bouwen loont als software je product is

Een eigen team raden we vooral aan als software je primaire product is en je continu nieuwe functionaliteit ontwikkelt. Een SaaS-bedrijf met een duidelijke roadmap, voldoende financiering en ruimte voor meerdere gespecialiseerde rollen heeft veel aan de korte lijn tussen de business en de mensen die bouwen. Voor snelle productbeslissingen kan dat een belangrijk voordeel zijn.

Zeer bedrijfsspecifieke processen zijn een tweede, zwakker argument. Een externe partij kan die kennis prima opbouwen. Voor snelle productkeuzes helpt het als iemand die processen dagelijks van dichtbij meemaakt.

Wat wij zouden overslaan, is het kleine team dat de hosting, de beveiligingsupdates, de performance en de bereikbaarheid buiten kantoortijd er ook bij doet. Dan hangt je hele digitale operatie aan een paar mensen, en dat merk je pas als een van hen er niet is.

Bouwer en hoster in één hand

Voor bedrijven waar digitale systemen bedrijfskritisch zijn, maar die geen compleet techbedrijf willen worden, ligt een partner meer voor de hand. Een e-commercepartij wil dat orders blijven lopen. Een publisher wil capaciteit bij piekverkeer. Een bureau wil projecten opleveren zonder voor elk specialisme een losse leverancier aan te sturen, en een platform wil doorgroeien terwijl de infrastructuur meegroeit.

Het verschil zie je op het moment dat er iets stilvalt. De bouwer wijst naar de hoster, de hoster wijst terug, en intussen blijft het probleem bestaan. Een partij die zowel de applicatie en de integraties als de infrastructuur kent, zoekt de oorzaak op één plek en weet ook dat het haar probleem is.

Daarom bouwen en hosten we bij LJPc onder één dak in Assen. Bij elke applicatie of koppeling die we opleveren hoort de vraag hoe die daarna stabiel blijft draaien en wie meekijkt als je groeit.

De grip houd je zelf. Een goede partner laat zien wat er draait en welke risico's er spelen. Voor goede regie moet je weten welke afspraken gelden, hoe incidenten worden opgepakt en wie beslist.

Geef je partner de context van je bedrijf

Een partnerschap loopt vast als je de techniek op afstand zet en pas belt wanneer er iets kapot is. Je partner wordt dan een ticketfabriek die oplost wat je meldt, zonder te weten wat het voor je bedrijf betekent.

Vraag je om een API-koppeling, vertel dan ook welk proces stopt als de koppeling faalt, welke gegevens foutloos moeten zijn en wanneer de druk het hoogst is. Met die context kan een partner de monitoring en de fallback afstemmen op jouw drukste momenten.

Andersom mag je van een partner openheid verwachten over afhankelijkheden en onderhoud. Een snelle oplossing die over zes maanden lastig te beheren is, kan uiteindelijk duurder uitpakken dan een iets betere technische basis nu.

Vier vragen die de keuze beslissen

Alles intern of alles extern zijn de uitersten. Loop eerst deze vier vragen langs, het liefst samen met de mensen die nu de storingen oplossen.

1. Hoe kritisch is stilstand? Raakt een storing direct je omzet, je dienstverlening of je reputatie, dan heb je meer nodig dan losse ontwikkelcapaciteit. Dan tellen monitoring, bereikbaarheid, back-ups en een duidelijke escalatie net zo zwaar.
2. Hoe voorspelbaar is het werk? Een vaste stroom productontwikkeling kan een intern team rechtvaardigen. Wisselende projecten of een specialistisch vraagstuk vang je vaak efficiënter op via een partner.
3. Welke kennis moet echt in huis blijven? Proceskennis, productstrategie en beslissingsbevoegdheid horen meestal intern. Diepgaande kennis van hosting of complexe integraties hoeft dat niet altijd te zijn.
4. Wie lost het op als het vrijdagmiddag misgaat? Het gaat om wie de storing dan oplost, ook als iemand anders formeel eigenaar is. Kun je hier geen naam invullen, dan is je technische organisatie nog niet goed ingericht.

Die laatste vraag weegt voor ons het zwaarst, omdat de eerste drie over de inrichting gaan en deze laat zien of die inrichting werkt.

Houd de regie intern, besteed het beheer uit

Moeten we één model aanraden voor een bedrijf waar software het product niet is, dan kiezen we voor een mix. Houd een producteigenaar of digitale lead in huis, eventueel met wat eigen ontwikkelcapaciteit, en werk daarnaast met een vaste technische partner. De businesskennis blijft dichtbij, en voor specialistische kennis en continuïteit heb je iemand die je systemen al kent.

Wij zijn zelf zo'n partner, dus lees dit advies gerust met die bril. Wij denken dat de takenlijst bovenaan dit artikel voor veel bedrijven deze kant op wijst.

De afweging zit in de afstand. Een partner zit niet dagelijks bij jouw overleggen, dus iemand intern moet de productbeslissingen nemen en de prioriteiten bewaken. Dit model werkt pas als de rollen vooraf vastliggen. Jij bepaalt wat voorgaat en welk resultaat nodig is. De partner adviseert over haalbaarheid, bouwt, beheert en meldt risico's. Grotere veranderingen plan je samen, ruim voordat er iets misgaat.

Je eigen mensen blussen daardoor ook minder brandjes. Routinebeheer en releases liggen bij de partner, en jouw team houdt tijd over voor productontwikkeling en het verbeteren van het bedrijf.

Leg vast wat er bij een storing gebeurt

Vergelijk offertes op meer dan tarieven en ontwikkeluren, en kijk naar wat er staat over responstijden, contactpersonen, onderhoudsvensters, het eigenaarschap van code en infrastructuur, documentatie en de manier waarop wijzigingen live gaan. Dat zijn de afspraken die je op een slechte dag openslaat.

Stel tijdens de selectie ook een inhoudelijke vraag. Krijg je iemand aan de lijn die begrijpt wat er speelt, of verdwijnt je vraag in lagen accountmanagement en tickets? Hoe dat gesprek loopt, zegt veel over hoe ze een storing aanpakken.

Let ook op de momenten waarop een partner nee zegt. Een betrouwbare partij benoemt het als een wens risico's oplevert, als een bestaande oplossing eerst opgeruimd moet worden of als investeren in stabiliteit nu verstandiger is dan nieuwe functionaliteit.

Neem de lijst van acht taken uit het begin van dit artikel deze week met je team door en zet er namen achter, inclusief de naam van wie je vrijdagmiddag belt. Waar een naam ontbreekt of steeds dezelfde naam terugkomt, zie je wat je intern wilt opbouwen en wat je bij een partner neerlegt.