Портал заявок и сервис деск на 1С ITIL

Я хочу рассказать о том:

• Что такое ITSM и ITIL,

• Что необходимо, чтобы внедрить систему,

• Как мы пришли к результату,

• В чем была уникальность нашего проекта,

• С какими проблемами мы столкнулись во время внедрения.

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

ITIL – это набор лучших практик для управления IT-сервисами в организации. Он помогает оптимизировать процессы, улучшить качество обслуживания пользователей и обеспечить согласованность работы отдела информационных технологий.

Если у вас все хорошо и вам нечего менять, немедленно закройте эту книгу. Изучение, а тем более внедрение ITIL из любопытства или следования моде, может привести к катастрофическим последствиям. И если вы менеджер и вас до сих пор не уволили, это означает, что все процессы, описанные в книге, у вас уже есть и они работают.

В этом есть доля правды, потому что внедрять ITSM ради ITSM неправильно. Необходимо сначала определить цель управления, понять, чем именно нужно управлять, какой результат требуется получить и как это эффективно автоматизировать.

Рассмотрим этапы подготовки и примеры того, что необходимо сделать. Это те шаги, которые я применяю в своей практике и которые помогают в дальнейшей реализации.

Первое – это процессы

Необходимо определить процессы, которые требуется автоматизировать. Я использовал стандартный подход: цель, процессы, структура.

Сначала необходимо получить цели бизнеса. Любая компания, независимо от сферы деятельности – производство, ритейл или другая отрасль, – имеет свои цели. На основе целей бизнеса формируются цели IT, которые помогают достигать бизнес-целей напрямую или косвенно.

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

На примере текущих изображений покажу, как определить необходимость технической поддержки в компании.

Мы получили цель от бизнеса – обеспечить непрерывность объектов продаж. Чтобы достичь этой цели со стороны IT необходимо повысить уровень удовлетворенности действующих клиентов за счет обеспечения поддержки и сопровождения информационных систем.

В рамках этого направления задействуются два подразделения: отдел технической поддержки и отдел инфраструктурных решений. Это связано с тем, что требуется управление инцидентами, управление проблемами и управление каталогом услуг. Следовательно, отдел технической поддержки должен присутствовать в компании в обязательном порядке.

Каталог услуг – что это и как этим управлять?

Каталог услуг – это список услуг компании, который отражает то, что делает исполнитель. Эти услуги относятся не только к IT, но и к таким подразделениям, как АХО, отдел кадров, бухгалтерия.

Что мы сделали для проработки каталога услуг? Сначала изучили все сервисы системы и определили уровень их критичности. На этом подробно останавливаться не буду. В практике используются разные уровни, мы в своем случае выделили следующие: mission-critical, business-critical, business-operational и другие.

Далее мы сформировали каталог услуг. После этого выделили ответственное подразделение за его актуализацию. Это необходимо, потому что каталог услуг – живая система. Он меняется не ежедневно, но как минимум раз в неделю должен пересматриваться. Задача ответственного специалиста – поддерживать каталог в актуальном состоянии.

Есть показательные примеры, когда пользователи не находят нужные услуги и выбирают вкладку «прочие». В результате до 70% заявок попадает именно туда. Задача специалиста, управляющего этим процессом, – разбирать обращения из раздела «прочее», выявлять реальные потребности заказчиков в услугах, модернизировать услуги, изменять их и делать более эффективными и прозрачными.

Обязательно необходимо проработать соглашение с заказчиком – SLA (Service Level Agreement), чтобы все условия были понятны и формализованы.

Управление инцидентами

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

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

2. После определения этапов обязательно необходимо проработать маршруты (схемы) процессов. Недостаточно просто задать статусы. Обязательно должна быть схема, потому что инцидент, как правило, не решается в рамках одного подразделения. Должны быть определены схемы эскалации, куда может быть передан тот или иной инцидент.

3. Также на каждом этапе должны быть ответственные исполнители.

4. Необходима привязка к соглашению (SLA) либо к услуге.

5. Завершающий элемент – формирование отчетности по инцидентам.

Базовые процессы управления IT, которые рекомендуется автоматизировать в первую очередь:

1. Управление каталогом услуг,

2. Управление (обращениями) инцидентами,

3. Управление проблемами,

4. Управление изменениями,

5. Управление активами.

В таком составе этих процессов достаточно для хорошего старта. Руководитель IT получает возможность управлять ключевыми процессами и иметь достаточный объем информации для дальнейшего планирования работы.

Кейс по внедрению

Далее рассмотрим кейс по внедрению: какие проблемы мы решали и какой результат получили в компании, где я сейчас работаю.

Начнем с проблем. Что происходило с IT и почему бизнес был недоволен?

На примере изображения: слева – IT-специалист компании, справа – заказчик со стороны бизнеса.

