Event Abstraction for Enterprise Collaboration Systems to Support Social Process Mining

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "Event Abstraction for Enterprise Collaboration Systems to Support Social Process Mining".

Jane: The paper was written by Jonas Blatt, Patrick Delfmann and Petra Schubert from University of Koblenz.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title: Tom: Welcome back to the show, everyone. Today we’re digging into a paper that’s got a real mouthful of a title: “Event Abstraction for Enterprise Collaboration Systems to Support Social Process Mining.” Jane, I’m going to need your help unpacking that one, because it’s dense.

Jane: Happy to, Tom. So the title is really three parts. First, “Event Abstraction” — that’s about taking super detailed, messy records of what people do on a computer and turning them into bigger, meaningful actions. Think of it like turning every single keystroke into “wrote an email” instead of “pressed the letter E.”

Tom: Right, and the second part, “Enterprise Collaboration Systems” — those are tools like HCL Connections, which is the one they actually studied. These are platforms where teams share files, write wiki pages, post blogs, comment on stuff. Basically the digital office.

Jane: Exactly. And the third part, “Social Process Mining” — that’s the exciting bit. Process mining usually looks at structured business software like ERP systems to find how work flows. But here, they want to do that for collaborative, social software. The goal is to see patterns in how people actually work together, not just how they process orders.

Tom: And that’s where the problem starts. These collaboration systems log everything at a super fine level. One user action, like uploading a file, can trigger three or four log entries. And those entries might not even happen in the same order every time. So if you run standard process mining on that, you get what they call a “spaghetti model” — just a tangled mess of lines.

Jane: Yeah, I’ve seen those. They look like a plate of spaghetti thrown at a wall. Completely unreadable.

Tom: So this paper’s whole point is to fix that. They built a method called ECSEA — that’s short for Enterprise Collaboration System Event Abstraction — which learns how to group those tiny log entries into meaningful high-level activities. And once you have that cleaner log, you can actually do social process mining and see real collaboration patterns.

Jane: And the cool part is they don’t need a domain expert to sit there and manually define what each log entry means. They train the model by observing real user clicks and comparing them to the system logs. So it’s data-driven, not guesswork.

Tom: That’s the part I love. It’s like teaching a translator by showing them a conversation in two languages side by side, instead of handing them a dictionary.

Jane: And they claim it works — they got up to ninety-six percent accuracy on real data from a university collaboration system. That’s pretty impressive.

Tom: It is. But I’m curious about how they actually pulled that off. That’s what we’re going to get into next — the guts of the method.

Paper discussion segment 2: Jane: So we’ve set the stage. The paper is “Event Abstraction for Enterprise Collaboration Systems to Support Social Process Mining,” and the problem is that collaboration system logs are too messy for process mining. Now let’s talk about how they actually solved it.

Tom: Right. So the authors — Jonas Blatt, Patrick Delfmann, and Petra Schubert from the University of Koblenz — they took a supervised machine learning approach. And here’s the clever bit: they didn’t try to guess what the high-level activities should be. They actually observed real users clicking around in the system and recorded those clicks as the “high-level” truth.

Jane: So they built an observer tool that tracks what buttons people press. That gives them a clean log of actual user intentions — like “I created a wiki page” or “I uploaded a file.” Meanwhile, the system itself is logging every tiny event in the background.

Tom: And then they compare the two. They take the fine-grained system logs and the observed high-level logs, and they train a model that learns which sequences of low-level events correspond to which high-level activities.

Jane: And the tricky part is that it’s not a simple one-to-one mapping. They list five challenges in the paper. One, a single high-level action can produce multiple low-level events. Two, two different high-level actions can overlap in time. Three, the order of low-level events can vary. Four, the same low-level event can be part of different high-level activities. And five, some low-level events are just noise — they call them “ghost activities.”

Tom: Ghost activities — I love that name. Like when the system logs that someone visited a community page, but that doesn’t really tell you anything about what they were trying to do.

Jane: Exactly. So their algorithm has to handle all five of those at once. And that’s what makes it different from previous work. They actually reviewed twenty-five existing event abstraction approaches and found that none of them could handle all five challenges simultaneously.

Tom: And that’s the gap they’re filling. Their method, ECSEA, uses two maps. One map goes from low-level activities to possible high-level activities. The other map goes from high-level activities to the sequences of low-level events that were observed for them, along with a count of how often each sequence appeared.

Jane: So it’s like building a phrasebook. You see that “wiki.page.created” followed by “wiki.page.follow” usually means someone created a wiki page. And you also learn that “wiki.page.updated” can be part of two different high-level activities depending on context.

Tom: And then when they apply the model to a new low-level log, they use a greedy sliding window approach. They look at the first few events, check which high-level activity they most likely belong to, and then merge them into one event.

