Recently I have been working on the implementation of an agreed upon service level agreement. It contained several different quality levels (I will refer to them as high, medium and low in this post), each having different service window, different time to fix and availability service level objectives.

I distilled an example out of the original values to avoid recognition:

Service Level	Service Window	Time to Fix	Availability
High	24 x 7	1 h	99,9 %
Medium	Mo-Sa 06:00-22:00	4 h	99,0 %
Low	Mo-Fr 08:00-18:00	20 h	95,0 %

Sounds reasonable doesn’t it?

So let us have a more detailed look at what these figures really mean. The high version states 99,9% availability out of 24 x 7. Per month this gets down to 99,9% of 720 hours. So how long can we permit to be down in total? The answer is

0,72 hours or 43 minutes and 12 seconds

So why did we state that the time to fix is one hour? If we adhere to the time to fix SLO, we may still miss the availability SLO even with a single outage!

For the medium SLA we have a 99% availability out of Mo-Sa 06:00 – 22:00, which is approx. 432 hours per month, leading to a maximum down of 4 hours and 32 minutes. This is closer to the mark.

But the greatest danger is in the low SLA. It states 95% out of Mo-Fr 08:00 – 18:00, which reduces the service time per month to 225 hours and results in a maximum down time of 11 hours and 15 minutes. This is little more than half of the SLO for time to fix!

What is my conclusion out of this? If you combine service level objectives you have to be very careful about what you do, since you may produce useless SLO targets and misguide people reading your service levels. It is much easier to understand what targets like time to fix mean for my job than a value of 95% availability, which may mean all or nothing. If you create SLAs, please make them consistent and logical without such traps. If you consume SLAs, verify everything and do not take logic for granted.

One of the most misused functionality in current incident management tools is the pending state (sometimes also called time out). When someone working on the incident decides that the SLA is in danger they can easily avoid escalation (and often SLA failure in the report) by setting the state to pending. This effectively cancels the SLA timing1 and by subtracting the time from start of the pending state up to the end of pending from the calculated incident SLAs. Quite often the reporting is reusing the pre-calculated and evaluated SLA timings these systems provide, so nobody will notice when an incident misses its service level objective by 1000%.

So should we remove the capability of pending states? Should we all alter the given functionality and remove any time outs? No would be my answer.

So do we have to change the way we use this functionality? Yes, now we are talking!

I suggest the following for time outs (my preferred terminology, pending is not exact enough):

1. Define possible time out reasons in your SLA
   Get the attention of your client or business to the possible reasons for delays. Make sure these are well understood and agreed upon.

2. Make sure the time out reasons are the things out of your control
   All things you can not control or guarantee should be listed as time out reasons. The first item will help in keeping this list short, since the business will not like too many exceptions.

3. Provide the reason of each individual time out
   Have the support personal select on of the reasons you listed in your SLA (even if it is only one). Log this in a reportable way and require an additional free text field for details.

4. Allow only limited time outs
   Indefinite time outs lead to indefinitely delayed incident resolution. If you stop escalations for eternity they will not return by itself.

5. Inform the user about time outs
   Send an automated mail about the time out or show the reason in your web support tool for the user to read. This manages the expectations and also reduces the possibility of pending fraud.

6. Generate & review reports on time outs
   Report on the delay per time out reason and check for ways of reducing this. Share this report with the business and jointly think about improvement options.

7. Define the influence on escalations & SLAs separately
   There may be situations where you have a defined action plan (e.g. vendor has to build a patch) which will take longer than your SLA. You may then either omit or reduce the escalations while still reporting the service level miss.
   

What kinds of time out reasons I can imagine? Well that depends on your situation and relationship with the business.

• A very common reason is that you need the customer / user to do something and he/she is not available.
• Another common one is “Agreed upon delay”. Sometimes the SLA forces me to fix this within a few hours while the customer / user does not want it to be fixed (e.g. battery issue with a laptop, while the user needs to go and present right now).
• If your business is responsible for third-party contracts and IT has no influence (or not enough) on external support another reason may be “Waiting for external service”.
• I have even seen a reason within an SLA stating that restoration of data is not part of the restoration of service since the amount of data influences this2.

This may seem like a lot of effort for a few simple process exceptions, but since they occur quite often it may be useful to think about this a bit more.

1: This is true for many incident workflow systems and in many configurations. It may or may not be the case for your individual setup, so please check it before relying on this information.
2: I would never suggest such a time out, it is just a sample. IT should design its restore capability to match the restore requirements and not the other way around.

This position is an Application Administrator to support operations within our client’s department. This position has a critical role in delivering our services to clients and ensuring successful ongoing operation of our applications and services. It services a highly interactive software development build/release process as well as a rich operational environment with many interrelated applications/database services. The candidate should be self-motivated, detail oriented, adaptable to change and must work well in a flexible team environment with developers, QA, operations staff, system administrators and managers.

RESPONSIBILITIES:

Application and database support

• Provide on-going database administration in both back-end and front-end with application infrastructure support for our client’s administration systems, including the deployment of new applications.
• Review the physical design of existing databases for optimal database structures, database performance tuning, security, database backup/recovery strategy, implementing high-availability, and pro-active and reactive performance analysis, monitoring, troubleshooting and resolution of issues, capacity planning, monitoring data growth and system utilization, trend analysis and predicting future database resource requirements.
• Install web-base applications from ground up to full-ballooned implementation and support, including configuration at Unix/Linux/Windows system level, back-end integration with database, front-end integration with user-interface, final delivery to users to fulfill users’ requirement and on-going maintenance.
• Take the lead in ensuring that application and web services are configured and tuned according to application needs; provide troubleshooting as needed.
• Work with System Administrators to ensure test and production boxes conform to the software application configuration needs.
• Support the department-wide infrastructure application for database management, system monitoring and notification, job scheduling, deployment, provision and patching automation, application topology and service level management for campus-wide system performance.

Build/release activities

• Manage the build, tagging and release processes for a number of interdependent Java web applications and background processes in the QA and production environments. Ensure the build and release process is scalable and repeatable.
• Work with the development team to ensure efficient and understandable build procedures are adhered to and conform to a standard process for configuration and release management
• Develop and maintain tools that automate the building of software releases for an Agile-based development process. This is one of continuous integration, where the automated build process can be run many times a day if necessary.
• Work with and support the QA team to ensure automated test suites run as part of the continuous integration build process.

REQUIREMENT FOR SKILL AND COMPETENCIES:

• Expert hands-on with shell scripts, other scripting languages, preferably Perl, and tool automations
• Minimum 2 years database administration experience in Oracle and 3 years Application administration experience in Unix/Linux infrastructure environments is required.
• Hands-on experience of Oracle databases 10g for 24/7 database operations and tool automation in installation, configuration, backup/recovery, startup/shutdown, data refresh, and application integrations.
• Experience with OEM/Grid Control is highly desired.
• Knowledge and understanding of large scale ERP implementation and support like Oracle Financial and PeopleSoft systems.
• Expert knowledge of Apache and Tomcat, and other web/application servers such as JBoss
• Strong Unix and system administration skills with basic network and security knowledge
• Strong experience and ability in web applications deployment, configuration and integration from both OpenSource and Commercial based systems with or without sophisticated vendor support.
• Java/J2EE based programs
• Java/servlet/JSP based web applications
• Experience with Subversion, PVCS or similar source code repository
• Experience with Maven and familiarity with automated build processes
• Experience with the Agile development methodology and concepts of extreme programming and continuous integration
• Understanding of the layers/tiers of web applications and the communication protocol between the tiers with networking protocols (TCP/IP, HTTP, SSL, DNS, FTP, etc.)
• Ability to multi-task and work in a team environment is critical and should have excellent communication skills in both verbal and written forms.
• Ability to manage multiple competing priorities and work under pressure in high stress situations
• Excellent communication skills in both verbal and written
• Ability to work under pressure and to deliver results in a complex and dynamic operational environment

Qualifications

Minimum 5 years as an IT professional in build/release and application/database administration, plus one or more of the following areas: IT infrastructure operations 24/7, systems analysis and design, or application development.

Education
Bachelors Degree in Computer Science, Engineering or related field or equivalent experience

If you are interested, please send your resume to tsotelo@mindsource.com.

Šoreiz ielikšu garāku citātu – kas tad īsti ir Pakalpojumu līmeņa pārvaldība un kādēļ tā nepieciešama.

Pavisam īsi sakot – pakalpojumu līmeņa pārvaldība ir starpnieks starp IT pakalpojuma sniedzēju un biznesu. IT Pakalpojuma sniedzēja interese ir minimāla kvalitāte par maksimālu cenu, savukārt biznesa interese ir maksimāla kvalitāte par minimālu cenu. Parasti šiem diviem runājot pa taisno, nekas prātīgs nesanāks, jo viena puse būs spēcīgāka un panāks savu (īstermiņā). Lai cik pārsteidzoši tas nebūtu, uzvar parasti bizness, kas saņem strādājošu pakalpojumu par lētām naudām. Tikai tad kad rodas problēmas ar pakalpojuma stabilitāti, pieejamību un ātrdarbību – tad gan IT ir vainīgs, jo nav brīdinājis, izskaidrojis un parādījis, ka biznesam ir jāiegulda naudiņas infrastruktūrā vai kodā.

Nu lūk – lai administratori varētu darīt savu darbu mierīgi un viņiem nebūtu ar biznesu jākašķējas, tad ir nepieciešams starpnieks – Pakalpojuma vadītājs, kurš rūpējas par to, lai biznesa prasības tiktu stingri un precīzi atrunātas, un pats galvenais – arī tiktu precīzi izmērīta pakalpojuma darbība pēc biznesam svarīgajiem parametriem.

Un nu pats citāts – jeb, kas tad īsti ir Pakalpojumu līmeņa pārvaldība. ITIL V3. Service Design. Service level management:

Pakalpojumu līmeņa pārvaldības nodrošina, ka visi esošie IT pakalpojumi biznesam tiek piegādāti saskaņotajā kvalitātē.

Pakalpojumu līmeņa pārvaldības uzdevumi ir:

• Definēt, dokumentēt, vienoties, monitorēt, mērīt, ziņot un uzraudzīt pakalpojuma kvalitātes līmeni
• Nodrošināt un uzlabot savstarpējo sadarbību starp biznesu, klientiem un pakalpojuma piegādātāju
• Nodrošināt, ka tiek izstrādāti pakalpojumam specifiski un izmērāmi kvalitātes rādītāji
• Uzraudzīt un uzlabot klientu apmierinātību ar saņemtajiem pakalpojumiem
• Nodrošināt, ka IT un klientiem ir skaidrs un vienots skatījums uz piegādājamo pakalpojumu kvalitātes līmeni
• Nodrošina, ka tiek veikti proaktīvi pasākumi pakalpojumu kvalitātes uzlabošanai, ja tos ir iespējams ekonomiski pamatot

Pakalpojumu līmeņa pārvaldība pārstāv IT pakalpojumu piegādātāju klienta priekšā un klientu – IT pakalpojuma piegādātāja priekšā. Pakalpojumu līmeņa pārvaldība ir starpnieks starp klientu (to, kas pērk pakalpojumu) un pakalpojuma piegādātāju (kas nodrošina pakalpojuma darbību). Ir jānotiek regulāriem kontaktiem, kur tiek apspriests esošais pakalpojuma līmenis un pakalpojuma nākotne. Pakalpojumu pārvaldībai ir jāspēj tikt galā ar abu pušu prasībām – gan IT, gan klienta. Pakalpojumu pārvaldība nodrošina to, ka saņemtā pakalpojuma kvalitāte atbilst tam, ko klients sagaida.

Pakalpojumu līmeņa pārvaldības process ietver sekojošus jautājumus:

• Attiecību veidošana ar biznesu
• Operacionālā līmeņa līgumu (OLA) noslēgšana un vadīšana
• Apakšuzņēmēju līgumu pārskatīšana
• Proaktīva pakalpojumu traucējumu novēršana, pakalpojuma risku novēršana un pakalpojuma darbības kvalitātes uzlabošana
• vadīt visus pakalpojumus un SLA pārkāpumu gadījumus, un atskaitīties par tiem

Pakalpojumu līmeņa pārvaldības vērtība biznesam ir tajā, ka tā nodrošina atbilstošu sadarbības mehānismu par visiem jautājumiem, kas saistīti ar pakalpojumiem. Pakalpojumu līmeņa pārvaldība nodrošina biznesam saskaņoto pakalpojumu kvalitātes līmeni un visu nepieciešamo vadības informāciju, lai nodrošinātu, ka kvalitātes rādītāji ir izpildīti. Kad SLA līmenis ir pārkāpts, pakalpojumu līmeņa pārvaldībai ir jānodrošina atgriezeniskā saite par pārkāpuma iemesliem un darbībām, kas tiek veiktas, lai pārkāpums neatkārtotos.

Pakalpojuma līmeņa pārvaldības process ietver plānošanu, koordinēšanu, vienošanos, uzraudzību un ziņošanu par Pakalpojumu līmeņa līgumiem (SLA) un nepārtrauktu pakalpojumu uzlabojumu iespēju izskatīšanu, lai nodrošinātu, ka prasītā pakalpojumu kvalitāte tiek piegādāta par saprātīgu maksu un pakāpeniski tiek uzlabota. SLA ir rakstīta vienošanās starp Pakalpojuma piegādātāju un tā klientiem, kurā tiek aprakstīts nepieciešamais pakalpojuma kvalitātes līmenis un abu pušu atbildība.

No otras puses, OLA ir vienošanās starp Pakalpojuma piegādātāju un citu tās pašas organizācijas struktūrvienību, kas piedalās pakalpojuma nodrošināšanā.

Nobeigumā divas bildītes – SLM un nekustamo īpašumu uzturēšanas analoģija:

Tātad, ko mēs redzam bildītē – Attīstītājs pasūta māju, celtnieks to uzbūvē, pircējs nopērk. Pēc tam, kad māja ir uzcelta, celtnieks dodas būvēt citu māju un viņa vietā nāk mājas pārvaldnieks – cilvēks, kuram ir visi mājas plāni, cauruļu shēmas, vadu rasējumi, rezerves atslēgas – viņš ir tas, kas rūpējas un uztur māju. Ja mājas iedzīvotājam rodas bojājums viņa dzīvoklī, viņš sauc uzturētāju (parasti zvana sekretārei vai dispečerei), kurš, atkarībā no bojājuma rakstura, atsūta atbilstošo meistaru – apkopēju vai Meistaru Vasju (ar lielo burtu). Ja Meistars Vasja galā netiek, tad mājas pārvaldnieks sauc palīgā celtnieku – pēc garantijas vai pasūta remontu. Elementāri un loģiski? Man tā liekas, tikai IT jomā tā, diemžēl, nenotiek – parasti celtnieks pats projektē, pats būvē un pircēju ielaiž negatavā mājā (skat stāstu par IT mājas būvi), un pēc tam izpiež no viņa naudu, lai novestu līdz pilnai apdarei. Protams, tā notiek arī reālajā celtniecībā, bet tad taču mēs skaidri saprotam, ka tiekam čakarēti.

Un te mēs nonākam pie tā, kā tad vajadzētu izskatīties IT Pakalpojumu pārvaldībai:

Bizness pasūta jaunu pakalpojumu, izstrādātājs kopā ar pircēja pusē esošu IT attīstību (projekta vadītāju), šo pakalpojumu izveido. Bizness šo pakalpojumu lieto, ja rodas kādi incidenti vai problēmas – ziņo Palīdzības dienestam, vai arī Monitorings pats pamana, ka ir pakalpojuma darbībā ir traucējumi. Pakalpojuma vadītājam ir pieejama visa informācija – par pakalpojumu kopumā – kādi serveri, kādi tīkli, kādas datubāzes nodrošina pakalpojuma darbību, cik svarīgs pakalpojums ir biznesam. Incidenti tiek nodoti Adminam Pēterim (ar lielo burtu), kurš atjauno pakalpojuma darbību, bet ja netiek galā – tad piesaista ražotāju (dzelzim vai softam).

Elementāri un skaisti… Tikai dzīvē tā notiek reti.

(Yes, I struggled to come up with a snappy title for this post that wouldn’t sound like marketing speak.)

In October, Paul Glen (re-)published an article at TechRepublic: Project managers: Stop “gathering” IT requirements and Hank Marquis published an article on CIO Update: Why IT Service Level Management Fails (And How to Fix It).

• In summary, Paul says that, while a failure to agree requirements is the root of many IT project failures, “gathering” requirements is the wrong attitude. As I’ve also found, customers tend not to be very good at articulating their requirements at the outset of a project (not nearly as good as they are at saying “No, that’s not what I wanted” at the end). Secondly, passively receiving requirements puts IT projects squarely within IT’s responsibility. It’s much better to negotiate or even sell requirements – to my mind, this is actually what customers mean when they complain “I thought it was IT’s job to define requirements”.
• In similarly brutal summary, for which I apologise, Hank says that service level reporting based on well-defined and controlled metrics – like percentage availability and mean time to repair – fail to address what customers want. He advocates dropping all the tightly-controlled (whether actually or theoretically) metrics and focusing on customer satisfaction. He reports on the SERVQUAL method for reporting quality in service industries in general. I haven’t looked into SERVQUAL enough to say whether it specifically is valuable, but I strongly agree with his principle that “quality is what customers tell you it is”.

It struck me that these two recommendations go together. Establishing, defending or analysing requirements (call this stage what you will) happens at the beginning of a service’s lifecycle, and service reporting happens at what we like to think of as the end (apart from service retirement or decommissioning).

The traditional, all-too-common approach is to ask users for requirements (or sometimes, especially in ITSM projects, not to ask at all), build the service or function, and then to find that it takes a lot of effort to report on service achievement, often in confrontation with the users. It’s fair to characterise this as passive and reactive. Trying to justify performance when IT thinks service levels are good and the users see service achievement as poor could even be characterised as passive-aggressive.

The approach that these articles taken together would suggest is that services begin by negotiating requirements, as a two-way activity in partnership – keeping the customers involved and committed. Then when the service has been delivered, report on achieve strictly from the customers’ perspective. This may take a humility that many IT departments are not familiar with, and at least can bring on the fear that many know all too well. But when customers are seeing a lack of alignment between IT and business, what could be better than placing their quality first? It’s fair to characterise this approach as proactive, although I do think that word is overused.

Instead of gathering requirements and struggling to sell achievements, sell requirements and gather satisfaction.

-

A guiding principle could be the SERVQUAL equation that Hank Marquis describes as “the E=mc² of every service industry except IT”:

• q = e – p, or service quality = expectation – perception

Set the expectation at the requirement negotiating stage; measure the perception and derive the quality during the service lifetime.

-

A key way of looking at the difference between the approaches is to consider how quality failures are handled. (Nothing in the “proactive” approach means that quality issues won’t occur any more, of course.)

With the traditional approach, a “service level breach” (in the contract-oriented language of ITIL) manifests as the failure of metrics under IT’s control. The users cannot easily understand how these relate to their service experience, let alone their business objectives. All they can do is complain at IT. Or feel obliged to take on part of IT’s role themselves and research best practices and benchmarks. When users quote industry reports on 99.999% availability to the IT department, it’s a sure sign of a failure of alignment – and doesn’t really help anyway. Costs can go out of control if IT invests in fixing the metrics and not in improving the business value of the services.