Со стороны бизнеса проблема заключалась в том, что было непонятно, как обращаться в IT. Использовались разные способы: устные обращения, сообщения, электронная почта. Для заказчика это превращалось в квест. Он подавал заявку и не понимал, как она обрабатывается. В результате мог неделями находиться в этом процессе и в итоге либо получить результат, либо не получить его вовсе.

С другой стороны – IT-специалист, который обрабатывает обращения через разные каналы связи: телефон, личные коммуникации, мессенджеры, почту и другие способы. Все это необходимо было одновременно учитывать, обрабатывать и решать.

В результате были выявлены следующие проблемы:

1. Отсутствие единой системы по работе с заявками,

2. Отсутствие единого окна для обращений бизнес заказчиков,

3. Отсутствие понимания статуса заявки и ответственных исполнителей.

Какие мероприятия мы проработали, чтобы перекрыть эти глобальные проблемы?

• Внедрение системы.

• Внедрение портала самообслуживания.

• Внедрение личного кабинета.

Что сделали

Какие мероприятия были проведены для закрытия этих проблем?

В первую очередь – выбор системы. Мы анализировали несколько решений. На примере изображения видно, что рассматривались такие продукты, как 1С:ИТИЛИУМ, 1С:Управление ИТ-отделом и 1С:ITIL. В итоге мы остановились на системе 1С:ITIL.

Причина выбора была следующей. Систему в любом случае требовалось дорабатывать, поэтому было принято решение выбрать продукт с максимально простым и понятным интерфейсом. Доработка сложного решения обходится значительно дороже. В результате был выбран 1С:ITIL, который, по нашему мнению, оказался оптимальным вариантом.

Подготовка каталога услуг и SLA

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

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

Также было проработано соглашение с заказчиком в разрезе каждой услуги. В него вошли уровни критичности, время реакции и время решения.

Процессы в 1С: инциденты, проблемы, изменения

Далее на примере интерфейсов показан процесс, который был внедрен. Это процесс управления инцидентами, проблемами и изменениями.

Важно подчеркнуть, что 1С – это система, в которой все элементы связаны между собой. Управление проблемами строится следующим образом: на основании инцидентов формируется проблема, которая подлежит устранению. После ее решения проблема закрывается, а связанные с ней инциденты также закрываются.

В 1С это реализовано удобно. На примере изображения видно, что к одной проблеме может быть привязано множество инцидентов. После проработки и закрытия проблемы все связанные инциденты автоматически переводятся в статус «закрыт».

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

Управление активами

Также был реализован процесс управления активами. Использовался внутренний инструмент без существенных доработок. Он предназначен в первую очередь для специалистов технической поддержки.

Основная задача заключалась в инвентаризации IT-оборудования. Сравнение данных инвентаризации с учетной системой комплексной автоматизации бухгалтерии оказалось неудобным как для IT, так и для бухгалтерии, поэтому процесс был разделен.

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

Портал самообслуживания, личный кабинет

Также был внедрен портал самообслуживания, в котором нуждалась компания. Слева на изображении представлен каталог услуг. Справа – личный кабинет, в котором заказчик может увидеть все свои обращения: открытые и закрытые, а также полный список заявок.

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

Единое окно обращений позволило направлять запросы не только по IT-вопросам, но и по другим направлениям. Например, можно обратиться к юристам для проверки договора или направить запрос в АХО на замену кресла.

Автоматизация процессов смежных служб

На примере показано, как были подключены и автоматизированы смежные службы и сформирован подход к использованию ITSM-системы как ESM-системы.

У таких подразделений, как АХО или юридическая служба, этапы обработки обращений во многом совпадают с IT-процессами. По этой причине с нашей стороны была инициатива предложить использовать систему для всех обслуживающих и сервисных подразделений. В результате они были переведены в единую систему.

В настоящее время в системе работают отдел маркетинга, который обрабатывает заявки по буклетам и вывескам, юридическая служба, работающая с договорами, а также АХО. В дальнейшем планируется подключение бухгалтерии, так как существует большое количество запросов на справки, а также кадрового отдела, который также занимается выдачей справок.

Результаты внедрения

Что мы получили в итоге?

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

Повысилась прозрачность работы IT для сотрудников бизнеса: пользователь видит свои заявки, видит исполнителя и может с ним взаимодействовать напрямую в рамках заявки. Нет необходимости искать номер телефона или писать в корпоративный мессенджер – обсуждение ведется в комментариях.

Появилась отчетность, которой раньше не хватало. До цифровизации IT-процессов не было понимания, что происходит в компании. Теперь доступны отчеты в различных разрезах: топ-20 услуг, топ-20 заказчиков, статистика по поступившим и решенным инцидентам и изменениям. Это позволяет эффективно управлять IT.

