MSS: Delegation....the final frontier?

[ChrisSolomon]

    Delegation...the final frontier....these are the voyages of the....sorry, wrong show. (haha) In all seriousness, delegation (also known to some as "substitution") seems to be one of those last unexplored frontiers for SAP in the area of self-services. However during almost every project I have been a part of that involved MSS, delegation gets brought up, and often times, suddenly becomes "in scope" (since many people do not even think of or remember it when they hear "MSS" because "that's just manager stuff" until actually into the project and gathering requirements). I am sure I'm not alone here, and you would think SAP was "wise" to this as well. In light of this all however, we have no standard SAP "DSS" (Delegate Self-Service? I need to copyright that! haha). Obviously, that leads to the question "why?". Is SAP really just trying to help us all stay employed by coming up with our own custom solutions? As thoughtful as  I would like to think SAP is, I think it is more because developing and providing a "standard delegation" solution would be like, as my grandfather use to say, "nailing wind to a wall".

The Baskin-Robbins of Problems?

    Baskin-Robbins is an ice cream company that is known for its "31 flavors" slogan. That's what delegation reminds me of most. It's a very simple concept (ie. ice cream), but the complexity comes in all the many "flavors" of it. At it's core, "delegation" is the same thing. It's just simply having someone act on behalf of a manager. However, I bet you could ask 100 different companies what "delegation" means to them, and you would get 100 different answers. In order to address these "flavors", you will typically make use of custom evaluation paths, custom org objects and/or custom ABAP classes, in order to "locate" the employees that the delegate should have access to view and act upon as if they were the manager of those employees. Here's just a few of the "flavors" I have come across:

Flavor #1 - I am too busy and important for this kind of work