Worse, the service levels can all be met but the customers still be dissatisfied, because they have no ownership in how the service level metrics relate to their business performance metrics. In this case IT has the appearance of full control, but the perception of poor service: again, this shows a lack of alignment between IT and the business.

What happens in the “proactive” approach? Quality failures still occur, but you know about them much more quickly (a “fail-fast” characteristic), because they come from the coalface. (Infrastructure component failures still occur, and should be monitored and managed within IT as is traditionally done – customers should not even be involved in the process of managing the infrastructure.) Moreover, you have much more insight into what to do because the affected customers can immediately tell you how they’re affected and what the impact is. This is valuable input to a change process. (Note that measuring “satisfaction” should not be seen as measuring one number. You need a framework, like SERVQUAL, so that you know which aspect of the customer experience is affected. Like any service reporting, reporting service quality can usefully be done through a dashboard that presents a clear top-level picture but allows drill-down.)

Because the quality failure is first expressed as a customer perception drop, it’s much easier to keep customers involved and committed to the success of the service and to participate in the continual improvement activities. This begins to sound like Agile principles (frequent iterations, responding to change instead of following a mammoth plan, working service over voluminous reports) … but that would be a subject for another post.^*

^* One of the reasons for my lapse in getting this blog going is that, in the several drafts I’ve jotted down in the past few months (see my recycle bin) I keep seeing things connected to the topic I’m writing about that I need to research and write about in the same post, to be comprehensive. Exactly what blogging should not try to be!

Indeed as my blog title suggests I passed my PRINCE2 Practitioner exam and have already received my certificate.  One comment I would like to pass on to ‘would-be’ PRINCE2 takers is that its a good idea to have your ‘pink’ book before you start your training program.  I found it provided me with a good foundation for taking both the Foundation and Practitioner exams.  I saw other delegates struggling having not become familiar with their book.  Maybe I’m just in the minority of people who like to read up on my desired career direction before embarking on the course and exam direction.

On Monday 10th November I attended an ITIL V3 Bridge course and exam.  I will kick myself should I have gotten one wrong answer, as I am expecting to get a perfect score.  Perfectionist I am not, but knowledgable of my choosen subject matter I am, and take great pride in this fact.

I am just itching to get stuck into the new ITIL v3 modules.

Now all I am doing is waiting for the right Project Manager and/or Business Analyst contract role to come my way that includes my Mastermind specialist area of ITIL.

In the meantime I’ll be writing on my blog for you all to read and comment on.  I’ll be swotting up on Service Level Management, Configuration Management and a new book that arrived from the rainforest bookstore ‘Enterprise Risk Management’, some good bedtime reading ahead of me.

پشتیبانی سرویس ( Service Support )

نظام پشتیبانی سرویس ITIL بر روی کاربر سرویس ICT متمرکز شده است و وظیفه اصلی آن تضمین دسترسی آنها به سرویس‌های مورد نظر ، به منظور پشتیبانی وظایف تجاری است .

 برای یک تجارت ، مشتری ها و کاربران نقاط ورودی به مدل فرآیند ( Process Model ) هستند . آنها ( مشتری ها و کاربران ) بوسیله :

• درخواست تغییرات ( Asking for Changes )
• لزوم ارتباطات ، بروز راسنی‌ها ( Needing Comminucation , Updates )
• درگیر شدن ، پرس و جو ( Having Difficulties , Queries )

درگیر پشتیبانی سرویس می شوند . برنامه Service desk تنها نقطه ارتباطی مشتریان برای مطرح کردن مشکلاتشان می باشد . که درصورت وجود پاسخ ، مشکل برطرف می شود و در غیر این صورت یک رخداد ( Incident ) ثبت می شود . رخداد باعث بوجود آمدن یک سری فرآیند می شود : مدیریت رخداد ( Incident Management ) , مدیریت مشکلات ( Problem Management) , مدیریت تغییرات (  Change Management ) , مدیریت نسخه های منتشر شده و مدیریت پیکربندی ( Release Management and Configuration Management ) . این سری فرآیندها توسط پایگاه داده مدیریت پیکربندی  ( Configuration Management Database - CMDB ) پیگیری و ثبت می شود . که هر فرآیند را ذخیره می کند و مستنداتی را برای امکان پذیر کردن پیگیری تولید می کند ( مدیریت کیفیت – Quality Management  )‌.

1. مدیریت درخواست سرویس ( Service Desk / Service Request Management )

وظایف ServiceDesk ، رسیدگی به رخدادها و درخواست‌ها می باشد و یک واسط برای سایر فرآیندهای مدیریت سرویس فن‌آوری اطلاعات ( ITSM ) فراهم می کند.

• تنها نقطه ارتباط  ( SPOC – Single Point of Contact  )  و نه لزوما اولین نقطه ارتباط ( FPOC – First Point of Contact  )  .
• تنها یک نقطه ارتباطی ورود و خروج وجود دارد
• سهولت استفاده برای مشتری ها
• یکپارچگی داده ها
• کانال ارتباطی سریع ، مفید ، موثر و پرکاربرد است

وظایف اصلی یک ServiceDesk عبارتند از :

• کنترل رخدادها :‌ مدیریت چرخه زندگی تمامی درخواست های سرویس
• ارتباطات : مطلع کردن مشتری ها از وضعیت رسیدگی به درخواست ها و پاسخ دهی به آنها

وظایف ServiceDesk تحت عناوین مختلفی شناخته می شود

1. Call Center ( مرکز تماس ) : تاکید اصلی بر روی رسیدگی به پاسخگویی به تعداد بسیار زیادی از تماس های تلفنی است .
2. Help Desk ( پیش‌خوان کمک و یاری [ برنامه پشتیبانی ]) : مدیریت ، هماهنگی ، رسیدگی و رفع مشکلات مربوط به رخدادها در سریع ترین زمان ممکن .
3. Service Desk ( پیش‌خوان سرویس ) : فقط به رخدادها ، مشکلات و پرسش ها رسیدگی نمی کند ، بلکه علاوه اینها یک واسط برای سایر فعالیت ها مانند درخواست‌های تغییر ، قراردادهای نگهداری ، مجوزهای نرم افزار ( Software Licenses  ) ، مدیریت سطح سرویس ( Service Level Management  ) ، مدیریت پیکربندی ( Configuration Management  ) ، مدیریت موجودی ( Availability Management  ) ، مدیریت مالی ( Financial Management ) و مدیریت بهبود مداوم سرویس‌های فن‌اوری اطلاعات ( IT Services Continuity Management  )  فراهم می کند .

سه نوع  ساختاری که برای ServiceDesk می توان به آنها اشاره کرد عبارتند از :

1. Local Service Desk ( داخلی ) : برای برطرف کردن نیازهای تجاری محلی – فقط تا زمانی یک ابزار تمرینی است که در چندین محل درخواست سرویس داشته باشند .
2. Central Service Desk ( مرکزی ) : برای برطرف کرذن نیاز موسساتی که دارای چندین محل هستند – هزینه های عملیاتی را پایین آورده و به کارگیری منابع موجود را بهبود می بخشد .
3. Virtual Service Desk ( مجازی ) : برای برطرف کردن نیاز سازمان هایی که در چند کشور قرار گرفته اند – می تواند با بهره گیری از مزایای بهبود شبکه و مخابرات ،از هر نقطه ای در جهان مورد دسترسی قرار بگیرد . و منجر به کاهش هزینه های عملیاتی و بهبود بکارگیری منابع موجود شود .

پشتیبانی سرویس ( Service Support )

نظام پشتیبانی سرویس ITIL بر روی کاربر سرویس ICT متمرکز شده است و وظیفه اصلی آن تضمین دسترسی آنها به سرویس‌های مورد نظر ، به منظور پشتیبانی وظایف تجاری است .

 برای یک تجارت ، مشتری ها و کاربران نقاط ورودی به مدل فرآیند ( Process Model ) هستند . آنها ( مشتری ها و کاربران ) بوسیله :

• درخواست تغییرات ( Asking for Changes )
• لزوم ارتباطات ، بروز راسنی‌ها ( Needing Comminucation , Updates )
• درگیر شدن ، پرس و جو ( Having Difficulties , Queries )

درگیر پشتیبانی سرویس می شوند . برنامه Service desk تنها نقطه ارتباطی مشتریان برای مطرح کردن مشکلاتشان می باشد . که درصورت وجود پاسخ ، مشکل برطرف می شود و در غیر این صورت یک رخداد ( Incident ) ثبت می شود . رخداد باعث بوجود آمدن یک سری فرآیند می شود : مدیریت رخداد ( Incident Management ) , مدیریت مشکلات ( Problem Management) , مدیریت تغییرات (  Change Management ) , مدیریت نسخه های منتشر شده و مدیریت پیکربندی ( Release Management and Configuration Management ) . این سری فرآیندها توسط پایگاه داده مدیریت پیکربندی  ( Configuration Management Database - CMDB ) پیگیری و ثبت می شود . که هر فرآیند را ذخیره می کند و مستنداتی را برای امکان پذیر کردن پیگیری تولید می کند ( مدیریت کیفیت – Quality Management  )‌.

1. مدیریت درخواست سرویس ( Service Desk / Service Request Management )

وظایف ServiceDesk ، رسیدگی به رخدادها و درخواست‌ها می باشد و یک واسط برای سایر فرآیندهای مدیریت سرویس فن‌آوری اطلاعات ( ITSM ) فراهم می کند.

