Business Process Performance

SAP Nav for Utilities

SAP for Utilites

New people I meet generally tend not to believe me when I tell them I have a terrible sense of direction.

Biologically, a good sense of direction is based on your ability to take advantage of environmental clues.

The most skilled navigators like the Bear Grylls of the world, mentally update their geographical position by keeping track of visual evidence. I can remember numbers and road names but using landmarks or remembering routes just doesn't work for me.

If you've ever visited Canada, you’ll agree with me when I say that the grid layout of the road is really helpful. (i.e. I have a 1 in 4 chance of getting it right!)

So... I decided to walk back from the office I was visiting and I have walked this route 4 times before. Simple right?..That wasn't quite the case..

By the time I got to the hotel I'd not only walked an extra 2 hours than anticipated, it was dark, -18 degrees and I was ready for my first cup of coffee in 28 years. I felt like I'd been wandering around the Canadian wilderness lost for hours.

The funny thing is navigation doesn't only apply to roads, finding your way around SAP software is equally a laborious and complicated task.

IS-U has over 100,000 transactions and probably around 100 relevant transaction codes (T Codes) a user may have to remember in order to resolve customer queries and exceptions.

It is inefficient when a user is spending time searching for the data they require, extending their handling time and it is frustrating to not be able to find what you need.

To assist me when I'm driving or even walking these days I can use navigational software like my Sat Nav® or Google Maps.

The SAP world is no different.

I can use data models of course to help me understand the context of each transaction and where it relates to, (I.e. the device or billing but without hours of training it’s not really that useful).

Why would you spend hours learning all the transactions with a high risk, when you can use a solution that ties all the transaction codes together, in context and gives you appropriate names to enable a user to simply find and execute the transactions they require?

A 360 degree view of your customers in your SAP system.

If you’re able to pull all the relevant data into one handy place and get a complete 360 degree view of the customer, you can enable a user to find all the necessary information required to investigate and resolve a customer’s account.

This is exactly what BDEx does!

If you want to improve customer experience and reduce operational overhead, BDEx contains over 350 different pre-packaged actions accessible with a single click.

You can easily navigate through SAP IS-U and really cut out all the unnecessary steps which have extended work processes and resolution times of exceptions.

This tool has been proven to reduce average handling times by up to 50% and improve first call resolution by up to 42% for customers such as Puget Sound Energy and American Water.

Make your users happier by giving them useful tools to help them work more efficiently and smarter, increasing productivity and customer satisfaction overall.

Using my favourite GPS has made travelling a less stressful more enjoyable experience and in my job I frequently travel so this is a must for me.

If you want to help your users navigate from A to B faster with BDEx and make their job easier, sign up for our webinar "Deliver true customer-centric service for Utilities running SAP" on September the 9th and get a sneak preview of BDEx 4.0 before it is launched at the SAP for Utilities Conference, Huntington Beach, in September.

5 Tips on using an Organizational Structure in SAP for Work Distribution

5 tips on using an organizational structure

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? A.Agent Determination
Q.How is it sent to them? A.Inbox Solution
Q.How long have they got to do it in? A.Deadline Monitoring
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.

Subscribe to RSS - Business Process Performance