The task of registering and recording applications in the IT-department

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

Методы. В качестве объекта исследования выбран процесс обработки технических заявок, который представляет собой последовательность этапов: регистрация запроса на устранение проблемы; анализ и назначение (фиксация элементов конфигурации, расчёт приоритета, постановка в очередь); непосредственная работа над сбоем (возможность переназначения, управления очередями); эскалация на более высокий уровень поддержки при нехватке времени или компетенций; устранение инцидента силами специалиста или автоматически; подтверждение закрытия заявки пользователем либо её повторное открытие.

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

В работе рассматриваются два основных класса программных решений: Help Desk и Service Desk [3-7]. Service Desk представляет собой более широкую IT‑систему, охватывающую помимо технической поддержки контроль качества сервисов, отчётность, анализ корневых причин инцидентов и проактивное управление IT‑процессами. Выбор конкретного подхода зависит от масштабов и задач организации [7, 8].

Help Desk ориентирован на приём, регистрацию, маршрутизацию и обработку пользовательских обращений (внутренних или внешних), обеспечивая автоматизацию работы службы поддержки [9-12].

Для сравнительного анализа были отобраны два представительных продукта: открытая система управления активами и заявками GLPI (с возможностью доработки) и российская коммерческая платформа HelpDeskEddy (предлагающая облачное и коробочное развёртывание). Оценка проводилась по критериям функциональности, стоимости, сложности внедрения, способа развёртывания и соответствия требованиям к отечественному ПО.

Результаты. Анализ показал, что ручной учёт через телефонные звонки не обеспечивает ни управляемости, ни накопления статистики. Существующие коммерческие и открытые системы имеют значительные ограничения.

GLPI — бесплатное решение с открытым исходным кодом, поддерживает полный цикл заявок и автоматический расчёт приоритета на основе срочности и влияния. Однако оно требует высокой квалификации администраторов для развёртывания и сопровождения, а также не входит в реестр отечественного ПО Минцифры (проект французской разработки), что делает его неприемлемым для государственных учреждений [13, 14].

HelpDeskEddy — российская система, что формально допускает её использование в госорганах. Предлагает два варианта развёртывания: облачный (данные хранятся на серверах провайдера, что лишает организацию прямого контроля и создаёт зависимость от внешнего поставщика) и локальный («коробочный»). При этом продукт распространяется по подписной модели, что влечёт регулярные финансовые затраты, особенно ощутимые для бюджетных учреждений [15].

Таким образом, ни одна из рассмотренных систем в полной мере не удовлетворяет требованиям небольшого ИТ‑отдела: GLPI — из-за сложности и отсутствия в реестре, HelpDeskEddy — из-за потери контроля над данными (в облаке) или дополнительных расходов (при локальной установке). Многие другие тиражные решения также страдают избыточной функциональностью, сложностью настройки или не учитывают внутренние регламенты учреждений.

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

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