InFormalBrain

I have been reading a flow of posts over on IT Skeptic discussing why creating an end user focused Service Management process drives the biggest bang for the buck within the ITIL v3 framework. Lets think about how users get services within any organization.

Channels:

1. Phone
2. Web
3. Email
4. Instant Messaging

Service Providers:

1. IT
2. Project Managers
3. Finance
4. Procurement
5. User Acceptance Testing

Key aspects of providing a clearly defined service:

• The User of the services needs a clear way to use each of the channels to reach the service provider.
• Where the user consumes the service the service must be clearly defined and provide "hints" to the User so they can provide required information so the service provider upfront. The "hints" must be in end user terms.
• All requests for service need to be queued and prioritized. Think about how many services are provided via email and the disaster which occurs when your inbox is full of responses to questions. You can no longer keep the queue straight.
• The execution details of actually executing the service should be hidden from the User. For example the User isn't interested in the detailed tasks or collaborations which are required to dig into a capacity request and provide a response.
• There should be only one place all the channels end so users can always have a consistent experience.
• The user should have the ability to switch channels during service acquisition. For example, they may start by submitting a request on the web, but they may discover that the priority needs to be escalated. The User should be able to get a Service Desk Analyst on the phone and discuss how to escalate.
• At the end of the service the user should be surveyed to understand their satisfaction with the service. The survey results should be used to provide continuous improvement to the service structure.

Components of a well defined service:

• Service Description - An end user focused description of what they will receive as a result of requesting the service to be performed.
• Service Requirements - An end user focused script which leads the User through a set of questions which help discover requirements needed for the Service Provider. The better this script is the less times the Service Provider will need to consult with the user to clear up what is required. Continuous improvement is key in this space to reduce cost.
• Pre-defined service Execution Plan - A set of repeatable tasks which the service provider will use to deliver the service. The tasks provide a vehicle to deliver the service the same way every time with lower risk. Lessons learned and review of the tasks at a frequent interval should help drive down cost and remove errors which may occur.
• Clear Approval Process - The approval process for Service Execution should be pre-defined and the approvers should be pre-defined.
• SLA - A clear Service Level Agreement will help the user understand when they should expect the service execution to be complete. This reduces unnecessary queries to the service provider. These queries are a critical distraction.

Service Pipeline:

Channel -> Service Request -> Change Request

Service Contact Flow:

User -> Service Desk -> Service Owner -> Approver -> Specialist -> Service Desk -> User

So, based on the kind comments of a number of people and a bit of pondering we came up with the following solution. 1. Each service model will be oriented around a single Application Environment (PROD, UAT, SYS, DEV) and then will include dependent CIs such as virtual and physical servers, database instances, application servers, etc..  Each dependent CI will be related to the Application CI using a direct impact type relationship.  (Our topology tools will find the dependency relationships between CIs and also add those to the CMDB). 2. The application CI which is being modeled will have a name like [application]-[environment] (e.g. app1-prod).  This will provide a unique name for each application instance as it exists in different environments. So, the environment is a unique part of the CI name and could be easily reported out using %Like% type queries.  At some point we may also add an attribute to the Application CI but it is not critical path.

I am currently running a project using Agile SCRUM to deliver a CMDB solution, an Upgrade to Remedy Version 7 and ITILv3 processes. Obviously this type of effort has some pretty profound impact on the organization especially when there are years of process, policy and belief which currently govern perceived best practices.

Obviously the goal of any ITIL implementation should provide an adequate set of controls, and awareness and collaboration within the Enterprise. The teams consuming the current processes are looking for ways to optimize their work, while still conforming to the core principles above.

We have laid out certain goals to mine out more standard changes within our organization to streamline IT. It is apparent that the focus of the organization should be on the large, complex and risky changes while metrics collected during problem management should help us understand if have turned the knob too far one direction.

One of the teams brought an interesting problem to us today. They wanted to document a set of activities which would not require even a standard change entered into out change management systems. This at first raised concerns on my part until I reviewed the kind of things they were talking about. They were asking about day to day system administrative tasks which in my mind would not fall under the definition of a change with ITIL:

The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. -- Source ITIL v3 Glossary

What is interesting is that by this definition many day to day administrative tasks such as cleaning up logs, running jobs, etc really don't fall under the definition of "Change" as they are not modifying a managed CI. For example if an UNIX admin needs to clean out /var should a change record be required? Some may argue that it could affect the system but I believe we could argue that most times it is completely safe.

So my thought here is to require a published document which outlines these types of Day to Day activities which are not changes. The standard would be reviewed and managed under change management and be approved by the CAB. These types of day to day activities would not require any change logs or records within our Change Management system. If problem management shows by trend that this day to day work is causing incidents then we reel them back to Standard or Non Standard Changes.

I would welcome the thoughts of others...