The basic convention within ITIL is that an organization’s overall Service Catalog can be usefully subdivided into a Business Service Catalog and Technical Service Catalog. Business Services are those which end-users interact with directly and which directly support end-user outcomes. Technical Services support business services, but they’re only accessed by users indirectly.
So, from a support perspective, what value do we get from defining technical services? What unique value do they offer a service management organization?
The answer is simple: Technical Services encapsulate performance commitments internal to the service provider. As such, they should map very closely to OLA’s (actual or planned) and probably also map very closely to support groups.
In considering the latter point, it’s probably safe to say that Technical Services can and should map EXACTLY to support groups unless some difference in performance is required for different services offered by a single support group.
Here’s an example. I have an application-based CRM service which is in turn supported by a number of technical services: network support, server hardware support, Windows support, application management, and data administration. But, upon closer examination, we see that both data administration and application management actually map to the same support group.
Does it make sense to continue to consider application management and data administration as separate services?
Well, unless there’s a different OLA attached to those two services, my answer (in the interest of keeping things simple) is probably not.
What purpose would it serve?
Clearly, ticket routing is going to be the same in both scenarios….only complicated (unnecessarily) by having two instead of one service.
What about reporting? Wouldn’t that be better supported by having both services in this example?
Well, probably not. We can already use other common fields such as incident/request categories to support reporting needs. We don’t have to use Technical Services for that purpose.
Again, the only really unique value offered is that Technical Services allow us to bundle up (encapsulate) performance commitments around one thing so that everyone downstream (business services and possibly other technical services) knows what they can depend upon.
In other words, we use them mainly to give OLAs a place to live.
This is a fairly arcane topic, but a lot of organizations put a lot of energy into Service Catalog modeling, often without a clear sense of what they can expect to get from their efforts. Modeling business services helps users understand and get what they want. Business Services also help the service provider be clearer about what it’s actually doing for users that’s actually useful. And, of course Business Services provide a home for SLAs. No services, no SLAs.
Technical Services define the known performance building blocks a service provider can draw upon to fashion dependable business services for end users. They give OLAs a place to live.
In practical terms, an organization with no OLAs and no plans for OLAs really has little to gain (apart from a general feeling of clarity) by modeling up its Technical Services. They won’t add much from a reporting point of view…at least not much that can’t be gotten elsewhere. Similarly, they won’t add any special magic to ticket routing.
So, a good starting approach for modeling technical services is to mirror them on your support groups and only elaborate them further if need or intend to wrap different OLAs around them…or if you can state a practical reason for otherwise making things more complex than they need to be!
