Поддержка ИТ-систем традиционно воспринимается как обязательная, но далеко не самая дорогая статья расходов на аутсорсинг. Но на практике часто происходит, что после обращения к вендору или интегратору стоимость поддержки оказывается значительно выше ожидаемой. После этого начинаются долгие обсуждения SLA, состава команды, объема часов и поиск компромисса между качеством сервиса и бюджетом — что не всегда позитивно отражается на итоговом сервисе.
Однако если экономия все же является одним из ключевых приоритетов, существует ряд подходов, которые позволяют существенно сократить затраты на ПО без снижения качества обслуживания. О них рассказывает Ибрагим Габидуллин, руководитель отдела разработки .NET компании ICL Services.
Из чего состоит стоимость поддержки
Прежде чем говорить об экономии, важно понять структуру затрат.
Вопреки распространенному заблуждению, стоимость поддержки формируется не только из количества инцидентов, так как даже две системы с одинаковым количеством обращений могут стоить в поддержке совершенно по-разному. Если в одной есть актуальная документация и понятная архитектура, а в другой знания остались только у нескольких разработчиков, трудозатраты будут несопоставимы.
Формируя предложение, аутсорсер обычно закладывает в стоимость процессы обработки инцидентов, сопровождение изменений и релизов, поддержку 24/7, а также поддержание экспертизы по системе, обновление базы знаний и резервирование ресурсов на случай критических сбоев.
В целом расходы можно поделить на пять составляющих:
- покупка или подписка на системы обслуживания, средства мониторинга доступности и производительности, антивирусы и иные средства защиты информации (при наличии);
- затраты на облачные хостинги, дата-центры, серверное оборудование, каналы связи и системы резервного копирования данных (при наличии);
- расширенная поддержка от вендоров или производителей оборудования;
- оплата труда инженеров первой, второй и третьей линий техподдержки, системных администраторов, DevOps-специалистов и менеджеров проекта;
- рабочие места, обучение персонала и регламентные аудиты безопасности.
Как снизить расходы на поддержку ПО
1. Расширить периметр поддержки
Один из неочевидных способов снизить стоимость — передать в поддержку не одно приложение, а целый пул связанных систем (например, связанных по бизнес-логике или по технологиям).
Кажется, что больше систем автоматически приведут к росту бюджета, но на деле часто происходит обратное. Когда интегратор берет на сопровождение несколько приложений, он может гибко распределять загрузку специалистов и снижать долю административных расходов.
Менеджмент и сервисные процессы становятся общими, проще организовать резервирование сотрудников, а команда начинает лучше понимать, как связаны между собой системы и как пользователи работают с ними в реальных бизнес-процессах.
Условно говоря, выделить специалиста на 20% времени под одну систему интегратору невыгодно, а загрузить его несколькими связанными приложениями, сразу на 100% — отличный сценарий, позволяющий предложить заказчику более привлекательные условия.
2. Выстроить сильную вторую линию поддержки
Во многих организациях любая нестандартная проблема сразу эскалируется в сторону вендора или на третью (или даже четвертую) линию поддержки. Это генерирует постоянные расходы на дорогостоящих экспертов.
Гораздо выгоднее инвестировать в развитие второй линии. Такой подход называется — Shift Left, когда большая часть проблем решается не дорогостоящей третьей линией, а второй или даже первой линией поддержки. Если обучить вторую линию и дать ей понятные инструкции, значительную часть обращений можно решить без привлечения дорогих экспертов третьей линии. Такие специалисты способны закрывать до 70% инцидентов промышленной эксплуатации: они могут анализировать причины ошибок, восстанавливать сервис по стандартным регламентам, корректировать настройки и забирать на себя типовые запросы пользователей.
Дорогая экспертиза третьей линии в такой модели подключается только в случае архитектурных проблем, критических сбоев или необходимости править код. Инвестиции в обучение команды и создание базы знаний совместно с вендором окупаются достаточно быстро за счёт того, что количество эскалаций к дорогостоящей третьей линии снижается.
3. Разделить поддержку и развитие системы
Еще одна распространенная ошибка — закладывать в контракт на поддержку весь абстрактный объем будущих доработок. Если система активно развивается, имеет смысл жёстко разделить два направления: промышленную эксплуатацию и реализацию изменений.
Поддержка отвечает за бесперебойную работу системы и выполнение SLA, а все новые функции и доработки оформляются по мере необходимости как отдельные проекты (запросы на изменения) с собственным бюджетом. В этом случае заказчик не оплачивает заранее работы, которые могут вообще не понадобиться, что снижает ежемесячный фиксированный платеж.
4. Снизить количество инцидентов, повысив стабильность ПО
Ещё один эффективный подход — снизить число самих инцидентов. Для этого совместно с вендором и командой поддержки необходимо регулярно проводить аудит и анализ текущего состояния сервиса (Monthly Service Review). Система может регулярно сталкиваться с одинаковыми проблемами; в таком случае нужно искать и устранять первопричины: технический долг, нестабильные интеграции, ошибки конфигурации или проблемы производительности.
Также в таких ситуациях очень помогает анализ корневых причин (Root Cause Analysis) после каждого инцидента. Хороший подрядчик не только закрывает обращения, но и показывает, какие проблемы повторяются из месяца в месяц и как убрать их причину.
5. Автоматизировать рутинные операции
Огромная часть времени инженеров уходит на повторяющиеся действия: перезапуск сервисов, выдачу доступов, сбор типовых отчетов и стандартные проверки. Автоматизация этих процессов с помощью скриптов, ITSM систем и порталов самообслуживания сильно снижает нагрузку на специалистов, а значит и стоимость.
К примеру, можно разработать скрипты Daily Check, которые к утру собирают все проблемы и статистику по системам в поддержке, подготавливают отчет для специалиста поддержки, вышедшему на смену, который на основе отчета уже выполняет необходимые действия. После автоматизации часть работы вообще перестаёт требовать участия человека, поэтому расширение периметра поддержки уже не приводит к пропорциональному росту команды.
6. Провести независимое обследование текущей поддержки
Часто компании переплачивают просто потому, что исторически сложившаяся модель сервиса уже не отвечает реалиям бизнеса. Перед пересмотром контрактов полезно провести комплексный аудит существующих процессов сопровождения, чтобы найти корневые причины избыточных затрат.
Например, можно произвести бесплатное обследование, которое позволяет определить наиболее эффективную модель поддержки. Такое обследование предоставляет не только всесторонний анализ текущих приложений, обращений и инцидентов, но и помочь в формировании дорожной карты для оптимизации сервиса и бюджетов.
Заключение
В условиях ограниченного бюджета особенно важно пересмотреть устоявшиеся шаблоны взаимодействия с подрядчиками. Как показывает опыт, наиболее успешные проекты по оптимизации начинаются с детального обследования текущей модели поддержки ПО. Это позволяет отсеять лишние пункты из контракта и сфокусироваться на действительно критичных для бизнеса сервисах.
Практика показывает, что экономия на поддержке чаще всего достигается не за счёт сокращения команды или ухудшения SLA, а за счёт более грамотной организации процессов. В результате компания платит меньше не потому, что получает меньший сервис, а потому, что сам сервис становится эффективнее. Решающую роль играет лишь правильная архитектура.
Источник: Ибрагим Габидуллин, руководитель отдела разработки .NET компании ICL Services
