Beschrijf het ontbrekende gedrag.
“We willen het systeem aanpassen” kan veel betekenen. Moet een planner een extra kenmerk zien, een nieuwe goedkeuring uitvoeren of een andere beslissing over beschikbaarheid nemen? Beschrijf eerst de handeling en de gewenste uitkomst. Daarmee voorkom je dat een schermwijziging wordt gebouwd terwijl de onderliggende regel hetzelfde blijft.
Een fictief voorbeeld: een magazijn wil goederen van meerdere eigenaren op dezelfde locatie bewaren. Een extra veld “eigenaar” kan de registratie uitbreiden. Maar als reserveren, picken, tellen en rapporteren nog steeds op de gezamenlijke hoeveelheid werken, is het proces niet opgelost. De eigenaar moet onderdeel zijn van alle beslissingen waarvoor dat onderscheid relevant is.
Neem ook een correctie en uitzondering mee. Wat gebeurt er als de verkeerde eigenaar is gekozen of een retour binnenkomt zonder herkenbare opdracht? De aanpassing moet in de hele werkroute kloppen.
Vier vormen van aanpassen, met verschillende gevolgen.
| Vorm | Wat verander je? | Wat onderzoek je? |
|---|---|---|
| Configuratie | Bestaande instellingen, rollen, workflows of toegestane waarden. | Ondersteunt het pakket de gewenste regel werkelijk, ook bij uitzonderingen? |
| Ondersteunde uitbreiding | Eigen velden, modules of code via de daarvoor bedoelde uitbreidingsmogelijkheden. | Welke mogelijkheden zijn gedocumenteerd en hoe blijven updates testbaar? |
| Eigen toepassing naast het pakket | Een afgebakend proces in eigen software, verbonden via interfaces. | Wie beheert de gegevens en welke bewerkingen biedt de pakket-API? |
| Aanpassing van de pakketkern | Bestaande interne code of opslagstructuur van het pakket. | Is dit toegestaan en ondersteund, en wie verwerkt conflicten bij wijzigingen? |
Welke vormen mogelijk zijn, verschilt per product, uitvoering en overeenkomst. Een extra module kopen, een extensie laten bouwen en eigen software koppelen zijn verschillende opdrachten. Laat de gekozen route aantonen met jouw proces; de term “aanpasbaar” is daarvoor te algemeen.
Het bestaan van een API betekent bovendien niet dat iedere functie van het pakket beschikbaar is. Controleer welke gegevens en acties toegankelijk zijn, met welke rechten en eventuele gebruiksgrenzen. Een eigen scherm kan alleen doen wat de achterliggende verwerking of een bewust afgebakend eigen onderdeel ondersteunt.
Een pakketuitbreiding blijft verbonden aan het pakket.
Een uitbreiding kan goed passen wanneer de kern van het pakket jouw proces ondersteunt en één afgebakende mogelijkheid ontbreekt. Je behoudt dan de bestaande gebruikersomgeving en sluit aan op de functies die al werken. Het ontwikkelwerk moet wel binnen de ondersteunde grenzen blijven.
Spreek af wie na een pakketupdate controleert of de uitbreiding nog goed werkt. Test de bedoelde handeling, rechten, rapportages en gekoppelde processen. Ook een ondersteunde uitbreiding blijft software die onderhouden moet worden. Vraag welke testomgeving beschikbaar is en hoe wijzigingen van de leverancier vooraf kunnen worden beoordeeld.
Een wijziging rechtstreeks in interne tabellen of code kan afhankelijkheden creëren die bij een update opnieuw moeten worden uitgezocht. Trek daaruit geen algemene conclusie over ieder pakket; onderzoek de concrete ondersteuning en onderhoudsroute. Juist dat verschil hoort thuis in de vergelijking van voorstellen.
Geef een eigen toepassing een duidelijke verantwoordelijkheid.
Een eigen scannerapp, portaal of planningsmodule kan een passende oplossing zijn wanneer het pakket bruikbare gegevens en bewerkingen beschikbaar stelt. Het maatwerk ondersteunt dan een herkenbare taak met eigen bediening en procesregels. Het pakket behoudt de verantwoordelijkheid die je eraan toekent.
Bepaal bijvoorbeeld of de eigen app alleen een ontvangst laat boeken in het WMS, of zelf de ontvangst en voorraad gaat beheren. In het tweede geval bouw je een eigen operationeel onderdeel en moeten de bestaande reserveringen en rapportages daarop aansluiten. Die keuze hoort expliciet in het ontwerp.
Leg vertaling van pakketvelden en foutmeldingen in een afgebakende koppeling vast. Houd de regels van jouw proces herkenbaar in de eigen toepassing. Dan is bij een leverancierswijziging duidelijk wat alleen een technische vertaling is en wat de werking van je bedrijf raakt. Lees verder over pakketten en eigen software verbinden.
Wanneer wordt aanpassen ingewikkelder dan zelf bouwen?
Onderzoek een eigen systeem nadrukkelijk als de belangrijkste bedrijfsregels op meerdere plekken moeten worden omzeild. Bijvoorbeeld wanneer medewerkers fictieve locaties gebruiken om statussen te bewaren, orders kunstmatig splitsen of besluiten buiten het pakket nemen en de uitkomst later terugboeken. Zulke oplossingen kunnen een tijdelijke reden hebben, maar verdienen een bewuste herbeoordeling.
Maak een overzicht van de gewenste veranderingen. Gaat het vooral om de kern van orders, voorraad of planning, dan kan een volledig eigen bedrijfssysteem de gewenste samenhang direct ondersteunen. Vergelijk dat met alle pakketuitbreidingen, koppelingen en blijvend handwerk die anders nodig zijn.
Neem daarbij dezelfde gebruiksperiode en dezelfde taken. Het aantal al betaalde licenties vertelt niet hoeveel werk de volgende verandering vraagt. Bestaande investeringen kunnen waarde houden, bijvoorbeeld in gegevens of goed werkende administratie, terwijl het operationele proces een nieuwe plek krijgt.
Toets de aanpassing aan een echte opdracht.
Laat vóór de keuze de normale route en een lastige uitzondering uitwerken. Welke informatie komt erbij, welke beslissing verandert en wat merkt een gebruiker daarvan? Spreek ook af hoe je vaststelt dat de aanpassing voldoende werkt. Een ingevuld extra veld is geen acceptatiecriterium voor correcte voorraadtoewijzing.
- Welke procesregels blijven in het pakket en welke komen in eigen code?
- Welke koppelingen en historische gegevens worden geraakt?
- Wie test na een update van het pakket of de uitbreiding?
- Hoe worden fouten zichtbaar en hoe kan iemand herstellen?
- Hoe neem je gegevens en eigen ontwikkeling mee bij een latere overstap?
De kostengids helpt om bouw, invoering en beheer op dezelfde basis te ramen. De vergelijking met je bedrijfsproces aanpassen aan software laat zien welke organisatorische veranderingen je daarnaast kunt onderzoeken.
Een andere inrichting vraagt ook een goede ingebruikname.
Een bestaande toepassing kan beter aansluiten door rollen, statussen, gegevens en overdrachten anders in te richten. Neem medewerkers mee in de nieuwe werkwijze, test een volledige opdracht en maak duidelijk welke omgeving vanaf de overstap leidend is. Onboarding verbindt die voorbereiding met het dagelijkse gebruik.
Blade begeleidt dit als onderdeel van inrichting en ontwikkeling. Bekijk bijvoorbeeld Odoo en Salesforce koppelen en inrichten, de overdracht naar Exact of AFAS en wanneer open source een passende basis is.
Bouw de oplossing die je bedrijf verder helpt.
Blade ontwikkelt eigen toepassingen en complete systemen, en bouwt de koppelingen met software die een nuttige rol houdt. We onderzoeken welke aanpassing een pakket daadwerkelijk ondersteunt en waar eigen proceslogica beter op haar plek is. Zo krijgt maatwerk een duidelijke verantwoordelijkheid in je bedrijf.
Laat ons zien waar je pakket vastloopt. Neem één handeling mee die nu omwegen vraagt. We bespreken wat een gerichte uitbreiding kan oplossen en wat een eigen systeem oplevert aan samenhang, met de bijbehorende ontwikkel- en beheerkeuzes.