ITSM. Що ми зрозуміли про послуги

Як було зрозуміло з минулої статті «Чотири вади обслуговування», ми активно впроваджуємо ITSM підходи в нашій компанії. Сьогодні хотілося б поговорити про те, з чого зазвичай починається впровадження ITSM в компанії — про каталозі послуг.

Виділення послуг виявилося не зовсім простим завданням і ми зіткнулися з масою труднощів:
  • Можна приймати за ІТ-послугу програмний комплекс чи ні?
  • Як виділити єдиного відповідального, якщо послуга складова і підтримується двома програмними комплексами?
  • Як визначати за якою послугу зареєструвати інцидент, якщо звалилася ІТ-інфраструктура в цілому і майже всі послуги не надаються.


Ось яких принципів ми дотримуємося при виділенні будь-якої послуги:

  • Будь-яка послуга повинна мати єдиного відповідального, який повністю відповідає за її якість (своєчасне усунення інцидентів, доступність і т. д.)
  • Назва та опис послуги повинні бути зрозумілі кінцевого споживача (внутрішнього клієнта) і при цьому послуга повинна надавати зрозумілу цінність.
  • Діюча послуга повинна підтримувати як мінімум один бізнес-процес.


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

Будь-яка послуга повинна мати єдиного відповідального, який повністю відповідає за її якість
Логічно ніби все зрозуміло. Якщо не буде єдиного відповідального, то не виключена проблема втрати відповідальності і подальший пінг-понг в усуненні інцидентів, про який я писав у попередній статті.

Але як визначити відповідального за складову послугу. Наприклад, є послуга У1, суть якої надання інтерфейсу до певного набору даних. Є програмне забезпечення П1, яке розробляє відділ О1. Програмне забезпечення П1 тільки відображає дані, що надаються в рамках послуги У1, для всіх співробітників компанії. Всі дані для програмного забезпечення П1 надає програмне забезпечення П2, яке розробляє відділ О2.

Хто є єдиним відповідальним за послугу У1?

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

Що це означає?

Інтерфейсний принцип визначення відповідальності
Відповідальний за послугу = відповідальної за додаток, в якому внутрішній клієнт споживає послугу.

Чому? Тому що для клієнта не повинна бути зрозуміла внутрішня архітектура послуги. Клієнт споживає послугу У1, використовуючи інтерфейс програми П1 і якщо з послугою щось не так, то буде страждати імідж співробітника, відповідального за програму П1 (імідж програми П1). І тут вже не важливо, що 80% проблем з даними в програмі П1 пов'язані з тим, що програма П2 погано вивантажує дані.

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



Назва послуги повинно бути зрозуміло кінцевому споживачу і відображати зрозумілу клієнту цінність
З першою частиною все має бути зрозуміло. З клієнтом потрібно спілкуватися на зрозумілій йому мові, в загальному. А зокрема, називати послуги так, як вони будуть зрозумілі клієнта.

Не треба використовувати у назвах послуг імена протоколів передачі даних і тому подібні технічні терміни.

Наприклад, замість послуги «Передача повідомлень по протоколу XMPP» краще використовувати «Сервіс передачі миттєвих повідомлень»

Одного разу я відкрив методичку з фізичного практикуму і у другому абзаці прочитав наступне:

"Інжектованих в базу дірки повинні дифундувати в напрямку колектора"

Треба бути простіше і тоді буде зрозуміліше.

З назви послуги клієнту повинна бути зрозуміла цінність. Наприклад, послуга «Автоматизація касових операцій» несе зрозумілу клієнту цінність. А послуга «Мережа передачі даних» немає. Не зрозуміло в чому цінність такої послуги для звичайного пересічного користувача. Навіщо йому передавати дані !? Яку цінність він отримає !?

ITIL досить строго визначає поняття цінності:



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

Даний принцип вберігає нас від внесення в каталог послуг того, що там бути не повинно: внутрішніх послуг (таких, наприклад, як ЛОМ, віртуальні сервера тощо)

Нещодавно зайшов на сайт nalog.ru і побачив, що щоб отримати податкове вирахування потрібно спожити послугу «Заповнити довідку 3НДФЛ» така послуга не несе цінність. По-перше 3НДФЛ термін бухгалтерський і незрозумілий, по-друге, абсолютно незрозуміло в чому цінність послуги. А ось послуга «Повернути 13% від суми медичних витрат» несла б цінність.

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

Саме цей принцип навів нас на думку про те, що програмний комплекс у самому загальному випадку не можна приймати за ІТ-послугу. Програмний комплекс може бути замінений іншим програмним комплексом, при цьому послуга залишається незмінною. Наприклад, послуга «Телефонія» підтримує бізнес-процеси в call-центрі. При заміні одного програмно-апаратного комплексу ip-телефонії іншим, послуга не повинна змінюватися. Тому, послуги «IP-телефонія Oktell» у нас немає.

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

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

Наприклад, є додаток RM+, яке реалізує різні аспекти управління компанією: Розрахунок ефективності та нарахування ЗП, Планування, Запит послуг (Service Desk) і т. д.

Різні модулі програми RM+ підтримують різні бізнес-процеси компанії. Тому і різні послуги.



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



Тому в даному випадку, послуга у нас одна — «Електронна пошта».

Є ще один 4-ий принцип, про який явно не написав на початку статті.

Якщо обвалився шматок інфраструктури, то інциденти потрібно заводити з тим послуг, які клієнт не може спожити в поточний момент.

Розглянемо на прикладі, що це означає.

Припустимо клієнт споживає три послуги: Послуга 1 Послуга 2, Послуга 3. Всі три послуги безпосередньо залежать від внутрішньої послуги: «Мережа передавання даних» (даної послуги немає в каталозі послуг користувача).

Припустимо, що відбувається з кореневим світче. Внутрішня послуга «Мережа передачі даних» перестає надаватися. Слідом за нею перестають надаватися послуги з каталогу послуг: Послуга 1 Послуга 2, Послуга 3.

Кінцеві клієнти нічого не знають про Послугу «Мережа передачі даних». Всі три послуги з каталогу послуг в поточний момент не працюють. З якоїсь послуги Service Desk повинен завести інцидент від кінцевого клієнта, по якій послузі мають застосуватися SLA-норми усунення інциденту і т. д.?



Наша відповідь: По тій, яку прямо зараз хоче, але не може спожити клієнт і з внутрішньої, про яку клієнт нічого не знає. В даному випадку послугами: «Послуга 3» і внутрішньої послуги «Мережа передачі даних». Якщо інші послуги клієнта не працюють, але він і не намагається їх використати, то за ним інциденти можна не заводити.

Це все, чим хотілося б поділитися в рамках даної статті. Сподіваюся, вам сподобалося. Спасибі!

Трохи подарунків


Знижка 20% на плагін Service Desk, який допоможе надавати послуги згідно ITSM-підходу у вашій компанії, а також реалізує багато інших корисних речей.

Знижка діє протягом 3 тижнів.

Наші плагіни для Redmine використовуються по всьому світу і славляться своєю гнучкістю і низькою вартістю.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.