Skip to Content

The situation will be familiar to many SAP consultants working on projects within large multinational companies. You need to manage your way though large and complex landscapes that often span different continents. Changes are managed by a collection of in-house development teams and outsourced entities. The company might have a template solution that needs to be rolled out to other countries, and thus they adhere to a strict governance mechanism in order to control changes throughout the system landscape.

Rev-Trac is often used as a platform in order to control transports throughout complex system landscapes.  It is used to manage risk and change control throughout a wide array of SAP instances, through fully automated approval workflows. Personally, I think it’s quite a good system, but it needs to be configured correctly, and as with SAP in general, over-customisation can cause its own issues. 

Based on past experience, one of the typical problems to overcome when using a tool such as Rev-Trac – or indeed any automated approval mechanism – is how to construct a  governance mechanism that enforces accountability, but isn’t overly cumbersome . A governance procedure that involves too many approval mechanisms can result in diminised accountabilty, and exactly the opposite of what is originally intended.

 

Diffusion of Responsibility

The problem with too many approvals is that accountability for a change gets diffused throughout a large group of people. This social phenomenon – Diffusion of responsibility – tends to occur in groups of people above a certain critical size where responsibility is not explicitly assigned. 

The phenomenon rarely occurs in small groups of three or fewer. Research has found that in  such groups everyone in the group takes action, as opposed to groups of ten or more where in most tests no one takes action. 

It’s the same scenario where e-mail requests for help sent to multiple people often gets a slower response than if individual emails are sent. 

Social psychologists have been studying the diffusion of responsibility effect ever since Darley and Latané’s (1970) influential studies that were motivated in part by the murder of Kitty Genovese in full view of up to thirty-eight (although this figure is disputed) bystanders who did nothing to help.  The case of Kitty Genovese describes the Bystander Effect.

 

Bystander Effect 

In 1964, a dozen or so people in Queens, New York, witnessed the murder of one of their neighbors, a young woman named Kitty Genovese. A serial killer attacked and stabbed Genovese late one night outside her apartment. When the police investigated the murder they found a dozen or so individuals nearby had heard or observed portions of the attack. Yet no one intervened or called the police. 

Social physhologists researching this case (and what’s called the Bystander effect) focused on two major factors:

1) Pluralistic Ignorance – One of the basic principles of social influence, is that bystanders monitor the reactions of other people in situations to check with others do and whether it is necessary to intervene. If everyone is doing the same thing i.e.nothing, they all conclude from the inaction of others that action is not needed.

2) Diffusion of Responsibility –  As outlined above, can occur when observers all assume that someone else is going to intervene, and so each individual feels less responsible and refrains from doing anything (as was the case with Kitty Genovese).

These factors can often manifest themselves in projects and within change approval mechanisms. Approvers may feel it is the responsibility of others to investigate the changes (e.g. objects in a transport etc), and can thus absolve themselves of responsibility. They also might feed that if others do not intervene and perhaps question the validity or otherwise of a proposed change, then it’s not up to them to request investigation. Cultural biases and the status of those requesting changes can also play a role here.  

 

Solving this problem 

Diffusion of responsibility is seen as a ”volunteer dilemma” wherein the probability that a rational person will volunteer to produce a public good decreases with group size. The fundamental part of this dilemma is that the utility (measue of satisfaction) of not volunteering is higher than the utility of volunteering, assuming someone else has volunteered.

The key to making the dilemma (and the diffusion of responsibility) disappear lies in increasing either the cost of not volunteering (i.e., of shirking) or the personal gain from choosing to respond. This can be done in 3 ways:

1) Ensure responsibility to approve specific changes is explicitely designated to a small group of individuals. Approval steps, where possible, should consists of three or fewer individuals.

2) Try to ensure, that the responsibility of each approver is clearly outlined. When their role in an approval mechanism is ambiguous, people become uncertain about what to do and the basic principle of social influence can occur i.e. what did everyone else do – ‘if they approved things so should I’. 

3) Ensure people are addressed by name. Having an approver as ‘Functional Expert 1’, or ‘Technical Approval’, can allow others to distance themselves from changes, as they names are not associated with approval. 

Formal change control processes are necessary to ensure changes are implemented in a controlled and coordinated manner. Their structure and implementation, however, needs to take into account social phenomenon, and the utility people gain from specific choices. Neglecting these, and relying on technology alone can have serious unintended consequences. 

 

For more on the Kitty Genovese, check this documentary from BBC Radio 4. 

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Rick Porter
    In being privy to hundreds of SAP change control processes over the years (as Rev-Trac consultants and advisors) we have seen many different approaches to approval workflow – from the mass email technique (to make sure someone gets the approval request) through to the targeted approach so narrow that the one person becomes a bottleneck to the frustration to the rest of the team.

    As pointed out, neither are even close to best practice and open to reduced accountability rather than increased due diligence.

    Correctly configured however, Rev-Trac as a change control technology can work with the social phenomenon Richard mentions.

    In particular the three areas specifically highlighted.

    1) Ensure responsibility to approve specific changes is explicitly designated to a small group of individuals. Approval steps, where possible, should consist of three or fewer individuals.

    Rev-Trac configuration can target approvers based on approval requirements be it a small group where multiple approvals are required or individuals.

    2) Try to ensure, that the responsibility of each approver is clearly outlined. When their role in an approval mechanism is ambiguous, people become uncertain about what to do and the basic principle of social influence can occur i.e. what did everyone else do – ‘if they approved things so should I’.

    Rev-Trac workflow emails can be descriptive and targeted reducing the potential socially influenced decision making

    3) Ensure people are addressed by name. Having an approver as ‘Functional Expert 1’, or ‘Technical Approval’, can allow others to distance themselves from changes, as they names are not associated with approval.

    As per point 2 above, Rev-Trac workflow emails can be personalised further reducing the thought of ‘opting out’ of the approval process

    Although Rev-Trac technology significantly improves the way change is controlled for many SAP change teams around the world, consideration of the points raised by Richard in its configuration can certainly improve control.

    (0) 
    1. richard fahey Post author
      Thanks for expanding on the points above.

      My central argument is essentially that the law of diminishing returns occurs after a certain number of approval steps. For each additional unit (i.e. approval) there yields smaller and smaller increases in output, which thus reduces productivity and accountability.

      (0) 
      1. Rick Porter
        Different types of change require different – and sometimes additional – approval steps to ensure PRD system stability when the change is promoted to PRD.
        Major ABAP program change should follow a more robust change control process than, for example, a simple change to a report layout.
        The major ABAP program change should require additional approval steps with each approval step requiring an appropriate signatory. To reduce the number of steps based on an expected diminishing return may very well increase the risk of PRD system damage due to less than required due diligence.
        I do agree however, that the fewer steps needed to achieve the result the better.
        (0) 

Leave a Reply