На основании анализа топ-20 проблем можно выявлять узкие места. Например, большое количество обращений по услуге «Диадок» указывает на проблему. Это может означать, что сервис работает некорректно либо процесс взаимодействия с ним выстроен неправильно. В результате формируется цель – снижение количества поступающих инцидентов, и эта цель реализуется силами службы технической поддержки.

Система также помогла во внедрении KPI. Мы изучили функциональность, в отдельных местах доработали ее и получили необходимую картину.

Стало понятно, сколько времени и каким образом решаются инциденты различных типов. Фиксируется учет рабочего времени сотрудников. Отдельно выделяются выезды на аптеки, так как объекты расположены по всей России, и специалисту необходимо не только обработать заявку, но и выехать на место, например, для замены фискального накопителя.

SLA позволяет видеть скорость реакции и выполнения работ. Это дает понимание того, что необходимо улучшать и как дальше развивать эффективность предоставления услуг.

Уникальность проекта

Уникальность проекта заключается в том, что 1С «из коробки» практически не используется, так как систему всегда требуется дорабатывать. После перехода в прошлом году на подходы Agile и Scrum функционал, реализованный в 1С:ITIL, не подходил для работы с такими процессами.

В системе были предусмотрены запросы на изменения, однако для их использования в рамках Agile потребовалась доработка. Мы доработали сущность бэклога в разрезе продуктовых команд, проработали спринты и настроили инструменты таким образом, чтобы и тимлид, и команда, работающая с ним, имели собственное рабочее пространство. В этом пространстве отображается пул текущих и планируемых работ, а также перечень задач, которые необходимо выполнить.

С интеграцией с 1С:Комплексной автоматизацией существовала отдельная проблема. Каждый месяц я, как руководитель IT, вручную заполнял данные в системе Комплексной автоматизации. Скорость заполнения не имела значения – ключевым оставался человеческий фактор, который всегда может привести к ошибке и вводу некорректных данных.

Мы проработали KPI в 1С:ITIL и настроили интеграцию с Комплексной автоматизацией. После того как руководитель фиксирует показатели, достаточно нажать кнопку, и данные автоматически передаются в КА. На основании этих данных рассчитывается заработная плата: KPI, оклад, бонусы, премии и другие выплаты.

SLA, реализованный в 1С:ITIL, также не соответствовал нашим требованиям. Либо мы изначально неверно поняли логику настройки, либо реализация была построена на иной методологии.

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

Проблемы при внедрении

При автоматизации и внедрении системы возникли определенные проблемы. Каталог IT-услуг был сформирован достаточно быстро благодаря предыдущему опыту. С бизнес-подразделениями ситуация оказалась сложнее.

Разработка каталога услуг у бизнес-направлений

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

Мне приходилось объяснять руководителям подразделений, в том числе руководителю АХО, зачем необходима аналитика и как управлять каталогом услуг. Только после формирования базового понимания каталог услуг перерабатывался и принимал рабочий вид. Каждому подразделению, которое подключалось к системе, требовалось отдельно объяснять принципы управления каталогом. В результате по каждому подразделению формировался качественный и структурированный каталог услуг.

Сложность адаптации сотрудников к информационной системе

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

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

Сложность внедрения из-за параллельной реструктуризации компании

Отдельной проблемой стало внедрение системы на фоне параллельной реструктуризации компании. Не рекомендуется автоматизировать процессы в момент, когда бизнес проходит реструктуризацию. Речь идет не о реструктуризации IT, а об изменении бизнес-процессов в целом.

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

Параллельная автоматизация процессов и дальнейшее исправление связанности

Это моя ошибка, хотя точнее сказать – я поторопился. Мы внедряли автоматизацию процессов параллельно. К чему это привело? У меня, как у руководителя, стояла задача срочно оцифровать в компании IT-процессы, и я начал делать это сразу.

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

Заключение и рекомендации

В заключение важно отметить следующее.

1. Необходимо читать литературу по ITIL и ITSM. Материалов в интернете много, также можно пройти курсы. Книга не расскажет, как именно построить систему, но поможет понять, что нужно делать.

2. Перед внедрением системы необходимо точно определить, какими процессами требуется управлять и какие возможности система предоставляет для этого. Кому-то нужно управлять только инцидентами, кому-то – изменениями. Руководитель должен определить перечень потребностей.

3. Нужно определить, какие процессы нуждаются в автоматизации.

4. Необходимо полноценно готовиться к внедрению и проходить подготовительные этапы. Неправильный подход выглядит так: определили, что система нужна, и сразу начали ее настраивать. Я так делать не советую. Сначала необходимо сесть, формализовать и описать процессы, пройти по пунктам и этапам, проверить, не попадает ли какой-то тип инцидента в цикл, чтобы система не теряла ни исполнителя, ни заказчика.

5. Сначала формализуем процессы, затем автоматизируем. Это снижает риск недоработок.

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

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT