Workflow agent determination

Multi-Dimensional Roles and Responsibilities
Agent Determination using multi-dimensional Roles &
Responsibilities
Introduction
Responsibilities define the domain of Roles. Coded responsibilities are key to automated
agent determination in work flow process.
This document describes the relationships of job-roles to business objects associated to
organization structure (functional and administrative), it then focuses on an approach to
code responsibilities and thereby define a functional organization which overlays the
reporting lines defined in HR. Some software implementation aspects are defined and the
need for an agent determination service is described.
Roles and
Responsibilities
Below is what could be called the “role model”; a model that describes how a role relates to
other terms and objects of administrative and functional universe to describe how a person is
deployed in an organization and work process.
Competency/
Qualification
Task
Role
Assignbment
Position
(Job Assignment)
Person
Job
Description
Job
(Position type)
Role
Work Process
(Work Flow)
Organizational
Unit
Responsibility
Delegations
Cost
Center
Delegation of
Authority
Security
Role
Physical
Access
Responsibility
Criteria
Reporting
Dimensions
Expense Reporting
Citeria
An organization is a “union”
of positions, which are slots
for people, each of those
who perform a predefined
set of tasks.
A person, who holds a
position, is expected to
perform a series of tasks,
which are grouped into just
a few job roles.
Saved: 23 Mar 2015 - 03:56 a3/p3 Page 1 of 8
Printed: 30 Oct 2008 - 15:34 a10/p10 Pinaki Ghosh

We typically equate a role with the responsibility to execute that role and security assignments
are done accordingly.
To perform the duties of any role, authorities need to be delegated to the person in necessary
domains, associated to the role, from the supervisor. Various types of delegations are listed in
the model.
Example roles for a typical position could be:
1. Operate Plant Engineer for the reactor section of the Methocel plant
2. Safety Focal Point for Methocel plant
3. Supervisor for production operators in the Methocel plant
These roles and tasks under any position can be looked-at as in terms of operator and
operant. The Operant (Safety Focal Point) describes the nature of the role, the operation that
is to be performed. The Operator (Methocel plant) describes the domain that the operation is
performed on.
The responsibility defines the boundaries of the domain that a role is to be applied to: reactor
section, Methocel plant or production operators. So the responsibilities can be defined by data-
sets which defines the domain (example for plant – geography Continent, Country, Region,
State, City may be such a domain hierarchy)
Problem
Statement
The whole process of task assignment in work-flow software consists of being able to find “an
agent” – who holds a position and is authorized to do a task. The problem does not end there.
If there is nobody assigned to a responsibility of a task then we need to find the next broader
level which encompasses that responsibility. We would also like to find an escalation path.
So we are typically looking for 3 or more sets of agents for each task which are as following.
1. One or more agents responsible for the task
2. One or more agents responsible at a higher level for approval
3. Escalation Agent
Responsibilities
and reporting
Responsibilities define the boundaries of domains pertaining to a role in terms of dimensions of
accountability. An established method of defining accountability in Dow is to use Global
Reporting Dimensions (which can also be called as Global Responsibility Dimensions).
Accountability can thus be defined in terms of business structure, functional structure,
geographic structure etc. GRD’s will need to be extended with other classifications such as
MRO classes, company structures and groupings (tenants) and other dimensions. Extending
Global Responsibility Dimensions will provide the vocabulary to describe responsibilities in
terms of global codes.
Defining responsibilities for a role in GRD terms allows for personalization of the data in the
business object warehouse. Example: Defining the responsibility of a marketing manager in
terms of country and product groupings, now allows for reporting on the sales volume that the
manager is responsible for.

Responsibilities
and workflow:
Agent
Determination
Workflows are reflections of work processes at executable level. Work flows contain a series of
tasks (human centric or system based) strung together by some logic and some rules. Each
human centric task is executed by a responsible agent. During execution time, an agent needs
to be determined for the task. This can be done manually by having a user select the next
agent to route the work item to, or the routing can be automated.
Automated agent determination can be done in three ways:
• Leveraging existing information in the systems. Example would be a cost center owner
that is stored in the cost center record, or an MRP controller that is stored in the material
master, or a CSR desk that is stored in the customer order. In some cases SAP code is
delivered, otherwise custom code is written to follow the links to a specific user.
• Using a custom Table with some hierarchical structure which contains agent names and
based on the work-process rule the appropriate agent is chosen.
• Using responsibility rules. Rather than specifying in each material, who the responsible
administrator is, a responsibility of “Material Data Steward” can be defined for a group of
materials in a geographic area and that responsibility is then assigned to a person as
shown in the model above.
Example: From a Styrofoam customer order for a German customer, the responsible material
data steward can be determined by following the ordered material (GMID) up the product
hierarchy to a value center and by following the place code up the Geographic hierarchy to a
Management Area until a responsibility is found that is defined in both dimensions.
Responsibilities can be defined at any level in the hierarchy. One business may have MDS’s
(Material Data Stewards) defined at the level of performance center, other businesses may
choose to do assignments at value center level (performance center and value centers are 2
levels of hierarchies in the business structure).
The direction should be to either use existing information or use responsibility rules.
Issue Escalation A typical problem in agent determination is that of escalating
an issue to the next layer of management with larger
authority.
The escalation can be along reporting lines as implemented
in the HR system (administrative organization structure):
escalating to a person’s supervisor. In more general terms,
the HR reporting structure is just one of several possible
directions of escalation.
Example: a project organization may consist of nested
projects, managed under a program office. Escalation may
need to be from sub-project to project to program. As in
escalation along the HR reporting structure, this would be a
case of escalating along a single dimension.
1
2
3
(X1,Y1)
(X2,Y2)
(X3,Y3)
Functional Hierarchy or
Administrative Hierarchy for
Escalation.
Example: A purchasing organization may be organized by the classes of material types and
services that are being procured in conjunction with a geographic dimension.
In such a 2 dimensional scenario, increasing spans of responsibility can reflect the
management layer. Escalation can be to a person with the next larger span of control.

