Change is hard. Service management people love the Status quo. Introducing new services in your system takes a lot of time, resources, knowledge. Even the slightest changes on an existing service can have adverse impact on the business process.
Large changes are often done by the technology specialists from architecture or infrastructure departments. They usually don't care much about your service management methodologies and best practices, since they operate by their project management methodologies and frameworks. Some of the common infrastructure project management methodologies are "Nexting" (clicking the Next button until the server is installed), Run'n'gun and Quick'n'dirty. And voila - new service is ready for support.
This mentality can create barriers between departments and impact the business in a very bad way.
In order to overcome this, all stakeholders have to agree on set of rules for introducing new/changed service.
So this is what chapter 5 is all about. Policy, procedural documents and records that cover activities during the service design and transition.
 |
| Design and transition documents |
Policy will describe the general rules of the game. I personally like to add a New/Changed service procedure which will describe the workflow and responsibilities. This ensures that everyone knows what to expect, minimizing the blame management playground.
1 comment:
Thanks for posting this valuable post. IT Service Management Certifications (ITSM) training are for professionals looking to develop information systems methods, reducing disruptions to the industry. Explore itil v4 mpt
itil 4 managing professional transition certification professional courses of IT Service management and excellence framework. Explore these professional courses of IT Service management and excellence framework.
<
Post a Comment