ITSM в облаке: привычное решение на российской платформе

Сергей Зинкевич
Директор бизнес-юнита КРОК Облачные сервисы

Алла Козлачкова
Product owner RockIT Manager

Артем Мукосеев
Менеджер продукта RockIT Manager

Сергей Зинкевич. Сегодня мы поговорим о новом ITSM-сервисе на базе Облака КРОК и о том, что такое ITSM-системы, в каких ситуациях они нужны и как с ними работать, а также покажем демо.

Алла Козлачкова. В начале года мы презентовали новый продукт, ITSM RockIT Manager, и сегодня это решение доступно из облака благодаря нашему партнерству с КРОК Облачные сервисы.




Артем Мукосеев. Клиентам больше не нужна собственная инфраструктура под ITSM, потому что можно быстро запуститься и получить все базовые процессы поддержки из облака.

Алла Козлачкова. RockIT Manager — ITSM-решение на low-code-платформе Comindware, которая является лидером BPMS на российском рынке. Мы очень долго вынашивали идею создания собственного продукта, и, когда начали выбирать платформу, подружились с Comindware, потому что решили, что, объединив ITSM с преимуществами low-cost-системы, мы получим именно то, что будет интересно и необходимо заказчикам. Довольно быстро после того, как запустились, мы поняли, что есть запрос на предоставление этого решения из облака, потому что сейчас многие хотят избавиться от головной боли, связанной с поддержкой инфраструктуры.




Сергей Зинкевич. Артем, что такое ITSM-система?

Артем Мукосеев. Системы ITSM (IT Service Management) помогают автоматизировать деятельность по управлению ИТ-услугами. Управление услугами начинается с обработки заявок. Многие трактуют эти системы как тикетные, но это не так. Существует множество задач, которые нужно и можно автоматизировать, помимо обработки заявок.

Мы выбирали список процессов для автоматизации в нашей системе на базе так называемых лучших практик.

Сергей Зинкевич. Как я понимаю, пплатродукт состоит из трех блоков, и, помимо платформы, включает модуль ITSM и портал пользователя?

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

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

Артем Мукосеев. Кроме того, на базе портала можно сделать единое окно, выступающее в роли так называемого «зонтика»: его можно интегрировать с разными системами, так чтобы все заявки попадали в эти системы через портал, а в портале собирался статус заявок.

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

Алла Козлачкова. Стоит более подробно рассказать про саму платформу.




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





 В отличие от многих ITSM-систем, платформы BPM изначально предполагают настройку силами бизнес-аналитика — это low-code.

Сергей Зинкевич. У нас осталось самое интересное — ITSM-модуль.




Артем Мукосеев. Мы включили в ITSM-модуль наиболее востребованные процессы, опираясь в выборе на ITIL — свод лучших практик, в котором описана процессная модель, т. е. какие процессы в ИТ должны быть и какие в идеале должны быть автоматизированы.

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

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

Расскажу подробнее про ядро — управление каталогом и уровнем услуг, два процесса, которые часто объединяют в один.

  В систему заложена трактовка услуги в соответствии с ITIL, т. е. услуга понимается как некая комплексная сущность, в рамках которой мы выполняем какую-то работу и даем пользоваться, например, информационной системой. SLA, которые заложены в продукте «из коробки», позволяют описать нормативы выполнения обращений (инцидентов и запросов на обслуживание) либо по всем услугам сразу, либо по отдельным услугам, либо для определенных заказчиков.



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




Сергей Зинкевич. Мне кажется, что обеспечить позитивный пользовательский опыт очень важно.

Алла Козлачкова. Это правда. Управление каталогом, выделение базовых услуг, формирование стандартных запросов и т. д. — все это сделано для того, чтобы пользователям было удобно обращаться по этим услугам в службу поддержки. Если интерфейс системы возвращает пользователей в далекое прошлое, они могут не зайти второй раз. Поэтому важно, чтобы портал нравился пользователям и позволял настраивать уникальные формы запросов, чтобы управление было удобным. Например, модальные окна для коротких действий, чтобы не нужно было открывать форму где-то далеко и листать вкладки, а можно было все указать в коротком всплывающем окне, например, подтвердить выполнение заявки (да/нет).

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

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




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




Управление инцидентами состоит из базовых шагов: принять в работу и выполнить работу. На этапе выполнения у исполнителя есть возможность создать сколько угодно связанных задач.
Между классическими ITSM-системами и BPM-системами есть базовые различия. В классической ITSM-системе есть карточка заявки, в которую специалист заходит, заполняет атрибуты и меняет статус. Жизненный цикл заявки обычно зашит в возможную последовательность смены статуса.




В BPM-системе на каждый шаг создается задача. Когда поступила заявка, создается задача на первую линию, чтобы ее классифицировать. После классификации заявка «летит» либо в инцидент, либо в запрос на то, чтобы его приняли в работу. Общий шаг в конце для всех заявок — это подтверждение выполнения. Неважно, как заявка была обработана — как инцидент или как запрос, на пользователя создается задача, что необходимо подтвердить устранение проблемы. И пользователь тоже выполняет задачи в рамках процесса.





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

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

Вопрос из чата. Эти задачи формируются для внутренней ИТ-службы или для вас?

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

Вопрос из чата. Если задачу закрыли, можно ли открыть ее повторно или мы каждый раз создаем новую?

Алла Козлачкова. Закрытую задачу можно открыть заново.

Вопрос из чата. Есть ли аналог внутренней Википедии?

Алла Козлачкова. В роадмапе есть база знаний, планируем выпустить в первом-втором квартале 2024. В системе есть полнотекстовый поиск, т. е. можно при настройке указать, какие атрибуты попадают под полнотекстовый поиск, включая вложения.

В RockIT Manager есть функция публикации новостей, в которые можно включать вложения. Они поддерживают HTML-верстку, и по ним также работает полнотекстовый поиск. Сейчас мы предлагаем заказчикам эту функциональность, когда им нужно, например, опубликовать инструкции, а не просто оповещения о том, что та или иная система будет недоступна. Например, можно публиковать новости о том, что в эксплуатацию вводятся новые системы или функции, и там же можно публиковать инструкции, которые находятся полнотекстовым поиском.

Вопрос из чата. Есть ли встроенный модуль Inventory?

Алла Козлачкова. Мы можем интегрировать систему с чем угодно. Одна из причин, по которой мы используем Comindware, является наличие low-code. Все, что нельзя настроить с помощью low-code, можно настроить с помощью инструмента, позволяющего использовать скрипты. Это наиболее частый метод для создания интеграций.

Сергей Зинкевич. Как дело обстоит с процессом создания процессов?

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

Сергей Зинкевич. То есть не требуется десяток-другой разработчиков, чтобы сделать новый процесс, и я могу сам мышкой перетащить и соединить блоки?

Артем Мукосеев. Нужен толковый аналитик, который умеет настраивать. Если ты умеешь рисовать процессы в Visio, то после небольшого тренинга сможешь это сделать. Главное корректно построить условия с использованием «и/или».

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

Алла Козлачкова. Да, но это не только про скорость запуска, но и про возможность развития — самостоятельно или с помощью партнера-интегратора. Мы это активно используем в запросах на обслуживание. Все больше заказчиков выделяют стандартные запросы — типовые истории. Например, самое популярное — создание рабочего места, когда нужна задачи, чтобы принести стол, стул, создать учетку, настроить права доступа и т. д. Такие стандартные запросы в компаниях формируются и формализуются постепенно. Наш базовый процесс управления запросами мало чем отличается от инцидентов за исключением дополнительного модуля согласования. Расчет сделан именно на то, что заказчики могут начать в рамках базового процесса и постепенно детализировать такие стандартные процессы. Это действительно просто.

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

