In my last few posts, I've been going over the steps for getting your team ready for planning a service catalog. We're taking a little break from that series to answer an important question. But stay tuned, in my next post I'll be discussing the parts of a Service Catalog, which is important too. For now, read on and get key insights on building a service taxonomy...
For those interested in how to best organize services for a service catalog, and appropriate taxonomies for doing so, I received a question from a participant in one of Evergreen's many webinars that may be of interest.
Recently Tiffany Wood, Assistant Director of Support Services at the University of Northern Colorado, asked the following question. I thought it would be of interest to others and Tiffany kindly gave me permission to post it in our blog. Thanks Tiffany!
Here is the email I received from Tiffany:
“Don - I was at a presentation a while back and you mentioned the Xmind mapping software that you have used (for taxonomies).
I have purchased this software and have built out our organizational structure and started to add in services that belong to specific groups. Where I am confused is the best way to show the relationship between a service that is owned by group A but group B handles one portion of that service.
Any light you could shed on the best way to map this out would be greatly appreciated.”
Good question! First rule - don’t put the org structure in the taxonomy. Organize the taxonomy in the way that the customer for any given part of it (aperture) would want to see it. And make sure the labels are ones the customers understand rather than provider labels. Otherwise it will just be a repeat of the silo thinking and ownership that has plagued so many for so long. It is true that the services in a given area like “Datacenter & Infrastructure Operations” might primarily be owned by one part of the organization, but it never is in its entirely. This will be uncomfortable for your providers as it is new thinking, as well as anyone focused on control.
Any given IT service being delivered stands on dozens up to possibly hundreds of other IT services. For example – if I am providing SAP accounts receivable software as a service to accounting, my service is standing on compute, cloud, storage, identity, network, active directory, disaster recovery, and dozens of integrations (services in their own right) for me to be able to do what I do.
To answer your question let’s use an example. In the taxonomy, perhaps we have a sub category we call Oracle Database Services – hanging off the taxonomy is a service we call Oracle for Windows. This supports the SAP accounts receivable app, but may also support hundreds of other apps as well. Now you could draw “backplane” connections for these interconnects in the taxonomy, but it would be thousands and would be unmanageable. This is what your CMDB is for – for mapping the sub service connections down from the higher tier service to all the sub services supporting it – and there are probably a lot!
So virtually every service IT delivers is really made up of lots of services working together. We see this as chains of customers and chains of service providers – until it gets to the ultimate end customer. Thus our principle - “everyone has customers, everyone has services.”
Hope this helps – good luck!
About the Author: Don Casson is CEO of Evergreen Systems, an IT consulting firm helping medium to enterprise public and private sector organizations to dramatically transform their IT operations. Don is a frequent writer, blogger and presenter, and has delivered over 50 webinars on topics in Service Management, including IT and shared services.
Feel free to contact Don at email@example.com