For years, every conversation began with the same question: how do we get our workflows documented without spending six months modelling? That is a good question, and there is a good answer to it. You take what is already there — a work instruction, an SOP, a manual — and turn it into a readable process.
That question still gets asked. It is just rarely the only one any more.
What changed isn't the market. It's the question put to it.
Someone facing an SAP migration doesn't want to know how a process is documented. They want to know which workflows, roles and dependencies outside order-to-cash are affected — and no single document answers that; holdings from several systems have to be laid side by side. Someone who needs audit evidence doesn't want to see the modelling, but the places where documented and lived practice diverge. And anyone who wants AI agents to do work needs no diagram, but a structure a machine can act on.
These are not three expansion stages of the same task. They are three different relationships between what goes in and what comes out.
The three relationships
One source in, one process out. A document, a standard, an instruction is read, and out of it comes a structured workflow with roles, steps and responsibilities. That is the basic operation, and it is the most common one. This is ProcessCollector.
Many sources in, one process out. The same workflow is described in four places: in the quality manual, in the legacy system, in the department's wiki, and in the head of a colleague who leaves in two years. Those four descriptions contradict each other — not at random, but at the interesting points. Pulling them together and condensing them into one dependable version is a different operation from the first. This is ProcessMagnet.
The same sources, many results out. Once the knowledge is structured, the process is no longer the only conceivable result. From the same body you can derive a migration baseline, audit evidence, a training path, an interface for an agent. This is ProcessForge.
Fitting all three relationships into one interface is possible. It just means nobody can say what the solution is actually for any more — and that every explanation starts with "you can also…".
Why this isn't a product line
The obvious suspicion with three names is a tiering: small, medium, large. That misses it, and the difference matters.
The three solutions differ not in ambition, but in how much goes in and comes out at once. A small organisation may need stage three; a large one may do fine with stage one. The question isn't how many people someone employs, but which relationship they have to resolve.
And they build on one another, in one direction: starting at the bottom costs you nothing. ProcessMagnet contains ProcessCollector's Excellence mode, ProcessForge contains both. There is no point at which something would have to be gathered again because you chose the smaller stage first. That isn't pricing policy; it follows from all three working on the same data model.
What expressly does not happen
It would be easier to claim the solutions understand an organisation. They do not.
They read what is there and lay it together. What emerges is a proposal with a source reference — traceable back to the passage in the document it came from. It becomes insight only once people in the organisation check it, correct it and use it. That boundary is not caution and not fine print. It is the reason the solutions are built the way they are.
Equally deliberate: no smoothing of contradictions. When two sources describe the same workflow differently, you could produce a clean model by picking one. That would be a better diagram and a worse result. The places where two descriptions contradict each other are almost always the places where an initiative later gets stuck. They are named, not tidied away.
What this means for the work
For anyone working with one of the solutions today, nothing about the substance changes. What changes is the assignment: it is now possible to name which of the three tasks is at hand — and therefore when the next one arrives.
For everything beyond that, the same order holds as before: understand before deciding. An organisation that cannot dependably say how it actually works can neither automate nor evidence nor migrate. Not because the solutions are missing — but because the ground they need is.
Further reading
The theory behind it is under Thinking. The three solutions in detail: ProcessCollector, ProcessMagnet, ProcessForge.