Taxonomy, the science or practice of classification, is all about specifying the relationships between entities and giving them agreed names.
I can’t count the number of times that clashing taxonomies have caused me difficulties: mis-interpreting what a friend is telling me, a boss not being on the same page, my direct reports looking at me like I’m from Mars. I remember a time when I was four years old, around the holidays, asking over and over again for ‘milk yolk’ while my mom tried desperately to figure out what I wanted. After 10 minutes of trying everything, she finally got it when I described what the drink looked and tasted like. I was after eggnog, of course.
As I explained in my last blog, when it comes to eGRC it’s critical to create common processes. A big part of this is providing consistent naming conventions so that everyone is talking the same language and there’s less chance of miscommunication. I gave the simple example of an ‘incident’ management process and an ‘issues’ management process that were identical except for what the stages in the process were called (largely just a difference in using ‘issue’ vs ‘incident’). But of course many taxonomy differences won’t be as obvious or straightforward as that example.
Naming conventions are important because they frame people’s understandings of what’s happening and what they need to do. They let people identify the context quickly and hand off information and activities without going through the palaver that my mom and I went through.
The issue of taxonomy often comes to the fore when you’re assigning labels to elements and workflow activities within software applications that are part of your eGRC strategy. People need to be comfortable with what things are called if they’re to use technology effectively; and it can take months to negotiate these naming conventions. Make sure you allow for this in your planning. Dealing with taxonomies effectively is a critical success factor for eGRC.
Good GRC taxonomy website:
Open Compliance & Ethics Group
When you’re trying to integrate and align governance, risk management and compliance, where do you start?
This has been one of the hottest topics that the RSA Archer eGRC Community has been discussing during the recent eGRC Roadshows that I have been extremely honored to be a part of this fall. The conclusion that organizations have all agreed on is that you need to identify the key processes across your business that relate to enterprise GRC activities, find the commonalities and intersections, and make changes as necessary to create consistency across them.
This is both easier and harder than you might think:
- It’s easier than you might think because the majority of GRC processes across the business will mostly be very similar to one another. People will use different names for things and think that they’re doing something very different from others, but in terms of underlying principles and steps, they mostly won’t be.
- It’s harder than you might think because people won’t want to change what they’re doing. Even if it’s just a name change, eg changing an ‘incident’ to be called an ‘issue’, people will fight hard not to change what they’re used to. Processes and their naming conventions can be really personal; they frame how people think about what they do. If you ignore this and try to be dictatorial about process change, you’ll be in for a hard time. To illustrate my point I present to you two examples of pretty much the exact same process for both ‘incident’ and ‘issues’ management. As you will note, the only thing different is what you call each stage of the process.
So when you’re setting out to break down GRC silos and create common processes, you need to allow plenty of time to negotiate process change. The role of a GRC advocate or leader is to orchestrate this negotiation, not impose change on people. If you want to be successful you need to help people to their own conclusions about why the change is necessary and not as bad as they think.
This applies even if you’re just changing the naming conventions (taxonomy) associated with processes (I’ll cover taxonomy in a bit more detail in my next blog). It applies even more so if you’re improving a bad or mediocre process, ie making actual process change. Process change is important if your processes don’t reflect best practice, otherwise the danger is that the improvements you make through eGRC will just make mediocre results happen more quickly.
So to reiterate, every eGRC project should:
1. Start with process.
2. Create consistent eGRC processes across the business.
3. Improve poor or mediocre processes.
4. Negotiation change in Taxonomy.