What are the reasons for companies not adopting full ITIL framework?
Need advice/suggests from SMEs, whether ITIL V3 EXPERT Certification worth doing it ???
(Considering the fact, its very Expensive one)
Geoff, you asked "Does BYOD fit with ITIL 2011?"
How could it not fit?
ITSM essentially is infrastructure-agnostic, and ITIL describes a number of best ITSM practices (although the ITIL critics are more and more asking for proof).
IT service management is essentially about managing the way the IT organization works, and it most often has (or at least should have) a focus on processes. The comment of many that ITIL v2 was "all about processes" and ITIL v3 was about the service lifecycle is fundamentally biased by the phenomenon that people always seem to run away from something they can't get their fingers behind. And 'processes' is a concept that has largely been missed by ITIL. Which essentially is not a criticism because ITIL is defined by its makers as a set of best practices...
I think this still holds - for the time being. ITIL 2011 has more infrastructure than any previous version: cloud, job scheduling, backup/restore, print and output management, server and mainframe support, network management, storage management and management of databases, middleware, desktops and internet technologies. If ITIL 2012 (2013? 2014?) continues to develop along this road - and an increasing infrastructure focus plus fast changing infrastructures will force it in that direction - the link between ITIL and ITSM will be weakened.....
Oh well, maybe that's evolution.
Great paper, Karen! It carefully considers all of the ITIL processes and their relationship with BYOD.
You might be interested in a paper I wrote some time ago on "BYOD and ITSM".
Enjoyed reading your post Derek, ofcourse Service Management and Lean can go hand-in-hand. Some times very easily.
Soon after Y2K, Baan Customer Service & Support (CS&S) used Lean Principles to transform itself and its processes and deliver very high customer satisfaction. This was when ITIL was still in its early days and still not very well known.
Baan CS&S had a global network of service desks, processes were inconsistent, metrics were not standard, the tools were rudimentary, quality of new versions and releases was an issue, and ofcourse there were issues manifesting themselves in support from implementations that were less than optimal - resulting in serious and widespread customer satisfaction issues.
Singapore based Robert Oh & I have outlined how these and other issues were resolved in a book titled "Strategic Lean Service". The book is essentially a case study of how this global service delivery organisation used Lean to drive organisational transformation and achieve customer satisfaction.
There were 5 pillars to the strategy :
- planning & reporting;
- human capital development;
- process improvement using Lean;
- supply chain management ie: working with development
- support infrastructure
We were keen that the lessons we learnt could be applied to others in a similar situation.
The links below will give you a chance to look inside the book to give you a greater flavour of the problem, the strategy and the implementation - particularly on the successful application of Lean Principles to IT Service Management.
Founding Director & Principal Consultant
Separating Governance from Management.
Even two disciplines encompass different activities,but in action and practical to run businesses,these two components are related and linkage as interdependence together.
In term of the other 4 COBIT 5 Principles,they mentioned quite clear about A Single Integrated Framework+A Holistic Approach and Covering the Enterprise.
So,leveraging Principle 5 is very questionable from Interdependency
I have disagreements over this all the time. We encourage support teams and our suppliers to log their own Problems and work to find a workaround or to fix immediately if they are high priority. They create a Problem record and advise the Service Desk of the open record. If an associated Incident is reported the Service Desk staff respond by linking it to the open Problem record and advising on the workaround or progress to Fix (through change of course). As we measure performance on Incident Resolution the support teams and, more importantly our suppliers, are encouraged to use proactive Problem Management as they get a head start to find the workaround or Fix before an Incident is spotted and reported. Hence maintaining up time and reducing Resolution time.
Glad to have the pdf version of the new Guide - great way to review the 2011 Edition updates.
Thanks for the book Jan.
Whistles don't blow themselves. If this petition was created to start any sort of change then who would carry it? The petitioner is anonymous and has turned correspondence off. The petition was opened in November 2011 and has so far collected two signatures. There is little conversation about this on the web, although I think Rob England's comments at http://www.itskeptic.org/somebody-spat-dummy-itsmf-international sum up the situation pretty well.
Correct answers. Well done!
Thanks to Revolution in the Head, by Ian MacDonald, an excellent book about all Beatles' songs and their origin, for reminding me of the songs of my youth and thanks to the elyrics.net website for confirmation of the actual lyrics.
If you have passed the 2005 version, then there is additional work to do, you are quite right but if you start with the 2011 it might be easier.
Of course a lot depends on the auditor,
When did any process belong to a particular function? Many incidents may get logged with the Service Desk as the first point of call by end users but I do not recall anyone saying it was a Service Desk process. That is like saying that the Change Management process belongs to a particular function such as Application Management.
In the suggested scenario James would have raised an Incident and instigated an emergency change - most likely identified as a standard change and therefore pre-approved - and just got on with the task in hand. The Service Desk could continue to discuss and hopefully find the meaning of apophenia.
Fun challenge, here goes:
1. Here Comes the Sun
2. Getting Better
3. Paperback Writer
4. Good Morning
5. The Word
6. Hey Jude
hello dear moderator
I just posted a comment saying that I disagree with Aale on the fact that iso20000 has lowered the bar.
I forgot to give my name, here it is : Jean-Pierre GIRARDIN at firstname.lastname@example.org
you can add my name on the previous comment, if you wish
I fully disagree with Aale, iso 20000 has not "lowered" the bar. I know both versions of the norm, as we (Orange Business Services) have received this certificate for both versions (2005 & now 2011).
The new version has more processes (e.g. : request management), the goal of the new version was just to clarify some aspects which needed to be clarified and to better align with itil v3 (now ITIL 2011)
Anyway I encourage all organizations to go for this certification as it helps to improve our processes and our services.
Up to the challenge !
very interesting column. I am looking to develop a process assessment questionaire for our manufacturering suppliers of various commodities.
I believe the IT framework could work with some refinements.
Thank you for th einfo.
Now we're talking! And Merry Christmas to you, Roman...
Well, if "organizations can clearly have different levels of "maturity" towards the grip they have on their processes", than maturity can be mesured in the context of particular process(es). So the model I offered in the column may be valid if we replace "maturity of a process" with "maturity towards a process" or "maturity of a process governance".
The process will not be the subject of assessment in this case but will provide a context or scope for assessment of the management sysytem (or organization).
Do you find it correct this way?
You ask: "What is then the new support model?"
Does the answer have to be singular?
Although it's common information that "cookie cutter" computers are falling out of favor, some industry verticals (finance and banking for example) are driven by compliance considerations to not only standardize devices, but remove capabilities from them. Wireless cards are removed, USB ports disabled, and so on, turning them mostly into dumb terminals except when they are wired up at workers' desks. The virtual desktop, contrary to popular belief, will not be a broad solution until truly high-speed connectivity is ubiquitous.
In other places--higher education, for example, BYOD has been in place for some time, and is working fairly well, though not without challenges and risks.
The service desks in banks and universities may perform somewhat similar functions in the broadest sense, but their ways of doing business are very different, from the channels used and monitored to the importance of certain metrics to the service levels promised and delivered.
There will be many models for service and support, not one, I think, from homegrown social support to complex technical support to security-driven oversight and assistance.
Thanks for your thoughtful post.
I agree. The Incident Process could be initiated by any IT personnel, not only by Service Desk agents.
I think James should have logged an incident and assigned to himself to fix the problem.
I notice that I may have been understood as saying that the Service Desk is obsolete and must go. That was not my intention.
Of course a Service Desk will be needed, the point is that the way it works must evolve with times and the ITIL model is pretty old. We need to move beyond ITIL
Mark wrote: "..the service desk has to up its game and have more high level skilled people at front line - though this coes at a cost so business may not want this." This has been true for the last 20 years and it will not change.
The Service Desk beyond ITIL will be more open and social, it will not see itself as the only source of support but as a facilitator of support.
This area needs to be clarified. Customers' problems ("user incidents") and system failures ("real incidents") should be handled with different processes.
Liked the post....reminded me of a rant of mine some time ago; while I don't think we can really do without Incident Management I do think that Event Management should play a much more prominent role, particularly in today's virtualized service infrastructure environments...
anyway, here's the rant....
Let's Kill Incident Management...
OK, it's a Friday and I'm tired. We've had two bomb scares, the Dow dropped like a stone and I'm just friggin' cranky. So I've decided to kill the Incident Management process.
It's one process I've always hated anyway…. users are pissed, zombie-like IT staff take endless calls --- many of them for the same Incident --- and we never seem to really know what's going on anyway. Log it, assign it, and re-assign it sometime later… let's just put this bastard out of it's misery.
We're goin' to a virtual cloud environment anyway, and since we'll be provisioning new services faster than sh*t outta' a loose goose we'd better get collaboration' in real time. Generating tickets after users calls is a sure road to hell in the new word that's already upon us...
There are still people out there who insist that unless we can 'create Incidents' then "you will not be a (XYC) company standard". Why? I like traceability as much as the next guy, but at what cost? Your arm's bleeding like crazy! Don't you want a tourniquet?
Get me some DevOps dudes and get them quick!
We'll provide them with service monitoring intelligence that will enable them to establish truly collaborative management. We won't open tickets, we'll just assign events to the right person; and in many cases before the service is impacted (so screw the damned Incident!).
We'll report on real time threats, service impacts, capacity trends and bring processes like Capacity, Availability and Event Management front and center (where they belong in the new world order).
I don't need a room full of people creating, reporting and shuffling tickets (Incident tickets anyway). I need people who can understand utilization trends, early warnings and take immediate action.
If users want to open tickets, we'll open a laundry.
Let's kill Incident Management.