We make your processes visible, measurable and governed.

Yes — it is one of our most common first conversations. We look at what you already hold: which components are licensed and actually used, the state of the model estate, whether governance runs. You get a written view with three options — invest, reduce or stop. Sometimes the right answer is to reduce the licence, and we say so.

Yes. We work under your licence, with accounts your administrator issues and revokes, and everything we build stays in your tenant. We do not resell SAP Signavio licences and we take no margin on them — so our advice on which components you need is not a sales position.

You can, and you should. A technical conversation with the people who would do the work, before there is a contract. Ask them how they would choose the case notion for your process, and what they would refuse to promise.

Yes. That is the designed end state: your people do the work with ours beside them, every decision is documented when it is made, and our reviews get lighter until they stop. We say when you no longer need us, rather than waiting for you to ask.

Often the smaller one is enough for the first question. Insights returns a fast, defensible read from SAP's own indicators; Intelligence is for questions that cross systems, need conformance against your own model, or hunt a root cause. We would rather do the smaller piece of work first.

Yes — under NDA. We do not publish client names, because process mining measures how an organisation really operates, and clients who allow that are entitled to discretion. Contact us and we will share relevant references, and you can put your questions to the consultants directly.

Yes — we keep our own risk register and we will walk you through it. Nine failure modes, clustered in three places: the event log is never built, or it is built around the wrong case notion; the analysis is presented before the log is reconciled; and models are published without conventions, without a dictionary and without a named approver. That is why extraction becomes a week-one workstream, why logs are reconciled before anyone presents, and why no widget ships without a named decision.

Yes, and as early as we can see it. An engagement that concludes the problem is upstream has produced the correct answer cheaply, and we would rather deliver that than a dashboard nobody uses. Be suspicious of a supplier whose analysis always finds work for that supplier.

Yes — and we are not competing with them. The split is agreed in writing in week one, not negotiated in month four: we own the process architecture, the conventions and the model estate, the event log and the queries built on it, the target design and the fit-to-standard gap list with its evidence. On a process engagement, your integrator owns configuration, development, test execution, cutover and hypercare — and challenges our gap list, rightly. If your integrator already has strong Signavio capability, we will tell you. The split is not territorial: the party who verifies the build should be independent of the party who built it, so on any one programme we take one side of that line.

Yes — and ask your SAP account team to show you Joule with SAP Signavio early, because it is a real change to how quickly an answer comes out of a process tool. Three things it does not change. An answer is only as good as the event log underneath it: asking a question in natural language does not make an unreconciled log true, and if the case notion is wrong you now get the wrong answer faster and in a full sentence. It does not decide which question is worth asking — ours is always which decision the analysis will change, and who makes it. And it does not own the change afterwards: named owners, an approval workflow that is actually used, and conformance checks that keep running. That is what a consultant is for once the tool can answer questions on its own — the log beneath the answer, the choice of question, and the ownership of the change.

Yes, in the first week, each with a named owner and a date against it. Extraction is an organisational question far more often than a technical one: who authorises the connection to the source system, what your data protection assessment requires once an event log contains user IDs, and whether your works council agreement covers analysis of data that can be traced to an individual employee. Those three answers set the schedule more often than anything technical does. Pseudonymising user identifiers is usually acceptable and usually sufficient, but it is not automatic — somebody on your side has to agree it, and agreement takes calendar time rather than effort, which is why it belongs in week one while nothing is waiting on it. We do not give legal or data protection advice. What we do is raise the questions early enough, and with the right people, for the answers to arrive before they hold anything up.

Yes — here is exactly what we need from your side. To start: the decision you are trying to make, the process area it concerns, and an honest description of what already exists, which needs no preparing. If the honest answer is that the models are old and nobody opens them, that is the answer we want. Then four people. Somebody who can authorise the connection to the source system — not approve it in principle, authorise it. Your workspace administrator, to issue our accounts and to revoke them. A process owner who knows how the work is really done and is willing to argue with the event log when we show it to them, because a log nobody who knows the process has challenged is not evidence yet. And your own analysts and modellers from the build stage onward, in the delivery team with ours beside them — slower for a few weeks, considerably faster after, and the reason you can run this without us later.

