Как выглядит ITSM-портал в XXI веке

Меня зовут Сергей Харитонов, я руковожу отделом технической поддержки группы компаний «АГАТ» – это большой автомобильный холдинг, мы занимаемся продажей автомобилей и последующим ремонтом. У нас есть большая логистическая компания и подразделения, которые занимаются Trade-in (автомобилями с пробегом).

На данный момент группа компаний АГАТ имеет филиалы в 12 городах России – это около 30 отдельно стоящих филиалов и 3000 пользователей компьютеров в нашей сети.

Попытаемся с вами пофантазировать о том, каких возможностей мы ожидаем от ITSM-системы.

Если мы ITSM-специалисты или руководители ИТ, то должны быть в курсе того, какие возможности могут быть у ITSM-систем. Т.е. мы должны смотреть на свою ITSM-систему и понимать, какие функции нам могут в ней понадобиться.

Сразу оговорюсь, что я буду рассказывать не своё конкретное видение, а скорее, некое исследование, в котором участвовали коллеги из других компаний (я интервьюировал порядка 30 человек на ITSM-форуме).

Я не буду говорить о конкретных ITSM-системах, мы порассуждаем о функциях ITSM-порталов в целом.

Но сразу оговорюсь, что мы работаем в системе Gandiva, поэтому скриншоты будут оттуда.

Что такое ITSM-система

ITSM-система – это портал, через который пользователь общается с ИТ-подразделением, как правило, в этом портале заложено несколько практик ITIL (именно поэтому это называется ITSM-система)

ITSM-системы сертифицируется по количеству практик, например, «Pink Elephant», думаю вы знаете об этой сертификации.

Давайте разберемся, что же мы ждем от ITSM-системы.

Мы ожидаем, что ITSM-система – это полноценный продукт

В 2020 году мы ожидаем, что ITSM-система – это полноценный продукт, который соответствует уровню зрелости ИТ-отдела. При этом понятно, что зрелость будет расти, и потребности в продукте тоже будут меняться. И если вам сегодня достаточно тех возможностей и функций, которые есть в текущей системе, но завтра-послезавтра их уже будет недостаточно – нужно будет эти функции нарастить.

Соответственно существует два варианта – либо мы наращиваем функции в нашей текущей системе, либо текущую систему просто «выкидываем на свалку» и покупаем новую.

Чтобы не выкидывать текущую систему, мы должны предположить, что наша текущая ITSM-система – это продукт, то есть у продукта есть владелец продукта, команда разработки, пользователи и всё, что с этим связано.

Соответственно, у ITSM-системы должна быть либо платформа с возможностью доработки (например, платформа 1С:Предприятие), либо у системы должно быть API, чтобы наши программисты смогли написать интеграцию с этой системой.

Именно это я подразумеваю под полноценным продуктом.

Мы ожидаем, что ITSM-система – это система, а не портал для общения

ITSM-система – это не портал для общения, а система, поэтому она должна иметь:

• интеграцию с корпоративными системами (БП, ЗУП, ERP-система для управления производством и пр.), с всевозможными CRM-системами.

• многоканальность;

• многоплатформенность.

Под многоканальностью и многоплатформенностью понимаются разные чат-боты, интеграция с почтой, с телефоном, возможность открытия системы с мобильного устройства, с компьютера, с планшета, из браузера, совместимость с Android, iOS и т.д.

Что касается интеграции с бизнес-приложениями, мы хотим, чтобы при возникновении ошибки во всех наших бизнес-системах была возможность нажать на кнопку, по которой создавалась бы заявка в ITSM-систему. Чтобы ИТ-специалисты сразу же получили эту заявку, принялись ее решать, воспроизводить нашу проблему и т.д.

Кроме этого, мы нуждаемся в интеграции со всеми ИТ-системами, такими как система мониторинга, телефония, чат-боты и т.д. И мы хотим, чтобы система мониторинга автоматически отслеживала возникновение ошибок, и если где-то неполадки – создавалась заявка (инцидент в ITSM-системе), назначался специалист и ему отправлялось SMS.

Мы ожидаем, что в ITSM-системе есть разные уровни сложности

Мы ожидаем, что в ITSM-системе есть разные уровни сложности представления (здесь речь идет о каталоге услуг).

Мы должны иметь возможность забить каталог услуг в нашу систему целиком – прописать там всех ответственных, все SLA-нормативы, трудоемкость, сложность заявок и т.д.

У нас должно быть два разных интерфейса:

• Интерфейс для ИТ-специалиста – с полноценным каталогом услуг, где видно все зависимые/скрытые/внутренние услуги, видно, какие нужны ресурсы/активы и т.д.

• Интуитивно понятный простой интерфейс для пользователя – пользователю не нужен наш каталог услуг, он просто вводит «починить принтер», и ему сразу предлагают категорию и т.д.

Мы ожидаем, что в ITSM-системе есть средства автоматизации

Мы ожидаем, что в ITSM-системе есть:

• Реакция на триггеры, создаваемые всевозможными системами мониторинга, средствами оповещения и пр. – они создают триггеры, и наша система как-то на все это реагирует.

• Занесение бизнес-процессов или рабочих процессов (назначение заявки на нужных специалистов, правильные маршруты, организация системы самообслуживания). Эта тема очень упрощает жизнь ИТ-подразделению. Например, человек выбирает конкретную категорию и пишет конкретные слова, то ему система выдает конкретные действия. Например, пользователь пишет: «Не могу настроить почту на телефоне», система ему тут же выдает «Попробуйте воспользоваться данной пошаговой инструкцией». Если у пользователя ничего не получилось, то он возвращает заявку и пишет: «По инструкции ничего не получается, не понимаю, где нажать в моем IPhone». Тут же по заявке назначается исполнитель из живых людей – он связывается с пользователем, и далее они решают проблему сообща.

• Автоназначение исполнителей на обращения – в зависимости от географии или от маршрута.

Мы ожидаем, что в ITSM-системе есть маршрутизация обращений – система должна иметь есть возможность помогать нам назначать правильных исполнителей в зависимости от загруженности, от приоритета задач, от маршрута.

Например, есть «здание 1», где сидит «Системный администратор 1» и «здание 2», где сидит «Системный администратор 2». И если заявка приходит со «здания 1», то она вешается на «системного администратора 1», но если на первом системном администраторе 50 заявок, а на втором системном администраторе – 0, то возможен вариант взаимопомощи, когда второй системный администратор выйдет из своего здания, дойдет до нашего и поможет нашему системному администратору справляться со своими задачами.

Также в ITSM-системе нам нужна возможность массовой работы с обращениями – согласование, назначение, отклонение. Это нужно скорее для удобства руководителей IT (когда требуется согласование), и исполнителей IT (когда требуется массовая работа c заявками).

Мы ожидаем, что в ITSM-системе есть возможности самообслуживания

Мы ожидаем, что в ITSM-системе заложены возможности построения системы самообслуживания:

• Должна быть настроена интеграция с чат-ботами с возможностью настроить правила – конкретные слова, которые будут использоваться в качестве триггеров выбора конкретной категории, конкретные ответы для конкретных типов обращений к нам и т.д.

• У пользователя должна быть возможность самостоятельно получить помощь, например, по раздаче прав – пользователь открывает список всех наших ресурсов, куда он может получить доступ, выбирает галочками, что ему нужно, нажимает «Сохранить». Дальше хозяева ресурсов согласовывают ему доступ в конкретную базу 1С (или сетевую папку), и система автоматически выдает пользователю эти доступы.

• То же самое с заявками, которые закрываются со ссылкой на инструкцию –когда пользователь пишет обращение: «Помогите настроить почту на мобильном телефоне…» и заявка тут же закрывается со ссылкой на инструкцию. Пожалуйста, читай, делай все по инструкции.

Мы ожидаем, что в ITSM-системе есть управление знаниями

