1. Альтернатива: каталог сервісів
2. Складові успіху каталогу сервісів
3. література

Сьогодні процеси ITIL операційного рівня, перш за все управління інцидентами, конфігураціями і змінами, вже не рідкість в російських компаніях, але значно рідше можна зустріти процеси тактичного рівня: управління рівнем сервісу, доступністю, потужностями і т.д. Такий стан спостерігається не тільки в Росії, зокрема, аналітики Gartner відзначають: «ITIL v.2 традиційно впроваджувався відділами підтримки ІТ-інфраструктури, яким було комфортно зосередитися саме на процесах підтримки сервісів, таких як управління інцидентами, змінами і конфігураціями» [1] . Чому так сталося?

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

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

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

Альтернатива: каталог сервісів

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

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

Хоча оцінка вартості сервісу в ITIL формально відноситься до сфери процесу управління витратами, включення вартісних оцінок в каталог дуже бажано. Бізнес зацікавлений у зіставленні витрат і результатів, а не в знанні того чи іншого окремо. За інших рівних умов впровадити один процес простіше, ніж два, тому на етапі впровадження каталогу сервісів розумніше включити вартісні оцінки саме в нього. Пізніше, якщо буде потрібно розвиток управління витратами, ці два процеси можна розділити.

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

Каталог сервісів не менш корисний і ІТ-службі - перш за все, він дозволяє «спрямити» процес обговорення ІТ-бюджету, доповнити неминучий торг обговоренням кількісної зв'язку між поточними і майбутніми вимогами до обсягу і якості ІТ-сервісів, з одного боку, і ресурсів, необхідних для цього ІТ-службі - з іншого. В результаті у відповідь на вимогу скоротити операційний бюджет ІТ-служба отримує можливість задати протверезний питання: «добре, підтримку яких сервісів ми тепер можемо скоротити або припинити зовсім?» [3]. Слід звернути увагу, що таке використання каталогу в обов'язковому порядку передбачає його узгодження з бізнесом в процесі впровадження, в іншому випадку важко забезпечити необхідний рівень довіри.

При необхідності перегляду бюджету каталог дозволяє розподілити скорочення на підтримувані сервіси. При цьому зниження витрат на сервіс може йти по лінії зниження рівня сервісу (наприклад, скорочення часу обслуговування до 8 × 5), обсягу (наприклад, скорочення числа користувачів), або накопичення ризиків (наприклад, відмова від технічної підтримки). Скорочення проводиться з обов'язковим урахуванням пріоритетів бізнесу, також зафіксованих в каталозі сервісів. Далі, за результатами скорочення з каталогу знову «збирається» сервісний бюджет.

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

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

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

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

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

Таким чином, каталог сервісів дозволяє отримати критично важливий для бізнесу та ІТ-служби ефект - узгоджене зіставлення результатів і витрат. Аллокаціонной модель оцінки витрат дозволяє в кілька разів знизити витрати на впровадження та подальшу підтримку процесу. При цьому точність розрахунку нижче, ніж в кращих моделях, і перш за все в моделі РТК (розрахунково-технологічна карта [4]), але зате перші результати можуть бути отримані набагато швидше. Нарешті, ніщо не заважає оцінити отримані результати пізніше, в ході їх практичного використання. Якщо бізнес або ІТ-служба вважатимуть їх точність неприйнятною, тоді можна буде впровадити потрібні експлуатаційні процеси з твердою впевненістю в їх необхідності.

Складові успіху каталогу сервісів

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

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

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

В результаті проект повинен вийти на деякий розумний рівень деталізації, що влаштовує замовника і виконавця, центральний апарат і підрозділи (філії).

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

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

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

І останнє - необхідно використовувати адекватні інструменти автоматизації. У великої багатофіліальної організації каталог може включати в себе 100-200 сервісів, кілька сот об'єктів витрат і десятки тисяч записів аллокации. Подібний масштаб вимагає автоматизації, але, на жаль, в більшості засобів автоматизації, таких як HP Service Manager, BMC Remedy або Axios Assyst, присутній тільки власне список сервісів, що не включає функціональність розрахунку витрат на них. Для цієї ситуації можна запропонувати розрахункову систему, орієнтовану на підтримку аллокаціонной моделі і включає функціональність збору даних, розрахунку витрат по аллокаціонной моделі і базовий набір звітів: за витратами на сервіси, по аллокации договорів і співробітників, за складом і структурі об'єктів витрат.

***

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

література

1. Implementing ITIL v.3: Theory Versus Reality, Gartner research ID G00171788, 29 жовтня 2009.
2. Hank Marquis. Effective Project Management, ITIL and BSM. CIO Update, June 09, 2010 року.
3. І. Баринов, С. Растопшіна, К. Скрипкін. Підстава: каталог послуг в управлінні ІТ-службою. ITSM-альманах, 2010 року.
4. Е. Аксьонов, І. Альтшулер. Аутсорсинг: 10 заповідей і 21 інструмент. СПб: Пітер 2009.

Кирило Скрипкін ( [email protected] ) - доцент кафедри економічної інформатики економічного факультету МГУ.