Blog
Tags:
Dit is het einde van je wendbaarheid IT’er
Steeds vaker zie ik bedrijven een opmerkelijke keuze maken: niet de software wordt aangepast aan de manier waarop zij werken, maar de manier van werken wordt aangepast aan de software.
De redenering klinkt logisch. Grappig bijna. Je koopt standaard SaaS, je kiest “best practices”, je voorkomt maatwerk en je bent sneller live. En ja, na twintig jaar van ERP-spookverhalen is die reflex te begrijpen. Projecten die jaren uitlopen omdat het ERP precies moet doen wat jouw proces doet. Maatwerk dat bij iedere nieuwe release opnieuw stukgaat. Performance die langzaam wegzakt omdat jouw extra laagjes nergens in het originele ontwerp zijn meegenomen. En afhankelijkheid van die ene developer die “weet hoe het echt zit”.
Dus draaien organisaties het om: “Als we ons proces nou gewoon laten passen op het pakket, zijn we van het gedoe af.”
Daar zit deze heel ongemakkelijke vraag onder: welk probleem ben je nu eigenlijk aan het oplossen?
Als je maatwerk het risico was, verplaats je dat risico dan niet? In plaats van afhankelijk te zijn van een programmeur, word je afhankelijk van een leverancier. Van hun roadmap. Hun prijsmodel. Hun integraties. Hun definities van “hoe het hoort”. En als jouw onderscheidende manier van werken precies dáár zit - in je uitzonderingen, je snelheid, je klantafspraken – dan lever je een stuk concurrentiekracht in voor rust in IT. Pfoe!
Kijk, op korte termijn kan die ruil aantrekkelijk zijn. Minder complexiteit. Sneller implementeren. Minder onderhoud. Minder incidenten door eigen knutselwerk.
Maar op de langere termijn komt de echte test: hoe wendbaar blijf je als wetgeving verandert, je markt verschuift, of je businessmodel kantelt? Kun je dan nog bewegen, of zit je bedrijf vast in de logica van een pakket? Waarschijnlijk dat laatste.
In dit blog kijk ik naar de problemen die organisaties deze kant op duwen, wat ze ermee proberen te winnen en welke alternatieven er zijn. Zonder terug te vallen in “alles op maat” of “slik de standaard maar”.
Bloat verkoopt. En jij betaalt de wachttijd.
De software van vandaag is verrassend vaak… gewoon niet goed.
Niet “een beetje rommelig”. Maar écht slecht: traag, fragiel en vol storingen die pas na uren zichtbaar worden. En als jouw mensen elke dag moeten wachten op schermen, exports, synchronisaties en “even opnieuw inloggen”, dan komt er een moment dat iemand zegt: “Klaar ermee, we gaan dit NU fixen”. En dan begint de ellende.
Alleen: dan begint de zoektocht … naar de verkeerde boosdoener.
Want waarom is software zo vaak ondermaats?
Reden 1: De snelheid van veranderen: “shippen” is belangrijker dan “kloppen”
De wereld schuift sneller dan je releasekalender. Wat vandaag “state of the art” is, voelt morgen al als legacy. Klantverwachtingen veranderen. Wetgeving verandert. Security verandert per kwartaal (soms per week). En dus moet software mee - sneller dan ooit.
Alleen: snelheid heeft een prijs. Niet omdat engineers lui zijn, maar omdat kwaliteit aan tijd gekoppeld is. Hoge kwaliteit = veel tijd. Weinig tijd = lage kwaliteit. Ga maar na, testen, threat modeling, performance-budgetten, fatsoenlijke release-cadans, terugdraaiplannen, documentatie, refactoring… dat zijn geen “extra’s”. Dat is de fundering. En precies die fundering wordt als eerste overgeslagen wanneer de druk erop staat.
Dus gaan teams rennen. Features erin. Hotfixes erachteraan. Nog een integratie. Nog een uitzondering. En voor je het weet is “het werkt” de norm en “het werkt goed” een luxe.
Kun je dat voorkomen? Ja. Maar dat is niet gratis. Dan moet je structureel investeren in engineering discipline: automated testing, observability, duidelijke architectuurgrenzen, een backlog die óók technische schuld afbetaalt en het lef om soms nee te zeggen tegen “even snel”.
Als je dat niet doet, is “sneller aanpassen” geen strategie. Het is een versnellingspedaal richting fragiele software. En maatwerk dat steeds sneller veroudert.
Reden 2: Gebrek aan kennis (en tijd om het goed te doen)
Er is al jaren schaarste aan architecten, goede engineers, testers en performance-specialisten. Gemiddeld talent is al lastig; echte sterspelers zijn zeldzaam. Gevolg: teams bouwen door, maar ze bouwen niet af. Refactoren, testen, hardenen en meten zijn de eerste dingen die sneuvelen wanneer “de business” iets nieuws wil.
En dan komt de nieuwe hype: “vibe coding”. Krijg ik serieus hoofd- en buikpijn van. Leuk voor prototypes. Totaal riskant als je productie-omgevingen voedt met code die vooral kopieert wat het het vaakst ziet: middelmaat. Middelmaat schaalt uitstekend. Kwaliteit absoluut niet.
Reden 3: Maatwerk zonder begrip van het hart van het systeem
Veel maatwerkbouwers kennen het pakket waar ze op uitbreiden niet diep genoeg. Ze kennen de API, maar niet de interne dynamiek. Ze optimaliseren functionaliteit (“het werkt”), maar niet kwaliteit (“het blijft werken als het druk wordt”). Performance en security worden bijzaak, tot ze de hoofdzaak worden met de problemen die ze veroorzaken.
Resultaat: extra lagen die het systeem zwaarder maken, upgrades die extra frustreren en incidenten die het allemaal veel duurder maken. Je krijgt een applicatie die precies doet wat je vroeg en … precies traag wordt op de plekken die je niet in je requirements had gezet. Oeps ..
Reden 4: Vraag naar bloat: uiterlijk verkoopt, frictie niet
Gebruikers zien iconen, kleuren, nieuwe menu’s. Ze zien geen efficiëntere query’s, minder I/O, betere caching. Leveranciers bouwen dus wat zichtbaar is. Windows 11 is een handig voorbeeld: Microsoft zet stevig in op “modern UX”, terwijl er door de jaren heen regelmatig kritiek is op bloat en prestaties (zeker op oudere hardware). En zelfs performance-claims blijken soms vooral hardware-vergelijkingen te zijn, niet “Windows 11 is per definitie sneller”.
Reden 5: Geen harde 80/20 discipline
Een mooi UI is waardevol. Maar als je met 20% performanceverlies 80% “mooier” krijgt, stop je daar. Anders eindig je met een glanzende motorkap op een motor die warmloopt.
En precies daar wordt maatwerk fataal: het stapelt zich op een al te zware basis. Slechte software is vervelend. Slecht maatwerk maakt het structureel.
Je ruilt maatwerk in voor afhankelijkheid
Als je je bedrijfsprocessen laat aansluiten op de werkwijze van je software, los je één ding meteen op: je hebt minder (of geen) gedoe meer met slecht functionerend maatwerk. Upgrades gaan soepeler. Je performance blijft voorspelbaarder. En je hoeft niet bij elke nieuwe versie te hopen dat “die ene uitbreiding” het nog doet.
Dat is de winst.
Maar je koopt er ook nieuwe risico’s voor terug. En die zijn vaak minder zichtbaar. Tot het misgaat. En mis gaat het, ik zie dat bij tal van onze klanten keer op keer gebeuren. Hier zijn de belangrijkste risico’s:
Wendbaarheid: hun tempo wordt jouw tempo
De wereld verandert snel. Wetgeving, factuurvereisten, security-eisen, nieuwe markten, nieuwe klantvoorwaarden. Als je processen in het pakket passen, ben je afhankelijk van de leverancier om op tijd mee te bewegen. Ik heb het meegemaakt: een klant kon per 1 januari niet naar bepaalde landen factureren omdat verplichte factuurvoorschriften nog niet in de software zaten. AU. Dat is geen “IT-probleem”. Dat is keiharde cashflow. En reputatie.
Verplicht meebewegen: verandering zonder businesscase
Als de leverancier besluit dat “de nieuwe manier” slimmer is, mag jij opnieuw inrichten. Soms omdat een grotere klant het eist. Soms omdat wetgeving in hún land verschuift. Soms omdat iemand een briljant architectuuridee had. Wat de reden ook is: jij moet je operatie aanpassen, processen herschrijven, mensen bijscholen en uitzonderingen opnieuw uitvinden. Dat kost geld, tijd en focus. En het levert zelden direct omzet op, alleen maar gedoe.
Afhankelijkheid: prijs, koers en eigenaarschap
Prijswijzigingen, bundels die ineens “moeten”, licentiemodellen die draaien van voorspelbaar naar variabel; je hebt het uiteindelijk niet meer in de hand. En als eigenaarschap of strategie verandert, verandert jouw risicoprofiel mee: soevereiniteit, datalocatie, support, roadmap. Soms klein. Vaker bedrijf kritisch.
Verdamping van onderscheid: jouw ‘speciale saus’ wordt standaard
Veel organisaties zijn niet uniek in hun organigram, maar wel in hoe ze leveren: doorlooptijd, uitzonderingen, servicebeloftes, ketenafspraken. Als je die unieke wijze van leveren inruilt voor “hoe het pakket het wil”, lever je vaak concurrentiekracht in voor schijnbare rust. Dat kan een prima keuze zijn, maar noem het dan ook zo.
De kern is simpel: je ruilt het risico van maatwerk in voor het risico van afhankelijkheid. Maak die afweging expliciet. En toets ‘m op de momenten die pijn doen: groei, nieuwe wetgeving, prijsstijgingen en koerswijzigingen.
Voordat je de keuze maakt: laat mij 30 minuten meekijken
Vaak is de oplossing voor complexiteit simpeler dan het lijkt.
Het probleem zelf voelt al complex. Veel afhankelijkheden. Nog meer meningen. Het al aanwezige “dat kan nou eenmaal niet”.
Het goede nieuws is dit: in de praktijk is de oplossing meestal verrassend simpel. Als je de ruis weghaalt en alleen naar de feiten kijkt.
Sciante haalt al ruim 15 jaar snel en kostenefficiënt de angel uit schijnbaar onoplosbare IT-problemen. We pakken precies die situaties aan waar teams op vastlopen, waar iedereen perplex van is en waar de business ondertussen doorbetaalt.
In slechts 1 tot 2 weken brengen we de blokkerende issues boven tafel die anderen ontgaan. Dat is onze kracht. Niet met dikke rapporten, maar met harde metingen en een korte, heldere lijst: dit remt je af, dit kost je geld, dit moet eerst.
Dus voordat je besluit om je processen te verbuigen naar een leverancier (en je autonomie in te ruilen voor “rust”), kijk ik graag met je mee.
Dat gaat snel. En … het is kosteloos.
Dan weet je snel of het opgeven van autonomie zin heeft… of dat je vooral een verkeerd probleem aan het oplossen bent.