Brian Pentland is a Full Professor at the Department of Accounting and Information Systems of the Michigan State University, USA. We have the great pleasure to talk with him about process mining and organization studies, drifts and patterns, event logs and biases, and much more.

Tell us a bit about yourself, Brian. How did it all start?

When I started as a graduate student at MIT I was interested in technology transfer – how can tools and technologies like renewable energy move from one place to another? I came there with an engineering mindset. I thought the key ingredient was about how to design things. I quickly understood it was not about design, but about economics and social science. The main problem is how people use tools. Hence patterns of actions, norms, policies, organizational science – that all came into the picture. To my understanding, the organizational side was crucial, so I got interested in processes and routines. It was back in the early 90s. At that time, process theory was at its early stages and fairly simplistic: as opposed to variance theory, focusing on variables, process theory targeted sequences of actions and events. Since then lots of things have changed. In the process mining realm, researchers came from the computer science area. I got fascinated by process mining because of the basic idea of turning an event log into a graph-like process model. “Holy smokes, what a great idea!” I thought. It suited my interest very well: as an ethnographer, I was observing what people do. I could collect stories about sequences of actions, but often I could not see the whole process. I could only see fragments of a process. How to aggregate the fragments to get the big picture was not straightforward.

What are event networks and how did you come up with the idea of ThreadNet?

There were several motivations. We were holding a series of workshops on process and sequence analysis and the observation came up that we did not have standard methods that you can put in textbooks and teach to graduate students. The question was: “Can we make something easy to use, such that people who are mainly trained in qualitative research can appreciate it and start using it?” We wanted something that did not require any coding – no JSON or XML. There was a definite need for that because, in organizational research, process researchers are most often qualitative researchers.

Another motivation was, as far as ThreadNet is concerned, that I wanted to learn to code better. As a student, I learned Fortran. I was inspired by Andrew Abbott, a sociologist at the University of Chicago. He is a top researcher in process theory in sociology. Back in the early 1990s, he wrote a program in Basic for optimal string matching and sequence alignment. He said that if you can write a program to do the operation then you understand what is going on. And I wanted to understand what was going on. The very first version of ThreadNet was written by a master’s student from our MS analytics program. It’s just a directly-follows graph. So I re-wrote that code in Matlab and then everyone told me I should do it in R. If you look at the result, it reveals I had a 3rd-grade education, compared to you guys. It is basically just a directly follows graph, but I definitely understand how it works.

What is novel there is the idea of constructing actions based not only on activity labels but also on actors, location, system, and other contextual factors. As an outcome, you get a graph that is structured like a directly-follows graph but the nodes incorporate multiple features that are otherwise typically put in the background. At the BPM conference this year, I attended the talk of Eva Klijn, Felix Mannhardt and Dirk Fahland on task and routine detection with event graphs. They were approaching a similar problem with a different type of representation. To me, the challenge is finding patterns of action when they are contextualized. That is the key part, together with the opportunity to click, select and zoom in on fragments of the threads to know more about events in an intuitive manner.

A memorable passage of your talks about challenges and opportunities introducing ThreadNet is the balance between change and stability. Could you let us know more about this concept?

At first, the idea that typically comes to mind with process management is finding a path that can be repeated – always the same. But when you are performing work you are also creating patterns that you would then follow. It could be on a very small scale, such as where to click to activate a menu versus a keyboard shortcut. When we find a way that works, that becomes our pattern for that task. At the collective level, we can observe a similar phenomenon as the performances make the pattern. In other words, the performances are enacted, not designed. So it’s very different from programmers or designers creating a workflow with BPMN or whatever. In that case, the designers make the patterns. If users make the patterns, then they can be continuously updated. In our research with electronic health records, we found that things repeat pretty much the same from week to week. However, on a longer timescale, things change quite a lot. It could be due to external factors, such as economic or technological factors, but it can also be a consequence of simply performing work.

In BPM, I think they call this concept drift, right? I understand why it’s named like that but it still baffles me. It’s not the concept that’s drifting. It’s the PRACTICE that’s drifting.

I think the notion of drift comes from conformance checking, doesn't it? Of course, in accounting or security procedures there may be laws and rules and you don’t want any drift. For the rest, though, drift is part of the nature of the process itself. The idea is to use process mining tools and mindset to discover the patterns of action and see if they are changing and how they are changing. This is an empirical question. However, if they are changing, we should be able to explain why. That’s what I am working on at the moment.

Reality to machines is what they record. However, this limited perspective creates a bias, doesn’t it?