Yes. The scoped assessment is the usual first engagement and it is deliberately small: one process area, one question you cannot answer today, and a written answer with the evidence attached. There is no minimum size to it. We start with the decision rather than the tool, put the permissions on the table in the same week with a named owner and a date on each, agree the case notion in writing before anything is built, and then take an honest look at your data to find out whether the question you asked can be answered from the systems you have. You get back the case notion and process boundaries in writing — including the questions the log cannot answer — a data feasibility assessment, a stakeholder and ownership map, a list of anything we think is not worth doing, and, when it applies, a recommendation to stop there. No SAP Signavio licence yet is not a blocker: we can begin with an assessment that does not require one, so you find out whether the tool fits your problem before you subscribe rather than after.

Yes. We start with the decision you are trying to make, not with the tool: which processes, why those ones, and what the programme around them is — an S/4HANA move, an audit finding, a carve-out, a cost target. Then what data can realistically be extracted, from which systems, and with whose permission. That last question is the one that moves your start date, so it becomes a workstream straight away rather than an assumption, and each permission gets a named owner and a date. If you already have a systems integrator, the boundary between their work and ours is written down in the same week rather than negotiated in month four. Nothing gets built until the case notion is agreed in writing with the process boundaries around it. At the end of that first stage the scope, the case notion and the data feasibility are in writing — and if the honest answer is that your data cannot support the question you asked, you have that in writing too, before anyone has built a pipeline.

Yes. A case notion is the thing your analysis counts one of: a purchase order item, an invoice, a delivery, a service ticket. Choose it, and the event log can answer questions about that thing — how long it takes, where it goes back a step, how often it takes the path nobody designed. Choose it badly, and every number the analysis produces is a precise answer to a question nobody asked. It is the decision that determines whether the whole investigation is useful, which is why we agree it in writing before anything is built. It is also the first thing to ask any supplier who wants to mine your process: how would you choose the case notion for our process, and what would that log not be able to tell us?

Yes, if one of these is recognisable. You already own SAP Signavio and a handful of enthusiasts are keeping the licences alive, and you need to know whether to invest, reduce or stop — from somebody who does not sell the licences. You are about to freeze a target design for S/4HANA and nobody can prove how the business actually runs today. You own a model estate and a mandate to keep it credible, and nothing has told you whether the models are still true. You have an operational problem that has survived being told to try harder: payment blocks, rework in order-to-cash, buying that goes around the process, a closing cycle that will not shorten. Or you need process documentation with an owner, a version and an approval date on it, because someone is going to ask for it. And if nobody can yet name the decision this analysis would change, or who makes it, start there and start with a conversation instead — we would rather tell you that than build the dashboard.

Yes to both. We work inside your SAP Signavio workspace, under your licence, on accounts your own workspace administrator issues and revokes — switching our access off is something your administrator does, not a request you have to make to us. The models, the pipelines, the investigations, the SIGNAL queries and the governance workflows are built in your workspace and they are yours, and so is the transformation SQL, documented. So are the conventions, the reasoning behind the case notion, and why each query asks what it asks, written down when the decision was made rather than reconstructed at the end. That is the difference between a handover and a dependency: a future analyst of yours can change what we built instead of rebuilding it. At the end you get a governance model actually in operation with the roles filled, a team of yours that can operate it, and a written handover whether or not you asked for one.

Yes — the work changes shape rather than disappearing. Before the design is frozen it gives you a baseline of how your processes run now, built from measured behaviour rather than opinion, so the business case is evidence instead of benchmark slides; set against SAP reference process content, what you will meet as SAP Signavio Process Explorer and Process Navigator, the gap list becomes a fact rather than a workshop outcome. During the build the target process is modelled in SAP Signavio and used as the shared reference across the SAP Activate phases, so test scope and training material come from the process instead of being written a second time, and every place your design departs from SAP best practice becomes visible as what it is: a candidate extension you will pay for when it is built, and again at every upgrade. After go-live, conformance monitoring finds process drift while it is still a habit rather than a culture. And if the build is already under way, the useful first question is not what your processes looked like a year ago — it is which of the deviations already in the design you are going to pay for at every upgrade, and whether anybody has written them down.