The gatekeeper will need to work with a person with good data profiling skills who, ideally, should already be part of the MDM core team or a member of the IT group who is supporting the MDM initiative. This person will be needed to help compile user access data and produce the end reports or views in the formats we'll be describing here. This person should also be aware of, or should inquire about, any data profiling, IAM-oriented, or MDM-oriented tools that may be available in the company and able to be utilized for any of the preparation, profiling, and reporting tasks involved in this process. Any technology that can greatly assist with the extensibility, repeatability, and automation of this process should not be overlooked.
With or without technology assistance, there are basic ingredients needed in the data access management process for preparation of the gatekeeper role. This includes employee data, user access management requirements, user group names, and the mapping of this information.
Employee Data
This comes in two flavors:
1. Employee access data. This data should cover all users with any assigned privileges (the privileges may also be referred to as responsibilities or rights) that allow any form of create, update, delete, or read-only capability with the customer master data. This data should include at least the employee name, employee ID, and the assigned privileges.
2. Employee HR data. This data will provide additional internal information about the employee. This should include data such as employee name, employee ID, company e-mail address, department number, manager name, and job title. This data will be combined with the employee access data to create the information needed to enable the gatekeeper to create the user access profiles needed for the access review, audits, and monitoring processes.
The MDM core team or the data governance council may need to work with IT and HR to ensure that this data will remain confidential and secure with the business gatekeeper role. The MDM team or governance council requesting this type of data should not come as a surprise to either IT or HR. In the planning stages for MDM initiative and in preparing the data governance charter, these needs should have already been discussed and expectations set.
Access Management Requirements
Having an integrated application with various functional groups sharing a common customer master means that there will be many user roles with various data access requirements that will need to be identified and managed. The gatekeeper will need to build a matrix that aligns user roles with the type of access requirements they have for the customer master data. Table 7.1 provides an example of this.
Table 7.1 User Access Requirements.
In a case where the customer master environment and user access assignments have existed prior to the MDM or data governance initiatives, check to see if this type of requirement information may already exist with the planning and implementation of that system. If this information doesn't exist, it will be necessary to create the matrix shown in Table 7.1 from scratch. Depending on a company's operational model, how job roles are defined, and how the system and data access privileges are defined, the matrix that you create could look very different than the example we have provided. What's important in any scenario is that this matrix will provide a high-level mapping between the user roles and their access requirements, which can serve as general guidance for what type of privileges should or should not be assigned to users.
Keep in mind that the privileges in combination with the associated user interface will dictate the specific views and functionality that the user will have. Default privileges that an application offers often do not fully align with the access requirements and restrictions needed, which is why the matrix will help provide a basis for evaluating this. For example, in an integrated application suite the default access privilege for an account manager or a telemarketing agent may be too broad and allow them to have create and update privileges when, per the company's business processes and job role guidelines, they should only be able to read and update specific customer data. In this case, the data access gatekeeper should work with IT to modify the privilege to be aligned to the business practice and associated guidelines.
As previously mentioned, access requirements may also be bound by SoD rules that limit ability to access or change customer data. For example, SoD rules may allow a contracts administrator role the ability to create and update the contract data but restricts this user to read-only access to the customer data. Depending on how a company handles their SOX compliance process, it may be necessary for the data access gatekeeper to be involved in management of the SoD rules. We'll touch more on this subject later in the chapter.
Add User Group Names
From the HR information, the job title or department name won't usually reflect the commonly used name for a user's functional group. A functional group name may include a geographic or regional element and may be more specific to a particular type of role. For example, a person with a Customer Care Agent job title may be in a functional group called North America Sales and Services, or a person with a Data Steward job title may be in a group called Asia Pacific Customer Operations, and so on.
This user group name is what will most often be referred to in internal meetings, presentations, planning, issues management, or other types of general interaction with users and teams. As the common identity for the user group, it is important for the gatekeeper to recognize this group name and map it in with the other employee information. Table 7.2 provides an example of mapping the user group name to the other employee information.
Table 7.2 User Group Names.
Depending on the size of the company and number of users that have requirements for access to the customer master data, this mapping exercise could be quite time-consuming. If a large task is anticipated, this is a perfect example of when to engage the functional area data stewards to help size the effort and assist as needed.
Map Privileges to Requirement Categories
There are usually default user access privileges that come with the application. These privileges provide the capabilities for a user to read, create, update, delete, or maintain the data. For access to the customer master data there could be only a few default privileges or, with an integrated business suite, there may be privileges specific to the customer master module itself as well as privileges for other modules such as quoting, order management, customer support, or finance functions. These functions also include capability to create, update, or delete customer master data. All privileges that can access the customer master data need to be identified and provided in the user access data that IT supplies. Recall that in Chapter 4 we discussed the need for a data entry point matrix (Table 4.1). This matrix can serve as a baseline and cross-reference point to determine if the access data IT provided includes these entry points.
These default privileges can have rather cryptic names, which may not provide much indication of the specific type of access being granted; therefore, there will probably be a need to map these privileges to the capability categories (i.e., read, create, update, delete, maintain) in order to better relate these privileges to the gatekeeping process. Doing this can also greatly simplify the displayed results from the profiling activity. Table 7.3 provides an example of this type of mapping.
Table 7.3 Privileges Mapped to Capabilities.
Once this preparation and mapping is completed, you are ready to start profiling the data.