Troy's Blog

Friday, August 13, 2010

Why You Need To Know ISO 20000

When You Are Building a House It Needs To At Least Meet the Code

ISO 20000 as the International Standard for Service Management has been published since 2005 and it is going through its first major update this year and next.

My good friends and fellow Pinkers Jack Probst and Robin Hysick are involved in the update project and Jack has the honor of serving as the US Task Group lead (Task Group 25) for the 20k update and is in the thick of things.

Add to this a noticeable lift in general interest and the addition of the ISO Foundation course to our growing portfolio of IT Management Education products and you will see why ISO 20000 is top of mind for me.

In my role of Product Strategy and as the Lead of our Consulting Practice I am expected to answer the “So What” question on a frequent basis.

So What: Why should I care about ISO 20000, if I have an ITIL background and certifications up the wazoo? Or conversely why should I care about ITIL since I have my Auditor’s or Consultants Certificate in ISO 20000?

Both are good questions that until recently I have struggled to find a concise “Elevator Speech” for. That is until just recently when I was talking with another Pinker friend of mine Anil Dissanayake. Anil and I were discussing the ISO 20000 class he was teaching and wrestling with the best way to position these two elements ITIL / ISO 20k when an analogy came to me that made the whole puzzle crystal clear in my head.

First we need to establish some baseline understanding.

ITIL is a library of knowledge or good practice which provides a reference model covered in 5 substantial books of a few hundred pages each

ISO 2000 (2005) Is a standard documented in two main parts:

Part 1: Specification - “Must Haves” (24 Pages including all the white space, terms of references and the usual acknowledgements)
Part 2: Code of Practice “Nice To Haves” (42 Pages providing an expansion on the specification with illustration, commentary and additional concepts)

So in total being overly generous there are 66 pages of content to teach, consult or Audit on - providing you count the title pages and table of contents.

This is why I find discussion about adopting or implementing ISO 20k extremely frustrating. A topic I address in the following article.

ISO 20k The Industrial IT Password / The Value And The Misunderstanding of ISO 20000

So that being said why should you or anyone want to attend a course on ISO 20000?

This is where my analogy comes in: Electrical Code and ISO 20k

Lets for the moment put this in the context of the trade of Electrical Engineering or simply the study to become a Certified card carrying Electrician.

As an Electrician you will need to study a body of knowledge relevant to your trade through a series of courses which start with the fundamentals of electricity and then progress on to harder courses studying the application of the fundamentals in various circumstances. This course of study will likely take you a series of years requiring you to pass a set of exams and certification processes which will eventual reward you with your license as an Electrician.

As part of this course of study you would also take one or more courses on the “Electrical Code” ensuring that you understand the minimum requirements for either the design of new projects or the repair and maintenance of existing facilities. As with most codes there is a minimum specification or mandatory set of requirements and also subsequent documents that expand on and provide context and further explanation of the code itself.

As part of your course of study you would study both the body of knowledge and the specification or code. It would not occur to you to do otherwise, even if your certification process as an Electrician did not require it.

So in this analogy you can make the following tie into the ITSM world.

As a student of IT Service Management you study frameworks of knowledge such as ITIL and COBIT but you also need to have a firm grasp on the minimum specification and code of practice for ITSM to ensure you build with the code in mind or conversely ensure your suppliers are providing you an ITSM service that meets at least the mandatory set of requirements. Explicitly: ITIL is the framework of reference and ISO 20k is the specification / code of practice that validates a minimum level of quality.

So the correct answer to the question: Which course should I take ITIL or ISO 20k? is Yes (Both are required)

Troy’s Thoughts What Are Yours?

”He knows the tax code as thoroughly as the pope knows the Lord’s Prayer.” William Proxmire

 

 

Friday, July 09, 2010

Request Fulfillment Improvement Roadmap

Request Fulfillment And Its Many Moving Parts

From the dawn of IT Support the users and customers of IT services have looked to the Service Desk or at least someone who will answer a phone or monitor an email account to respond to requests for new, modified or additional services. 

