Answer
A concrete example makes this easier to plan around: if a customer's shipping address changes, does that update start in the ERP because it affects order fulfillment, or in the CRM because a sales rep took the call first. Without a documented answer, both systems can end up with a different address, and whichever one runs the next invoice or shipment uses whatever happened to sync last. The same problem shows up with pricing overrides, credit holds, and contact title changes, all of which can plausibly originate in either system depending on who touches the account first.
Governance for this does not need to be complicated, but it does need to be written down and enforced technically where possible, not just agreed to in a meeting. Buyers should ask CRM vendors whether the platform can be configured to make certain fields read-only when they originate elsewhere, whether conflicting updates trigger an alert instead of silently overwriting one value with another, and how the integration logs which system last touched a given record. Assigning clear ownership by data type, and building the integration to respect that ownership rather than treating every field as equally editable everywhere, is what actually prevents the duplicate-truth problem from showing up six months after go-live.