Organisational mining

What is organisational mining?

Organisational mining uses event data to see how people, teams and systems actually work together in a process. It shows the real division of work, the handovers between people, the roles that carry out each step and the patterns of collaboration behind them.

For that, the event log needs one more field beyond case, activity and timestamp: a resource, meaning the person, job role, group or application that performed the event. From the order in which resources appear across a case, you can work out how they relate.

It is not a replacement for the org chart. The chart says who reports to whom. Organisational mining shows how work really flows through one specific process, which is often a different picture.

Questions it can answer

Resource analysis shows which roles perform which activities, how work is spread across teams, and where queues build up. A role can be inferred from similar activity behaviour even when job titles differ.

Handover analysis looks at who passes work to whom inside the same case. A network of these handovers can reveal two teams that keep bouncing work back and forth, or a single specialist who quietly handles almost every exception.

Other analyses look at collaboration, subcontracting, how evenly tasks are shared, or how similar two resources are in what they do. The measure you pick has to match the question, because a link between two resources does not mean the same thing in every analysis.

From events to a social network

Picture the resources as the dots in a network. A directed link from A to B can mean B carried out the next activity in the same case that A had just worked on. The weight of the link can count how often that handover happened.

Network measures such as centrality and density help summarise the pattern. High centrality might point to expertise, to a coordinator, to a formal approval gate, or to a bottleneck. The number alone does not tell you which reading is right, so filter by process, period, case type and activity before you conclude anything. Without that, large teams and routine cases dominate the picture.

Example: a service desk

A service desk logs each ticket through receipt, classification, diagnosis, escalation and resolution, along with the handling team and, where allowed, a pseudonymised agent ID.

The process map looks tidy, but the handover analysis shows network problems bouncing repeatedly between first line, infrastructure and vendor management. Tickets with more than four team switches take noticeably longer to resolve.

That does not prove any team is underperforming. Complex tickets may cause both the extra handovers and the longer throughput time. Reading a sample of cases might show the real culprit is a vague routing rule or missing diagnostic information at intake.

How it differs from task mining

Organisational mining uses process events from business systems and usually looks across many cases and resources. It is about who does which process step and how work is passed along.

Task mining instead records actions at the desktop, such as clicks and keystrokes inside applications, and focuses on how one task is carried out and whether it could be automated. The two can be combined, but they sit at very different levels of detail and carry different privacy risks. A screen recording says far more about one individual than a team-level event ever does.

Data quality and resource identity

Shared accounts, system users and automated batch jobs distort a human collaboration network, so separate people from roles, teams and applications. Resource fields also change on reassignment without anyone writing an event, which quietly loses a handover. Time zones, duplicate events and wrong case correlation all skew the result too.

Link identities only when it is necessary and lawful. A stable pseudonym can keep patterns visible over time without putting real names in the analysis table.

What to watch out for with organisational mining

This kind of analysis can feel like staff monitoring, so set a process goal first, keep the data to a minimum, and involve privacy, HR and employee representatives as the context requires.

Work at team or role level by default. Individual analysis needs a clear reason, a proper legal basis, restricted access and an explanation of how the results are used and how long they are kept. Do not build a league table from event counts or throughput time: cases differ in complexity, invisible work is often missing from the log, and the numbers make an unfair ranking. Use the findings to talk about process design, staffing and collaboration, not as an automatic performance review.