As of ITIL version 3 Request Fulfillment is understood to be a separate and distinct process from Incident Management. I explored this process in an earlier article.

Service Request vs. Request for Information

From the ITIL v3 glossary we can find the following definitions:

Service Request: A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See Request Fulfillment.

Now that the debate over wether an Service Request is part of Incident or Change Management is over despite your personal views on the matter. Lets look at what it really means to tackle improvements around this process we have been doing for years.

First it is important to point out that making improvements to the process of managing requests is not as simple as dealing with one workflow. Like most things in life Request Fulfillment is more complicated under the surface than it may seem. Sure you can create an efficient way to submit requests without too much of a challenge. However, its what happens behind the scenes from the point of someone filling out the web form or making a call to the Service Desk until the shining new laptop is delivered fully loaded that takes the real work to figure out.

Think of the Request Fulfillment process like the two slices of bread on a sandwich, in between the top and tail of the processes are several other inter-related but separate processes.  To improve the maturity of this process (make sure the new employee is productive on day one, or that that laptop comes with the right OS and software image) it is necessary to understand the approval, ordering, inventory and supply elements that support the provisioning of the request. A key understanding is that Request Fulfilllment is typically front ended by a Service Catalog or IT Portal and integrates key processes such as:

1. Service Catalog
2. Procurement, Cost Center Approvals
3. Asset Management
4. Service Asset and Configuration Management
5. Service Level Management
6. Provisioning
7. Access Management (On boarding / off boarding of employees)
8. Image Management
9. Etc..

Without the tight integration of these various management practices the request is received and not progressed through these process dependencies in an efficient and time sensitive manner.

For Example: You receive a request to prepare for a new employee start in 5 business days but it is several weeks before all the accounts and elements the employee requires to be productive are delivered for their use.

Since what we are describing here is the coordination of a set of variable and dependant tasks executed by many different groups it is highly recommended that this process be implemented leveraging a tool best suited to supporting the full lifecycle of the request and that supports the management of dependant and parallel work orders or tasks.

Since what I have described can be a complex task it is typical that an organization will improve Request Fulfillment as a series of maturity stages or steps. In my experience the maturity of this process can often be improved in the following steps.

Step 1: The process is managed as an extension of Incident Management and front ended by the Service Desk. There are no separate process elements or established ownership elements. The process record is differentiated from the Incident record by an attribute on the incident record that establishes it as a request. This record level differentiation supports reporting separation and different escalation policies.

Step 2: The process is understood as separate and distinct from Incident Management and has defined in relationship to both process and requestable service elements. The Request Process is managed by an ITSM tool that supports the management of complex task assignments to multiple support groups that are required to provision different aspects of the request in a parallel or set of sequential tasks.

Step 3: The Request Fulfillment process is front ended by a Portal or Service Catalog that enables the workflow and approval aspects of requesting and provisioning service elements. Integration is defined with other key processes such as procurement, asset management and various supplier-provisioning processes.

Remember that perfection is not always the goal and that incremental improvement is better than no improvement at all.

Troy’s Thoughts What Are Yours?

“Consciously or unconsciously, everyone of us does render some service or another. If we cultivate the habit of doing this service deliberately, our desire for service will steadily grow stronger, and it will make not only for our own happiness, but that of the world at large.” ~Mahatma Gandhi

 

Thursday, June 17, 2010

Using Lean Principles for Effective Continual Service Improvement

“Standing On A Lean Scale Takes Discipline and Unusual Courage”

Lets face it sometimes ignorance is bliss!

One of the challenges related to effectively engaging in continual service improvement or even the initial task of documenting processes, policies and roles is that it forces us to take a long hard look at what we do today.

The desire not to acknowledge or confront what we know to be issues stems from the same irrational dislike we have for bathroom scales or even worse the annual fitness assessment at our family doctor. As long as we don’t have the facts confronting us we can willfully ignore what we intrinsically understand to be true but do not have to will or desire to face.

