02-23-2013 12:17 PM
Ideally workshops are held with business to (1) Map Transactions to Activities, (2) Map Activities to Roles, and (3) Map Roles to Positions. Following from this the SAP users will then be allocated to their respective positions and inherit said roles. Please advise me where and how SAP training fits into this equation?
02-23-2013 8:53 PM
Hi,
That is one method of doing it, typically on IT-led programs rather than business change led ones.
Classical organisational design flips that over:
ID the jobs that operate the process
ID the positions that perform the jobs (position being a function of job and location)
Map the activities that the jobs will do
ID how are those activities performed (some are SAP, some are manual). Only at this point the tx are mapped to roles which can represent positions, jobs, tasks, activities etc.
That doesn't address your question though.
Training can happen at a number of points in both models. Most typical is once the the positions to access/roles have been identified as there is no point in training until it's known what users are doing. It may be that there is a course for each activity or you may choose to do it at the role, job or position level.
02-23-2013 8:53 PM
Hi,
That is one method of doing it, typically on IT-led programs rather than business change led ones.
Classical organisational design flips that over:
ID the jobs that operate the process
ID the positions that perform the jobs (position being a function of job and location)
Map the activities that the jobs will do
ID how are those activities performed (some are SAP, some are manual). Only at this point the tx are mapped to roles which can represent positions, jobs, tasks, activities etc.
That doesn't address your question though.
Training can happen at a number of points in both models. Most typical is once the the positions to access/roles have been identified as there is no point in training until it's known what users are doing. It may be that there is a course for each activity or you may choose to do it at the role, job or position level.
02-24-2013 8:47 AM
02-24-2013 9:19 AM
Ideal is to have good "bridging consultants" between the business requirements and the technical build who know what impact the choice of transaction code has on the complexity of the role.
This can influence whether the role is "idiot proof" and training is not required (like an ESS service) or whether a proof of training or even a successful test result is required before the role may be assigned (like the key user role of a production plant which can explode if mistakes are made...).
A useful little trick is also to perform (internal) license classification via roles and allocate costs based on the roles assigned. The owners of the organizational elements of the roles have an incentive that the functional capabilities of the roles are correct and only assigned to employees who know how to make good use of them. A lot of dead wood sorts itself out that way on a continious basis... 🙂
Cheers,
Julius