Just like any well-oiled machine, the smooth running of a streamlined and efficient SAP system depends on proper maintenance and regular servicing.
Only in the case of the former, rather than oil, it could be argued that the necessary lubricant is proper decision-making, needed to avoid decision paralysis.
And in the latter, what servicing is required depends upon the right resources being available to deal with the right tasks at the right time.
This applies to the human element of a SAP system just as much as as it does to the hardware itself. Spare the maintenance and risk clogging up the system with a backlog of stuff you might never clear out.
Skimp on the servicing and you just might have to redo what has already been done incorrectly, or, worse, rue that it was never done at all when it should have been.
Inevitably, in every SAP implementation, there comes a time when the following questions come up and need answering:
Q.What type of work is required and why?
A.Business Process Models
Q.Who needs to do it?
Q.How is it sent to them?
Q.How long have they got to do it in?
Q.What are the consequences of it not being done?
A.Escalation & Lifespan
Q.What happens next?
A.Reporting & QA
Often, though, before any of these questions can be properly addressed, there is always a fundamental question that needs tackling first:
“How should the agents of a system be defined and organised?”
In most cases the SAP HR Module provides the ideal answer: Organizational Management.
For experienced Workflow Developers or Payroll Experts this part of the HR Module should be as basic and as familiar as logging on.
To experienced Developers who have come across Workflow or other types of assigned work, such as BPEMs, the underlying concepts will be very familiar indeed.
And yet, it’s often surprising how even experienced Functional Consultants or ABAPers alike can find some of the concepts involved a little daunting.
Here are some key things that I’ve learned along the way that I try to re-use and pass on to the uninitiated on this subject whenever I can.
Tip #1: (Re-)Draw the Organizational Structure from a Work Management perspective
Sounds simple but if done right even a skeleton diagram can open up a world of discussion and highlight areas of contention for later, much more easily than a wall of text, no matter how well-structured that text may be.
Annotate this diagram and overlap the work with the people if you can. Try not to get bogged down in the details if an existing Payroll Org Structure has already been defined as this may not be appropriate for the distribution of work.
Note that Employee Assignment and User Assignment are not the same thing for exactly this reason.
Tip #2: Agree on terminology so that everyone knows what the objects within the Org Structure represents
Another self-explanatory thing to do but sometimes just agreeing on what the word ‘Team’ means can be quite an achievement in itself.
This can often flush out mismatches between the real world and the virtual world where real concepts like geographical location may have very little to do with actual work distribution in the virtual world.
Tip #3: Subdivide the Org Structure until at the lowest level there are logical groups of agents of no more than 50 individuals
Sounds obvious, but if the number of users assigned to an object is high this can lead to complications later on with higher processing costs at the expense of system performance. Don’t be afraid of multiple objects being assigned as possible agents as sometimes this is perfectly acceptable and actually desirable.
Tip #4: Decide whether agents should be assigned concurrently to more than one object
And, if so, agree on the correct weighting percentage of their assignments - Some Businesses have static Teams, others dynamic Teams. Some Businesses rotate their staff routinely, others have stratified levels with fixed paths.
The right solution might need an Org Structure that supports all of these things at once.
Tip #5: Choose the right level object to distribute work to
Typically the right level to aim at in an Org Structure is at the ‘Position’ level (Object Type ‘S ‘). This tends to be the ‘goldilocks’ zone where the granularity of the people involved and the work to be done can be finely balanced.
However there’s an additional dimension to bear in mind here: the volume of both parts of the equation.
Distribute to too few people and work may be left un-handled for too long. Distribute too much work and the people receiving it will be swamped and backlogs will ensue. So in some cases this might mean that work should be aimed at the next level up, i.e. at the ‘Org Unit’ (Object Type ‘O ‘).
In others this might mean assigning work to across other Teams, such as at the ‘Job’ level (Object Type ‘C ‘). Or in other cases this might mean that multiple objects need to combine their efforts and a combination of objects might be the right answer, e.g. multiple Positions.
It’s also important to remember that an Org Structure will always be subject to change and may have to evolve. It may need to become simpler, it may become more complex. Either way don’t be afraid of using draft ‘Plan Versions’ in the HR Module if need be and experiment.
But do be mindful that as with all things related to HR the large majority of relationships defined in the Org Structure are based on validity periods or ‘timeslices’.
This includes the answer to the second question in the list above: Agent Determination. Sometimes the people who received the work yesterday may not be the same as those who receive it today or tomorrow, but the Org Structure itself may not need to change at all to reflect this!
Solving the equation should thus be a simple matter of combining the right Team with the right Work, i.e. Team + Work = Teamwork.