SLA для внутрішнього IT: як встановити строки, яких реально дотримуються

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

Коротко

1. Спершу виміряйте, як є зараз. Строк, узятий не з власних даних, порушується першого ж тижня.

2. Строків завжди два: коли відповіли і коли зробили. Плутати їх — найдорожча помилка.

3. Рахуйте в робочих годинах. Обіцянка «за 4 години» о 17:30 п’ятниці — це обіцянка на понеділок.

Що таке SLA всередині організації

Це коротка письмова відповідь на питання, яке вам ставлять щодня: «коли до мене прийдуть?». Не договір, не інструмент покарання і не привід для штрафів — їх усередині установи все одно немає.

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

Чого SLA не робить: він не додає рук. Якщо один адміністратор обслуговує 300 користувачів, SLA не прискорить жодного ремонту. Він зробить чергу чесною і видимою — не більше й не менше.

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

Два строки, які треба розрізняти

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

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

Плутанина між ними — головна причина, чому SLA перестають виконувати. Обіцяли «полагодимо за чотири години», а картридж приїде через два дні — і ви порушник, хоча зробили все можливе за пів години.

Правильно виглядає так: «Відповідаємо протягом години. Якщо ремонт залежить від запчастини, повідомляємо строк постачання того ж дня». Реакція — тверда, вирішення — з чесним винятком.

Крок 1. Виміряйте базову лінію

Будь-які цифри до вимірювання — фантазія. Потрібно знати, як ви працюєте зараз, без жодних зобов’язань.

Візьміть 20–30 останніх закритих заявок і випишіть для кожної три дати: коли подали, коли взяли в роботу, коли завершили. У SmartOKS перші дві є в самій заявці й у журналі змін статусу, третя — теж у журналі.

Далі не рахуйте середнє. Середнє ховає хвіст: дев’ять заявок по годині й одна за тиждень дадуть «у середньому 17 годин», і це число не описує нічого.

Робіть інакше: впорядкуйте свої 20 заявок за часом виконання, відкиньте дві найдовші — і те, що лишилось найдовшим, і є ваш реальний строк. Це грубий 90-й процентиль: він означає «дев’ять із десяти заявок ми закриваємо не довше, ніж за це». Саме таке число можна обіцяти.

Якщо базова лінія вийшла соромною — це нормально. Її не показують назовні, вона потрібна вам, щоб не пообіцяти вчетверо менше і не провалитись.

Крок 2. Визначте робочий час

SLA поза робочим часом — фікція, якщо у вас немає чергування. І він майже не потрібен.

Ось реальний розподіл із бази установи: 51 заявка з 55 надійшла в робочі години — з понеділка по п’ятницю, з 9:00 до 18:00. Поза ними — чотири звернення за дев’ять місяців.

Тому в угоді пишуть просто: строки рахуються в робочих годинах, з понеділка по п’ятницю, з 9:00 до 18:00, крім святкових днів. Заявка, подана о 17:30 п’ятниці зі строком реакції «4 робочі години», має бути взята в роботу до 11:30 понеділка. Це не бюрократія — це те, що рятує вас від образи «я ж написав увечері».

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

Крок 3. Поділіть заявки на три класи

Чотири рівні пріоритету, які є в системі, — це шкала для сортування черги. Для угоди про строки потрібні класи, які може розрізнити сам заявник.

Робочий поділ для установи — за наслідком, а не за типом техніки:

Той самий принтер може бути класом A і класом C — залежно від того, чи є поруч другий. Тому клас визначає не техніка, а наслідок для роботи.

У картці заявки це лягає на наявні пріоритети: клас A — «Критичний» або «Високий», клас B — «Середній», клас C — «Низький». Ставить їх адміністратор або менеджер, не заявник: інакше терміновими стають усі.

Крок 4. Поставте строки, які витримає одна людина

Орієнтири нижче — для установи з одним адміністратором і потоком до 15 заявок на тиждень. Це відправна точка, яку ви коригуєте своєю базовою лінією з кроку 1.

