The terms omni-channel banking and omni-channel retailing are becoming popular within businesses these days.
In this context omni (meaning all) is considered to be something more advanced than multi (meaning many) as in multi-channel retailing.
Data management, including Master Data Management (MDM), is always a bit behind the newest business trends. In our discipline we have hardly even entered the multi stage yet.
Some moons ago I wrote about multi-channel data matching on the Informatica Perspectives blog in the post Five Future Data Matching Trends. Today, on the same blog, Stephan Zoder has the post asking: Is your social media investment hampered by your “data poverty”?
Herein Stephan examines the possible benefits of multi-channel data matching based on a business case within the gambling industry.
Using omni in relation to MDM was seen in a vendor presentation at the Gartner MDM Summit in London last week as reported in the post Slicing the MDM Space. Omnidomain MDM was the proposed term here.
The end goal should probably be something that could be coined as omni-purpose MDM. This will be about advancing MDM capabilities to cover multiple domains and embrace multiple channels in order to obtain a single view of every core entity that can be used in every business process.
Liliendahl on Data Quality 
Greetings Henrik,
What feels important to me behind the “words” omni-, multi-, -vectors, -domains etc. is the true ability from a solution to deliver it.
As you emphasize, there is “omni” by design, and “omni” by acquisition. There is also “omni” in terms of the freedom you receive from your solution. How far can you freely expand in domains, entities, attributes, sources, instances or users before being hit by scalability or even worse increasing costs?
MDM is a journey. If there is a toll gate at each turn, it will make any “-omni” less much attractive.
Gauthier, thanks a lot for commenting. I also think it means that MDM solutions should be somewhat open for services that add special features in a given channel (or set of channels) or related to a given domain. Examples could be MDM services for onboarding party data, MDM services for sharing and publishing product data, MDM services for handling advanced location data.
It looks interesting to make MDM handling new business models, or at least new functional blocks, the drawback remains the performance. As you stated there should be some “core functional services” like “sharing & publication”, but the more you would ask on the functional side of the MDM solution the more it become transactional oriented. A tradeoff would be to plan the functional extension on the existing domain using (synchronized) master data copy. I join Gauthier’s point of view but yours is pointing out the minimum requirement an MDM functional layer should have, wich is also something that needs to be adressed according the maturity of each specific environment of the MDM solution .
Thanks for adding in Tarik. Sure, there is a lot of balancing to be done both for sellers and buyers of MDM solutions.