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

Прежде всего, несколько общих моментов:

1. Назначение интеграции. Необходимо понимать, для чего проводится интеграция. Возможно для усиления контроля качества работы поставщика? Или для получения формальных данных для оценки стоимости услуг поставщика? Или для экономии времени своих специалистов за счет освобождения их от необходимости исполнять роль промежуточного звена между поставщиком и пользователем? От понимания назначения могут зависеть ответы на многие другие вопросы проекта.
2. Охват интеграции. Следует определиться, по каким вопросам планируется организовать взаимодействие поставщика и заказчика. Это может быть выполнение типовых запросов по настройке АРМ, решение любых заявок по какой-либо ИТ-системе, устранение инцидентов в сетевой инфраструктуре и т.д. Чем точнее получится определить охват, тем легче будет прорабатывать детали интеграции.
3. Основные бизнес-сценарии. На какой стороне могут регистрироваться инциденты, запросы, и прочие объекты? Возможна ли остановка обработки запроса? Возможна ли многократная передача ответственности за обработку между организациями? Могут ли пользователи напрямую взаимодействовать  со специалистами поставщика (т.е. не своей организации)? Возможно ли завершение обработки на стороне поставщика без подтверждения со стороны инициатора? И так далее.
4. Механизмы эскалации. Даже продумав все основные сценарии, мы не исключаем возможность возникновения непредвиденных ситуаций, поэтому обязательно нужно предусмотреть правила обработки исключений. Например, у поставщика нет возможности выполнить работы; к поставщику поступают запросы от незарегистрированных пользователей/филиалов и т.д., поставщик затягивает с решением и его нужно как-то поторопить. К кому обращаться поставщику, и к кому обращаться заказчику в подобных ситуациях?
5. Правила/процедуры контроля договоренностей. Правильно организованные точки эскалации помогут оперативно решить множество непредвиденных проблем. В то же время есть ряд негативных ситуаций, типичных для ITSM-процессов – это, например, нарушение сроков или низкое качество выполнения работ. Полностью таких ситуаций не избежать, поэтому следует предусмотреть их периодический обзор, анализ, а также выполнение корректирующих действий и (возможно) применение штрафов и санкций.
6. Права и роли. Следует понимать, кто и в какой роли будет участвовать во взаимодействии. Например, возможность назначать заявки на специалистов поставщика может быть у любого сотрудника заказчика, а может быть только у специально выделенной группы (например, службы service desk). Или, например, кто-то должен быть ответственным за функционирование технической составляющей интеграции, а кто-то должен понимать и быть ответственным за ее бизнес-логику.

Разобравшись с общими вопросами, можно чуть более детально посмотреть на данные, которыми предстоит обмениваться:

1. Синхронизируемые объекты. Исходя из назначения и охвата интеграции, а также учитывая правила работы поставщика и заказчика, следует определить, какие объекты в системе заказчика и поставщика будут синхронизироваться. Это могут быть «инциденты», «запросы на обслуживание», «задания» и т.д. Иногда в различных системах это будут разные объекты, например, «задания» у заказчика и «инциденты» у поставщика.
2. Точки синхронизации этапов обработки. После определения объектов, подлежащих синхронизации, следует подробнее рассмотреть их жизненные циклы. На основе бизнес-сценариев можно выделить все основные события, информацию о которых нужно передавать между системами. Таким образом, можно построить три списка:

    

   • Перечень событий, инициирующих пересылку (с обеих сторон)
   • Перечень команд, отправляемых при возникновении этих событий 
   • Перечень реакций на эти команды (с обеих сторон)
3. Передаваемые данные. Для реализации определенной реакции на те или иные события система, получающая команду, должна получать и необходимый набор данных. Для каждой команды следует определить те данные, которые в рамках нее передаются.
4. Справочники. Среди передаваемых данных могут оказаться справочники. Для ITSM-систем типичными справочниками являются оргструктура, список сотрудников, список территорий, классификаторы объектов. Поскольку виды справочников и данные в них разнятся от системы к системе, следует продумать, каким образом данные справочника одной системы будут превращаться в данные справочника другой системы. Возможно, стоит производить периодическую синхронизацию справочников, а может быть стоит зафиксировать некоторые значения по умолчанию в одной системе, используемые для объектов в другой системе.

В качестве хорошего примера модели, описывающей типовые команды, их параметры и типы данных, правила их обработки, можно использовать «Унифицированный протокол интеграции ITSM-систем». 

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

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

    

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

И наконец, есть несколько важных технических деталей:

1. Транспортная среда. Безусловно, важно выбрать удовлетворяющий всем требованиям механизм передачи команд. Это может быть e-mail, веб-сервисы, промежуточные базы данных или файлы, интеграционные шины и т.д. Выбор транспортной среды зависит, в частности, от необходимости обеспечения:

    

   • Гарантированной доставки
   • Правильного порядка отправки команд
   • Достаточной скорости передачи данных
2. Формат сообщений. Определившись с транспортной средой, следует продумать формат сообщений.
3. Формат данных. И, конечно же, нужно обязательно понимать, что из себя представляет каждый параметр передаваемой команды, к какому типу данных он относится, какого он может быть размера и как его интерпретировать при получении. Отдельное внимание стоит уделять датам и часовым поясам, ссылкам на элементы справочников, файлам и их расширениям, длинным и форматированным текстовым полям и т.д.

АВТОМАТИЗАЦИЯ

Реестр ESM- и ITSM-систем в России 2024

Из чего выбирать и на что мигрировать