Як побудувати службу підтримки користувачів ІС

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

Регламентуючі документи

Ми вже неодноразово наголошували, що правила роботи служби та правила взаємодії мають бути зафіксовані. Розглянемо проблему з більш загальних позицій: яка нормативна документація буде потрібна для організації служби підтримки користувачів ІС?

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

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

«Описи ролей та рольових функцій». Містять інформацію про ролі учасників процесів підтримки та функціональні обов'язки, що покладаються на виконавців даних ролей. На відміну від посад, ролі можуть виконуватися не на постійній основі та поєднуватися.

«Посадові інструкції»визначають права та обов'язки посадових осіб, які беруть участь у підтримці користувачів.

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

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

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

Надання інформації

Одна з важливих функцій служби підтримки користувачів (крім власне надання допомоги користувачам) - це накопичення інформації, що характеризує:

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

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

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

З іншого боку, якщо ігнорувати цю інформацію, нехтувати її накопиченням та подальшим аналізом, це може різко знизити ефективність діяльності служби підтримки користувачів, так і всього ІТ-департаменту (а як наслідок — і бізнесу в цілому).

Оцінка діяльності служби підтримки

Як і будь-який елемент бізнес-структури, функціонування служби підтримки користувачів має якось оцінюватися. Щоб оцінка несла в собі реальний зміст і була насправді корисною для організації, вона повинна ґрунтуватися на спеціально розроблених для цього метриках. Для служби підтримки такими метриками можуть бути:

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

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

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

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

Засоби автоматизації

Третій (після чітких правил та підготовленого персоналу) ключовий елемент системи підтримки користувачів – спеціалізовані технології, які використовуються для діяльності співробітників відповідно до обумовлених правил.

Крім того, у службі підтримки користувачів можуть бути корисними такі програмні продукти:

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

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

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

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

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

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

Як вчинити

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

Визначення переліку сервісів ІТ, що надаються користувачам.
Формування угод про рівень послуг ІТ.
Проектування процесів підтримки користувачів.
Визначення та формалізація рольових функцій учасників процесів.
Визначення вимог до засобів автоматизації.
Вибір засобів автоматизації.
Проектування системи автоматизації служби.
Розробка необхідної документації.
Створення диспетчерської служби.
Використання системи автоматизації.
Введення служби підтримки в експлуатацію.

Зверніть увагу на те, що не слід вибирати засоби автоматизації до опису реалізованих процесів! Це традиційна помилка більшості компаній: спочатку купимо ПЗ, а потім визначимося, що з ним робити. Занадто часто продукти роблять не зовсім те, що від них очікувалося (тим більше якщо очікування формально не викладені). У результаті це, як правило, призводить до розчарування у самій ідеї, до ототожнення невідповідного інструментарію та власне нового підходу до організації підтримки.

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

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