Як виглядає IT-служба до ITSM - і чому найняти ще одного адміністратора не допомагає
Понеділок, дев'ята ранку. У IT-відділу вже 40 повідомлень у трьох месенджерах, бухгалтерія двічі попросила те саме різними каналами, а ноутбук, який «точно був на складі», в обліку досі числиться за звільненим співробітником. Це типовий вигляд підтримки, де правила живуть у головах інженерів, а не в системі.
Впровадження ITSM починається не з вибору системи, а з єдиної точки входу для заявок, каталогу послуг і обліку активів. GLPI закріплює ці правила в щоденній роботі. Повний набір практик ITIL для старту не потрібен: достатньо трьох-чотирьох ITSM процесів, запущених у правильному порядку.
ITSM (IT Service Management) - це підхід, за якого IT-відділ працює як постачальник послуг: з переліком того, що він робить, правилами прийому звернень і зобов'язаннями щодо термінів.
Хаос у підтримці - це проблема відсутніх правил, а не браку людей. Новий адміністратор у тому ж хаосі просто розбирає більше повідомлень, але не зменшує їх кількість. Саме тому впровадження GLPI без попередньої домовленості про правила перетворює систему на ще один «чат» із гіршим інтерфейсом. Нижче - послідовний шлях, який команда TechExpert проходить разом із клієнтами: від підготовки до метрик, за якими видно результат.
Чому не варто впроваджувати ITIL цілком
Міф: щоб працювати за ITSM, потрібно впровадити ITIL повністю. Реальність: ITIL 4 описує 34 практики управління - 14 загальних, 17 сервісних і 3 технічні. У 2026 році почав поступово запускатись ITIL 5: за офіційним поясненням ITIL там залишаються ті самі 34 практики, здебільшого без змін, згруповані в дві групи.
Компанії з IT-відділом на 5–15 людей на старті не потрібна й третина цього переліку. Типовий сценарій «все й одразу» виглядає так: півроку піде на регламенти, жоден із них не запрацює, і команда повернеться до месенджерів. Після такого досвіду бізнес сприймає будь-яку ініціативу з порядку як бюрократію.
Працює інший підхід: обрати три-чотири практики, які знімають найбільший біль, і запускати їх послідовно. Кожен наступний процес спирається на дані попереднього, тому порядок важливіший за повноту. Якщо ви ще не знайомі з базовою логікою, почніть із матеріалу про те, що таке ITSM і для чого автоматизують управління IT-послугами.
Що зробити до встановлення GLPI: три рішення, які ухвалює керівник, а не система
Технічне розгортання займає кілька днів, а підготовка - тижні, і саме вона визначає результат. GLPI безкоштовний як програма, проте цей етап найдорожчий за часом, і його неможливо купити разом із ліцензією. Спершу потрібно ухвалити три рішення:
- Канали прийому заявок. Визначте, які залишаються (портал, пошта, телефон), а які закриваються. Поки месенджери відкриті, частина заявок і надалі йтиме повз систему.
- Каталог послуг. Каталог IT-послуг - це перелік того, що IT-відділ робить для бізнесу, з умовами: хто може замовити, за скільки часу виконують, хто відповідальний. Для старту достатньо 15–30 позицій зрозумілою користувачу мовою: «Новий співробітник: робоче місце», а не «Provisioning».
- Власник процесу. Це одна людина, яка має право змінювати правила й відповідає за їх виконання. Без неї навіть ідеально налаштований ITSM на базі GLPI за пів року перетвориться на архів застарілих домовленостей.
Ці рішення не потребують коду, але вимагають розмов із керівниками інших підрозділів. Тому на цьому етапі корисний зовнішній консультант, який знімає внутрішні суперечки про те, «як у нас заведено».
Чому ми обрали Moodle 5.0 як основу рішення
Moodle є найпоширенішою у світі відкритою системою управління навчанням: за даними офіційної статистики Moodle, платформа працює на майже 147 тисячах зареєстрованих сайтів у 236 країнах і обслуговує понад 530 мільйонів користувачів. Для державного замовника важливо, що Moodle розповсюджується за ліцензією GPL, не вимагає щорічних ліцензійних платежів і не прив’язує заклад до одного постачальника.
Ми розгорнули актуальну на момент старту проєкту версію Moodle 5.0.1, яка отримала оновлену архітектуру, покращений інтерфейс і розширені інструменти для викладачів. Модульна будова платформи дозволяє додавати функціональність через плагіни та власні розширення, не змінюючи ядро системи, тому заклад зберігає можливість безпечно оновлюватися до нових релізів. Саме ця гнучкість Moodle дала змогу реалізувати генератор розкладу, документообіг і інтеграцію з КЕП як окремі компоненти, що не конфліктують зі стандартними модулями.
Не менш важливо, що навколо Moodle існує величезна спільнота розробників, документація українською мовою та тисячі готових плагінів. Це означає, що навіть після завершення проєкту заклад не залишається наодинці з унікальною «закритою» системою, яку ніхто, крім автора, не здатен підтримувати.
Перший процес - заявки: як за місяць отримати одну точку входу
Перший із ITSM процесів, який варто запустити, - обробка звернень. Розділіть їх на два типи з першого дня: інцидент - це «не працює», а запит на обслуговування - це «потрібно». У них різні терміни, різні виконавці й різна логіка пріоритетів, тому змішування двох типів в одному потоці знову породжує хаос.
Що налаштовують у GLPI на цьому етапі:
- категорії заявок (достатньо 10–20, а не 200);
- правила автоматичного призначення на групи виконавців;
- шаблони заявок з обов'язковими полями;
- пріоритети на основі впливу й терміновості;
- портал самообслуговування для користувачів.
Цей крок суттєво спростила нова версія: у GLPI 11, що вийшла наприкінці вересня 2025 року, з'явилися вбудовані форми та новий портал самообслуговування. Телефон - окремий канал: дзвінок має ставати заявкою автоматично, інакше значна частина звернень знову губиться. Для цього використовують інтеграцію GLPI з IP-телефонією Asterisk.
Метрика етапу проста: частка звернень, зареєстрованих у системі, а не «в чаті».
SLA без бюрократії: які терміни обіцяти й як їх рахувати
SLA (Service Level Agreement) - це зафіксована домовленість про терміни та якість послуги. Починайте з двох-трьох рівнів пріоритету й двох показників: часу реакції та часу вирішення. Складні матриці з десятками комбінацій залиште на пізніше, коли з'являться реальні дані.
Головне правило: перші SLA ставлять за фактичними даними першого етапу, а не за побажаннями. Саме тому SLA - другий етап, а не перший. Якщо обіцяти «реакція за 15 хвилин», не знаючи, що сьогодні вона триває дві години, перший же звіт покаже провал і підірве довіру до всієї ініціативи.
Для керівника IT SLA - це аргумент у розмові з бізнесом. Замість «у нас багато роботи» з'являється формулювання на кшталт «ми закриваємо 87% запитів вчасно» (це приклад формулювання, а не статистика).
У GLPI SLA пов'язують з робочим календарем, щоб час не «біг» вночі й у вихідні. Також налаштовують ескалації та нагадування: система сама попереджає виконавця, коли термін наближається, і підключає керівника, якщо його порушено. Так впровадження ITSM процесів переходить від домовленостей на словах до керованих зобов'язань.
Облік техніки й CMDB: як зв'язати заявку з конкретним комп'ютером
Третій етап - активи. Замість Excel використовують інвентаризацію агентом: він автоматично збирає дані про залізо, встановлене ПЗ і ліцензії. Вручну вносять лише те, що агент не бачить: відповідального, підрозділ і місце розташування.
CMDB (база конфігураційних одиниць) - це структурований облік активів і зв'язків між ними, який показує, від чого залежить кожна послуга. Вона корисна лише тоді, коли заявки вже проходять через систему. Тоді зв'язок «заявка - пристрій» дає історію поломок і основу для рішень про заміну: видно, що один принтер за квартал викликав дев'ять заявок, і дешевше його замінити (це ілюстративний приклад).
Ще одна перевага GLPI 11 - вбудовані власні типи активів, які створюються без плагінів.
Типова пастка - спроба занести в CMDB усе, включно з мишами й кабелями. Такий облік неможливо підтримувати, і за місяць він застаріває. Вносьте те, що має вартість, ліцензію або вплив на послугу. Усе інше краще рахувати кількісно на складі, а не поштучно. Такий підхід робить ITSM на базі GLPI корисним інструментом, а не ще одним реєстром.
Коли база вже працює: проблеми, зміни й база знань
Цей етап вмикають, коли перші три стабільні - за оцінкою практиків TechExpert, зазвичай через 3–6 місяців після старту. Термін залежить від масштабу компанії й варто узгодити з конкретним замовником.
Управління проблемами починається з повторюваних інцидентів. Якщо одна й та сама помилка трапляється вп’яте, треба шукати першопричину, а не вдесяте перезапускати сервіс.
Управління змінами відповідає на питання, хто погоджує зміну в інфраструктурі й як не «покласти» сервіс у п’ятницю ввечері. Достатньо простого маршруту: опис, оцінка ризику, погодження, вікно робіт.
База знань працює у двох напрямках. Інструкції для користувачів зменшують кількість типових звернень, а статті для інженерів зберігають експертизу, коли людина йде з компанії.
Окремо варто виділити багатоетапні ITSM процеси: онбординг нового співробітника чи зміну доступів виконують кілька людей, часто паралельно. Для таких сценаріїв у GLPI є процеси з кількома виконавцями та паралельними етапами, що знімає ручну координацію в чатах.
П'ять причин, через які впровадження ITSM буксує
У проєктах, які зупинилися, повторюються одні й ті самі помилки:
- Немає власника процесу. Правила ніхто не оновлює, категорії й маршрути розходяться з реальністю, і система старіє за пів року. Інженери повертаються до звичних способів роботи, а керівник втрачає єдине місце, де видно навантаження команди.
- Залишили «запасний» канал. Особисті повідомлення інженеру «для терміновості» створюють другий потік, невидимий для статистики. Користувачі швидко дізнаються, що так швидше, і обходять портал, тому звіти втрачають сенс.
- Перенесли хаос у систему. 200 категорій заявок, з яких реально використовують 12, змушують користувача гадати, що обрати. Наслідок - неправильна класифікація, помилкова маршрутизація та зайві перепризначення.
- SLA поставили до появи даних. Амбіційні терміни без фактичної бази дають провальний перший звіт. Команда сприймає показники як покарання, а не як інструмент, і починає їх ігнорувати.
- Не навчили користувачів. Систему налаштували, але не пояснили, навіщо вона їм. Люди бачать додаткову бюрократію, а не швидшу допомогу, тому далі телефонують знайомим інженерам.
Висновок простий: технічна частина впровадження GLPI рідко ламається. Ламається організаційна.
Метрики, за якими видно результат через 3 і 6 місяців
Порядок у підтримці можна перевірити цифрами, а не відчуттями. Після впровадження ITSM варто відстежувати невеликий набір показників, який пов’язаний з етапами впровадження.
|
Метрика |
Що показує |
Орієнтир через 3 міс. |
Орієнтир через 6 міс. |
|
Частка звернень у системі |
що канали-«запасні» закриті |
понад 90% |
понад 95% |
|
Заявки, закриті в межах SLA |
дисципліну виконання |
зафіксовано базовий рівень |
зростання до узгодженої цілі |
|
Час першої реакції |
швидкість підтримки |
вимірюється для всіх пріоритетів |
скорочується відносно базового |
|
Активи з автоматичною інвентаризацією |
повноту обліку |
понад 70% |
понад 90% |
|
Частка повторних інцидентів |
зрілість управління проблемами |
розпочато облік |
стабільно зменшується |
|
Оцінка задоволеності користувачів |
сприйняття сервісу |
запущено опитування |
стабільний тренд |
Ці орієнтири - стартові приклади, а не гарантії: фактичні цілі визначають за вашими даними після першого етапу. Такий набір дає керівникові прозору картину для розмови з бізнесом і показує, куди далі рухатися розвитку ITSM процесів.
Як TechExpert впроваджує ITSM на GLPI
TechExpert працює з GLPI з 2014 року і реалізує впровадження для комерційних та державних структур різного рівня. Команда виступає і інтегратором, і консультантом: допомагає ухвалити організаційні рішення етапу 0, налаштувати систему та навчити користувачів.
Є два шляхи старту:
- коробковий Service Desk на базі GLPI - для швидкого запуску з типовими процесами;
- впровадження ITSM-процесів на GLPI під вашу компанію - коли потрібні власний каталог послуг, SLA та інтеграції.
Щоб зрозуміти, з чого починати, достатньо побачити поточну картину. Замовте аудит поточної підтримки: ми покажемо, як заявки надходять сьогодні та скільки з них губиться, і запропонуємо план перших кроків. Залиште запит на techexpert.ua або запишіться на консультацію - відповімо протягом робочого дня.
Часті запитання про впровадження ITSM на GLPI
Перший процес - одну точку входу для заявок - зазвичай можна запустити приблизно за місяць. Всі три базові етапи - заявки, SLA та активи - займають кілька місяців. Це орієнтир, який залежить від масштабу компанії та готовності керівників ухвалювати рішення.
За експертизу, а не за ліцензію: каталог послуг, процеси, SLA, інтеграції, навчання користувачів і подальший супровід. Додатково враховують інфраструктуру: сервер або хмарний хостинг.
Не обов'язково. Достатньо, щоб власник процесу розумів основні принципи, а команда дотримувалась узгоджених правил. Сертифікація корисна, але не є умовою старту.
Заявки (інциденти та запити) і каталог послуг, потім прості SLA та облік активів. Проблеми, зміни та базу знань краще відкласти до моменту, коли перші три вже працюють стабільно.
Так. Дані про техніку імпортують з таблиць або збирають агентом інвентаризації. Історію заявок зазвичай переносять вибірково: активні звернення та те, що дійсно потрібне для аналізу.
Власний сервер дає повний контроль над даними і підходить, коли є вимоги безпеки, зокрема в державному секторі. Хмара швидше стартує й зменшує навантаження на адміністрування. Вибір залежить від вимог до захисту даних та ресурсів команди.
