What Is BPM in the AI Era: A Guide from the Ground Up

What is BPM, really? When we think about BPM — Business Process Management — we tend to think «it is expensive», «it is for large companies», «it eats too much management time» or «we are not ready for that yet». Is that what is actually behind BPM?

Ten years ago we already argued that all of those perceptions were wrong. Today, with artificial intelligence embedded in every stage of the discipline, they simply do not hold. In this article we explain BPM from first principles, in plain language and aimed at whoever has to decide on this without being technical — the CEO, the general manager, the board member — and then we go stage by stage showing what changes with AI. Our position up front: the stages are the same as always; what changes is how much they cost, how long they take and who can do them.

Everything that follows applies to BPM in general, as a discipline. That said, when we get to examples we are mostly thinking about no-code BPM (or low-code) platforms, which are today the most widely adopted by organizations everywhere, large or small. They are configured from the browser, require no programmers, and let you go from drawing the process to running it on the same day.

This does not mean traditional BPM Suites have disappeared. They still exist and are still the right choice for specialized cases: processes with enormous transaction volumes, deep integrations with legacy systems, very particular regulatory requirements. They are harder to implement and more expensive, but also more powerful. The distinction is worth keeping in mind, because when a vendor says «BPM» they may be talking about two rather different things in cost, timeline and the team needed to operate them.

A business process is a sequence of activities that happen in your company to achieve one of its objectives. It normally involves several people, each contributing a particular task. Consider this example: your company receives enquiries and product orders by email, by phone, through the website, through the call center or directly through the sales reps. In every case, once the order is received it is assigned to a rep, who contacts the customer to understand the need better and build a proposal. There are standard proposals, which go straight to the customer by email. And there are complex proposals, which need additional approval from the sales manager before they reach the customer. Let us say the customer can only do three things: buy, reject the proposal, or ask for changes. If they buy, the process continues through the rep, who coordinates delivery.

Does that sound complicated? Not really. That paragraph already describes a complete process, with its tasks, its owners, its decisions and its branches. What BPM does is formalize it, so it can be executed, measured and changed without depending on each person remembering exactly how it went.

And here it is worth returning to those opening perceptions. Manual processes do not scale. Put differently, a company that has to process twice the work per unit of time cannot do it by hand without costs exploding and competitiveness eroding. A no-code platform costs today what an office software license costs, and the first process is automated in days. No organization, whatever its size, should leave this for later.

BPM is organized as a continuous improvement cycle with four stages: model the process, automate it (put it to run on a platform), measure it through indicators (KPIs) and improve it based on what those indicators show. Once the fourth stage is done, you return to the first with a new version of the process, and the cycle repeats again and again. That is the discipline, and that is the part that has not changed in twenty years.

What did change, a lot, is what happens inside each stage. We will walk through them one by one, first with the traditional approach and then with what AI adds today. In each case we give a few illustrative examples, not a complete list; the uses of AI in processes multiply every month, and by the time you read this there are probably several more.

Modeling is essentially drawing the process: what tasks exist, who does them, in what order, what decisions are taken and what happens on each branch. In practice, when you model a process in order to run it, you have to define three things that go together. The flow itself (the diagram). The form — that is, what data travels in each instance of the process (the customer, the amount, the date, the attached documents). And the integrations with other systems: what needs to be read or updated in the CRM, the ERP or email when the process reaches a given point.

In the traditional approach, modeling was the slowest stage of the cycle. Meetings with each area, an analyst drawing, reviews, more meetings. Weeks, at best. And with an underlying problem we have all seen: the diagram aged fast, because the real process changed and nobody updated the drawing.

Today modeling is semi-automatic. The starting point is no longer a blank page but a prompt. You describe the process in natural language — a paragraph like the example above is enough — and the platform generates a first draft. For instance, from the sentence «complex proposals require sales manager approval», the AI proposes the approval task, the decision gateway and the approved and rejected branches. From the same text it infers the form fields (customer, proposal type, amount, assigned rep, due date) and proposes data types and validations. And if the prompt says «look the customer up in the CRM», it suggests the corresponding connector and the point in the flow where it belongs.

The draft is rarely perfect, and that does not matter. What changes is that you start from a process that is 80% done and correct it, instead of starting from zero. And something even more relevant: the person who knows the process — the sales manager, not the systems analyst — can model it directly and validate it in the same session. The model stops being an intermediate document and becomes the process itself, ready to run.

For the drawing to be executable and understood by everyone, a common notation is needed. By far the most used is still BPMN (Business Process Model and Notation), a standard from the Object Management Group (OMG) that is also an ISO norm. The current version, BPMN 2.0, is over a decade old, and it is the reference both in no-code platforms and in traditional BPM Suites. Years ago we wrote about why BPMN matters as much to a corporation with thousands of employees as to a small business, and the arguments still hold.