Что касается инструкций – той самой «базы знаний». В ITSM-системе должно быть две разных базы знаний:

• База знаний для ИТ-специалистов – там, где системные администраторы и программисты 1С хранят свои всевозможные доступы, настройки, логины, пароли, инструкции, как установить сертификат на IIS и т.д.

• База знаний, которая повернута к пользователю – где пользователь может открыть инструкцию, прочитать и сделать так, как все там написано. Либо мы закрываем пользователю обращение с заявкой на ссылку на инструкцию.

Сейчас мы в нашей системе внедряем «управление знаниями» через закрытие обращений на консультирование просто ссылками на инструкции. Инженер должен найти конкретную инструкцию, а если ее нет, то добиться, чтобы она появилась, вставить ссылку на инструкцию в заявку и молиться, чтобы пользователь не вернулся со словами «Пожалуйста, настройте мне, а то у меня самостоятельно настроить не получается». Это – то, как мы для себя видим развитие пользовательских инструкций в нашей работе.

Очень важный момент – это идея Антона Богданова «Личная страница в базе знаний». Как правило, у компании не существует базы знаний, или она недостаточно хороша, чтобы её показывать пользователям. Здесь нам на помощь приходит инструмент «Личная страница в базе знаний», когда конкретный администратор пишет инструкции «для себя», хранит для себя доступы, логины, пароли, делает себе напоминание, что таким-то образом можно установить сертификат IIS и т.д.

Со временем эта история вырастает в корпоративную базу знаний – когда соседний администратор спрашивает: «А какой пароль указывать при доступе к такому-то сервису?» ему в ответ отправляют ссылку на личную страницу и т.д. Постепенно наша система обрастает страницами в базе знаний и потом уже можно будет пользователям показывать эту базу знаний – выделить там то, что нужно для пользователей.

Соответственно, под управлением знаниями мы подразумеваем также всю около IT-ную информацию – всевозможные наши активы (контракты, оборудование, ПО), табели рабочего времени, графики отпусков и т.д. Мы подразумеваем, что всё это у нас есть либо в ITSM-системе, либо интегрировано с нашими системами, где вся информация хранится.

Мы ожидаем, что в ITSM-системе есть отчетность и аналитика

Также в ITSM-системе нам нужна отчетность и аналитика, причем мы хотим, чтобы:

• Отчетность формировалась быстро, чтобы каждый показатель был нам понятен – дата начала, дата конца, какие подразделения и т.д.

• Нам важна прозрачность этих отчетов – прошли те времена, когда сотрудники бухгалтерии не должны были знать, как работают сотрудники ИТ, сколько у них просроченных заявок и т.д. Мы пытаемся построить прозрачную систему работы ИТ, и эта отчетность должна быть доступна руководителю любого уровня. Может быть, не по всем сервисам – может быть, есть скрытые сервисы, по которым не нужно показывать отчетность для всех, но это нужно продумать заранее.

На слайде вы можете увидеть реальную отчетность моего подразделения за июнь-июль 2020 года.

Нормальный показатель – это 10-11 тыс. обращений в месяц, в июле мы вышли на докарантинное количество заявок.

Пять важных показателей, за которыми мы следим в нашей работе:

• Обращения, которые закрыты автоматически (в июле это 10%). Это то, где пользователь получил инструкцию, либо получил сервис без участия ИТ-специалиста.

• Сколько обращений закрыто на первой линии (32% в июле – это очень большой показатель для нас, мы считаем нормальным 20-25%).

• Далее мы следим за SLA – в июле он героически провален из-за того, что техподдержка 1С в этом месяце была в отпуске.

• Дальше у нас есть показатель «Заявок закрыто за 1 час» – мы пытаемся иметь больше 50% закрытых заявок за 1 час, но понятно, что техподдержка инфраструктуры не может компьютер починить за 1 час при всей возможности.

• И, конечно, важным показателем является «Удовлетворенность пользователей» – оценки пользователей за нашу работу.

Вместо вывода

