Can you do process mining without event logs?
Not process mining as the term is defined, because the method is the reconstruction of a process from event logs. You can still get the thing you wanted the logs for, which is an accurate picture of how the work actually runs, from evidence most organisations already hold.
Written for transformation and operations leaders who have been told they need event logs first. Reviewed .
What an event log actually has to contain
The question is worth answering precisely, because the honest answer depends on what the term means rather than on anyone's opinion of the tools.
Process mining reconstructs a process from a table of recorded events. For that table to work, each row needs three things at minimum: a case identifier saying which instance of the process this event belongs to, an activity name saying what happened, and a timestamp saying when. Given those three columns across enough rows, the sequence of each case can be rebuilt and the variants counted.
Everything else the discipline offers rests on that table. Without a reliable case identifier there is nothing to group events into a process instance, and the result is a list of things that happened rather than a picture of how work flows.
Why many real processes cannot produce one
The three columns sound modest until you go looking for them in a process that spans several systems and a few people.
- The case identifier does not survive the boundary. A request gets one reference in the intake system, another in the finance system, and a third in the ticket someone raised to chase it. Joining them is a project in itself, and where the join is a person's memory it cannot be done at all.
- The steps that matter leave no event. Work done in a spreadsheet, an email thread, a chat message, or a conversation writes nothing anywhere. That is not an edge case: it is often where the delay and the risk live, because unrecorded steps are also unmanaged steps.
- Timestamps record the wrong moment. Batch jobs stamp everything at the time of the batch. Systems that log on save rather than on action compress an afternoon of work into one second. The resulting durations look precise and are wrong.
- The actor is a service account. Steps performed by an integration on behalf of several teams collapse into a single anonymous participant, which removes exactly the distinction you were trying to see.
What organisations usually try first
The standard response is to build the log rather than abandon the method: instrument the systems, extract and transform what they already write, and construct a case identifier by joining on whatever the systems share.
That work is legitimate and sometimes the right call. It is also where a large share of the effort in these programmes goes, and it happens before anyone sees a diagram. It is worth asking what the first useful output is and when it arrives, because the answer decides whether the approach is viable in your situation or merely correct in principle.
The uncomfortable version of the question: if the extraction and joining were to take longer than the decision you are trying to make, would you still choose this route? For a process that runs cleanly inside one well-instrumented system, the answer is usually yes. For a process held together by documents and people, it usually is not.
The evidence that is already there
Most processes are documented somewhere, just not in a place anyone would call documentation.
- Procedures, runbooks, work instructions and training material. Written to tell someone how to do the job, which is exactly the question. Usually out of date in parts, which is information too: the parts that drift are the parts under pressure.
- Wiki and intranet pages. Often the only record of why a step exists, which is what you need to decide whether it should continue to.
- Meeting transcripts. Increasingly captured by default, and full of the exceptions and workarounds that never reach a procedure because nobody would write them down.
- Policies, contracts and standards. These tie a step to the requirement it serves, so the step can be questioned rather than merely recorded.
- One recorded run of the job. Watching the work performed once, with the consent of the person doing it, resolves in an hour the disagreements that documents leave open.
What you give up, honestly
This is not a free substitution, and anyone who tells you it is has something to sell.
What you lose is statistical precision at volume. Event logs, where they are good, can tell you the distribution of cycle times across every case in a year, and no amount of reading and observing gets you that. If your question is genuinely about that distribution, and the logs exist and are sound, use them.
What you gain is coverage and speed. A picture built from documents and one observed run includes the steps no system saw, and it exists in days rather than after an extraction project. It is also easier to check, because the people who do the work can read it and tell you where it is wrong, which is not true of a variant diagram.
How to tell which situation you are in
Before choosing a method, ask three questions about the specific process, not about the organisation in general. The answers usually settle it in a single conversation.
- Does one system carry the case from start to finish? If two or more do, ask what identifier survives between them, and ask someone who has actually looked rather than someone who assumes.
- What fraction of the elapsed time happens inside a system at all? If most of the waiting is for a person, an approval, or a document, the logs will show you the fast part and hide the slow one.
- Could you answer the question by reading and watching instead? If a week of reading what exists and observing one run would settle it, that is cheaper than any extraction, and it can be done while the extraction question is still being debated.
Where Valstra fits
Omni is built on the second answer. It generates the model from documents, transcripts and wiki pages, and from a single consented recording of someone doing the job, rather than from system event logs. That is a deliberate constraint, not a gap being filled later: it is what makes the approach work for processes that never produce a usable log.
It is worth saying plainly that this makes Omni the wrong tool for the case where log-based mining shines. If your process is one clean system, your logs are sound, and your question is about cycle time across thousands of cases, a process mining platform will answer it better than we will.
Common questions
- Is this just process mining with a different name?
- No. Process mining has a specific meaning: reconstructing a process from event logs. Building a model from documents, transcripts and observed work is a different method with different inputs, different strengths and different limits. Calling it process mining would be a marketing decision rather than an accurate one.
- Can we start without logs and add them later?
- Yes, and that order often works better. A model built from what exists tells you which processes matter and which steps are worth measuring precisely, so any later instrumentation is aimed rather than exhaustive.
- How accurate can a model be if it comes from documents that are out of date?
- More accurate than the documents, because it is reconciled against a recorded run and against the people who do the work. The drift between what is written and what happens is not noise to be removed; it is usually the most useful finding in the exercise.
- What if our systems do produce good logs?
- Then use them. Where logs are reliable they measure at a scale no observation can reach. The two approaches also combine well: logs for the instrumented middle of a process, documents and observation for the ends where the work leaves the system.
See it against your own processes
A demo runs on your material, not a canned dataset. Bring a process you find hard to explain.