Дві речі, які роблять таку таблицю виконуваною.

«Обхідне рішення» — це теж результат. Перевести друк на сусідній принтер, видати підмінний ноутбук, підняти сервіс на резервній машині. Для класу A важливо, щоб робота пішла далі, а не щоб причина зникла негайно.

Строк С — це не «коли встигну». Планові заявки роблять пачками: наприклад, кожен четвер по обіді. Тоді п’ять робочих днів — чесний строк, а не оптимістичний.

Крок 5. Впишіть винятки одразу

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

• очікування запчастини, картриджа або заправки;

• роботи підрядника чи постачальника послуг;

• закупівля через тендерні процедури;

• доступ або дії з боку зовнішньої організації — банку, казначейства, оператора;

• завдання проєктного типу: переїзд кабінету, розгортання нової системи.

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

Крок 6. Оголосіть угоду і показуйте цифри

Угода має бути однією сторінкою: робочий час, три класи з прикладами, таблиця строків, винятки, аварійний канал. Підписана керівником — інакше це ваша особиста обіцянка, а не правило установи.

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

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

Як контролювати строки в SmartOKS

Чесно про те, що є, і чого немає.

Що допомагає. Фільтр «Відкриті за пріоритетом» показує тільки заявки в статусах «Нова заявка» і «У роботі», відсортовані за пріоритетом і датою — це і є ваша черга на день. Дата подачі видна в картці, тож вік заявки видно очима. Журнал змін фіксує, хто і коли змінив статус, — з нього рахують і реакцію, і час до завершення.

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

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

Типові помилки

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

Один строк на всі заявки. «Реагуємо протягом години» звучить сильно рівно до дня, коли одночасно прийдуть дев’ять заявок. У базі установи максимум за день — саме дев’ять.

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

SLA як інструмент покарання. Щойно строки починають використовувати для доган, заявки повертаються в чат — там немає відміток часу.

Строки, яких ніхто не міряє. Якщо цифри не зводяться раз на місяць, угоди фактично немає. Достатньо трьох чисел, але регулярно.

Якщо строки постійно порушуються

Це не привід переписати цифри на більші. Спершу перевірте три речі.

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

Класи визначені неправильно. Якщо половина заявок потрапляє в клас A, класифікація зламана: «зупинка» має бути рідкістю. Перегляньте приклади в таблиці разом із керівником.

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

Питання, які виникають найчастіше

Чи потрібен SLA, якщо в IT-відділі одна людина? Саме тоді він і потрібен найбільше. Один адміністратор фізично не може реагувати на все одразу, і письмовий строк — єдиний спосіб зробити чергу зрозумілою, а не образливою.

Що робити, якщо керівник вимагає «усе за годину»? Покажіть базову лінію і кількість заявок на тиждень. Розмова про строки без цифр — це розмова про наміри. З цифрами вона перетворюється на розмову про ресурс.

Чи можна дати різні строки різним підрозділам? Можна, але це складніше в підтримці. Простіше врахувати критичність у класі A: бухгалтерія в день звіту й приймальна комісія — це «зупинка» за визначенням, і окремих правил для них не треба.

Як бути із заявками «зроби, коли зможеш»? Це клас C з узгодженою датою. Домовтеся про день і запишіть його в коментар — тоді заявка не висітиме в черзі як докір.

Чи рахувати час, поки чекаємо відповіді від заявника? Не рахувати. Якщо ви написали уточнення й чекаєте, годинник зупиняється — інакше строк порушує не IT, а той, хто не відповідає. Зафіксуйте це правило в угоді одним реченням.

Візьміть готовий шаблон угоди

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

Читайте також

• Заявки в IT через месенджер: чому це не працює — без системи заявок строки нема на чому рахувати.

• Як навести порядок в обліку IT-обладнання — заявка, прив’язана до конкретного пристрою, показує його історію одразу.

• Мережевий принтер не підключається: 0x0000011b, 0x00000709, 0x00000002 — типова заявка класу B, у якої є обхідний шлях.