The Service Catalog (or “Catalogue”, if you are in the UK) is a component of the ITIL framework that quickly found meaning in many IT shops (even those uninterested in ITIL). It’s an extremely simple concept, but vendors and consultants have really hyped it up over the past decade. It has been pitched as a multi-month engagement and/or a customized application. Yet, all the Service Catalog represents is a menu of services that an IT service provider offers. It bundles, aggregates and translates a bunch of IT components into a service offering that a business can understand.
Each service within the catalog typically includes:
- A description of the service
- Timeframes or service level agreement for fulfilling the service
- Who is entitled to request/view the service
- Costs (if any)
- How to fulfill the service
The Service Catalog…
- Translates “IT Speak” into “Business Speak” by portraying services in an intuitive way customers can understand
- Bundles technical components into business services
- Projects and proposals can reference a ready-made product description
- Documents service information such as price, service levels, and value proposition
- Tracks cost allocations and key metrics
- Defines and maps service delivery processes, made repeatable and measurable to enable continuous improvement; reducing IT process inefficiencies and redundancies
- Creates a standard language across sales, architecture, engineering, implementation, and support teams
The Service Catalog itself requires some diligence and attention, but it is a relatively trivial effort to produce… it’s a front-end menu with a description, owner, features, etc..
The back-end to a service catalog, however, is certainly non-trivial. It calls out the level of maturity of all the processes that fulfill the Service Catalog menu. And if those processes are not there or are not as robust as they should be, the Service Catalog can be a catalyst to maturity.