#SMFlashbook – Best Tip(s) for Building a Service Catalog
This blog is being posted today as part of a larger community effort to publish common topic blogs on the same day. I encourage you to review the other blogs on this subject by searching the hashtag #SMFlashbook.
I was simultaneously confused and disappointed by the recent itSMF/Forrester survey results that indicated a large number of organizations had not built a Service Catalog due to lack of funding. I am also always confused when organizations move forward with their Service Management initiatives without first defining their services.So I challenge you with a question: How can you manage services if you do not have a clear understanding of the services that you provide?
Here are some very simple and virtually free tips for creating an initial and meaningful Service Catalog:
- Step away from your tool. The first steps can be captured on paper, whiteboards or in documents. The tool part will come later.
- Gather stakeholders and collectively define and agree on your business services. If you do not know where to start, take a look at your company website or intranet. In actuality, all businesses or business units only do five things:
o Acquire or develop a product
o Market and sell the product
o Deliver the product (logistics)
o Support the product
o Have a corporate infrastructure – HR, IT, Finance, etc.
- Map the IT Service (s) that underpin each of your business services. Remember, an app is not a service – one service is likely comprised of multiple applications and infrastructure. Try to use the same terminology for the business and IT service (e.g., the “Fullfillment Service”)
- Describe the purpose and use of the service in concise, business-speak
- Identify and document the stakeholders for each service
- Try to define some very generic service levels or service hours for each service
- Review, agree and publish
- If you have a Configuration Management System, you can then replicate this information in a “service CI” record. The Service CI can then be joined with all of the other technical and non-technical CIs that contribute to the service. This allows you to compose or decompose the service for processes such as Incident, Problem and Change.