Data Stewardship
Data stewardship in a Customer or Supplier MDM application is performed by two distinct roles: data stewards and business users. Each role requires the configuration of different Web UI screens to perform certain tasks. In this topic, the roles (and the tasks performed by each) are defined and Web UI configuration guidelines are provided.
Note: When configuring any Web UI, consult the Web User Interfaces documentation here. This documentation contains details on how to add various components of the Web UI.
Role of the Data Stewards
Experienced data stewards must be provided with the proper tools to ensure data quality.
These tasks include:
- Clerical Review - Data Stewards can review potential duplicates.
- Manually maintaining records - Data Stewards update and edit records as needed.
- Monitoring / Data Quality - Data Stewards should review customer data quality in the Web UI, and monitor Source system performance.
Data Steward Tasks
Typically, Data Stewards will need to perform the following tasks: clerical review, ad hoc data stewardship, data governance, hierarchy maintenance, and attribute maintenance.
Note: The online help topics for these tasks are extensive and cover configuration and typical use.
Clerical Review
Clerical reviews allow a data steward to approve matched duplicates, reject erroneously matched records, and reassign tasks that are better suited for other users.
To assist data stewards in identifying critical issues, Clerical Review task lists can be filtered to display only high priority tasks. To flag tasks as high priority, a workflow status flag and accompanying business condition must be configured on the relevant matching algorithm.
For more information on clerical reviews, refer to the Golden Record Clerical Review Task List topic in the Matching, Linking, and Merging documentation here.
Use Cases
Arthur is a senior data steward responsible for the carrying out several data management tasks and must interact with many areas of the Web UI to do so.
When Arthur begins their day, they will first handle any clerical review tasks that may have been generated from the previous day’s activity. Some new customers coming into MDM have a risk flag set to ‘yes’, this requires Arthur’s immediate attention. Arthur is made aware of these high priority tasks through a visual cue (defined below). Arthur is then able to enter the task list and filter based on priority. This allows Arthur to immediately address the high priority clerical reviews, before continuing with their other tasks.
Components
Arthur utilizes the following components to address the story presented above:
- The Global Navigation Panel - Allows Arthur to review all clerical review tasks grouped in one central location. For more information, refer to the Global Navigation Panel Component section of the Web UI documentation here.
- Golden Record Clerical Review Task List – Allows Arthur to address deduplication tasks. More specifically, this screen allows for merging duplicate records, task reassignment, and rejecting potential duplicates.
- Advanced Merge – Allows Arthur to manually dictate survivorship by selecting individual attribute values.
Hierarchy Maintenance
Maintaining the company hierarchy is key to ensuring that data can be correctly represented across the enterprise. Using a hierarchy visualization implementation helps represent the flow of companies and how their ownership functions.
For more information on setting up and using a company hierarchy, refer to the Company Hierarchy Visualization and Maintenance topic of the Web UI documentation here.
Use Cases
A volcanic eruption has destroyed an ACME subsidiary. Arthur has been asked to remove the subsidiary from ACME’s corporate hierarchy.
Arthur navigates the subsidiary in question and selects the hierarchy tab. From this screen, Arthur can remove the link to its parental organization using built in functions.
Components
Arthur utilizes the following components to address the story above:
- Global Search – Arthur can navigate to the subsidiary based on source record ID.
- Company Hierarchy Screen – This screen allows Arthur to add, edit, and remove links throughout the hierarchy. Several different views are also available for each hierarchy.
Attribute Maintenance
Data stewards must create and maintain various attributes and attribute groups.
For more information on attributes, refer to the Attribute and LOV Creation and Maintenance in Web UI topic of the Web UI documentation here.
Use Cases
Arthur has been notified by management that an upstream SAP system is now tracking additional financial attributes (Income Verified Flag). Arthur would like to create this attribute in MDM, so they will have access to the most complete view of the customers.
To do so, Arthur will utilize the attribute maintenance screens. First, Arthur will need to identify the correct party data attribute group. Since this is new financial data, Arthur decides it belongs best in the IncomeData group. Arthur selects this group and can create the attribute using the buttons on the screen.
Components
Arthur utilizes the following components to address the story above:
- Attribute Group Management Screen – Using this screen, Arthur can view all attributes within the attribute group and judge whether the new attribute they want to create belongs there. For more information, refer to the Attribute Group Management Screen section of the Web UI documentation here.
- Attribute Link Editor Screen - Arthur can establish or remove links between attributes via this screen. For more information, refer to the Attribute Link Editor Screen section of the Web UI documentation here.
- Attribute Management Screen – Arthur can create new attributes or edit existing ones via the Attribute Management Screen. They can edit the attribute details, change the attribute validity, and maintain attribute links via various tabs configurable on this screen. For more information, refer to the Attribute Management Screen section of the Web UI documentation here.
Additional Considerations when Performing Attribute Maintenance
Update import configurations with the appropriate mappings, otherwise the new incoming data is not written to any attribute.
If the attribute does not fit into any existing attribute groups, a new group should be created first. If the attribute fits into a current display group, no Web UI configuration is needed. Standalone attributes must be manually added to the appropriate Details screens.
If the attribute should be considered during matching, adjust the algorithms and/or match codes. If the intention is for the attribute to ‘pool’ similar customers together, it should be added as a match code function. If the attribute is intended to be considered by the algorithm, a new corresponding normalizer and matcher must be added. Additionally, the rules must be updated to include how the final score provided by the algorithm is affected. In order for survivorship to properly execute, the attribute must be placed in the relevant survivorship groups.
An onboarding process may be considered to verify that all considerations have been accounted for prior to finalizing new attribute(s).
If the attribute should be monitored via data governance, update the required policies and widgets to account for it.
Role of Business User
Experienced business users need to be able to accurately search for customers to verify information, and export customer data.
Business User Tasks
Business users need to be able to maintain small areas of the database, mostly involving searching for customers to find records and exporting this data.
Advanced Search and Data Export
Business users need to be able to navigate the large amount of data in the system. To do this, they need to create customized, granular searches using a myriad of search criteria.
Nikki, a business user, has been asked to export a list of customers who have outstanding payments. To do so, Nikki utilizes an advanced search. Nikki then saves the results to a collection and uses the built-in buttons to export.
To build these search queries, refer to the Using Advanced Search topic in the Web UI documentation here.
Export the data once the data is isolated for external support. For more information, refer to the Export Manager topic of the Data Exchange documentation here.
Manual Edits
Business users may also manually edit customer information within the Web UI. One example is a business user working within a call center may receive an updated contact number from a customer. The business user may edit an existing phone number or add an additional number to the customer’s record.
While working in a call center, Nikki receives a phone call from a customer. The customer has notified Nikki that they are moving and would like to update their address to continue receiving promotional mailings. Nikki can look this customer up based on a provided loyalty card number and manually update the address. Once Nikki saves the address update, Loqate will trigger and standardize the new address.
Manual edits within the Web UI is generally carried out within the Node Details Screen.
Hierarchy Maintenance
Business users may also be responsible for maintaining company hierarchies.
Maintaining the company hierarchy is key to ensuring that data can be correctly represented across the enterprise. Using a hierarchy visualization implementation helps represent the flow of companies and how their ownership functions.
For more information on setting up and using a company hierarchy, refer to the Company Hierarchy Visualization and Maintenance topic of the Web UI documentation here.