Несколько ИТ-подрядчиков: как организовать общую ответственность за результат

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

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

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

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

Как понять, что инфраструктура осталась без ответственного

Есть несколько характерных признаков:

• Заявки ходят по кругу. При серьезном сбое подрядчики выясняют, чья это проблема, вместо совместного поиска причины.
• Знания сосредоточены у отдельных людей. Важные настройки и зависимости известны только инженеру, который когда-то создавал систему.
• Отчетность не отражает состояние сервисов. Руководство видит количество заявок и доступность оборудования, но не понимает, насколько стабильно работают процессы, от которых зависит бизнес.
• Изменения приводят к неожиданным сбоям. Подрядчики не согласуют работы и не учитывают влияние на другие компоненты.

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

Кто должен отвечать за всю инфраструктуру

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

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

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

В зависимости от ресурсов компании эту роль можно закрепить за внутренним ИТ-руководителем или передать внешнему партнеру.

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

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

Важно понимать: передача всех работ одному подрядчику сама по себе не решает проблему. Даже один поставщик может отвечать только за выполнение отдельных задач, не принимая на себя ответственность за доступность бизнес-сервисов. Главное — наличие единого центра управления.

Как выстроить единую систему ответственности

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

1. Составить карту критичных сервисов

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

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

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

2. Закрепить полномочия интегратора

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

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

3. Организовать единую точку входа

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

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

4. Согласовать действия при крупных сбоях

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

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

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

5. Согласовать правила работы с подрядчиками

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

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

6. Контролировать изменения и вести документацию

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

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

7. Пересмотреть отчетность

Руководству важно видеть не только количество обращений и время реакции, но и показатели, отражающие реальную работу ИТ-сервисов:

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

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

Как организовать комплексное сопровождение

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

Такой подход использует ГК «СОЦИАЛИТ». Компания специализируется на комплексном ИТ-аутсорсинге и сопровождает инфраструктуру организаций с распределенной сетью подразделений. В зоне ответственности — поддержка пользователей и рабочих мест, администрирование серверов, обслуживание сетей, информационная безопасность, сопровождение 1С и Битрикс24.

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

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

Для компаний с филиалами в разных регионах важна единая модель обслуживания на местах. «СОЦИАЛИТ» использует собственную команду и партнерскую сеть, обеспечивая техническую поддержку более чем в 70 городах России. При необходимости к удаленной диагностике подключаются выездные инженеры.

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

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

Подробнее о возможностях и подходе компании — на официальном сайте ГК «СОЦИАЛИТ».

Как работает система с единой ответственностью

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

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

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

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

С чего начать

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

1. Назначить ответственного за работу критически важных ИТ-сервисов и координацию подрядчиков.
2. Описать ключевые сервисы и определить, какие компоненты обеспечивают их работу и кто за них отвечает.
3. Установить общие правила взаимодействия: порядок обработки заявок, привлечения специалистов и действий при серьезных сбоях.

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

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

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

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