Rationalisation != Optimisation

I know the title of this post is somewhat geeky and probably completely meaningless if you’ve never programmed a computer, and maybe even somewhat so if you have.  It says rationalisation is not the same thing as optimisation.  Although the natural thing for enterprise architects to want to do is to rationalise, rationalise, rationalise, with a view to optimise, some degree of caution should be practised when making the recommendation.

Achieving optimisation through rationalisation is predicated on two assumptions which aren’t always a given:

  1. The areas being rationalised work in exactly the same way serving the very same purpose, or at least can do.
  2. The areas being rationalised will evolve in the very same direction.

For example, there may be several parts of an organisation that manage incidents – internal IT may manage incidents raised by staff about their IT equipment, building facilities may manage incidents about physical facilities offered to staff, whilst an externally facing customer service function may be managing incidents related to customer’s consumption of services provided commercially.

An incident is an incident is an incident isn’t it? Why can’t we have just one incident management process and system to manage all of these types of incidents?

We absolutely can, but this doesn’t mean it is a good idea. There may be very different working practices between the three groups because of the way the underlying area works.  Although it may be possible to rationalise staff facing incident management processes and systems, it would probably would not be a good idea to also rationalise the customer facing incident management process and system into the same mix.  The externally facing incident management function serves a very different purpose, to satisfy customers and maintain a good reputation for the organisation, unlike the internally facing functions which there to ensure things are running smoothly to support the customer facing functions.

These functions, however, may evolve to take a different approach to customer management.  Untangling what was created when the functions were rationalised may be more difficult than and negate the value of rationalisation in the first place.  If there is a strategic view of how a function will evolve, this should be taken into account when deciding what to do.

Similarly, there may be two groups in an organisation that are doing what superficially appears to be the same thing where one of these groups subcontracts to the other.  There certainly is a case for investigating whether rationalisation is a good idea.

The key questions to be asked when proposing such a rationalisation may not be related to the group itself but how they interact with their respective upstream and downstream groups such as the artefacts produced to enable this interaction, and how much ownership the upstream/downstream group is expected to take.

If the two functions being rationalised sit within two areas of the organisation with different leadership there is also the politics that require a degree of navigation, with the leadership of one or both groups needing to relinquish a degree of ownership and control they have of their instance of function – sometimes this isn’t easy.

 

Leave a Reply

Your email address will not be published. Required fields are marked *