It is easy to say ‘map processes at the activity level’ but what level is this?

In practice an activity can be defined at anywhere between almost a sub-process level, at what we normally mean by an activity level, and at a level that is barely above tasks level, the only difference being that no ‘how to’ is attached to the activity otherwise it would be a task.

How can you tell what level you are at? I find that defining activities at the generally accepted activity level will result in a map that can fit onto one or two pages, whereas at a low level the process stretches across multiple pages.

So which is right?

My experience is that the AS IS and TO be should be defined at the higher activity level as this avoids the trap of loosing sight of the wood for the trees and only realising marginal improvements for the TO BE. This is because people are less likely to focus on what they do (which is at task level), and are more likely to think of radical improvements. So, significant process innovation is much more likely if the analysis is done at a higher level.

If the AS IS has been done at a lower level, because people really want to explain the intricacies they have to cope with, is this a waste of time? Well, you will still need to move the discussion up to the higher level but when you have finished the AS IS, TO BE and any SYSTEM design (the TO BE modified to maximise use of a BPMS and/or functionality provided by existing enterprise applications) at the higher level you will progress to defining the procedure and business requirements. These will be developed at the task level, and at this time the insight from the more detailed AS IS will enable this to be done more quickly. So overall not much time will be wasted and the key people who do the work will feel they have been properly listened to and are more likely to ‘let go’ of current practice and focus on getting the best improvements.

The post Map at what level of activity? appeared first on Business Processes Australia.

Using portfolio and program management this organisation could be running three or more projects in parallel, albeit staggered. In terms of rapid organisational improvement this approach is essential.

The post Process Projects appeared first on Business Processes Australia.

Tony (not his real name) runs a central administration team. This team liaises with individual teams in business units, which report locally. There was good support for process change both in the central and the business unit teams and with customers, primarily because of real involvement and consultation from the start and the obvious need for improvement. Process designs, system builds and implementations went well. However once new processes were implemented it was clear that some organisational change was necessary as resources could be redeployed and process managers were required, but somehow attempts to implement the changes were forestalled and relations between the central and business unit teams deteriorated.

It appears that the business unit managers feel threatened by what they perceive as a takeover of control by the central unit manager. This is because they think that the central unit manager is reluctant to appoint a process manager who is not a direct report; despite this if a local manager is a logical appointee as process manager the local manager wants recognition of the expansion of responsibilities before taking on a process manager role in addition to their other responsibilities. There has been no resolution because it has been easier to avoid the issue.
Because the lines of control are separated this issue will only be resolved at an executive level. Leadership is required to negotiate a resolution, Tony or his boss needs to bring the parties together and go through all of the issues and work towards a solution. This has not happened because other priorities can always be pointed to as more important – after all there is no loss here, merely sub-optimisation.

The post Organisational Change following Implementation of Processes appeared first on Business Processes Australia.

To secure the business benefits will often require cross-functional leadership that only the process owner has sufficient influence and authority to undertake.
The biggest danger is when the project reports are good and the busy executive is lulled into a sense of everything being alright; that is the time to check on how the business benefit targets will be achieved.

The post Realising Business Benefits of Process Change appeared first on Business Processes Australia.