What is a Service Taxonomy and Why Do I Need One?

Editor's Notes

• #3: Hello all and thanks for joining us! I am Don Casson, CEO of Evergreen and with me is Jeff Benedict who heads up Evergreen’s ITSM practice, and leads our Innovation efforts.
• #4: If you are new to our webinar series, welcome. If you are a past attendee thanks for joining us again. Our goal is to share valuable information & insights you can use in your planning and activities right now. The topic we will explore today is, What is a service taxonomy & why do I need one? Here is our agenda- After a very little bit about Evergreen, we will dive into our topic. Beyond that we will briefly demonstrate our visual taxonomy, and our always evolving view of a very advanced, self-service catalog & portal experience, built on ServiceNow. Then we will answer questions if you have any.
• #5: Evergreen is a US based consulting firm and we have worked with hundreds of mid market, Fortune 1000 companies and public sector organizations to improve their IT Service Management execution. We are a full lifecycle firm, or in the words of one customer, “you have both process and technology in one company.” We are one of the top 5 US ServiceNow partners and have over a decade of domain experience in each area of the ServiceNow portfolio, but we view all of this from a perspective of customer centric IT Service Mgmt.
• #6: At Evergreen we think Traditional ITSM thinking is wrong, because it puts the customer last! Hard to believe but true. How can this possibly happen? First – we have walls around our thinking we don’t even see. “ This is how its always been done” – so we don’t think to challenge it. Second – we don’t know how to put the customer first. What are the best practices? How do we build it? So we put them in phase 3. Third – we DO know traditional Incident – Change & Problem REALLY well – so we do what we’re comfortable with. Unfortunately, its wrong.
• #7: We need to start with the customer. If we do it will change what we do. In Incident – rather than thinking about how to handle Incidents, we will focus instead on how to eliminate or prevent the customer from having to contact us in the first place. In Change Mgmt. – rather than always thinking about managing change – instead we will think first about how to eliminate or streamline changes. Knowledge becomes Search & Learn – a place for powerful, social self enablement – rather than a tired afterthought. Start with the customer and it changes what you do!
• #8: As we often do, starting with some ITIL definitions can help. You’ll notice black and green text. The green text is where we extended the definition to provide needed clarity. Services are consumable, durable in nature and are provided on an on-going basis. Services carry expectations around availability, hours of service, and support & remediation. Services are managed as CIs in the CMS, typically stored in a CMDB. Services are under Change control. Requests are transactional - once complete they are done, versus Services that are on going. Providing Oracle database to a customer is a service. Asking for access to the Oracle database is a request. There is no ITIL def for a Service Taxonomy, so we had to borrow one. According to dictionary.com, a taxonomy is the science or technique of classification. So for us a service taxonomy is the science or technique of classifying services.
• #9: You can see how the layering of services and customers could quickly give rise to a large number of services and combinations of services. As the providers, you can also see how easy it is to get lost in the volume. A Service Taxonomy is a logical, repeatable way to classify the services we offer, as well as the ones we might want to offer. The taxonomy of homo sapiens here is a pretty good type of taxonomy model for IT Services – the classification goes from very broad to specific, from millions to few. The 140 year old Dewey decimal system is another good taxonomy example, in use at over 200,000 libraries today. Could you imagine trying to find a book or manage a library without it? Most taxonomies organize things into logical categories, groups, and even sub groups as the classification gets more specific. Taxonomies don’t have to be hierarchical groups, they can be alphabetic listing of things as well. The best type of taxonomy for you is the type that is most useful in creating and managing the services you want to offer.
• #10: So what are the benefits of having a Service Taxonomy? Here are 5 good ones. Since we will have a number of constituents - customers and providers - with varying interest in building and maintaining our taxonomy, having a commonly understood way to group & classify items helps in the CONSISTENT definition & categorization of services. This consistency also brings CLARITY amongst the constituents as a strong, general, group understanding of the use of the framework develops. Being able to “see” and handle the framework easily from high to low helps to “shine a light” on redundant or unnecessary services thereby SIMPLIFYING the Service Catalog as well as ensuring individual services are built in the most simple, reusable way. A well understood classification system makes it much easier to ALIGN services in logical groups – helping to eliminate cultural or organizational biases. A clear, consistently understood framework with its attendant services makes it easier to identify services or sub services that can be combined to create new services – driving up beneficial REUSE.
• #11: At the highest level the framework should capture the broadest view of what you see as potentially within the scope of your effort. Of course the taxonomy can be grown or shrunk later – it is never locked down. But it is easier to start with a broad view as there is no downside to it. You don’t have to use all of it right away, and you will minimize re-classification efforts downstream that could come from changing the taxonomy. The parts of a taxonomy are meant to be parts of a whole. Here is a simple example of a broad framework covering Line of business services, shared services, and two types of IT service categories. http://www.evergreensys.com/servicenow-enterprise-service-taxonomy-framework
• #12: As mentioned, we break IT services into two groups – customer facing and internal IT. You don’t have to follow this convention, but these are often mixed together – which can confuse everyone. Here you also see one of our service taxonomy principles – that “the taxonomy labels are for the customer, and the framework is for the providers.” A service can be presented to a customer many different ways. It may be in a “what’s new” flashing icon, or in a list of “people who like this also like this” services. It isn’t just found by drilling down the taxonomy. But any section of a taxonomy is targeted at a particular customer set – and since we want to think like the customer, then the labels in that section should be in the customer’s language – not the provider’s. If you look at the 2 categories above – you can see the difference in the labels for the two groups. What do we mean when we say the framework is for the providers? It is the way the providers can understand the breadth and depth of services, and combinations of services offered. If you have 300 services – could you really understand a numbered or alphabetical list of them? It would be too hard. So the framework is for the providers – to help understand the services and combinations offered logically – to avoid creating redundant services, to better combine existing ones, and to ensure that services are aligned with the right customer.
• #13: Another Evergreen principle is “We all have services, and we all have customers.” Here is a view of that conversation from a Visual Service Taxonomy perspective. At the top IT is providing an Infrastructure, or Internal IT service from the category business continuity, in support of an application - SAP. The customer for the service is the IT employee who owns the app SAP. That IT employee provides the service we are calling “SAP application” to his customer the finance department, in this case, at a college. The college finance department provides the service “collect amounts owed” or “pay your tuition online here” to their reluctant customer – the college student.
• #14: A Taxonomy can have as many levels as make sense in any given section of the framework. One area may only have two levels of classification while another may require five. The guiding principle is customer centric – what is the way the customer would expect to see it? As a general rule of thumb – if any area exceeds 7-8 items, it makes sense to further refine with another level, as the number of choices becomes too broad to easily see & understand. Remember, the Taxonomy is only a framework for organizing, and ends where Services begin. To help better see the distinctions we have color coded Taxonomy purple, Services orange, and Requests green.
• #15: Here is an example - let’s assume we have 6-7 different flavors of Oracle service – Windows, Linux, HP UX, etc. As you can see Oracle is a Service Family. This is because Oracle alone is not a Service – it is not consumable. Oracle for Windows is a Service. In this example - we also have three different Service Offerings for Oracle for Windows - silver, gold and platinum. Last you see Requests, which are actions – often some form of add, change or remove.
• #16: We previously did a Webinar with 4 specific steps to building a Taxonomy - which you can access from our website if you like. So to change it up, instead, I’d like to highlight some key tips for success. Start with a common understanding. I know many of you have had ITIL training. I bet you found it much easier to discuss ITSM principles with co-workers who had also been through ITIL training. The same thing is true for moving from a technical, inwardly focused IT organization to a services based, customer centric organization. Building a common understanding of key terms with your team is essential for success.
• #17: Creating a single, broad taxonomy early on is critical. As mentioned, at the highest level the framework should capture your broadest view. It is completely fine to create multiple, different service catalogs inside a single, broad taxonomy. For example, the category HR would have a service catalog with services that are logically seen as HR services in the eyes of the customer. The same would be true for Customer Facing IT Services.
• #18: Here are some good general framework practices to follow. Try to target 8 or less selections per category, and try to limit the number of hops from highest level category to actual service in the 3-5 range. These two trade off each other as the schema is a balancing exercise in breadth and depth. Going broader at the end is not all bad – you might even have 10-15 items (services) under a sub group. Because you are drilling down to the customers real focused interest level, they will be ok with more options. Then work to simplify, use as few words as possible, and define the services in the customers’ terms.
• #19: We use a visual mapping technology called X Mind. Its powerful, easy to use and inexpensive. A visual approach allows you to work effectively as a group, to better understand the range and types of services offered – even as services reach into the hundreds. It helps you “see” where a new service type in one area might also be valuable in another area. It makes it easier to prevent duplication of services you already have – driving up re-use of existing services, and enabling you to see where combining existing services can more easily create a new service, rather than designing each new service individually from start to finish.  
• #20: It is important to apply a building block mentality to constructing services, then combine the blocks to create new services and variations of existing ones. If all your services are single threaded, custom built – they will be very expensive to create, impossible to maintain, and confusing to your customer. Think about Amazon – what would it be like if every Amazon department had its own checkout procedure? But this idea has challenges too – any service module, say for example “financial approval process” could be used in hundreds of services. So Service Configuration Management is mandatory, with each service being managed as a configuration item (CI), and mapped into any combined services of which it is a part. I know the CMDB has a reputation as a solution in search of a problem. This is a great use for it. It is important to look past that reputation and use it for managing your services, or you will get lost.
• #21: There is an old saying – “we have met the enemy and it is us.” It is true that the big pitfalls are frequently the ones we create ourselves – out of our inherent “IT nature.” We often don’t even see them. IT navel gazing is looking IT out rather than customer in. You cannot design services customers want and need if you don’t talk to them. Start and sustain a dialogue with key customers as you go down the services path – make it a part of the process you follow for success. don’t go all “wild west” on it. In IT if some is good, more is better. When we have a new, exciting idea we go gangbusters. We can build a lot of stuff fast, so we could build hundreds of “rifle shot” services quickly – with no consistency, discipline, or reuse. Then we would have a confused mess. Slow down, be premeditated, build with enterprise durability in mind. don’t claim victory too early. A taxonomy is challenging because in some ways it is a new way of thinking, with some new terminology. Even so, it’s the easy part – building the service offerings and delivering the services well, in a way customers love them,… that’s the hard part.
• #22: OK, now comes my fun part. They don’t let me demo much of anything here – but I do get to demo our taxonomy solution.
• #24: If you found this interesting and wonder what might be a logical next step, here are a few options. If you are interested in our advanced Self-Service Catalog & Portal, it is available as a self-service demo. You can get your own login on our website – follow the front page banner. Or perhaps you are considering a broader Service Catalog initiative but aren’t sure where to start. Evergreen offers a one day, private Service Catalog Workshop on your site for up to 15 attendees. It educates your team and creates a common language and direction. You can save months of effort in consensus building and get your program moving. We feel like it’s a real value at less than 4 thousand dollars, including travel. If you are looking for a better way to organize services – you can access a short demo video of our Service Taxonomy Mind Map application on our website. Last –here’s a webinar special! If you would like a copy of our Service Taxonomy Definitions and Best Practices Guide – just reply via e mail and we will be in touch to get it to you.