От заявки к выполнению: как связать ITSM и управление рабочими местами

Заявка может быть зарегистрирована, согласована и обработана по SLA, но техническое действие на рабочем месте по-прежнему выполняется вручную. Разбираем, как связать ITSM/Service Desk с Колибри-АРМ, автоматизировать исполнение типовых запросов и часть операций перевести в контролируемое самообслуживание.

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

Но после согласования часто остается еще один этап — фактически выполнить требуемое действие на устройстве.

Специалист открывает систему управления рабочими местами, находит компьютер, выполняет операцию, проверяет результат, возвращается в Service Desk и обновляет статус.

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

Колибри-АРМ позволяет автоматизировать эту «последнюю милю» сервисного процесса. ITSM или Service Desk управляет заявкой, согласованиями, сроками и сервисной логикой, а Колибри-АРМ выполняет предусмотренные операции на рабочих станциях и серверах.

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

Запросить пилот

Где после Service Desk остается ручная работа

Рассмотрим простой запрос: сотруднику необходимо корпоративное приложение.

С точки зрения ITSM процесс может быть организован правильно:

1. пользователь создает заявку;
2. система определяет ее категорию;
3. запрос направляется на согласование;
4. владелец лицензии или руководитель подтверждает установку;
5. заявка поступает в работу;
6. соблюдение SLA контролируется автоматически.

После этого начинается техническое исполнение:

7. инженер открывает систему управления устройствами;
8. ищет компьютер сотрудника;
9. выбирает нужный пакет;
10. назначает установку;
11. проверяет результат;
12. возвращается в Service Desk;
13. изменяет статус заявки.

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

При сотнях однотипных запросов несколько ручных минут на каждом превращаются в существенную нагрузку.

Дополнительно появляются риски:

• выбрать не то устройство;
• назначить неправильный пакет;
• пропустить этап;
• выполнить действие, но не вернуть результат в Service Desk;
• задержать исполнение из-за очереди ручных операций.

Следующий уровень автоматизации — связать сервисное решение с техническим действием на устройстве.

Как ITSM, ESM, CMDB и Колибри-АРМ работают вместе

В зрелой сервисной архитектуре разные системы отвечают за разные этапы процесса и дополняют друг друга.

Колибри-АРМ добавляет к сервисной архитектуре исполнительный уровень для рабочих станций и серверов Windows/Linux.

Так получается связка:

сервисный запрос → решение и согласование → техническое исполнение → контроль результата.

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

«Последняя миля» сервисного процесса

Разрыв между заявкой и фактическим исполнением возникает не только при установке ПО.

Запрос на приложение

Заявка согласована — после этого приложение необходимо установить на конкретное устройство.

Подключение нового компьютера

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

Диагностика

Service Desk принимает обращение — специалисту необходимы актуальные сведения об ОС, оборудовании, установленном ПО и конфигурации устройства.

Изменение конфигурации

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

Onboarding сотрудника

HR инициирует процесс — ИТ-служба должна подготовить рабочее место, установить необходимые приложения и привести устройство к требуемой конфигурации.

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

управление процессом → техническое исполнение.

ITSM и ESM управляют сервисной логикой, а Колибри-АРМ позволяет автоматизировать предусмотренные действия на управляемых устройствах.

Как OpenAPI связывает сервисный процесс с Колибри-АРМ

В Колибри-АРМ предусмотрен OpenAPI для интеграции с внешними корпоративными системами.

С его помощью после определенного события в Service Desk или другом процессе можно программно инициировать поддерживаемую операцию в Колибри-АРМ.

Например:

заявка согласована → внешняя система инициирует действие → Колибри-АРМ выполняет операцию на устройстве.

В релизе 26.02.2.1 API охватывает операции с компьютерами, коллекциями и папками внутри коллекций. Доступные сценарии включают работу с объектами компьютеров, добавление устройств в коллекции, запуск инвентаризации и предусмотренных административных команд.

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

Архитектурно роли распределяются просто:

ITSM / Service Desk — бизнес-логика, согласования и маршрутизация;

OpenAPI — программное взаимодействие между системами;

Колибри-АРМ — техническое выполнение предусмотренной операции.

Так интеграция позволяет автоматизировать процесс, сохраняя сервисную логику там, где ею уже управляет ITSM.

Сценарий 1. Установка ПО после согласования заявки

Один из наиболее понятных сценариев — установка корпоративного приложения.

Последовательность может выглядеть так:

1. пользователь запрашивает ПО через Service Desk;
2. заявка проходит согласование;
3. определяется целевое устройство;
4. после одобрения внешняя система инициирует предусмотренную операцию;
5. устройство включается в нужную коллекцию или иной настроенный процесс;
6. Колибри-АРМ выполняет развертывание;
7. результат используется для дальнейшей обработки заявки.

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