• تنها نقطه ارتباط  ( SPOC – Single Point of Contact  )  و نه لزوما اولین نقطه ارتباط ( FPOC – First Point of Contact  )  .
• تنها یک نقطه ارتباطی ورود و خروج وجود دارد
• سهولت استفاده برای مشتری ها
• یکپارچگی داده ها
• کانال ارتباطی سریع ، مفید ، موثر و پرکاربرد است

وظایف اصلی یک ServiceDesk عبارتند از :

• کنترل رخدادها :‌ مدیریت چرخه زندگی تمامی درخواست های سرویس
• ارتباطات : مطلع کردن مشتری ها از وضعیت رسیدگی به درخواست ها و پاسخ دهی به آنها

وظایف ServiceDesk تحت عناوین مختلفی شناخته می شود

1. Call Center ( مرکز تماس ) : تاکید اصلی بر روی رسیدگی به پاسخگویی به تعداد بسیار زیادی از تماس های تلفنی است .
2. Help Desk ( پیش‌خوان کمک و یاری [ برنامه پشتیبانی ]) : مدیریت ، هماهنگی ، رسیدگی و رفع مشکلات مربوط به رخدادها در سریع ترین زمان ممکن .
3. Service Desk ( پیش‌خوان سرویس ) : فقط به رخدادها ، مشکلات و پرسش ها رسیدگی نمی کند ، بلکه علاوه اینها یک واسط برای سایر فعالیت ها مانند درخواست‌های تغییر ، قراردادهای نگهداری ، مجوزهای نرم افزار ( Software Licenses  ) ، مدیریت سطح سرویس ( Service Level Management  ) ، مدیریت پیکربندی ( Configuration Management  ) ، مدیریت موجودی ( Availability Management  ) ، مدیریت مالی ( Financial Management ) و مدیریت بهبود مداوم سرویس‌های فن‌اوری اطلاعات ( IT Services Continuity Management  )  فراهم می کند .

سه نوع  ساختاری که برای ServiceDesk می توان به آنها اشاره کرد عبارتند از :

1. Local Service Desk ( داخلی ) : برای برطرف کردن نیازهای تجاری محلی – فقط تا زمانی یک ابزار تمرینی است که در چندین محل درخواست سرویس داشته باشند .
2. Central Service Desk ( مرکزی ) : برای برطرف کرذن نیاز موسساتی که دارای چندین محل هستند – هزینه های عملیاتی را پایین آورده و به کارگیری منابع موجود را بهبود می بخشد .
3. Virtual Service Desk ( مجازی ) : برای برطرف کردن نیاز سازمان هایی که در چند کشور قرار گرفته اند – می تواند با بهره گیری از مزایای بهبود شبکه و مخابرات ،از هر نقطه ای در جهان مورد دسترسی قرار بگیرد . و منجر به کاهش هزینه های عملیاتی و بهبود بکارگیری منابع موجود شود .

ITIL v3 در ماه may ( خرداد ) 2007 منتشر شد و شامل پنج جلد کلیدی ( key volumes ) است :

استراتژی سرویس ( Service Strategy )
طراحی سرویس ( Service Design )
انتقال سرویس ( Service Transition )
عملیات سرویس ( Service Operation )
بهبود مداوم سرویس ( Continual Service Improvement )
1. استراتژی سرویس ( Service Strategy )

استراتژی سرویس در مرکز ( هسته ) چرخه زندگی ITIL v3.1 قرار گرفته اما نمی تواند به تنهایی و بدون سایر بخش های ساختار IT ایجاد شود . این بخش دربرگیرنده یک framework ( ‌زیربنا ) برای ایجاد تجربیات موفق ( best practices ) در اثر توسعه بلند مدت استراتژی سرویس است . این بخش شامل موضوعات مختلفی مانند :

استراتژی عمومی ( General Strategy )
رقابت و فضای بازار ( Competition and Market Space )
انواع فراهم کنندگان سرویس ( Service Provider Types )
مدیریت سرویس در نقش دارایی استراتژیک ( Service Management as a Strategic Asset )
طراحی و توسعه سازمان ( Organization Design and Development )
فعالیت های کلیدی فرآیندها ( Key Process Activities )
مدیریت مالی ( Financial Management )
مدیریت سرویس سهام ( Service Portfolio Management )
و نقش های کلیدی و مسئولیت های کارکنان درگیر در استراتژی سرویس ( Key Roles and Responsibilities of Staff engaging in Service Strategy )
می باشد .

2. طراحی سرویس ( Service Design )

طراحی سرویس IT از تجربیات موفق ( Best Practice ) تبعیت می کند و شامل طراحی معماری ( Design of Architecture ) ، فرآیندها ، قوانین ( Policies ) ، مستندات و درنظر گرفتن نیازمندی های تجاری آینده است . این بخش همچنین شامل موضوعاتی مانند ،

بسته طراحی سرویس ( SDP – Service Design Package )
مدیریت سرویس فهرست ( Service Catalog Management )
مدیریت سطح سرویس ( Service Level Management )
طراحی برای مدیریت گنجایش ( Designing for Capacity Management )
سرویس IT مداوم ( IT Service Continuity )
امنیت اطلاعات ( Information Security )
مدیریت ملزومات ( Supplier management )
و نقش های کلیدی و مسئولیت کارکنان درگیر در طراحی سرویس ( key roles and responsibilities for staff engaging in service design )
می باشد .

3. انتقال سرویس ( Service Transition )

انتقال سرویس به تحویل سرویس هایی مربوط می شود که نیاز تجاری فعال / عملیاتی ( Live\Operational use ) دارند . و اغلب از بخش “پروژه” IT پیروی می کنند بجای تجارت مرسوم ( BAU – Business as Usual ) . این بخش همچنین موضوعاتی از قبیل :

مدیریت تغییرات در محیطهای تجارت مرسوم ( Managing changes to the “BAU” environment )
دارایی سرویس ( Service Asset )
مدیریت پیکربندی ( Configuration Management )
برنامه ریزی و پشتیبانی انتقال ( Transition Planning and Support )
مدیریت توسعه و نسخه ( Release and Deployment Management )
مدیریت تغییرات ( Change Management )
مدیریت دانش ( Knoweledge Management )
نقش های کلیدی کارکنان درگیر در انتقال سرویس ( Key Roles of Staff engaging in Service Transition )
را شامل می شود .

4. عملیات سرویس ( Service Operation )

تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش ( agreed levels ) سرویس ها ، برای هردوی کاربران نهایی و مشتری هاست ( که “مشتری” به کسی گفته می شود که برای دریافت یک سرویس بهایی را پرداخت کرده باشند و در مورد ، توافق نامه سطح سرویس ( SLA’s – Service Level Agreement ) گفتگو کرده باشند ) . عملیات سرویس بخشی از چرخه زندگی است ، وقتی که سرویس ها و مقادیر ( value ) کاملا تحویل شده اند . همچنین ردگیری ( Monitoring ) مشکلات ( Problems ) و برقراری تعادل بین سرویس اطمینان بخش ( Service reliability ) و هزینه و غیره قابل ذکر و توجه است . موضوعات شامل :

برقراری تعادل بین اهداف برخوردی ، مانند اطمینان و هزینه و … ( Balancing Confilicting Goals )
مدیریت رخدادها ( Event Management )
مدیریت وقایع ( Incident Management )
مدیریت مشکلات ( Problem Management )
تکمیل رخدادها ( Event Fulfillment )
مدیریت دارایی ها ( Asset Management )
سرویس خدمات ( Service Desk )
مدیریت برنامه و تکنیکی ( Technical and Application Management )
نقش های کلیدی و مسئولیت کارکنان درگیر در عملیات سرویس ( key roles and responsibilities for staff engaging in Service Operation )
می شوند .

5. بهبود مداوم سرویس ( CSI – Continual Service Improvement )

5.1 شرح کوتاه

مرتب سازی و مرتب سازی دوباره سرویس های IT به منظور تغییر نیازهای تجاری انجام می شود ( به آن دلیل که ثبات ، باعث رو به زوال رفتن موسسه و یا تنزل آن می شود).
هدف بهبود مداوم سرویس ،‌ مرتب سازی و مرتب سازی دوباره سرویس های IT ، برای تغییر نیازهای تجاری ، بوسیله تعریف و پیاده سازی بهبودها در سرویس های IT یی است که فرآیند تجاری را پشتیبانی می کنند . دورنمای بهبود مداوم سرویس در بهبودها ، دورنمای تجاری کیفیت سرویس است ، حتی با اینکه بهبود مداوم سرویس ، می خواهد تاثیرات فرآیندها ، بازدهی و هزینه موثر فرآیندهای IT را در تمامی طول چرخه حیاتشان بهبود ببخشد . بر اساس بهبود مدیریت ، بهبود مداوم سرویس باید بصورت کاملا روشن و واضح ، تعریف کند که چه چیزی باید کنترل و اندازه گیری شود .

بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود . آنها نیازمند یک برنامه ریزی بالا به پیش رو ( upfront ) ، آموزش و اطلاع رسانی ، زمان بندی مداوم ، ایجاد نقش ها ، نسبت دادن به خود ، و فعالیت ها براساس میزان موفقیت شناسایی می شوند . بهبود مداوم سرویس باید مانند فرآیندها با فعالیت های تعریف شده ، ورودی ها ، خروجی ها ، نقش ها و گزارش ها برنامه ریزی و زمان بندی شود .

5.2 شرح کامل

