Личный опыт внедрения системы GLPI. Часть 1

в 12:19, , рубрики: GLPI, Help Desk Software, helpdesk, service desk, support, поддержка пользователей

Недавно мне было поручена задача по реанимации системы сервис деск системы на основе уже развернутой 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 в каждой компании будет свой, здесь я просто обозначил те позиции, на которые, на мой взгляд, стоит обратить внимание.

После проработки данной теоретической части я приступил к внутренней настройке системы. Об этом во второй части.

Автор: Quattro805

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js