Стандартное техническое исполнение можно автоматизировать.

В результате сокращается интервал между:

«заявка согласована»

и

«приложение фактически установлено».

Сценарий 2. Подключение нового рабочего места

Другой типовой процесс — ввод компьютера в эксплуатацию.

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

В зависимости от архитектуры и доступных API-операций процесс может включать:

• создание или обработку объекта компьютера;
• размещение в необходимой структуре;
• добавление в коллекции;
• запуск инвентаризации;
• дальнейшее назначение предусмотренных политик и операций.

При массовом вводе рабочих мест эффект особенно заметен: одна и та же последовательность перестает вручную повторяться для каждого компьютера.

ИТ-служба получает возможность масштабировать стандарт подготовки нового АРМ.

Сценарий 3. Актуальные технические данные для сервисного процесса

Качество сервисного решения зависит не только от маршрута заявки, но и от исходных данных.

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

• о версии ОС;
• аппаратной конфигурации;
• установленном ПО;
• версии приложения;
• сетевых параметрах;
• фактическом состоянии устройства.

Колибри-АРМ собирает технические сведения об управляемых рабочих станциях и серверах.

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

Вместе системы дают более полную картину:

Колибри-АРМ → фактическое техническое состояние;

CMDB → корпоративный контекст и связи.

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

От автоматизации заявки к самообслуживанию

Для части стандартных запросов можно сделать следующий шаг — убрать лишний промежуточный этап и дать пользователю возможность получить разрешенную ИТ-услугу самостоятельно.

Предположим, приложение:

• разрешено ИТ-службой;
• не требует индивидуального согласования;
• подготовлено для централизованной установки;
• доступно определенной группе сотрудников.

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

Для подобных сценариев в Колибри-АРМ предусмотрен Центр корпоративных приложений.

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

Получается цепочка:

пользователь → разрешенная операция → выполнение

вместо:

пользователь → заявка → очередь → специалист → выполнение.

Для массовых и заранее разрешенных запросов это помогает одновременно:

• сократить число типовых обращений;
• уменьшить нагрузку на поддержку;
• ускорить получение нужного ПО или услуги.

Самообслуживание под контролем ИТ-службы

Self-service в Колибри-АРМ строится как управляемое самообслуживание.

ИТ-служба заранее определяет:

• какие приложения публикуются;
• каким пользователям или группам они доступны;
• какие операции разрешено запускать;
• какие задачи могут выполняться с повышенными привилегиями.

Пользователь выбирает действие внутри подготовленного ИТ-службой набора.

Так совмещаются две цели:

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

Типовые административные задачи без постоянных прав администратора

Особенно полезен self-service для действий, которые требуют повышенных привилегий.

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

Такой сценарий подходит для операций, где:

• действие заранее определено;
• оно разрешено ИТ-службой;
• результат воспроизводим;
• участие администратора не требует отдельного экспертного решения.

Это уже не просто ускорение Service Desk, а сокращение самого потока рутинных обращений.

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

Когда сохранять Service Desk в цепочке

Самообслуживание наиболее эффективно для стандартных и заранее разрешенных действий.

Если операция требует:

• индивидуальной лицензии;
• одобрения руководителя;
• дополнительной проверки;
• оценки риска;
• согласования с ИБ;
• экспертного решения специалиста,

Service Desk сохраняет свою роль владельца процесса.

Тогда работает схема:

запрос → проверка → согласование → автоматизированное исполнение → контроль результата.

Для стандартных операций можно использовать:

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

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

Как Колибри-АРМ участвует в ESM-процессах

ESM — Enterprise Service Management — распространяет сервисную модель за пределы ИТ.

Хороший пример — onboarding нового сотрудника.

Общий процесс может включать:

• действия HR;
• создание учетной записи;
• предоставление доступов;
• выдачу оборудования;
• подготовку рабочего места;
• установку приложений;
• административные процедуры.

В такой цепочке Колибри-АРМ может выполнять endpoint-часть процесса:

HR инициирует onboarding → формируется ИТ-этап → определяется рабочее место → Колибри-АРМ выполняет предусмотренные операции на устройстве → процесс продолжается.

То есть ESM управляет межфункциональным процессом, а Колибри-АРМ помогает автоматизировать его техническое исполнение на рабочих станциях и серверах.

Это позволяет включать endpoint management в более широкие корпоративные сервисные сценарии без дублирования функций между системами.

Какие процессы автоматизировать первыми

Нет необходимости начинать с масштабной интеграции всех корпоративных систем.

Лучший первый кандидат обычно соответствует трем критериям:

