Workflow projects automate tasks. Process programmes change how the work runs end to end — which means knowing what the process actually is, who owns it, how many undocumented variants exist, and which ones are worth keeping. Twopir Consulting runs that programme: discovery and mapping first, then orchestration across workflow, documents, bots and people. Discover, map, prioritise, orchestrate, measure, improve.
Nintex process automation is the programme-level work of understanding an end-to-end business process, deciding what it should be, and then running it across whichever mix of workflow, documents, bots and human steps it actually needs. Workflow automation is one component of that: a single automated flow. The distinction matters commercially, because an organisation with fifty excellent workflows and no process ownership still has an unmanaged estate.
| Process automation | Workflow automation | |
|---|---|---|
| Unit of work | An end-to-end business process — quote to cash, hire to retire, request to fulfilment. | One automated flow inside it, such as the approval stage or the document step. |
| Starting question | What is this process, who owns it, how many variants exist, and which of them should survive? | How should this specific flow be triggered, routed, handled and recovered when it fails? |
| Who is in the room | The process owner, the functions either side of the handoffs, and whoever answers for the outcome. | The people who use the flow, the system owners it touches, and the builder. |
| Tooling | Process discovery and mapping, plus whichever execution tools the process needs. | The workflow designer, forms and connectors. |
| Measure of success | The process is faster, more consistent and visible, and the documentation still matches reality. | The flow runs reliably, recovers from failure and can be changed safely. |
| Failure mode | A beautiful map nobody automates, or fifty automations with no owner and no measurement. | A flow that works in isolation while the process around it still leaks days at the handoffs. |
| Where to read more | This page. | Nintex workflow automation. |
Nintex Process Manager is the platform's home for documented, owned, living processes — mapped visually, published to the people who run them, with variations, feedback and governance reporting built in. Our job is the part that is not software: getting to the truth.
We interview the people who do the work, not only the people who designed it. The gap between the two is the finding — and it is usually where the workarounds, the shadow spreadsheets and the real cycle time live.
Most processes have more variants than anyone believes. Each one gets classified: a legitimate variation to model, a local workaround to remove, or a divergence nobody could justify when asked. Automating before this is how five-region processes become five permanent forks.
Someone accountable for the process, empowered to approve a change to it, and expected to review it. Nintex Process Manager supports that ownership structure and an administrator role to keep it honest; what it cannot supply is the person.
Where does it wait, how often does it go back a step, how many systems does one person touch, and what does an exception cost to resolve? Without a baseline there is no case for investment and no way to prove the result afterwards.
Approvals that exist because of a retired system, duplicate checks, and reviews nobody has ever rejected. Deleting a step is cheaper than automating it and always faster than the automation would have been.
The people inside the process are the earliest signal that it has drifted. Process Manager lets them raise that against the published process itself, which is the only mechanism we have seen keep documentation alive past its first year.
A real end-to-end process is rarely all workflow. It is workflow holding the state, people making judgement calls, documents carrying the output, and bots or integrations reaching systems that will not talk any other way. Nintex has consolidated these into a single platform experience; the architecture still has to decide which participant does what.
Exactly one component should know where the process is and what happens next. When two do, they disagree, and the reconciliation becomes somebody's permanent job. In our designs that component is the workflow.
Automation should remove the coordination, not the decision. We design the human steps to arrive with enough context to be answered in one pass, on a device the person actually uses, without opening three other systems first.
Most processes exist to produce something — a contract, a statement, a pack, a certificate. Generating it from the record rather than assembling it by hand removes a step, a delay and an entire class of error at once.
Attended bots assist a person on demand; unattended bots run without one. Both are legitimate, and both are more fragile than an API call — so we use them where there is genuinely no interface, and design the process to survive their failure.
The order matters more than the speed. Programmes that automate before standardising end up maintaining every variation they inherited, permanently.
Map the in-scope processes as performed, surface every variant, name the owners, and measure the friction. The deliverable is a documented current state that the people in the process recognise as true.
Score the candidates against volume, variability, systems touched, error cost and regulatory exposure. Some rise to the top, some are deferred, and some are recommended for deletion rather than automation.
Agree the target process and which variations survive. This is the political stage and the one most often skipped — and skipping it is what turns a programme into a set of unrelated automations.
Build the end-to-end flow across workflow, tasks, documents and system steps, with the state held in one place and the handoffs designed rather than assumed. Delivery runs to the gates on our implementation method.
Ownership, review cadence, a route for change requests, and a measurement that gets read. The map is updated when the process changes — not annually, and not never.
Usually not the loudest one. We score candidates on five dimensions and read them together — a process can be high volume and still be the wrong first choice if its variability is unresolved.
| Dimension | What raises the score | What should make you pause |
|---|---|---|
| Volume | It runs often enough that a small per-instance saving compounds into a real one. | It runs four times a year. The build and its maintenance will cost more than the manual effort. |
| Variability | The path is predictable, and the exceptions are few and nameable. | Every instance is judged case by case. Automate the coordination around it, not the decision inside it. |
| Systems touched | It crosses two or more systems, so people are currently re-keying between them. | It lives entirely inside one platform that already has native automation for it. |
| Cost of an error | Mistakes are expensive, slow to detect, or reach a customer before anyone notices. | Errors are obvious and cheap to fix. The controls may not repay their complexity. |
| Regulatory exposure | Approval sequence, thresholds or retention have to be evidenced to an auditor. | Nothing is required to be evidenced — in which case do not pay for an audit trail you will never use. |
We run this as a scored workshop with the process owners in the room. The output is a ranked list with the reasoning attached, so the sequence can be defended later — including to the person whose process came fourth.
Every process estate we have inherited was documented once. The difference between the ones that stayed useful and the ones that became fiction is four habits.
A process owner who has the authority to approve a change and is expected to review the process on a cadence. An owner who cannot say no is a name on a document, and the process will drift around them.
Every request for a new variation, a new approval or a new field goes through the same route and is judged against the standard process. Without it, the estate re-fragments through the side door within a year.
The earliest signal that a documented process no longer matches reality comes from whoever ran it this morning. Making that easy to raise — and visibly acted on — is what keeps the map honest.
Cycle time, exception volume and adoption reviewed on a cadence by a person who can act on them. Reporting that nobody opens has the same practical value as no reporting, at higher cost. See Nintex analytics and reporting.
No, and programmes that try usually stall before delivering anything. Map the processes you are about to touch, to the depth the automation decision needs, and map the rest as you reach them. The failure modes are symmetrical: automating with no map produces permanent bad process, and mapping everything first produces a large document and no working system. We aim to have something in production while the discovery of the next candidates is still running.
Usually yes, once you separate the variations that have a reason from the ones that are habit. In our experience a large share of regional difference turns out to be historical rather than regulatory, and disappears when someone finally asks why. What genuinely varies — statutory requirements, local approval thresholds, language — gets modelled as a configured variation of one process rather than as a separate process. One workflow with regional configuration is maintainable; five regional copies are five estates.
Both, with a clean split. The business owns the process: what the steps are, what the thresholds should be, and whether a proposed change is correct. IT owns the implementation: how it is built, how it integrates, how it performs and how it is released. The arrangement that reliably fails is the one where IT owns the process by default because they own the tool — the requests then arrive as technical change tickets and nobody is examining whether the process itself still makes sense.
As a participant, not as the strategy. A bot is the right answer when a system has no usable API and the only way in is the interface a person would click — attended when it assists someone on demand, unattended when it runs on its own. It is the wrong answer when an API exists, because a screen-level automation is far more fragile than a call and breaks on a cosmetic change nobody told you about. We design bot steps so the workflow expects them to fail occasionally, and we replace them with an integration as soon as one becomes available.
Almost always one of three things. The processes were written by a project team rather than by the people who run them, so they read as aspiration and nobody recognises them. Or there are no owners, so nothing is ever updated and the content ages out of usefulness. Or the maps were never connected to anything — reading a process is not part of anyone's day, so nobody does. The fix is rarely more mapping. It is ownership, a feedback route, and connecting the documented process to the system people actually work in.
By baselining before you start, which is the step almost everyone skips. During discovery we measure the current cycle time, rework rate, exception volume and manual touchpoints for the in-scope process, and those numbers become the comparison. Afterwards the same measures come from the running system rather than from a survey. If no baseline was captured, any later claim of improvement is an estimate, and we will say so rather than present it as a measurement.
A single process discovery gives you a documented current state, a measured baseline, a list of the steps worth deleting, and a defensible answer on whether automation is the right investment at all.
Process programmes where the map and the running system stay the same thing