Вместо вывода хочу сказать, что ITSM-система должна удовлетворять уровню зрелости IT.

При этом мы должны быть в курсе тех тенденций, которые существуют в ITSM-системах на рынке. Мы должны подразумевать, какие функции нам могут понадобиться, и с учетом этого перед выбором ITSM-системы проверять ее возможности по чек-листу.

Вопросы

Как вы боретесь с пользователями, которые не понимают, что написано в инструкциях?

Если пользователь не понимает, что написано в инструкции, он возвращает заявку на инженера. И инженер уже разбирается с пользователем самостоятельно. Инженеру выгодно, чтобы заявка закрылась автоматически, чтобы не тратить на эту заявку свое время, соответственно, в его интересах разобраться, почему инструкция пользователю оказалась непонятна. И если в инструкции существует реальная проблема, то инженер должен ее поправить – либо отправить заявку на исправление инструкции (у нас для инструкций используется «Корпоративный университет»), либо, если у пользователя систематически возникают вопросы по элементарным функциям системы, провести для него индивидуальное обучение.

Как вы рассчитываете штат сотрудников в поддержке?

В нашей ITSM-системе у каждой заявки помимо внешних показателей, которые прописаны в SLA (время на исполнение и группа исполнителей), существуют также внутренние показатели для ИТ. Например, трудоемкость – каждой категории заявок соответствует определенная трудоемкость. И когда я в конце месяца складываю эти трудоемкости, я получаю определенную цифру. При этом я знаю, что на одного системного администратора норма трудоемкости такая-то, на программиста 1С норма трудоёмкости такая-то.

Если в этом месяце у меня общая трудоемкость получилась больше нормы, я могу доказать, что мне необходимо такое-то количество сотрудников на моих линиях техподдержки. Например, я таким образом пронормировал системных администраторов, выяснил, что у меня их очень много, и мы их сильно сократили.

Внедряли вы сами ITSM-систему? Как вы описывали бизнес-процессы, заключали SLA? С чем и по каким критериями вы это сравнивали?

Я сейчас не буду рассказывать про выбор нашей ITSM-системы, потому что это было очень давно, это тема отдельного разговора – как мы сравнивали и как выбирали. На тот момент полного понимания того, что нам нужно, не было. Там выбор был более сложный, скорее, импульсивный. SLA с бизнесом мы для своей компании заключали, мы его периодически пересматриваем. Это живой документ, который я делал сам.

На основании чего вы устанавливаете SLA?

SLA мы устанавливаем на основании требований бизнеса. Все сервисы, которые мы предоставляем, разбиты на четыре уровня критичности (очень критичный, высокой степени критичности, средней критичности и некритичный). И мы по поводу каждого сервиса договариваемся с представителями бизнеса, насколько он критичный. Точнее, мы разбиваем на сервисы продукты, которые мы предоставляем, и уже данные сервисы нормируем.

Вы сами внедряли ITSM-систему или привлекали кого-либо?

Сами внедряли, сами писали SLA, сами проставляли в системе правильные показатели и сами до сих пор ее поддерживаем. Нужно понимать, что нельзя внедрить и уйти – это живой продукт, который меняется каждый день и требует новые решения. Система не статична.

Вы рассказывали, что рассчитываете нормо-часы для администраторов и т.д. В эти нормы входит обучение специалистов?

У меня в подчинении есть три подразделения – первая линия, техподдержка системных администраторов и поддержка 1С. У них все по-разному. У системных администраторов время на обучение не выделено, у них, как правило, мы организуем внешнее обучение – мы сейчас активно обучаемся на Linux, приглашаем преподавателей и т.д. У первой линии техподдержки обучения тоже практически нет, там больше обучение в процессе работы происходит – просто ребята без опыта пытаются вникнуть, как работает компания. А для сотрудников техподдержки 1С реально выделено время под самообучение, потому что навыки здесь очень нужны.

*************

Статья написана по итогам доклада (видео), прочитанного на митапе «ServiceDesk в 1С».