If you search in google for “single customer view” you’ll get over 20,000 hits. If you search for “single business partner view” you’ll get zero – until I just posted this blog post.
Some time ago I wrote about getting a 360° Business Partner View elaborating on extending the 360° Customer View or Single Customer View (SVC) to embrace all sorts of party master data managed within the organization.
In fact there is at least the same amount of similar techniques used between
- managing supplier master data and business-to business (B2B) customer master data
as there is between
- managing business-to-business (B2B) customer master data and business-to-consumer (B2C) customer master data.
If you look at Customer Relation Management (CRM) systems almost every package is aimed at managing B2B data as the data model and the functionality supports real world B2B structures and how the sales force and other employees interacts with B2B customers and prospects.
Interacting with B2C customers and prospects is much more diverse and often supported by operational systems specialized for the industry in question like solutions for financial services, healthcare and so on.
A business partner is a party acting in the role as customer, prospect, supplier, reseller, distributor, agent and other forms of partnership. Sometimes the same party is acting in several roles at the same time thus potentially being both on the Sell–side and Buy-side of Master Data Quality management.
As sell side and buy side has intersections within party master data, in some industries we may also go deeper into identity resolution and find intersections between B2B entities and B2C entities. I’ve described these matters in the post So, how about SOHO homes. The business case is that some products in some industries are aimed at the households of business owners and the small businesses at the same time. This is for example true for industries as banking, insurance, telco, real estate and law.
All in all achieving a single view of business partners is a task going beyond traditional customer data integration (CDI) and stretching into areas traditionally belonging to Product Information Management (PIM). This is a business case for multi-domain master data management.
Liliendahl on Data Quality 
This is funny – try searching for “single party view” – you will get over 120K hits of the kind we didn’t expect ; seriously, thinking what you are truly describing is the party concept in MDM (just not labeled as such) where a party can be any combination of customer, organization, business, employee, supplier, or counter-party knitted together by role or relationship; thanks for the bringing this our attention…
-jdp (Parnitzke)
James, thanks for the comment. Yep, it is about parties: The single ones, the couples and the incorporated ones.
Henrik,
First off, thanks for the invitation to the group. I’ve always enjoyed your DQ posts and insights and I’m looking forward to exploring these (multi-domain) concepts further.
You might by now begin to see a pattern in your posts: abstracting customer information out to include supplier, distributor and agent via a partner construct is not much different than abstracting address information out to include both positional, coordinate and place information as three aspects of ‘Location’…
I have found that applying this principle abtraction out to all facets of information results in some very stable and persistent patterns. Take, for example, address information. In many cases the addresses we try to manage refer only indirectly to organizational entities. A more direct relationship is to the physical assets they ‘address’. Not in all cases – some customers only have Post Office boxes – but when you manage an entity in a physical domain (like an office building or a store) as distinct from the business that currently occupies that space, you have a much better chance at making that information persistent, clean and therefore reusable to other applications.
It turns out that almost all classes of information ‘behave’ that way.
Thanks for commenting here John.
Pleased that you joined the LinkedIn Multi-Domain MDM group.
Good point about addresses. Should be handled as an own entity type being location master data. This is a pet peeve of mine too when I see data models mixing it up.