Neven Zitek Just by casually reading our blog, you can pretty much get all the basic info regarding core ITIL modules from Service Operation, Service Transition, Service Design, or Service Strategy. IT organizations are generally most interested in Service Operation, but individual modules within the ITIL framework are so delicately interconnected that without deeper understanding, only confusion arises. When writing articles on this blog, we aim to clear the confusion and bring sense to the whole ITIL framework.
With the success of the ITIL Capacity Plan – A document you need, but probably don’t have article, it seems appropriate to start a whole series of articles with similar titles. This week we’d like to bring the Availability Plan to your attention, and before we continue I strongly suggest that you read more on Availability Management – calculating for improvement, if you haven’t already.
Purpose of the Availability Plan
Figure 1 – Availability Management (SLM = Service Level Management, IT Svc. Cont. M. = IT Service Continuity Management)
In the simplest terms, the purpose of the Availability Plan is to ensure that all existing and future Availability Requirements for IT services can be provided cost effectively.
As Availability Management has both reactive and proactive components, there are lots of data sources from which meaningful information can be obtained, and stored in the Availability Management Information System (AMIS). The Availability Plan is a living document that should be updated and reviewed regularly.
At the beginning, there is always a scope.
As with any document, the Availability Plan should start with a clear scope of the services that are covered by it. At a bare minimum it should cover current business-critical services (VBF – Vital Business Function – read more on Vital Business Function according to ITIL principles) and new and planned services in development.
Of course, the document should state roles, responsibilities, and responsible persons for updating the plan, approvals, and expected frequency of those activities.
Measured service disruptions and impacts on availability
All expectations regarding service availability should be stated in the Service Level Agreement, and any recorded drop in availability should be recorded in the Availability Plan.
If you create a simple “Agreed vs. Measured” matrix, for all services in scope, you’ll have a clear overview of services’ capability to provide required functions without any interruptions.
Note that in the case of unavailability, measurements should reflect real business impact, and should always be business or customer focused.
What is/should be done to address shortfalls?
Once we have all information regarding (un)availability, the responsible person should plan for actions to address any availability shortfalls. Those plans should be listed and related with appropriate service, as well as planned timeline (due date), and any investment needed in order to fulfill the plan.
Where investment decisions are required, options with associated costs and benefits should also be included.
What is currently being done to address past shortfalls?
Aside from planned or past actions to address availability shortfalls as described in the previous section, the Availability Plan should also contain a list of all current actions (in progress). This information is important and should be aligned with other framework components (Change Management, Knowledge Management, Service Desk function, Service Level Management, etc.) in order to avoid any confusion or miscommunication; we want to avoid multiple requests to address the same issue.
Changes to expectations
Everything in life is subject to change, and the Availability Plan is no exception. If there are some changes in availability requirements, make sure they are listed in a separate section.
It is important to keep track of such changes, so any follow-up actions can be tracked back. It’s also practical to have such changes listed in one place for historical and review reasons.
Technology or other considerations
We live in a time where technological advancements greatly impact our lives and businesses. Every once in a while, the responsible person should conduct a formal evaluation of current (in use) vs. new technology on the market from an availability perspective – is there anything on the market that can improve our availability score, or bring other benefits to the table (reduce maintenance efforts, costs, or reliability)?
Service (un)availability can’t be swept under the rug
Service availability is the most visible and measurable component of any service, or to put it more accurately – service unavailability is the most visible and measurable component of any service. Ensuring expected and agreed availability should be one of the key goals for any IT provider.
With Availability Management tied to Incident Management, producing Availability Reports and an Availability Plan should be fairly simple tasks, yet many organizations fail to recognize the value. As in any other similar situation, I believe that IT organizations are so deep in technology that they expect that same technology to resolve any issues by default. The truth is, more technology only brings more issues if it’s not managed properly.
Use this free ITIL Gap Analysis Tool to check how your Availability Management process implementation complies with ITIL recommendations.
