Begin bij de reden voor de uitzondering
Vraag welk bedrijfsresultaat een aanpassing moet ondersteunen. Een scherm dat er anders uitziet is een andere aanleiding dan een ontbrekende controle voor productie. Beschrijf hoe vaak de situatie voorkomt, wie ermee werkt en wat er misgaat zonder aanpassing. Daarmee voorkom je dat een oude gewoonte vanzelf een nieuwe software-eis wordt.
Ons afwegingsmodel
Onderzoek eerst een procesafspraak en standaardconfiguratie. Kijk daarna of een bestaande toepassing of koppeling de behoefte beter afdekt. Als die routes onvoldoende zijn, kan ontwikkeling worden onderzocht. Dit is een beslisvolgorde, geen regel dat maatwerk verkeerd is. De uiteindelijke keuze moet de behoefte, beheerlast en afhankelijkheden verklaren.
| Mogelijke route | Wanneer onderzoeken? |
|---|---|
| Procesafspraak | De regel of verantwoordelijkheid is onduidelijk |
| Standaardconfiguratie | De behoefte past bij bestaande werking |
| Koppeling | Een ander systeem vervult de taak al goed |
| Uitbreiding | De behoefte blijft bestaan na toetsing van de alternatieven |
Een voorbeeld uit de orderflow
Stel dat uitvoering een order pas mag oppakken na controle van de aangeleverde informatie. De vraag is dan welke controle nodig is en wie haar vastlegt. Een status of bestaande workflow kan al voldoende zijn. Pas als de controle bijzondere gegevens of regels vereist, komt een uitbreiding in beeld. Dit is een illustratief scenario, geen gerealiseerd klantresultaat.
Rekening houden met de volgende wijziging
Een aangepaste module vraagt tests en een verantwoordelijke voor onderhoud. Ook configuratie en koppelingen hebben gevolgen bij een wijziging. Noteer welke onderdelen ervan afhangen en hoe een nieuwe versie wordt beoordeeld. Een lagere eerste projectprijs kan een grotere latere beheerlast verhullen.
De beslissing overdraagbaar maken
Bewaar de aanleiding, onderzochte alternatieven en gekozen oplossing in een besluitnotitie. Voeg een test toe die laat zien wanneer het onderdeel goed werkt. Zo kan een volgende medewerker of uitvoerder begrijpen waarom iets bestaat. Dat voorkomt dat het bedrijf opnieuw moet raden welke aanpassingen nog nodig zijn.
Documenteer waarom een aanpassing nodig is. Die reden is later net zo belangrijk als de code.
Vragen bij deze keuze.
Is Odoo Studio hetzelfde als maatwerkontwikkeling?
Het zijn verschillende manieren van aanpassen. Welke route geschikt is, hangt af van de gewenste werking en de omgeving. Laat ook rechten, beheer en wijzigingen meewegen.
Moeten we alle bestaande modules opnieuw bouwen?
Nee. Inventariseer eerst wat ze doen en welke processen ervan afhangen. Behouden, vervangen of vereenvoudigen vraagt per onderdeel een onderbouwde keuze.