Алла Козлачкова. Такая возможность есть. Более того, в RockIT Manager даже в базовом виде есть функциональность массовых инцидентов. Когда инцидент указывается как массовый, с ним связываются другие инциденты, и, когда этот массовый инцидент выполняется, т. е. работы завершены, по всем связанным инцидентам расходится такое же решение, и они тоже переходят в состояние «Работы завершены». Кроме того, если нужны другие специфические связи, все можно настроить.

Артем Мукосеев. Можем поговорить про чуть более сложные процессы. Их делают по-разному, даже в рамках одной компании разные направления зачастую подходят очень по-разному. Если в компании подробно выстроена разработка софта, то там может быть сложный процесс, например, коллеги работают с User Story и часто работают в Jira. Большая задача делится на много маленьких, и сам процесс зачастую может состоять из нескольких шагов. Например, сначала разработчик разрабатывает и передает группе, которая разворачивает все в тестовой среде, потом отдельные люди тестируют, переносят в следующую среду и т. д. А инфраструктурные изменения значительно проще, там действует принцип «принесли-подключили-работает». По разным системам, например, веб-приложениям, сложным монолитным системам (например, SAP) используются свои процессы.

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




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

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

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

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

Все можно настроить под себя, при этом на верхнем уровне все выглядит как в ITIL, т. е. универсально.

Вопрос из чата. Какая есть отчетность «из коробки»?

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

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

Алла Козлачкова. Да, наш роадмап максимально ориентирован на запросы заказчиков.

Сергей Зинкевич. Клиентоориентированность — это здорово. Мы, когда разрабатываем облако, тоже ориентируемся на запросы заказчиков.

Вопрос из чата. Есть ли учет трудозатрат?

Алла Козлачкова. Мы презентовали роадмап в начале 2023 года. Сначала вопросов про трудозатраты было немного, но в последнее время их количество возросло, поэтому дорожная карта будет меняться.

Сергей Зинкевич. А доступ из Power BI?

Алла Козлачкова. Интегрировать и передавать данные для построения отчетности Power BI, конечно, можно, как и в любую BI-систему. Есть разные варианты интеграции. В зависимости от используемой системы отчетности, она может сама забирать данные либо данные могут передаваться из RockIT Manager, событийно или по расписанию.

Вопрос из чата. Кто и как настраивает процессы?

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

Алла Козлачкова. Если есть какие-либо интеграции, все сложнее, разумеется.

Вопрос из чата. Расскажите про структуру ролей в привязке к сотрудникам. Насколько это гибкая система?

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

В RockIT Manager базовая роль — это пользователь портала, который подает заявки, отвечает на запросы дополнительной информации, подтверждает выполнение, а также может участвовать в согласовании (пользователь портала может быть согласующим, и для этого не нужна дополнительная лицензия). Также базовые роли — это сотрудник первой линии, сотрудник второй линии (исполнители) и менеджеры (для изменений, для инцидента).

Все гибко настраивается в зависимости от задач.

Вопрос из чата. Как обеспечивается безопасность доступа к данным при использовании системы из облака?

Алла Козлачкова. В базовом виде мы подключаем:

• SSL (HTTPS-сертификаты),
• single sign-on, чтобы только доменные пользователи могли заходить в систему.

Из мобильного интерфейса нет даже теоретического доступа к администрированию системы.

Сергей Зинкевич. Не могу оставаться в стороне от темы ИТ-безопасности в облаке. В чем разница между сервисом из облака и у себя? Обычно облачная инфраструктура более безопасна, чем инфраструктура on premise, например, потому что у нас в облаке есть результаты теста на проникновение не старше полугода, поскольку мы делаем его два раза в год. Это связано с тем, что мы работаем в соответствии с множеством стандартов, включая PCI DSS (Payment Card Industry Data Security Standard), ГОСТ 57580 для финансовых платформ и др. Мы очень любим вопросы, связанные с безопасностью, потому что по этим вопросам у нас твердая «пятерка».

Алла Козлачкова. Именно поэтому многие заказчики предпочитают сервис из облака, где про инфраструктуру и безопасность думают другие.