Introduction and Background to Business Process Management

This paper discusses some of the key aspects of Business Process Management (BPM) in the context of its application and goals; there are many reasons why an organisation may wish to map processes: reflection of a new regulatory environment, for example the General Data Protection Regulation (GDPR); to support the implementation of new systems, for example an Enterprise Resource Planning (ERP) implementation; or in environments where increasingly disruptive technologies play a part, for example Robotic Process Automation (RPA), Internet of Things (IoT); preparation for an organisational change or to give visibility. To name a few that are becoming key considerations for an organisation

Everything we do is part of a process, some complex and some more straightforward.  It is understanding these and correctly documenting them that will provide the foundation upon which analysis and improvements can be made.

Essentially BPM is the discipline of improving a business process from end to end by analysis, modelling, recommending and executing improvements, and monitoring the improved process and continually optimising it. It is the understanding of these factors and correctly documenting them that will drive success.

Put simply, a business process is the recipe for an organisation’s goods and services, the process is more than a model, it depicts how we use the associated elements to create the best approach for delivering products and services. In this context a model is the process flowchart that has a particular format enhanced with additional information that permits process analysis. It is a series of actions, that have a beginning and an end, and that are directed towards achieving an outcome; or put another way, a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.  Therefore, the organisation can be viewed as a system of interconnecting parts and functions that deliver a customer requirement to produce financial results.  The processes within a business drive and control the quality of the output to the customer.

The information that we are documenting can be described as falling into three streams:

  1. People and their skill sets; the human element and interaction involved in the process, including the resources present and those required
  2. Facilities, the environment which the organisation operates within
  3. Technology, the tools which are available to get the job done.

Business Process Management Goals and Measurement                   

When commencing such an exercise it is important to define why it is being undertaken and the end goal. It is also important to understand the context in which the process is operating. What is the maturity level of the processes in the organisation?  Are they chaotic, well managed but inconsistent or measured for performance?  Also is there an existing business architecture framework in which the process exists?  These factors need to be assessed prior to undertaking the BPM activities.

Using BPM will introduce project based discipline to help bring about process improvements. It follows therefore that the project should be resourced to reflect this. A project would typically include subject matter experts, process experts and project management resources as required.

The goal of BPM is improvement to ensure the organisation is able to produce the right outcome every time at the right cost.  This can be measured in terms of effectiveness and efficiency of the business processes which therefore determine the success in the marketplace.

When assessing the quality of a process we would drill down on the effectiveness and efficiency.   Effectiveness being delivery to the customer at the right quality, cost and on time; and efficiency being the amount of resource consumed in affecting that delivery.

  • In an ideal world the process would be both effective and efficient.
  • It could be effective but not efficient; where re-work is required but the product is still delivered on time.
  • It could be efficient but not effective; where, for example, the customer requirements are not properly understood so that they are ineffective as the right product would not be delivered.
  • It could be inefficient and ineffective; where re-work prevents the product being delivered on time, or to the appropriate quality.

The introduction and use of KPIs and other metrics will address questions on the role of the business process; but if you cannot define the purpose or the value we should start to question why are we doing it.

Business Process Architecture and Operating Models                                       

The business process model is a key component of BPM; it does not exist in isolation, but is part of a hierarchy.  Before commencing a mapping exercise it is important to understand where this process fits within the operating model hierarchy. Different hierarchy levels may demand different mapping approaches that are suitable for their main audience, eg senior management, day-to-day process operators, and so on.  Furthermore, it is important to achieve consistency across the organisation; this can be achieved through rigorous and controlled process mapping standards across the organisation.

Whilst there is no standard hierarchy model there are typically four or five levels.  The structuring will depend on a number of factors including the size and complexity of the organisation and the maturity of their process approach.  We find that it is best practise to establish whether a client has an existing process hierarchy; and if so where our statement of work fits into it; if not it is this something to establish and put in place as part of the exercise.                                   

An operating model shows the main components that make up an organisation, those components documented may include business processes, organisation structure and location, technology and data points.  Typically it will be derived from the business’ value chain, and just as with processes, an operating model would be documented “as is” – known as the current operating model, “to be” – known as the target operating model; and resulting gaps to be addressed in order to achieve the project goals.

As Is Versus To Be Process Mapping

“AS IS” mapping is identifying the current state of the process.  That means we are documenting the process exactly as it is performed today, albeit not as managers think it is being done, and not as it ought to be done, but exactly as it is done today.  This is important in order to get an accurate start point for any transitions that will be reliant upon this; it is the foundation to allow for process analysis.

“TO BE” mapping is defining the target state process.  It incorporates new and/or changed functionality which may be driven by any number of transitions depending on the organisation goals and purposes.

Gap Analysis is the difference between the “AS IS” and “TO BE” and provides the basis for the activities that need to take place to enable the changes.

Project Based Approach

It is important to remember that process mapping should be approached in a methodical way, and is not done in isolation.  Here at Ownet we ensure that the exercise is set up as a process based project using recognised standard methodologies and modelling formats.

When first engaged, we would hold an introductory meeting with the relevant stakeholders at the client, in order to understand where they are in BPM maturity, this allows us to outline our approach and methodology.  We then explore the scenario in order to understand the Client’s needs and capabilities.

Does the client, for example, have existing tools in place that are fit for purpose? In which case it makes sense to explore these and how we can build upon them.  Use of the client’s methodology versus applying standardised modelling techniques would ultimately come down to the specific situation, including drivers for the project and the suitability of any existing tools and completed work products. Next, what is the extent of resources they will be deploying to the project? This would help us to determine the resource we need to provide, levels of training and start building working relationships

We would define the scope of the area to be reviewed and documented, and determine whether there is an existing client Operating Model that we should adhere to.  The deliverables must be clearly defined, this would cover the process maps to be produced (and at what level); and any related deliverables, for example procedures, RACI charts, internal controls frameworks, governance requirements, change impact assessments etc.

Collaboration tools would be set up, so sharing across the team, both internally and for this client is facilitated, covering versioning to avoid confusion, duplication and data redundancy.  Appropriate access rights can be set at the same time, to allow for example sharing within the project team for work in progress; and producing a finished project library to hand over to the client.

A governance structure must be put in place, it would be appropriate for the client organisation and have been approved by the client and documented in the project charter.  It would cover validation for the process definition activity and process maps; QA/peer reviews; and client signoff.  A project initiation document, project charter (or similar) and project plan would be produced and signed off by the client.

For each process, the modelling approach, the methods to be used for collecting the information and what information needs to be gathered needs to be determined.  This is again tailored to the client circumstance, key factors being the time and resource they are able to dedicate to the exercise, how much time they are willing to invest up front, and the level of touchpoints in a process – that is how many people are involved.  Factors such as this drive the project approach; for example one to one meetings with end users and process owners versus workshop type structuring.

Conclusion

Business process management is part of the overall architecture of an organisation, and this should be kept in mind throughout the exercise, as should an organised and disciplined project management approach to the exercise.  Client engagement and agreement on the scope of the work and the deliverables is critical to success.

At Ownet our consultants have significant breadth and depth of experience in BPM exercises, having supported clients with diverse business process goals, and across multiple industry sectors.

Contact us

020 7638 8987
info@ownet.co.uk