In an idealistic world all five of our key analysis contexts (see Part One in this series) would align such that they are all essentially the same thing, here’s a totally hypothetical example:
| Business Process |
provide transportation for city commuters |
| (Business) Task |
transport city commuters from their departure to destination points |
| (User) Activity |
I as a Commuter want to travel from A to B in the city |
| (User) Interaction |
self-service: I set my destination B on the city teleporter & press ‘GO’ |
| Operation |
when the commuter presses ‘GO’ then teleport them from A to B |
Of course this perfect alignment where each context is synonymous with the others is idealistic and it’s never the case in a real life. But it serves the purpose to demonstrate that a high degree of context synonymity equates to better alignment between the goals of the organisation and the efficiency in the delivery of these goals, it also implies a high degree of relevance from the business measurements and reporting.
The above simplification overlooks the fact that there can be anything from a handful to hundreds of separate Tasks in any one Business Process. Ideally we might wish to design fewer to lower the operational costs and ongoing management overheads. But it is also important to have multiple Tasks that can be reorganised rather than a single Task ‘black box’ that only does one thing. The right balance can be found by checking that there are enough component Tasks to support business adaptability and innovation.
I check suitability for adaptability and innovation by generating a number of future scenarios against which the flexibility/rigidity or otherwise of the process can be tested. This need for alignment carries on down the context tree and requires the same balance should exist when assigning Activities to Tasks.
This is harder to do and often organisations have excessive numbers of Activities supporting a single Task. A common example of where Activities proliferate is where a frontline call-centre team doing customer service is not trusted to do a process that involves an expensive computer application, maybe it’s one with a wide range of ‘power functions’, and as a result all customers get transferred to a ‘special team’ who are the trusted ones.
In this situation the use of specialist teams is a proliferation of Activities with no basis in flexibility or innovation, in fact it creates a much more rigid and fragile organisational design. It simply masks an IT failure to meet the business needs and is an example of the organisational design being dictated by the features of a computer system! I have seen many organisations that are designed this way and appear to be ignorant of the expense and wider issues. Such organisations have potential for massive improvements in their operations and business models.
If you’re wondering about how IT can address the problem above, it is to expose key functions from the said application in a front end (optimised for usability), even possibly integrated with other task functions, or into an existing application or intranet. You should be aware that this is not expensive or difficult for most applications – even now for windows thick client apps.
Just remember that all Activities should be driven by the goals not driven by the tools. And as we go further down the context tree the problems of alignment usually become more common. For example user Interactions across different software systems are sometimes treated as wholly separate activities where the user might work on one system for a period of time processing a batch of things and then go to another system to concentrate on something else. Whereas they would have liked to used the functions from across both applications in a continuous set of synchronous interactions to carry out their Activity.
In these context alignment checks I also look for alignment in goals. It’s commonplace to find that the goals of a business task are not the same as the goals of the corresponding user interaction. This is most often due to poor organisational management of goals, e.g. conflicting bonus structures: a customer service representative is rewarded on reaching a target of15 calls per hour but they can easily do this by having a number of very short customer calls so they drop calls or transfer them regularly; this is in contrast to the business goal of reducing repeat customer calls. These targets are mutually exclusive demonstrating a lack of alignment in organisational goals.
Obviously I’m scratching the surface with these examples but this post serves to highlight the need to review the alignment across these analysis contexts. This review will report on business and organisational issues, and underpin design for improvements. In some cases it will contribute to the business case for change.
Leave a Reply