As the new analyst for The ITSM Review, I was presented with the objectives and characteristics of the role – namely that of The Curious Technologist.
As I embark on this odyssey, I want these articles in particular to be a little more anecdotal in nature, as this subject can be as dry as toast (see what I did there?)
I landed in the world of ITIL back in 2005, when bids were looking for my organisation to demonstrate ITIL alignment and revolved around seemingly holy grail of Configuration Management
A simple gallop around potential contacts in the geographic regions, and within the various departments showed that everyone had their own ideas of what Configuration Management.
There was actual configuration setups of machines, to the rigidly adhered to ITIL descriptions in the book.
Welcome… to Jurassic Park!
Perhaps my favourite, certainly for Configuration Management was the ‘Jurassic Park’ principle.
Ask any technical group what their discovery tool does, and you will receive the most complex, macro-ridden spread-sheets with all manner of data widgets that can be scanned.
Trying to change the mind-set of technical folk to focus on configuration item data that is relevant is a challenge.
In the film, as the main protagonist, John Hammond, is smugly announcing his plans to literally unleash recreated dinosaurs on the unsuspecting tourist public, a mathematician specialising in chaos theory sets him straight.
Sparring from the start, the character of Ian Malcolm chides him for taking work that others have done, and just taking that extra (terrifying) step.
Sometimes technicians, to paraphrase the character of Ian Malcolm, are: “… so preoccupied with whether or not they could, they didn’t stop to think if they should.”
Whilst maybe not as (fictionally) fatalistic, this is true when we looked at the depth of scan-able data versus what is actually required to make Configuration Management achievable.
The next logical step was to analyse the list of discovered widgets but to ask two key questions:
How frequently is the data element scanned?
How current is it kept and used as part of another process?
Not surprisingly, a lot of things are scanned once, and never once referred to again, or even updated again.
The linkage with Change Management in particular proved to give us the grounds to define the “highest” common denominator, which is the most typical configuration item to be affected in a change.
And therein lay the basis for our definitions (in this case) on standards.
“Here in my car, I feel safest of all…”
Perhaps my most constant analogy of all was one that was taught to me as I was preparing for my first billable project.
In moving to a new role recently I was fortunate enough to be working on a different service desk tool, and indeed my late career was often spent moving clients from one tool to another.
There is no real difference in the raison d’être of a tool – it exists to take a ticket from the start of its life-cycle journey to another.
Processes are the fuel that will drive that engine – but essentially a ticket is opened, it is assigned, it is resolved or closed.
Not unlike a car.
I could give anyone of you the keys to my car and with a few moments of familiarisation someone could drive it away.
Simplistic analogy? Yes.
But it is often a necessary first step in detaching recipients from their emotional attachment to whatever tool is being replaced.
Welcome to… The Curious Technologist…
A lot of these articles may well be anecdotal, but in my years of watching some of the best consultants at practice, the ability to boil down a complex requirement or approach sometimes requires a more simplistic touch.
After all, if the prospect of moving to a new set of tooling meets with barriers straight away, then how will the deployment ever move forward?
Sure, the use of film lines or pop culture may cause me more amusement than my audience, it does bring a mechanism to channel people’s thoughts along a different line, which is vital in the complex environment we often work in.
We are looking at railways (railroads) as a useful case study for talking about service management.
What is the service catalogue of a railway?
If you said the timetable then I beg to differ. If you said one-trip, return and monthly tickets I don’t agree either.
The menu analogies we see all the time when talking about service catalogue are misleading.
A menu (or timetable) represents the retail consumer case: where the customer and the user are one. In many scenarios we deal with in business, the one paying is not the one consuming.
The service catalogue describes what the customer can buy. The request catalogue is what the user can request. Consider a railroad cook-wagon feeding a track crew out in the wilds: the cook decides with the railroad what to serve; the staff get a choice of two dishes.
The cook’s services are:
Buying and delivering and storing ingredients
Mobile cooking and eating facilities
Serving food onsite
That is the service catalogue. The railway can choose to buy some or all of those services from the caterer, or to go elsewhere for some of them.
The menu is a service package option to the “cooking food” service. The railroad chooses the options based on cost and staff morale. The menu gives staff the illusion of choice.
First and foremost, a service catalogue describes what a service provider does. How often and what flavour are only options to a service or package of services. A railway’s service catalogue is some or all of:
Bulk goods transport (especially coal, stone and ore)
Less-than-container-load (parcel) transport
Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
Door-to-door (trucks for the “last mile”)
Dangerous goods transport (the ethanol delusion generates huge revenues for US railroads)
Large loads transport (anything oversize or super heavy: huge vehicles, transformers, tanks…)
Rolling-stock transport (railways get paid to deliver empty wagons back their owners)
Finance (a railway can provide credit services to customers)
Accommodation (big Indian stations all have dormitories and rooms)
Tours and entertainment (party trips, scenic trips, winery trips…)
Land cruises (just like a cruise ship but on rails)
Bulk goods storage (railroads charge companies to hold bulk materials in wagons for them awaiting demand: they provide a buffering service)
Rolling stock storage (in the USA railroads make money storing surplus freight wagons for other railroads)
Rolling stock repair (railways repair private equipment for the owners)
Private carriage transport (in many countries you can own your own railroad carriage and have the railway carry you around; a fantasy of mine)
Property rental (many large railways are significant landlords)
Where’s the timetable or ticket pricing now? It has such a small part in the true scope of a railway’s services as to be trivial. More to the point, it is not a service: tickets are request options associated with one of many services. Users don’t request a service: “I’d like an email please”. No, they make a request for an option associated with a service: provision email, increase mailbox, delete account, retrieve deleted email etc…
People confuse their personal consumer experience with business: they try to apply consumer experience models to business processing. Most customers don’t want a service catalogue “to look like Amazon”. They want meaningful business information. The best vehicle for that is usually a text document. The users/consumers of a service(s) may want to see the requests associated with that service(s) in an Amazon-like interface. Sometimes there may even be a valid business case for building them a groovy automated request catalogue, but it is not the service catalogue.
The service catalogue defines what we do. It is not simply an ordering mechanism for customers. That is that personal/business thing again. A service catalogue has multiple functions.
Yes it is a brochure for customers to choose from.
It also provides a structure to frame what we do as a service provider: availability planning, incident reporting, server grouping… Once we have a catalogue we find ourselves bring it up in diverse contexts: “we see the list of services show up in the table of contents”.
It is a reference to compare against when debating a decision
It is a benchmark to compare against when reporting (especially the service levels, but not only the service levels)
It becomes a touchstone, a rallying point, an icon, a banner to follow. It brings people back to why we are here and what we are for as an organisation.
You don’t get that from Amazon.
Then we come to that endless source of confusion and debate: technical service catalogue. That deserves a whole discussion of its own, so we will look at it next…
Editor’s Note: We are very pleased to welcome Rob England (a.k.a The IT Skeptic) as regular columnist at The ITSM Review.
Railways provide a useful analogy for understanding what service management is and how it works.
What is a railway for? (or “railroad” for our American readers)
If you said “to move people and/or goods” you are only partly right. On the right track (pun intended) but not there yet.
How should it move goods and passengers? With maximum quality? Or at minimum cost? The answer to that is “it depends”. It depends on what the customer wants.
A customer is one who pays for the service of the railway. That isn’t always the same as the one who buys the ticket or books the freight. Many railways receive public funding, so the government or other body is effectively also a customer: they are paying for part of the service. Not all customers are users of the services.
The railway is answerable not only to its customers. It is also answerable to its owners and the governors they delegate authority to. The owners may not want the same things as the customers at all. For example, railways are often required to provide a passenger service as a requirement of gaining the right to operate. These passenger services are often unprofitable: the money is in the freight services. Guess how often such passenger services meet the needs of the paying ticket-holders.
So a railway exists to provide a service that moves people and/or goods to meet the needs of its governors and customers.
Your are in the service business
If you were operating a railway, what activities would you have to manage in order to ensure you meet the needs of your governors and customers? There would be some activities that are unique to railways, such as scheduling, servicing rolling stock, dispatching trains and so on. But the bulk of the activities involved in operating a railway are the same as operating any business: reporting, financials, HR, marketing, IT, procurement… and delivering your services. It doesn’t matter whether an organisation’s services are transporting goods, providing accommodation, building houses or catching fish. They all serve customers and they all perform a similar set of activities to manage that service.
Whether you build roads or map them, operate ports or use them, build houses or sell them, plan weddings or sing at them, care for kids or clothe them, sell PCs or scrap them, you are in a service business, even if you may not be in a “service industry”.
We aren’t talking about over-the-counter “may I help you?” service, how to develop the customer service interface, the experience of contact. Service Management is about the end-to-end process of providing services. It covers such things as:
Service management activities
Executing a service for users
Food service, engine drivers, shunters
running the infrastructure that makes the services work
Signaling, track maintenance, security guards
Responding to user requests for service or help, and resolving them
Ticket sales, call centre, guard, repair crews
Providing information about what services are available
Timetables, websites, brochures
Maintaining relationships with customers
Customer account managers, sales, public relations
Monitoring and reporting service metrics
Punctuality, traffic volumes, profitability
Proposing, choosing and strategising new services, improvements and retirements
Routes, trains, schedules, freight deals, specialised cars e.g. refrigerated)
How the service will work, what infrastructure it needs
Developing anew schedule, specifying new equipment
Creating the infrastructure, mechanisms, and processes to deliver a service
Ordering or constructing new rolling stock, laying track, hiring and training staff, printing collateral
Rolling out the new service, going “live”
Commissioning new rolling stock, publishing new or changed schedules, deploying staff, rolling trains
Protecting the organisation, its staff, customers and users. Making sure the service is safe for people, compliance and profits.
Direct, monitor and evaluate the management and execution of the services
Corporate vision and goals, high-level policy, risk profile, annual report
Service Management says the most important thing you do is deliver services to your customers. Moreover, everything you do should be considered in terms of the services you provide to your customers.
Adopting a service management approach can have a profound affect on the way your business works and your staff think. It takes us away from that introverted, bottom-up thinking that begins with what we have and what we do and eventually works its way up and out to what we deliver to the customer. Instead, with service management we change our point of view from concentrating on the internal “plumbing” of our business, moving instead to a focus on what “comes out of the pipe” – what we provide. We take an “outside-in” view. Starting from this external perspective we then work our way top-down into the service organisation to derive what we need and what we have to do in order to provide that service.
Service management isn’t one subset of the business; it is not one activity at the end of the main supply chain. It is a different way of seeing the whole supply chain, the whole business that produces the services, by seeing it initially from the outside, from the customer’s point of view. Therefore any discussion of Service Management may stray into general business management topics.
Seeing our business in terms of the services it provides can’t help but make us better at providing them.
To a customer, “better” means more useful and more reliable, i.e. more valuable and better quality.
From the service-provider’s point of view, “better” means more effective and more efficient, i.e. better results and cheaper.
Follow along in this series of articles as we look at Service Management through the lens of railways and how they operate. We hope it will provide a fun and useful way to understand this thing called Service Management.
In my previous piece for The ITSM Review, I examined the state of general dissatisfaction with ITSM tools at the moment.
In doing so, I wanted to question why a positive dedication to “process” should be at the heart of how organisations solve complex (and simple for that matter) IT services challenges. This time around, I want to look at the human element of process.
The new ABC
ABC (for the purposes of our story here) stands for Attitude, Behaviour and Culture — basically, this sets out to ensure that the human aspect of ITSM and service delivery matches that of the IT implementation.
One area that can help ITSM professionals today is to look at their approach to ABC in a new light, based on understanding the wider processes that are in place.
Re-evaluating processes gives ITSM teams the opportunity to look at their own ABC successes and issues again. It also represents a chance to examine how these ABC milestones can be used to improve wider service within the organisation. Without the right elements in place, those individuals working on the service desk may not be able to deliver what the business expects and requires of them. More importantly, changes within the organisation won’t be successful.
ABC is equally important when it comes to inter-team communication, as the hand-off between teams can be affected by differences in approach and behaviour. If one team is performing well on its own terms, but its output goes through another group with motivational challenges or a different work method, then the initial team’s work may be viewed as not meeting the overall requirements of the business.
The release management black hole
This can be seen in the ITSM world when an application implementation is not completed successfully across to the complete scope and breadth of the organisation. The application itself has been written to specification, thoroughly tested and was ready to go — but the team responsible for managing help-desk calls may see a massive spike in users getting in touch. In this example, the release management process has not been completed successfully, which leads to issues getting raised with the help-desk team and poor perception of IT in general.
Nothing was wrong in the development phase and the ITSM function can provide a great level of service — however, what users remember is that there was a problem in the first place.
In the user’s mind, IT is seen as being one complete unit, yet this is not often the case. Most teams within large organisations are broken down into project and technology teams, depending on how they have evolved over time. Responsibility is split across these different teams and each can have its own approach to managing work based on how it is led.
Achieving some kind of level of “unity of approach” and getting each part of IT to buy into a common set of values is a significant challenge. The responsibility for this should sit with the CIO as part of their leadership role. As business requirements change and IT has to evolve to support new demands, so getting the right processes in place to complement the right ABC is therefore critical. Changing or amending behaviour at the individual level relies on how much people buy into what is being put in place at the process level, too.
Process and ABC: a two-way street?
On the individual attitude and behaviour front, there has to be an understanding across the IT team responsible for delivering a service of how their section fits into the wider business process. This can be as simple as letting each individual know how their work contributes towards a key performance indicator or meeting a service level. For organisations that already have some degree of joined-up processes, the information given back to people can be much more granular.
At the same time, this emphasis on process can be used to remove manual work where it is possible to take it out. In the example above, automating the release of an application that has been developed and tested properly, rather than relying on ad hoc scripting and manual labour, could remove the potential for things going wrong. Not only does this speed up the process overall, it also makes the whole IT team concerned with that installation appear to be part of a uniform and co-ordinated strategy to the business.
For organisations with ABC challenges, looking at “process hand-overs” between teams is the simplest way to evaluate where these problems start and why. Is this an issue with an individual, a team or with the wider IT function within the organisation? Depending on the level at which the problem is occurring, this will change how the ITSM team looks at their processes in a new light.
The attitude and culture that a company has in place will have an impact on the overall process that is being completed — if employees feel valued and trusted, then they are more likely to care that the results of their work are good. At the same time, design of a process can affect ABC as well — a well-designed process that is fit for purpose, automated where it needs to be, and running well should support employees in achieving job satisfaction.
The business-to-IT connection challenge
One of the most common complaints around IT is that it does not match up with the business. Traditionally, IT has been separate to business functions based on the availability of the skills that were required to understand and run the technology department. This is changing with the advent of cloud computing and the growing understanding of IT within the business itself. But whether organisations want to embrace a cloud computing approach or not, the fact is that ITSM professionals have to realise that their service delivery is being judged against a different yardstick. Whereas previously, IT operations and services would be based on what direct competitors are doing, now it is more likely that the business will look at what consumer websites and portals are able to deliver.
This change in emphasis and the need to keep pace with what the business expects from IT, makes looking at ABC more important than ever. Service providers have the mantra in place that “the customer is king” – even when they either don’t know what they want, or are actively looking at the wrong approach. For ITSM, this means looking again at their attitudes to managing users and where this may have to change in future. As cloud continues to attract interest, IT will have to learn lessons from the service provider world.
Managing ABC in this environment should theoretically be easier — after all, IT and the business are both part of the same company. However, there can be this barrier between the two that has to be broken down. If it is not, then IT risks either remaining as a support function with little value, or instead being replaced with outside tools and services instead. This would do ITSM a grave disservice, as it should be obvious that internal IT teams have not only the interest of the organisation at the front of their minds but also the most in-depth knowledge of what the business really requires. What does have to change is that understanding of service delivery from the business perspective.
Hand in hand with this ITSM imperative is the need to get the business function’s perception of IT to change. The attitude and behaviour of the business towards IT is just as important as IT’s own ABC i.e. without the willingness to embrace IT as a strategic part of the corporate decision making process, there can be no real change in approach across ITSM. IT can aim at being customer-centric as much as possible, but if the IT team is not involved in the decision-making process from the outset, then this will remain a largely unfulfilled ambition.
Analysing the role of IT across the business process is the best way to achieve the much-needed inclusion that we must achieve here, alongside aligning the culture of the IT team with that present across the wider organisation. By understanding how work goes through the business and the ITSM resources required to support that flow, IT can claim its place at the table.
“Gamification is the concept of applying game-design thinking to non-game applications to make them more fun and engaging.” http://gamification.org/
The logic states that generations of IT workers have been weaned throughout their youth on video games, so game-like features can be introduced to the workplace to increase employee engagement and satisfaction.
In ITSM terms this means being awarded points, badges and appearing on leader boards based on specific service desk actions.
There is much talk of Gamification in the ITSM industry (Gartner plots ‘Gamification’ hype at near peak) – but is Gamification simply marketing hysteria or a real force for change?
Firstly, I believe something smells a bit fishy about conditioning employees to beg, roll and fetch for coins and stars like Pavlov’s dogs. Shouldn’t the work itself be rewarding and fulfilling? But existential angst aside, I think it is a smart idea if implemented correctly and a great opportunity to inject a bit of fun into everyday working life.
Two examples of game mechanics in action stand out from my working career. Both were a similar format with similar goals – one went very well and one went horribly wrong. If I were to pinpoint the difference between success and failure of these two games – it would be the respect staff had for the boss. I don’t think game mechanics can be implemented as a Band-Aid for poor morale and poor performance. It takes the right spirit and the right manager.
InvGate claims the benefits of gamifying the service desk include great team engagement, increased productivity, increased team collaboration, and aligned objectives.
An important point in the InvGate offering is the ability to reward service desk agents, in a fairly automated fashion, based on perceived quality by users.
These rewards are not based on banal ITSM metrics but by ‘likes’, ‘thumbs ups’, ‘stars’ and other simple measures of user satisfaction (Social concepts that users are likely to be increasingly familiar with outside of work). Never mind first call resolution time – was the user HAPPY?
The most powerful aspect of this for a manager, assuming she has her team onside and playing along – is the ability to align quickly with business goals. Even the largest of service desks can quickly focus on tactical campaigns with a high degree of engagement from agents. Good-bye Service Desk Manager, hello Game master.
A cool offering from InvGate, I’m looking forward to delving further – further info here.
itSMF UK Seminar – Service Catalogues & Service Portfolios
“Service catalogue, service portfolio and service level management are the essential elements of the relationship between IT and the business. Without these processes in place, it is increasingly difficult to define what IT services are available to the business and on what basis.
But the relationship between service catalogues and service portfolios is often poorly understood, and this can lead to confusion and misunderstanding. This seminar explains how these concepts inter-relate, and helps attendees to build a solution that suits their specific business needs. “Problem management is often the most under used process, and is described by some as the “If we only have the time” process. In reality it is a process that if used correctly adds real value to the business, and supports all of the other service management processes. To get there, there is a need to invest both time and resource – the very things that problem managers have little of.”
Wednesday 18th April 2012, 9am – 4pm
The National Motorcycle Museum, Coventry Road, Solihull, West Midlands, B92 0EJ
Service catalogue – all things to all people?Not only is the service catalogue a way to orientate your organization and processes around services, it is also a user facing service itself. This is Unilever’s experience of delivering a user-friendly catalogue that is part of improved customer satisfaction. ~ Andrew Davies, Unilever
Unlocking the potential of service portfolios and service catalogues, and measuring the right thing This presentation will destroy some myths, make you think differently, and give you the tools to continually improve both IT and the business by integrating portfolios, catalogues and measures. ~ Kevin Holland, UK Public Sector Consultant.
Magic wand session: Service catalogues and service portfolios in your organizationTake part in one of our interactive round table discussions, led by Dr Don Page of Marval, and discuss the answers to some key questions concerning service catalogue and service portfolio implementation. ~ Don Page, Marval
The service portfolio – the new tool in your service management toolset Just when you have finally understood the concept of the service catalogue and managed to produce a useful addition to your service management toolset, along comes ITIL v3 and the service portfolio. What is it, how does it help us? This presentation will give you some answers. Rob Young, Fox IT
The UK has 4.5 million SME companies that account for 58.8% of all private sector employment in the UK and 48.8% of private sector turnover (source).
I have used UK figures here but my bet is that the vast majority of countries have a similar balance – perhaps even more so in developing countries.
Similarly, teams or divisions within larger organizations are breaking free of the shackles of prehistoric software and taking IT support provision into their own hands.
With this is mind I have compiled a short list of companies offering IT helpdesk software offering an entry level for under a grand. All the offerings below are web-based (do start ups and small companies buy servers?).
Conditions of inclusion
Under US$1,000 per year per user
Pricing is readily available on their website
Delivered via the Web
The website is not scary
If I have missed any companies that meet the criteria above please leave a comment below. Thanks in advance for your help.
Recently I’ve been working on Incident Management, and specifically on Major Incident planning.
During my time in IT Operations I saw teams handle Major Incidents in a number of different ways. I actually found that in some cases all process and procedure went out of the window during a Major Incident, which has a horrible irony about it. Logically it would seem that this is the time that applying more process to the situation would help, especially in the area of communications.
For example in an organisation I worked in previously we had a run of Storage Area Network outages. The first couple caused absolute mayhem and I could see people pushing back against the idea of breaking out the process-book because all that mattered was finding the technical fix and getting the storage back up and running.
At the end of the Incident, once we’d restored the service we found that we, maybe unsurprisingly had a lot of unhappy customers! Our retrospective on that Incident showed us that taking just a short time at the beginning of the outage to sort out our communications plan would have helped the users a lot.
ITIL talks about Major Incident planning in a brief but fairly helpful way:
A separate procedure, with shorter timescales and greater urgency, must be used for ‘major’ incidents. A definition of what constitutes a major incident must be agreed and ideally mapped on to the overall incident prioritization system – such that they will be dealt with through the major incident process.
So, the first thing to note is that we don’t need a separate ITIL process for handling Major Incidents. The aim of the Incident Management process is to restore service to the users of a service, and that outcome suits us fine for Major Incidents too.
The Incident model, its categories and states ( New > Work In Progress > Resolved > Closed ) all work fine, and we shouldn’t be looking to stray too far from what we already have in terms of tools and process.
What is different about a Major Incident is that both the urgency and impact of the Incident are higher than a normal day-to-day Incident. Typically you might also say that a Major Incident affects multiple customers.
Working with a Major Incident
When working on a Major Incident we will probably have to think about communications a lot more, as our customers will want to know what is going on and rough timings for restoration of service.
Where a normal Incident will be handled by a single person (The Incident Owner) we might find that multiple people are involved in a Major Incident – one to handle the overall co-ordination for restoring service, one to handle communications and updates and so on.
Having a named person as a point of contact for users is a helpful trick. In my experience the one thing that users hate more than losing their service is not knowing when it will be restored, or receiving confusing or conflicting information. With one person responsible for both the technical fix and user communications this is bound to happen – split those tasks.
If your ITSM suite has functionality for a news ticker, or a SocialIT feed it might be a good idea to have a central place to update customers about the Major Incident you are working on. If you run a service for the paying public you might want to jump onto Twitter to stop the Twitchfork mob discussing your latest outage without you being part of the conversation!
What is a Major Incident
It is up to each organisation to clearly define what consitutes a Major Incident. Doing so is important, otherwise the team won’t know under what circumstances to start the process. Or you might find that without clear guidance a team will treat a server outage one week as Major (with excellent communciations) and not the next week with poor communications.
Having this defined is an important step, but will vary between organisations.
Roughly speaking a generic definition of a Major Incident could be
An Incident affecting more than one user
An Incident affecting more than one business unit
An Incident on a device on a certain type – Core switch, access router, Storage Area Network
Complete loss of a service, rather than degregation
Is a P1 Incident a Major Incident?
No, although I would say that every Major Incident would be a P1. An urgent Incident affecting a single user might not be a Major Incident, especially if the Incident has a documented workaround or can be fixed straightaway.
Confusing P1 Incidents with Major Incidents would be a mistake. Priority is a calculation of Impact and Urgency, and the Major Incident plan needs to be reserved for the absolute maximum examples of both, and probably where the impact is over multiple users.
Do I need a single Incident or multiple Incidents for logging a Major Incident?
This question might depend on your ITSM toolset, but my preference is to open a separate Incident for each user affected in the Incident when they contact the Servicedesk.
The reason for this is that different users will be impacted in different ways. A user heading off to a sales pitch will have different concerns to a user just about to go on holiday for 2 weeks. We might want to apply different treatment to these users (get the sales pitch user some sort of service straight away) and this becomes confusing when you work in a single Incident record.
If you have a system of Hierarchical escalation you might find that one customer would escalate the Major Incident (to their sales rep for example) where another customer isn’t too bothered because they use the affected service less frequently.
Having an Incident opened for each user/customer allows you to judge exactly the severity of the Incident. The challenge then becomes to manage those Incidents easily, and be able to communicate consistently with your customers.
Is a Major Incident a Problem?
No, although if we didn’t have a Problem record open for this Major Incident I think we should probably do so.
Remember the intended outcome of the Incident and Problem Management processes:
Incident Management: The outcome is a restoration of service for the users
Problem Management: The outcome is the identification and possibly removal of the causes of Incidents
The procedure is started when an Incident matches our definition of a Major Incident. It’s outcome is to restore service and to handle the communication with multiple affected users. That restoration of service could come from a number of different sources – The removal of the root cause, a documented Workaround or possibly we’ll have to find a Workaround.
Whereas the Major Incident plan and Problem Management process will probably work closely together it is not true to say that a Major Incident IS a Problem.
How can I measure my Major Incident Procedure?
I have some metrics for measuring the Major Incident procedure and I’d love to know your thoughts in the comments for this article.
Number of Incidents linked to a Major Incident: Where we are creating Incidents for each customer affected by a Major Incidents we should be able to measure the relative impact of each occurance.
The number of Major Incidents: We’d like to know how often we invoke the Major Incident plan
Mean Time Between Major Incidents: How much time elapses between Major Incidents being logged. This would be interesting in an organisation with service delivery issues, and they would hope to see Major Incidents happen less frequently
There you go. In summary handling Major Incidents isn’t a huge leap from the method that you use to handle day-to-day Incidents. It requires enhanced communciation and possibly measurement.
Kylie Fowler is a regular columnist for The ITSM Review, see previous articles from Kylie here.
It’s not often that most people get to experience a true paradigm shift, even in IT where change is endemic and part of the lifeblood of the industry. However there is no doubt that cloud computing and the commoditization of processor power and storage represent a true metamorphosis in the way we think about and structure IT services.
Cloud computing is actually the next step in a long series of IT developments which have promoted the decentralization of computing in businesses. The gradual decentralization of corporate IT can be tracked from highly centralized mainframes with their bespoke software, through the development of client server computing, the commoditization of software and finally, with cloud computing, the commoditization of processor power. This shift will have dramatic implications for how and where IT professionals will carry out their roles in future,
Right back at the beginning of corporate IT (in the dark ages known as the 1970s) computing power was served up from giant mainframes to users sitting at dumb terminals who carried out business functions using highly centralized in-house applications. Believe it or not, some of these old systems, developed on punch cards by engineers are still in use today, generally because they are too expensive to redevelop on a more modern platform, or the risks of doing so are too high.
The first steps towards the decentralization of IT came in the next era of computing, the one most of us are familiar with – the era of client-server computing. Significantly lower processor costs mean that processor power can be co-located with users (although largely separated from storage to ensure data security), while large clusters of servers provide basic services such as network access and email. For most businesses, day to day IT operations are still architected, managed and controlled within the organisation, albeit on highly commoditised hardware. In contrast, software has been largely commoditised, with powerful software publishers selling software for use under license. Complex applications are still modified in-house to meet corporate needs, but the underlying intellectual property is owned by the software vendor. This is the era of Microsoft, Oracle and SAP.
However we’re gradually moving into a new era, where the configuration and day to day management of hardware, software and the actual processing of bits and bytes are moving out of the corporation altogether. More and more organisations are asking themselves whether it is really cost effective to host basic services like email or word processing or spreadsheet analysis in-house when high quality services are available on-line for minimal cost.
Don’t get me wrong, there will always be servers and desktops and laptops, just as there are still mainframes, while large organisations may decide to develop private clouds to take advantage of economies of scale while reducing the risks inherent in trusting data to a third party, but the paradigm shift, the change in the computing world view that we are experiencing at the moment, is every bit as profound as the shift from mainframes to client-server computing was 20 years ago.
So what will the impact of this paradigm shift be for real people like you and me? Here are some of my predictions.
Service Operations will migrate out of the business
The essence of cloud computing is that what we have traditionally thought of as ‘IT’ has become a commodity. Most companies will no longer find they have a requirement for staff who can build a PC or a server as this requirement will have either been outsourced, virtualized or hosted on the cloud. But as is the case for mainframes, there will always be the odd niche where techies will thrive, so don’t despair!
Despite the growing importance of the actual connection to the cloud, network operation skills will also be outsourced, despite the fact that a secure, robust network to access cloud services will be even more critical than it is now.
Service Strategy and Service Design will become the core competence of IT Departments
The main business of IT is providing services that meet the needs of the business, but the new world of the cloud means most of those services will actually be provided by external companies. Logically, then, the core function of an IT department will be to decide HOW to provide the services to the business. Questions for Service Strategists and Designers will include: Which services do we put on the cloud, and which do we keep in house? How will we ensure there is a seamless blend between the two? Which services should be provided as a unit, and which can be provided be different suppliers? How do we manage our suppliers to ensure they work together to ensure effective provision of all the services we need?
Service Transition will be vital for keeping suppliers on their toes
One of the biggest risks inherent in cloud computing is the danger of being locked into poorly performing, costly services which are either too risky or too expensive to escape. Service transition skills will be critical in keeping suppliers on their toes by giving management the confidence that it is possible to walk away if the service isn’t up to scratch while ensuring that new services are up and running as quickly and smoothly as possible.
Peripheral skills will move to the core
Areas which are currently considered peripheral to the operation of an IT organisation will become more prominent. The ability of Strategic Procurement to negotiate contracts that create value and minimise costs and risks will determine whether IT brings competitive advantage to the business, or, at the opposite extreme, becomes a costly white elephant that reduces productivity. IT Vendor and Asset Management will focus on ensuring the business achieves the value it expects from its Service Providers and will manage the fall-out when things go wrong, while Information Security will become more akin to Business Risk Management, assessing information risks and ensuring safeguards are in place to protect the organisation’s reputation.
How to survive the coming change?
The move to cloud computing resembles the slow grind of tectonic plates rather than a sudden tsunami devouring everything in its path. As with the movement of the continents, the shift to cloud computing will be slow but both inevitable and unstoppable. There will be the odd earthquake, of course, devastating for those on the fault line, but many people will find it has no major effect on their careers, and in some instances, may even enhance them.
IT folk are inured to change, but it has to be said that many of us lack flexibility. Be willing to shift sideways, or into a different industry (or onto the cloud itself) and be open to alternative ways of using your existing skills – perhaps move into consultancy or (shudder) sales. Broaden your skills base and see continuous professional development as a fundamental part of your working life – on a par with your morning commute or annual review.
Develop your soft skills, particularly communication. It’s hard to be a consultant, for instance, helping organisations change, unless you can communicate effectively and work with a wide range of people on many different levels.
Make it your business to understand the business. IT exists only because it offers businesses competitive advantage. The higher the competitive advantage provided by IT, the higher the rate of investment – you just need to compare the level of investment between the Finance and Construction industries to see clear evidence of that! Understand how IT offers your business competitive advantage and make sure your work supports this. If the business asks you to change because you are no longer helping it succeed, then change!
Find a niche. There are still jobs out there supporting mainframes, and there will always be jobs maintaining server based in-house applications. The jobs will be limited, but if you find a niche or have an obscure skill that a particular company can’t survive without, then the rest of your career could be very comfortable indeed. But don’t forget to be flexible! If your bosses out-source 90% of the niche jobs to India, it will be your ability to manage the outsourcer effectively that means you keep your job!
It’s an exciting time to be working in IT, and although some people will suffer from the shift to the cloud, I am optimistic that the old Chinese proverb ‘may you live in interesting times’ will turn out to be a blessing rather than a curse for most IT professionals.
Note: if you are interested in reading more about the impact of the shift to the cloud, the Silicon.com website has an extensive special feature on the impact of the cloud which can be accessed at the link below.