Firstly, let’s get the words right.  Digitisation just means converting physical information into a digital format whereas digitalisation means using digitisation to improve business processes, so do not muddle them up!  RPA stands for Robotic Process Automation and is a key market focus for digitalisation software vendors.

RPA has really caught on in recent times.  Probably because software vendors identified a niche which is easier than BPMS (Business Process Management Systems) which cover end-to-end processes. RPA deals with high volume repetitive sub-processes, activities and procedures.  It is attractive to businesses because it is quicker and cheaper to start digitalisation using RPA.

The intent of BPM is to optimise processes end-to-end and that really is where process innovation occurs. To just dive into low level process automation using RPA will provide immediate automation benefits but may in the end defeat the ability to innovate and optimise the end-to-end process.

So, a good approach is to use BPM to design the new innovated end-to-end process, then pick the pain points for RPA projects. 

The counter argument is that you can still do BPM and process innovation later and include earlier automated procedures.  Nice theory but by then the task level procedures or sub-processes have been automated and you are locked into that way of doing things. So, you never know what innovation chances you have missed.

The other RPA trap is that existing manual or desktop processes are automated with minimal improvement, so you miss both innovation and some process improvement.

Those who have been doing RPA successfully for a while will tell you that you must still do the hard process design work.

The post How to use RPA in implementing a business led enterprise digitalisation strategy appeared first on Business Processes Australia.

These situations arise because organisations are sold on an IT solution rather than a business solution.  A business solution starts with the process – how the work is done – rather than the technology – which is a platform for the business solution.  Today this is happening again, RPA (Robotic Process Automation) solutions are being sold as a major leap forward.  RPA is good technology, but that means it can be even more effective and quicker at implementing the wrong process!  Get the process right first, then apply RPA and you really will get quantum leaps in efficiencies and customer value.  Those who have worked with RPA successfully will tell you that you still have to do the hard work of process optimisation.

The post Why an IT solution is not the immediate answer for improving an old business process appeared first on Business Processes Australia.

So why are we still talking about process improvement when our experience of Business Process Management (BPM) indicates strategic jumps are the normal result for process projects?  Probably because many executives and managers whose careers are functionally based are used to improvement programs that drive towards functional improvements, often of relatively modest proportions. Transformation programs can take the enterprise view and higher goals, but they often still focus on functional improvements.

The point about processes are that they are cross-functional and focused on delivery to customers, they do not falter at functional boundaries.  Process programs and projects need to be sponsored at the top of the organisation in order to avoid falling foul of functional territoriality.  As they are enterprise-wide the view changes from operational improvements and creates the opportunity for complete redesign across the organisation, yielding strategic jumps in value delivery and efficiencies.

Process improvement is worthwhile ongoing operational work, but to talk about process improvement projects is to miss the opportunity for radical change and to miss the opportunity for strategic jumps.  So please, do not talk about process improvement when you are talking about process projects, talk about radical process change, talk about process innovation.  Setting expectations high will deliver surprising and gratifying results.

The post Why process improvement is a missed opportunity, go for process innovation. appeared first on Business Processes Australia.

Using a BPM consultant will also ensure that the client’s people learn the right practical methods, tools and skills which workshop training starts out but cannot complete.  In time the consultant will no longer be required and the organisation carries on its process work with entirely internal teams.

You notice I am not advocating a team of consultants or extended engagements, that’s expensive and does not encourage internal teams to master BPM.  A single expert BPM consultant gets you best value,

The post Why you need a good BPM consultant to support an internal BPM team appeared first on Business Processes Australia.

First of all RPA is only good for highly repetitive and structured processes. For more complicated and less structured processes the use of data mining and analysis will merely extract current practices.  RPA applied without good process design will therefore merely automate current practice (AS IS) and entirely miss the opportunity to optimise processes, which BPM is designed to do.  So if you are considering introducing RPA for other than highly repetitive and structured processes then BPM is, if anything even more necessary because RPA is not the tool for redesigning processes, merely automating them.

Given RPA is not the answer does AI offer an automated alternative to BPM?  This is the more interesting question, which will not really be answered for most organisations for some time to come.  AI is a machine intelligence that so far cannot offer ‘general intelligence’ that humans display, however AI can surpass human intelligence and performance when applied to a narrow area of knowledge.  In theory therefore if the business is reasonably specialised AI might be able to improve processes over time.

However we are not there yet and what is emerging is Intelligent Automation (IA), whereby the strategic thinking is still done by humans, who use technological agents (‘Bots’) to do a lot of the time-consuming work.  This means BPM is still needed by humans for process design but after the high level design is completed the rest can be automated using RPA.  To use AI requires a lot of data and RPA can assist with this task until such time as IA can be used, and one day perhaps, AI.

The post RPA, AI – is BPM redundant? appeared first on Business Processes Australia.

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.