Business management software: standaard of maatwerk?
Je organisatie groeit. Meer klanten, producten en processen. En ergens begint het te wringen: een export naar Excel, een extra document omdat een veld ontbreekt, een werkwijze die niemand meer precies kan uitleggen. Het pakket werkt nog steeds. Alleen het proces eromheen wordt steeds ingewikkelder. Wanneer is een standaardpakket dan niet meer genoeg? En bouw je iets ernaast, pas je het pakket aan of toch maar alles vervangen? Dat is het gesprek dat we bij Cube voeren zodra de eerste omwegen zichtbaar worden.
Wat belooft business management software?
Business management software, vaak afgekort tot BMS, bundelt de systemen waarmee je je organisatie bestuurt in één pakket: financiën, verkoop, voorraad, projecten, uren en rapportage, op één database en bij één leverancier. Partijen als Salesforce, Zoho One, NetSuite, Odoo en monday.com positioneren zich in dit veld. In Nederland kom je daarnaast AFAS en Exact tegen.
Waar ERP de administratieve ruggengraat vormt en een CRM de verkoopkant bedient, claimt een BMS de hele breedte. Het onderscheid is in de praktijk minder scherp dan in de brochures: veel pakketten die zich BMS noemen zijn een ERP met modules eromheen. Welke soorten bedrijfssoftware er bestaan en hoe ze zich tot elkaar verhouden, staat los uitgewerkt in de kennisbank. De belofte zelf is concreet: één inlog, één set gegevens, updates en beveiliging bij de leverancier, en licentiekosten per gebruiker per jaar die je vooraf kunt begroten. Voor een groot deel van de organisaties klopt die belofte gewoon. Maar de interessante vraag is niet wat een pakket allemaal kan, maar: waar houdt het op?
Wanneer werkt één pakket wél?
Een standaardpakket is de betere keuze zolang je processen niet wezenlijk afwijken van wat de markt normaal vindt. Vier kenmerken voorspellen dat het goed blijft gaan: een standaardproces, weinig koppelingen met andere systemen, een overzichtelijk aantal gebruikers en geen afwijkende productstructuur.
Dat eerste kenmerk weegt het zwaarst. Loopt je orderproces van offerte naar order naar levering naar factuur, zonder tussenstappen die alleen bij jou bestaan, dan koop je met een pakket de ervaring van duizenden implementaties mee. Je hoeft niet te bedenken hoe een creditnota werkt. Hetzelfde geldt voor koppelingen: twee systemen die gegevens delen is te overzien, vijf systemen is een landschap dat onderhoud vraagt.
Ook de kostenkant pleit vaak voor het pakket, en dat mag eerlijk gezegd worden. Licenties per gebruiker per jaar zijn voorspelbaar en schalen mee met je organisatie. Ontwikkelkosten zitten vooraf en zijn moeilijker te begroten: je betaalt eerst en gebruikt daarna. Daar komt bij dat mensen die een bekend pakket kennen makkelijker te vinden zijn dan mensen die jouw eigen systeem kennen. Gelden drie van deze vier kenmerken, dan is de eerlijke conclusie dat je geen maatwerk nodig hebt.
Eén signaal is geen probleem. Drie wel.
Waar loopt het vast? Vier grenzen uit de praktijk.
Proces in een omweg
Het duidelijkste signaal is de export. Iemand haalt elke maandagochtend een lijst uit het pakket, bewerkt die in Excel en zet het resultaat ergens anders weer in. Dat werkt, want het werkt al jaren. Alleen staat het proces daarmee buiten het systeem, inclusief de fouten die niemand ziet.
De tweede variant is het veld dat niet bestaat. Een order heeft een kenmerk dat het pakket niet kent, dus belandt het in het opmerkingenveld. Handig voor de collega die het leest, waardeloos voor elke rapportage daarna. Je herkent het patroon aan de inwerkperiode: als een nieuwe collega in week één leert hoe jullie om het systeem heen werken, is de omweg onderdeel van het proces geworden. Deze kosten zitten in uren, niet in licenties. Daardoor staan ze op geen enkele factuur en komen ze in geen enkele evaluatie terug.
Geen toegang
Dat een pakket een API heeft, zegt op zichzelf niets. Wat telt is welke gegevens die API vrijgeeft, hoe vaak je ze mag opvragen, of je ook mag terugschrijven en of die toegang in jouw abonnement zit. Soms wordt een koppeling per stuk afgerekend, soms zit API-toegang alleen in een duurder pakket, en soms is er geen testomgeving en mag je oefenen in de productieadministratie.
Dit is het moment waarop data-eigenaarschap van een abstract begrip een factuur wordt. Welke vragen je hierover stelt voordat de scope vastligt, staat uitgewerkt in het artikel over een API-koppeling.
Dezelfde gegevens
Prijzen in het pakket en in de webshop. Artikelteksten in twee systemen. Relatiegegevens in het pakket en in de mailtool. Zodra dezelfde gegevens op twee plekken worden onderhouden, ontstaat de vraag welke van de twee klopt, en die vraag wordt meestal beantwoord door degene die het hardst roept.
Het gevolg zie je terug in de rapportage: twee overzichten met verschillende getallen en een vergadering over welk getal de waarheid is. De oplossing is geen extra export maar een afspraak per gegevenssoort over welk systeem leidend is. Dat principe heet single source of truth en het is goedkoper om het vooraf vast te leggen dan achteraf te herstellen.
Leverancier bepaalt
Een pakket heeft een roadmap, en die roadmap is niet van jou. Staat jouw wens er niet op, dan kun je wachten of eromheen bouwen. Datzelfde geldt voor de techniek die je nodig hebt om te koppelen. AFAS stuurt bijvoorbeeld geen melding zodra een artikel of een prijs verandert: in Profit bestaan webhooks alleen op dossieritems en workflows, en voor de rest houd je gegevens actueel door periodiek op te vragen wat er gewijzigd is. Dat schrijft AFAS zelf in het eigen Help Center. Het is geen fout van de leverancier, maar het bepaalt wel wat jij kunt bouwen en hoe vers je gegevens zijn. Hoe langer dit duurt, hoe meer een pakket gaat lijken op legacy software: cruciaal voor de dagelijkse gang van zaken en tegelijk een rem op wat je wilt. Ook als de leverancier de software keurig onderhoudt.
Hoe dat er in de praktijk uitziet.
Bij Nou, ontstaan uit de samenvoeging van Canon Business Center Noordoost, OSN Nederland en Repromat, is AFAS het centrale ERP voor relatiebeheer, bestellingen, contracten en financiële administratie. Toen daar een webshop bij kwam, liep AFAS tegen de grenzen van de productstructuur aan. Nou werkt namelijk met eigen driecijferige categoriecodes, zoals 100 voor papier en 111 voor gecoat papier. In plaats van AFAS aan te passen, is die logica ondergebracht in een laag ernaast: het Data Management Platform. Zo kreeg de webshop de juiste structuur, zonder AFAS te verbouwen.
Synchroniseren zonder meldingen.
Het tweede punt was de uitwisseling zelf. Omdat er geen meldingen uit AFAS komen op artikel- en prijsgegevens, draait er een volledige synchronisatie die tweemaal per dag alles ophaalt, plus een gedeeltelijke synchronisatie die elke vijf tot tien minuten alleen de wijzigingen verwerkt. Ophalen en terugschrijven gaat via de GetConnector en de UpdateConnector van AFAS, zodat nieuwe bestellingen automatisch in het ERP landen.
Het resultaat: AFAS blijft de plek waar de bedrijfsgegevens staan, de webshop volgt, en er kwam geen tweede abonnement op een e-commerceplatform bij. Het volledige technische verhaal staat in de blog over het ontwerpen van een webshop op AFAS, het bredere traject in de case van Nou. Daar hoort een nuance bij die in diezelfde blog ook staat: voor organisaties die snel willen opschalen en weinig afwijkende logica hebben, is een standaard e-commerceplatform juist de kortste route. De keuze volgt uit het bestaande landschap, niet uit een principe.
Alles vervangen, of er iets naast bouwen?
Drie routes om iets naast je pakket te bouwen.
Maatwerk in het pakket zelf.
Een extra veld, een aangepast rapport of een afwijkende goedkeuringsstap bouw je binnen het pakket. Snel geregeld en alles blijft op één plek. Bij elke upgrade betaal je die keuze terug, want wat erin zit moet opnieuw getest worden.
Een applicatie ernaast met een koppeling.
Je bouwt het afwijkende proces als losse applicatie en verbindt die via een koppeling met het pakket. Het pakket blijft standaard en dus upgradebaar, en het tempo van de nieuwe applicatie bepaal je voortaan zelf.
Een integratielaag ertussen.
Delen drie of meer systemen gegevens, dan wordt een reeks losse koppelingen onhoudbaar. Eén laag ertussen bepaalt welke gegevens waarheen gaan. Meer investering vooraf, aanzienlijk minder onderhoud daarna.
Hoe maak je deze keuze zonder je meteen vast te leggen?
Begin bij het proces, niet bij een pakketvergelijking. Twee weken bijhouden waar mensen om het systeem heen werken levert meer inzicht op dan drie demo's.
Schrijf per proces op welke omweg er bestaat en hoeveel tijd die kost. Bepaal daarna welke processen onderscheidend zijn, want alleen daar verdient maatwerk zichzelf terug; de rest moet vooral gewoon werken en blijft prima in het pakket. Stel je leverancier vervolgens vier vragen: welke gegevens geeft de API vrij, mag je terugschrijven, wat is het maximale aantal aanvragen en zit die toegang in je huidige abonnement. Die antwoorden bepalen meer over de haalbaarheid dan welk technisch ontwerp dan ook.
Reken daarna over vijf jaar in plaats van over één: licenties per gebruiker, kosten per koppeling of module, en de uren die nu in de omwegen zitten. Dat laatste getal ontbreekt bijna altijd, terwijl het de reden is dat de vergelijking scheef staat. Begin tot slot met één proces. Eén werkend onderdeel naast je pakket vertelt je binnen een paar maanden meer dan een businesscase van vijftig pagina's.
Weet je niet waar je staat, dan geeft een kwaliteitsscan van je bestaande software een onafhankelijk beeld voordat je iets vervangt of bijbouwt. Twijfel je of jouw situatie tegen de grens aanloopt: leg hem voor, dan kijken we samen waar de omwegen zitten en wat ze kosten.
Loopt jouw bedrijfssoftware pakket tegen zijn grens aan?
Leg je situatie voor. We kijken samen waar de omwegen zitten, wat ze kosten en wat er nodig is om je proces weer werkbaar te maken.
Dit sluit mooi aan...
Het ontwerpen van een webshop zonder gebruik van standaard E-commerce systemen met AFAS.
Wat is legacy software? Betekenis, risico's en oplossingen.
Hoe maak je digitale impact met een verouderd ERP-systeem?
Vragen over business management software? Geen probleem.
Business management software is een pakket dat meerdere bedrijfsprocessen in één systeem bundelt: financiën, verkoop, voorraad, projecten, uren en rapportage. Alles draait op één database bij één leverancier. De term overlapt sterk met ERP; veel pakketten die zich BMS noemen zijn een ERP met extra modules.
Het verschil zit vooral in het moment. Licenties per gebruiker per jaar zijn voorspelbaar en lopen door zolang je het pakket gebruikt. Maatwerk vraagt een investering vooraf en daarna onderhoud. Vergelijk daarom over meerdere jaren, en reken de uren mee die nu in handmatige omwegen gaan zitten.
Ja, en dat is de meest gekozen route. Het pakket blijft de administratieve waarheid en de nieuwe functionaliteit komt ernaast, verbonden via een koppeling. Zo blijft het pakket standaard en dus upgradebaar, terwijl je het afwijkende proces bouwt zoals jouw organisatie werkt.
Aan vier signalen: processen die via exports om het systeem heen lopen, gegevens die je er niet uit krijgt, dezelfde gegevens die op twee plekken worden bijgehouden, en wensen die wachten op de roadmap van de leverancier. Eén signaal is normaal, drie tegelijk niet.
Dat hangt af van de scope, de omvang van je organisatie, het type oplossing en de moeilijkheidsgraad. Een bedrag noemen zonder die context helpt je niet verder. In het eerste gesprek rekenen we het samen door en laten we zien wat welke keuze kost, inclusief migratie en het tijdelijk dubbel draaien van systemen.