Hope all are good and well...
Audio version created with Paper2Audio.
Audio by Paper2Audio
Hope all are good and well...
The world of Process Capture, Improvement, Implementation is fascinating to say the least... This articles provides a beneficial introduction...
Need a Six Sigma Black Belt — Process Expert? Drop a message and let's discuss your requirement/project...
Musab Qureshi
Emails: musabquk@hotmail dot com / mail@musab.co.uk
WhatsApp: +44 7857 709 573
#Musab #C.S.S.B.B #Process #Processes #B.P.M #B.P.R #B.P #B.PFramework #iso #Q.M.S #Available #OpenToWork
Table of Contents
1. Understanding Business Processes
2. Analysing, Modelling and Improving Processes
3. The B.P.M and B.P.R Project
4. E.R.P, B.P.M, Automation and Process Technology
5. Artificial Intelligence and the Future of Business Processes
6. Connecting B.P.M with C.X, C.J.M and Service Design
7. B.P.M Standards, Frameworks and Best Practice
8. A Universal Enterprise B.P.M Framework
1. Understanding Business Processes
Before we talk about Business Process Management, Business Process Reengineering, E.R.P, automation or artificial intelligence, we need to answer one very simple question:
What exactly is a business process?
You may already know more about processes than you think.
Imagine you order a laptop from a company.
You choose the laptop.
You place the order.
The organisation receives the order.
The order is checked.
The item is prepared.
It is dispatched.
A delivery company transports it.
You receive the laptop.
The order is completed.
That entire chain of activity is a business process.
Nothing mysterious.
A process is simply:
A connected set of activities that takes something from a starting point to a desired outcome.
Once you understand that idea, you have already understood the foundation of Business Process Management.
1.1 Processes Are Everywhere
Every organisation runs on processes.
A hospital has a process for registering a patient.
A manufacturer has a process for producing a product.
A retailer has a process for fulfilling an order.
A university has a process for admitting a student.
A telecommunications company has a process for activating a service.
A government department has a process for handling an application.
An airport has processes for checking passengers, handling baggage and managing departures.
A technology company has processes for developing products, resolving incidents and releasing software.
Even a very small organisation has processes.
Someone has to:
Find customers
Take orders
Deliver the service
Purchase supplies
Deal with questions
Handle complaints
Manage employees
Maintain technology
In some cases, raise invoices
The organisation may never have drawn these processes on a diagram.
They still exist.
That gives us our first important principle:
A process does not need to be documented to exist.
Sometimes a process exists mainly in people's heads.
That can work when an organisation is very small.
As the organisation grows, it can become a problem.
1.2 So What Makes Something a Process?
A process usually contains three basic elements:
Input to Activities to Output
Something enters.
Work is performed.
Something comes out.
For example:
Customer request to Request handling activities to Completed request
Or:
Purchase requirement to Procurement activities to Required item available
Or:
Employee joins organisation to Onboarding activities to Employee ready to work
The process may contain five steps or five hundred.
It may involve one person or thousands of people.
It may happen in minutes or take months.
The basic idea remains the same.
1.3 A Process Needs a Trigger
Most processes start because something happens.
A customer places an order.
An employee submits a request.
A machine breaks down.
A contract reaches a renewal point.
A new employee joins.
A citizen submits an application.
A product needs to be launched.
That starting event is often called a trigger.
For example:
Customer submits request
↓
Request is received
↓
Request is assessed
↓
Request is approved or rejected
↓
Request is fulfilled
↓
Customer is informed
The process has a beginning, a series of activities and an outcome.
1.4 Processes Can Branch
Real life is rarely as neat as a simple straight line.
Suppose a customer submits an application.
The information may be complete.
Or it may be incomplete.
If it is complete, the application can continue.
If information is missing, it may need to go back to the customer.
That creates a decision:
Is the information complete?
Yes: Continue
No: Request additional information
Processes can therefore contain:
Decisions
Approvals
Waiting
Exceptions
Escalations
Rework
Parallel activities
This is where process analysis starts becoming interesting.
1.5 Process, Activity, Task and Procedure
These terms often get mixed together.
They are related but different.
A process is the complete flow of work.
An activity is a significant piece of work within the process.
A task is a specific action.
A procedure explains how a task should be performed.
For example:
Process: Employee onboarding
Activity: Prepare employee access
Task: Create user account
Procedure: Instructions explaining exactly how the account is created
Think of it as zooming in.
The process is the whole journey.
Activities are the major stages.
Tasks are the individual pieces of work.
Procedures provide the detailed instructions.
1.6 Processes Have Customers
When people hear the word customer, they often think about someone buying a product.
In process management, the idea is broader.
The recipient of a process outcome might be:
An external customer
An employee
Another department
A supplier
A citizen
A partner
A regulator
Another organisation
Consider an employee onboarding process.
The employee is obviously involved.
But the I.T team also needs the outcome.
The manager needs the outcome.
Human Resources needs the outcome.
Security may need the outcome.
Facilities may need the outcome.
So a process can have several stakeholders and several recipients.
1.7 Internal and External Processes
Some processes directly face customers.
For example:
Customer places order to Organisation fulfils order
Other processes happen mainly inside the organisation.
For example:
Employee requests equipment to Internal teams process request to Equipment provided
These are both business processes.
The difference is who is receiving the outcome and where the work takes place.
Modern organisations contain a huge combination of customer-facing and internal processes.
1.8 Why End-to-End Matters
Now we reach one of the most important ideas in B.P.M.
Imagine a customer wants to change their contact details.
From the customer's perspective, this is one simple request.
Inside the organisation it might involve:
Customer Service
↓
Operations
↓
Data Management
↓
I.T system
↓
Notification service
From the organisation's perspective, several teams are involved.
From the customer's perspective:
“I asked you to change my details.”
That is why process professionals think end to end.
They look at the complete journey rather than focusing only on what happens inside one department.
1.9 Departments Are Not Processes
This distinction is extremely important.
An organisation might have:
Human Resources
I.T
Procurement
Operations
Sales
Customer Service
Legal
Facilities
These are functions or organisational areas.
A process can cross all of them.
For example:
Employee joins organisation
may involve:
Human Resources
↓
Manager
↓
I.T
↓
Security
↓
Facilities
↓
Employee
The employee does not think:
“I am now progressing through seven departmental processes.”
They think:
“I am joining the organisation.”
That is the difference between functional thinking and process thinking.
1.10 Process Handoffs
Whenever work moves from one person, team or system to another, we have a handoff.
Handoffs are common.
They are not automatically bad.
But they are frequent sources of delay and confusion.
Imagine this:
Team A completes the request
↓
Team B receives it
↓
Team B cannot find some information
↓
Team B sends an email
↓
Team A responds later
↓
Team B continues
The actual work may take twenty minutes.
The waiting may take two days.
That is a classic process problem.
The issue is not necessarily the work itself.
The issue is the way the work flows between people and teams.
1.11 The Hidden Process
Some of the most important processes are not written down anywhere.
An experienced employee may simply know:
“First I check this system.”
“Then I send this email.”
“Then I wait for approval.”
“Then I update that spreadsheet.”
“If something unusual happens, I call this person.”
That is still a process.
It is simply an undocumented process.
This can create risk.
What happens when that employee leaves?
What happens when another employee needs to perform the work?
What happens when the organisation needs to automate it?
What happens when someone asks how the process actually works?
Documenting important processes therefore helps create organisational knowledge.
1.12 Why Processes Become Complicated
Processes rarely become complicated overnight.
Usually it happens gradually.
Someone adds a new approval.
Another team introduces a new form.
A new system is introduced.
An old system remains.
A new regulation creates another check.
Someone adds an extra spreadsheet.
Another exception is added.
A new team becomes responsible for one activity.
Years later, nobody remembers why half the steps exist.
The process still works.
But it has become unnecessarily complicated.
This is sometimes called process bloat.
1.13 A Simple Example
Consider a request for a new piece of I.T equipment.
At first the process might have been:
Employee requests equipment
↓
Manager approves
↓
I.T provides equipment
Simple.
Over time it becomes:
Employee completes form
↓
Manager checks form
↓
Department administrator checks requirement
↓
Procurement reviews request
↓
I.T reviews technical specification
↓
Security checks requirement
↓
Manager approves again
↓
Procurement places order
↓
Supplier confirms order
↓
I.T receives equipment
↓
I.T configures equipment
↓
Security checks equipment
↓
I.T gives equipment to employee
Nothing here is automatically wrong.
But now we have a much better question:
Does every step add value?
That is the kind of question a process professional asks.
1.14 Value-Adding and Non-Value-Adding Work
Some activities directly contribute to the desired outcome.
Other activities may be necessary controls.
Some may simply add delay or duplication.
Imagine a customer has already provided their address.
If three different teams ask for the same address again, something may be wrong.
If three people independently check the same information, perhaps there is a good reason.
Perhaps there is not.
Process analysis helps us find out.
The objective is not to remove every control.
It is to distinguish between:
Necessary work
Useful work
Required control activities
Unnecessary work
That distinction becomes extremely important when improving a process.
1.15 A Process Is More Than a Flowchart
This is worth remembering.
A process is not just a series of boxes and arrows.
A real process includes:
People
Who performs the work?
Information
What information do they need?
Data
What information is stored and exchanged?
Rules
What determines what can happen?
Technology
Which systems support the work?
Controls
What prevents mistakes or inappropriate actions?
Measures
How do we know whether the process is performing well?
Resources
What does the process need in order to operate?
This is why Business Process Management can become a large discipline.
The flowchart is only one part of the picture.
1.16 Process Ownership
Someone needs to be accountable for the process.
That person is often called the Process Owner.
The Process Owner does not necessarily perform every task.
Instead, they are responsible for the health of the process as a whole.
They may oversee:
Process performance
Process design
Process controls
Process standards
Process improvement
Process documentation
Process risks
Process objectives
This becomes particularly important when a process crosses several departments.
Without ownership, every department can optimise its own part while the overall process becomes worse.
1.17 Local Optimisation Can Hurt the Whole Process
Here is a surprisingly common problem.
Team A improves its own performance.
Team B improves its own performance.
Team C improves its own performance.
Yet the customer experience becomes worse.
How?
Because each team has optimised its own part of the process without considering the entire journey.
For example:
Team A processes requests extremely quickly.
But sends incomplete information to Team B.
Team B therefore spends additional time checking it.
Team B then sends incomplete information to Team C.
Team C has to correct the problem.
Every team may appear efficient.
The end-to-end process is not.
This is why B.P.M encourages end-to-end performance thinking.
1.18 Process Performance
How do we know whether a process is working well?
We measure it.
Useful measures include:
Time
How long does the process take?
Quality
How often is the result correct?
Volume
How much work is being processed?
Rework
How often does work have to be repeated?
Waiting
How much time is spent waiting?
Productivity
How much work is completed with the available resources?
Customer experience
How easy was the process for the customer?
Compliance
Was the process performed according to the required rules?
A process does not need hundreds of K.P.I's.
A few well-chosen measures are often much more useful.
1.19 Process K.P.I's
A Key Performance Indicator, or K.P.I, is a measure that tells us something important about performance.
For example:
90% of service requests completed within two working days
This tells us considerably more than:
Service requests processed
A useful K.P.I should help people understand whether the process is achieving its purpose.
The best K.P.I is not necessarily the one that is easiest to measure.
It is the one that tells us something useful.
1.20 Processes and Customer Experience
A process can be efficient for an organisation and still be frustrating for the customer.
Imagine a customer has to:
Enter their information
↓
Wait
↓
Enter the same information again
↓
Receive an email
↓
Click a link
↓
Call the organisation
↓
Explain everything again
The organisation may have perfectly reasonable internal steps.
From the customer's perspective, the experience is poor.
This is why modern process management connects naturally with:
Customer Experience
Customer Journey Mapping
Service Design
User Experience
The process is what the organisation does.
The journey is what the customer experiences.
They are closely connected but they are not identical.
1.21 Processes and Employee Experience
The same principle applies internally.
Suppose an employee needs to request something simple.
They have to:
Open one system
Download a form
Complete a spreadsheet
Email it
Wait for a response
Enter the information again
Follow up
Call someone
The process may technically work.
But it creates unnecessary employee effort.
Good process design therefore considers both business performance and human effort.
1.22 The As-Is Process
Before improving a process, we need to understand its current state.
This is called the As-Is process.
As-Is answers:
“What happens today?”
It tells us:
How the process starts
What activities occur
Who performs them
Which systems are used
Where decisions happen
Where approvals occur
Where exceptions occur
Where the process ends
The As-Is is not a wish list.
It is not:
“What should happen?”
It is:
“What actually happens?”
That difference is crucial.
1.23 The To-Be Process
Once the current process is understood, we can design the To-Be process.
The To-Be answers:
“What should happen in the future?”
Perhaps the new process:
Removes unnecessary steps
Reduces waiting
Removes duplication
Introduces clearer ownership
Improves controls
Improves information
Introduces automation
Improves customer experience
Makes sensible use of A.I
The As-Is shows where we are.
The To-Be shows where we want to go.
The gap between them becomes a major part of the transformation effort.
1.24 Business Process Improvement
Business Process Improvement, or B.P.I, is about making an existing process better.
The improvement may be small.
Perhaps one unnecessary approval is removed.
Perhaps two systems are integrated.
Perhaps a paper form becomes digital.
Perhaps information is captured once rather than three times.
Small improvements can have a surprisingly large effect when a process is performed thousands of times.
1.25 Business Process Reengineering
Business Process Reengineering, or B.P.R, goes further.
Instead of asking:
“How can we improve this step?”
B.P.R asks:
“Why are we doing the process this way at all?”
That can lead to major redesign.
A process may be:
Simplified
Reorganised
Standardised
Digitised
Automated
Rebuilt around customer needs
Rebuilt around a new operating model
B.P.R is therefore more radical than ordinary process improvement.
1.26 Automation Comes Later
Here is a rule worth remembering:
Do not automate a bad process before understanding it.
Suppose a process contains ten unnecessary manual steps.
Automating those ten steps does not necessarily create a good process.
It may simply create a faster bad process.
A sensible sequence is:
Understand
↓
Simplify
↓
Standardise where appropriate
↓
Improve
↓
Automate where appropriate
↓
Consider A.I
This principle will return throughout this Article.
1.27 What About A.I?
Artificial Intelligence is changing the way organisations think about processes.
A.I can potentially help with:
Process discovery
Document analysis
Requirements analysis
Process documentation
Decision support
Information classification
Customer interaction
Exception handling
Process monitoring
Process optimisation
A.I may also enable new types of workflows involving A.I agents.
But the basic principle does not disappear.
You still need to understand the process.
A.I does not remove the need for process thinking.
In many cases it makes process thinking even more important.
1.28 Business Process Management
Now we can finally define Business Process Management, or B.P.M.
B.P.M is the structured approach to:
Understanding
Designing
Managing
Measuring
Improving
business processes.
It covers the complete process lifecycle rather than one isolated activity.
B.P.M is therefore much more than process mapping.
It brings together people, processes, technology, information, performance, governance, controls and improvement.
1.29 The Basic B.P.M Mindset
A good process professional keeps asking simple questions:
What are we trying to achieve?
What starts the process?
What actually happens?
Who does the work?
Why is each step necessary?
Where does the work wait?
Where do errors occur?
Who owns the process?
How do we measure it?
What can be improved?
What should be automated?
Where could A.I help?
These questions are often more valuable than a complicated methodology.
1.30 The Golden Rule of Process Management
We can reduce much of this chapter to one simple idea:
First understand the work. Then improve the work. Then decide how technology can support the work.
That means:
People before technology
Process before automation
Outcomes before activities
End-to-end thinking before departmental optimisation
Evidence before assumptions
This way of thinking will carry us through the rest of the Article.
1.31 The Big Picture
A business process is simply a structured way of getting something done.
It starts with a trigger.
It uses people, information, rules, resources and technology.
It contains activities and decisions.
It produces an outcome.
It may cross several teams and systems.
It can be measured.
It can be improved.
It can be redesigned.
It can be automated.
And increasingly, parts of it can be supported by A.I.
Once you learn to look at an organisation through the lens of processes, something interesting happens.
You stop seeing a collection of departments.
You start seeing a network of connected work that produces outcomes.
And that is the real beginning of Business Process Management.
2. Analysing, Modelling and Improving Processes
We now know what a business process is.
The next question is much more practical:
How do we understand a process well enough to improve it?
This is where Business Process Management starts becoming a practical discipline.
A process may appear simple from the outside.
A request comes in.
Someone checks it.
Someone approves it.
Someone performs the work.
The request is completed.
But look underneath those five steps and you may find several systems, multiple teams, repeated data entry, waiting, emails, spreadsheets, unnecessary approvals and a collection of unofficial workarounds.
The process may work.
It may simply not work very well.
2.1 Start With Reality
The first rule of process analysis is:
Understand what actually happens before deciding what should happen.
This sounds obvious.
It is not always followed.
Organisations often have an official procedure describing the process.
The document may say:
Request received to Check to Approve to Complete to Close
But the real process might be:
Request received to Email someone to Update spreadsheet to Check information to Ask for missing information to Wait to Forward request to Wait again to Obtain approval to Enter information into another system to Complete work to Update spreadsheet to Close
The difference between those two processes can be enormous.
The first describes the intended process.
The second describes the lived process.
A good process professional wants to understand both.
2.2 Process Discovery
The activity of finding out how a process really works is called process discovery.
There are many ways to do it.
You can:
Interview people
Run workshops
Observe employees performing the work
Review procedures
Examine forms
Analyse system records
Look at reports
Study complaints
Review exceptions
Analyse process data
Use process mining
Use task mining
The objective is simple:
Discover the truth about the process.
Not the version people wish existed.
Not the version written five years ago.
The version people actually use.
2.3 Talk to the People Doing the Work
One of the best sources of process knowledge is often the person performing the work every day.
They know things that may never appear in a process manual.
They know:
Which step causes delays
Which information is usually missing
Which system is difficult to use
Which activity gets repeated
Which approval adds little value
Which exceptions occur frequently
Which unofficial workaround everyone uses
This is why workshops and interviews are so important.
But there is an interesting problem.
Different people may describe the same process differently.
That does not necessarily mean someone is wrong.
It may mean the process is not standardised.
That variation is itself valuable information.
2.4 The As-Is Process
Once we understand the current process, we can document the As-Is.
As-Is simply means:
This is how the process works today.
The As-Is process may show:
The trigger
Activities
Decisions
Roles
Systems
Inputs
Outputs
Approvals
Exceptions
Handoffs
Waiting points
The purpose is not to make the current process look good.
It is to make the current process visible.
That matters because people often disagree about what is actually happening.
A process model creates something everyone can look at together.
2.5 Start Simple
Do not begin by creating a giant diagram with hundreds of boxes.
Start with the big picture.
For example:
Customer submits request
↓
Request is checked
↓
Request is assessed
↓
Decision is made
↓
Request is fulfilled
↓
Customer is informed
That may be enough for the first conversation.
Once the major flow is understood, we can add detail.
This is much easier than trying to model every tiny action from the beginning.
2.6 Process Hierarchy
Large organisations often need several levels of process detail.
At the highest level we may have a broad area such as:
Manage Employee Lifecycle
Within that we might have:
Recruit Employee
Onboard Employee
Develop Employee
Manage Employee Changes
Offboard Employee
Within Onboard Employee, we might have:
Prepare New Starter
Set Up Access
Provide Equipment
Complete Orientation
Within Set Up Access, we might have individual tasks.
The important point is that a process can be viewed at different levels.
Senior management may need the high-level picture.
A Business Analyst may need the detailed process.
A technical team may need the individual tasks and system interactions.
2.7 sipoc
A useful way to begin analysing a process is sipoc.
It stands for:
Supplier
Who provides what the process needs?
Input
What enters the process?
Process
What are the major activities?
Output
What does the process produce?
Customer
Who receives the result?
For example:
Supplier: Employee
Input: Equipment request
Process: Submit to Review to Approve to Fulfil
Output: Equipment provided
Customer: Employee
sipoc is deliberately simple.
That is why it is useful.
You can create one quickly and use it to frame a more detailed process investigation.
2.8 Process Maps
A process map shows how work moves from one activity to another.
For example:
Request received
↓
Check information
↓
Is information complete?
→ Yes: Continue
→ No: Request missing information
↓
Review request
↓
Approve?
→ Yes: Continue
→ No: Reject request
↓
Fulfil request
↓
Close request
Even a simple map can reveal things that are hard to see in prose.
We can see decisions.
We can see loops.
We can see rework.
We can see where work goes backwards.
2.9 Swimlanes
A swimlane diagram adds responsibility.
For example:
Employee
Submit request
↓
Manager
Review request
↓
Approve
↓
Service Team
Validate request
↓
Fulfil request
↓
Employee
Receive outcome
Now we can see who performs each part.
More importantly, we can see where responsibility moves from one participant to another.
Those are the handoffs.
2.10 Handoffs
A handoff occurs when work moves from one person, team or system to another.
Handoffs are normal.
But they deserve attention.
Imagine:
Team A completes work
↓
Team B receives it
↓
Team B discovers missing information
↓
Team B sends an email
↓
Team A responds later
↓
Team B continues
The actual work may take thirty minutes.
The waiting may take two days.
This is why a process professional asks:
How much of the process is actually work and how much is waiting?
That can be a surprisingly revealing question.
2.11 Processing Time Versus Waiting Time
Imagine a process takes five working days.
The people involved may spend only two hours actually working on the request.
The rest is waiting.
Waiting for:
Information
Approval
Another team
A system
A supplier
A decision
A meeting
Someone to return from another task
This creates a major opportunity.
Improving process performance does not always mean making people work faster.
Sometimes the biggest improvement comes from removing waiting.
2.12 Bottlenecks
A bottleneck is a point in the process that restricts the flow of work.
Imagine ten requests arrive.
Only one person can perform a particular activity.
The requests start to build up.
That activity has become a bottleneck.
Bottlenecks may be caused by:
Limited capacity
Too many approvals
Poor prioritisation
System limitations
Specialist knowledge
Manual work
Poor information
Excessive checking
Finding the bottleneck is often much more useful than simply telling everyone to work faster.
2.13 Look for Rework
Rework happens when work has to be performed again.
For example:
A request is submitted.
The request is processed.
The team discovers information is missing.
The request goes back.
The information is added.
The request is processed again.
That is rework.
Rework increases:
Time
Effort
Cost
Frustration
Risk
Reducing rework can therefore produce significant benefits.
2.14 Duplication
Another common problem is duplication.
The same information may be:
Entered into several systems
Checked by several people
Stored in several spreadsheets
Requested from the customer more than once
Sometimes duplication is necessary.
Sometimes it is not.
A process analyst needs to understand why the duplication exists before recommending its removal.
2.15 Process Pain Points
A pain point is something that makes the process harder, slower, more expensive or more frustrating than it needs to be.
Typical pain points include:
Long waiting times
Too many handoffs
Repeated data entry
Unclear responsibilities
Too many approvals
Poor information
Manual work
System limitations
Frequent errors
Excessive exceptions
Unclear procedures
The important thing is not simply to collect complaints.
We need to connect each pain point to evidence.
2.16 The Five Whys
One of the simplest investigation techniques is the Five Whys.
Suppose requests are regularly delayed.
Ask:
Why are requests delayed?
Because the processing team does not receive all the required information.
Why?
Because the request form does not capture it.
Why?
Because the form was designed several years ago.
Why has it not been changed?
Because nobody owns the end-to-end process.
Now we have found something interesting.
The visible problem was delay.
The deeper issue was process ownership and outdated design.
This is why process improvement should focus on root causes, not just symptoms.
2.17 Root Cause Analysis
The objective of root cause analysis is to understand why something happens.
Useful techniques include:
Five Whys
Fishbone analysis
Pareto analysis
Cause-and-effect analysis
Failure analysis
Process data analysis
Imagine a process has a high error rate.
The answer might not be:
“Employees need more training.”
The real problem could be:
Poor instructions
A confusing system
Missing information
An unclear business rule
A badly designed form
Too many manual steps
The right solution depends on the real cause.
2.18 Process Performance
Once we understand a process, we need to know how well it performs.
Useful measures can include:
Cycle time
How long does the complete process take?
Processing time
How much time is actually spent performing the work?
Waiting time
How much time is spent waiting?
Volume
How much work enters the process?
Quality
How often is the outcome correct?
Rework
How often must work be repeated?
Backlog
How much unfinished work exists?
First-time-right
How often is the result correct without rework?
Customer effort
How difficult is the process for the person using it?
These measures help turn vague complaints into evidence.
2.19 Process K.P.I's
A Key Performance Indicator, or K.P.I, is a measure that tells us something important about performance.
For example:
90% of service requests completed within two working days
That tells us something useful.
Compare it with:
1,200 requests processed
The second number tells us how much work occurred.
It does not tell us whether the process performed well.
The best process measures connect directly to what the process is supposed to achieve.
2.20 Do Not Measure Everything
There is a temptation to create huge lists of K.P.I's.
That can create another problem.
People spend hours producing reports.
Nobody knows which measures really matter.
The process becomes measurement-heavy and improvement-light.
A better approach is to focus on a manageable number of measures that answer important questions.
Is the process fast enough?
Is it accurate enough?
Is it controlled?
Does it deliver the intended outcome?
Is the customer experience acceptable?
2.21 Business Rules
Many processes contain rules.
For example:
If required information is missing, return the request to the requester
Or:
If a particular condition applies, additional approval is required
Or:
If an item is unavailable, use the approved alternative process
These rules should be clear.
Otherwise different people may interpret the same situation differently.
That creates inconsistency.
For complex decision logic, organisations can use Decision Model and Notation, or D.M.N, alongside bpmn.
A simple way to remember the distinction is:
bpmn shows how work flows.
D.M.N shows how decisions are made.
2.22 Process Controls
Not every process problem is about efficiency.
Some are about risk.
A process may need controls to make sure:
The correct person performs an action
Required information is present
Important checks are completed
Decisions are recorded
Sensitive information is appropriately protected
Exceptions are identified
Evidence exists
Controls can be important.
But controls can also accumulate over time.
A good question is:
Does this control still provide enough value to justify the effort it creates?
That does not mean controls should simply be removed.
It means they should be understood and designed properly.
2.23 The To-Be Process
Once we understand the current process, we can begin designing the To-Be process.
To-Be means:
How should the process work in the future?
A good To-Be process might:
Remove unnecessary steps
Reduce waiting
Reduce duplication
Improve information quality
Clarify ownership
Improve controls
Reduce manual effort
Improve customer experience
Introduce sensible automation
Use A.I where appropriate
The To-Be is not about making the process look more sophisticated.
It is about making it work better.
2.24 Eliminate Before You Automate
This is one of the most useful principles in B.P.M:
Do not automate unnecessary work.
Imagine a process has fifteen steps.
Analysis shows that:
Three are unnecessary
Two can be combined
One can be eliminated
Several can be automated
The best approach is not to automate all fifteen.
First redesign the process.
A useful sequence is:
Eliminate to Simplify to Standardise to Automate to Optimise
Then ask:
Where can A.I add genuine value?
2.25 Standardisation
Suppose three departments perform the same basic process.
Department A uses one procedure.
Department B uses another.
Department C has developed its own approach.
This can create unnecessary variation.
Standardisation can help by establishing a common way of working.
But standardisation does not mean everything must be identical.
There may be genuine reasons for variation.
The objective is to distinguish between:
Necessary variation
and
Unnecessary variation
That distinction is particularly important in large organisations.
2.26 Business Process Improvement
Business Process Improvement, or B.P.I, is the structured effort to make an existing process better.
The changes may be relatively small.
For example:
Remove an unnecessary approval
Simplify a form
Combine two activities
Improve information capture
Reduce a handoff
Introduce better monitoring
Integrate systems
Small improvements can have a significant impact when a process is performed frequently.
2.27 Business Process Reengineering
Business Process Reengineering, or B.P.R, is more radical.
Instead of asking:
“How can we improve this process?”
we ask:
“If we were starting again today, how would we design this process?”
This can challenge the assumptions behind the current process.
Perhaps a department should no longer perform a particular activity.
Perhaps several steps can disappear.
Perhaps the customer experience can be redesigned completely.
Perhaps technology allows a completely different operating model.
B.P.R is about fundamental redesign rather than incremental improvement.
2.28 Process Mining
Modern organisations have another powerful source of information:
System event data.
Many enterprise systems record events such as:
Request received
Request assigned
Request updated
Request approved
Request completed
When this data is analysed, we can discover how the process actually behaves.
This is called process mining.
It can help reveal:
Bottlenecks
Delays
Rework
Process variations
Unusual paths
Exceptions
Performance patterns
This can be particularly valuable when a process is too large or complex to understand through interviews alone.
2.29 Task Mining
Process mining looks mainly at events across processes and systems.
Task mining can look more closely at how people perform individual tasks on their computers.
It can reveal repetitive activities such as:
Copying information
Moving information between systems
Repeating searches
Updating multiple records
Performing predictable sequences of actions
These may become candidates for simplification or automation.
2.30 The Customer Perspective
There is another question we must ask:
What does the process feel like to the person using it?
A process may appear efficient internally and still create a poor experience.
Imagine a customer has to:
Provide the same information several times
Wait without knowing what is happening
Contact several teams
Repeat the same explanation
Use an inconvenient channel
The process may technically work.
The experience may not.
This is where B.P.M connects with Customer Experience, Customer Journey Mapping and Service Design.
We will explore that relationship later.
2.31 People Matter
Technology is important.
But process improvement is not simply a technology exercise.
People perform processes.
People manage processes.
People make decisions.
People deal with exceptions.
People interact with customers.
People identify problems.
A brilliantly designed process that people cannot understand or use will not succeed.
That is why process design must consider:
Roles
Skills
Workload
Responsibilities
Training
Change
Employee experience
2.32 A Good Process
There is no single perfect process.
But a well-designed process should normally be:
Clear
People understand what should happen.
Effective
It produces the intended outcome.
Efficient
It avoids unnecessary effort.
Controlled
Important risks are managed.
Measurable
Performance can be understood.
Adaptable
It can respond to legitimate changes.
Customer-aware
The experience of the person receiving the service matters.
Technology-enabled
Technology supports the work rather than creating unnecessary complexity.
2.33 A Simple Process Improvement Cycle
For someone new to B.P.M, the whole discipline can be simplified into ten steps:
1. Define
What process are we looking at?
2. Discover
What actually happens?
3. Map
Can we see the process clearly?
4. Measure
How well is it performing?
5. Analyse
Where are the problems?
6. Diagnose
What are the root causes?
7. Redesign
What should the future process look like?
8. Decide
What should be eliminated, simplified, standardised, automated or supported by A.I?
9. Implement
Put the new process into operation.
10. Improve
Keep monitoring and improving it.
That is B.P.M in a nutshell.
2.34 One Powerful Question
There is one question that can completely change a process discussion:
If we were designing this process today, would we design it this way?
Sometimes the answer will be yes.
Sometimes the answer will be:
“Probably not.”
That second answer is where transformation opportunities begin.
2.35 The Big Picture
A process map is only the beginning.
Good process management involves understanding:
What the process does
Why it exists
Who performs it
Who receives the outcome
How the work flows
Where the work waits
Where problems occur
What causes those problems
How performance is measured
What controls are required
What the future process should look like
Where technology can help
Where automation can help
Where A.I can help
The goal is not to produce beautiful diagrams.
The goal is to create better ways of working.
And once an organisation begins looking at processes this way, another question naturally appears:
Who is responsible for making all of this happen?
That brings us to the people behind B.P.M and B.P.R: the Business Process Consultant, Business Analyst, Project Manager, Process Owner and the wider transformation team.
3. The B.P.M and B.P.R Project
We now know what a business process is.
We know how to discover it.
We know how to map it.
We know how to find problems.
We know how to design a better process.
So how does all of this actually happen in a real organisation?
Usually through a project.
A Business Process Management project or Business Process Reengineering project brings people together to understand a process, improve it and put the new way of working into operation.
And this is where a rather interesting group of people appears.
The Business Process Consultant.
The Business Analyst.
The Project Manager.
The Process Owner.
The Subject Matter Experts.
The technical team.
The change team.
They all have different responsibilities.
When they work well together, process transformation can be remarkably effective.
When they do not, things can become messy very quickly.
3.1 What is a B.P.M Project?
A B.P.M project is a structured initiative to understand, improve, manage, automate or transform one or more business processes.
The project might focus on one process.
For example:
Employee onboarding
Or it might cover a much larger area:
Complete employee lifecycle
It could also involve several connected processes.
For example:
Recruitment to Onboarding to Employee Changes to Offboarding
The scope depends on what the organisation is trying to achieve.
3.2 What is a B.P.R Project?
A B.P.R project is generally more transformational.
Instead of making small improvements to the existing process, the organisation may decide to redesign the process fundamentally.
The project may be driven by:
A major technology change
A new operating model
Poor customer experience
Excessive process complexity
Major organisational change
Poor performance
Mergers or restructuring
Regulatory requirements
The need to simplify operations
New automation or A.I opportunities
The question is no longer simply:
“How can we improve this process?”
It becomes:
“What should this process look like in the future?”
3.3 Every Project Needs a Reason
A process project should have a clear purpose.
Perhaps the process is taking too long.
Perhaps customers are unhappy.
Perhaps employees are spending too much time on repetitive work.
Perhaps multiple teams perform the same activity differently.
Perhaps a new E.R.P or B.P.M platform is being introduced.
Perhaps the organisation wants to automate parts of the process.
Perhaps a process needs to become much easier to manage.
Whatever the reason, the project needs a clear statement of the problem.
A good starting point might be:
“Our current employee onboarding process takes too long, involves too many manual activities and provides a poor experience for new employees.”
That is much more useful than:
“We need a new B.P.M system.”
3.4 Start With the Outcome
Before drawing a single process map, ask:
What are we trying to achieve?
Maybe the goal is:
Faster service
Better quality
Fewer errors
Lower employee effort
Better customer experience
Stronger controls
Greater consistency
Better use of technology
More automation
Better use of A.I
The project should be built around the desired outcome.
Technology is a means.
The process outcome is the reason.
3.5 The Project Sponsor
A major transformation project normally needs a senior sponsor.
The sponsor provides leadership and support.
They may:
Approve the project
Provide funding and resources
Resolve major issues
Support key decisions
Remove organisational obstacles
Champion the change
The sponsor does not run every workshop.
That is not their job.
Their role is to provide senior-level direction and support.
3.6 The Process Owner
The Process Owner is particularly important.
They are accountable for the process as a whole.
Imagine a process crosses:
Human Resources
↓
I.T
↓
Facilities
↓
Security
↓
Employee
Who owns the end-to-end process?
Without clear ownership, each department may focus only on its own part.
The Process Owner provides an end-to-end perspective.
They help answer:
What is this process supposed to achieve?
How should it perform?
What standards should apply?
What needs to improve?
What risks need to be managed?
Which decisions need to be made?
3.7 The Business Process Consultant
The Business Process Consultant focuses heavily on the process itself.
They may:
Analyse the current process
Facilitate workshops
Identify process problems
Map the As-Is
Design the To-Be
Identify improvement opportunities
Assess process maturity
Recommend process changes
Identify automation opportunities
Support process governance
Help define the future operating model
The Business Process Consultant often acts as the person asking:
“Why are we doing it this way?”
They challenge assumptions.
They connect individual activities to the end-to-end process.
They look for opportunities to simplify.
3.8 The Business Analyst
The Business Analyst, or B.A, overlaps with the Process Consultant in some areas but has a broader analytical role.
A B.A may:
Elicit requirements
Analyse stakeholder needs
Document business requirements
Analyse current and future states
Identify gaps
Define functional requirements
Define non-functional requirements
Support solution evaluation
Support testing
Support user acceptance
Translate business needs into clear requirements
There can be considerable overlap between B.P.M Consultants and B.A's.
In some organisations one person performs both roles.
In others they are separate.
The important thing is to make responsibilities clear.
3.9 The Project Manager
The Project Manager is focused on getting the project delivered.
They manage areas such as:
Scope
Schedule
Resources
Risks
Issues
Dependencies
Governance
Reporting
Stakeholder coordination
Delivery milestones
A useful way to think about the difference is:
The Process Consultant asks:
“What should the process look like?”
The Business Analyst asks:
“What does the business need and what should the solution do?”
The Project Manager asks:
“How are we going to deliver all of this successfully?”
These roles work together.
None of them replaces the others.
3.10 The Subject Matter Expert
The Subject Matter Expert, or S.M.E, knows the business in detail.
They may know:
How the current process operates
Why particular decisions are made
Which exceptions occur
Which rules apply
Which systems are used
Which problems are common
S.M.E's are essential.
But there is an important point:
Knowing how something is done is not the same as knowing how it should be done.
An S.M.E may explain why a particular step exists.
The Process Consultant may then ask whether it still needs to exist.
Both contributions are valuable.
3.11 The Technical Team
Process transformation often involves technology.
The technical team might include:
Solution Architects
Enterprise Architects
Application specialists
Developers
Integration specialists
Data specialists
Platform specialists
Security specialists
Test specialists
Their role is to determine how the future process can actually be supported.
This is where the process meets reality.
A beautiful To-Be process is not useful if it cannot be implemented.
3.12 The Change Team
Changing a process changes people's work.
That is why Change Management matters.
People may need:
New responsibilities
New procedures
New systems
New skills
New approval arrangements
New performance measures
The change team helps people understand and adopt the new way of working.
A technically excellent process can still fail if people do not adopt it.
3.13 Starting the Project
A typical B.P.M or B.P.R project might begin with a simple sequence:
Project idea
↓
Initial assessment
↓
Business case
↓
Approval
↓
Project initiation
↓
Discovery
↓
Design
↓
Implementation
↓
Deployment
↓
Benefits realisation
The exact methodology may vary.
The basic logic remains remarkably consistent.
3.14 Defining Scope
One of the first major questions is:
What exactly are we changing?
Suppose the organisation says:
“We want to improve employee onboarding.”
Does that include:
Recruitment?
Offer management?
Security checks?
Equipment?
System access?
Facilities?
Training?
Payroll?
The first few months of employment?
Without clear scope, the project can expand indefinitely.
Good scope provides boundaries.
3.15 Stakeholder Mapping
A process can affect many people.
Stakeholders may include:
Senior management
Process owners
Employees
Customers
Suppliers
I.T teams
Operations
Legal
Security
Compliance
Service teams
Project teams
Not everyone needs the same level of involvement.
Some people need to make decisions.
Some provide information.
Some need to approve the future process.
Some simply need to understand the change.
Good stakeholder management prevents surprises later.
3.16 Discovery Workshops
One of the most common B.P.M project activities is the workshop.
A process workshop may bring together:
Process specialists
Process owners
S.M.E's
Business analysts
Technical specialists
Customer representatives
The group might spend several hours answering:
What triggers the process?
What happens next?
Who performs the work?
Which systems are involved?
Where are the decisions?
Where do things go wrong?
Where do people wait?
What happens when something unusual occurs?
By the end, the team should have a much clearer picture of the current process.
3.17 The Current-State Assessment
After discovery, the project team normally documents the current state.
This may include:
As-Is process maps
sipoc
Process roles
Systems
Business rules
Pain points
K.P.I's
Risks
Controls
Issues
Process variations
Now the project has evidence.
The team can stop debating what people think happens and start discussing what actually happens.
3.18 The Problem Statement
A good project should turn observations into clear problems.
For example:
Problem 1: Requests are frequently returned because required information is missing
Problem 2: Employees enter the same information into multiple systems
Problem 3: Approval queues create long delays
Problem 4: Different teams use different procedures
Problem 5: Customers have limited visibility of progress
These statements are much more useful than:
“The process is bad.”
They give the project something specific to address.
3.19 Designing the Future State
Now the fun begins.
The team starts designing the To-Be process.
Questions might include:
Can we remove this step?
Can these two activities become one?
Can the customer provide this information once?
Can two systems exchange the information automatically?
Does this approval still make sense?
Can we standardise this process?
Can we automate this activity?
Could A.I assist with this decision?
Should this activity remain with a person?
This is where the project moves from analysis to transformation.
3.20 Gap Analysis
The difference between the As-Is and To-Be is the gap.
For example:
Today:
Three manual checks
Future:
One automated validation
The gap is:
Remove two checks and automate the remaining validation
Or:
Today:
Four systems
Future:
Integrated process across two systems
The gap includes the integration work and changes to the operating model.
Gap analysis turns the future vision into actionable work.
3.21 Requirements
The Business Analyst will often document what the future solution needs to do.
Requirements may include:
Functional requirements
Process requirements
Data requirements
Integration requirements
Reporting requirements
Security requirements
Performance requirements
User experience requirements
Compliance requirements
For example:
The system must automatically route completed requests to the appropriate team.
Or:
The customer must be able to see the status of their request.
Clear requirements help the technical team understand what is needed.
3.22 Business Case
A significant transformation normally needs a business case.
The business case explains why the organisation should invest in the change.
It may consider:
Expected benefits
Implementation effort
Resources
Technology requirements
Risks
Dependencies
Expected improvements
Strategic alignment
Benefits might include:
Reduced processing time
Fewer errors
Better customer experience
Improved employee experience
Better process control
Reduced manual effort
Faster service delivery
Better information
The business case connects process improvement to organisational outcomes.
3.23 Implementation
Once the future process has been agreed, it needs to become real.
Implementation might involve:
Process changes
System configuration
Software development
Integration
Data changes
New procedures
New controls
Training
Communications
This is where design meets delivery.
It is also where hidden complexity tends to appear.
Something that looked simple on a diagram may be surprisingly complicated when implemented across real systems and organisations.
3.24 Testing
A new process should not simply be switched on and hoped for the best.
It needs testing.
Testing might include:
Functional testing
Does the solution work?
Process testing
Does the complete process work from beginning to end?
Integration testing
Do connected systems work correctly?
Data testing
Is the right information being passed between systems?
User acceptance testing
Can the people performing the work use the new process successfully?
Exception testing
What happens when something goes wrong?
That last one is particularly important.
Normal scenarios are easy.
Real life is full of exceptions.
3.25 Training
A new process may be beautifully designed.
If nobody knows how to use it, it will fail.
Training may cover:
New procedures
New systems
New responsibilities
New controls
New customer interactions
New escalation routes
Training should focus on what people actually need to do.
Not simply on explaining every feature of a new system.
3.26 Deployment
Eventually the new process goes live.
This may happen:
All at once
In stages
By location
By business unit
By process
Through a pilot
The right approach depends on the organisation and the complexity of the change.
3.27 Hypercare
Immediately after deployment, the project team usually needs to remain close to the process.
This period is often called hypercare.
The team watches for:
Errors
User problems
Unexpected process behaviour
Data issues
System issues
Performance problems
Unforeseen exceptions
The objective is to stabilise the new process.
3.28 Benefits Realisation
The project does not truly succeed simply because the new system is live.
The real question is:
Did the organisation achieve the expected improvement?
Suppose the project promised:
Cycle time would fall from five days to two days.
After implementation, we need to measure it.
Perhaps it fell to two days.
Excellent.
Perhaps it fell to four.
That tells us more improvement is required.
This is benefits realisation.
3.29 B.P.M Projects Are Not Just I.T Projects
This is an important distinction.
A B.P.M project may involve major technology changes.
But B.P.M is fundamentally about how work is performed.
Technology may support that work.
It may automate the work.
It may completely change the work.
But the starting point is still the process.
This is why process professionals need to work closely with technology teams without allowing technology to define the entire solution.
3.30 A Typical B.P.M Team
A practical B.P.M project might bring together:
Project Sponsor
Project Manager
Business Process Consultant
Business Analyst
Process Owner
Subject Matter Experts
Enterprise Architect
Solution Architect
Data specialists
Technical specialists
Change Manager
Test specialists
Product Owner
End users
Not every project needs all of these roles.
The important thing is that the necessary responsibilities are covered.
3.31 Who Does What?
A simple way to remember the main roles is:
Business Process Consultant
Focuses on the process and how it should work.
Business Analyst
Focuses on business needs and requirements.
Project Manager
Focuses on delivering the change.
Process Owner
Owns the process and its performance.
Subject Matter Expert
Provides detailed operational knowledge.
Architect
Ensures the solution fits the wider enterprise.
Change Manager
Helps people adopt the new way of working.
Technical Team
Builds, configures and integrates the technology.
The exact boundaries can vary by organisation.
Good projects make those boundaries clear.
3.32 When Things Go Wrong
B.P.M projects can fail for many reasons.
For example:
The scope is too large
The project tries to transform everything at once.
The current process was never properly understood
The team redesigns based on assumptions.
Senior sponsorship is weak
Important decisions remain unresolved.
Process ownership is unclear
Nobody takes responsibility for the end-to-end outcome.
Technology drives the design
The organisation designs its process around software limitations.
Users are not involved
The future process looks good on paper but fails in practice.
Benefits are not measured
The organisation cannot tell whether the project worked.
Too much change happens at once
People struggle to adopt the new operating model.
These lessons will appear again later in the Article.
3.33 The B.P.M Project in One Sentence
A good B.P.M project can be summarised as:
Understand the current process, identify what needs to change, design a better future process, implement it successfully and measure whether it delivered the intended outcome.
That sounds simple.
In practice it can involve people, data, technology, governance, culture and significant organisational change.
But the underlying logic remains straightforward.
3.34 A Practical B.P.M Project Lifecycle
For the beginner, remember this sequence:
1. Initiate
Why are we doing this?
2. Define
What is in scope?
3. Discover
How does the process work today?
4. Analyse
What is wrong and why?
5. Design
What should the future process look like?
6. Specify
What does the solution need to do?
7. Build
Create or configure what is required.
8. Test
Prove that the new process works.
9. Deploy
Move it into real operation.
10. Stabilise
Fix early problems.
11. Measure
Did we achieve the expected benefits?
12. Improve
Keep improving the process.
And there is one final point.
The project may eventually end.
The process does not.
A project creates the change.
Process management keeps the process healthy afterwards.
That is why the next chapters are so important.
Once an organisation understands and improves its processes, it needs to decide which technologies should support them.
That takes us into E.R.P, B.P.M platforms, workflow, automation, process mining and the rapidly changing world of process technology.
4. E.R.P, B.P.M, Automation and Process Technology
We have learned how to understand a process.
We have mapped it.
We have analysed it.
We have identified problems.
We have designed a better version.
Now comes an obvious question:
How can technology help us run the process?
This is where things get interesting.
Modern organisations use a huge range of technologies to support business processes.
Some systems manage the core activities of an organisation.
Some manage specific processes.
Some move work from one person to another.
Some automate repetitive tasks.
Some analyse how processes actually perform.
Some connect different systems.
And increasingly, some use A.I to help people and systems make decisions and perform work.
The important thing is not to start with the technology.
Start with the process.
Then decide what technology is appropriate.
4.1 What is E.R.P?
E.R.P stands for Enterprise Resource Planning.
The name can sound complicated.
The basic idea is actually quite simple.
An E.R.P system brings together many of an organisation's core operational processes and information in an integrated environment.
Instead of every department maintaining completely separate systems, an E.R.P platform can provide connected processes and shared information.
For example, an organisation may use E.R.P capabilities to support:
Procurement
Supply chain
Manufacturing
Inventory
Human resources
Projects
Asset management
Sales
Service
Operations
Reporting
Modern cloud E.R.P platforms increasingly include automation, analytics and A.I capabilities as part of the core enterprise platform. sap describes cloud E.R.P as software supporting core end-to-end business processes while Microsoft positions Dynamics 365 as an E.R.P platform connecting business processes and increasingly embedding Copilot and agents.
4.2 Why E.R.P Matters to Processes
Think back to our earlier definition:
Input to Activities to Output
An E.R.P system can provide much of the technology that allows those activities to happen.
Consider a simple procurement process.
Someone needs an item
↓
Request is created
↓
Request is approved
↓
Order is created
↓
Supplier provides item
↓
Item is received
The E.R.P system may support several of these activities.
The important point is that E.R.P is not simply a place where information is stored.
It can become part of the actual process.
4.3 E.R.P Is Not the Same as B.P.M
This distinction is important.
E.R.P is primarily about managing enterprise operations and the information associated with them.
B.P.M is about managing and improving business processes.
They overlap.
But they are not the same thing.
An E.R.P platform may execute or support a process.
A B.P.M approach helps the organisation understand whether that process is well designed.
You could therefore think of it this way:
B.P.M asks:
How should this process work?
E.R.P helps answer:
How can our enterprise system support this work?
That is a useful distinction.
4.4 E.R.P and Standard Processes
Modern E.R.P platforms often include preconfigured processes based on established business practices.
This creates an important choice.
Should the organisation:
Adapt the process to the E.R.P?
Or:
Customise the E.R.P to match the existing process?
Sometimes the best answer is to change the process.
Why?
Because the existing process may contain years of unnecessary complexity.
An E.R.P implementation can therefore become a process improvement opportunity.
Instead of saying:
“We have always done it this way.”
the organisation can ask:
“Does this still need to work this way?”
That is a very healthy question.
4.5 Leading E.R.P Platforms
The enterprise E.R.P landscape includes several major platforms.
Important examples include:
sap
sap Cloud E.R.P and sap S/4hana Cloud provide broad enterprise capabilities and increasingly combine core processes with embedded A.I, automation and analytics.
Microsoft
Microsoft Dynamics 365 provides E.R.P applications spanning areas such as operations, supply chain, projects and human resources, with Copilot and agent capabilities increasingly integrated into business processes.
Oracle
Oracle Fusion Cloud Applications provide a broad cloud enterprise application environment covering core organisational processes.
Other major E.R.P ecosystems
The wider market also includes platforms such as:
Infor
I.F.S
Epicor
Sage
NetSuite
Workday
Unit4
Acumatica
Odoo
Other regional and industry-focused E.R.P platforms
The purpose of this Article is not to declare a single winner.
Different organisations have different requirements.
Instead, we want to understand the capabilities these platforms provide and what they teach us about enterprise processes.
4.6 E.R.P Modules Are Really Process Families
When you look at an E.R.P system, you will often see modules.
For example:
Procurement
Supply chain
Inventory
Human resources
Manufacturing
Projects
Assets
Sales
Service
But from a B.P.M perspective, it is more useful to think about the processes behind those modules.
For example:
Source to Receive
Order to Deliver
Recruit to Onboard
Maintain to Retire
Plan to Produce
Request to Fulfil
These are end-to-end process concepts.
The software modules are simply the technology supporting different parts of those processes.
4.7 What is B.P.M Software?
A B.P.M platform is designed specifically to help organisations model, manage, orchestrate, automate and monitor business processes.
Depending on the platform, it may provide capabilities such as:
Process modelling
Workflow
Forms
Business rules
Case management
Process monitoring
Integration
Automation
Reporting
Process mining
Low-code development
A.I capabilities
This is where B.P.M starts becoming more than a method.
It becomes a technology-enabled discipline.
4.8 B.P.M Platforms
There is a broad enterprise B.P.M and process-automation market.
Examples include:
Appian
Appian positions its platform around enterprise process orchestration and A.I-powered automation across people, systems and A.I.
Pega
Pega combines workflow, case management, process automation, process mining, R.P.A and A.I capabilities within its platform.
ServiceNow
ServiceNow provides workflow automation, process automation, process mining, R.P.A and orchestration through its broader platform.
Camunda
Camunda focuses heavily on process orchestration using bpmn and increasingly combines deterministic workflows, human tasks and A.I agents within end-to-end processes.
sap Signavio
Signavio brings together process modelling, process analysis, process transformation and process mining within the sap ecosystem. sap's current process-mining offering also incorporates A.I capabilities for analysing and improving processes.
Microsoft Power Platform
Power Automate provides workflow automation, cloud flows, desktop R.P.A, task and process mining, orchestration and A.I-assisted automation.
There are many other platforms.
The names matter less than understanding the capabilities.
4.9 Workflow
Now we need another word:
Workflow.
A workflow is the movement of work through a defined sequence.
For example:
Request received
↓
Review
↓
Approve
↓
Assign
↓
Complete
↓
Close
Software can manage this flow automatically.
It can create tasks.
Send notifications.
Route work.
Apply rules.
Escalate overdue activities.
Record decisions.
Track progress.
This is workflow automation.
4.10 Workflow Versus Process
The words are sometimes used interchangeably.
It is useful to keep a distinction.
A business process describes the complete way work is performed to achieve an outcome.
A workflow focuses more on how work moves between activities, people and systems.
A workflow can therefore be part of a broader business process.
For example:
Business Process
Employee onboarding
Within it:
Workflow
Create employee access
Within that:
Tasks
Create account to Approve access to Notify employee
The hierarchy helps us understand what we are actually automating.
4.11 Business Process Automation
Business Process Automation, or B.P.A, uses technology to automate repeatable business activities and workflows.
The objective might be to:
Reduce manual work
Reduce errors
Improve consistency
Speed up processing
Improve visibility
Reduce unnecessary handoffs
Automation could be very simple.
For example:
Request completed to Automatically notify requester
Or much more sophisticated:
Request received to Validate to Route to Check rules to Obtain approval to Update systems to Notify requester to Close
The second is closer to end-to-end process automation.
4.12 R.P.A
Another familiar term is Robotic Process Automation, or R.P.A.
R.P.A uses software robots to perform repetitive computer-based tasks.
Imagine an employee repeatedly:
Opens one application
Copies information
Opens another application
Pastes the information
Updates a record
Downloads a document
Sends a notification
An R.P.A bot may be able to perform some or all of these actions.
R.P.A can be useful.
But it is important to understand its place in the bigger picture.
R.P.A often automates tasks.
B.P.M and workflow platforms can manage larger processes.
As ServiceNow explains, workflow automation typically coordinates interconnected processes and tasks while R.P.A focuses more heavily on repetitive interactions with applications.
4.13 When R.P.A Is Useful
R.P.A can be particularly useful when:
Existing applications cannot easily be integrated
A repetitive task occurs frequently
The task follows predictable rules
Manual interaction is causing delays
Replacing the underlying system is unrealistic
But R.P.A should not automatically be the first solution.
Sometimes an A.P.I integration is better.
Sometimes a system configuration change is better.
Sometimes the process itself should be redesigned.
Again:
Understand first. Automate second.
4.14 A.P.I's and Integration
Imagine the organisation uses several systems.
One system contains customer information.
Another manages service requests.
Another manages inventory.
Another manages communication.
If each system is isolated, employees may have to move information manually.
An A.P.I, or Application Programming Interface, can allow systems to communicate.
For example:
System A
sends information
↓
A.P.I
↓
System B
receives information
This can eliminate manual re-entry.
Integration is therefore a major part of modern process design.
4.15 Process Orchestration
The word orchestration is increasingly important.
Think about an orchestra.
Different instruments perform different parts.
The conductor helps coordinate them.
Process orchestration works in a similar way.
A business process may involve:
A person
E.R.P
C.R.M
B.P.M platform
A.P.I
R.P.A bot
A.I agent
A process-orchestration platform can coordinate these different participants.
Camunda, for example, explicitly positions process orchestration as a way of coordinating people, systems and A.I agents within governed end-to-end processes.
4.16 Case Management
Not every process is predictable.
Consider a complex customer complaint.
Or a major equipment failure.
Or an unusual service request.
You may know the desired outcome without knowing exactly which steps will be required.
This is where case management becomes useful.
Instead of forcing every case through an identical sequence, the system can allow appropriate activities to be added or performed depending on circumstances.
So:
Workflow is often highly structured.
Case management is more flexible.
Both have an important place in B.P.M.
4.17 Low-Code and No-Code
Modern platforms increasingly allow business applications and workflows to be created with relatively little traditional programming.
This is often described as:
Low-code
or
No-code
These tools can allow teams to:
Create forms
Build workflows
Configure approvals
Connect systems
Create dashboards
Automate tasks
Build simple applications
This can dramatically reduce the time needed to turn a process design into a working solution.
But governance still matters.
A process built in ten minutes can cause problems for ten years if nobody manages it properly.
4.18 Process Mining
We encountered process mining earlier.
Now we can see where it fits into the technology landscape.
Process mining uses event data from systems to understand how processes actually run.
Imagine an organisation believes every request follows this route:
Receive to Review to Approve to Complete
Process mining might reveal that in reality:
Receive to Review to Wait to Reassign to Review to Return to Resubmit to Approve to Wait to Complete
That is powerful information.
The process diagram tells us what was designed.
Process mining can show us what actually happened.
4.19 Task Mining
Task mining goes closer to the individual employee's computer activity.
It can help identify:
Repetitive actions
Manual data movement
Application switching
Frequent searches
Copying and pasting
Repeated document handling
These findings can help identify automation candidates.
Together:
Process mining
shows how the process behaves.
Task mining
shows how individual tasks are performed.
4.20 Digital Process Automation
Digital Process Automation, or D.P.A, takes process automation beyond isolated tasks.
The focus is on digitally managing broader processes.
That may include:
Forms
Workflow
Rules
Integrations
Notifications
Human tasks
Automation
Monitoring
This is particularly useful where the process involves several people and systems.
4.21 The Technology Stack
It helps to imagine the technology landscape as a set of layers.
At the bottom:
Systems of Record
E.R.P, C.R.M, H.R and other core enterprise systems
Above them:
Integration
A.P.I's, integration platforms and data services
Above that:
Process and Workflow
B.P.M, workflow, orchestration and case management
Alongside them:
Automation
R.P.A, document automation and other automated actions
Then:
Process Intelligence
Process mining, task mining and analytics
And increasingly:
A.I
Generative A.I, A.I agents, intelligent decisions and A.I-assisted work
The layers can work together.
No single product necessarily needs to do everything.
4.22 One Process, Many Technologies
Consider a new employee onboarding process.
The employee submits information through a portal.
A workflow platform routes the request.
The H.R system stores employee information.
An integration connects the H.R system with I.T.
An automation creates standard access.
A service-management platform creates tasks.
An A.I assistant answers employee questions.
A process-mining platform monitors performance.
A dashboard measures completion times.
Suddenly we have a complete digital process ecosystem.
The employee sees one experience.
Behind the scenes, several technologies may be cooperating.
That is modern B.P.M.
4.23 Technology Should Follow the Process
This principle is worth repeating:
Do not start by asking which technology we should buy. Start by asking what process we need to improve.
Suppose an organisation buys a powerful B.P.M platform.
Then it discovers that nobody has defined:
Process ownership
Process standards
Process K.P.I's
The As-Is process
The To-Be process
Business rules
Requirements
The software cannot solve those organisational problems by itself.
Technology enables good process management.
It does not replace it.
4.24 E.R.P and B.P.M Can Work Together
An organisation does not necessarily choose:
E.R.P or B.P.M
It may need:
E.R.P + B.P.M
For example:
E.R.P might manage the transaction.
B.P.M might coordinate the end-to-end process.
A workflow engine might route activities.
An integration platform might connect systems.
Process mining might analyse performance.
Automation might eliminate manual tasks.
A.I might assist with decisions.
Each technology can play a different role.
4.25 A Practical Example
Imagine a customer requests a new service.
The process begins through a customer portal.
Step 1
Customer submits request.
Step 2
Workflow checks whether required information exists.
Step 3
A business rule determines which route applies.
Step 4
The E.R.P or operational system creates the relevant record.
Step 5
An integration sends information to another service platform.
Step 6
A human reviews an unusual case.
Step 7
Automation performs routine tasks.
Step 8
The customer receives an update.
Step 9
The process closes.
Step 10
Process analytics measures performance.
That is much more than automation.
It is a connected digital process.
4.26 Choosing the Right Technology
When assessing a technology option, consider:
Process complexity
How complicated is the process?
Volume
How frequently does it occur?
Variation
Does every case follow the same path?
Integration
How many systems are involved?
Human judgement
How much human decision-making is required?
Automation potential
Which tasks can genuinely be automated?
Data
Is good-quality data available?
Controls
What governance and auditability are required?
Scale
Does the solution need to support an enterprise?
Change
How often will the process change?
A.I potential
Could A.I provide meaningful value?
These questions help prevent technology-led decision-making.
4.27 The Current Direction of Travel
The technology landscape is changing quickly.
Traditional boundaries are becoming less clear.
E.R.P platforms increasingly incorporate A.I.
B.P.M platforms increasingly include automation and process intelligence.
Automation platforms increasingly use A.I.
Process-mining platforms increasingly connect discovery with optimisation.
Microsoft Power Automate, for example, now combines workflow automation, R.P.A, task and process mining, orchestration and A.I capabilities.
sap Signavio increasingly connects process analysis and mining with A.I-supported process transformation.
Camunda is combining bpmn-based orchestration with human tasks and A.I agents.
ServiceNow is bringing workflow automation, process mining, R.P.A and A.I together on its platform.
The technology landscape is therefore moving towards connected intelligent processes.
4.28 What Should Remain Human?
This is going to become an increasingly important question.
Not every activity should be automated.
People may still be better suited to:
Complex judgement
Sensitive situations
Creative work
Negotiation
Empathy
Ambiguous decisions
Exceptional cases
Strategic decisions
Automation may be better suited to:
Repetitive tasks
High-volume processing
Predictable rules
Data movement
Notifications
Standard validation
A.I sits somewhere new.
It can potentially help with activities that previously required significant human cognitive effort.
That is why the future process may look like:
Human + Workflow + Automation + A.I + Systems
rather than simply:
Human + System
4.29 The Technology Question
A mature organisation therefore asks more sophisticated questions.
Not:
“Can we automate this?”
But:
“What is the best way to perform this activity?”
The answer might be:
Human
or:
Workflow
or:
A.P.I
or:
R.P.A
or:
A.I
or:
Human + A.I
or:
A combination of several technologies
That is a much more useful way of thinking.
4.30 The Golden Rule of Process Technology
We can now extend the rule from Chapter 2:
Do not automate a process simply because you can. Improve the process first, then choose the technology that best supports the desired outcome.
Technology should make the process:
Simpler
Faster
More reliable
More visible
More controlled
More scalable
Easier to improve
If technology makes the process more complicated, something has probably gone wrong.
4.31 The Big Picture
The modern process-technology landscape can now be understood quite simply.
E.R.P
Manages core enterprise operations.
B.P.M
Helps manage and improve processes.
Workflow
Moves work through defined activities.
Case management
Handles processes requiring flexibility.
Integration
Allows systems to communicate.
R.P.A
Automates repetitive computer-based tasks.
Process mining
Shows how processes actually perform.
Task mining
Shows how individual tasks are performed.
Process orchestration
Coordinates people, systems, automation and increasingly A.I.
A.I
Adds new possibilities for analysis, decisions, assistance and autonomous activity.
The exciting part is that these technologies are increasingly converging.
The organisation of the future will not simply have isolated applications.
It will increasingly have connected digital processes in which people, systems, automation and A.I work together.
But this creates a new question.
If technology can now automate more and more work, how should organisations decide where A.I belongs, what A.I should do and where humans should remain in control?
That is the subject of the next chapter.
5. Artificial Intelligence and the Future of Business Processes
We have seen how technology can support business processes.
Now we arrive at one of the biggest changes taking place in the world of work:
Artificial Intelligence.
A.I is changing how organisations discover processes, analyse them, design them, automate them and perform them.
But there is an important distinction.
A.I is not simply another piece of software.
Traditional software normally follows instructions that people have designed.
A.I can work with information, recognise patterns, generate content, interpret language, make recommendations and increasingly take actions.
That creates a very different possibility.
Instead of asking:
“How can we automate this task?”
organisations can increasingly ask:
“Could an intelligent system perform part of this process?”
And that changes the conversation completely.
5.1 What is A.I?
Artificial Intelligence is a broad term covering technologies that can perform tasks that normally require some form of human intelligence.
These may include:
Understanding language
Analysing information
Recognising patterns
Classifying content
Generating text
Summarising information
Making predictions
Recommending actions
Interpreting documents
Supporting decisions
Generative A.I adds another dimension.
It can create new content such as text, summaries, descriptions, requirements, documentation and other outputs based on the information and instructions provided to it.
A.I agents go further.
They can be designed to use tools, interact with systems and execute multi-step tasks or processes. Microsoft now explicitly positions business agents as systems that can execute core business processes while Copilot Studio supports agents that can manage tasks and business processes with autonomous capabilities.
5.2 A.I Is Not the Same as Automation
This distinction matters.
Traditional automation might say:
If X happens to perform Y
For example:
When a request is submitted, send an acknowledgement.
That is deterministic.
The rule is clear.
A.I can work differently.
It might receive a request written in natural language and determine:
What the person is asking for
Which process applies
Whether information is missing
Which team should handle it
Whether the request appears routine
Whether it requires human attention
That is a different type of capability.
5.3 A.I Can Sit Inside the Process
A.I does not necessarily replace the entire process.
It can sit inside it.
Imagine:
Customer submits request
↓
A.I understands the request
↓
Workflow determines the route
↓
A.I checks information
↓
Human reviews an exception
↓
Automation performs routine activity
↓
System updates the record
↓
Customer receives response
The process is still a process.
A.I has become one of the participants.
5.4 A.I-Powered Process Discovery
One of the first opportunities for A.I is understanding existing processes.
Imagine an organisation has:
Hundreds of process documents
Thousands of emails
Procedure manuals
System records
Forms
Reports
Knowledge articles
Meeting notes
An A.I system can potentially help analyse this material and identify:
Common activities
Repeated procedures
Process variations
Missing documentation
Potential bottlenecks
Conflicting instructions
Common exceptions
This can make process discovery much faster.
Modern process platforms are already moving in this direction. sap, for example, now describes A.I capabilities in Signavio that use process context and process data to help identify bottlenecks and opportunities for transformation and A.I agents.
5.5 A.I and Process Documentation
Process documentation can be surprisingly time-consuming.
A Business Analyst may spend hours turning workshop notes into:
Process descriptions
Requirements
Procedures
User stories
Acceptance criteria
Meeting summaries
A.I can assist with producing initial drafts.
For example:
A workshop recording could be summarised.
The activities could be identified.
Possible decisions could be extracted.
Business rules could be suggested.
A draft process description could be produced.
The human still needs to review it.
But the starting point can be much faster.
5.6 A.I and Requirements Analysis
A.I can also assist Business Analysts.
Suppose a project has hundreds of requirements.
A.I could help identify:
Duplicate requirements
Similar requirements
Missing information
Conflicting statements
Ambiguous wording
Potential dependencies
Areas requiring clarification
This does not remove the B.A.
It gives the B.A another analytical tool.
The professional judgement remains important.
5.7 A.I and Process Modelling
Imagine telling an A.I system:
“Create a high-level process for handling a new employee onboarding request.”
The system might generate a first draft:
Request received
↓
Validate information
↓
Create employee record
↓
Request access
↓
Provide equipment
↓
Complete onboarding
↓
Close process
That can be useful.
But it is only a starting point.
A.I may not know the organisation's actual policies, operating model, exceptions or responsibilities.
A human still needs to validate the model.
This is an important principle:
A.I can accelerate process modelling, but it does not automatically know the correct process.
5.8 A.I and Process Analysis
A.I can help analyse large quantities of process information.
It might identify patterns such as:
Requests that frequently fail
Activities that create delays
Common exception types
Repeated customer questions
Frequently misunderstood instructions
Process variants
Areas where manual work is concentrated
That becomes particularly powerful when A.I is combined with process-mining data.
The process-mining system provides evidence.
A.I can help interpret the evidence.
Together they can give the process professional a much richer view.
5.9 A.I and Documents
Many business processes depend heavily on documents.
Examples include:
Applications
Forms
Contracts
Technical documents
Service reports
Delivery documents
Inspection records
Instructions
Correspondence
A.I can increasingly help classify, extract, summarise and interpret information from documents.
This can reduce manual work.
Instead of someone reading a document and manually copying information into a system, A.I may extract the relevant information and present it for validation.
That is particularly useful where large volumes of unstructured information enter a process.
5.10 A.I and Decisions
This is where things become more interesting.
Many processes contain decisions.
For example:
Does this request meet the criteria?
Which team should receive this case?
Is additional information required?
Is this a routine or unusual request?
Traditional automation generally works well when the rules are clear.
A.I becomes potentially valuable when the information is more complex or unstructured.
But we need to be careful.
A recommendation is not necessarily the same thing as an authorised decision.
Some decisions should remain with a human.
Some can be automated.
Some may use a combination.
The design needs to be deliberate.
5.11 Human in the Loop
One of the most useful concepts in A.I-enabled processes is:
Human in the loop.
This simply means that A.I can perform part of the work while a person remains responsible for an important decision or approval.
For example:
A.I reviews request
↓
A.I recommends outcome
↓
Human reviews recommendation
↓
Human approves
↓
Workflow continues
This can provide a useful balance between speed and human oversight.
5.12 Human on the Loop
There is another model.
Instead of a person reviewing every individual action, the A.I operates more independently while people monitor the overall process.
For example:
A.I handles routine requests
↓
System monitors performance
↓
Human reviews exceptions
This can be appropriate when the process is highly predictable and well controlled.
The amount of human involvement should depend on:
Risk
Complexity
Consequences
Reliability
Regulatory requirements
Quality of information
5.13 A.I Agents
The term A.I agent is becoming increasingly common.
A simple way to understand an agent is:
An A.I system that can pursue a defined goal by using information, tools and actions rather than simply producing a response.
Imagine an employee asks:
“Please arrange the equipment required for this new starter.”
An agent might:
Read the employee information
Determine what equipment is required
Check approved options
Submit the appropriate request
Track progress
Notify the relevant people
Escalate an exception
That starts to look much more like a process participant than a chatbot.
Microsoft now describes agents as capable of executing business processes, while its Power Automate platform combines A.I, workflow, R.P.A, process mining and orchestration capabilities.
5.14 Agentic Workflows
A traditional workflow might be:
Step 1 to Step 2 to Step 3 to Step 4
An agentic workflow can be more flexible.
The agent may receive a goal and determine which permitted actions are needed.
For example:
Goal: Resolve a service request
The agent may:
Understand the request
Gather information
Check available knowledge
Determine the appropriate route
Perform approved actions
Ask a person for help when necessary
Confirm the result
Close the request
The process still needs governance.
The agent does not simply receive unlimited freedom.
5.15 A.I Does Not Remove Process Design
This is perhaps the most important lesson in this chapter.
A.I does not make process design irrelevant.
In fact, it may make it more important.
An A.I agent needs to know:
What its objective is
What process it belongs to
What information it can access
What actions it may perform
What rules apply
What it must not do
When it needs human approval
When it must stop
How its actions are recorded
Without good process design, A.I can create confusion faster than humans can.
5.16 Designing A.I-Ready Processes
An A.I-ready process is not simply a process with an A.I tool added to it.
It is a process designed so that A.I can operate safely and effectively within it.
Consider these questions:
Is the process clearly defined?
Are the roles clear?
Are the rules documented?
Is the required data available?
Is the data reliable?
Are exceptions understood?
Are approvals clear?
Can A.I access the systems it needs?
Can its actions be monitored?
Can humans intervene?
If the answers are mostly no, the process may need improvement before A.I is introduced.
5.17 A.I Needs Good Information
A.I is only as useful as the information it can access and interpret.
Suppose an organisation has:
Outdated procedures
Conflicting documents
Poorly maintained data
Missing process rules
Inconsistent terminology
An A.I system working with that information may produce unreliable results.
This creates a powerful connection between:
B.P.M
and
Data Management
and
Knowledge Management
and
A.I
Good A.I-enabled processes therefore need good information foundations.
5.18 A.I and Exception Management
Traditional automation works best when the process is predictable.
But real organisations are full of exceptions.
A document is incomplete.
A customer asks an unusual question.
A system is unavailable.
Information conflicts.
An activity falls outside the normal rules.
A.I can potentially help identify these exceptions and determine what should happen next.
For example:
Routine request
→ Automated processing
Unusual request
→ A.I analysis
High-risk or ambiguous request
→ Human review
This can help organisations focus human attention where it adds the most value.
5.19 A.I and Customer Experience
A.I can also change the customer experience.
Imagine a customer asking:
“What is happening with my request?”
Instead of searching several systems and waiting for someone to respond, an A.I assistant could potentially retrieve relevant information and explain the current status.
It could also help customers complete processes by:
Explaining requirements
Identifying missing information
Answering questions
Guiding users through forms
Providing updates
Helping resolve straightforward issues
The important point is that A.I becomes part of the customer journey.
We will return to this connection in Chapter 6.
5.20 A.I and Employee Experience
The same principle applies to employees.
Imagine an employee asking:
“How do I request new equipment?”
An A.I assistant could potentially explain the process and help initiate the request.
Or an employee might ask:
“Why has this request been rejected?”
The system could explain the relevant process rule.
This can reduce the amount of time employees spend searching for procedures and asking other people for basic information.
5.21 A.I and Continuous Improvement
A.I can potentially become part of the improvement cycle itself.
For example:
Monitor process
↓
Analyse performance
↓
Identify pattern
↓
Suggest improvement
↓
Human reviews
↓
Implement change
↓
Monitor again
That creates a much tighter improvement loop.
Instead of reviewing a process once a year, organisations could increasingly monitor process behaviour continuously.
5.22 A.I and Process Simulation
Another possibility is asking:
“What might happen if we change this process?”
Process simulation can help organisations test different scenarios.
For example:
What happens if we remove an approval?
What happens if we automate a step?
What happens if demand increases?
What happens if a team becomes unavailable?
A.I can potentially assist in exploring such scenarios and explaining possible consequences.
But again, simulations are aids to decision-making.
They are not guarantees of what will happen in the real world.
5.23 A.I Risks
A.I introduces real risks.
These can include:
Incorrect outputs
The A.I may produce an incorrect answer.
Hallucination
The A.I may present information that sounds convincing but is not supported by the available evidence.
Poor decisions
An A.I recommendation may be unsuitable.
Data exposure
Sensitive information may be handled incorrectly.
Bias
An A.I system may reproduce problems in its data or design.
Lack of explainability
People may not understand why a particular recommendation was produced.
Over-reliance
People may trust the system too much.
Unexpected behaviour
An agent interacting with multiple systems may produce results that were not anticipated.
These risks need to be designed into the process itself.
5.24 A.I Governance
A.I governance should therefore answer questions such as:
What can the A.I do?
What can it not do?
What information can it access?
Which actions require approval?
Who owns the A.I-enabled process?
How are A.I decisions recorded?
How are errors identified?
How are users informed when A.I is involved?
How is performance monitored?
How can the A.I be stopped?
The answers should be part of the process design.
Governance should not be something added after deployment.
5.25 A.I Does Not Always Mean Full Automation
Sometimes the best use of A.I is simply assistance.
For example:
A Business Analyst remains responsible for requirements but uses A.I to identify duplicates.
A Process Consultant remains responsible for process design but uses A.I to analyse documentation.
A service employee remains responsible for the customer interaction but uses A.I to find relevant information.
A manager remains responsible for a decision but uses A.I to summarise the available evidence.
This can be extremely valuable.
A.I does not have to replace the person to improve the process.
5.26 Think in Levels of Automation
When analysing a process, we can ask:
Level 1: Human
A person performs the task manually.
Level 2: A.I-assisted
A.I helps the person.
Level 3: Automated
Technology performs the activity according to defined rules.
Level 4: A.I-enabled
A.I performs more complex analysis or decision support.
Level 5: Agentic
An A.I agent can perform a sequence of authorised actions with limited human intervention.
Not every process needs Level 5.
In many cases Level 2 may be exactly right.
5.27 What Should A.I Do?
A useful question is:
Where does A.I create genuine value?
A.I may be particularly useful where work involves:
Large amounts of information
Natural language
Documents
Classification
Pattern recognition
Unstructured requests
Repetitive analysis
Complex information retrieval
Frequent exceptions
It may be less useful when a simple deterministic rule already solves the problem.
There is no prize for making a process more complicated than it needs to be.
5.28 The New Process Team
As A.I becomes embedded into business processes, the traditional team structure may evolve.
A future process may involve:
Process Owner
Owns the outcome.
Business Process Consultant
Designs the process.
Business Analyst
Defines requirements.
Project Manager
Delivers the change.
Employee
Performs human activities.
Automation
Performs repetitive tasks.
A.I Assistant
Supports people.
A.I Agent
Performs authorised multi-step activities.
Systems
Provide data and execute transactions.
That is a very different operating model from a process performed entirely by people.
5.29 A.I Changes the Question
For many years the question was:
“Which activities should we automate?”
The new question is becoming:
“Which activities should be performed by people, rules, automation, A.I or a combination of all four?”
That is a much more interesting question.
It moves process design beyond simple automation.
It creates the idea of the intelligent process.
5.30 The Intelligent Process
An intelligent process might look like this:
Customer request
↓
A.I understands request
↓
Workflow identifies process
↓
A.I checks information
↓
Business rules determine standard route
↓
Automation performs routine actions
↓
A.I handles an unusual situation
↓
Human reviews an important exception
↓
System completes transaction
↓
A.I monitors performance
↓
Process data identifies improvement opportunity
That is no longer simply an automated process.
It is an A.I-enabled process ecosystem.
5.31 The Golden Rule for A.I
We can now extend our earlier B.P.M principle:
Do not introduce A.I because A.I is available. Introduce A.I where it improves the outcome, experience, control, quality or efficiency of the process.
The question is never simply:
“Can A.I do this?”
The better questions are:
Should A.I do this?
How should A.I do it?
What should remain human?
What controls are required?
How will we know whether it is working?
5.32 The Future of Business Processes
Business processes are moving from being:
Manual
to:
Digital
to:
Automated
to:
Intelligent
And increasingly:
Agentic
But this progression does not mean humans disappear.
Instead, work can become more distributed between people and technology.
People may focus more heavily on:
Judgement
Relationships
Complex problems
Exceptions
Creativity
Accountability
Strategic decisions
Technology can increasingly handle:
Repetitive work
Information processing
Routine decisions
Data movement
Monitoring
Workflow execution
A.I sits between these worlds and can increasingly support both.
5.33 The Big Picture
The future business process is unlikely to be:
People versus A.I
It is much more likely to be:
People + Processes + Data + Systems + Automation + A.I
The challenge is not simply adopting A.I.
The challenge is designing the right process around it.
That means understanding the current process.
Removing unnecessary work.
Improving the information.
Defining clear rules.
Establishing ownership.
Creating appropriate controls.
Then deciding where A.I genuinely belongs.
And this brings us to another important realisation.
A business process does not exist in isolation.
It creates an experience for someone.
A customer.
A citizen.
An employee.
A user.
That is why the next chapter brings B.P.M together with CustomerExperience, Customer Journey Mapping, Service Design and the wider experience ecosystem.
6. Connecting B.P.M with C.X, C.J.M and Service Design
We have spent the previous chapters looking at what happens inside an organisation.
Now let us step outside.
Because there is another side to every business process.
Someone experiences it.
That person might be a customer.
A citizen.
An employee.
A supplier.
A partner.
A user.
The organisation may think it is managing a process.
The person experiencing it may simply think:
“Why is this so difficult?”
That difference is the reason Business Process Management is closely connected with Customer Experience, Customer Journey Mapping, Service Design and User Experience.
6.1 The Process Is Not the Experience
Suppose a customer wants to arrange a new telecommunications service.
Inside the organisation, the process might involve:
Customer request
Identity checks
Availability check
Service configuration
Order processing
Technical activation
Confirmation
From the organisation's perspective, that may be a perfectly normal process.
From the customer's perspective, however, there is one simple question:
“When can I use my new service?”
The customer does not see the internal departments.
They see the experience.
This gives us an important distinction:
B.P.M looks at how the organisation performs the work.
C.X looks at the experience created by that work.
You need both.
6.2 What is Customer Experience?
Customer Experience, or C.X, is the overall experience a customer has when interacting with an organisation.
It includes things such as:
Ease
Speed
Clarity
Convenience
Communication
Consistency
Trust
Effort
Problem resolution
A customer may interact with an organisation many times.
They may:
Search for information
Ask a question
Purchase something
Receive a service
Request support
Make a change
Raise a complaint
End the relationship
Each interaction contributes to the overall experience.
And each interaction is supported by processes.
6.3 What is Customer Journey Mapping?
Customer Journey Mapping, or C.J.M, looks at the experience from the customer's perspective.
Imagine a customer applying for a new service.
The journey might be:
Discover
↓
Research
↓
Apply
↓
Provide information
↓
Wait
↓
Receive decision
↓
Receive service
↓
Get support
The journey map is interested in what the customer sees, does, thinks and experiences at each stage.
It asks:
“What is it like to be the customer?”
That is different from simply asking:
“What does the organisation do?”
6.4 Journey and Process Are Connected
Now we can connect the two.
The customer journey might say:
Apply for service
Behind that single journey stage might sit several business processes:
Capture application
↓
Validate information
↓
Check availability
↓
Assess request
↓
Create service
↓
Notify customer
The customer sees one stage.
The organisation may perform six processes and use several systems.
This is where C.J.M becomes extremely useful for B.P.M.
6.5 Frontstage and Backstage
Service Design often uses a useful distinction:
Frontstage
What the customer can see.
Backstage
What the organisation does behind the scenes.
For example:
The customer sees:
“Your request is being processed.”
Behind the scenes:
A workflow is triggered
Data is validated
Several systems are updated
A service team receives work
An approval may be required
A notification is generated
The customer does not need to understand the machinery.
They simply want the service to work.
6.6 The Customer Journey Can Expose Process Problems
Imagine a customer says:
“I had to explain my situation three times.”
That sounds like a customer experience problem.
But underneath it may be a process problem.
Perhaps:
Teams do not share information
Systems are not integrated
Customer information is stored separately
The process was designed around departments
The same information is repeatedly requested
C.J.M tells us where the customer experiences the problem.
B.P.M helps us investigate why the organisation creates the problem.
That is a powerful combination.
6.7 Touchpoints
A touchpoint is an interaction between a person and an organisation.
Examples include:
Website
Mobile application
Telephone
Chat
Physical location
Service desk
Notification
Document
Portal
Every touchpoint may be supported by one or more processes.
A customer may therefore experience several different processes without knowing that they are separate.
6.8 Moments That Matter
Not every interaction has equal importance.
Some moments matter much more to the person involved.
For example:
First registration
Starting a new service
Receiving an important decision
Reporting a problem
Cancelling a service
Recovering from a failure
These are sometimes called moments that matter.
A process professional should pay particular attention to them.
A process that performs perfectly in the background but fails at an important customer moment can still produce a poor overall experience.
6.9 Customer Effort
One of the simplest ways to evaluate a process is to ask:
How much effort does the customer have to make?
Consider two processes.
Process A
Customer provides information once.
The organisation uses it.
The customer receives updates.
The request is completed.
Process B
Customer provides the same information several times.
The customer receives unclear instructions.
The customer has to call for an update.
The customer repeats the problem to another employee.
The process is eventually completed.
From the organisation's perspective, both processes may technically work.
From the customer's perspective, they are worlds apart.
6.10 Employee Experience
The same concept applies internally.
Employees are also users of organisational processes.
Consider a simple internal request.
An employee may have to:
Open system
↓
Find form
↓
Download document
↓
Complete document
↓
Email it
↓
Wait
↓
Answer questions
↓
Enter information again
A process can therefore create poor Employee Experience, or E.X.
And poor employee experience can affect productivity, adoption and service delivery.
6.11 Citizen Experience
Public-sector organisations have another important dimension:
Citizen Experience.
A citizen may need to:
Submit an application
Request a service
Report an issue
Provide information
Receive a decision
Appeal a decision
Access support
The citizen may not know which government department performs which activity.
They simply experience the service.
This makes end-to-end process thinking particularly important in public services.
6.12 User Experience
User Experience, or U.X, is closely related but has a somewhat different focus.
U.X often looks at how a person interacts with a specific product, application, website or interface.
For example:
Is the form easy to complete?
Can users find what they need?
Are instructions clear?
Are errors easy to correct?
Is navigation intuitive?
B.P.M looks at the wider process.
U.X looks more closely at the interaction.
A poor form may be a U.X problem.
But perhaps the form exists because the underlying process itself is poorly designed.
Both perspectives matter.
6.13 Service Design
Service Design brings together the different parts required to deliver a service.
It asks questions such as:
What does the customer need?
What should the service feel like?
What happens at each touchpoint?
What happens behind the scenes?
What people, processes and systems are required?
Where are the service failures?
How can the complete service be improved?
This makes Service Design a natural partner for B.P.M.
6.14 Service Blueprinting
A Service Blueprint can connect the experience with the operational reality behind it.
For example:
Customer action
↓
Customer-facing interaction
↓
Employee activity
↓
Back-office process
↓
System activity
The blueprint helps connect what people experience with what the organisation must do to deliver that experience.
This is extremely useful during process transformation.
6.15 Outside-In Thinking
Traditional organisational thinking often starts from the inside:
“Here is our department. Here is our system. Here is our procedure.”
Customer-centred design starts from the outside:
“What does the customer need and what must we do to deliver it?”
This is sometimes called outside-in thinking.
Instead of starting with organisational structures, we start with the desired experience and work backwards.
That can expose unnecessary internal complexity.
6.16 Inside-Out Versus Outside-In
An inside-out process might begin:
We have this system
↓
We have this team
↓
We have this procedure
↓
The customer must fit into it
An outside-in approach begins:
Customer needs this outcome
↓
What experience should they have?
↓
What service do we need to provide?
↓
What process is required?
↓
What people, systems and technology should support it?
That second approach can produce very different designs.
6.17 Connecting C.J.M to B.P.M
A powerful way to connect the disciplines is:
Journey Stage
↓
Customer Need
↓
Touchpoint
↓
Business Process
↓
Activity
↓
Role
↓
System
↓
Data
↓
Outcome
For example:
Customer applies
↓
Needs a simple application experience
↓
Online application
↓
Application processing
↓
Validate information
↓
Service Team
↓
Case Management System
↓
Customer information
↓
Application assessed
Now the customer journey and business process are connected.
6.18 Connecting C.X to Process K.P.I's
The process team may measure:
Cycle time
Error rate
Rework
S.L.A performance
The C.X team may measure:
Customer satisfaction
Customer effort
Journey satisfaction
Complaint levels
These measures should not operate in separate worlds.
Suppose the organisation reduces process time by 30%.
That sounds impressive.
But what if customer effort increases?
Perhaps the organisation made the process faster internally by making the customer provide more information.
The internal K.P.I improved.
The customer experience became worse.
That is why process performance should be considered alongside experience performance.
6.19 Complaints Are Process Intelligence
Complaints are often treated as individual problems.
They can be much more valuable than that.
Suppose customers repeatedly complain:
“I had to provide the same information twice.”
That is a signal.
Or:
“Nobody could tell me what was happening.”
Another signal.
Or:
“I was transferred three times.”
Another signal.
A collection of complaints can reveal systematic process problems.
The best organisations do not simply resolve complaints.
They ask:
What does this complaint tell us about the process?
6.20 Voice of the Customer
The Voice of the Customer, or VoC, brings customer feedback into improvement activity.
Sources may include:
Surveys
Interviews
Complaints
Reviews
Contact-centre data
Service interactions
Digital feedback
Customer research
VoC should influence process design.
A process designed entirely from the organisation's perspective can easily optimise the wrong thing.
6.21 Journey Analytics and Process Analytics
Modern organisations can increasingly connect journey and process data.
For example:
Customer journey data
shows where customers abandon an online process.
Process data
shows where requests are delayed.
System data
shows where errors occur.
Together they can reveal something much deeper.
Perhaps customers abandon a journey because a process step requires information they do not understand.
That creates a chain:
Customer behaviour
↓
Experience problem
↓
Process problem
↓
Root cause
↓
Improvement
This is far more powerful than looking at any one dataset alone.
6.22 Product Management and B.P.M
Product teams also need to understand processes.
A digital product often changes how customers perform activities.
For example:
An app may simplify a request.
A portal may replace email.
A self-service feature may eliminate an employee interaction.
Product design therefore affects process design.
The product is part of the process experience.
This means Product Management, U.X, C.X and B.P.M can often benefit from working together rather than operating independently.
6.23 I.T Service Management and B.P.M
I.T Service Management, or I.T.S.M, is another natural connection.
Consider a service request.
The user experiences:
Submit request to Receive service to Request completed
Behind the scenes there may be:
Workflow
Approvals
Service catalogue
Configuration information
Assignment
Fulfilment
Escalation
Resolution
Closure
That is a business process.
I.T.S.M therefore provides a useful example of process management in practice.
6.24 C.R.M and B.P.M
Customer Relationship Management, or C.R.M, also intersects heavily with B.P.M.
C.R.M systems may support processes such as:
Customer onboarding
Service requests
Complaints
Sales enquiries
Account changes
Customer communication
Again, the system is not the process.
It supports the process.
That distinction remains important.
6.25 E.R.P and the Customer Journey
E.R.P systems are often thought of as internal systems.
But they can have a major effect on the customer experience.
Suppose a customer places an order.
The customer may see:
Order confirmation
↓
Status update
↓
Delivery
Behind the scenes, E.R.P processes may support:
Order processing
↓
Inventory
↓
Fulfilment
↓
Dispatch
The customer experience depends partly on those internal processes working correctly.
The customer may never see the E.R.P system.
They certainly experience its consequences.
6.26 Designing the Future Experience and Future Process Together
This is a powerful practice.
Do not design the customer journey first and throw it over to the process team.
Do not design the process first and expect the U.X team to make it attractive.
Instead:
Design the desired experience
and
Design the supporting process
together.
Ask:
What should the customer experience?
Then:
What must the organisation do to deliver that experience?
Then:
What technology is required?
Then:
What should be automated?
Then:
Where could A.I help?
That creates a connected design process.
6.27 Experience-Led Process Improvement
Traditional process improvement may ask:
How can we reduce processing time?
Experience-led improvement asks:
How can we reduce processing time while also making the experience easier?
Traditional improvement may ask:
How can we reduce the number of employee interactions?
Experience-led improvement asks:
How can we remove unnecessary interactions while keeping the customer properly supported?
The difference is subtle but important.
The objective is not efficiency at any cost.
It is better end-to-end outcomes.
6.28 Experience-Led Automation
Automation should also be judged through the experience it creates.
A badly designed chatbot can increase customer frustration.
An automated notification sent too frequently can become annoying.
An automated form that rejects legitimate requests can create unnecessary work.
Automation is therefore not automatically an improvement.
The right question is:
Does the automation make the overall journey better?
6.29 Experience-Led A.I
The same principle applies to A.I.
A.I could:
Help customers understand a process
Help employees answer questions
Identify missing information
Provide updates
Summarise cases
Support complex service interactions
Route requests intelligently
But A.I should serve a purpose.
A chatbot does not improve a customer journey simply because it is a chatbot.
An A.I assistant is valuable when it makes the experience clearer, faster, easier or more effective.
6.30 The Connected Enterprise View
We can now connect everything we have discussed.
C.X
tells us what experience we want to create.
C.J.M
shows how that experience unfolds over time.
Service Design
shows how the service should work across frontstage and backstage activities.
B.P.M
shows how the organisation performs the work.
Business Analysis
turns needs into requirements.
E.R.P, C.R.M, B.P.M and other systems
support the processes.
Automation
removes appropriate manual work.
A.I
adds new forms of assistance, analysis, decision support and autonomous activity.
That is the larger picture.
6.31 One Customer Journey Can Cross an Entire Enterprise
Consider something as simple as:
Customer requests a new service
The journey may involve:
Website
↓
Application
↓
Identity verification
↓
Availability check
↓
Order processing
↓
Service activation
↓
Customer notification
↓
Customer support
↓
Ongoing service
Behind that journey may sit:
C.X
U.X
Product
Service Design
B.P.M
C.R.M
E.R.P
I.T.S.M
Workflow
A.P.I's
Automation
A.I
That is why modern transformation cannot operate in isolated disciplines.
The customer experiences one journey.
The organisation must coordinate the whole system behind it.
6.32 The Golden Rule
Here is the principle to carry into the rest of the Article:
Design the experience you want to create, then design the process required to deliver it.
Not the other way around.
And once the desired process is clear, decide which parts should be performed by people, systems, automation and A.I.
6.33 The Big Picture
Business Process Management is no longer just about internal efficiency.
It is increasingly about the complete experience produced by the organisation.
A process can affect:
Customer Experience
Customer Journey
Citizen Experience
Employee Experience
User Experience
Service Experience
And those experiences are shaped by:
People
Processes
Data
Technology
Policies
Controls
Automation
A.I
The strongest process transformation therefore connects all of them.
The organisation does not simply improve a process.
It improves what happens to the person at the other end of that process.
And once we understand this broader ecosystem, we need another question:
What standards, frameworks and recognised good practices can help organisations design and manage these processes properly?
That takes us to the world of iso, E.F.Q.M, A.P.Q.C, C.M.M.I, bpmn, Lean, Six Sigma, cobit, itil, togaf and many others.
7. B.P.M Standards, Frameworks and Best Practice
By now we have seen that Business Process Management touches almost everything:
People
Processes
Customers
Services
Data
Technology
Risk
Automation
A.I
So naturally, organisations have developed many standards and frameworks to help manage all of this.
This can be confusing for a beginner.
You may hear:
iso 9001
E.F.Q.M
A.P.Q.C
C.M.M.I
bpmn
itil
cobit
togaf
scor
etom
and many others.
Are they competitors?
Do you choose one?
Do you need all of them?
Not really.
The easiest way to understand them is to recognise that they solve different problems.
7.1 Standards, Frameworks and Methodologies Are Not the Same
This is the first thing to understand.
A standard provides agreed requirements or guidance.
A framework provides a structured way of thinking about a subject.
A methodology provides an approach for carrying out work.
A reference model provides a reusable model that organisations can adapt.
A maturity model helps assess how capable or developed an organisation or process is.
A process modelling notation provides a language for representing processes.
These categories overlap.
But they are not identical.
That is why trying to find one framework that does everything usually leads to disappointment.
7.2 iso 9001
One of the most important standards for process management is iso 9001.
iso 9001 is a quality management standard.
At its heart are ideas that fit naturally with B.P.M:
Process approach
Customer focus
Risk-based thinking
Measurement
Continual improvement
Defined responsibilities
Controlled ways of working
The new iso 9001:2026 edition was published in September 2026. iso continues to describe customer focus, the process approach, risk-based thinking and continual improvement as central principles.
This makes iso 9001 extremely relevant to B.P.M.
You can think of it as asking:
“Does the organisation have a disciplined management system that consistently produces the intended results and improves over time?”
That is very close to the heart of process management.
7.3 The Wider iso Family
iso has many other standards that can influence business processes.
For example:
iso 31000
Provides guidance for risk management including identifying, analysing, evaluating, treating, monitoring and communicating risk. The current published edition remains iso 31000:2018 while a new edition is under development.
iso 37301
Focuses on compliance management systems.
iso/I.E.C 27001
Focuses on information security management systems.
iso/I.E.C 20000 to 1
Focuses on service management systems including planning, design, transition, delivery and continual improvement of services.
iso 22301
Focuses on business continuity management systems and organisational resilience.
iso 55001
Focuses on asset management systems and the systematic management of assets throughout their lifecycle. The current edition is iso 55001:2024.
The important lesson is that these standards do not replace B.P.M.
They can become requirements, controls or good-practice inputs into B.P.M.
7.4 iso/I.E.C 19510 and bpmn
Now we come to something much more directly connected with process modelling.
bpmn stands for:
Business Process Model and Notation
The international standard is iso/I.E.C 19510.
It provides a standardised notation for representing business processes and was designed to create a bridge between business process design and technical implementation. The current iso/I.E.C 19510:2013 edition was reviewed and confirmed in 2022.
That is why bpmn is so useful.
A Business Analyst can understand it.
A Business Process Consultant can use it.
A technical team can interpret it.
A Process Owner can use it to discuss the process.
A developer can use it as a basis for implementation.
It gives everyone a common language.
7.5 bpmn, D.M.N and C.M.M.N
bpmn is not the only modelling language relevant to process work.
A useful trio is:
bpmn
Shows how work flows.
D.M.N
Decision Model and Notation shows how business decisions and rules can be modelled.
C.M.M.N
Case Management Model and Notation is useful where work is less predictable and depends on the circumstances of an individual case.
A simple way to remember them is:
bpmn = How does the work flow?
D.M.N = How is the decision made?
C.M.M.N = How is the case managed?
Together they give process professionals a much broader modelling toolkit.
7.6 A.P.Q.C Process Classification Framework
One of the most useful references for enterprise process architecture is the A.P.Q.C Process Classification Framework, usually called the P.C.F.
A.P.Q.C describes the P.C.F as a taxonomy of business processes that helps organisations name, organise and map processes and compare performance. The current cross-industry version is P.C.F 8.0.
This is particularly valuable when an organisation asks:
“What processes do we actually have?”
The P.C.F provides a common structure.
Instead of every department inventing its own terminology, the organisation can establish a common process language.
This is particularly helpful for:
Process inventories
Process architecture
Benchmarking
Process ownership
Transformation programmes
Process repositories
A.P.Q.C also provides industry-specific versions where a generic cross-industry taxonomy needs more detail.
7.7 Why A.P.Q.C Matters to Our Universal Framework
A.P.Q.C gives us something very important:
A way of organising processes.
bpmn gives us:
A way of modelling processes.
iso 9001 gives us:
A management-system perspective.
Already we can see how different frameworks can fit together.
We do not need one to replace another.
7.8 E.F.Q.M
The E.F.Q.M Model operates at a broader organisational level.
E.F.Q.M describes its model as a globally recognised management framework supporting organisations in managing change and improving performance.
Its structure is built around three broad questions:
Why?
Why does the organisation exist and what direction is it taking?
How?
How will it deliver its purpose and strategy?
What?
What has it achieved and what does it intend to achieve?
E.F.Q.M refers to these areas as Direction, Execution and Results.
This makes E.F.Q.M useful when B.P.M needs to connect with:
Strategy
Organisational performance
Leadership
Transformation
Stakeholders
Results
Continual improvement
A process does not exist merely to complete activities.
It exists to help the organisation achieve outcomes.
E.F.Q.M helps keep that bigger picture visible.
7.9 Baldrige Excellence Framework
The Baldrige Excellence Framework takes another organisation-wide view.
It focuses on areas such as:
Leadership
Strategy
Customers
Measurement
Workforce
Operations
Results
The important B.P.M connection is operations.
Processes are part of how an organisation turns its strategy into real-world results.
So Baldrige can help answer a bigger question:
“How well does the organisation as a whole operate and perform?”
B.P.M can then go deeper into the actual processes creating those results.
7.10 C.M.M.I
C.M.M.I, or Capability Maturity Model Integration, is strongly associated with process capability and organisational maturity.
Its current maturity scale runs from:
Level 0: Incomplete
Work is ad hoc or unknown.
Level 1: Initial
Work is unpredictable and reactive.
Level 2: Managed
Work is planned, performed, measured and controlled at the project level.
Level 3: Defined
Organisation-wide standards guide work.
Level 4: Quantitatively Managed
Performance is measured and controlled using data.
Level 5: Optimizing
The organisation continually improves and adapts.
C.M.M.I describes these maturity levels as a staged path for performance and process improvement.
This is particularly useful when an organisation asks:
“How mature are we?”
7.11 iso/I.E.C 33000
The iso/I.E.C 33000 family also addresses process assessment.
iso describes the family as providing a framework for assessing process quality characteristics such as capability and organisational maturity. Assessment results can support process improvement, benchmarking and risk identification.
This connects very nicely with the maturity assessment framework we will develop later in this Article.
We can learn from C.M.M.I.
We can learn from iso/I.E.C 33000.
We can learn from other maturity models.
Then we can create a practical model specifically for enterprise B.P.M.
7.12 Lean
Lean is not an iso-style standard.
It is an approach to improving the flow of work and reducing activities that do not add value.
The famous Lean ideas include:
Value
Flow
Pull
Waste reduction
Continuous improvement
Lean encourages us to ask:
“What is the customer actually receiving value from?”
That question can expose unnecessary movement, waiting, duplication and complexity.
7.13 Six Sigma
Six Sigma focuses heavily on reducing variation and defects through disciplined measurement and analysis.
One of its most familiar approaches is dmaic:
Define
What problem are we solving?
Measure
What is happening now?
Analyse
Why is it happening?
Improve
What should change?
Control
How do we sustain the improvement?
Notice something familiar?
That is very close to the B.P.M improvement cycle we explored earlier.
7.14 Lean Six Sigma
Lean and Six Sigma are often combined.
The basic idea is attractive:
Lean helps remove waste and improve flow.
Six Sigma helps reduce variation and defects.
Together they provide a powerful process improvement toolkit.
They are particularly useful inside the Improve part of a B.P.M lifecycle.
7.15 cobit
cobit focuses on governance and management of enterprise information and technology.
The current cobit 2019 framework contains 40 governance and management objectives linked to processes, enterprise goals and alignment goals.
Why does this matter to B.P.M?
Because many modern processes depend heavily on technology.
cobit can help address questions such as:
Who governs technology?
Who is accountable?
How is performance measured?
How are risks managed?
How are technology-related processes controlled?
How does technology support enterprise objectives?
cobit therefore adds an important governance dimension.
7.16 itil
itil is particularly relevant to service management and technology-enabled services.
And there is an important current development to know about.
In 2026, itil Version 5 became the latest version of the framework. The official itil site describes it as building on key concepts from itil 4 while introducing a more practical approach to applying guidance in an A.I-enabled world.
The B.P.M connection is obvious.
Service management is full of processes and value streams.
Examples include:
Incident management
Service request management
Change management
Service configuration management
Monitoring
Problem management
Continual improvement
itil therefore provides specialist process guidance for the service-management environment.
It should not be confused with a universal B.P.M framework.
7.17 togaf and Enterprise Architecture
togaf is an Enterprise Architecture standard and framework.
Why does it belong in a B.P.M Article?
Because processes do not operate alone.
They depend on:
Capabilities
Applications
Data
Technology
People
Organisation
togaf provides a broader architecture perspective.
The current togaf Standard is the 10th Edition and The Open Group positions it as a configurable approach for enterprise architecture across commercial organisations and public-sector environments.
This helps answer an important B.P.M question:
“What technology and organisational architecture do we need to support this process?”
7.18 ArchiMate
ArchiMate complements Enterprise Architecture work by providing a modelling language for describing relationships across architecture domains.
The Open Group describes ArchiMate as an open and independent modelling language that helps architects describe, analyse and visualise relationships between business, application and other architectural domains.
This makes it useful for connecting:
Process
to:
Capability
to:
Application
to:
Data
to:
Technology
That is exactly the kind of relationship a large B.P.M programme needs to understand.
7.19 scor
Some sectors need specialised process reference models.
Supply chains are a good example.
The scor Digital Standard, from A.S.C.M, provides a structured reference for analysing, measuring and improving supply-chain processes. It incorporates process engineering, leading practices, benchmarking, people capabilities and metrics.
scor is therefore an excellent example of an industry-focused process reference model.
A large organisation does not need to reinvent supply-chain terminology from scratch.
It can use an established reference model and adapt it.
7.20 etom
Telecommunications provides another excellent example.
The T.M Forum Business Process Framework, commonly known as etom, categorises business activities used by service providers and allows processes to be progressively decomposed into greater detail. The current T.M Forum production suite is version 26.0.
etom is useful because it shows how a specialised industry can develop a detailed process reference model while still fitting within a wider enterprise architecture.
7.21 There Are Many More
The world of process frameworks is much larger than the names we have covered.
Depending on the organisation and industry, practitioners may also encounter:
I.T4I.T
iso 13485
iso 45001
iso 14001
iso 50001
iso 15189
iso/I.E.C 17025
Automotive spice
I.E.C standards
Government architecture frameworks
Defence reference architectures
Healthcare process models
Manufacturing reference models
Supply-chain reference models
Telecommunications reference models
Industry-specific A.P.Q.C frameworks
The list can become enormous.
So should an organisation adopt everything?
Definitely not.
7.22 The Big Mistake: Framework Collection
There is a danger in collecting frameworks.
An organisation may end up with:
iso 9001
plus:
E.F.Q.M
plus:
C.M.M.I
plus:
cobit
plus:
itil
plus:
Lean Six Sigma
plus:
togaf
plus:
A.P.Q.C
plus several industry models.
People then spend more time discussing frameworks than improving processes.
That misses the point.
Frameworks are tools.
They are not the objective.
7.23 Use the Right Framework for the Right Question
A much better approach is to ask:
What question are we trying to answer?
If the question is:
How should we classify our enterprise processes?
Look at A.P.Q.C P.C.F.
If the question is:
How should we model a process?
Look at bpmn.
If the question is:
How mature are our processes?
Look at C.M.M.I and iso/I.E.C 33000.
If the question is:
How should quality be managed?
Look at iso 9001.
If the question is:
How should the organisation pursue broader organisational excellence?
Look at E.F.Q.M or Baldrige.
If the question is:
How should technology governance work?
Look at cobit.
If the question is:
How should enterprise architecture connect processes, capabilities, applications and technology?
Look at togaf and ArchiMate.
If the question is:
How should I.T-enabled services be managed?
Look at itil and iso/I.E.C 20000 to 1.
If the question is:
How should risk be managed?
Look at iso 31000.
If the question is:
How should supply-chain processes be structured?
Look at scor.
If the question is:
How should telecommunications processes be structured?
Look at etom.
Now the landscape starts to make sense.
7.24 How the Pieces Fit Together
Imagine an organisation wants to transform its employee onboarding process.
It could use:
A.P.Q.C
to help classify and structure the process.
bpmn
to model the current and future process.
iso 9001
to strengthen quality management.
iso 31000
to consider process risks.
iso/I.E.C 27001
to consider information-security controls.
togaf and ArchiMate
to connect the process with applications, data and technology.
Lean Six Sigma
to improve flow and remove waste.
C.M.M.I or iso/I.E.C 33000
to assess capability and maturity.
itil
where the onboarding process includes I.T service-management activities.
This is not duplication.
Each contributes something different.
7.25 Standards Should Support the Process
The process comes first.
Then we ask which standards and frameworks are relevant.
Not:
“We have to use iso 9001 so let's make the process fit iso 9001.”
Instead:
“We need a reliable process. Which parts of our management system, standards and controls should shape it?”
That is a much healthier approach.
7.26 Certification Is Not the Same as Capability
Another important distinction:
Being certified does not automatically mean a process is excellent.
An organisation can have a certificate and still have frustrating processes.
Likewise, an organisation can have excellent processes without pursuing every available certification.
Certification can provide assurance and structure.
Capability comes from how well the organisation actually operates.
The process still has to work.
7.27 The Same Process Can Use Several Frameworks
This is completely normal.
Consider an I.T service process.
It might be:
Classified using A.P.Q.C
Modelled using bpmn
Managed using itil
Aligned with iso/I.E.C 20000 to 1
Protected using iso/I.E.C 27001
Governed using cobit
Mapped within togaf and ArchiMate
Improved using Lean
That sounds like a lot.
But each framework is answering a different question.
7.28 What We Can Learn From the World's Frameworks
This is where our Article becomes particularly interesting.
When we look across all these standards and frameworks, recurring ideas appear again and again.
They repeatedly emphasise:
Purpose
Why does the process exist?
Customer or stakeholder needs
Who benefits from the process?
Process definition
What exactly happens?
Ownership
Who is accountable?
Governance
How is the process controlled?
Performance
How do we know it works?
Risk
What can go wrong?
People
Who performs the work?
Information
What information is required?
Technology
What supports the process?
Improvement
How does the process become better?
This common ground is extremely valuable.
7.29 The Foundation for Our Universal Framework
This gives us the foundation for the next and final chapter.
We do not need to choose between iso 9001, E.F.Q.M, A.P.Q.C, C.M.M.I, bpmn, itil, cobit, togaf, scor and etom.
Instead, we can ask:
What does each framework teach us about effective process management?
Then we can bring the common elements together.
The result should not be another giant methodology.
It should be something much more practical.
A framework that an organisation can use regardless of:
Industry
Size
Public or private sector
E.R.P platform
B.P.M platform
Technology architecture
Operating model
7.30 The Golden Rule
There is one principle to remember:
Use standards and frameworks as building blocks, not as cages.
Take what is relevant.
Connect it to the organisation's objectives.
Adapt it to the context.
Keep the process understandable.
And above all:
Use the framework to improve the organisation.
Do not make the organisation serve the framework.
7.31 The Big Picture
We have now travelled quite a distance.
We started with a very simple question:
What is a process?
We then learned how to:
Understand it
Map it
Measure it
Improve it
Redesign it
Automate it
Use A.I within it
Connect it to C.X and C.J.M
And now we have seen that there is a huge body of established knowledge surrounding process management.
But something is still missing.
We have all these pieces.
What if we could bring them together into one practical framework?
Something a medium or large organisation could use across public and private sectors.
Something that works whether the organisation uses sap, Oracle, Microsoft, ServiceNow, Appian, Pega, Camunda or something else entirely.
Something that accommodates people, processes, customers, data, technology, controls, automation and A.I.
8. A Universal Enterprise B.P.M Framework
We have now looked at business processes from almost every direction.
We have asked:
What is a process?
How do we analyse it?
How do we improve it?
Who manages it?
How do E.R.P and B.P.M platforms support it?
Where can automation help?
Where can A.I help?
How does the process affect customers and employees?
What standards and frameworks can guide us?
Now we can bring everything together.
The goal is not to create yet another complicated methodology.
It is to create something simpler:
A Universal Enterprise B.P.M Framework that any medium or large organisation can use to understand, manage and improve its business processes.
It should work in:
Public-sector organisations
Private-sector organisations
Large enterprises
Medium-sized organisations
Different industries
Different operating models
Different technology environments
It should also work whether the organisation uses:
sap
Oracle
Microsoft
ServiceNow
Appian
Pega
Camunda
Other B.P.M platforms
Custom applications
Mostly manual processes
The framework should belong to the organisation, not to a software vendor.
8.1 What Should a Universal Framework Cover?
A serious enterprise process framework needs to consider much more than process diagrams.
It needs to connect:
Strategy
Customers and stakeholders
Processes
People
Governance
Risk
Controls
Data
Technology
Automation
A.I
Performance
Continuous improvement
That gives us the foundation.
8.2 The Framework in One Picture
The framework can be understood as a connected chain:
Strategy
↓
Outcomes
↓
Customer, Citizen and Employee Needs
↓
Capabilities
↓
Processes
↓
People and Organisation
↓
Data and Information
↓
Technology
↓
Automation and A.I
↓
Performance and Controls
↓
Continuous Improvement
And then the improvement cycle feeds back into strategy.
It is not a straight line.
It is a continuous system.
8.3 Layer 1: Strategy and Outcomes
Every process should have a reason for existing.
That reason should ultimately connect to what the organisation is trying to achieve.
For example:
An organisation may want to:
Deliver better services
Improve customer experience
Increase operational efficiency
Improve employee experience
Expand services
Strengthen resilience
Improve quality
Meet regulatory obligations
Reduce operational risk
Processes should support those outcomes.
A process that no longer contributes anything useful should be challenged.
The first question is therefore:
Why does this process exist?
8.4 Layer 2: Customer and Stakeholder Needs
The next question is:
Who is the process for?
This could be:
A customer
A citizen
An employee
A supplier
A partner
Another internal team
Another organisation
We need to understand what that person or organisation needs from the process.
This is where C.X, C.J.M and Service Design connect to B.P.M.
The process should not simply be efficient for the organisation.
It should produce the intended outcome for the recipient.
8.5 Layer 3: Enterprise Process Architecture
Now we need to understand the organisation's processes as a whole.
A large organisation may have thousands of processes.
We need a logical structure.
For example:
Enterprise
↓
Value Chain
↓
Process Group
↓
End-to-End Process
↓
Subprocess
↓
Activity
↓
Task
This creates an enterprise process architecture.
It allows people to answer:
“Where does this process fit?”
Without this structure, organisations often end up with disconnected process diagrams scattered across departments.
8.6 Layer 4: Process Ownership and Governance
Every important process should have an owner.
The Process Owner is accountable for the end-to-end health of the process.
Governance should establish:
Process ownership
Decision rights
Standards
Policies
Controls
Review arrangements
Escalation routes
Performance expectations
This is particularly important for processes that cross several departments.
A process cannot be truly end-to-end if nobody is responsible for the end-to-end result.
8.7 Layer 5: Process Design
Now we get to the process itself.
We define:
Trigger
What starts the process?
Inputs
What does the process need?
Activities
What work is performed?
Decisions
What determines the route?
Business rules
What rules apply?
Outputs
What does the process produce?
Exceptions
What happens when things do not go as expected?
Customers
Who receives the outcome?
This is where tools such as sipoc, process mapping, bpmn and D.M.N become useful.
8.8 Layer 6: People and Organisation
Processes are performed by people, technology or a combination of both.
We therefore need to understand:
Roles
Responsibilities
Skills
Capacity
Organisation structure
Decision rights
Segregation of responsibilities where appropriate
Training
Employee experience
A process may look perfect on paper but fail because employees do not have the time, skills or authority to perform it.
People are part of process design.
They are not an afterthought.
8.9 Layer 7: Data and Information
Every process needs information.
The information may include:
Customer information
Employee information
Product information
Asset information
Service information
Transaction information
Documents
Records
Knowledge
We need to know:
Where does the information come from?
Who owns it?
Is it accurate?
Where is it stored?
Who can access it?
Where does it move?
Bad information can destroy a good process.
A well-designed process therefore needs good information management.
8.10 Layer 8: Risk and Controls
Every significant process has risks.
Something could be:
Incorrect
Late
Missing
Misused
Inappropriately approved
Lost
Exposed
Incomplete
The process therefore needs appropriate controls.
Controls may include:
Validation
Approval
Review
Segregation of responsibilities
Access restrictions
Audit trails
Exception handling
Monitoring
But controls should be proportionate.
A process should be controlled without becoming unnecessarily complicated.
8.11 Layer 9: Technology
Only now do we reach technology.
The process may be supported by:
E.R.P
For core enterprise operations
C.R.M
For customer-related processes
I.T.S.M
For technology-enabled services
B.P.M platforms
For process management and orchestration
Workflow
For routing work
Case management
For flexible processes
Integration
For connecting systems
Data platforms
For information and analytics
The technology should support the process.
It should not define the organisation's entire operating model by accident.
8.12 Layer 10: Automation
Once the process has been understood and improved, we can identify automation opportunities.
Possible approaches include:
Workflow automation
A.P.I integration
R.P.A
Document automation
Rule-based automation
Intelligent document processing
Event-driven automation
Straight-through processing
The key question is:
Which activities should no longer require manual effort?
Not every activity should be automated.
Some require human judgement.
Some are simply too variable.
Some are better left with people.
8.13 Layer 11: A.I
A.I adds another dimension.
We can now ask:
Could A.I assist the employee?
Could A.I analyse information?
Could A.I classify requests?
Could A.I recommend a decision?
Could A.I handle routine exceptions?
Could an A.I agent perform part of the process?
The important thing is that A.I becomes a design option within the process rather than a separate technology experiment.
8.14 Layer 12: Performance
Every important process needs to be measurable.
The measures should cover the things that matter.
For example:
Cycle time
Waiting time
Quality
Volume
Rework
Backlog
First-time-right
Customer effort
Employee effort
Service performance
Compliance
Benefits
A process without meaningful measures is difficult to manage.
8.15 Layer 13: Continuous Improvement
This is the final layer and also the beginning of the next cycle.
The organisation should continually ask:
What is working?
What is not working?
What has changed?
What is causing problems?
What can be simplified?
What can be automated?
Where can A.I help?
What should be redesigned?
This creates a continuous loop:
Measure to Learn to Improve to Implement to Measure again
That is how processes remain healthy.
8.16 The Universal B.P.M Lifecycle
The framework becomes much easier to use when we turn it into a lifecycle.
Step 1: Align
Start with strategy and desired outcomes.
Ask:
What are we trying to achieve?
Step 2: Discover
Understand the current process.
Ask:
What actually happens today?
Step 3: Classify
Place the process within the enterprise process architecture.
Ask:
Where does this process belong?
Step 4: Model
Create the As-Is process.
Ask:
Can everyone see how the work flows?
Step 5: Measure
Establish the performance baseline.
Ask:
How well is the process performing?
Step 6: Diagnose
Find pain points and root causes.
Ask:
Why does the problem exist?
Step 7: Design
Create the To-Be process.
Ask:
How should the process work?
Step 8: Decide
Determine what should be:
Eliminated
Simplified
Standardised
Digitised
Automated
A.I-enabled
Kept human
Step 9: Build
Configure systems, change procedures and implement the new process.
Step 10: Test
Test:
Normal scenarios
Exceptions
Data
Integrations
Controls
User experience
Step 11: Deploy
Put the new process into operation.
Step 12: Stabilise
Monitor early performance and correct problems.
Step 13: Measure
Compare the new results with the original baseline.
Step 14: Improve
Continue the cycle.
That is the Universal B.P.M Lifecycle.
8.17 A Universal Process Structure
The framework can also be used to examine an individual process.
Take something simple like Customer Order to Delivery.
The process may contain:
Trigger
Customer places an order
Input
Order information
Activities
Validate to Process to Prepare to Dispatch to Deliver
Decision
Is the order valid and fulfilable?
People
Customer service to Operations to Warehouse to Delivery team
Data
Customer, order, product and delivery information
Technology
Customer portal to E.R.P to Warehouse system to Delivery system
Controls
Validation to approval where required to tracking to confirmation
Automation
Order routing to notifications to status updates
A.I
Customer query handling to exception analysis to delivery support
Output
Order delivered
Customer outcome
Customer receives the requested product or service
The same structure can be applied to thousands of different processes.
For another process, such as Invoicing, the specific activities change but the framework remains the same:
Trigger to Input to Activities to Decisions to People to Data to Technology to Controls to Automation to A.I to Output to Outcome
That is what makes the framework universal.
8.18 The Process Maturity Assessment
Now we need a way to understand how mature an organisation's processes are.
We can use a simple six-level model.
Level 0: Unmanaged
Processes are largely invisible.
Work depends heavily on individuals.
Documentation is limited or absent.
Performance is poorly understood.
Ownership is unclear.
Level 1: Ad Hoc
Processes exist but vary considerably.
Different people perform the work in different ways.
Problems are usually dealt with when they occur.
Little formal measurement exists.
Level 2: Documented
Important processes have been identified and documented.
Basic roles are understood.
Procedures exist for significant activities.
Some performance information is available.
Level 3: Controlled
Processes have clear ownership.
Standards are established.
Performance is measured.
Risks and controls are understood.
Process governance exists.
Variation is actively managed.
Level 4: Optimised
Processes are regularly analysed and improved.
Process data is used to identify opportunities.
Automation is used appropriately.
End-to-end performance is actively managed.
Continuous improvement is embedded.
Level 5: Intelligent
Processes are highly integrated and data-driven.
Automation and A.I are used strategically.
Process behaviour is monitored continuously.
A.I can support decisions and selected activities.
The organisation can adapt processes quickly based on evidence.
The objective is not simply to achieve Level 5 everywhere.
That would be unnecessary.
A simple low-risk process may not need sophisticated A.I.
A critical enterprise process may need much stronger capabilities.
Maturity should be appropriate to the process.
8.19 Assess More Than the Process
Maturity should not be measured only by asking:
“Do we have a process map?”
A more useful assessment looks across several dimensions.
Assess:
Strategy
Does the process clearly support organisational objectives?
Architecture
Is the process properly positioned within the enterprise process landscape?
Governance
Is ownership and decision-making clear?
People
Are responsibilities and skills appropriate?
Process Design
Is the process clearly defined and understood?
Performance
Are meaningful K.P.I's available?
Risk and Controls
Are risks and controls understood?
Data
Is the information reliable and accessible?
Technology
Does technology appropriately support the process?
Automation
Are suitable activities automated?
A.I
Are A.I opportunities understood and governed?
Customer Experience
Does the process produce the intended experience?
Continuous Improvement
Is improvement systematic rather than occasional?
This provides a far richer picture of maturity.
8.20 The Enterprise Process Repository
A medium or large organisation should maintain a central view of its processes.
This could be called an Enterprise Process Repository.
It should help answer:
What processes do we have?
Who owns them?
Where are they documented?
Which systems support them?
What K.P.I's are used?
What risks exist?
What controls exist?
How mature is each process?
What automation exists?
Where is A.I being used?
What improvements are planned?
The repository becomes the organisation's process memory.
Without it, process knowledge becomes scattered across documents, systems and individuals.
8.21 The Process Portfolio
Not every process deserves the same amount of attention.
A process portfolio helps the organisation decide where to focus.
Processes can be considered according to:
Business importance
How important is the process to organisational outcomes?
Customer impact
How much does the process affect customers, citizens or employees?
Risk
What happens if the process fails?
Volume
How frequently does it occur?
Complexity
How complicated is it?
Performance
How well does it currently operate?
Automation potential
Could technology remove significant manual work?
A.I potential
Could A.I materially improve the process?
This helps identify where improvement effort is most valuable.
8.22 The B.P.M Centre of Excellence
Large organisations may establish a B.P.M Centre of Excellence, or B.P.M CoE.
The CoE can provide:
B.P.M standards
Process modelling standards
Templates
Training
Governance
Process architecture
Process maturity assessments
Tool guidance
Process assurance
Best practices
Improvement methods
The CoE does not necessarily own every process.
It helps the organisation manage processes consistently.
Think of it as the organisation's B.P.M capability hub.
8.23 The Complete Process Professional Toolkit
A mature B.P.M capability should have practical tools ready to use.
These may include:
Process Inventory
What processes exist?
Process Classification
Where does each process belong?
Process Owner Charter
Who is accountable?
sipoc
What enters and leaves the process?
As-Is Process Map
How does the process work today?
Pain-Point Register
What is wrong?
Root Cause Analysis
Why is it wrong?
K.P.I Catalogue
How is performance measured?
Risk and Control Assessment
What could go wrong and how is it controlled?
To-Be Process
How should it work?
Gap Analysis
What needs to change?
Automation Assessment
What can be automated?
A.I Opportunity Assessment
Where could A.I create value?
Business Case
Why should we invest?
Implementation Roadmap
How will the change happen?
Benefits Realisation
Did the change actually work?
These are practical tools rather than theoretical exercises.
8.24 One Framework, Many Industries
The real test of a universal framework is whether it can cross industries.
Consider:
Healthcare
Patient registration to assessment to treatment to discharge
Manufacturing
Demand to planning to production to quality to dispatch
Telecommunications
Customer request to validation to provisioning to activation to support
Government
Application to assessment to decision to notification to service delivery
I.T
Request to assessment to approval to fulfilment to closure
Property
Requirement to assessment to allocation to handover to support
The details are completely different.
The underlying process logic is remarkably similar.
That is why a universal B.P.M framework is possible.
8.25 Public and Private Sector
The framework also needs to work in both sectors.
A private organisation may focus heavily on:
Customer experience
Growth
Productivity
Quality
Operational performance
A public organisation may place greater emphasis on:
Citizen experience
Public value
Accessibility
Accountability
Policy outcomes
Compliance
The process principles remain broadly the same.
The emphasis can change.
That is exactly what a flexible framework should allow.
8.26 What the Framework Deliberately Does Not Do
A universal framework should not prescribe:
One E.R.P
There is no single correct E.R.P for every organisation.
One B.P.M platform
Different organisations have different needs.
One modelling tool
The tool is less important than having a shared approach.
One maturity target
Not every process needs the same level of sophistication.
One organisation structure
Process ownership can work within many operating models.
One methodology
Different projects may require different delivery approaches.
The framework describes what should be considered.
The organisation decides how to implement it.
8.27 The Universal Process Question Set
A useful way to use the framework is simply to ask twelve questions.
1. Why does this process exist?
2. Who needs its outcome?
3. What starts it?
4. What actually happens?
5. Who owns it?
6. How well does it perform?
7. What can go wrong?
8. What information does it need?
9. What technology supports it?
10. What should be eliminated, simplified or standardised?
11. What should be automated or supported by A.I?
12. How will we continue improving it?
These twelve questions can be applied to almost any enterprise process.
8.28 The Universal B.P.M Model
We can now reduce the entire Article to one model:
Purpose
Why does the process exist?
↓
Experience
Who receives the outcome and what do they need?
↓
Process
How should the work flow?
↓
People
Who performs and owns it?
↓
Information
What data and knowledge are required?
↓
Controls
What risks must be managed?
↓
Technology
What systems support the process?
↓
Automation
What repetitive work can technology perform?
↓
A.I
Where can intelligent assistance or autonomous activity add value?
↓
Performance
How do we know the process is working?
↓
Improvement
How do we make it better?
Then the cycle begins again.
8.29 The Future Enterprise
The organisations that manage processes well will increasingly think differently.
They will not ask only:
“Which system do we need?”
They will ask:
“What is the best way for this work to happen?”
They will not ask only:
“Can we automate it?”
They will ask:
“Should this activity be performed by a person, a rule, automation, A.I or a combination?”
They will not ask only:
“Is our department efficient?”
They will ask:
“Is the end-to-end process producing the right outcome?”
And they will not ask only:
“Did we implement the project?”
They will ask:
“Did we actually improve the result?”
That is the mindset of mature process management.
8.30 The Final Lesson
Business Process Management can sound complicated.
There are standards.
Frameworks.
Tools.
E.R.P systems.
B.P.M platforms.
Process-mining products.
Automation technologies.
A.I agents.
There are consultants, analysts, architects and project managers.
There are hundreds of methodologies and thousands of process diagrams.
But underneath all of that, the discipline remains remarkably simple.
Understand the outcome.
Understand the people.
Understand the process.
Measure the result.
Control the risks.
Use information properly.
Use technology intelligently.
Automate where it makes sense.
Use A.I where it adds genuine value.
Keep improving.
That is the essence of Business Process Management.
And that is the purpose of A Universal Enterprise B.P.M Framework:
To provide a simple, practical way of connecting strategy, experience, processes, people, data, governance, technology, automation, A.I, performance and continuous improvement into one coherent enterprise view.
The framework does not belong to a particular software vendor.
It does not belong to one industry.
It does not belong to one methodology.
It belongs to the organisation using it.
And perhaps that is the most important lesson of all:
Technology changes. Organisations change. Customers change. Processes change. The discipline of understanding how work creates outcomes remains.
This article was sourced via A.I by the Author.
Musab Qureshi
Emails: musabquk@hotmail dot com / mail@musab.co.uk
WhatsApp: +44 7857 709 573