Service Catalogue in a Telecommunication Services Co.

[TelcoGuy]

Does have any experience in establishing of a Service Catalogue in a large/incumbent Telco. In terms of; What are the traps for new players in this space?

[Guerino1]

Hello TelcoGuy,

I and my firm have a great deal of experience in this space. However, I don't understand what you mean by "traps for new players".

The biggest problem we've found is the implementation of a truly usable and robust Service Catalog that is accessible by everyone in the enterprise who needs it and that can generate appropriate Service Requests which can be managed through completion. The catalog must be able to provide complete transparency as to the work going on to manage the Service Requests, for the Requestor, for the Accountable Service Group doing the work, for executive management to see, etc. The catalog must also be generic enough to allow for the definition of many different Services that meet the needs of the entire enterprise, not just the IT staff.

We've seen many mid-to-large companies try to go the cheap route and implement Service Catalogs through spreadsheets and/or static web pages, only to have to scrap their implementations as entire failures after long painful rollouts (in the end they burned all that money and it wasn't cheap for them, at all!). This is because these solutions are totally unusable and ultimately unacceptable in large geographically disperse enterprises that have many different organizations who rely on the Services and the Service Groups.

Here are some general requirements for your Service Catalog:

- Service Owners must be able to define and publish new Services
- Service Owners must be able to assign default Service Groups to their Services
- Services must be editable
- End Users must be able to easily search for, find, and invoke Services
- Invokation of Services should lead to one or more manageable Service Requests
- Accountable Service Groups should be able to manage Service Requests through completion
- Requestors should be able to see progress on the Service Requests, including Requested Priority vs. Assessed Priority
- Everyone should be able to collaborate in the platform on both the Services, themselves, as well as on the Service Requests that are being managed
- All entities associated with Services, Service Requests, Service Groups, Resources, Documents, etc. should all be fully visible in the CMDB, including all relationships between them.
- Services in the Service Catalog should have clearly published SLAs
- The catalog should allow for the publishing and access of related documentation to both Services and Service Requests
- Service Teams should be able to run reports on Services and Service Requests to allow for trending and analysis
- Service Requests should correlate back to formal Projects that have been approved
- The Service Catalog should allow you to quickly spot and optimize redundant Services and Service Groups
- Services should allow for the publishing of SLAs
- Service Requests should allow for the harvesting of metrics to be used for comparison against the SLAs
- Etc.

There are "many" more requirements but the above should give you a warm feeling of what it takes to be successful with a Service Catalog.

Anyhow, I don't know if I've properly addressed your questions. If not and you'd like to contact me offline, please feel free to do so at: Frank.Guerino@TraverseIT.com, I'd be more than happy to help you with any questions you have.

Regards,
_________________
[Edited by Admin to remove link]

[m_croon]

Telco Guy,

I've worked on setting up sla's (actually OLA's) for a telco, where I operated from a business perspective. My main experience so far being with ITIL and "regular" ICT (mostly IT without the C), I found some trouble adressing differences between IT (Information Tech.) and TI (tech. Infrastructure). The latter being very specific for telco's (major tech, platforms from suppliers such as Siemens, Alcatel etc.). My aim was to use one sla template (incl. service descriptions) for both IT and TI.

I found myself being in danger of detailing too much on the level of TI-components with which I was unfamiliair, where I should have thought and worked more in terms of TI-functionality (end to end service). Also, the guys from TI were not familiair with ITIL, therefor a lot of communication had to be put in to convince them of the benefits. In 2 out of 3 cases, I found myself succesfull. The delivery of the 3rd SLA was postponed for a while, and will be re-started next year.