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