مادامی که موسسه در حال شناسایی سرویس هایش است ( اینکه چه سرویس هایی دارد ) ، همچنین فرآیند توسعه و پیاده سازی مدیریت سرویس فن آوری اطلاعات ( ITSM – IT Service Management ) آن سرویس ها را قابل استفاده می نماید ، بسیاری بر این باورند که کار مشکل انجام شده است . آنها سخت در اشتباهند !!! کار واقعی تازه آغاز شده است . موسسات چگونه برای استفاده فرآیند جدید درگیر می شوند ( چگونه بر اساس فرآیند جدید کار می کنند ) ؟ موسسات چگونه می سنجند ، گزارش می گیرند و از اطلاعات برای بهبود نه تنها فرآیند های جدید بلکه بهبود مداوم سرویس های مهیا شده اقدام می کنند ؟ این کار مستلزم یک بحث خردمندانه برای آداپته کردن بهبود مداوم سرویس با ورودی ها ، خروجی ها و نقش های تعریف شده و مسئولیت ها و اهدافی است که بطور واضح تعریف شده اند و رویه هایی است که مستند شده اند ، می باشد . برای موفقیت ، بهبود مداوم سرویس باید با فرهنگ هر سازمان سازگار و بومی ( embed ) شود .

چرخه حیات سرویس یک معبر وسیع به مدیریت سرویس ( Service Management ) است : برای درک ساختار آن ، ارتباط مابین تمامی اجزای آن ، و اینکه چگونه تغییر در هر منطقه ( یا جایی ) بر روی تمامی سیستم و بخش های تشکیل دهنده ( که از آن به بعد ایجاد می شوند ) تاثیر گذار خواهد بود ، یک زیربنا و شالوده ( Framework ) سازمان یافته برای کارایی بهتر و قابل تحمل طراحی شده است .

چرخه حیات سرویس می تواند در یک قالب گرافیکی نمایش داده شود ، که در این حالت مقادیر را به راحتی می توان در دو شکل ” همکاری تجاری ( Business Contribution ) ” و ” سود و منافع ( Profit ) ” نشان داد . همکاری تجاری ، بیانگر توانایی یک سازمان IT برای پشتیبانی از یک فرآیند تجاری و مدیریت سرویس های IT با میزان کارایی درخواست شده است . سود و منافع ، بیانگر توانایی مدیریت هزینه های سرویس در ارتباط با درآمدهای تجاری است .

چرخه حیات سرویس را می توان مانند یک چرخه حیات فازبندی شده نمایش داد ، که این فازها عبارتند از :

تعریف استراتژی برای مدیریت سرویس IT ( که به آن استراتژی سرویس ( Service Strategy ) یا SS گفته می شود ) .
طراحی سرویس ها برای پشتیبانی از استراتژی ( که به آن طراحی سرویس ( Service Design ) یا SD )
پیاده سازی سرویس ها بر اساس نیازمندی های طراحی شده ( که به آن انتقال سرویس ( Service Transition ) یا ST )
پشتیبانی از سرویس های مدیریتی فعالیت های عملیاتی ( Support the Services Managing the Operational Activities ) یا ( که به آن عملیات سرویس ( Service Operation ) یا SO )
ارتباط بین فازها براساس بهبود مداوم سرویس ها مدیریت می شود ، که مسئولیت سنجش ( Measuring ) و بهبود سرویس ها و به کمال رسیدن فرآیندها را برعهده دارد . پس از مقایسه همه فازها ، یک بازه سرویس ( Service Period ) تمام می شود و یک بازه سرویس دیگر آغاز می شود .

فاز بهبود مداوم سرویس در تمام فازهای چرخه حیات سرویس درگیر می باشد . و مسئولیت سنجش سرویس و فرآیندها ( سنجش سرویس – Service Misurement ) ، و مستندسازی نتایج ( گزارش گیری سرویس – Service Reporting ) براساس بهبود کیفیت سرویس و سنجش فرآیندها ( بهبود سرویس – Service Improvement ) را بر عهده دارد . این بهبودها در بازه بعدی چرخه حیات سرویس پیاده سازی خواهند شد ، مجددا با استراتژی سرویس آغاز می شوند و سپس با طراحی سرویس و انتقال سرویس ، فاز عملیات سرویس البته برای عملیات مدیریتی درطول تمامی بازه های سرویس ادامه می یابد .

