What Is a Taxonomy?
Quite simply, a taxonomy is the science of naming and classifying things. Taxonomies organize things into groups, often going from the very general to the quite specific. Each section of the taxonomy is part of the whole and taxonomies, by their very nature, include the principles and rules that underlay the classification of whatever objects the taxonomy is being used to classify.
Perhaps the two most easily-understandable examples of taxonomies would be the Dewey Decimal System — still in use in over 200,000 libraries — and the taxonomic ranking system (kingdom, phylum, class, order, family, genus, species) that most of us learned in science class.
Why Do I Want to Build a Taxonomy for My Company?
Anyone can manage ten service options for his or her customers. But what about 50? 100? What if IT wants to create and publish its own services? Adding in HR, Contract Services or other departments can make things even messier, especially if each department wants to name their portal and what they want and design it in a way that is most familiar to their customers.
Essentially, the main reason to build a taxonomy of services for your company is because a taxonomy of services is one of the best ways to give customers an easy-to-use, hassle-free experience when they’re attempting to use the services that your company provides.
The Difference Between Services and Requests
Many of the companies that we work with have request catalogs, not service catalogs, and there's a very significant difference between the two. Requests are related to services, but a request is not a service. Rather, a service is a durable, ongoing set of commitments that company promises to fulfill for its customers. Requests are transactions that take place within services and putting one before the other is like putting the cart before the horse.
For example, let’s say you went to Amazon and, instead of being presented with the Amazon home page, you reviewed the purchase request process (payment, billing and shipping) and then went looking for something to buy – it’s entirely backward from how the process is supposed to go.
So, to clear up:
- A request from a user is for something to be provided. That request is transactional – once it’s completed, it’s done. Because of this, requests only usually carry completion goals (ex. “This will ship in two days”). Asking for access to a service is an example of a request.
- In contrast to a request, a service is durable over time – that is, it’s ongoing. As such, it has defined goals, such as customer support, restoration of service, etc. Providing Oracle for Windows as a service is a service.
All requests, at their most basic, are hanging off of services — they’re simply some form of Add, Change or Remove. Switching to a service-centric catalog means that you have a smaller number of things to manage and you can present a much more intuitive user experience for your customers.
How Do I Design the Taxonomy That Is Right for My Business?
The best type of taxonomy for you is the one that is most useful in creating and managing the services that you want to offer.
At its most broad, there is the broad-service taxonomy. This is the easiest type to use right away, and by using it, you'll minimize any reorganization efforts that could come from changing it. A basic broad-service taxonomy can include line-of-business services, which face the customer; shared services, which face the employees; and department services, such as IT.
A department service such as IT can be further broken down into its own internal and customer-facing parts, with the customer-facing parts including services such as a service desk or training.
One of the best practices for a service catalog taxonomy is to remember that service labels are for the customers and the service framework is for the providers. Every section of the taxonomy is geared toward a particular customer set: since we want to think like the customer, then the labels in any customer-facing sections should be in the customer's language, not the provider’s.
When we say that the framework is for the providers, we mean that the framework is one of the best ways to understand the breadth and depth of the services the provider is offering, rather than an alphabetical or numerical list.
To better understand this, let’s break it down with an example in Higher Ed:
- At the top, IT provides an infrastructure or internal IT service in the category of Business Continuity.
- This service or infrastructure supports an application, like SAP.
- The customer for this service is the IT employee who owns SAP.
- That employee then provides the service of the SAP application to his own customer – in this case, the finance department at a local college.
- The college finance department then provides its own services (such as “Collect Amounts Owed” or “Pay Your Tuition Online”) to its own customers, the college students.
The guiding principle and another best practice for a service catalog is that the taxonomy functions as a framework — it ends where services begin. Requests are then transactions placed against the service. One good thing to remember when designing a taxonomy is that they are customer-centric: how is the customer going to see it?
As a general rule of thumb, if an area of the taxonomy exceeds seven plus/minus 2 items, it should be refined down to another level because the number of choices has become too large to be easily understood. When it comes time to name these levels, use whatever conventions are relevant or make sense in your business — as long as everyone can understand and can use the same naming conventions.
An example of a basic service taxonomy could go something like this:
- Service family
Inside the service family would be the list of services that would be offered to the customer. Services can be further broken down into service offerings – for example, silver or gold package options. Requests are last on the list and are made against the service offering – as we said earlier, they're usually some form of Add, Change or Remove.
Now that we have some understanding of how taxonomies are built, we're going to shift gears and cover some service catalog best practices.
Best Practices for a Service Catalog Taxonomy
The first best practice is to start with a common understanding. Building a shared understanding of key terms and principles with your team is essential for success. At its highest level, the framework of your taxonomy should capture its broadest view.
Once that broad view is complete, it's completely fine to have multiple different categories inside this broad taxonomy that can cater to various departments. So the HR group would then have its own sub-category with services and service families that would logically be seen as HR services.
Building your taxonomy should always be a group activity. Use of visual tools is also highly recommended — they enable the group to discuss, re-label and rearrange parts of the taxonomy as needed.
Visualizing the taxonomy can also help you see where a service that’s located in one area might be valuable in another, can help prevent duplication of services and enables you to see where combining already-existing services may be more valuable or expedient than creating a new one wholesale.
Seeing how services and requests “hang” off the taxonomy gives a much-needed relevance to the taxonomy and can help solve issues when it comes to depth, breadth and labeling.
When building your taxonomy, you may be faced with a series of questions. Are a lot of simple services, or large complex services the right choice? There are upsides and downsides to each: too many services can be confusing to the customer, while too big of a service can be complicated for IT to manage.
When deciding the number of services to offer, consider Miller's Number. Miller's Number says that Humans can only handle five things error-free – by nine, error-free operation is very unlikely. The sweet spot when it comes to deciding the number of services you want to provide should be seven plus or minus two.
Our experience in the transition from service taxonomy to service has led us to develop our own version of Miller's number. We believe that the number of levels of taxonomy down to service should be in the four plus or minus two range, meaning it could be as little as two or as many as six.
We've also found that once you reach the specific service level, you can reach a little higher in the number of options that you provide because you have found the specific level where the customer expects to find their answer. Regarding options provided to the customer, you can go as high as nine plus or minus two, as long as the relevance of all the options provided to the customer is very high.
The second best practice one can use when designing their service taxonomy is to use configuration management to preserve services sanity. What this means is to use a building-block mentality when it comes to constructing services. You can then combine the blocks to create new services and variations of existing services.
If all of your services are single-thread, custom-built affairs, they will be impossible to maintain and quickly become very confusing for the customer. Think again about our Amazon example from earlier: what if each department had its own check out procedure?
However, this idea has its challenges, too — any single service "building block" could end up being used in hundreds of other services. One way to solve this is to manage each service as a Configuration Item (CI) and then map it into any combined services of which it is a part.
As the provider, it can be hard to think like the customer when it comes to designing services — it’s human nature to frame things in our own language. So when it comes to designing a taxonomy, a service or a service portal — anything that serves the customer — remember to design it in their language.
There are two things you want to you want to do/consider when designing a taxonomy for your customers:
- Design the taxonomy in the customer’s language.
- Figure out who owns what sections of the taxonomy – the “owners” in this case being the customers for that section, not the providers.
There’s a basic three-phase approach to success when it comes to organizing and managing customers:
- First, focus on customer interaction. Build a beautiful, basic customer service portal — this will become the heart of your interaction with your customers. At this stage, once the customer service portal is complete, build the first version of the rest of your taxonomy.
- Focus on bringing the departments themselves, such as IT, into the customer portal. Ask yourself what the services you would provide are — the answer being services that knowledgeable workers in those departments would consume. Consider a shared services pilot customer. Establish further customer service portal functionality and extend the taxonomy to cover the new additions.
- Bring shared services on as a full-fledged customer. Consider the possibility of bringing on line of business services as a pilot customer. Extend the service taxonomy and customer service portal to include the new shared services options.
Possible Next Steps
Now that you’re familiar with the basics of what an IT taxonomy is and how to design one, here are some possible next steps:
- Download one of our many related on-demand webinars including What Is A Service Taxonomy (and Why Do I Need One)?
- Demo our Self-Service Portal and Catalog yourself.
- See how our graphical Service Taxonomy Designer works.
- We also offer copies of our service definition dictionary and our service taxonomy guide. If you’re interested in either one, just get in touch with us via email.
Feel free to check out the Evergreen Systems website for a more in-depth view of the services we provide.