There are many reasons why it is advantageous to arrange customer data into some type of classified grouping. Sales teams may be interested in grouping customers by region for proper field rep assignments. Services may be interested in grouping customers by level to give proper discounts. Marketing may be interested in grouping customers by industry to define effective campaigns.
Sometimes these needs can be met by creating reports on existing attributes associated with customers. But quite often, it is necessary to create a more permanent structure with attributes and relationships that are not readily available, or it could take too long to determine on the fly. Customer hierarchy falls into this last category.
A customer hierarchy adds a vertical dimension to the horizontal 360° view, as depicted in Figure 10.3. It is possible to uncover relationships not readily available on the hub, especially when doing business with large companies with many subsidiaries and/or departments. The hub will normally carry the atomic set of information about a given customer, located at a particular address, with a certain account type, and through a specific contact, has engaged in a selling relationship. But a lot of these atomic records can be associated with distinct departments and/or subsidiaries; have separate bill-to, ship-to, and installed-at addresses; and/or were carried on by a specific sales channel. A customer hierarchy enables the proper connections and abstractions, especially because the volume of data can be quite overwhelming.
Figure 10.3 Customer Hierarchy as a Vertical Dimension to the 360° View
But some considerations should be made when deciding on a customer hierarchy structure, usage, and maintenance. Let's take a look at these next.
Operational versus Analytical Hierarchies
Hierarchies can be maintained either at the operational level or at the analytical level depending on your MDM implementation. In analytical or operational MDM implementations, there is obviously a single option for each of them. But in enterprise MDM implementations, there is a choice.
Recall from Chapter 1 that enterprise MDM is a combination of operational and analytical MDMs. Therefore, a customer hierarchy may reside in either environment. There are advantages and disadvantages in both cases.
Customer hierarchies are traditionally more utilized at the business intelligence level. Since business intelligence is intrinsically an analytical task, HM in the analytical world has matured more quickly from a technology perspective. But some operational customer data hubs do support hierarchy associations, and many HM tools are quite independent from the underlying data repository and with means for proper integration at either level.
Knowledgeable staff is a necessity no matter where HM occurs. It is easy to underestimate the amount of experience necessary to manage customer information. Furthermore, it is a very time-consuming activity that requires a lot of data analysis and research. Research on company and contact information is mostly accomplished through two main mechanisms:
1. Internet resources, including company web sites and search engines and other information sites such as Google, Bing, Yahoo, and Wikipedia.
2. Third-party data providers, for example, D&B, Acxiom, OneSource/Infogroup, Experian, Equifax, and IXI.
Generally speaking, HM at the operational level is preferred over the analytical level for the following reasons:
- Analytical MDM is downstream from operational MDM; therefore, the hierarchy information can be more easily transferred.
- When HM is done at the analytical level, but is needed by operational teams, it must either be transferred regularly to the operational hub, or be made available through other applications and/or reports. This alternative obviously complicates maintenance.
But that is not necessarily a clear-cut decision. Other factors may drive the decision, such as:
- Technology. As stated previously, HM is a very time-consuming activity. A tool that provides a friendly graphical user interface comes a long way to facilitate and expedite hierarchy updates. Therefore, if technology is much better at the analytical level than at the operational level, this can drive the final determination.
- Access capability. The HM team obviously needs access to the data to perform their functions. But sometimes this is an issue as certain LOBs are very sensitive to operational data access and on-the-fly changes. Furthermore, hierarchies do change quite often. If a company is very sensitive to constant changes in the operational environment, it may be more appropriate to perform HM at the analytical level, and make scheduled updates in the operational environment.
- Where the information is needed. Hierarchy information is always needed for business intelligence, but depending on each LOB strategy, it can also be required at the operational level. Where the hierarchy information is needed may drive where it is best maintained.
When considering hierarchy management, take into account the overall strategy for your company as well as the adopted Customer MDM solution as a whole. Remember, MDM is about people, process, and technology, and to base a decision on just one of those elements is usually not recommended.
Single versus Multiple Hierarchies
Different LOBs may have different classification needs. Sales may have a vested interest in hierarchical organization for means of territory segmentation and sales commissions. Services may want to organize customer information to better structure service-level delivery and pricing. Finance may be interested in a legal hierarchy disposition for regulatory compliance. Marketing may want to create a hierarchy that better represents buying patterns and demographics to improve marketing campaigns.
It is doubtful that a single hierarchical representation will meet the needs of all LOBs within any large company. Multiple representations are not uncommon but add to the project's cost. Maintaining a single hierarchy can be very challenging already. As the different perspectives grow, companies risk compromising the main reason that they engaged in an MDM project in the first place: an agreed-upon view of master data across the entire company. Finding the right balance is key.
Number of Levels in the Customer Hierarchy
Most HM tools will support many levels of parent-child relationships, but more levels typically add to the complexity and the maintenance effort. On the other hand, more levels will provide a more segmented view, potentially leading to better intelligence.
Figure 10.4 depicts a hierarchy structure for a fictional Global Company with three levels shown.
Figure 10.4 Fictional Global Company Three-Level Hierarchy
But it is important to realize a given hierarchy does not necessarily need to include a level for each required segmentation, otherwise management of the hierarchy can get very convoluted. Remember that attributes are associated with the records in the hierarchy, making it possible to combine hierarchy information with data attribution to obtain desired reports. Let's take a look at an example.
Let's say a company, Comp1, has three subsidiaries: Sub1, Sub2, and Sub3. Sub1 does business in the Americas, Europe, and Asia/Pacific; Sub2 does business in the Americas and Asia/Pacific; and Sub3 does business in Europe and Asia/Pacific. Two possible hierarchy arrangements for this scenario are depicted in Figures 10.5 and 10.6.
Figure 10.5 One Possible Hierarchy Structure for a Company (Comp1)
Figure 10.6 Another Possible Hierarchy Structure for a Company (Comp1)
Both structures are valid; however, they may be more complex than necessary. For instance, both structures have children with multiple parents. It is important not to confuse reporting needs with hierarchy structure. If it is necessary to report on Comp1 either by subsidiary or by region, it is possible to do so with a structure such as the one in Figure 10.7. It is obvious to see how a report can be generated by a subsidiary. As far as a report by region, remember that records associated with the hierarchy do have attached attributes. Country is likely one of them, making it possible to generate a report by region even though this is not explicitly maintained in the structure.
Figure 10.7 Yet Another Hierarchy Structure for a Company (Comp1)
The bottom line is: Do not complicate company hierarchy structure any more than necessary. Hierarchy maintenance is already a daunting task when the number of levels is kept low and only single parents exist. Weight your requirements carefully.
Virtual versus Physical Customer Records
A virtual record is a record that is created for the purpose of organizing other records only, like a label. It does not represent a customer engaged in a transaction as a physical record would. In essence, virtual records are entries created for the purpose of forming a skeleton for the hierarchy, to which physical records are then attached.
Some HM tools do not support the concept of virtual records; therefore, the hierarchy structure has to be created by associating physical records with each other. It can be a challenge sometimes to decide which physical record best represents a customer and/or one of its subsidiaries and set it as the parent in the tree or in a branch.
Even when a tool does not support virtual records, it is usually possible to fake it by creating a pseudo-physical record that is not really referenced by any transaction, and can be used for the purpose of labeling. But be aware that this can be dangerous, as it may be difficult to control how the pseudo-physical record is used outside of the HM scope. Before you know it, users will be consuming the pseudo-record as a real customer.
The advantage of virtual records is the capability to create a structure that is independent from the existing customer records. For example, the fictional Global Company structure on Figure 10.4 can be created with virtual records even if you don't do business with every single subsidiary. But as you increase your reach, the structure is ready.
On the other hand, virtual records add to the volume of data and consequently increase maintenance effort. If entity resolution is performed at efficient levels, it may be beneficial to stick with physical records only, since the definition of a parent will be facilitated by a higher level of data de-duplication. But if not, the use of virtual records may be more advantageous. Be realistic about the quality level of your data when making a decision as to which is best for your company.
Legal versus Non-Legal Hierarchies
Companies are formed as legal structures. The factors driving the legal establishment of a company are typically tax liability, ability to borrow money or attract investors, and legal liability protection and jurisdiction. These motivators are not necessarily the same as the ones driving the selling relationships developed by that company. Therefore, mimicking your customer hierarchy on a legal model may not always be the best approach.
Ultimately, a legal structure is determined by outside forces while a customer hierarchy may be more effective when it takes into consideration internal strategies and a very specific and unique ongoing relationship with that company. A non-legal hierarchy is also known as account hierarchy if it represents mostly a selling view of the association.
Some third-party data providers, such as D&B, sell company legal structure information and some HM tools will include integration with those data providers, making it easier to create an internal customer hierarchy based on a legal model. But as stated previously, that is not necessarily the best for your company.
A typical approach is to maintain both a legal and a non-legal hierarchy. The non-legal hierarchy sometimes has gaps because of sparse business endeavors. In these cases, it may be desirable to use the legal hierarchy as a complement.
As we discussed previously in this chapter, the classification needs of each LOB can be quite different, but maintaining multiple hierarchies is very resource intensive. Adopting a legal hierarchy and a single non-legal hierarchy may be the happy medium desired, but evaluate your needs carefully.