Jane: And they use a threshold to decide whether a mapping is good enough, and they calculate an error score based on how different the observed sequence is from the learned ones. That’s how they handle the varying order problem.

Tom: It’s a pretty elegant design. But the real question is — does it actually work? And that’s what we’re going to talk about next, because they ran some pretty thorough evaluations.

Paper discussion segment 3: Tom: So we’ve covered the method. Now let’s get into the results, because that’s where the rubber meets the road. The paper is “Event Abstraction for Enterprise Collaboration Systems to Support Social Process Mining,” and the authors ran two evaluations.

Jane: Right. First, they did a synthetic test. They took a real event log from the BPI Challenge two thousand twenty — that’s a well-known dataset in the process mining community — and they treated it as if it were a high-level log. Then they artificially generated low-level logs from it, with different numbers of low-level activities per high-level activity.

Tom: And they made those synthetic logs match the messy characteristics we talked about — multiple events per activity, overlapping events, varying order, and so on. They generated seventy different low-level logs and trained models on each one.

Jane: And the results were really strong. The accuracy was always above ninety-eight percent, even when they had eight low-level activities for every high-level activity. And they only used about ten percent of the traces for training.

Tom: That’s a big deal. It means you don’t need to observe the system forever. You can observe a small sample, train the model, and then apply it to years of historical data.

Jane: Then they did a real-world test. They used a system called UniConnect — that’s an actual enterprise collaboration system at their university with over three thousand users. They observed it for three months, recorded the high-level clicks, and extracted the corresponding low-level logs.

Tom: And they got ninety-six percent accuracy on that real data. That’s not just a lab experiment — that’s a working system.

Meng: Hey, can I jump in here? I’m wondering about the practical side. If I’m an IT team at a company, what does it take to actually deploy this? Do I need to install that observer tool?

Jane: Great question, Meng. So the observer is a browser-based tool that records clicks. And the key insight is that you only need to run it once per system type. Once you’ve trained the model on one instance of, say, HCL Connections, you can apply it to other instances of the same system — as long as they haven’t been heavily customized.

Meng: So it’s a one-time setup cost. That’s actually pretty reasonable. But what about the accuracy drop from ninety-eight percent to ninety-six percent — is that just noise, or is there something about real data that’s harder?

Tom: That’s a good observation. Real data has more variability. Users don’t follow clean paths. They interrupt themselves, they switch tasks, they do things in weird orders. The synthetic data was generated to be messy, but real users are messier.

Jane: And they also mention that the model can be reused for other instances of the same system type. They actually tested it on another instance called KoCo and it worked. So the investment pays off across multiple deployments.

Meng: That’s the kind of thing that makes this actually viable in a company. You don’t want to redo the whole observation process for every department.

Tom: Exactly. And the authors see this as a preprocessing step for something bigger — social process mining. Once you have clean high-level logs, you can start looking for collaboration patterns, like how teams work on documents together or how knowledge flows through an organization.

Jane: And that’s where the real value is. It’s not just about making pretty process maps. It’s about understanding how people actually collaborate.

Conclusion: Tom: Alright, let’s wrap this up. We’ve been talking about “Event Abstraction for Enterprise Collaboration Systems to Support Social Process Mining” — and honestly, this is one of those papers that solves a real bottleneck.

Jane: Yeah. The problem was that collaboration systems generate logs that are too fine-grained for process mining. You’d get spaghetti models that nobody could read. And the existing event abstraction approaches couldn’t handle all the messiness — overlapping events, varying order, ghost activities, all that.

Tom: And what these authors did was build a method that learns from observed user behavior. They watch people click, they compare that to the system logs, and they train a model that can automatically convert messy low-level logs into clean high-level ones.

Jane: And the results are solid — over ninety-eight percent accuracy on synthetic data and ninety-six percent on real data from a university system. Plus, the model is reusable across instances of the same software.

Meng: And from a practical standpoint, that one-time observation cost makes it feasible for real companies. You don’t need to run the observer forever.

Lu: And I think the bigger picture here is that this opens the door to actually studying collaboration as a process. We’ve been able to study how orders flow through an ERP system for decades. Now we can study how knowledge flows through a team, how ideas get developed on a wiki, how a community forms around a document. That’s a whole new frontier.

Lalam: And if I may add — this could change how organizations understand their own culture. When you can see patterns in collaboration, you can identify which teams are siloed, which workflows are actually working, and where knowledge gets stuck. That’s not just a technical improvement; it’s a way to make organizations more humane and effective.

Tom: Beautifully said. So that’s it for this paper. We’ve covered the problem, the method, the results, and the implications. Next up, we’ve got another paper that’s going to push into a completely different corner of process mining. Stay tuned.

Jane: Thanks for listening, everyone. We’ll see you on the next one.