We are at the end of an ERP system implementation project, a month until we go live, our system integrator is taking the final steps to fine-tuning the new system, tests are coming to the end, the migration of historical data is ready to be performed, the interfaces with legacy systems have been tested and they work as expected. However two important activities still remain to realize, they seem to have nothing in common apparently be but indeed they are deeply linked, we are speaking about training and user profiling.One of the most common mistakes is to consider user profiling a merely technical activity and, in fact, when it is considered in this way, it just becomes a necessity to perform just to go live.
In these circumstances, the profiles are made with wide access to the system features to minimize the risk of continuous help desk calls caused by access problems; the constraints regarding to the segregation of duties, and even the needs to limit the data access are not considered at all.
So the engineering of the roles in the system has not be done, but this course of action is just a delay of this kind of activity as once the new system has gone live, soon we will achieve that the re-engineering of roles must be done quickly, (once again!!) and maybe upon recommendation of the internal audit with all the related pressures.
I spoke about the relationship between training and user profiling, as also the identification of training needs answers to the same basic simple question that is the basis of preparation of the authorization roles: Who does what?
The starting point is once again organizational and is not an IT concern. Realizing roles without proper process mapping is like trying to start from the roof in the construction of an house. The solid foundation is the identification, within defined processes, of the activities to be carried out into the system by an “operational job”. The operational job is just an authorization tool to define the proper access to the proper people.
The formalization in RACI, or RAPID, matrices allow a faster verification of the authorizations by the process owner. The use of authorization objects (as organizational units, type of material, cost centers ect.), enables the implementation of the organization to work in the different functions and/or the ability to govern access privileges to data considered “sensitive” by the company.
The next step, that seems apparently easy and immediate, is to associate these privileges with the names and surnames of people. The list of users accessing the system will have to be associated with the different “operational jobs”. The authorization specialist will create general roles to minimize redundancies and duplication of operations; the declination for authorization objects will be done through a derivation of roles from the general ones. In this way any subsequent changes will be applied to the general roles and the derived ones will “inherit” these changes.
Once the names have been associated with different operational jobs we could immediately understand that to design training courses targeted for users that will operate the new system will be a very easy task.
The last step that should not to be overlooked is testing these roles. In some situations, the training will be used also to perform these tests, this approach is highly discouraged for several reasons, the first is that it could cause considerable drawbacks in the training delivery in case of any malfunctions and the second is that we can give the perception to the users that nothing is working properly with the risk of spreading rumors about inefficiency of the new system.
The project manager should always take into account this two responsibilities: to ensure the correct access to users and to guarantee the proper segregation of duties to the organization.
Andrea Gribaudo
