Het deel dat echt sneller is.

Eer wie eer toekomt: het bouwen van een CPQ betekende vroeger maanden van ontwikkeling en een flinke begrotingspost voordat je iets te laten zien had. Nu kan er al een werkende demo zijn – inclusief optieregels, actuele prijzen en een offerte in PDF-formaat – nog voordat je ons weer belt. Dat neemt twee van de grootste bezwaren tegen zelf bouwen weg: de kosten vooraf en de tijd die het kost om een eerste versie te maken.

Om een idee te testen, is dat een echt voordeel. Als je wilt weten of een configurator je verkoopproces zou helpen voordat je een budget vastlegt, geeft een in het weekend gebouwde demo daar sneller antwoord op dan welk verkoopgesprek dan ook. Gebruik het op die manier en het verdient zijn geld terug.

Het deel dat niet sneller gaat.

Het weglaten van kosten en tijd uit de vergelijking neemt niet weg wat er daarna komt. Alle andere bezwaren tegen op maat gemaakte CPQ gelden nog steeds:

Er moet nog steeds iemand het systeem onderhouden. Als de persoon of het team dat het heeft gebouwd vertrekt, moet degene die het systeem overneemt het eerst reverse-engineeren en daarna ondersteunen.
Bugs moeten nog steeds onder druk worden verholpen. Een productieprobleem wacht niet tot iemand opnieuw heeft geleerd hoe de applicatie werkt.
De stack veroudert nog steeds. Frameworks moeten worden geüpgraded en de beveiliging moet worden bewaakt, of de oorspronkelijke code nu door een persoon of door AI is geschreven.
Integraties vereisen nog steeds echt technisch vakmanschap. Een CPQ dat communiceert met je ERP, CRM en PIM heeft gedocumenteerde, achterwaarts compatibele koppelingen nodig, geen eenmalig script.

Gartner komt tot dezelfde conclusie over eigendom: het vereenvoudigen van de manier waarop iets wordt gebouwd, vermindert niet de kosten om het te laten draaien. Een systeem houdt niet op een project te zijn zodra het wordt gelanceerd; het wordt een “bedrijfskritische, langdurige operationele capaciteit”. De werkzaamheden op het gebied van beveiliging, compliance en ondersteuning die volgen op de implementatie zijn volgens Gartner harde kosten in plaats van zachte kosten.

Er is hier ook een scherpere versie van het oude ‘zelf bouwen versus kopen’-argument. Zodra een zelfgebouwd systeem de bedrijfsvoering aanstuurt, ligt de macht bij degene die de interne werking ervan begrijpt: niet bij jou, en niet bij een leverancier. Leveranciersafhankelijkheid was altijd het risico waar mensen zich zorgen over maakten wanneer ze ervoor kozen om te kopen. Wat echter echt pijn doet, is de ‘lock-in’ van medewerkers: de dag dat de enige persoon die het systeem begrijpt om een loonsverhoging vraagt, waarvan hij weet dat je die niet kunt weigeren.

De vragen die in een demo worden overgeslagen.

Pas als je met de op gevoel geprogrammeerde demo aan de slag gaat, besef je hoeveel er niet mogelijk is. De hiaten komen zelden naar voren in de demo. Ze komen later aan het licht, in vragen die niemand op de eerste dag had bedacht:

Hoe komt deze offerte in het ERP terecht zodra deze is ondertekend?
Wat ziet een dealer als een andere dealer een andere korting bedingt?
Waar vindt het productieteam de stuklijst waarop de offerte is gebaseerd?
Welk reserveonderdeel past precies op deze machine, vier jaar nadat deze is geleverd?
Wie mag een prijs wijzigen en wie mag deze zien?
Wat gebeurt er met openstaande offertes als de technische afdeling een onderdeel vervangt?
Wie zet de systemen terug naar de oude stand als de wijziging van gisteren onjuist blijkt te zijn?

Dit zijn geen onbelangrijke hiaten. Neem bijvoorbeeld de kwestie van de dealerkorting: een configurator met Vibe-codering kan twee verschillende prijzen weergeven, maar kan nog niet garanderen dat dealer B nooit het bedrag van dealer A te zien krijgt, omdat daarvoor een echte machtigingslaag nodig is, niet alleen een inlogscherm. Of neem de kwestie van de reserveonderdelen: iemand moet deze vraag nog steeds correct beantwoorden, tien jaar nadat het product is geleverd, lang nadat het weekend waarin de demo werd gebouwd, al lang vergeten is.

Elk van deze kwesties is een subsysteem dat een op vibe-code gebaseerde CPQ nooit hoefde te bouwen: complexe prijslogica, machtigingen, een audittrail, integraties die de volgende upgrade overleven.

Waar Hive CPQ van pas komt.

Dit is geen argument tegen het gebruik van AI om sneller te bouwen. Het is een argument tegen het richten van AI op een leeg blad en dat dan een voltooid systeem noemen.

Wat een in een weekend gebouwde oplossing je niet kan bieden, is wat er al onder het platform schuilgaat: ISO 27001-certificering en jaarlijkse penetratietests, versiebeheer met rollback, en integraties die al zijn gebouwd en worden onderhouden voor de systemen die fabrikanten daadwerkelijk gebruiken.

Forrester-analist David Mooter verwacht dat dit de norm in de sector wordt: softwareleveranciers die zelf uitgroeien tot vibe-coding-platforms, die API’s aanbieden voor wat niet helemaal vanaf nul hoeft te worden gebouwd, en codeeragenten die het domein goed genoeg begrijpen om deze correct te gebruiken. Bij Hive is dat geen voorspelling, zo werkt het platform nu al.

Hive AI biedt je dezelfde snelheid die vibe-coding zo aantrekkelijk maakt, maar dan met ingebouwde veiligheidsmaatregelen. Beschrijf wat je nodig hebt, en de Modeler Agent zet dit om in werkende configuratielogica die controleerbaar blijft en pas wordt toegepast na jouw goedkeuring. Met de MCP van Hive kunnen AI-assistenten rechtstreeks binnen uw omgeving werken, onder uw bestaande machtigingen, waarbij voor elke belangrijke wijziging een momentopname wordt gemaakt.

Snel bouwen is niet het moeilijke deel. Het resultaat de komende tien jaar in eigen beheer houden, dat is het wel.

Wil je zien hoe snel AI-ondersteund modelleren werkt op een platform dat speciaal is gebouwd voor fabrikanten? Praat met een expert.

CPQ-software