Як ми впроваджуємо ITSM. Чотири вади обслуговування


Ми вирішили поділитися досвідом від впровадження цієї непростої методології всередині нашої компанії і плануємо написати ряд статей про те, як впроваджуємо ITSM, які труднощі долаємо, і які рішення у нас є. Сподіваємося, що статті будуть цікаві IT-менеджменту.

Трохи передісторії. Ми працюємо у великому холдингу, основна діяльність якого: продаж медикаментів в роздробі. Більшість IT-продуктів для управління холдингом розробляються в ньому самому. Холдинг рідко купує програмні продукти на стороні (якщо мова йде про автоматизацію основних бізнес-процесів компанії)

У нас великий IT-департамент, який складається з декількох груп розробки, системних адміністраторів, архітекторів, Service desk, сб і т. д.

У певний момент IT-департамент став отримувати просто гігантську кількість скарг на роботу ІТ-служб і після довгих обговорень ми вирішили впроваджувати ITSM-підходи всередині компанії. Ми провели аналіз скарг внутрішніх клієнтів IT-департаменту і виділили основні. Ось що вийшло.

Пінг-Понг
У цієї проблеми є цілий ряд назв: «Перекладання відповідальності», «Проблема не на моїй стороні» і т. д.

Припустимо, є автоматизоване робоче місце касира («Каса»). Програмне забезпечення для даного робочого місця розроблено всередині компанії. В один прекрасний момент з «Каса» відбувається якийсь збій, заводиться інцидент, який відправляється в Service Desk.

Оскільки ЗА «Каса» розробляється відповідним відділом і співробітники Service Desk не можуть самостійно вирішити проблему, то Service Desk направляє інцидент у відділ розробки каси.

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

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



Пінг-Понг дуже часте явище в сфері обслуговування. Гірше того часто Пінг-Понг призводить до міжособистісних конфліктів.

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

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

Наприклад, відбувається масовий інцидент з «Каса», який зачіпає всі точки продажу (аптеки в нашому випадку). В одній з аптек інцидент помітили раніше і повідомили про це в Service Desk. Service Desk зрозумів масовість інциденту, але забув повідомити про це всім зацікавленим особам. Як мінімальне наслідок — шквал дзвінків на 1-шу лінію підтримки.


Необхідність пояснювати проблеми двічі
Майже будь-якого клієнта дико дратує, коли доводиться пояснювати проблеми двічі. Дана проблема проявлялася:

  1. Внутрішній клієнт ІТ департаменту повідомляє про проблему Service Desk.
  2. Співробітник Service Desk приймає проблему і починає займатися її усуненням.
  3. Внутрішній клієнт починає нервувати, оскільки не отримує інформації про хід вирішення інциденту.
  4. Внутрішній клієнт повторно дзвонить в Service Desk і потрапляє на іншого працівника, який не в курсі проблеми.
  5. Слід питання «А чому у вас проблема?»
  6. Внутрішній клієнт IT-департаменту в гніві.


Неправильна пріоритезація інцидентів

Неправильна пріоритезація — це ще одна банальна проблема, яку доводиться вирішувати в рамках впровадження проекту.

Два однакових інциденту надходять з різних торгових точок. У торгової точки по вул. Руська товарообіг в рази перевищує торгову точку в п. Врангель. Інцидент з Врангеля надходить раніше і буде робитися раніше, оскільки співробітник Service Desk тупо не в курсі фінансових показників торгових точок. Як наслідок, з'являється чергу усунення інцидентів, не відповідає інтересам бізнесу.



Рішення

Що ми реалізували, щоб вирішити ці проблеми.

Перше, найважливіше і банальне — зробили каталог IT-послуг. Ми розплутали клубок незрозумілого IT-сервісу, зробивши його прозорішим для замовника і для себе.



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

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

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



Єдина відповідальність сама по собі виключає пінг-понг, але породжує невдоволення і внутрішній опір: «Чому я повинен відповідати за роботу адмінів».



Насправді тут все дуже просто. Хтось надає послугу, хто її споживає. Споживачеві послуги наплювати на те, з яких причин послуга не надається. Споживач хоче послугу, за яку заплатив віртуальні гроші.

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

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



Погане інформування. Рішення

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

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

Співробітник повинен інформувати клієнта в рамках інциденту. Для цього ми реалізували кнопку «Інформувати», яка може відправляти повідомлення відразу по декількох каналах та логирует надіслані повідомлення в інциденті.



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

Необхідність пояснювати проблеми двічі. Рішення
Рішення придумали, але поки не реалізували.

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

Чекаємо впровадження нової ip-телефонії і відразу будемо робити інтеграцію з нашим Service Desk.

Неправильна пріоритезація інцидентів. Рішення
Ми реалізували можливість створювати скрипти впливу в нашій системі. Скрипт являє собою дерево питань, на які повинен відповісти співробітник Service Desk, класифікуючи інцидент.

Кожен скрипт прикріплюється до послуги.

Скрипти розробляють і адмініструють співробітники 2-ої лінії підтримки. Саме ці співробітники володіють необхідними компетенціями і більшою зацікавленістю в правильній пріоритезації інцидентів.

Ось приклад скрипта:



Співробітник 1-ої лінії, класифікуючи інцидент, прощелкивает скрипт.



Скрипт допомагає визначити вплив інциденту на конкретну послугу. Пріоритет інциденту визначається з поєднання впливу і терміновості (в кращих традиціях ITSM).



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



Післямова

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

У наступних статтях я планую більш глибоко поринути у ITSM підхід і його реалізацію в нашому програмному забезпеченні. Є кілька тем, які я хотів би описати. Буду радий, якщо ви підкажіть мені, що б вам було цікаво. Ось теми:

  • Проблеми взаємодії ліній підтримки і їх рішення.
  • Каталог послуг.
  • Організаційні зміни при впровадженні ITSM.
  • Інтерфейс інциденту.
  • Мотивація працівника 1-ої лінії підтримки.
  • Життєвий цикл інциденту.


Подарунки


Презентація

Перед початком впровадження ITSM ми зібрали всіх замовників та влаштували їм невелику презентацію проекту. Презентація вийшла шикарна, все на момент опинилися у щасливому майбутньому. Можливо вона буде корисна тим, хто збирається впроваджувати ITSM у себе в компанії. Тому тримайте посилання на слайди:

docs.google.com/presentation/d/18m_SzZ7C8Dbkypncp7-sKZLQeGYkZ9PuKbxEp2QIVU0/edit?usp=sharing

Знижка

Ми досить давно і успішно продаємо наші рішення. Вони славляться низькою вартістю і гнучкість налаштування.
Знижка до 30% буде діяти до 21 листопада.

Взяти demo-версію плагіна Service Desk

Всім спасибі!
Джерело: Хабрахабр

0 коментарів

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