با تکامل بازه های سرویس ، ” سود و منافع ” برای هر فاز نگرانی استراتژیک و فازهای تاکتیکی ( استراتژی سرویس ( SS ) ، طراحی سرویس ( SD ) و انتقال سرویس ( ST ) را کاهش خواهد داد . در اینجا فاز عملیات سرویس ( SO ) بهینه سازی شده و نقش اصلی را برعهده می گیرد . در هر چرخه سرویس ( بازه سرویس ) سرویس با نتایج افزایش ارزش ( value ) تجاری و به حداکثر رساندن منافع بهبود خواهد یافت .

برطبق اصول همکاری تجاری ، سرویس های IT وقتی با ارزش می شوند ، که در قدم اول مرحله انتقال سرویس ( ST ) آغاز شود .

برطبق اصول سود و منافع ، در سرویس های IT مهمترین سرمایه گذاری ، نیازمند پیاده سازی بزرگ پروژه هاست ( ST ). هنگامی که انتقال ( Transition ) به اتمام می رسد و عملیات ( Operation ) آغاز می شود ، سرویس شروع می کند به پشتیبانی از فرآیندهای تجاری ، و درآمدهای جدید ، هزینه ها را تعدیل می کند . پس از چند بازه بهینه سازی سرویس ، ” سود و زیان ” شروع می کند به سودرسانی و به ” شکستن توانهای زوج ( break even point ) ” میل می کند .

پس از چند بازه ( بسته به پیچیدگی سرویس و انعطاف پذیری تجارت ) همکاری تجاری و سود و منافع ثابت می شوند ، که این بدان معناست که موسسات IT ، به سطح صحیحی از سنجش در مدیریت فرآیندها ، و سرویس به سطح صحیحی از کارایی در ملاقات نیازمندی های سطح سرویس ( performance in meeting the service level requirements ) رسیده اند .

منبع : ‌http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

ITIL v3 در ماه may ( خرداد ) 2007 منتشر شد و شامل پنج جلد کلیدی ( key volumes  )  است :

1. استراتژی سرویس ( Service Strategy )
2. طراحی سرویس ( Service Design )
3. انتقال سرویس ( Service Transition )
4. عملیات سرویس ( Service Operation )
5. بهبود مداوم سرویس ( Continual Service Improvement )

1. استراتژی سرویس ( Service Strategy )

استراتژی سرویس در مرکز ( هسته ) چرخه زندگی ITIL v3.1 قرار گرفته اما نمی تواند به تنهایی و بدون سایر بخش های ساختار IT  ایجاد شود . این بخش دربرگیرنده یک framework ( ‌زیربنا ) برای ایجاد تجربیات موفق ( best practices ) در اثر توسعه بلند مدت استراتژی سرویس است . این بخش شامل موضوعات مختلفی مانند :

• استراتژی عمومی ( General Strategy )
• رقابت و فضای بازار ( Competition and Market Space )
• انواع فراهم کنندگان سرویس ( Service Provider Types )
• مدیریت سرویس در نقش دارایی استراتژیک ( Service Management as a Strategic Asset )
• طراحی و توسعه سازمان ( Organization Design and Development )
• فعالیت های کلیدی فرآیندها ( Key Process Activities )
• مدیریت مالی ( Financial Management )
• مدیریت سرویس سهام ( Service Portfolio Management )
• و نقش های کلیدی و مسئولیت های کارکنان درگیر در استراتژی سرویس ( Key Roles and Responsibilities of Staff engaging in Service Strategy )

می باشد .

2. طراحی سرویس ( Service Design )

طراحی سرویس IT از تجربیات موفق ( Best Practice ) تبعیت می کند و شامل طراحی معماری ( Design of Architecture ) ، فرآیندها ، قوانین ( Policies ) ، مستندات و درنظر گرفتن نیازمندی های تجاری آینده است . این بخش همچنین شامل موضوعاتی مانند ،

• بسته طراحی سرویس ( SDP – Service Design Package ) 
• مدیریت سرویس فهرست ( Service Catalog Management )
• مدیریت سطح سرویس ( Service Level Management )
• طراحی برای مدیریت گنجایش ( Designing for Capacity Management )
• سرویس IT مداوم ( IT Service Continuity )
• امنیت اطلاعات ( Information Security )
• مدیریت ملزومات ( Supplier management )
• و نقش های کلیدی و مسئولیت کارکنان درگیر در طراحی سرویس ( key roles and responsibilities for staff engaging in service design  )

می باشد .

3. انتقال سرویس ( Service Transition )

انتقال سرویس به تحویل سرویس هایی مربوط می شود که نیاز تجاری فعال / عملیاتی ( Live\Operational use  )  دارند . و اغلب از بخش “پروژه” IT پیروی می کنند بجای تجارت مرسوم ( BAU – Business as Usual ) . این بخش همچنین موضوعاتی از قبیل :

• مدیریت تغییرات در محیطهای تجارت مرسوم ( Managing changes to the “BAU” environment  )
• دارایی سرویس ( Service Asset )
• مدیریت پیکربندی ( Configuration Management )
• برنامه ریزی و پشتیبانی انتقال ( Transition Planning and Support )
• مدیریت توسعه و نسخه ( Release and Deployment Management )
• مدیریت تغییرات ( Change Management )
• مدیریت دانش ( Knoweledge Management )
• نقش های کلیدی کارکنان درگیر در انتقال سرویس ( Key Roles of Staff engaging in Service Transition )

را شامل می شود .

4. عملیات سرویس ( Service Operation )

تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش ( agreed levels ) سرویس ها ، برای هردوی کاربران نهایی و مشتری هاست ( که “مشتری” به کسی گفته می شود که برای دریافت یک سرویس بهایی را پرداخت کرده باشند و در مورد ، توافق نامه سطح سرویس  ( SLA’s - Service Level Agreement  )  گفتگو کرده باشند ) . عملیات سرویس بخشی از چرخه زندگی است ، وقتی که سرویس ها و مقادیر ( value ) کاملا تحویل شده اند . همچنین ردگیری ( Monitoring ) مشکلات ( Problems ) و برقراری تعادل بین سرویس اطمینان بخش ( Service reliability ) و هزینه و غیره قابل ذکر و توجه است . موضوعات شامل :

• برقراری تعادل بین اهداف برخوردی ، مانند اطمینان و هزینه و … ( Balancing Confilicting Goals )
• مدیریت رخدادها ( Event Management )
• مدیریت وقایع ( Incident Management )
• مدیریت مشکلات ( Problem Management )
• تکمیل رخدادها ( Event Fulfillment )
• مدیریت دارایی ها ( Asset Management )
• سرویس خدمات ( Service Desk )
• مدیریت برنامه و تکنیکی ( Technical and Application Management )
• نقش های کلیدی و مسئولیت کارکنان درگیر در عملیات سرویس ( key roles and responsibilities for staff engaging in Service Operation )

می شوند .

5. بهبود مداوم سرویس ( CSI – Continual Service Improvement )

5.1 شرح کوتاه

 مرتب سازی  و مرتب سازی دوباره سرویس های IT به منظور تغییر نیازهای تجاری انجام می شود ( به آن دلیل که  ثبات ، باعث رو به زوال رفتن موسسه و یا تنزل آن می شود).
هدف بهبود مداوم سرویس ،‌ مرتب سازی و مرتب سازی دوباره سرویس های IT ، برای تغییر نیازهای تجاری ، بوسیله تعریف و پیاده سازی بهبودها در سرویس های IT یی است که فرآیند تجاری را پشتیبانی می کنند . دورنمای  بهبود مداوم سرویس در بهبودها ، دورنمای تجاری کیفیت سرویس است ، حتی با اینکه بهبود مداوم سرویس ، می خواهد تاثیرات فرآیندها ، بازدهی و هزینه موثر فرآیندهای IT را در تمامی طول چرخه حیاتشان بهبود ببخشد . بر اساس بهبود مدیریت ، بهبود مداوم سرویس باید بصورت کاملا روشن و واضح ، تعریف کند که چه چیزی باید کنترل و اندازه گیری شود .

بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود . آنها نیازمند یک برنامه ریزی بالا به پیش رو ( upfront  ) ، آموزش و اطلاع رسانی ، زمان بندی مداوم ، ایجاد نقش ها ، نسبت دادن به خود ، و فعالیت ها براساس میزان موفقیت شناسایی می شوند . بهبود مداوم سرویس باید مانند فرآیندها با فعالیت های تعریف شده ، ورودی ها ، خروجی ها ، نقش ها و گزارش ها  برنامه ریزی و زمان بندی  شود .

5.2 شرح کامل

مادامی که موسسه در حال شناسایی سرویس هایش است ( اینکه چه سرویس هایی دارد ) ، همچنین فرآیند توسعه و پیاده سازی مدیریت سرویس فن آوری اطلاعات ( ITSM – IT Service Management  ) آن سرویس ها را قابل استفاده می نماید ، بسیاری بر این باورند که کار مشکل انجام شده است . آنها سخت در اشتباهند !!! کار واقعی تازه آغاز شده است . موسسات چگونه برای استفاده فرآیند جدید درگیر می شوند ( چگونه بر اساس فرآیند جدید کار می کنند ) ؟ موسسات چگونه می سنجند ، گزارش می گیرند و از اطلاعات برای بهبود نه تنها فرآیند های جدید بلکه بهبود مداوم سرویس های مهیا شده اقدام می کنند ؟ این کار مستلزم یک بحث خردمندانه برای آداپته کردن بهبود مداوم سرویس با  ورودی ها ، خروجی ها و نقش های تعریف شده و مسئولیت ها و اهدافی است که بطور واضح تعریف شده اند و رویه هایی است که مستند شده اند ، می باشد . برای موفقیت ، بهبود مداوم سرویس باید با فرهنگ هر سازمان سازگار و بومی ( embed  ) شود .

چرخه حیات سرویس یک معبر وسیع به مدیریت سرویس ( Service Management  ) است : برای درک ساختار آن ، ارتباط مابین تمامی اجزای آن ، و اینکه چگونه تغییر در هر منطقه ( یا جایی ) بر روی تمامی سیستم و بخش های تشکیل دهنده ( که از آن به بعد ایجاد می شوند )  تاثیر گذار خواهد بود ، یک زیربنا و شالوده ( Framework ) سازمان یافته برای کارایی بهتر و قابل تحمل طراحی شده است .

 چرخه حیات سرویس می تواند در یک قالب گرافیکی نمایش داده شود ، که در این حالت مقادیر را به راحتی می توان در دو شکل ” همکاری تجاری ( Business Contribution  ) ” و ” سود و منافع ( Profit ) ” نشان داد . همکاری تجاری ، بیانگر توانایی یک سازمان IT برای پشتیبانی از یک فرآیند تجاری و مدیریت سرویس های IT با میزان کارایی درخواست شده است . سود و منافع ، بیانگر توانایی مدیریت هزینه های سرویس در ارتباط با درآمدهای تجاری است .

چرخه حیات سرویس را می توان مانند یک چرخه حیات فازبندی شده نمایش داد ، که این فازها عبارتند از :

• تعریف استراتژی برای مدیریت سرویس IT  ( که به آن استراتژی سرویس ( Service Strategy ) یا SS گفته می شود  ) .
• طراحی سرویس ها برای پشتیبانی از استراتژی ( که به آن طراحی سرویس ( Service Design )  یا SD  )
• پیاده سازی سرویس ها بر اساس نیازمندی های طراحی شده ( که به آن انتقال سرویس ( Service Transition ) یا ST )
• پشتیبانی از سرویس های مدیریتی فعالیت های عملیاتی ( Support the Services Managing the Operational Activities  ) یا ( که به آن عملیات سرویس ( Service Operation ) یا SO )

ارتباط بین فازها براساس بهبود مداوم سرویس ها  مدیریت می شود ، که مسئولیت سنجش ( Measuring ) و بهبود سرویس ها و به کمال رسیدن فرآیندها را برعهده دارد . پس از مقایسه همه فازها ، یک بازه سرویس ( Service Period ) تمام می شود و یک بازه سرویس دیگر آغاز می شود .

فاز بهبود مداوم سرویس در تمام فازهای چرخه حیات سرویس درگیر می باشد . و مسئولیت سنجش سرویس و فرآیندها ( سنجش سرویس – Service Misurement ) ، و مستندسازی نتایج ( گزارش گیری سرویس – Service Reporting  ) براساس بهبود کیفیت سرویس و سنجش فرآیندها ( بهبود سرویس – Service Improvement )  را بر عهده دارد . این بهبودها در بازه بعدی چرخه حیات سرویس پیاده سازی خواهند شد ، مجددا با استراتژی سرویس آغاز می شوند و سپس با طراحی سرویس و انتقال سرویس ، فاز عملیات سرویس البته برای عملیات مدیریتی درطول تمامی بازه های سرویس ادامه می یابد .

با تکامل بازه های سرویس ، ” سود و منافع ” برای هر فاز نگرانی استراتژیک و فازهای تاکتیکی ( استراتژی سرویس ( SS ) ، طراحی سرویس ( SD ) و انتقال سرویس ( ST ) را کاهش خواهد داد . در اینجا فاز عملیات سرویس ( SO ) بهینه سازی شده و نقش اصلی را برعهده می گیرد . در هر چرخه سرویس  ( بازه سرویس ) سرویس با نتایج افزایش ارزش ( value ) تجاری و به حداکثر رساندن منافع بهبود خواهد یافت .

برطبق اصول همکاری تجاری ، سرویس های IT وقتی با ارزش می شوند ،  که در قدم اول مرحله انتقال سرویس ( ST ) آغاز شود .

برطبق اصول سود و منافع ، در سرویس های IT  مهمترین سرمایه گذاری ، نیازمند پیاده سازی بزرگ پروژه هاست ( ST ). هنگامی که انتقال ( Transition  ) به اتمام می رسد و عملیات ( Operation  )  آغاز می شود ، سرویس شروع می کند به پشتیبانی از فرآیندهای تجاری ، و درآمدهای جدید ، هزینه ها را تعدیل می کند . پس از چند بازه بهینه سازی سرویس ، ” سود و زیان ” شروع می کند به سودرسانی و به ” شکستن توانهای زوج ( break even point  )  ” میل می کند .

پس از چند بازه ( بسته به پیچیدگی سرویس و انعطاف پذیری تجارت ) همکاری تجاری و سود و منافع ثابت می شوند ، که این بدان معناست که موسسات IT ، به سطح صحیحی از سنجش در مدیریت فرآیندها ، و سرویس به سطح صحیحی از کارایی در ملاقات نیازمندی های سطح سرویس ( performance in meeting the service level requirements  )  رسیده اند .

منبع : ‌http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

Service Desk مهمترین قابلیت و کاربرد IT Service Management ( ITSM ) بر اساس تعاریف Information Technology Infrastructure Library ( ITIL ) می باشد . و برای ایجاد یک نقطه اشتراک ( Single Point of Contact – SPOC ) بین کاربران و راضی نگه داشتن مشتری ها و راهم کنندگان خدمات IT بوجود آمد . تعداد بیشماری از سازمانها ، یک نقطه ارتباطی مشترک را برای پاسخگویی به مشتری ها ، کاربران و افراد مرتبط ( کاربر یا User به کسی گفته می شود که از سرویس استفاده می نماید و مشتری یا Customer به کسی اطلاق می شود که در ازای دریافت سرویس مبلغی را پرداخت کرده است ) ایجاد کرده اند . قابلیت های Service Desk به چند بخش تقسیم می شود . که شامل :

• Call Center – نقطه تماس مرکزی
• Contact Center – نقطه ارتباط مرکزی
• Help Desk – بخش پشتیبانی
• Service Desk – بخش ارائه  سرویس و خدمات

از دیدگاه ITIL تنها نقطه ارتباطی مابین فراهم کننده سرویس ( ارائه کننده خدمت ) و مشتری یا کاربر ( سرویس گیرنده ) ServiceDesk است . همچنین ServiceDesk یک نقطه مرکزی برای گزارش Incident ها ( رخدادها ) و اشخاصی است که درخواست دریافت سرویس ( Service request ) دارند . Service Desk رخدادها ( Incident ) و درخواست های سرویس ( Service Request ) را هندل کرده و با استفاده از یک رابط کاربری ، سایر فعالیت های ITSM را ( که در زیر لیست شده ) پشتیبانی می کند :

• Incident Management – مدیریت رخدادها
• Problem Management – مدیریت مشکلات
• Configuration Management – مدیریت تنظیمات ( پیکربندی ها )
• Change Management – مدیریت تغییرات
• Release Management – مدیریت ارائه شده ها ( نسخه نهایی محصول که به بازار ارائه می شود )
• Service Level Management – مدیریت سطح سرویس
• Availability Management – مدیریت موجودی ها ( داشته ها – آن چیزهایی که در دسترس است )
• Capacity Management – مدیریت ظرفیت
• Financial Management – مدیریت مالی
• IT Service Continuty Management – مدیریت سرویس هایIT دنباله دار
• Security Management – مدیریت امنیت

Service Desk به سرعت زیادی کاربران را از رخدادهای سرویس – فعالیت های انجام شده بر روی آن – تغییرات مطلع می کند . Service Desk در خط مستقیم تمامی اتفاقات مهم قرارداد سطح سرویس ( Service Level Agreement – SLA ) و آنجایی که باید تغییرات ، طرح ها و دردسترس نبودن سرویس ها به سرعت انجام شود ، قرار دارد .

Service Desk با نقطه تماس مرکزی ( Call Center ) ، نقطه ارتباط مرکزی ( Contact Center ) و یا Help Desk متفاوت استو این تفاوت دردید مرکز گرایانه و وسعت بیشتر آن است که تلاش می کند که نیازهای ICT کاربران را تنها و تنها فقط از یک نقطه مرکزی اداره کند . Service Desk تلاش می کند تا یکپارچگی فرایند تجارت ( Business Process ) را در قالب و چارچوب مدیریت سرویس ها ( Service Management Infrastructure ) تسهیل نماید . با توجه به مانیتور کردن فعالانه و مالکیت رخدادها و درخواست کاربران و فراهم کردن یک کانال ارتباطی برای دیگر نظام های مدیریت های سرویس ( Service Management Deciplines ) با جامعه کاربران یک Service Desk  یک واسط برای فعالیت های دیگری مانند درخواست تغییرات کاربران ، برنامه های دیگر ( third Party ) و درخواست های مجوز نرم افزار ( Software Licensing Request ) فراهم می کند .

اهداف ServiceDesk عبارتند از :

• فراهم کردن یک نقطه ارتباطی مشترکبرای تمامی مشتری ها .
• تسهیل بازیابی سرویس های عملیاتی معمولی با حداقل میزان اهمیت ( impact ) تجاری برای مشتری هایی که قراردادهای سطح سرویس – SLA - را پذیرفته اند و با توجه به میزان اهمیت تجاری .

کاربردهای معمول Service Desk عبارتند از :

• دریافت تماس ها ، اولین گروه پاسخگوی مشتری ها
• ضبط و پیگیری رخدادها و شکایات
• مطلع کردن مشتری ها از وضعیت درخواست و مرحله پردازش
• اظهار نظر کردن ابتدایی برای درخواست ، سعی در حل آن و یا ارجاع آن به شخصی که می تواند مشکل را حل کند
• مانیتور کردن و پاسخگویی و حل مشکل در بازه زمانی مشخص شده در قرارداد سطح سرویس – SLA .
• شناسایی مشکلات
• حل ( بستن ) مشکلات و گرفتن تاییدیه از مشتری
• هماهنگ کردن پشتیبانی سطح دوم و سوم

                    چنانچه مشاهده می شود درخواست های سرویس که با Service Desk پیگیری می شوند یک فرآیندهستند ، درحالی که ITIL پیشنهاد می کند ( می گوید ) که Service desk یک کاربرد ( Function ) است و نه یک فرایند ( Process ) .

منبع : http://en.wikipedia.org/wiki/Service_Desk_(ITSM)

Service Desk مهمترین قابلیت و کاربرد IT Service Management ( ITSM ) بر اساس تعاریف Information Technology Infrastructure Library ( ITIL ) می باشد . و برای ایجاد یک نقطه اشتراک ( Single Point of Contact – SPOC ) بین کاربران و راضی نگه داشتن مشتری ها و راهم کنندگان خدمات IT بوجود آمد . تعداد بیشماری از سازمانها ، یک نقطه ارتباطی مشترک را برای پاسخگویی به مشتری ها ، کاربران و افراد مرتبط ( کاربر یا User به کسی گفته می شود که از سرویس استفاده می نماید و مشتری یا Customer به کسی اطلاق می شود که در ازای دریافت سرویس مبلغی را پرداخت کرده است ) ایجاد کرده اند . قابلیت های Service Desk به چند بخش تقسیم می شود . که شامل :

• Call Center – نقطه تماس مرکزی
• Contact Center – نقطه ارتباط مرکزی
• Help Desk – بخش پشتیبانی
• Service Desk – بخش ارائه  سرویس و خدمات

از دیدگاه ITIL تنها نقطه ارتباطی مابین فراهم کننده سرویس ( ارائه کننده خدمت ) و مشتری یا کاربر ( سرویس گیرنده ) ServiceDesk است . همچنین ServiceDesk یک نقطه مرکزی برای گزارش Incident ها ( رخدادها ) و اشخاصی است که درخواست دریافت سرویس ( Service request ) دارند . Service Desk رخدادها ( Incident ) و درخواست های سرویس ( Service Request ) را هندل کرده و با استفاده از یک رابط کاربری ، سایر فعالیت های ITSM را ( که در زیر لیست شده ) پشتیبانی می کند :

• Incident Management – مدیریت رخدادها
• Problem Management – مدیریت مشکلات
• Configuration Management – مدیریت تنظیمات ( پیکربندی ها )
• Change Management – مدیریت تغییرات
• Release Management – مدیریت ارائه شده ها ( نسخه نهایی محصول که به بازار ارائه می شود )
• Service Level Management – مدیریت سطح سرویس
• Availability Management – مدیریت موجودی ها ( داشته ها – آن چیزهایی که در دسترس است )
• Capacity Management – مدیریت ظرفیت
• Financial Management – مدیریت مالی
• IT Service Continuty Management – مدیریت سرویس هایIT دنباله دار
• Security Management – مدیریت امنیت

Service Desk به سرعت زیادی کاربران را از رخدادهای سرویس – فعالیت های انجام شده بر روی آن – تغییرات مطلع می کند . Service Desk در خط مستقیم تمامی اتفاقات مهم قرارداد سطح سرویس ( Service Level Agreement – SLA ) و آنجایی که باید تغییرات ، طرح ها و دردسترس نبودن سرویس ها به سرعت انجام شود ، قرار دارد .

Service Desk با نقطه تماس مرکزی ( Call Center ) ، نقطه ارتباط مرکزی ( Contact Center ) و یا Help Desk متفاوت استو این تفاوت دردید مرکز گرایانه و وسعت بیشتر آن است که تلاش می کند که نیازهای ICT کاربران را تنها و تنها فقط از یک نقطه مرکزی اداره کند . Service Desk تلاش می کند تا یکپارچگی فرایند تجارت ( Business Process ) را در قالب و چارچوب مدیریت سرویس ها ( Service Management Infrastructure ) تسهیل نماید . با توجه به مانیتور کردن فعالانه و مالکیت رخدادها و درخواست کاربران و فراهم کردن یک کانال ارتباطی برای دیگر نظام های مدیریت های سرویس ( Service Management Deciplines ) با جامعه کاربران یک Service Desk  یک واسط برای فعالیت های دیگری مانند درخواست تغییرات کاربران ، برنامه های دیگر ( third Party ) و درخواست های مجوز نرم افزار ( Software Licensing Request ) فراهم می کند .

اهداف ServiceDesk عبارتند از :

• فراهم کردن یک نقطه ارتباطی مشترکبرای تمامی مشتری ها .
• تسهیل بازیابی سرویس های عملیاتی معمولی با حداقل میزان اهمیت ( impact ) تجاری برای مشتری هایی که قراردادهای سطح سرویس – SLA - را پذیرفته اند و با توجه به میزان اهمیت تجاری .

کاربردهای معمول Service Desk عبارتند از :

• دریافت تماس ها ، اولین گروه پاسخگوی مشتری ها
• ضبط و پیگیری رخدادها و شکایات
• مطلع کردن مشتری ها از وضعیت درخواست و مرحله پردازش
• اظهار نظر کردن ابتدایی برای درخواست ، سعی در حل آن و یا ارجاع آن به شخصی که می تواند مشکل را حل کند
• مانیتور کردن و پاسخگویی و حل مشکل در بازه زمانی مشخص شده در قرارداد سطح سرویس – SLA .
• شناسایی مشکلات
• حل ( بستن ) مشکلات و گرفتن تاییدیه از مشتری
• هماهنگ کردن پشتیبانی سطح دوم و سوم

                    چنانچه مشاهده می شود درخواست های سرویس که با Service Desk پیگیری می شوند یک فرآیندهستند ، درحالی که ITIL پیشنهاد می کند ( می گوید ) که Service desk یک کاربرد ( Function ) است و نه یک فرایند ( Process ) .

منبع : http://en.wikipedia.org/wiki/Service_Desk_(ITSM)

As empresas de tecnologia já fizeram seu papel quando transformaram seu negócio de hardware para serviços.
Hoje, estamos acompanhando as empresas de telecomunicações que seguem o mesmo caminho: transformando suas tradicionais ofertas de telefonia e circuitos, também em serviços. Se juntas, caminham para se tornarem empresas TIC – Tecnologia da Informação e Comunicação.

Essas transformações acontecem num momento onde a customização de serviços e de soluções, cada vez mais se tornam um diferencial, tanto na oferta para empresas como também na segmentação dos consumidores. Ou seja, cada vez mais estão altamente direcionadas e individualizadas.

Entendido esses momentos recentes, fica fácil assimilar por que o SLM era algo cujas atenções eram mínimas. Nessa transição de empresas de hardware e telefonia para serviços, os primeiros contratos e respectivas soluções ainda tiveram que passar por um árduo processo de aprendizado tanto por parte dos Provedores como dos Clientes.

Agora, hoje em dia, isso vem mudando acentuadamente dos dois lados:

No lado do Cliente, ele aprendeu e acumulou experiência suficiente para entender que sua estratégia de sucesso deve considerar o Outsourcing de TI e Telecomunicações para preencher suas necessidades de negócios. Ele já teve sua experiência na contratação desses serviços e, no momento da renovação do seu contrato atual, já considera procedimentos como RFI, RFP e metodologias de gestão de contratação e gestão de contratos como fatores a serem considerados na hora de decidir se faz essa renovação ou se opta por outro Provedor.

Olhando pelo lado do Provedor, podemos dizer que o aprendizado ocorreu na mesma proporção. Desde aspectos de re-engenharia organizacional, com foco em Serviços, nas transformações de suas métricas de SLO (Service Level Objective) em métricas de SLA (Service Level Agreement), enfim, podemos citar inúmeras situações. Uma delas é considerar que os resultados de determinados contratos geridos pelo SLM, já podem ser associadas ás regras que determinam o perfil de remuneração variável de sua organização. Como exemplo, podemos considerar que os indicadores de pesquisa de satisfação de Clientes, podem e devem exercer uma importante influência na composição da remuneração variável dos executivos ligados diretamente á qualidade da Prestação de Serviços.

Agora chegou o momento de o Cliente e o Provedor investirem na importância de considerar o SLM – Service Level Management como uma disciplina mandatória como fator de sucesso desses contratos e estratégias de avaliação de seus Provedores.
Antes de refletirmos sobre o SLM, estamos assumindo que existe por parte de ambos, Cliente e Provedor, um esforço anterior para identificar uma significativa cumplicidade entre as Empresas. O Provedor deve entender bastante sobre processos, cultura, rotinas e funcionamento do Cliente. Deve se dedicar á conhecer os Consumidores e Mercado desse Cliente. Somente assim, a Solução do Provedor terá o nível de customização pretendido por esse Cliente e, os indicadores de SLA irão refletir o resultado desse entendimento.

Vividas essas duas etapas, chegamos ao SLM. O SLM será responsável por gerenciar as métricas, de forma automatizada e profissional, considerando ferramentas, processos e metodologias pré-acordas e, com isso, fornecerá informações que irão determinar se o contrato está sendo respeitado por ambas as partes, se os indicadores de desempenho realizados estão em linha com os indicadores pretendidos, se o contrato está gerando penalidades excessivas. Enfim, o SLM irá tangibilizar em números as expectativas em relação ao serviço contratado.
O SLM demonstra compromisso com Governança Corporativa entre as Empresas e, para tal deve se tornar uma disciplina mandatória e indispensável nos contratos de Outsourcing e/ou Prestação de Serviços Gerenciados. Pode também, ser inserido nas estratégias de remuneração de executivos nas Empresas, influindo positivamente nos aspectos de bonificação variável conforme metas atingidas em contratos regidos por SLM.

SLM não é uma simples ferramenta de operações e de gestão de performance.Se bem implementada, torna-se um indicador financeiro dos seus objetivos estratégicos e um forte aliado na imagem de um Provedor que agrega valor ao negócios do seu Cliente.

O Cliente que exige o SLM e o Provedor que fornece SLM, estão dando exemplos de maturidade no segmento da Prestação de Serviços.

Abraços, Fabiano Facó

Nesses últimos meses andei pesquisando e ouvindo bastante como as Empresas Integradoras ou Provedoras (ou será que já podemos chamá-las de Empresas TIC?) estão estruturadas para atuar na disciplina de SLM no que diz respeito a contratos com seus Clientes.

Foi exatamente a partir dessa percepção que resolvi usar esse título nada criativo, porém, informativo. Por quê? Vamos aos porquês!

- Muitas delas ainda não praticam a disciplina de SLM em seus Contratos, sejam eles de Outsourcing ou Serviços Gerenciados. Em alguns casos, mesmo havendo o compromisso contratual em prática-lo.

- Muitas chamam o SLO de SLA e vice-versa.

- Muitas delas que já o praticam, executam-no ainda de forma bastante manual, demandando enorme esforço de profissionais e o uso de ferramentas que ainda não se relacionam corretamente entre si. Ou seja, podemos dizer, de forma artesanal.

Aqui está o momento que explica o título: a falta do uso de uma ferramenta específica para uma das principais disciplinas desse contrato, o SLM, causa uma demora em média de uns 10 dias para sua conclusão.

Durante esses dias equipes de profissionais se utilizam de planilhas eletrônicas e dados de diferentes ferramentas, para montar o cenário de SLM daquele contrato, daquele mês, daquele respectivo Cliente.

Enfim, vou me desculpar aqui, mas não vou contar os 10 passos e dias que levam para se concluir aquele SLM, pois não estaria dando nenhuma contribuição. Podemos sim, dar um salto para compartilhar os benefícios de uma Gestão de SLM, onde os profissionais estariam envolvidos somente na análise dos resultados e na criação de um plano de ação, ou seja, pensando e gerando valor.

Essa tarefa deve e pode ser delegada para uma ferramenta apropriada, moldada ao seu negócio, que interaja com as demais ferramentas de gerenciamento da sua Empresa. Essa mesma ferramenta estaria executando a função de garimpar as informações necessárias, executando as devidas correlações e entregando, de forma executiva, uma fotografia comparando o que consta no contrato versus o que foi realizado pela sua área de Operações. Ou seja, se o SLA foi ou não atendido.

Você Cliente, pergunte ao seu provedor como ele está cuidando do seu SLA. Antes, esteja preparado para ouvir a resposta, porque se o seu Provedor não está lhe entregando um SLM, que administra as informações para saber se o SLA foi ou não atendido, com a devida automação, você deve estar preparado para lhe pedir isso.

Cabe lembrarmos que “O que não é medido, não é gerenciado“, portanto vamos direcionar o foco e olhar para o SLM como uma disciplina de negócio e não meramente como uma ferramenta técnica.

No SLM sabemos se estamos entregando aquilo que assinamos no contrato com nossos Clientes. Também, no SLM, sabemos se estamos pagando multas excessivas que podem comprometer a lucratividade do nosso contrato e, principalmente a nossa relação de longo prazo com esse Cliente.

Abraços, Fabiano Facó

The IT Infrastructure Library (ITIL) is a series of eight books and is referred to as the only consistent and comprehensive best practice for IT service management to deliver high-quality IT services. Although produced and published by a single governmental body, ITIL is not a standard and is generally referred to as a framework.  There is a lot of work involved in tailoring an implementation to any organization. The published books (subject to change my mid-2007) are:

• Software Asset Management
• Service Support
• Service Delivery
• Planning to Implement Service Management
• ICT Infrastructure Management
• Application Management
• Security Management
• Business Perspective, Volume II

There are two main operational components or logical groupings within ITIL, with Security Management completing the underpinning for both groups are:

• Service Support (activities that are more or less performed daily)
• Service Delivery (activities that tend to take place monthly or quarterly, but at a minimum annually)

ITIL Process Overview

BUSINESS DRIVERS FOR IMPLEMENTING

ITIL is usually implemented subject to one or more of the following business cases:

• Defining of service processes within the IT organization
• Defining and improving the quality of services
• Need to focus on the customer of the IT
• Implementation of a central help desk function

There are several methods in approaching an implementation of ITIL and having done several operations assessments, I can attest that the two main building blocks that have to be solid are Configuration Management and Change Management.  Both gear their activities off a Configuration Management Data Base (CMDB).  If the CMDB does not exist or if Change Management is a haphazard process, then the other processes within ITIL tend to fail on a regular basis.  Recently more and more vendors are creating products geared specifically towards CMDB (e.g., HP, CA, BMC, etc.) that address a method to collect all of the configuration specifics of your environment.  If you don’t know what you have, it will be problematic when implementing any change, but you can never been certain of the effect of the change.Two principal concepts characterize the basic thinking of ITIL:

• Service management—IT service managers:
  • Assure the consideration of requirements for operations and maintenance
  • Develop test plans
  • Identify the effects on existing infrastructure caused by new or modified systems
  • Define future requirements
• Customer orientation—IT services are to be provided at a level of quality that allows permanent reliance on them. To assure this quality, responsibility is assigned to individuals who:
  • Consult the users and help them use the services in an optimal approach
  • Collect and forward opinions and recommendations of users
  • Track complaints
  • Monitor the users’ appraisals of the services delivered
  • Support internal user groups

  Technorati