Track and Trace User Activity

There are many strategies how to govern this.

First of all, of course, is to prevent the such an event - is the access to the content through the folders. 

But yeah, some 'talents' are always ready to make you suffer )  We produce a couple of reports to estimate the DB health (it depends on how many monkeys with grenades are within the project/DB). First of all - we use Export with all GUIDs of the objects (in Excel), and then, e.g., when shit happens, we import (with another script) the old Excel file that shows what object changed, what was deleted, and what is new. 

Another strategy is to evaluate the 'mass' of objects on the diagrams. The principal is very similar—one script exports to Excel, another import, and both give you an understanding of what happened with your processes. 

Hello Peter,

as a precaution we have two roles with different access permissions: 

• modelers who cannot delete models/object definitions
• process architects who can

Another idea: Do you use db versioning? Then you could compare older versions against the workplace or HEAD revision.

There is no simple, built-in "whodunnit" traceability in ARIS. Maybe my earlier post can help. But for logging such detailed user activities you should bear in mind GDPR, users' consent and worker's council participation.

Regards, Martin

Thanks for your comments. Much appreciated. I am afraid I will have to invest more time into access rights on group level. 

Hello Peter,

yes, that definitely is a good investment to protect your (mental) sanity. When you have your grips around your repository with designer roles, reader roles, stakeholder roles and proper access permissions for them you are a great step further. Versioning for publishing content is also a standard pattern.

If the need to trace individuals' activities persists after that, there are add-on components large banks use for auditing purposes - including traces of who accesses what. That would definitely be an issue to justify against GDPR (and a lot of logs to scan!).