Very Good article,
I totally agree with the points highlighted.
Clock should tick all the time and time should be reported against all STATUS (like pending Customer/Pending Third Party/etc..).These all times should be prominently visible in Audit Log of ticket. SLA should consider Pending time due to Third Party or any Other Team however it should exclude time when ticket was pending due to Customer’s response. As correctly said, most of the time we use SLA to hide ourselves but that does not assure customer satisfaction/Expected SL Targets.
SLA should be defined keeping Customer in mind and OLA should be considered while defining SLA. I like having SLA BREACH REASON field which might have values like "Third Party Supplier Delay", “Awaiting User Response” which should justify SLA breach due to Third Party/Requestor at the same time accounting pending time. In this case, there will be Breaches , However we can use this data to do CSI and go to Third Parties and Customer asking them to improve their response time and re-visiting SLA if required.
Perhaps you should read the ITIL 2011 pocket guide. It's all in there. See http://bit.ly/xhe3Ul
Benjamin, thank you for the advice!
The points you've made are nice and practical, but why do you call it "managing human side of IT"? Do you see any specific features relevant to IT area - or even more specificaly, IT support - in this list?
This will be going to be an immense advantage for the students, it's not a pocket guide, it's a complete package...
Change is inevitable. Progress is optional :)
>> "Formal aspect:
• Clear definition of the utility of services provided" <<
The utility of a service type can be easily specified (instead of "defined") by means of the first three standard service attributes
01. Service Consumer Benefits
02. Service-specific functional Parameters
03. Service Providing Point
The service (type) warranty can be easily specified by means of the standard service attributes 04 to 12.
>> "• Clear definition of the provider’s responsibility and liability" <<
This is pretty easy, too:
The ICTility service provider is accountable & liable for rendering each & every triggered ICTility service explicitly to the triggering service consumer in the quality clearly & concisely specified as well as bindingly committed in the respective Service Level Agreement.
>> "• Terms of service provision and limits for customer expectations" <<
The quality of the identified ICTility service types must be specified according to the exigencies & expectations of the authorized service consumers in the realm of the commissioning service customer. That's because the service consumers are
- the single & sole activators & addressees of any service provision
- the critical success factors for service providing as well as for service-based value creating.
>> "• Systematic control of the service quality achievements" <<
Based on the complete & concise service specification with 12 practical attribute values, for each & every triggered service can be impartially verified if it has been rendered according to this specification or not.
>> "Informal aspect:
• Understanding of the customer’s needs and demands and seeking for a way to satisfy it reactively as well as proactively" <<
The service customer wants & needs that each & every triggered ICTility service is rendered explicitly to the triggering service consumer in the quality specified in the respective Service Level Agreement. Then, the triggering service consumer, i.e. the employee in the business unit, can efficiently execute his upcoming business activity and create the respective business value in so doing.
Thus, the accountable ICTility service provider must providently ensure reliable service providing for satisfying each & every triggering service consumer in the realm of the commissioning service customer. By achieving this, he satisfies the service customer, too.
>> "• Monitoring and managing of customer’s and user’s satisfaction with the services" <<
Only the service consumer's satisfaction is relevant because he needs & consumes the service-specific benefits for executing his upcoming business activity.
>> "• Regular and systematic interactions with customer." <<
Most important are the explicit service triggers of the authorized service consumers in the realm of the commissioning service customer. The respective service transactions are performed by the service automats, i.e. the service-relevant ICT-systems.
The regular interaction of the accountable service provider with the service customer comprises
- billing the number of services consumed by his authorized service consumers
- reviewing the service specifications in the service catalogue in joint alignment with his service consumers.
>> "The formal aspects of service orientation imply a certain level of service provider’s maturity while the informal mean some level of trust between the provider and the customer." <<
The service provider must ensure reliable, efficient & paying service providing explicitly to the triggering service consumer for each & every triggered ICTility service. Thus, the authorized service consumers as well as the commissioning service customers must trust the service provider because the latter is accountable for making performing each & every real-time service transaction according to the respective service specification.
>> "What is service orientation?
Although this term is widely used by ITSM folks, I couldn’t find a sound definition for the service orientation." <<
True service orientation starts with a clear & complete, consistent & concise definition of the service term that reads:
A service is a set of one-time consumable & perishable benefits that must be rendered explicitly to the triggering service consumer by effectuating the service-specific benefits to the service object he has designated with his dedicated service trigger.
Based on this generic definition,
- each & every service type can be clearly & precisely identified from the perspective & the perception of the service consumers by means of its three constitutive service-identifiers
1. service consumer
2. service object
3. service-specific benefit
s. article 'Service Identifying - 3 Service Identifiers' on the blog of OmniNet
in Russian 'Определение услуг – 3 идентификатора услуг'
- each identified service type can be completely & concisely specified based on the 12 standard service attributes according to the exigencies & expectations of the authorised service consumers in the realm of the commissioning service customer
01. Service Consumer Benefits
02. Service-specific Functional Parameters
03. Service Provision Point
04. Service Consumer Count
05. Service Providing Readiness Times
06. Service Consumer Support Times
07. Service Consumer Support Language
08. Service Fulfillment Target
09. Service Impairment Duration
10. Service Providing Duration
11. Service Provision Unit
12. Service Providing Price
s. article 'Service Specifying - 12 Service Attributes' on the blog of OmniNet
in Russian 'Создание спецификации услуг - 12 атрибутов услуг'
All further methods are illustrated in the article 'Servicialisation - thought leading concept for providing services' on the blog of OmniNet
in Russian 'Сервициализация – ведущая концепция обеспечения услуг'
All further service terms are explained in German in the 'Glossar Service-Terminologie'
>> "What is ITSM?
To put it simply, ITSM theory and practice are based on two basic principles:
• We use services as a primary means of working for and communicating with the Business." <<
In reality, it is required to make the service automats, i.e. the service-relevant ICT-systems instantaneously effectuating & rendering each & every triggered ICT-system based service explicitly to the triggering service consumer so that he can execute his upcomping business activity and create the relevant business value in so soing. Thus, it must be all about rendering ICT-system based Business Support Services (ICTBSS) instead of communicating with the Business by means of services.
>> "• We use processes as a way to keep our services and activities in order."<<
These ITIL-based processes deal with managing the service-relevant ICT-systems but not with reliably providing each & every triggered ICTBSS explicitly to the triggering service consumer. This is the case because
- the service consumers are not taken center stage in ITIL
- there is no service providing process described or worked out in ITIL.
>> "The ITSM system is a system of processes and functions specialized to manage the quality of IT services. At least ITIL puts this in similar words." <<
In reality, ITIL is about the management and the quality of the service-relevant ICT systems based on the definition:
"Service: One or more IT systems that enable a business process."
that is operant up to the last & the latest paragraph of ITIL (V3) Edition 2011 as well as in every ITIL-based practice.
>> "But does this mean that the IT management system must inevitably be the IT Service management system?" <<
The question is if there is any difference between
- IT management
- IT service management
in particular because
- ITIL is about IT system management
- a service cannot be managed as each & every service is intangible & immaterial, insubstantial & perishable.
s. Wikipedia entry 'Service characteristics'
The resource provider and/or IT(IL) department must evolve into the accountable ICTility service provider of the enterprise by rendering each & every triggered ICTility service (= ICT-systembased utility service) explicitly to the triggering service consumer in the service quality specified in the respective Service Level Agreement.
This evolution can be performed in parallel to the daily business based on
- the methodology of servicialisation
- the Service Providing Maturity Model
as illustrated in the slide deck of the master class 'Servicialisation - From Service Identifying to Service Billing' on May 24, 2012, in Moscow
There might be some general hiccups
- the misleading definition of the service term in ITIL V2 that is operant throughout ITIL (V3) Edition 2011 and in all ITIL-based practices:
"Service: One or more IT systems that enable a business process." ...
... in short: Service = IT system(s)
must be corrected
- the ITIL-based "Plan - Build - Run ICT systems" must be complemented with the "Compose - Commit - Conduct service providing" of servicialisation
Nevertheless, there is hardly another option regarding the changes and the pressure in the enterprises as well as in the ICT business.
Regarding the efforts and the business case: As up to 30% of all efforts are currently wasted because they don't contribute to effectuating & rendering the triggered ICTility services, there is a valide case for performing the change and saving this money.
The reason that rule-based approaches as described here are destined to "always" fail is that these are rule-based approaches as an example of how NOT to do them.
I am not sure whose comment this was (reproduced by the editor as a post), but it leans rather heavily upon a few straw men.
The rule-based approaches described here could easily be improved by allowing (for a few examples) typographical errors to be corrected without specific approval and documented as corrected, or by recognizing that installing a huge printer for which the IT department is responsible is a bit more involved a proposition than simply plugging it in. Perhaps the person making the comment (now the main body of the post above) was not exposed to other aspects of the "A0 Plotter" acquisition and installation, but there was more to it than plugging it in.
And so it goes with this post, where the supposed difference between principles and practices and rules and expertise have been laid out in a fashion designed to reflect poorly on what the author refers to as a "rule-based" approach. Now, obviously, if we could all simply substitute "information, guidelines, and expertise" for "data, rules and scores", then we could do away with all that time-wasting ranking and prioritization as well. We would simply know what needed to be done, and then we would of course do it. With that sort of workforce, who needs meetings, or for that matter, managers?
Where I work, we could use a few more rules, and a little less "experience" guiding us toward the future. None of us have experience in the future, no matter how firmly some insist that they have seen it before. The one thing I know is that if we do not change direction (Chinese proverb, it seems), we are highly likely to wind up further along the same road. And that is not looking so good. For us, "Evolution Three" is the same as Zero.
The book begins storgnly with a rousing introduction and a very interesting first chapter. From then on the book gradually degenerates into boring, long lists of bullet points, each accompanied by a few sentences about each point. If this book had been 100 pages I would recommend it. Unfortunately however, the author does not have enough to say to justify a book of this length. I think most managers will read the introduction and the first chapter and then lose interest and put the book away, never to be looked at again.
Lean can be used as one of the tools or approaches wihtin Continual Improvement, but it can't replace ITIL or any other competent service management framework as it is not designed to be used that way and doesn't cover 95% of the scope it would have to. I'm not saying that ITIL is the only thing you should use each organisation needs to decide how they want to do' service management. It is likely that they will be influenced by ITIL, ISO/IEC 20000, COBIT, Lean and many other frameworks, methodologies, standards and practices. None of these on their own should be a guiding force' we need to get back to the customer, their requirements, the services we deliver to them and the business objectives of our organisation, as being the primary guiding force.
Thank you very much for sharing, your train of thguoht I would like to encourage you to continue your blogs on technology in higher education, it is a career where we as technology professionals in higher education do not share a lot of information except at conferences. Once again I like to say thank you.
I think there are two other aspects that need to be coevred in this discussion and which you alluded to briefly affect and impact. When we discuss efficiencies and effectiveness in the context of total productivity, we have to include the overall affect and impact on the area where we are trying to improve on efficiencies and effectiveness. The affect and impact on a given area, whether that is lab support, application support, research and development or any other given area where IT is involved, has to be considered both in the short term and in the long range planning. Of these two, impact is the most visible and probably the most likely to change the overall effectiveness of the CIO's role.We recently witnessed the impact of Hurricane Irene on the east coast. The efficiencies and effectiveness of the weather reporters, FEMA and local government staff, and other support services could not have been better conducted; however, the impact of the storm, the torrential rains and the damage caused by the post-storm flooding could not have been stopped no matter how efficient or effective the pre-storm preparations were. One could ask, what the comparison of this event has in relationship to IT in higher education and that would be a fair question. The comparison, as I see it, is that no matter how well you prepare, no matter how efficient or effective your vision for your department and programs will' be, no matter how well you communicate to the administration, staff and students, you still have to deal with the aftermath of any changes to the environment that you make towards the end objective of being more efficient. The aftermath could be positive or negative depending on what was done, but you have to be ready to support the change in policies, procedures or staffing to your constituents while limiting the negative impact or affect on their environment.A prime example is the implementation of change management. If performed correctly and with proper governance, change management can have an extremely overall positive affect on IT operations. At the same time, even if performed correctly, change management has a tendency to slow the implementation process. The impact to the end users, if they have been accustomed to having their requests acted upon immediately, will be received as a negative change. The CIO and the IT department has to be prepared to support or even defend these types of changes and the impact of these types of changes.
I think the overarching principle of 'adapt and adopt' is the key takeaway from ITIL - remembering that it's a framework and not the rule-book. I've 'implemented' ITIL-based processes in both large and small companies and have found that if you take the principles of the framework and apply with common sense, you can do wonders.
Another piece of advice is that ITIL isn't everything - it's intended to guide service management throughout the lifecycle but IT organisations need other supporting processes and practices, like any other organisation.
What is the progress on ISO/IEC 20000-8 (the process assessment model) please anyone?
@Anonymous (11/04/2012): Why ask IT what it wants to achieve? One should be asking what does Business want to achieve. IT is an enabler.
Why is ISO15504 not featured as part of the jigsaw diagram above? Other ISO's recognise it as an enabler (such as ISO20000-4) and you mention it in your text under ISO20000-8. Is this an omission or does it have a valid place alongside 90006, 27013, and 19770 as a related process?
Hi, Interesting comments and thoughts. From what I see ITIL has some good aspects. But to think there is an all encompassing all including, all solution system for IS...IT... for corporations is unrealistic. Each corpaoration or company must find their own way of managing their infrastructure. ITIL is not for the small. And for the large ITIL is very costly and lengthy to implement.
Sounds somewhat like "Manage by Exception' in Prince2 mixed with a little bit of Agile (do the things that matter most) - I like it!
This column is completely based on ITIL V2
You may have been asked this question before, and it is purely out of quriosiry. ITSM, as you say is based on ITIL, and seems to be entrenched on the ITIL V2 processes + Service Desk. Where as ITIL is the best practise Framework, ITSM is punted as a Methodology.. Some of the new ITIL processes, viz., Request Fulfillment (RF), Servive Validation and Testing (SVT), Service Evaluation (SE) have been left out.
Should it still be classified as an ITSM Methodology, if it leaves 'new' processess out? Could it be that ITIL has gone too granular by goining into the level of defining defining RF, SF, Supplier Management and Business Relationtion Management? Just qurious.
I wouldnt worry about the 2011 revision affecting your status as a Service Manager unless you have forgotten everything you have learned so far :)
In terms of qualifications the big difference is not 2011 but the original v3 release which totally changed the face of ITIL qualifications and therefore, you could argue, retired your Managers certificate.
However, most of the people I know (me included) who were v2 managers and now have v3 still refer to the v2 path as well since they believe that it was a significantly more relevant way to demonstrate an understanding (the essays rather than a multi choice exam).
The main thing is to demonstrate your experience and this should render qualifications as less relevant on your CV
Also read the column by Geoff Harmer: http://www.itwnet.com/columns/itil-master-here-strong-competition#commen...
related news item: http://www.itwnet.com/news/new-post-graduate-certificates-itsm-coming