Wednesday, February 15, 2012

ERMS routing in detail

In last week's post, I discussed the working of the ERMS1 workflow and how the workflow works together with the rule modeler and the ERMS service manager.
I ended the post with a few complexities that might occur when using ERMS in an Interaction Center context.
Let's take a look at them one by one.

What if a user moves from one department to another? 
'Why would this even be important?', you might think. This is important, because in standard ERMS, the agent assignment is done upon receiving the email. This means that if a user moves from one department to the other, despite the change in the organisational model, the emails assigned to the agent, will keep being assigned to the agent. Still no real harm done. New emails will flow into 'his inbox' correctly based on his new assignment. This is no surprise when you think of an email as a workflow item. If you think of an email as a communication item that needs to be processed by 'someone from the department it is meant for', this seems kind of strange. Also note that it is the same the other way round. A new employee in the department will not automatically see the emails that were received before his assignment in the organisational model. 


What if you use ERMS in a B2C (Interaction Center) environment?
In the Interaction Center, email workflow items are processed using the agent inbox (former Universal Agent Inbox). The agent inbox (apparently) has quite some ERMS-specific logic, and it seems SAP has been struggling with exactly the issue as described above. Would you see an email as a a workflow item, or a communication item that needs to be processed by a group of people?

What happens if I use 'My Groups' in the IC Inbox?
This is what happens in the B2C environment:
  1. The email is received.
  2. The workflow is triggered
  3. The servicemanager is called
  4. The ERMS rule policy is processed
  5. The agent determination is performed
As the IC Inbox is based on searching for emails, you can then search for email items assigned to 'me', 'my groups' and to specific organisational units.
If you would have the agent inbox search for 'open emails assigned to me', this would be fine, but if you choose to search for emails assigned to a specific org unit or 'my groups', what the system automatically does, is determine the relevant group(s), then determine all agents assigned to the group, and then determine all emails assigned to all the agents.
This means, that emails could be mixing up between the Agent Inbox groups when agents are assigned to multiple organisational units or when agents are moved from one department to the other.
Also take a look at note 1375170. This note implements a change in the workflow so that the determined organisational unit is also saved to the workitem description. The organisational unit is mapped to a variable that can be used in an implementation of the before_search badi of the CRM_IC_INBOX_BADI badi.
 
How does the IC Inbox cope with all the workitems waiting to be processed?
Before implementation of note 1375170, when changing the organisational assignment of a user, all emails that have been determined for this user in the workflow, will stay assigned to the agent.
After implementation of note 1375170, when searching for emails assigned to 'my groups', the selection will change when the agent's organisational assignment is changed.
For non-interaction-center users, emails received and assigned to the agent will stay assigned to the agent, even after a change of the organisational assignment.

So... when implementing ERMS, I would recommend to always also implement note 1375170. This will improve both the functionality and the performance of the agent inbox.

2 comments:

  1. Hi There,

    It would be great if you could help me with the customizing steps for ERMS routing to specific agent or group & how is IDI different from ERMS?

    Regards
    Upinder

    ReplyDelete
  2. I am trying to configure ERMS for my client and facing couple of issue listed below:

    1) If the incoming email is not associated with a BP in the system, it does not create service ticket/interaction record. I understand this is standard functionality, however, would like to understand of there is a workaround without development to create business object (without having BP in the system) for an incoming email.

    2) when a business object(interaction record) is created based on incoming email (and rule), and when i click on the email link on IC, it navigates to the next page but the view does not contain any information and is blank & disabled.I am wondering how should the standard screen look and what is the standard functionality for an incoming email with rule (auto acknowledgement, create service ticket and interaction record).

    ReplyDelete