This is where formal Improvement Models can be used effectively to move us into the discipline of self evaluation and prioritized improvements. This is the same reason we sign up at health clubs and work with expensive personal trainers or in our context consultants. It is not that we could not figure out what needs to be improved on our own, but somehow working within a structure and being held accountable gives us the discipline to get things done.

This is where Lean Principles can be used to drive a discipline of assessment and improvement.

First: We acknowledge that there are many things we do today that are not directly or indirectly beneficial to our goals or produce value. In short activities or actions in which we engage that are wasteful, redundant and provide zero to no value.

This means we have to first understand which activities of a process are part of its “Value Stream” where process inputs are worked on and transformed into a valued output that meets a validated need. In light of this understanding we can assess all process activity in terms of:

Valued Activity: Actions, resources or activities which have a direct connection to producing the desired outcome
Non Value Activity: Actions, resources or activities that while not having a direct hand in producing outcome provide the necessary measurement and governance elements to keep the process intact. (The glue that holds the process together and executed as expected)
Waste Activity: Actions we take that neither support the outcome or have a hand in keeping it glued together

With these principles in mind the goal is to optimize the valued activity, minimize the necessary Non Value Activity and eliminate the waste. However the question is how do we identify the waste, trim the fat and make sure we are only doing things that produce value?

This is where the Lean waste categories come in; time to have your process measured on the Lean Scale!

Consider using the following categories to evaluate either your current “As Is” process or even your freshly minted “To Be” process design and face the unpleasant and sometimes downright ugly facts of process bulge that will likely require a lifestyle change to remove.

Overproduction—Too many steps, transactions, authorization requirements, cycles in the process

Lets face it sometimes our processes look like Mac Trucks when what we really need is a Honda Civic or a GM Vibe. The problem with some of us process geeks is that we can over engineer a process based on the goal of perfection versus fit for purpose. Sometimes good enough is good enough!

ƒƒOver processing—Too much Non Value-added activity

Yes measurement is good, and assessments have their place to keep an eye on quality and service improvement opportunities. However, maintaining a sane balance of reports, administration and process governance is key based on the complexity and risk required.

ƒƒWaiting Unnecessarily—Too much time between process activities

Since a process is at heart a series of dependant or parallel tasks which take inputs from the upstream activity and passes them downstream towards the eventual value based outcome there are many points of potential wait states where the flow of the value stream spends unnecessary time queuing. Making sure that these wait states are not unduly long or even necessary is a key part of finding opportunities for process improvement.

ƒƒOwnership Issues—When a single person cannot be identified as the single point of process accountability (The request “Take Me To Your Leader” produces a blank stare!)

Without clear ownership a lot of finger pointing and “Someone should really take care of that” type of statements are common. Just like having 25 priorities means you have no priorities, a process with out clear ownership suffers from benevolent neglect. The concept of we all own it is sure to lead to wasteful activity.

ƒƒUnnecessary Movement —Too much or redundant movement between value-added steps

A good example of this is an incorrectly designed Change Management process where all changes regardless of risk or size flow through a change advisory board for approval. This tends to bog a Change Process down to where it is deemed to be ineffective, bureaucratic and yes wasteful of people’s time. The idea is that changes should have the right level of approval and release assurance based on the level of risk. To many approval cycles for a minor change is not beneficial.

ƒUnderutilization Of Human Resources and Talent — We don’t use the skills and talents that we have

We typically think of waste in regards to things we should not be doing. How about those things or people we should be using but do not due to political or lack of knowledge reasons. An example of these types of situations? How about not giving the Service Desk ownership of end to end incidents? Not utilizing your Quality Assurance folks as part of your production assurance steps of Release and Deployment Management Not tying your Architecture group into the process of defining IT Services (many of which they helped to design). Unfortunately we too often allow silo mentality block us from using the skills already inherent in our organizations.

Lets face it we could all loose a few pounds of inefficiency if we looked at our current practices through the pragmatic lense of value and waste.

Troy’s Thoughts What Are Yours

“Regret for time wasted can become a power for good in the time that remains, if we will only stop the waste and the idle, useless regretting.”
~Arthur Brisbane