Process Automation Projects – What Else Could Go Wrong?
Does your organisation have a process automation agenda? We’ve all heard about the big disastrous IT projects that fail to deliver and cost £millions. But what about the ones that are perceived as successful? Is that really the end of the story? In many cases the answer is no. We will explore a number of the wider, probably unforeseen and potentially unnoticed, consequences of automating processes with IT systems. These issues will seriously detract, or even negate, the projected benefits of the project unless recognised and addressed at an early stage.
The Hidden Impact on HR Policies
Large businesses have long employed large numbers of un-skilled staff to deal with the huge volumes of simple transactional processing work that is required in their back office operations. Poorly qualified, trained only in their specific task and with little knowledge of the wider end to end process (all the way from first customer engagement to full and final satisfaction of customer requirement), these staff members have nevertheless been relentlessly toiling to carry out the tasks required of them.
As attention has focused on automating the simpler processes, there is an inherent expectation that the number of staff will reduce significantly to provide cost savings, as well as offset the cost of the automation. As this strategy evolves there will be a steady and inevitable transformation in the profile of work carried out within the operation; the simple work has gone, the work that remains is higher order, requiring greater discretion and decision making capability. This requires an associated transformation in the profile of staff – from unskilled staff to knowledge workers. The knowledge worker will require much broader and deeper skills and capabilities to deal with the more complex and diverse work that they have to deal with, as well as a more sophisticated managerial style.
The hidden danger is that this change in work profile is not overtly identified as a direct and inevitable consequence of the automation strategy. If this is the case, then HR will not be alerted to the impending transformation and the impact it will have on them. HR will not amend its policies and practices, consequently the business will continue to recruit, train, grade and reward staff in the same ways that they always have. Failure to recognise and adjust to the changing work profile could lead to years of poor delivery and under-performance in the remaining non-automated processes, with knock on effects on customer satisfaction and profitability.
This is a problem that should be considered and addressed at the very early stages of an automation strategy. HR needs to be an integral part of the project team, analysing the impact on staffing requirements from the entire automation programme in the medium to long term. HR policies and procedures can then be put in place at an early stage to ensure that the business will have the skills and capability required for the emerging work profile:
- Redundancy selection can be on the basis of ability to assimilate new skills and knowledge and thereby potential to upgrade to the knowledge worker role
- Grades can be re-based to accommodate the higher skill and qualification requirements of knowledge workers
- Rewards and incentives can be re-aligned to the new grades and the requirements of a more highly skilled workforce
- Middle managers and Team Leaders will need to be up-skilled, particularly with enhanced coaching skills needed to develop and get the most from their more highly skilled teams
- Recruitment profiles can be updated to reflect the need for knowledge workers
- The business case for the automation strategy should be adjusted to reflect the change in the workforce cost base that will result.
Indeed a fundamental change in the frontline management organisation and management philosophy will likely be required. The links in the previous sentence lead to further information on these extended topics.
Locking in Waste
A typical approach to an IT project to automate processes is for a Business Analyst to map the current process, as well as talk to key stakeholders to identify any additional business requirements. The current process with additional requirements is then fed into the development engine and the lowest cost technical solution developed.
Unfortunately, none of the people involved in this development process are likely to have operations excellence or operations improvement experience. As a result, any waste (whether it is business waste or customer effort waste) is not identified or eliminated and becomes effectively locked into the system. Any existing business waste becomes an unrealised benefit, which once locked in will likely never be realised. Moreover, the customer effort waste that exists in the current process and goes un-noticed, becoming locked into the system, will probably remain as an enduring obstacle to the business ever achieving real customer service excellence.
Fortunately, the solution to this issue is relatively easy to address, provided it is recognised and addressed at the outset of the automation strategy; prior to commencing the IT development cycle, apply operations excellence or lean thinking to the target process. Develop a future state process design as the foundation for the automation system:
- Carry out value stream mapping of the full end to end process – even if the intention is to automate only part of it
- Fully understand the customer requirements and the impact that the current process is having on the customer and the effort that they have to expend to receive the service / product.
- Use lean consumption techniques to optimise the process from the customer perspective
- Design ways to eliminate any business waste remaining in the end to end process
- Pilot and refine the future state end to end process before passing to the automation development team to ensure that the new design is fully viable and tested before committing to development
Inhibiting Flexibility
Another consequence of the typical IT development cycle, particularly the strong focus on the lowest cost technical solution, is locking out future flexibility. Many processes will need to evolve over time. This may be due to the market shifting, product changes, changes in business strategy, process improvement, regulatory requirements, evolving risk scenarios etc. However, the lowest cost technical solution often means hard coding the current design, such that any future changes to the process require a new IT project to re-code the process changes. This habit can be very entrenched, often driven by a short-term budget fixation. This is illustrated by a large UK pensions organisation that hard coded its pension calculations despite the fact that the UK government changed the details every year in their budget. As a result there was a new project every year to recode the new pension rules.
The solution is again relatively straightforward, provided it is addressed at the beginning of the automation strategy. Carefully analyse all the possible changes that could impact the process. In turn analyse the probability of each change to determine its likely frequency. Where the change is unlikely to occur for many years, the risk and consequent cost of hard coding it is low. However, where the change is likely to occur at a reasonably short interval, it makes a lot of sense to consider developing a configurable solution that will enable user updates without initiating a repeat development project. The key metric for evaluating the viability of a configurable system is whole life cost on a net present value basis.
Not Effectively Managing Exceptions
Most processes have a blend of work passing through them; the high volume standard items, medium to low volume items that are slightly more complex or different to the standard and the low volume more complex items. This phenomenon is often referred to as runners, repeaters and rarities. In an automation project it is often feasible to automate the repeaters as well as the runners. However, it is also common that the complexity and variability of the rarities does not justify the additional incremental cost to automate them. Consequently, these exceptions are typically left to be processed manually.
The complication arises when the implication of these exceptions is not fully understood or fully thought through. They are often flagged as manual only at an early stage and then simply ignored for the rest of the project. The problem is that these exceptions usually require some interface with the automation system – they may not be identified as exceptions until part way through the process, alternatively the output from their processing may require introduction into the system in order to undergo a common final step. If this has not been properly designed, it is possible for the work content of these exceptions to grow disproportionately, seriously eroding the anticipated benefit from automating the process. This can be further exacerbated if the blend of work were to change in favour of the exceptions as time progresses.
This is another example where early appropriate planning and design can ensure that a balanced solution is adopted. The outcome will be a cost effective system implementation without a large and potentially growing manual overhead.
Conclusions
These issues would not typically be considered as IT project problems, though their root cause is clearly in the automation project itself. Once these shadow problems are brought to light and added to the project agenda from the outset, their potential for disruption becomes significantly reduced. Building a broad based multi-disciplinary project team, including HR and operations excellence, is a good way to facilitate this As always, careful and innovative consideration at an early stage, of all the things that could result in the project failing to deliver the expected benefits, will be more than justified by the improved results delivered.
By Paul Thomas
Paul has been involved with operations excellence for over 20 years initially in capital equipment manufacturing and for the last 12 years in the service sector. Working with blue chip companies, Paul has been involved in operating model design and implementation, operations strategy development, operations improvement and operations capability development, as well as running the Lean Service Forum.