• процесс часто повторяется;
• алгоритм достаточно стабилен;
• экспертное решение требуется только в отдельных точках или не требуется вовсе.

Хорошими стартовыми сценариями могут быть:

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

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

Как измерять результат

Оценивать стоит не только SLA обработки самой заявки.

Для технического исполнения полезны отдельные показатели.

Особенно показательна метрика:

время от согласования до фактического изменения на устройстве.

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

Как Колибри-АРМ дополняет сервисную архитектуру

Колибри-АРМ дает сервисной модели то, чего ей часто не хватает для сквозной автоматизации, — управляемый исполнительный контур на рабочих станциях и серверах.

В общей архитектуре роли могут распределяться следующим образом:

Колибри-АРМ получает фактические сведения об управляемых Windows/Linux-устройствах и выполняет предусмотренные административные операции.

Благодаря этому сервисные платформы можно дополнить техническим исполнением:

запрос → решение → действие на устройстве → результат.

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

Как спроектировать интеграцию через OpenAPI

OpenAPI дает техническую основу для включения Колибри-АРМ в корпоративный сервисный процесс.

Перед реализацией полезно определить:

1. какой процесс автоматизируется;
2. какая система является его владельцем;
3. как определяется целевое устройство;
4. какая операция должна выполняться;
5. что считается успешным результатом;
6. как обрабатывается ошибка;
7. какой статус необходимо вернуть во внешнюю систему;
8. какие права получает интеграционная учетная запись;
9. какие методы доступны в используемой версии Колибри-АРМ.

Так интеграция проектируется вокруг конкретного результата.

Например:

«после согласования заявки установить приложение на рабочее место пользователя и вернуть статус выполнения»

значительно точнее, чем абстрактная задача:

«интегрировать Service Desk с системой управления АРМ».

Что проверить на пилоте

Первый пилот лучше строить вокруг одного частого и понятного запроса.

Например — установки согласованного приложения.

Проверьте:

1. создание заявки в Service Desk;
2. прохождение стандартного согласования;
3. определение целевого устройства;
4. передачу предусмотренной операции;
5. выполнение действия в Колибри-АРМ;
6. обработку успешного результата;
7. поведение при ошибке или недоступности устройства;
8. возврат результата в сервисный процесс.

Параллельно можно выбрать приложение, которое не требует согласования, и опубликовать его в Центре корпоративных приложений.

Тогда в одном пилоте сравниваются две модели:

ITSM → согласование → автоматическое исполнение

и

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

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

Часто задаваемые вопросы об интеграции ITSM и Колибри-АРМ

Как распределяются роли между ITSM и Колибри-АРМ?

ITSM или Service Desk управляет заявкой: регистрацией, SLA, маршрутизацией и согласованием.

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

Вместе системы позволяют построить сквозной процесс от запроса до результата.

Можно ли использовать Колибри-АРМ в ESM-процессах?

Да. Колибри-АРМ может выступать исполнительным уровнем для операций на рабочих местах и серверах внутри более широкого ESM-процесса.

Например, при onboarding система может автоматизировать предусмотренную подготовку рабочего места после запуска соответствующего ИТ-этапа.

Можно ли интегрировать Колибри-АРМ с Service Desk?

Да. Для интеграционных сценариев предусмотрен OpenAPI. Конкретная реализация зависит от используемого Service Desk, версии Колибри-АРМ и выбранного процесса.

Можно ли автоматически устанавливать ПО после согласования заявки?

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

Как распределяется логика между ITSM и OpenAPI?

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

Это позволяет автоматизировать техническое исполнение без переноса сервисной логики из профильной системы.

Можно ли использовать Колибри-АРМ вместе с CMDB?

Да. Колибри-АРМ предоставляет фактические технические сведения об управляемых устройствах, а CMDB может хранить их бизнес-контекст и связи.

Совместное использование данных дает сервисным процессам более полную информацию об объекте.

Что такое Центр корпоративных приложений?

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

Может ли пользователь выполнять задачи с повышенными привилегиями?

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

Когда лучше использовать самообслуживание, а когда Service Desk?

Стандартные и заранее разрешенные операции удобно переводить в самообслуживание.

Если требуются лицензирование, согласование, проверка или экспертное решение, Service Desk сохраняет управление процессом, а Колибри-АРМ может автоматизировать техническое исполнение после одобрения.

От управления заявкой — к управлению результатом

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

Приложение должно быть установлено. Рабочее место — подготовлено. Требуемое изменение — выполнено.

ITSM и ESM структурируют запрос, определяют владельцев, управляют согласованиями и контролируют сроки.

Колибри-АРМ добавляет к этой модели техническое исполнение на рабочих станциях и серверах.

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

В результате ИТ-служба может последовательно перейти через три модели:

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

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