And the condition we consider decisive: the chosen tool must allow going directly from the BPMN model to its execution. Once the decision to automate a process is made, for it to really be a competitive instrument you must be able to go from drawing to production in hours, perhaps days, but never weeks or months. If there are weeks of development between the drawing and the running process, every adjustment costs too much, so it is not made, and continuous improvement never happens.

Here it pays to be precise, because there is a fair amount of noise in the market. The BPMN 2.0 standard has no native element called «AI task» or «agent». What exists are different ways of solving it with what the standard already provides, and all of them are in use today.

The most common is to use the existing elements as they are. A call to a language model is modeled as a service task, just like any other integration with an external system. A decision taken by the AI is modeled as a business rule task, or as a gateway whose condition evaluates what the model returned. And human review of the result is a user task, as always. This covers the vast majority of cases, and it is what no-code platforms do.

Another approach, more interesting, uses the ad-hoc sub-process that BPMN 2.0 has included from the start: a block where activities have no fixed order. The more advanced process engines reuse it to model AI agents. Inside the block you draw the tools the agent has available — query the CRM, send an email, ask a person for approval — and the agent decides at runtime which ones to use and in what order. The BPMN process around the block still controls the boundaries: what the agent may do, when a human steps in, what happens on timeout. It is a combination of bounded autonomy and governance that a board should want to see drawn before approving anything.

There are also academic proposals to extend the notation with agent lanes (carrying a confidence level and a role), «agentic» tasks with review strategies, and gateways where several agents collaborate. They are worth following closely, but they are not standard, and at the time of writing there is no formal OMG initiative toward a «BPMN 3.0».

Automating means putting the model to run. Each instance of the process — each order, each request, each claim — advances through the flow, and the platform takes care of assigning every task to the right person, notifying them, controlling deadlines, storing the form data and executing the integrations. Internal email, the shared spreadsheet and the «where did this end up?» question all disappear.

In the traditional approach, execution rules were fixed. Assignment followed a role table, notification texts were templates, and every query to an external system had to be programmed. This is the stage where AI plugs into the most points of the process, so it is worth giving several examples — illustrative ones, since there are many more.

One point worth fixing from the board: in all these cases the BPMN flow defines which tasks AI intervenes in, within what limits, and at which points a person validates. That is the difference between automating with AI and letting a chatbot «resolve» things with no traceability at all. It is also one of the questions a board should be asking about AI before approving an investment.

Modeling a process also means defining how it will be measured. It is part of the discipline, and it is what brings objectivity to the discussion about how the organization is actually performing. The classic BPM KPIs are few and powerful: cycle time (how long an instance takes end to end), time per task, volume processed per period, rejection or rework rate, deadline compliance, cost per transaction.

Since the platform records every step of every instance, the data was always there. The work was building the reports, looking at them and drawing conclusions. And that work, let us be honest, was done rarely and late in most organizations, because there was always something more urgent. With AI, measurement becomes continuous and cheap.

And beyond the data point, you get a probable explanation: «the increase in cycle time coincides with the credit verification step introduced in version 3 of the process». With that explanation in hand, the next stage starts halfway done.

With the KPIs in view, you have to draw conclusions, and those conclusions usually mean changing the process: removing a step, changing a condition, adding an approval, moving a deadline. Again, this is where having the process modeled in BPMN on a tool that runs it directly becomes essential, so introducing the improvement is simple and fast. Put differently: if changing a stage or a condition takes weeks or months, it will not be done. And therefore nothing will improve.

AI lowers the cost of each iteration even further, and it does so across the whole stage.

And with that we are back at stage 1, with a better version of the process, and with a cycle that now takes days instead of quarters.

AI does not decide which process to automate. That remains a business judgement: the process that hurts most, the one that repeats most, the one that crosses the most areas or the one that most affects the customer. Our advice is the same as it was ten years ago: start with one, just one, and learn with it. It is, at bottom, the same exercise of lifting your head and choosing a direction before swimming faster.

AI does not replace process governance; it demands it. Every point where a model decides or generates content is a point where you have to define who reviews, what gets logged and what happens when it gets it wrong. BPM is precisely the framework for that, because the drawn process says where AI intervenes and where it does not. A board approving «automate with AI» without seeing that drawing is approving something it does not fully understand.

And AI reduces the cost of each stage, not the need to do them. A badly modeled process that runs faster is still a badly modeled process. The discipline is the same; what happens is that the cycle turns many more times per year.