Зрозуміти itil - значить правильно застосовувати - центр тестування

Сьогодні всі говорять про ITIL. Всі цікавляться ITIL. Створюється враження, що ITIL - це панацея від усіх бід. Однак ITIL - НЕ Біблія і не скрижаль. Вона швидше нагадує Камасутру, що дає кваліфіковані поради, як отримати найбільший ефект в області певних відносин. Але щоб скористатися цими порадами, недостатньо одного бажання - необхідна наявність певних фізіологічних і фізичних можливостей.

Чим викликаний такий бурхливий інтерес до ITIL? Тим, що в сучасному світі жодна компанія не може вижити без інформаційних технологій, і тим, що довгий час інформаційні технології розглядалися як один з ключових чинників, що забезпечують стратегічну перевагу на ринку.

Сервісна модель забезпечує перехід від управління інфраструктурами до управління сервісами. Якщо управління інфраструктурою фокусується на операційній доступності компонентів, то управління сервісами - на потребах клієнта. Операційна інформація про стан інфраструктури критично важлива, але недостатня. Багато ІТ-організації інтуїтивно усвідомлюють необхідність зв'язати свої дії з бізнесом клієнта, але часто не можуть прийняти рішення, як далеко треба йти. Сервісна модель дозволяє ІТ-організації менше фокусуватися на інфраструктурі та інформаційних системах і в більшій мірі - на забезпеченні бізнес-результатів клієнта.

Сервісна модель в своєму найбільш концентрованому вираженні відображає суть системи управління сервісами, основою якого, відповідно до ITIL v.3 (книга Service Strategy), є акт перетворення ІТ-ресурсів в сервіси, що представляють цінність для тих, кому вони виявляються (для зовнішніх або внутрішніх клієнтів). Без цього ІТ-організація - це просто певна кількість ресурсів, що саме по собі має відносно низьку внутрішню цінність для клієнтів. Управління сервісами є професійною практикою, яка підтримується сукупністю знань, досвіду і навичок. Нова версія ITIL вперше розглядає управління сервісами як один із ключових активів сервіс-провайдера. Мета управління сервісами - зробити доступні виробничі можливості і ресурси ІТ-організації корисними клієнту у формі сервісів з прийнятним рівнем якості, вартості та ризиків.

Багато керівників ІТ-організацій розуміють ІТ-сервіс як надання бізнесу ІТ-інфраструктури та інформаційних систем і управління цими активами для забезпечення їх доступності та безперервності роботи. Відповідно, основний фокус робиться на структури звітності та ресурси, призначені цим структурам. Однак, відповідно до ITIL v.3 сервіси - це сукупність дій, що приносять клієнту цінність, сприяють отриманню результату, якого клієнт хоче досягти, не несучи відповідальності за специфічні витрати і ризики. Сервіси завжди пов'язані з виконанням певних завдань і наявністю певних обмежень. Сервіси визначають взаємовідносини між клієнтом і ІТ-організацією. Головна помилка - фокусуватися на інфраструктурі і функціях ІТ, а не на тому, як сервіс інтерпретується і сприймається клієнтом.

