BPMN process automation Switzerland
Process automation that starts with reading, not with a diagram
You have an approval chain, a case file or a document run that today lives in email, a spreadsheet and one person’s head. Before we model anything, we read how it actually runs. What comes out of that is put in writing.
Describe your processFour starting points, and none of them is a blank sheet
What BPMN is and what it explicitly is not is a question about the notation, and not the subject of this page. Here it is about something else: what happens to your process, in what order, and what is left in your hands at the end.
Approval workflows
A request travels through three stages by email. Whose turn it is right now is recorded in no system. If someone is on holiday the case sits there, and nobody notices.
Document and case processing
A case consists of a folder, a spreadsheet and a mailbox. How far along it is can only be answered by someone going to look. What it is waiting on, nobody knows.
Operational task orchestration
Several systems have to do something in a particular order. Today a script or a person holds that order together. When it jams halfway, what has already run is unclear.
Modernising existing workflows
The flow was automated long ago, but the rules sit in the code of an application nobody enjoys touching. A change means searching, guessing, testing. The flow is written down nowhere.
Why it still runs in email anyway
Not because nobody could draw it. A diagram takes an afternoon. Between a diagram that documents the flow and one that executes it lies everything else.
The second reason is more mundane. The process everyone describes is not the process that runs. One person knows the exceptions, and they are written down nowhere. A model built on the description goes wrong at exactly those points. You find out in production.
Four steps, and the first two produce no code
1. We read the process as it runs
Not the process description. The mailbox, the spreadsheet, the exports from whatever holds it today, and the code that touches it. Plus the person who knows the exceptions. Without read access we do not start.
2. We write down what we found
The process as it actually runs, including the places where two departments describe the same step differently and both are certain. It also says what we would delete rather than automate. Which version stands is your decision. Not ours.
3. We model what an engine can execute
A drawn model and a running one are not the same thing. Only constructs an engine actually executes go into the model.
4. You get the operation, not just the model
Model, integrations and test cases sit in your repositories. Where a case stands and what it is waiting on is queryable, without anyone searching a mailbox. You should be able to run this without us.
The effort sits in one and two. Modelling comes afterwards, which is why it is third and not first.
What is left in your hands
| The process record | How the process actually runs today, in writing, including the places where two departments describe the same step differently, and what we would delete rather than automate. |
|---|---|
| The executable model | The flow as a model an engine executes. A file in your repository, versioned like code and openable in any BPMN modeler. |
| The integrations | The code the process uses to talk to your systems, so that nobody types anything in a second time. |
| The test cases | Your real cases, including the ones that go wrong. They run on demand and without us. |
| The operational view | Which case is where, since when, and what it is waiting on. Queryable, instead of searched for in a mailbox. |
We do not sell you a licence, and what we recommend hangs on no reseller agreement.
Often your existing supplier is the right answer
If the process happens entirely inside one system and that system ships a workflow module, its vendor is closer to it than we are. If we see that, we will tell you.
Three signs point the other way, and you can check all three yourself:
- •The process crosses system boundaries: ERP, document store, line-of-business app, mailbox.
- •The flow cannot be read out of the system. It sits in configuration, rules and forms, and nobody can print it.
- •The flow is part of your supplier’s product. Then what you own is not the process but the right to use it.
If it turns out that what you are missing is not a flow but an application, that belongs under custom software development.
Five things determine the effort, and you can see four of them yourself
There is no number on this page, because any number without the process would be a guess. What is here is the arithmetic behind it. It is the same one we do when we quote.
- •How many variants the process really has. The exceptions are the point. The main path does not count here.
- •How many systems it talks to, and whether each of them has a usable interface.
- •Whether the flow is decided, or still being negotiated between two departments.
- •Whether test cases exist, or have to be created first.
- •What happens to the cases already running today: carry them over, or let them run out.
You can estimate the first four before any conversation. We help with the fifth.
When you are in the wrong place
This fits you if a named process is holding people up, more than one system is involved, and somebody at your end is allowed to decide how the flow should work. It does not fit when:
- •The flow is still being negotiated between two departments. An engine does not settle the argument. It freezes it.
- •You cannot give us access to the systems the process talks to. A flow can be modelled from a description, but not integrated. And a model that docks onto nothing is a picture.
- •You need a binding number without anyone having spoken to you about the process first. After the call you get one; before it, nobody does.
- •It is a single form, with no cases, no deadlines, no handovers. A form tool is enough for that, and we will tell you so rather than sell you an engine.
- •You are looking for someone to confirm a tooling decision that has already been made.
- •There is nobody who is allowed to decide how the flow should work. Without that person the process record is a collection of opinions.
How it starts
1. You describe the process
A paragraph is enough: who triggers it, who signs off, which systems it touches, and how you notice when it jams. A screenshot or an existing diagram helps. It is not a prerequisite.
2. We come back within 48 hours
With a practical first step, and with the questions we have to ask before more can be said. No number: at this point we have had the process described to us, not seen it.
3. A 30-minute call, free of charge
What we need to know for an assessment we ask during that call and record there, rather than sending it to you as homework.
4. By the end of that call your path is named
Not “we will get back to you”. Either: this process belongs on an engine. Or: it needs a decision inside your organisation first, because two departments describe it differently. Or: it is too small for one, and a form tool will do. Which of the three is yours, we tell you while you are still on the phone.
5. The first step is quoted afterwards, with a fixed scope
The first step is the process record. Its scope is settled before the reading starts, which is why it can be quoted; everything after it cannot. A number for the after, produced before reading, is a guess. And we do not hand you a guess.
Three questions before the first call
- Do we have to choose a tool first?
- Not first. What the engine has to be able to do follows from what your systems speak and who runs the process afterwards.
- If you already have one in house, the first question is whether it is enough. We talk about replacing it only once the answer is no.
- We already have a diagram. Is that a basis to build on?
- As a basis for the conversation, yes. As a build specification, rarely. A diagram describes the process everyone describes, which is not necessarily the one that runs.
- What separates a drawn model from an executable one is the subject of our article on process modelling with BPMN. So we read the flow as it actually happens first, and compare it with the diagram.
- What if you are not reachable in two years?
- A fair question to put to any supplier. It cannot be answered with a reassurance, only with what sits on your side.
- The flow is written down as a model a subject-matter expert can read. The integrations are code in your estate. The test cases state what the process has to be able to do, and they run without us. Whoever takes over reads that and carries on.
Have a process that should stop living in email?
Send us the approval, task flow or document run that slows people down. A paragraph is enough. We come back within 48 hours with a practical first step; the call after that takes 30 minutes and costs nothing.
If the honest answer is that you do not need process automation for this, you hear it in that same call.
Request the free 30-minute callIs this process running on Camunda 7 today? Then the question upstream of it is where that estate is going: Camunda 7 migration.