Чому «IT-відділ і так працює» — це не система, а везіння

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

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

ITIL простими словами: довідник, а не програма

ITIL (Information Technology Infrastructure Library) — це збірка описаних практик управління IT-послугами, яку компанії використовують як зразок для побудови власних процесів. Це не програмне забезпечення, не обов’язковий стандарт і не сертифікат відповідності для компанії. Це радше довідник на тему «як це влаштовано в тих, у кого воно працює».

Бібліотека з’явилася наприкінці 1980-х як розробка британського державного агентства, а згодом стала міжнародною практикою. Її головна ідея звучить майже банально: IT-відділ надає послуги внутрішнім замовникам так само, як це робив би зовнішній підрядник. А в послуги є вимірювані характеристики — канал звернення, час реакції, час відновлення, відповідальний.

Що змінюється, коли в обслуговуванні з’являються правила

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

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

Є і менш очевидний ефект: змінюється характер розмови між керівництвом і IT. Замість «зробіть щось, у нас усе гальмує» з’являється предметне обговорення — які саме послуги не витримують заявленого рівня, скільки це коштує компанії й що потрібно, щоб виправити. Це переводить IT з категорії витрат у категорію керованих ресурсів.

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

Три слова, які варто розуміти нетехнічному керівнику

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

SLA (Service Level Agreement) — письмова домовленість про те, за який час IT-відділ реагує на звернення і за який відновлює роботу. Саме з розбору цих трьох понять зазвичай і починається навчання ITIL та COBIT для керівників, які не працюють в IT, але залежать від нього щодня. SLA не робить підтримку швидшою автоматично — він робить очікування взаємно зрозумілими.

ITIL 4 і ITIL 5: що змінилося у 2026 році

У лютому 2026 року PeopleCert, власник фреймворка, випустив ITIL Version 5 — першу велику зміну від 2019 року. Оновлення переносить акцент із сервісів на продукти, додає окремий напрям з управління штучним інтелектом і розширює модель життєвого циклу. Спеціалізовані модулі виходили поетапно протягом весни.

Для компаній це не привід терміново все переробляти: сертифікати ITIL 4 залишаються дійсними, а обидві версії певний час існуватимуть паралельно. Тому курси з управління IT сьогодні пропонують обидва треки, і вибір залежить від того, чи в компанії вже є діючі процеси, чи їх тільки збираються будувати. У Навчальному центрі «Мережні Технології», наприклад, ITIL 4 і ITIL 5 читають паралельно саме з цієї причини.

З чого починати, якщо у вас 20 людей, а не 2000

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

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