Permit, licensing, and inspection systems each store slightly different spellings and tax IDs for the same contractor companies, causing wrong notifications and duplicate vendor payments. What problem does this primarily motivate?
Select an answer to reveal the explanation.
Short Explanation
When three desks keep three versions of 'Acme Plumbing,' the city is not arguing about plumbing—it is arguing about who Acme is. That shared contractor identity is classic party master data. MDM exists so processes stop inventing competing company records.
Full Explanation
Slightly different spellings and tax IDs for the same contractor companies across permit, licensing, and inspection systems primarily motivate establishing master data management for the party/organization domain so shared contractor identity is consistent across civic processes. Wrong notifications and duplicate vendor payments are classic symptoms of unmanaged party masters. Replacing all operational systems with a single monolithic ERP so no shared entities remain fails as an extreme rip-and-replace that avoids MDM rather than solving cross-process identity. Turning off cross-system notifications until every spelling matches character-for-character fails by halting useful civic communications instead of mastering identity. Archiving transactional permit history because inconsistency “only matters in analytics” fails when operational payments and notices are already harmed. Exam caveat: multi-system party inconsistency is a canonical MDM business case—do not leap to ERP replacement as the only answer. Operational check: profile contractor duplicates across the three systems, propose party MDM scope, define match keys (legal name, tax ID), and pilot golden identity for notifications and payees. Report avoided duplicate-payment risk to finance sponsors as the municipal value story.