- PVSM.RU - https://www.pvsm.ru -

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

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

Автор: Quattro805

Источник [1]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/support/198449

Ссылки в тексте:

[1] Источник: https://habrahabr.ru/post/312448/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox