Down Under: The Importance of Clearly Understanding End-to-End Processes

Sometimes the lack of simplicity and clarity in a BPM project can be the thing that creates the highest risks. You would think that it would be simple to clearly define what the scope of a project is by determining the start and end of the processes that relate to the BPM project. The most important word in the title of this Column is “clearly”. Too many BPM activities commence, and continue, without having a clear and agreed definition of when a process starts and ends, and the question is not asked “is this start and end point appropriate for what you are trying to achieve?” as an outcome of the project.

This clarity is particularly important for the following reasons:

  1. your project scope will change depending upon the start or end points; you risk attempting to solve the wrong business problem, or not achieving the desired project outcomes;
  2. lack of clarity of the process will make it more difficult to identify hand over, cross-over and process rub points, and maybe the services the process delivers;
  3. restructuring / redesigning processes is easier if you have a clear understanding of the end to end processes; and
  4. certainly business analysis is made simpler with clarity.

On a more holistic business level the challenges of not having current and clear end to end processes can include:

  1. In times of significant business change and volatility, knowledge may be 'walking out the door' as employees depart, particularly if processes are not documented well.
  2. Changing employee situations often necessitates the need to backfill roles. Even with process documentation there is a ramp up period for any new person to be effective. Without process documentation the ramp up time is considerably longer.
  3. If your BPM activity encompasses multiple business processes, it is critical you have a clear understanding of how the processes fit together, and identify clearly the hand off points.
  4. Finding efficiencies in (or leaning) work practices is far easier when an organization has 'as is' processes and can make the journey to the 'to be' leaned processes.

Let's look at a couple of case studies.

Government department: a project in the procurement area was underway and the project sponsor, the Chief Financial Officer (CFO), was not happy with the progress being made. He called in a consultant to replace the project manager (the procurement manager). After several days the new project manager realized that the project scope seemed to be continually changing and this was confusing the project team. Decisions as to what needed to be achieved seemed to be continually changing and evolving.

The project manager decided to meet with the project sponsor (the CFO) to gain additional project clarity because he perceived that the project sponsor did not have clarity around the procurement project start and end points.

The project sponsor was initially annoyed that he was being asked this 'obvious' question, however as the conversation continued he realised why it was important and admitted that he was not sure where the commencement point should be. Further discussion agreed the start and end points.

Once the start and end points were agreed the project started to make significant progress.

On this project, and with the particular stakeholders involved, it was essential to maintain the Decision Register which maintained the decisions made, by whom, dates, the reasons for the decision, as well as other details. Each time the sponsor made a decision that conflicted with previous decisions, the register was referenced. It was the prerogative of the project sponsor to change his mind. It was important for him to understand the consequences and the project impacts. This had the desired result of ensuring the sponsor didn't change his mind too often and allowed the project team to make significant progress and achieve the desired project outcomes.

Energy organization: the project team was asked to look at the Collections process. The KPI for the collection of payments was set at 28 days. The current actual average collection time was 45 days. The project team were asked to look at the collection process and fix it to achieve the KPI target.

After some analysis it was discovered that no matter how much the project team worked on and improved the collections process they would never achieve the KPI target. The problem had nothing to do with the collections process, it was the manual based Meter Reading process that was broken.

The meter reading staff were making mistakes and causing customers to receive incorrect and disproportionately large invoices, for example, up to $7,000 when their normal invoice was $1,000. By the time clients progressed through the complaints process the KPI target was unachievable.

An understanding of the 'true' end-to-end process and an increase in project scope to include the meter reading process fixed the project problems and enabled the achievement of the collection KPI target.

Business Case development: one of the authors became briefly associated with the development of a business case to go to tender for an Enterprise Resource Planning (ERP) system. The project team were mapping the business processes and attributing various metrics to the processes with a view of determining the potential savings associated with a change to a new ERP.

It was found that the project team had no process taxonomy and were indeed mapping various sub-processes with no understanding of how the sub-processes fitted together. This made the metrics analysis and identification of the potential cost savings significantly problematic, thus impacting the quality of the business case for change.

How are these situations avoided?

If an organization has a process asset and an understanding of their process taxonomy then they have a fighting chance of understanding its processes better and an ability to scope projects more effectively.

If the organization doesn't have a process taxonomy then the project team needs to firstly determine the part of the taxonomy effecting the business area they are concerned with. This is an essential scoping exercise before the project commences. To us, it is a critical aspect of project risk management.

John Jeston & Gina Craig

John Jeston & Gina Craig

John has serious experience getting things done—the right way. For over 30 years he has covered Business Process Management (BPM), business process re-engineering, project management, systems development, outsourcing, and general management. He has held the positions of Financial Controller, Divisional Manager, Company Director, HR Director and Chief Information Officer. John is internationally recognised as a key opinion leader in BPM strategy and implementation. He has provided these services to significant organisations throughout Australia, Europe, Saudi Arabia, Dubai, the United Kingdom, U.S.A., Singapore, Mexico and Brazil. He has authored a number of books and more than 20 articles on BPM and high performance management. He is a regular speaker at conferences and a Master Project Director, with the Australian Institute of Project Management and is a Chartered Accountant. John has authored or co-authored: Business Process Management: Practical Guidelines to Successful Implementations (2006 and 2008), Management by Process: A Roadmap to Sustainable Business Process Management (2008)—the only book to provide a roadmap to sustainable BPM and High Performance Management, and Beyond Business Process Improvement, On To Business Transformation (2009). He also writes a regular Column in the international BP Trends Monthly Update. He can be reached at johnjeston@managementbyprocess.com Gina has 30 years experience as an adult teacher, trainer, facilitator, designer of training courses, writer and senior manager. Gina has provided these services to the higher education sector, private enterprise and large and complex government agencies. Gina has proven expertise in the creation of, and transformation to, an extremely large and complex shared services environment. She then demonstrated that the new entity was designed and structured correctly by successfully managing the largest team within that entity. She also leaned the processes within the entity to find work and workforce efficiencies. Gina has also been a lecturer and tutor with University of New South Wales, Australia where she lectured and tutored economics, calculus, statistics and accounting; managed and supported a Learning Management System and Learner Content Management System; lead and managed large teams of 100 plus staff; and managed numerous projects some of which resulted in $10’sm in savings. Gina's consulting, communication and relationship skills enable her to successfully manage and mentor individuals and teams.
FacebookTwitterGoogle+Share

Comments

  1. Eric Tweedy says:

    “Process taxonomy?” A “taxonomy” is a nomenclature used to assign objects to classifications. Objects themselves are categorized using a taxonomy, but as a set, they do not constitute a taxonomy. I suggest that for a set of processes, we might refer to a “process inventory” and go on to suggest heuristics by which we could make the identification and classification of the processes most useful for process engineering.

Speak Your Mind

*