This is the first in a number of articles that will explore what is meant by Transformation, starting with Business Processes. We will define what is a process, how to capture the necessary details (the “AS-IS” process), transform those processes (the “TO-BE” process), implement the new processes with appropriate governance and then undertake constant improvement as the organisation evolves to meet new challenges.
It is easy to say “Let’s transform our processes”, but getting an organisation to understand what this means is much more difficult.
This article focusses on what a process is and some of the fundamental things to consider before modelling a process.
Process or Procedure?
There is always controversy when addressing definitions of Process and Procedure. The definitions below are typical.
What is a process?
There are many definitions for a process as shown below:
- A process is a set of interrelated or interacting activities which transforms inputs into outputs
- A process is a series of actions or steps taken in order to achieve a particular end.
- A process is a series of steps and decisions involved in the way work is completed
- ‘Directives to communicate established methods for performing and administering work’
- ‘Mode of Conducting Business’
- A specific way to perform an activity
- The flow of work that links people together to produce a defined output
- Implementation of Policies
- A document describing a specified sequence of actions within a process (WHO, WHAT, WHEN, WHERE, WHY and HOW)
Organisations often talk about Processes at Level 0, Level 1, Level 2, Level 3 etc. These are also sometimes referred to as “Parent” and “Child” processes. What this is about is identifying where a Process or Procedure fits within a Hierarchy.
What is a procedure?
A procedure is a specified way to carry out an activity or a process.
Organisations typically have Standard Operating Procedures (SOPs). These describe an established or official way of doing something. This is typically documented either as a flow diagram or in textual format, where the focus is more on how to perform a task or several tasks. So, is a Manual or a detailed Work Instruction a procedure? Does a Checklist constitute a procedure (It does describe things that have to be done, but maybe not how)?
Types of Process
These are typically how most organisations define processes (e.g. HR, Finance, Sales, Marketing, Production, Customer Service, Project Management).
End-2-End Processes (Value-chains)
These processes address cross-functional processes in a value chain (e.g. Lead2Cash, Procure2Pay, Lead2Order, Hire2Retire, Record2Report, Issue2Resolution).
Process Journeys (Customer, Supplier, Employees….)
Process Journeys capture the Customer, Supplier, or Employee touch points in an organisation’s processes. Understanding the context around each touch point enables an organisation to identify where improvements can be made. Typical information captured would be the step (Task) in an internal process, WHO is involved, WHAT Technology and documentation supports that Task, associated Risks, data, Improvement Initiatives, (e.g. training requirements (Skills & Competences), new Products & Services and Key Performance Indicators (e.g. Customer Survey results).
Before we model a process, it is essential to have clear definitions for the different process models and what details should be modelled for each process “Level”.
Processes can be modelled at different levels of detail, so for any process, it is necessary to define the Parent/Child relationships (e.g. “Produce the Architectural Design” may be a sub-process of the “Product Development Life-cycle”).
Now let’s take a look at some process fundamentals.
Processes do not exist independently of other processes.
Processes have starts, middles and ends and interface with preceding or following processes. The start of a process is triggered (usually called events) by the output of a previous process (or one of several previous processes), so all processes can be linked by looking at the output from a process and seeing where it is the input to another process.
The objective of a process is to deliver a product or service that has had value added to it.
A process will have a scope that determines the business activities that are covered by the process. This can also include statements about what is not within the scope of the process.
Processes often have constraints imposed, such as meeting regulatory or business requirements (e.g. Legislation, Policies, Standards, Codes of Practice (CoP’s), Contractual and many more).
Process tasks are undertaken by people, automated systems, Process Robots or a combination of these. The responsibility for a task can be assigned in the process.
To understand a process, the modelling needs to address WHO (Process Roles) does WHAT, WHAT (Tasks) are to be done, WHERE (Location) they are done, WHY those tasks are necessary, WHEN (immediately, month-end, defined time) the tasks are performed and HOW (Skills and Competences) they are done.
A process needs to have Business Ownership, either by someone with a particular Position (e.g. CFO) or Role (e.g. Sales Order Clerk), or by a group of people representing different parts of the business involved in the process being modelled. A useful acronym to remember is RASCI (who is Responsible, Accountable, Supports, is Consulted (or Consults) and Informed).
For any task, the model should be able to access supporting assets, such as documentation (Manuals, Work Instructions, Checklists, Product and Services collaterals, file templates, reference documentation, media files, Online links (Internet, Intranet and Extranet), tools and equipment, materials to be consumed (e.g. raw materials, part-processed materials), Facilities (such as premises, utilities, transport).
When modelling a process, take into account the “Suppliers” and “Customers” of the process tasks. Note that “Suppliers” and “Customers” can be “Internal or External Suppliers and Customers” in the interfacing processes.
Take note of process “Stakeholders”, those who are impacted by the process, but not necessarily involved.
All processes have deliverables (i.e. Products and Services). Processes also create Records of actions performed, or Key Performance Indicators (KPI’s), which can be used to evaluate performance, enabling bottlenecks, issues, variation etc. to be identified.
All tasks in a process take time (e.g. Setup time, maximum and minimum process times) and have associated costs.
All processes need to be subject to Governance, typically real-time reporting of Key Performance Indicators (KPI’s), such as Time, Cost, Quality and Quantity indicators, implementation of Monitoring tasks, audits and management of changes.
Processes leave audit trails (Records of tasks completed either manual records or automated records, as from an ERP system). Records should be “Owned”, kept for a defined period of time (Taking into account Regulatory requirements) and the data can be used for conducting process analysis.
Processes are never perfect, therefore the likelihood and impact of Risks occurring needs to be identified, owned and appropriate controls identified.
So now that we have a clear understanding of how we are going to help our organisational colleagues understand what we are doing, what are the next steps?
- Most important is to align the changes with organisational strategies and find a sponsor (or sponsors) and champions to support the changes.
- Establish a governance structure to ensure ongoing leadership and control.
- Agree what the Business Architecture will be (i.e. Process Architectures, Organisational, data, technology, products & services).
- Agree what the measures of success will be.
- Agree the methods and conventions for the creation, review and approval of the business architecture as it evolves.
- Define the mechanisms for the release and ongoing improvement of the process models.
- Align Business objectives with IT and Technology initiatives
The next steps are best achieved by setting up a”Business Centre of Excellence”, which will be the subject of the next article in this series.