This one is rather common...possibly the most common. Typically, your higher level managers (Directors, VP's, C-level, etc) will be too busy for the day-to-day approvals. They will want an administrative assistant/secretary to handle this for them. In the past, like it or not, it was common practice that the manager would just give their assistant their userid/password so they could do the work (and it still happens to the chagrin of security folks everywhere!).  In this day and age of SOX and auditing, however, we will want the system to know that it is in fact the assistant doing this work rather than the manager. This usually involves simply coming up with a correct evaluation path scheme for config in order for the assistant to "see" the same employees as the manager.

Flavor #5 - King for a Day

This one is fairly similar to "flavor 1" above. In this scenario, a manager is going on vacation or leave for a period of time. During that time, they want to assign their duties to one of their own team (possibly a team lead?). However, this will allow limited access of information and only for a certain time period. The team member will only act as the manager until the manager returns. Since the team member is usually already within the same organizational unit as the manager, the configuration for this is fairly easy. The work will be in building the content to be a "lite" version of the MSS role.

Flavor #15 - Manager-to-Manager "Up the Ladder"

We like it a lot when one manager selects another manager to be their delegate. This is because they are usually both "chiefs" (in OM speak) which are quite easy to find with evaluation paths. In our most simple of simple scenarios, suppose we allow a manager to assign a delegate who is a manager of an organizational unit below them. By simply building our evaluation path config to simply "find the delegate's org unit and then move up to the parent org unit", we can pretty much knock this one out of the ballpark. We like this flavor! (haha) The "twists" on this one comes if we want to limit or block visibility from the delegate to other org units under the manager.

Flavor #16 - Manager-to-Manager "All in the Family"

In this scenario, suppose we have two managers that "roll up" under the same parent org unit but are on separate "branches". One manager wants the other "across the way" manager to be their delegate. Again, this requires a little org chart climbing and scrambling via evaluation paths to get it right.

Flavor #17 - Manager-to-Manager "Hey, we're all managers here"

Another variation on the manager-to-manager flavor is when our business rules dictate that we can assign a delegate but that delegate much be a manager. This means they can be a manager anywhere else, ie. they do not have to be directly or indirectly part of our organizational branch. For instance, suppose a sales manager is good friends with an IT manager (since we all know sales guys and IT guys like to hang out together sooooo much! haha). The sales manager trusts his IT friend and wants him to be his delegate while he takes a 2 week vacation. This delegation scenario gets fairly complicated, and is probably best handled by using a custom org object (such as making a "delegate" object) and assigning it to the IT manager with the relationship back to the sales manager's org unit. This would require a lot of manual assignment however in terms of assigning the custom object and then un-assigning it later. That's just one idea of handling this though.

Flavor #768 - Free for All

Well, if you're going to ask for delegation, why not shoot for the moon??? I have actually had one client who actually does this. This is similar to the "Hey, we're all managers here" scenario but with a twist. In this case, this company allows anyone to be a delegate for a manager. It is the manager's discretion and responsibility for their choice. Of course, the delegate's access to information is very restricted to just the specific tasks they need (time approval and view to time related and some general information for the employees).Since this really is so "open", evaluation paths based on standard organizational management objects do not really do us much good. Custom code might help for business rules but would probably grow too complex. This is really a scenario where utilizing custom org objects in our evaluation paths really becomes almost the only option.

Flavor #3853 - Multiple Personalities

A manager wants to "split" their duties among delegates. For instance, a manager wants to assign one delegate to handle leave requests and general information but wants to assign a different delegate to handle timesheet approvals and travel/expeneses approvals. A "twist" on this is where a manager wants to be able to pick not only multiple delegates but also be able to assign what services each one should get. Uggg. Thankfully, I have only seen this come up once, and it was dropped after discussions of scope creep and costs to implement this.

The Devil is in the Details

    So let's say that you have nailed down and defined exactly "what" delegation means to your company....great job! But here's where the real fun begins..."How will this process work?" Typically, when a company talks "delegation", they are not simply talking about "we JUST want the delegated user to be able to see and execute work items from the other manager" (that's what is more commonly known as "substitution). SAP now provides a solution for this which we will discuss later. No, typically, the role of a delegate will involve not only taking care of workflow items from the other manager, but it will often involve having visibility to the same kinds of services and information that the other manager has as well. In effect for all intents and purposes, the delegate should appear as if they are the manager and acting on the manager's behalf. For this reason, let's consider that your solution will involve a "delegate" that needs both UWL (Universal Work List) access as well as access to some or all of the MSS iViews/applications.

    Let's look at this first from the starting point....let's say a manager wants some one to be their delegate. Sounds easy enough, eh? They just say "hey, I want so-an-so to be my delegate." Well, not quite that easy. This "simple" step can then involve any manner of things. Previously, this was largely several choreographed manual steps and assignments. Thankfully, with HCM Processes & Forms, you could automate a lot of this work as well as implement a better mechanism for tracking this, but that's another discussion. Let's consider "what" the delegate needs versus "how" they get there. This will most surely involve changing backend security where needed for the delegate. It should also involve assigning the delegate an additional portal role. Furthermore, if the delegate is already a manager, maybe you luck up and they can use a modified MSS role. However, if the delegate is not a manager, you will often times want a "MSS Lite" kind of role...maybe a "DSS" role that is really just an MSS role with a lot of details stripped out (salary, employment history, etc). And of course, you must insure that the delegate has the UWL somewhere in their portal roles if they will be involved in workflows. That pretty much covers the "content", but what about the backend changes? At some point, your backend configuration will get rather complicated as you try (and hopefully succeed! haha) to define correct evaluation paths (or a custom class) for you OADP (Object and Data Provider) so that the delegate actually sees the correct list of their newly assigned employees. The complexity of this step will depend one just which "flavor" of delegation you have as described previously. So security, content and config covered....sounds like you have everything set for the delegate to "see" what they should and be able to act on it, right? Well, what about the "how" as in "how do they use it"? This could also involve providing training for the delegate since they might not be experienced with the portal let alone MSS itself!

    Sounds like we have the solution all covered now, eh? Security, content, config, training, etc.....time to start planning the "go live" party, eh?!?!? This is gonna be cake! Well, please allow me to throw a few wrenches in your gears. (haha) What happens if the delegate (delegate A) the manager (manager 1) has selected has in fact assigned a delegate (delegate B) of their own? Should "delegate B" then see all the information from "manager 1" or only that from "delegate A"? Hmmmmm? What if the person the manager selects as their delegate is leaving the company within the time frame the manager needs them to be delegate (say the manager needs a 6 month leave but the delegate is leaving or does leave 1 month into the manager's leave)? I could go on and on with some of these "interesting considerations" I have come across. But I said we were going to have "fun" right? Well, I will let you come up with solutions of your own for these, and we will move on to even more "fun".

    If getting a person assigned correctly as a delegate sounded like a daunting task, un-assigning a delegate can be even more challenging. Let's say that a manager did select someone to be their delegate and everything we discussed before is working well (will wonders never cease?!?! haha). What happens if at some point the manager wants to un-assign that person as their delegate? (and yes, we also need to provide the manager some way in viewing what people are their delegates to first make this determination, but again, I leave that to you). How do we notify the delegate that they are no longer a delegate? How will we remove their security and portal content/roles (if necessary)? What happens if they are also a delegate for someone else so we must be careful not to remove everything from them? What happens to workflow items for the manager that the delegate had began work on or were in mid-process with them involved? These and many more are the kinds of "opportunities" that often give me nightmares, so once again, I will leave this "fun" to you. (haha)

Baby Steps or Rome wasn't Built in a Day

    I would say that often times SAP provides the "80%" solutions. That is, they build the solutions that address about 80% of the market's needs in an area. The other 20% is left to taking the standard solution and "tweaking" it as needed. However, the problem with "delegation" as touched upon in our "flavors" discussion is that I don't think there is anywhere close to an 80% common solution. I would be surprised if there was even a 50% solution that was flexible enough to even be "tweaked" to meet the other needs.

    Although SAP does not yet provide a standard "delegate self-service" solution, I do not want to mislead you into thinking they have not done anything for us in this area. A few capabilities (some more recent than others) have at least made our life easier in developing our own delegation solutions. These include:

• Custom Organizational Management (OM) objects
• Extended OADP flexibility
• UWL Substitution

    As mentioned previously in OM, we can define our own custom objects and assign them with relationships. So for example, much like the standard "chief" object/assignment, we could create a "delegate" object and assign it as needed. For instance, we could assign the "delegate" of an org unit the relationship to our "delegate" employee much like assigning a "chief" to an org unit. This gets "real interesting" however when our employee is assigned as a delegate in many areas (ie. more than one assignment).

    The ability to define "how" and "who" a manager views as employees is controlled by the OADP (Object and Data Provider) configuration found under the MSS section of the IMG. We can utilize this likewise by making our own OADP configuration for our "delegate". Previously, OADP only allowed you to configure these "views" using "evaluation paths" in a kind of "two level" approach. You would define a "primary" path to define "what" determines a manager (generally, the "chief" relationship to an "org unit" object). Then you would define a "secondary" path that determines what objects to view "down" from the point of the "manager". For example, you can define it to look down to "positions" under the manager only or "to positions and then to the holder of the positions" to get the actual employee. In effect, you are saying "here is the manager and now this is what they should see". However, this functionality has been extended. You can now define an ABAP class to use in lieu of the evaluation paths. With this ability, you are really wide open to define pretty much whatever you want. This is really great, if as mentioned previously, we want to put business rules around what a manager or delegate sees such as limiting them to seeing some org units or employees but not others.

    Lastly, the Universal Work List is really the central "hub" of a lot of the work managers do such as timesheet, vacation, and/or travel/expense approvals via the portal. This is their "window" into workflow. In the "old days", it was no easy task to re-assign workflow items to a delegate. However, in relatively recent times, SAP has added functionality to the UWL to allow someone to assign another person to their "inbox". This is a little menu option found off in the top right corner of the UWL called "Substitution". It works quite well, and puts the control in the hands of the user. They can assign and un-assign substitutions as they please. It offers more options, but I will leave that to you to explore....hey, it might actually be the "fun" I had promised you! (haha)

But hey, what about you?

    So what do you think? I would love to hear other people's experiences with delegation...your "flavor" of delegation?...your solution?...and/or your ideas for how SAP can address this gap and possibly provide us with a solution (or at least an easier "starting point")?