And then change management of vendor X regarding the ERP kicks in.
Client: 'What's your release schedule for patches'?
X: 'Every 2 weeks'
Client thinks: 'Damn, how can I keep up with this change schedule?'
Client: 'Well, can you tell me anything regarding the average impact of these patches?'
X: 'Well, they can be very small and very big'
Client thinks: 'Ok, what are you NOT telling me'
Client:'Ok, but this ERP is like 15 years old, so give me an overview of the average impact'
X: 'Basically anything can happen'
Client thinks: 'o, o'
Client: 'Ok, but the majority of these changes are of course situated in the application layer, not the data layer?'
X: 'Well..anything can happen.'
Client thinks: 'Is it warm in here?'
Client: 'Anything? Also in the data layer? Table changes, integrity changes, domain type changes, value changes?'
Client thinks: 'Ok - I'm dead'
Client: '...at least tell me that existing structures always remain intact and the data remains to be auditable - extent instead of replace for example'
Client thinks: 'Well, at least I am healthy...'
Client: 'hmm...just a side note, we use Change Data Capture, I assume that these changes are fully logged?'
X: 'Nah - log is turned off, otherwise we can't deploy the changes'
Client thinks: '..hmm....is my resume up to date?'
My point; do not assume your vendor (of any system) to engage in professional application development and a change management policy that takes into account the simple fact that data of these information systems need to be shared with other information systems in your company.
Change management and professional application development needs to be important criteria regarding the selection of information systems.