Naming Activities

The activity name is a modelling choice disguised as a data field. It decides what the discovered process looks like.

The granularity trade

Fine naming — every status code as its own activity — produces a map with hundreds of nodes and thousands of variants. Technically accurate, operationally unreadable.

Coarse naming — grouping codes into business steps — produces a readable map that hides real distinctions.

Neither is correct. The right level is the one at which the operation makes decisions.

Start coarse, refine where a finding demands it. The reverse produces a first presentation nobody can follow.

Making names readable

Use the words the operation uses, not database codes.

Verb plus object: "approve invoice", not "STATUS_04".

Consistent tense and form across the whole log, or the same step appears twice.

Build a mapping table from raw code to activity name, versioned, held outside the tool.

The abstraction decisions

Collapse repeated identical events? A status set three times in a second is one action.

Merge synonyms? Two systems calling the same step different things.

Split by attribute? "Approve" performed by a manager and by an automated rule are arguably different activities, and treating them as one hides the automation rate.

Drop technical events? Interface confirmations and system housekeeping usually add nodes and no meaning.

Each decision changes the variant count, which is why variant count is not a finding.

Why variant counts mislead

They are a function of your naming, not of the process.

Refining one activity into three can multiply variants by an order of magnitude with no change in reality.

So "we found 412 variants" says more about the log design than about the operation.

Report what the variants cost — cycle time, rework, cases affected — rather than how many exist.

Validating the naming

Show the activity list to the operation before showing them a map.

Ask whether anything is missing, which reveals steps the systems do not record.

Ask whether any two names mean the same thing.

Ask which distinctions matter, which tells you where to refine and where to collapse.

Maintaining it

New status codes appear as systems change, and unmapped codes silently become a new activity or get dropped.

Alert on unmapped codes in each refresh.

Version the mapping, so a change in the map can be attributed to a naming change rather than to the process.

Report the mapping version with every analysis, because a comparison across versions is not a comparison.

The mapping table

The artefact that determines what the map looks like, and it belongs outside any tool.

Columns: raw code, activity name, group, include or exclude, notes.

Versioned, so a change in a figure can be attributed to a naming change.

Reviewed with the operation before the first presentation.

Alerted on: any raw code appearing that is not in the table.

Exported with the log, because rebuilding it after a vendor change is the most laborious part of a migration.

Deciding the granularity from the question

There is no correct level, only a level matched to what is being asked.

For cycle time and waiting: coarse. Business steps, a dozen or so activities, a readable map.

For compliance: whatever the rule references. If the rule is about an approval code, that code must be its own activity.

For automation scoping: fine, because the specification needs the detail.

Build one mapping per question rather than one universal mapping, and say which was used.

Building the vocabulary

An hour of work that determines whether the discovered model is readable.

List every distinct source event type in the extraction.

Group them into activities at the level your question needs.

Give each a short verb phrase in consistent tense, chosen with the people who run the process.

Record the mapping from source event to activity, versioned.

Check the result: if the discovered model has more than a few dozen activities it is too granular; if the interesting behaviour has disappeared it is too coarse.

Expect to revise once after seeing the first model, and then to leave it alone.