Tuesday, January 29, 2008
Integrated Tool Strategy
Integrated ITSM Tools or Best of Breed Point Solutions?
It is no secret that to even get close to the process integration that ITIL suggests is good practice it is critical to consider workflow automation and tool requirements. However, that being said, have you also considered that underpinning these processes is data? Data that is passed back and forth between processes as tasks, workflow records, approvals, SLA time frames, costs and configuration item details.
Invariably the activities, inputs and outputs of IT service management are represented in a digital form that is shared by many processes at various times and for various reasons. This digital web of information flow is ultimately represented by an ITSM tool and data architecture that supports the over all vision and strategy of an enterprise IT function fulfilling the role of a key business partner and service provider.
Underpinning the integrated ITIL process model must be an integrated ITSM tool strategy that is supported by a shared data model!
In the ITSM community we are very comfortable talking about the IT governance and process levels of service management. However, we often fail to consider the tool and data definition that is required to make it real. In my personal experience it is always the tool element of the ITIL project that takes the longest time; not the process design!
At the heart of this challenge is the silo or domain approach to how we purchase IT management tools. Those of you who follow my posts will recognize a familiar theme in this statement. The fact is that one of the most significant challenges to a service management approach is the cultural and organizational focus on IT silos to the detriment of enterprise IT management issues.
To explore this concept further from a tool perspective consider your own organization and the following questions:
- Is there a defined enterprise IT tool strategy and architecture model?
- Is there any function or group in your organization that has a mandate to create and govern an enterprise tool strategy?
- Do you have a function in your organization that manages and supports IT tools which are used by the enterprise IT function?
- Are IT management tools budgeted for and purchased at a domain / departmental level but are required to fit within a predefined enterprise strategy?
If you are like the majority of companies I have worked with over the last 10 years all of these questions would most probably be answered with a no and the resulting tool landscape would be filled with multiples and duplicates of various types of tools that do not integrate. It is also very common to find tool decisions for ITSM programs being made in isolation without the consideration of integrated tool requirements. This scenario I address in the following article. When ITIL Projects Collide
The following picture represents the concept of an integrated tool architecture with a focus on IT operations. As you can see from the diagram you could develop a whole new set of boxes on the development side of the IT house for the category I have listed as “Resource and Portfolio Management Tools”
With this picture in mind let me walk you through the following use case.
A business customer submits a request via the online service catalog for an enhancement to an application service. This request is fed into the Change Management process where the approval initiates the assignment of a development resource. The development resource engages with the release and deployment process during the build and test phases of the enhancement.
Once the release has been tested and validated as production ready the change process validates and coordinates the scheduled update of the production version of the application service. Triggered by the approved change schedule the provisioning tool picks up the code within the definitive media library and updates the production environment. As a final step and after validation that the release has gone without an issue that requires a back out of the change the CMDB is automatically updated with the new version number.
Sound like Fantasy? Not if you have integrated IT management tools. This concept diagram is exactly what the major ITSM vendors are striving for and is the basis for much of the merger’s and acquisitions you hear about on a regular basis. The prize they are after is a management tool to run the majority of your IT shop.
Two questions come to mind:
- Are the tools there yet? (Many of you would agree with the direction but say we are several years off)
- Is the average IT shop culturally and organizationally ready to take advantage of an Integrated IT Management suite?
In my view the same business logic that argues that Enterprise Resource Planning (ERP) tools like SAP or ORACLE Financial makes sense for the business (integrated modules connected to common data repositories) applies here as well. Some call this ERP for IT
Troy’s Thoughts What Are Yours?
”Where we have the choice between putting a dollar against those that are going to advance horizontal integration and those that are going to sustain current capability, we’d rather put them against the horizontal integration activity.” ~Stephen Cambone
Saturday, January 19, 2008
Who Is My Customer?
A critical aspect of understanding IT Service Management is the ability to distinguish just who you are trying to serve.
As a reader you might read this first statement and raise an eyebrow at what seems to be an obvious question since you probably have a fairly good perception of who you believe your customers to be. However, the keyword that I just used in the last sentence is the word “perception”. You see the thing about perception, or to use a related word “Perspective” is that it changes based on where you are currently standing.
So the question is, where am I going with this bizarre line of logic?
Consider that many of the articles in this Blog discuss the concept of maturity and the changing role of the IT function within the business. That change is the evolution of focus from technology optimization to the additional concept of service provision. During this journey of discovery there are at least three different answers to the question: Who is my customer?
Before I launch into this further let’s establish a few definitions.
Customer: A customer is an individual or group of individuals that uses or consumes products and services that you offer. The word customer derives from the english word custom. The context is a shop keeper who has a client who’s custom it is to come into the shop on a regular basis and purchase products or services unless that custom is disrupted or broken based on an unsatisfactory experience. In which case the custom of buying at the shop is stopped and they are a customer no longer.
Perspective: To establish a point of view or belief based on a filter of observable and experiential sensory evidence. As the saying goes: “Perception is reality”
Now that we have established my layman’s view of these two definitions consider the following maturity model.
The Changing Role Of IT Within The Business
- IT is focused on technology optimization, infrastructure and applications are managed as separate and largely unrelated domains.
- IT is focused on the integration of technology and the delivery of end-to-end systems (Business Solutions).
- Enterprise IT (Applications & Infrastructure )groups have a single strategy and are focused on business process automation; however, IT sees itself as different and distinct from the business functions.
- IT realizes that it provides a core business function and that there is no practical way to separate the digital business process from its underlying technology systems. The IT function considers itself one of many business functions.
- IT’s focus is enabling business services and products for use and consumption by outside customers.
As an organization moves through these five stages of maturity the answer to who is the customer changes.
- Stage 1: The question of who the customer is, is not even asked
- Stage 2: The customer is understood to be other IT groups or domains that need products and services for their part of the offering. Eg: Server Hosting for an applications group. (The exception here is the application group which understands the business units to be the customer)
- Stage 3: The customer is understood by the entire IT function to be the business units they enable.
- Stage 4 & 5: The customer is now the external customer of the organization, firm, hospital, etc.. (In addition to the IT and Business Unit Customers)
Remember that I commented above that perception and perspective are based on where you are standing!
However, what is equally true is that each definition of customer is true at all stages. So when you are defining your services to publish in the service catalog, who are you focusing on? In reality, you will have IT services defined for each type of customer so your service catalog should enable you to display different services and service types based on role.
* IT Customer
* Business User Customer
* Business Unit Customer
* External Business Customer
Troy’s Thoughts, What Are Yours?
“The Total Perspective Vortex, in the fictional world of Douglas Adams’s The Hitchhiker’s Guide to the Galaxy, is the most horrible torture device to which a sentient being can be subjected. Located on Frogstar World B, it shows its victim the entire unimaginable infinity of the universe with a very tiny marker that says “You Are Here“ which points to a microscopic dot on a microscopic dot….....
Thursday, January 03, 2008
Automation Is The Key To Managing Complexity
A key strength of the ITIL framework is the fact that it gives us an integrated process model for delivering and supporting IT Services. It provides insight and guidance into the fact that processes have direct and indirect inputs and outputs to each other. This logical integration makes sense when read in print, but becomes overwhelming to keep in the forefront of your mind when you are faced with the daily task of managing an IT operation.
One of the most compelling reasons to adopt and implement a formal process within an organization is when you realized that the complexity of your support environment can no longer rely on tribal knowledge and best effort service levels when dealing with the delivery and support of business critical IT services. The same argument can be used for the necessity of using integrated IT service management systems over simple tools such as email or excel spreadsheets. In time simple tools no longer provide the support you need for your processes.
In my personal opinion you can’t even get close to the level of process integration and efficiencies ITIL describes without an investment in an IT Service Management tool that focuses on integration of key processes over a best of breed approach for a single process. However, based on a historical approach of buying best of breed we have a tendency to select the best hammer in the market when our overall needs would be better suited by a reasonably priced multi-function tool.
To provide an example lets examine a use case scenario of automating a SLA.
- You have set targets for service restoration and published them to your clients
- You have defined and established an enterprise IT policy and Operational Level Agreement for Prioritization (The Practicality of Prioritization)
- You have implemented an IT Service Management tool that supports Incident Management and is integrated with a CMDB
- The tool that you are using has a common business rule engine across process modules that enables automated assignment, escalations and notifications through email or paging systems.
Ok with these assumptions lets play through a support scenario:
Step 1: The Phone Rings At the Service Desk and A User Reports That An Application Service Is Not Available.
Using a set of general questions the service desk agent determines and records the Impact (scope) and Urgency (time sensitivity) of the call. The Service Desk agent will also do their best to classify the incident record by business service and technology failure based on the information they gain from the caller. (Its Classified)
This initial classification combination of what has failed and the relative Impact and Urgency establishes the Incident priority and the initial SLA target that will have a pre-defined set of of time and role based escalations and notifications automated by the business rule engine.
However there is more!
Step 2: Assigning The Person Record and Impacted Organization to the Incident Record.
We now have to consider that not all people are equal when it comes to support and service level agreements. People also have records in the IT Service Management tool with attributes that describe who they are, the function they play within the organization and their relative importance to the business. (role or position)
This means that each person record can have its own SLA target associated to either the organizational group they belong to or attached to their personal record. The tool that you are using should be capable of assigning a unique SLA target to the person record that once associated to the Incident record overrides the initial SLA target if the VIP status of the person or organization in question requires a faster or higher level of service.
Were not done yet!
Step 3: Attaching A Configuration Item (CI) Record From the CMDB to the Incident Record
One of the most basic things that an integrated CMDB will support is the ability to attach a CI record to a workflow record such as an Incident, Problem, Release or Change record. In terms of this article a key reason why this is important is that just as people are not equal relative to IT support, neither are CIs.
Consider the common example of a server that hosts various applications. It is probable that the various applications hosted on this server have different levels of business criticality and for that reason have different Service Levels assigned to them. However, the server in question hosts them all so what SLA would you attach to that component? The answer of course is that it has to inherit the highest SLA of the various services it supports. This means that the server itself can also be assigned its own SLA through either inheritance from the application service or direct SLA association.
Now when you attach the CI record to the Incident record it compares the SLA target it carries to the one from the initial classification in step 1 and potentially overrides the initial SLA target with its higher level target just as we observed with the person record.
As I mentioned earlier this may seem logical in print. However trying to keep all of this in mind when you are under fire in the trenches of IT support is practically impossible. This level of complexity truly requires automation, but before you can automate escalations and notifications to support SLA targets as I have described you need to define them on paper and get agreement to them first.
Troy’s thoughts, what are yours?
Complexity that works is built up out of modules that work perfectly, layered one over the other. ~Kevin Kelly