Для ілюстрації цієї тези можна скористатися прикладом системи запам'ятовуючих пристроїв з книги "Service Strategy". Оперативна пам'ять (пам'ять) використовується для зберігання, організації або захисту інформації в контексті деякої діяльності, завдання або роботи. Оперативна пам'ять створює також такі корисні умови: легкість доступу, ефективну організацію або захист від загроз. Ця проста модель притаманна багатьом типам запам'ятовуючих пристроїв, кожне з яких спеціалізовано для підтримки конкретного типу результату, потрібного клієнту. Можна просто надати пристрій клієнту, а можна запропонувати йому сервіс по зберіганню інформації. В останньому випадку ІТ-організація бере на себе вирішення питань "що зберігати" (інформацію, файли, бази даних і т.д.) і "як зберігати" (база даних в режимі онлайн, портативні пристрої, екрановані шафи і т.д. ). При цьому принципово важливо розмежування обов'язків клієнта і сервіс-провайдера.

Але все це ІТ-сервіс, а не аутсорсинг бізнес-процесу. Клієнт зберігає відповідальність за виконання замовлень на покупку в режимі онлайн. Але він не відповідає за функціонування та обслуговування відмовостійких конфігурацій запам'ятовуючих пристроїв, виділених і резервних джерел живлення, роботу ІТ-персоналу, відповідність вимогам безпеки, аварійні заходи або оптимізацію проблем з невикористовуваними потужностями при несподіваних сплесках попиту. Сервіс-провайдер приймає на себе володіння і розподіляє витрати і ризики по кожній одиниці зберігання, використовуваної клієнтом запам'ятовує.

Цінність такого ІТ-сервісу для клієнта полягає не тільки в функціональності онлайнового зберігання, але і в легкому доступі до інформації в відмовостійкості пристрої зберігання даних (як і коли це буде потрібно) при забезпеченні конфіденційності, цілісності і доступності даних.

Таке визначення сервісу рухає ІТ-організацію до фокусування ІТ на завданнях і потреби бізнесу, в ідеальному варіанті - до інтеграції ІТ з бізнесом. Концентрація на результатах бізнесу, а не на чому-небудь ще, є критично важливим фактором успіху ІТ-організації. Це означає зміщення акцентів від ефективного використання ІТ-ресурсів до ефективному досягненню результатів. Тут доречно ще раз процитувати ITIL v.3: "Клієнти не купують сервіси - вони купують здійснення конкретних потреб". Ця різниця пояснює часту роз'єднаність між ІТ-організаціями та їх клієнтами. Те, що цінує клієнт, часто відмінно від того, що поставляє ІТ-організація. Про це треба завжди пам'ятати.

Життєвий цикл сервісу і сервісна модель

Наведений приклад допомагає зрозуміти, чому ITIL v.3 можна розглядати як модель побудови системи надання ІТ-сервісів. Пропонована ITIL v.3 модель сервісної системи заснована на життєвому циклі сервісу. Це принципово нова концепція представляє корінна відмінність ITIL v.3 від попередньої версії. Кожен том ядра ITIL v.3, яке складають книги (див. Малюнок) Service Design, Service Transition і Service Operation, описує певну фазу життєвого циклу сервісу. Книга Service Strategy представляє політики і цілі реалізації сервісів. Книга Continual Service Improvement присвячена накопиченню досвіду і вдосконалення сервісу.

Подібно будь-який інший моделі, сервісна модель вимагає адаптації до специфіки та конкретних потреб організації.

Місце на ринку і роль ІТ-організації у величезній мірі визначається її активами. При традиційному підході активи - це елементи інфраструктури, інформаційні системи і обслуговуючі їх люди. Відповідно до ідеології ITIL v.3 до цих активів додаються й інші стратегічні активи: керівництво, адміністрування, політики, метрики ефективності роботи і стимули, а також процеси надання та підтримки сервісу: активні конфігурації людей, процесів, програм та інфраструктури. Нематеріальні активи включають функціональні ієрархії, а також системи, які використовуються людьми для спільної роботи по досягненню загальних цілей, і стимули. До стратегічних нематеріальних активів, як згадувалося, відноситься і управління сервісами. Такі стратегічні активи створюють конкурентну перевагу і ринкову диференціацію ІТ-організації.

Що означає впровадження ITIL?

Часто кажуть: "Ми впровадили ITIL" або "Ми впровадили кілька процесів ITIL" (наприклад, управління рівнем обслуговування, управління конфігураціями і т.д.). А що означає впровадити ITIL? Або процес? Які критерії самого факту впровадження та / або його успішного завершення?

Тут необхідно зупинитися ще на одному важливому аспекті. Сьогодні на ринку доступний широкий спектр інструментальних засобів управління ІТ-сервісами. За заявою виробників, всі ці кошти підтримують основні процеси ITIL і мають модулі, навіть за назвою орієнтовані на конкретні процеси. Багато ІТ-організації щиро вважають, що запровадивши ці модулі, вони впровадили ITIL.

На мій погляд, тут є певна небезпека. Такі ІТ-організації орієнтуються на функціональні можливості інструментальних засобів і організують свої процеси відповідно до цими коштами. Насправді, необхідно вибудувати свою власну логіку, свою модель ІТ-сервісу, визначити необхідні для реалізації цієї моделі процеси і підібрати інструментарій, який в найкращій мірі відповідає поставленому завданню.

Книги ядра ITIL v.3 описують сукупність процесів. Процеси мають конкретні результати - отримання результату є причиною існування процесу. Щоб сформувати критерії впровадження ITIL, непогано задати собі питання: "А що я хочу отримати в результаті впровадження?". Припустимо, що ви маєте всю необхідну підтримку з боку вищого керівництва, вам навперебій пропонують ресурси, гроші, обладнання, приміщення. Чи можете ви чітко сказати, які продукти процесу збираєтеся отримати на виході, чи можуть вони розглядатися як переконливі докази самого факту впровадження? При цьому не можна обмежитися найменуванням і переліком цих продуктів. Слід визначити їх структуру, контент і форму подання.

Чітке визначення структури та контенту робочих продуктів процесу допоможе встановити зрозумілі критерії впровадження і уникнути розбіжностей в питаннях результативності впровадження.

Розглянемо як приклад один з основоположних процесів сервісної моделі - управління рівнем сервісу. Цей процес має три вихідних продукту: каталог сервісів, угоди про рівень сервісу і сервісну звітність. Спробуємо визначити структуру і контент робочого продукту на прикладі каталогу сервісів.

Спочатку приймаємо рішення, що каталог сервісів повинен описувати всі надані послуги і їх основні характеристики. Отже, розробку каталогу почнемо з визначення послуг, які ІТ-підрозділ надає своїй компанії або сервіс-провайдер своєму клієнтові. З самого початку приймемо, що має значення те визначення послуги, яке зрозуміло користувачам.

Як вимоги до цього робочого продукту встановимо, що каталог сервісів визначає ієрархію послуг і включає в себе бізнес-функції, їх зв'язок з необхідними ІТ-процесами і ресурсами. Каталог сервісів буде мати таку структуру:

Класифікатор послуг з описами і рівнями обслуговування.

Основні регламенти взаємодії клієнта і виконавця (регламент замовлення).

Стандартні пакети сервісного обслуговування.

Критерії оцінки послуг, що надаються.

Каталог сервісів повинен містити інформацію про саму послугу і про рівні сервісу, зрозумілі клієнтові принципи ціноутворення, інформацію про замовленні послуги, регламент її виконання, процедури ескалації. Необхідно також визначитися, в якому форматі буде виконаний каталог сервісів (Microsoft World, Excel або у вигляді онлайн-каталогу).

Чітке визначення вихідного продукту процесу є необхідною, але недостатньою умовою впровадження процесу. Вихідні продукти не повинні без діла лежати на полиці. Вони повинні використовуватися в масштабах організації, систематично оновлюватися, повинен проводитися моніторинг їх ефективного використання. Для каталогу сервісів критеріями впровадження процесу є такі питання:

чи використовується каталог сервісів як механізм замовлення сервісу;

визначає він політики, керівні вказівки і звітність;

визначає він цілі кожного сервісу;

діє він як портал закупівель для клієнтів, включаючи ціноутворення та зобов'язання за рівнем сервісу, а також умови та норми надання сервісу;

чи використовується він при розробці рішень для клієнтів, що включають один або більше сервісів.

Описувані ITIL-практики засновані на досягненнях передових фірм, тому ITIL багатьма розглядається як фактичний стандарт, однак стандартом ITIL не є. ITIL швидше можна уподібнити Камасутрі, яка дає кваліфіковані поради, як отримати найбільший ефект в області певних відносин. Але щоб скористатися цими порадами, недостатньо одного бажання. Необхідна наявність певних фізіологічних і фізичних можливостей.

ITIL розрахована, в першу чергу, на освоєння передових практик фахівцями, які виконують процеси, однак ці фахівці далеко не завжди можуть впливати на рішення по організації і вдосконалення процесів. ITIL передбачає певну систему сертифікації конкретних фахівців, але не торкається питань сертифікації системи управління ІТ-сервісами.

Чи потрібна формальна сертифікація, якщо система управління ІТ-сервісами створена, діє і дає реальні результати? Що дає компанії наявність сертифіката? Сертифікація є добровільним актом і пов'язана з певними витратами, однак сертифікат дає компанії реальні вигоди. По-перше, це підтвердження незалежною стороною ефективності діючої в компанії системи управління ІТ-сервісами. По-друге, це впевненість клієнта в правильному виборі виконавця і / або співвиконавця. По-третє, це підтвердження статусу компанії. Не можна опускати з розгляду і таку важливу обставину, як вимога наявності сертифікату в офіційних тендерах.

"Підготовка до сертифікації включає в себе вивчення продуктів і технологій. Можливо доведеться вивчати ті частини з якими ви ще не працювали. Для нових технологій дуже складно визначити те, на що слід звернути особливу увагу. І ось тоді важливо використовувати рекомендації для складання іспитів на сертифікацію . Саме вони допоможуть вам сконцентруватися на головному. "

Jonathan Blair, MCSD for .NET Edinburgh, Scotland

Tony Neuser, Director of the Microsoft Solutions Practice for Unisys Global Network Services, Unisys Corporation

"Пропонуючи новий проект, іноді досить просто вказати, скільки фахівців в компанії мають сертифікат MCSD, щоб підкреслити наскільки серйозно Compaq проводить технічну експертизу."

Mark King, Solutions Architect, Compaq Computer Corporation

Новини по темі