In the diagram above, 3 responsibilities have been defined as 3 sets of XYZ coordinates. They
are drawn above each other to show the increasing layers of functional management. The Z
co-ordinate is the line of delegation or authority and that defines the functional structure.
Each responsibility can be represented by a combination of dimensions (which are initially
defined in the responsibility container as “object tables” for validation purposes. We can use
“n” number of dimensions (with Y1, Y2 to Yn values for each dimensions) which transpires into
Y1 x Y2 x……..x Yn combination of responsibilities which provides enormous amount of
flexibility.
Delegation of
tasks
In the data model, a role is defined as a grouping of authorized tasks. The group is assigned to
a position and coded through responsibilities at the role level to support agent determination.
However, there are several scenarios where individual tasks/responsibilities instead of the
whole role are being delegated:
• Delegation of routine tasks to administrative personnel
• Temporary delegation of tasks during absence of the role performer.
Example: A supervisor will delegate signing of requests for Leave of Absence, but will likely not
delegate key tasks such as promoting or firing people. These tasks will be suspended during
his/her absence or be escalated.
In general, an agent determination solution needs to support partial delegations of roles. When
delegating a single task within a role, the dimensions of responsibility may not have to be
redefined. In other words: responsibilities can be defined at the role level and delegations can
be at the task level. SAP knows several methods of task delegation. The most common one is
“substitution” of the agent in the portal.
Sharing of tasks The agent, that is selected to perform a task, may in certain cases be a team of agents. This
happens in call centers, support desks etc. Users can share a work-list (inbox) and select work
items from the shared list or work items may be distributed to a group of users. An agent
determination service needs to support the assignment of tasks to a team.
Functional
organization
1
2
3
b c
a
In the organization pictured to the left, a two
dimensional responsibility plane has been
divided amongst 3 top level managers, a, b
and c.
Manager “a” has sub divided her space into 3
responsibilities, assigned to 3 further leaders
underneath her (green). Manager c divided
his space into 2 responsibilities (blue)
By assigning such responsibilities to positions
held by persons, functional hierarchies are
defined that overlay the HR reporting
structure.
The functional organization hierarchy acts as
the third “dimension” in this drawing.

These functional hierarchies extend the solid HR reporting lines with the dotted lines of
functional accountability.
Example: A transactional document such as a purchase requisition possesses attributes in
multiple dimensions (functional org, material and geography) and thus transactional
accountability can be allocated, and also a functional escalation path is defined. Ideally, at
each level, the responsibilities cover the complete domain in both dimensions. and ideally,
Responsibilities are subdivided at lower levels in the functional hierarchy. A subordinate should
not have responsibilities that are not covered by a functional superior of that person or in other
words the subordinate should not cover an area in the responsibility domain which is not
covered by the functional superior.
Administrative
Organization
The above diagram shows an administrative hierarchy – we have a scalar view which has
been mapped to a vector view. As it is seen that this model can support only one dimension.
The flexibility is also very limited since in the hierarchy we can move from one node to the next
higher node. So if we need more flexibility for purchasing purposes then we have to build and
maintain an equivalent structure in purchasing. So we have n number of structures to define
the various functional Organization which makes maintenance difficult and even then flexibility
is limited.
Implementation
considerations
Most work flow software engines supports the definition of rules. The SAP ECC classification
system supports the definition of dimensions of responsibility. A combination of the two can be
used to implement the concepts describe in this document. A single rule that uses classes of
geographic locations (plants) and the classes of procured items (MRO classes) can describe
the purchasing functional organization. Pre-requisite is that these classes are available in SAP.
(SAP Classification System)
Workflows, tasks, rules and responsibilities are core ECC SAP entities that will be shared
amongst all SAP modules. Shared use requires governance of the process (definitions of
ownership, naming conventions etc).

Check if FLOC data is available . (If not then we have to create it in the system)
Create a rule container with FLOC Class, Characteristic elements
Create a rule container with Maintenance Plant and planning plant element. The screen below has a
plant element and since the maintenance and planning plants are in the same table I added one plant
element. If the design requires two individual plant elements just let me know and one more may be
added.

Create a rule container with FLOC Class, Characteristic elements, Maintenance Plant and planning
plant element.
Ensure that some Generic job positions are available in SQ1. If not then we have to create about 5
job positions.
Tie the Job positions to Employee ID

Workflow agent determination

More Related Content

What's hot

Similar to Workflow agent determination

More from Pinaki Ghosh

Recently uploaded

Workflow agent determination