The Paradigm Shift in the BPM Market: First the Process, Then the Diagram

A BPM project can do many things right and still lose valuable time at the same point: between the described process and its actual implementation.

The people involved have discussed the procedure. Responsibilities are settled. A model captures decisions, deadlines and exceptions. Only then does the work begin of turning this shared idea into a usable application. Forms, data structures, permissions and notifications have to be created. And finally someone has to check whether the result really works outside the model.

This order made sense for a long time, because implementation was expensive. The model was the comparatively quick part. AI is now changing that balance: implementation no longer has to be the slow end of a BPM project. It can begin in the middle of the business discussion.

The bottleneck lies behind the model

Business process management created a common language for business departments and IT. A good process model makes procedures discussable. It shows who takes on which task and when, and which decisions determine the path ahead.

What a model does not show is the experience of the people who will work with it later. Does the department see the incoming application in its inbox? Can the second approval level read the fields it needs? Does a reminder really reach the right group when the deadline passes? Is the work done so far preserved after a case is sent back?

These questions cannot be answered from the diagram alone. They are decided in the running application.

Even so, implementation often began only after an extensive modelling and specification phase. By the time a gap became visible, the business group had often long since dispersed. The correction turned into a new cycle of coordination and development.

The order is reversed

At flying dog, requirements or existing documents first become a running business application. New requirements can be described in dialogue, or existing material can be used: process descriptions, PDFs, Visio diagrams or screenshots of a legacy system.

The AI uses MCP to build the parts that belong together:

• Data model and server-side logic
• Forms and user interfaces
• Roles and group inboxes
• Workflow, deadlines and escalations
• Notifications and mail templates

Its work does not stop there. It creates test accounts for the roles involved and plays the process through itself. Deadlines are actually fired with test values. Mail delivery can be traced in the send log. Findings are documented, and corrections lead to another run.

So the business group no longer sees only a description of the planned result. It can use the result.

The requirements document becomes a running object

This reversal also changes how people work together. A workshop no longer has to end with a promise to deliver an implementable specification later. A first prototype can become part of the discussion. What the participants correct goes into the next version, which is played through again.

For business departments this means judging the procedure from their own role instead of predicting its later effect from a model. IT gets a verifiable application state and a report on the actual run. Works councils and approvers get a usable prototype.

Documentation changes its place as well. At flying dog, BPMN 2.0 is generated from the built process. The model stays, but it is no longer the precondition for getting started. It describes the result instead of waiting for it to be implemented.

BPMN is the result, not the precondition.

What changes for the BPM market

The paradigm shift is not that AI can now draw boxes and arrows too. It is a new division of labour:

People decide how their organisation should work. They settle responsibilities, approvals, exceptions and the right business sequence. The AI takes over the implementation and testing cycle that used to translate these decisions into slow projects.

This moves the yardstick for BPM. Progress is no longer shown by the number of modelled processes, but by the time from a requirement to a tested, usable version. And the one-off go-live is no longer the only success. What counts is the ability to change a process just as quickly later and to test it completely again.

Everywhere else, the finished, tested process comes at the end of the paid project. With us it comes at the start, before you buy.

This is the new order: build first, then play through, then document. Or, as an offer to companies that want to experience this with their own procedure: Your finished process first. Then we talk.