Особистий досвід впровадження системи GLPI. Частина 1

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

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

1. Аналіз поточної діяльності відділу
Пару слів про компанії:
Основний напрямок — будівництво, постійний штат >150 осіб, >5 віддалених об'єктів.

Про самому відділі:
У відділі працює 6 чоловік:

  • 1С програміст — вирішує питання щодо впровадження корисного софта для потреб компанії;
  • Фахівець технічної підтримки — ваш покірний слуга, основний напрямок — підтримка користувачів, другорядне — розробка документації відділу і т. д.;
  • Мережевий адміністратор — адміністрування серверів компанії, телефонії і т. д.;
  • Веб-розробник — відповідає за сайт компанії;
  • Фахівець з інфраструктури — внутрішня інфраструктура компанії;
  • Керівник служби ІТ.
Висновок:
В результаті знайомства з обов'язками співробітників було виведено чотири основних напрямки для налаштування та використання системи:

  • Підтримка — сюди входять запити на зміни, інциденти, критичні інциденти. Крайній термін для такого типу звернень встановлюється згідно каталогу сервісів (про нього нижче);
  • Супровід — внесення змін до системи, ресурси, налаштування обладнання. Крайній термін встановлюється відповідальним за рішення заявки фахівцем;
  • Проекти (окремий модуль GLPI) — робота над новими проектами. Задані критерії для визначення проекту: є час початку і час закінчення, є чіткі завдання (віхи проекту), є група учасників, є мета. Крайній термін встановлюється проектною групою;
  • Завдання керівника відділу своїм співробітникам.
Також було прийнято рішення про надання багаторівневої підтримки. Спочатку розглядалося питання однорівневою підтримки, але у такому разі звернення дублювалися.

2. Підготовка до внутрішньої налаштування системи GLPI (теорія, документація)
Перший етап введення системи в експлуатацію — це опис теоретичної частини роботи системи і роботи з системою. Не буду кривити душею, багато речі документувалися вже в процесі установки системи (як раз із-за відсутності туториала по даній системі).

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

  • Вкладка «Сервіс» — найменування сервісу, наприклад, пошта, 1С, телефонії і т. д.;
  • Вкладка «Послуги» — послуги, що надаються в рамках сервісу, наприклад, настроювання облікового запису, надання доступу і т. д.;
  • Вкладка «Користувачі» — опис груп користувачів, що використовують сервіс, наприклад, топ-менеджмент, адміністрація, канцелярія і т. д.;
  • Вкладка «Доступність» — опис рівня доступності сервісу, наприклад, 24х7, 5х40 і т. д.;
  • Вкладка «Вплив» — опис рівня критичності сервісу, впливу на інші сервіси, вплив на бізнес-процеси компанії;
  • Вкладка «Відповідальні» — відповідальні за надання послуг фахівці;
  • Вкладка «Метрики» — опис вимірних показників, наприклад, час реакції на звернення, максимальний час вирішення звернення, допустима кількість звернень у конкретний термін і т. д.
Типи заявок:
Далі був процес поділу заявок/звернень на типи:

  • Запит — всі заявки на зміну чого-небудь, наприклад, надання/зміна прав доступу, установку програмного забезпечення і т. д., рішення таких звернень в режимі 5х40;
  • Інцидент — тимчасове призупинення доступу або роботи сервісу для 1-3х чоловік одноразово, рішення таких звернень в режимі 5х40;
  • Критичний інцидент — недоступність сервісу для 4-х і більше чоловік одноразово, рішення таких звернень відбувається у режимі 24х7.
Групи:
Поділ відділу на групи (з доробком на розширення штату) та призначення відповідальних:
Так як було прийнято рішення використовувати модель багаторівневої підтримки з різним напрямком роботи і взаємодії з системою glpi, було виділено кілька груп:

  • Інфраструктура — сюди увійшли: мережева інфраструктура, розробка стандартів, підтримка шлюзів, підтримка мережевого обладнання. Відповідальний — адміністратор;
  • Телефонія — обслуговування АТС, адміністрування абонентів, стики з call — центром. Відповідальний адміністратор;
  • Користувачі та кероване обладнання — тут зібрані установка і підтримка робочих місць, підключення периферії, ремонт техніки, заміна витратних матеріалів і т. д;
  • Серверна інфраструктура — відповідальний спеціаліст по інфраструктурі;
  • Веб ресурси — створення, підтримка та супровід. Відповідальний веб-розробник;
  • Корпоративні інформаційні системи. Розробка та релізи, адміністрування прав користувачів, робота з підрядними організаціями. Відповідальні — 1С розробник.
  • Сторонні ІТ-послуги. Мобільний зв'язок, ККД, Інтернет — це те, що знаходиться на аутосорсе.
Даний поділ дозволило розмежувати зони відповідальності і зняти з порядку денного питання — чому співробітників контролює їх колега.

SLA:
Далі настав час опрацювання SLA (крайнього терміну звернень). Нижче я наводжу фактори, які вплинули на встановлення SLA конкретно в нашому випадку.

  • Розташування замовника. Деякі питання потребують виїзду до замовника на майданчик, відповідно крайній термін для таких звернень закладався з урахуванням часу в дорозі +20% часу від звичайного SLA;
  • Критичність/вплив — SLA для звернень, надають помітне вплив на бізнес-процеси компанії встановлювався мінімально можливий строк рішення (в рамках розумного);
  • Відповідальність за сервіс. Тут мається на увазі чий сервіс недоступний — наш або провайдера. У разі недоступності сервісу з боку провайдера, наприклад, інтернет, SLA брався з договору надання послуг.
Ось ці три показника змінювали SLA в більшу або меншу сторону. Зрозуміло, SLA у кожної компанії свій, тут я просто позначив ті позиції, на які, на мій погляд, варто звернути увагу.

Після опрацювання даної теоретичної частини я приступив до внутрішньої налаштуванні системи. Про це в другій частині.
Джерело: Хабрахабр

0 коментарів

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