Definitely. Particularly event logs are designed by a team of programmers to be the ABSOLUTE MINIMUM to be stored not to clog the server. Back in the days when I used to write code, I wanted to log everything users were doing. I soon realised it was not a good idea. That would have taken too much space.

There’s a very famous paper from Harold Garfinkel entitled “Good organizational reasons for bad clinical records”. The title says it all. The information stored was serving one purpose, but it was not good for other purposes.

To be honest, we should acknowledge that an event log represents a narrow point of view. It’s like a shadow of what really happens. Imagine there is a flock of birds flying above you. If you stare at the ground you see only dark shapes moving around. You don’t see the flock of birds – just their shadows. That’s like an event log.

What you need is data from another point of view. For example, you can talk to people who work there. Or you can observe the work yourself. Mind that each of those sources is also limited too, though. The view is still fragmented but in a different way. With people, you tend to get fragments and a selective sample; with event logs, you can trace end-to-end, but you only have shadows.

I like the metaphor of two islands. People on the BPM island are happy with event logs and the knowledge they extract from them. People on the Process Organization Studies island are content with ethnography and observation of work. However, neither one has the full picture. There needs to be a bridge. For example, looking at the event logs, one could say that something odd is happening. But what is it? You have to go and look – you have to ask what’s going on!

Sounds like explainable AI, just the other way around. It’s not the machine explaining to humans its inner models, but humans explaining the sense of patterns inferred by machines.

Some time ago, I attended the presentation of a dissertation using neural networks to detect anomalies. There was no need for a process model. No Petri net. It was a statistical approach – it worked extremely well – but as you suggest, I don’t think it could explain why anomalies occurred.

So the question is: “Why do we see the patterns we see?” And we can approach this from a critical perspective. For example, Is profit or efficiency really the goal we should aim at in this situation? Or should it be equity and social justice? My colleagues at the University of Rochester are working on a project to use process mining to detect structural racism in health system records. What do I mean by that? Imagine there are two groups of people with the same diagnosis for a disease and the same severity. Also, they are covered by the same insurance. But they differ by ethnicity. Ideally, you would expect the same care paths – the same patterns of action – for both groups. Well, that is not necessarily the case. Process mining provides innovative ways of detecting and understanding structural racism in terms of divergent action patterns. This kind of bias would be difficult to observe using other methods. If you consider a patient at a time you wouldn’t recognize the phenomenon. We need to make the process visible: we need to aggregate multiple cases and analyse common patterns. I am not 100% sure it will work but I am 100% sure it’s going to be interesting: Process mining to discover racism.

In pursuing this question, we plan to start with the usual directly-follows graphs. However, we don’t particularly care about the whole process from end to end. More likely, the important differences will be in the fragments – parts of the process that differ between groups. These processual fragments cannot be taken from single cases but from aggregated data, which is a core feature of process mining indeed.

For that kind of comparison, it seems like the declarative approach of rule mining might be very useful. It can provide evidence of interdependence between events if something always happens before something else. It can show us if there are different constraints in different segments of the population.

To me, finding evidence of a constraint is a computational move. By computational move, I mean an operation you can basically conduct with a computer – let it be an aggregation, filtering, clustering. Mining technologies excel in computational moves such as finding what activity always precedes another activity. The interpretative move is about finding the meaning of this precedence. We often do both kinds of moves together. For example, we often decide that a specific subgroup is meaningful and focus on that for the analysis. So every time we aggregate or take averages, we are actually doing both computational and interpretative moves at once, aren’t we? Similarly, with declarative rule mining, the idea is that we get discovered rules out of data as a computational move but the understanding of those rules is an interpretative move. I think that organizational people may find much more declarative mining much more comfortable. Also, the vocabulary of discovered rules is pretty rich. This is part of my thinking these days: when computing something, are we truly aware of what that means at all?

The renownedly typical nightmare for process miners is accessing data. What’s your take on it?

It’s really tough. Especially with conflicting forces like privacy, deidentification, GDPR, which all require not to include identities of actors in the event logs! Yet my research agenda is about finding out the who, what, when, where and why. All those contextual features make data more identifiable, so I have a real problem.

For example, if you want to create social networks out of event logs, you need to have meaningful identities of people doing the work. That’s not always possible. With electronic health data, we typically have nothing about the patients. Luckily, we know pseudonyms for hospital actors and the workstation where they are located. That is apparently quite a big achievement on its own and it is tough to get. And probably only getting worse because of increasing concerns about privacy.

Thank you so much, Brian!

Thanks again for the opportunity to talk. This was really fun and interesting for me!