De aanleiding voor veel organisaties om hun ERP-landschap opnieuw te bekijken is zelden “alleen techniek”. Vaak gaat het om een combinatie van stijgende beheerkosten, veranderende businessmodellen, druk op doorlooptijden en toenemende eisen rondom data en compliance. In die context komt regelmatig dezelfde beslisvraag terug: blijf je investeren in het bestaande SAP-landschap (optimaliseren, harmoniseren, upgraden) of stap je over naar een alternatief zoals Odoo?
Deze blog vergelijkt SAP (in de praktijk vaak SAP ECC of SAP S/4HANA, afhankelijk van het vertrekpunt) met Odoo, met focus op ERP-kernprocessen, reporting/analytics en integraties. Het doel is niet om een “winnaar” aan te wijzen, maar om de afweging expliciet te maken: waar liggen de functionele en strategische verschillen, welke trade-offs zijn reëel, en waar zitten onzekerheden die pas tijdens een fit-gap of pilot zichtbaar worden?
De vergelijking is relevant voor drie groepen beslissers:
Een heroverweging komt vaak op tafel bij signalen zoals: structureel hoge change-lasten (veel governance, lange doorlooptijden), licentie- en bundelcomplexiteit, behoefte aan sneller itereren in processen, of juist de wens om meer te standaardiseren en lokale varianten terug te dringen. Ook veranderingen in data-eisen (EU data residency, strengere contractuele eisen rond verwerkers, of AI-initiatieven die data-toegang en semantiek vereisen) kunnen een kantelpunt zijn.
Belangrijk is de afbakening. “SAP” is geen enkel product: organisaties kunnen werken met on-premise, private cloud of public cloud varianten, met verschillende mate van standaardisatie en extensiemogelijkheden. Voor Odoo geldt hetzelfde: community versus enterprise, hosting via Odoo, via partner of on-premise. Deze keuzes beïnvloeden niet alleen kosten, maar ook controle over data, update-cycli, securityverantwoordelijkheden en integratiepatronen.
De opzet van deze blog is als volgt: eerst de uitgangspunten en positionering van beide platformen, daarna de gebieden waar SAP doorgaans sterker is en waar Odoo vaak voordeel biedt. Vervolgens volgt een vergelijkingsdeel met een matrix per domein, een verdieping op AI en integratie, en een sectie over kosten en organisatorische impact. Tot slot: een besluitvormingsgerichte afsluiting met vervolgstappen en hoe een onafhankelijke partij kan ondersteunen.
SAP en Odoo worden in de praktijk vaak vergeleken omdat ze beide “ERP” heten, maar ze vertrekken vanuit een ander ontwerpprincipe en een andere doelgroep. Dat verschil is bepalend voor implementatie-aanpak, governance, extensie-strategie en de mate waarin je enterprise-complexiteit out-of-the-box kunt dragen.
SAP (met name S/4HANA) is traditioneel sterk in mid-market tot enterprise omgevingen, vaak met internationale structuren, meerdere juridische entiteiten, meerdere plants en een complex supply chain- en controllingmodel. Denk aan discrete manufacturing (automotive, industrial machinery, high tech) en process manufacturing (chemicals, life sciences, CPG/food), maar ook groothandel/distributie en retail. In gereguleerde contexten wordt SAP ook gekozen vanwege volwassen compliance- en deploymentopties, waaronder concepten rond soevereine cloudvarianten.
Odoo zit van oorsprong sterker in SMB/mid-market, maar wordt in toenemende mate ingezet bij groeiende organisaties die een modulair systeem willen dat relatief snel te configureren en uit te breiden is. De kern is een breed palet aan modules (finance, sales, voorraad, productie, HR, e-commerce), met een uniforme gebruikerservaring. De mate waarin Odoo enterprise-schaal “native” ondersteunt hangt in hoge mate af van scope, implementatiekwaliteit en governance rond maatwerk.
SAP is doorgaans een suite-ERP dat uitgaat van sterke procesgovernance en een fit-to-standard benadering: standaardprocessen en data-structuren krijgen prioriteit, en afwijkingen worden expliciet gemanaged via configuratie, extensies en integraties. Dat biedt stabiliteit en voorspelbaarheid, maar leidt vaak tot zwaardere change-processen.
Odoo is meer een modulair platform: je kunt starten met een beperkt domein en uitbreiden per proces. In veel scenario’s kun je sneller itereren, omdat modules relatief “licht” te implementeren zijn. De trade-off is dat flexibiliteit ook discipline vereist: zonder duidelijke architectuur- en dataprincipes kan wildgroei ontstaan in custom modules, afwijkende workflows en rapportages.
Bij SAP is de sectorfit vaak sterk in scenario’s met diepe manufacturing- en supply chain complexiteit, multi-entity controlling, uitgebreide compliance-eisen en hoge eisen aan audit trails. Voor Odoo geldt dat het breed toepasbaar is, maar dat het bij zwaardere industrie- of regulatiescope vaker neerkomt op: ofwel een streng gestandaardiseerde implementatie (minder maatwerk), ofwel aanvullende modules/maatwerk met bijbehorende onderhoudslast.
Voor data-soevereiniteit en hosting is SAP relatief expliciet: er zijn public cloud, private cloud en on-premise opties, en SAP communiceert datacenterlocaties per service. Daarnaast bestaan er soevereiniteitsinitiatieven (zoals “sovereign cloud” proposities) die bedoeld zijn om regionale controle, compliance en operationele verantwoordelijkheden beter af te stemmen op EU-eisen. In de praktijk is het belangrijk om per dienst en editie te verifiëren wat de exacte data residency, support-toegang en loggingmogelijkheden zijn.
Odoo kan cloud-gehost zijn of on-premise draaien, afhankelijk van editie en implementatiepartner. Dat maakt data residency in theorie flexibel (bijvoorbeeld EU-hosting of eigen datacenter), maar het betekent ook dat je contractueel en technisch zelf meer moet borgen: waar staat welke data, wie heeft beheeraccess, hoe worden back-ups en logging geregeld, en wat is de rolverdeling (verwerkingsverantwoordelijke/verwerker) bij gebruik van externe AI- of integratiediensten?
SAP leunt sterk op een breed ecosysteem met platformcomponenten voor integratie en extensies (zoals SAP Business Technology Platform) en analytics (zoals SAP Analytics Cloud). Het voordeel is een consistent enterprise-ecosysteem met governance en lifecycle. Het nadeel kan zijn dat de oplossing minder “lichtgewicht” aanvoelt en dat je sneller afhankelijk wordt van aanvullende subscriptions en platformkeuzes.
Odoo heeft een groot aanbod aan apps en partner-/third-party modules. Dat kan snel waarde leveren, maar de kwaliteits- en securitytoetsing varieert. Voor besluitvorming is het relevant om niet alleen te kijken naar “beschikbaar”, maar naar onderhoudbaarheid, upgrade-pad, community-ondersteuning en de mate waarin een module past bij jouw control framework (autorisaties, logging, data governance).
SAP is ontworpen voor organisaties met enterprise-schaal: meerdere landen, valuta, plants, uitgebreide autorisatieconcepten en complexe ketens. Vooral in omgevingen met strikte scheiding van taken, uitgebreide workflows en stevige controllingbehoeften (cost centers, profit centers, segment reporting) komt de volwassenheid van SAP naar voren.
Dit betekent niet dat Odoo dit niet kan, maar het betekent wel dat SAP in veel gevallen minder “ontwerpwerk” vraagt om governance en controleerbaarheid op te zetten. Voor operations kan dat stabiliteit bieden; voor IT betekent het vaak een duidelijker standaard voor rollen, logging en procesdiscipline.
In discrete en process manufacturing heeft SAP een lange historie met bewezen procespatronen. Denk aan variantenbeheer, complexe planning, traceability-eisen, en scenario’s waar QA, batchmanagement en audit trails geen bijzaak zijn. In gereguleerde omgevingen speelt ook mee dat SAP deploymentopties biedt die kunnen aansluiten bij soevereiniteits- en compliancewensen, afhankelijk van editie en contract.
De trade-off is dat deze diepgang vaak samenhangt met complexere implementaties. Fit-to-standard keuzes zijn in zulke omgevingen niet alleen “best practice”, maar vaak ook randvoorwaarde om een landschap beheersbaar te houden.
Een onderscheidend punt van SAP S/4HANA is de sterke integratie van transacties en analytics op dezelfde operationele data (“embedded analytics”). Voor veel use-cases betekent dit dat KPI’s, multidimensionele rapporten en analytische apps direct op de ERP-data kunnen draaien, zonder dat je per definitie data hoeft te repliceren naar een apart datawarehouse voor basisrapportage.
Voor besluitvorming is dit relevant omdat het impact heeft op architectuur en operationeel beheer: minder datakopieën kan leiden tot minder reconciliatievraagstukken, maar het kan ook betekenen dat je performance- en autorisatieontwerp zwaarder moet managen binnen het ERP zelf.
SAP’s semantische datalaag (bijvoorbeeld CDS views en het Virtual Data Model) biedt een gestandaardiseerde manier om data te interpreteren: definities van omzet, marge, voorraadwaarde en doorlooptijden zijn niet alleen queries, maar onderdeel van een bredere semantiek. Met tooling zoals een Query Browser en Custom Analytical Queries kan een organisatie KPI’s beheren met meer controle op definities en hergebruik.
Dit helpt vooral in organisaties waar “één versie van de waarheid” belangrijk is en waar veel stakeholders rapportages gebruiken. Het neemt echter niet weg dat definities en datakwaliteit nog steeds organisatievraagstukken zijn. De semantische laag faciliteert governance, maar vervangt die niet.
In SAP-landschappen is integratie en uitbreiding vaak gestructureerd via platformcomponenten. SAP Business Technology Platform wordt gebruikt voor integratie, extensies en aanvullende services; SAP Analytics Cloud kan fungeren als analytics-client met live connecties naar analytische queries. Het voordeel is een consistent ecosysteem met duidelijke lifecycle en vendor roadmap.
De onzekerheid zit in de mate waarin je deze componenten nodig hebt. Voor sommige organisaties is dit precies de gewenste enterprise-architectuur. Voor andere organisaties voelt het als extra lagen met extra contracten, die je TCO en afhankelijkheid vergroten.
Odoo wordt vaak gekozen vanwege snelheid: je kunt relatief snel starten met kernprocessen en itereren op basis van feedback uit de operatie. In omgevingen waar processen nog in ontwikkeling zijn, of waar een organisatie bewust klein wil beginnen (bijvoorbeeld eerst finance en sales, daarna voorraad en productie), kan dit de implementatierisico’s verlagen.
De trade-off is dat “sneller aanpassen” ook kan leiden tot minder uniforme processen als governance ontbreekt. Snelle iteraties zijn alleen een voordeel als je ook duidelijke beslisregels hebt over wat standaard blijft en wat maatwerk mag zijn.
In de praktijk ervaren veel organisaties SAP-licenties en bundels als complex. Odoo is vaak eenvoudiger te begrijpen en te schalen per module of gebruikersgroep. Dat betekent niet dat een prijsvergelijking 1-op-1 te maken is: hosting, partnerkosten, maatwerk, supportniveaus en externe tooling bepalen de totale kosten.
Voor besluitvorming is vooral relevant: hoe voorspelbaar zijn de terugkerende kosten, en welke kosten ontstaan indirect (bijvoorbeeld extra BI-tooling of iPaaS) als je functionaliteit buiten Odoo moet oplossen?
Het modulaire karakter maakt het mogelijk om implementatie te faseren en “big bang” risico’s te beperken. Een organisatie kan bijvoorbeeld starten met finance en order-to-cash, vervolgens voorraad/warehouse toevoegen, daarna productie of projectmanagement. Dit kan goed passen bij organisaties die hun processen willen harmoniseren terwijl de business doorloopt.
Het risico is scope-creep: als elk domein eigen keuzes maakt, kan het eindresultaat alsnog complex worden. Een duidelijke enterprise-architectuur (ook bij een “simpel” platform) blijft noodzakelijk.
Odoo staat bekend om een uniforme gebruikerservaring over modules heen. Voor dagelijkse taken kan dit de trainingslast verlagen, vooral als de organisatie grotendeels in standaardprocessen kan blijven. In de praktijk hangt dit sterk af van maatwerk en van de mate waarin de implementatie partner-specifieke aanpassingen toevoegt.
Voor operations is een belangrijke vraag: ondersteunen de standaard workflows de uitzonderingen die in jullie business normaal zijn? Als veel uitzonderingen maatwerk worden, verschuift het voordeel van gebruiksgemak naar onderhoudslast.
Veel organisaties hebben een landschap met CRM, e-commerce, WMS, PLM, field service tooling en BI-oplossingen van verschillende leveranciers. Odoo past vaak pragmatisch in zo’n omgeving via API’s en beschikbare connectoren. Dat kan de afhankelijkheid van specifieke platformcomponenten verminderen, zeker als je al een iPaaS of API-managementlaag gebruikt.
Ook hier geldt: “kan koppelen” is niet hetzelfde als “goed beheersbaar integreren”. Monitoring, foutafhandeling, versiebeheer en security (mTLS, OAuth, secrets management) moeten expliciet ontworpen worden.
Onderstaande vergelijking is bedoeld als beslisondersteuning. Het gaat om typische verschillen in volwassenheid, standaardfunctionaliteit en implementatie-impact. In de praktijk bepalen configuratie, scope en partnerkwaliteit de uitkomst.
Indicatieve vergelijking (algemeen beeld; bevestigen in fit-gap):
SAP biedt vaak diepe ondersteuning voor enterprise scenario’s, zeker in manufacturing en controlling. Odoo biedt brede basisfunctionaliteit en vult aan via modules. Dat is aantrekkelijk als je organisatie vooral “standaard ERP” nodig heeft en snelheid wil. Het risico is dat “brede basis” bij complexere scenario’s alsnog leidt tot functionele gaps die je moet opvangen met maatwerk of aanvullende systemen.
Een praktische manier om dit te toetsen is om niet te starten met een generieke demo, maar met end-to-end scenario’s die jouw complexiteit representeren: bijvoorbeeld batch traceability met quality checks, intercompany flows, of maandafsluiting met specifieke controlling-rapportages.
SAP past goed bij organisaties die bereid zijn processen te standaardiseren en governance centraal te organiseren. Fit-to-standard werkt vooral goed als je management ook werkelijk stuurt op het beperken van uitzonderingen.
Odoo biedt meer flexibiliteit in configuratie en uitbreiden. Dat is een voordeel als je snel moet aanpassen, maar het vraagt discipline om wildgroei te voorkomen. Governance betekent dan: heldere architectuurprincipes, change board, en afspraken over wat maatwerk mag zijn (en hoe het onderhouden wordt).
In SAP is reporting vaak nauw verweven met het ERP zelf via embedded analytics en de semantische laag (CDS/VDM). Hierdoor kun je veel KPI’s direct op transactiedata draaien, met herbruikbare definities. Het is tegelijkertijd een keuze: je gebruikt het ERP als analytische bron, wat eisen stelt aan performancebeheer, authorizations en datamodellering.
Bij Odoo is rapportage sterker afhankelijk van de gekozen aanpak. Voor basisrapportage kun je vaak binnen Odoo blijven. Voor managementinformatie, cross-system dashboards of historisering kiezen organisaties regelmatig voor een externe BI/DWH-laag. Dat geeft flexibiliteit, maar introduceert integratie- en reconciliatievraagstukken. De juiste keuze hangt af van latency-eisen (realtime versus dagbatch), KPI-governance en de volwassenheid van je datateam.
SAP kent gestandaardiseerde extensiemodellen (vaak via platformcomponenten). Dat helpt om upgrades beheersbaar te houden, maar kan de drempel voor kleine aanpassingen verhogen. Odoo maakt maatwerk relatief toegankelijk. Dat versnelt, maar verhoogt het risico dat upgrades en support lastiger worden, zeker als custom code diep in kernprocessen grijpt.
Een nuchtere trade-off: maatwerk is niet “goed” of “slecht”, maar het moet expliciet worden geprijsd in onderhoud, testlast en afhankelijkheid van specifieke ontwikkelaars of partners.
SAP positioneert generatieve AI onder andere via Joule, een copilot die in S/4HANA Cloud-scenario’s kan ondersteunen bij informatie- en taakgerichte interacties. Praktisch kun je denken aan: sneller vinden van relevante transacties, ondersteuning bij processtappen, en in bepaalde domeinen hulp bij datagerelateerde taken (zoals master data governance scenario’s). Belangrijk: dit is doorgaans een service die draait op SAP BTP en vraagt om subscription- en identity-inrichting.
Bij Odoo zijn AI-mogelijkheden vaker afhankelijk van het ecosysteem: aanvullende apps, partneroplossingen of integratie met externe AI-diensten. Dat kan flexibiliteit geven (je kiest best-of-breed), maar het betekent ook dat je zelf meer ontwerpkeuzes moet maken rond datatoegang, security, logging en kosten per gebruik.
Voor AI en advanced analytics is het datafundament vaak bepalender dan de “AI-feature” zelf. SAP’s CDS/VDM semantiek kan helpen om data eenduidig te definiëren en herbruikbaar te maken, wat relevant is voor KPI’s, features en governance. Dit verkleint het risico dat verschillende teams verschillende definities gebruiken voor dezelfde metric.
In Odoo is de semantiek vaker project- of modelafhankelijk. Dat is niet per se een probleem, maar het vraagt expliciet datamodellering en KPI-governance buiten het pakket: definities vastleggen, data lineage beheren, en zorgen dat AI-toepassingen dezelfde interpretatie hanteren als finance en operations.
SAP-landschappen kiezen vaak voor een centrale integratie- en extensiehub (zoals BTP). Dat biedt gestandaardiseerde connectiviteit, monitoring en governance, maar kan leiden tot extra platformafhankelijkheid.
Odoo wordt vaak API-first geïntegreerd: direct via API’s of via een iPaaS. De keuzecriteria zijn hier concreet: wil je centrale monitoring en foutafhandeling, hoe regel je security (OAuth, token lifecycle), hoe ga je om met latency, en wie “owned” de integratielogica? Een pragmatische architectuur kan zeer effectief zijn, maar alleen als ownership en beheerprocessen zijn ingericht.
SAP omgevingen zijn vaak ingericht met enterprise IAM, rolgebaseerde policies en strakke scheiding van taken. Voor AI-services zoals Joule komen daar subscriptions, identity setup en mogelijk extra audit/logging-eisen bij. Dat past goed in organisaties met een volwassen securitymodel, maar verhoogt de implementatielast.
Bij Odoo is security en governance sterker afhankelijk van deployment en partnerkeuzes. Dit betekent dat je vooraf expliciet eisen moet formuleren: SSO/MFA, rolmodel, logging, incident response, back-up/restore tests, en patchmanagement. Dit is vooral belangrijk als Odoo een kernsysteem wordt in een gereguleerde omgeving.
AI vergroot vaak de discussie rond data-soevereiniteit: welke data verlaat je ERP, waar worden prompts en output opgeslagen, en wie heeft toegang? SAP biedt in bepaalde contexten soevereine cloud- en on-premise varianten en publiceert datacenterlocaties per service. Toch blijft het noodzakelijk om per AI-scenario contractueel en technisch te verifiëren: welke data wordt verwerkt, hoe wordt die gelogd, en welke supporttoegang bestaat er?
Bij Odoo (en zeker bij externe AI-diensten) moet je datalocatie en verwerkersrollen contractueel borgen. Denk aan DPIA’s, beleid voor persoonsgegevens in prompts, dataminimalisatie, en duidelijke afspraken over dataretentie. Zonder dit kan AI “snel” starten, maar later compliance- en reputatierisico’s creëren.
Een SAP→Odoo afweging is in de kern een TCO- en risicovraagstuk, niet alleen een licentievraag. In veel business cases verschuiven kosten van licenties naar implementatie, integratie en organisatorische verandering. Daarom is het zinvol kosten te structureren naar eenmalig, terugkerend en organisatorisch.
De verwachte ROI ontstaat doorgaans uit een mix van: lagere terugkerende kosten (niet gegarandeerd), lagere change-kosten per wijziging, snellere doorlooptijden, minder handwerk door betere datakwaliteit en processtandaardisatie, en betere sturing door betrouwbare KPI’s. Welke component dominant is, verschilt per organisatie.
De doorlooptijd en impact van een overstap worden vooral bepaald door scope en complexiteit. Typische drivers zijn: het aantal landen en juridische entiteiten, manufacturingcomplexiteit (batch/traceability, QA, planning), compliance-eisen, het aantal integraties en de kwaliteit van master data. Een organisatie met weinig uitzonderingen en sterke datakwaliteit kan in fasen relatief snel migreren. Een organisatie met veel legacy maatwerk en veel uitzonderingsprocessen zal veel tijd kwijt zijn aan harmonisatie, datacleaning en control design.
Belangrijk: een “sneller systeem” betekent niet automatisch een “sneller project”. Een groot deel van de doorlooptijd zit in besluitvorming, proceskeuzes, datavraagstukken en adoptie.
Deze posten bepalen vaak of de business case realistisch is. Het is verstandig ze vroeg te kwantificeren, ook al zijn het bandbreedtes.
Een ERP-transitie raakt operatie en cashflow. Risico’s zitten vooral in cut-over (voorraadstanden, open orders, onderhanden werk), financiële afsluiting en productiestilstand. De mitigaties zijn bekend, maar moeten consequent toegepast worden: fasering per entiteit/proces, pilots, parallel-run waar nodig, en een rollback-strategie voor kritieke stappen.
Een praktische keuze is vaak: minimal viable scope voor go-live met strakke controls, gevolgd door gecontroleerde optimalisatie. Dat kan risico’s verlagen, maar alleen als de organisatie bereid is om tijdelijk met beperkingen te werken.
Bij SAP kan exit-impact ontstaan door contractuele verplichtingen, bundels en afhankelijkheden van platformdiensten. Een overstap vraagt dus niet alleen een technisch migratieplan, maar ook contractmanagement: opzegtermijnen, data-extract rechten, en afspraken over support in de uitloopfase.
Bij Odoo speelt partnerafhankelijkheid een grote rol: implementatiekwaliteit, SLA’s, hosting, en kennisborging. Als data residency en EU-hosting randvoorwaarden zijn, moeten die expliciet in contracten en technische ontwerpen terugkomen (inclusief back-up locatie, supporttoegang en subverwerkers).
SAP blijft vaak de logische keuze als de organisatie enterprise manufacturing- of regulatiecomplexiteit heeft, zwaar leunt op embedded analytics en semantische KPI-structuren, en governance als noodzakelijke voorwaarde ziet. In die context zijn de risico’s van functionele gaps bij een migratie vaak groter dan de baten van een ander platform, zeker als je huidige landschap met rationalisatie en standaardisatie beter beheersbaar gemaakt kan worden.
Odoo wordt logischer als snelheid, modulariteit en veranderbaarheid zwaar wegen, en als de organisatie grotendeels met standaardprocessen kan werken (of bereid is gaps expliciet te managen). Dit geldt vooral als de huidige SAP change-lasten disproportioneel zijn ten opzichte van de businesswaarde, of als de organisatie een gefaseerde aanpak wil waarbij niet alles tegelijk hoeft.
Pantalytics kan helpen door requirements te structureren en te vertalen naar concrete keuzes, zonder te vertrekken vanuit een toolvoorkeur. Dat begint met procesinventarisatie en prioritering (must/should/could), gevolgd door mapping van SAP-processen naar Odoo modules en het expliciet maken van gaps. Dit helpt om discussies te verplaatsen van “meningen” naar toetsbare scenario’s.
Een overstap raakt vrijwel altijd reporting en KPI’s. Pantalytics kan de huidige KPI-structuren en embedded analytics (waar van toepassing) analyseren en vertalen naar een doelarchitectuur: wat kan in Odoo, wat vraagt een BI/DWH-laag, en welke semantische definities moeten centraal geborgd worden. Dit voorkomt dat reporting pas na go-live “gerepareerd” wordt.
Voor een beheersbare overstap is een target landscape nodig: welke systemen blijven, welke worden vervangen, hoe loopt de data, en waar ligt ownership? Pantalytics kan helpen met een integratiestrategie (API/iPaaS), security/IAM ontwerp, monitoring en logging. Ook kan per domein een migratiepad worden uitgewerkt (bijvoorbeeld eerst finance, daarna supply chain), inclusief impact op interfaces.
Een migratieplan dat alleen technisch is, is onvoldoende. Pantalytics kan fasering uitwerken (per land, entiteit of proces), een cut-over plan opstellen, een teststrategie definiëren (SIT/UAT/controls) en compliance checks inbouwen. Hiermee worden risico’s rond voorraad, financiële afsluiting en productiestilstand concreet gemitigeerd.
Tot slot kan pantalytics ondersteunen met een business case die meerdere scenario’s naast elkaar zet: SAP optimaliseren, Odoo migreren, of een hybride variant. Daarbij hoort een TCO-model met bandbreedtes, expliciete aannames en meetpunten (bijvoorbeeld change-doorlooptijd, incidentvolume, closing time). Dit maakt de uiteindelijke beslissing bestuurbaar en toetsbaar, in plaats van gebaseerd op eenmalige prijsvergelijkingen.
