Привет, на связи Авдей Мартынович, руководитель направления среднего и малого бизнеса, ALP ITSM. В своей практике я постоянно вижу договоры, где заказчик платит за закрытые тикеты, а не за то, что бизнес работает без остановок.

Об ALP ITSM. Компания работает вот уже 30 лет, с 1996-го. Мы берем на себя ИТ-инфраструктуру бизнеса и отвечаем за результат не только технически, но и деньгами. Нашу поддержку в 900+ городах России и СНГ обеспечивают 2100+ специалистов. Про модели оплаты в договорах знаем с обеих сторон стола.

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

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

Кейт Витасек, исследователь Университета Теннесси, назвала это «ловушкой активности». Подрядчику платят за действия, а не за результат, поэтому ему выгодно, чтобы действий было больше. Дело не в том, что подрядчик плохой, а в том, что так устроен договор.

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

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

В связи с этим возникает несколько типичных проблем.

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

Микроменеджмент вместо доверия. Заказчик не верит, что подрядчик сделает хорошо сам, и устанавливает ему жесткий SLA (соглашение об уровне сервиса), создавая контроль ради контроля. Подрядчик становится ответственным за результат, но лишается права на инициативу, делает только то, что прописано, даже если знает решение лучше. Клиент нанимает эксперта и тут же запрещает ему быть экспертом.

Спад после «медового месяца». В начале отношений подрядчик старается изо всех сил. Дальше, по наблюдениям Gartner, удовлетворенность падает: поднимать уровень сервиса незачем, по договору за это не платят. Сервис тихо деградирует, пока заказчик не решает сменить подрядчика, и цикл запускается заново.

Итог закономерный. По оценке Aberdeen Group, до 75% запланированной экономии от аутсорсинга растворяется за первые полтора года. Кажется, что просчитали экономику и аутсорсинг позволит экономить, а деньги утекают через перекосы: микроменеджмент, дополнительные простои и работу, обусловленную снижением качества сервиса.

Альтернатива простая на словах и сложная на деле: платить не за активность, а за результат. Не за закрытые заявки, а за то, что бизнес работает без простоев. Эту модель Витасек описала как Vested Outsourcing. У подрядчика появляется заинтересованность в вашем результате, а не в объеме отгруженных услуг.

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

На уровне собственника модель сводится к нескольким принципам.

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

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

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

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

И последнее. Управление строится на понимании, а не на надзоре. Доверять эксперту и держать над ним армию контролеров — это разные вещи. Хороший договор дает прозрачность, а не превращает вас в надсмотрщика.

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

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

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

• успех описан несколькими понятными показателями, а не толстым регламентом;

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

Пока что картина выходит слишком черно-белой. Почасовая оплата сама по себе не делает подрядчика заинтересованным в ваших сбоях. «Ловушка активности» срабатывает только там, где в договоре нет финансовой ответственности за результат. Уберите эту ответственность, и любая модель скатится в погоню за лишними заявками. Впишите ее, и почасовая оплата перестанет работать против вас.

Поэтому выбирать стоит не «плохую» или «хорошую» модель, а смотреть на две ее характеристики сразу.

Зрелость заказчика. Готовы ли вы управлять подрядчиком через метрики: договориться о показателях, смотреть на доступность и время восстановления, держать SLA под контролем, а не считать закрытые заявки. 

Зрелость подрядчика. Выстроены ли у него процессы: ITIL, управление проблемами (а не только решение инцидентов), финансовая ответственность и гарантии в договоре. Если это есть, повременная модель со SLA дает клиенту тот же результат, что и оплата за результат: зрелый подрядчик и так сводит число сбоев к минимуму, потому что отвечает за доступность рублем.

Иными словами, дело не в модели, а в том, прописана ли в договоре ответственность за итог и хватает ли обеим сторонам зрелости эту ответственность держать.

Модель «на результат» подходит не для всего. Витасек предлагает делить ИТ-функции по двум осям: ценность для бизнеса и собственная экспертиза.

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

Разница между «платим за активность» и «платим за результат» видна на типовых ситуациях.

Дистрибьютор платил подрядчику за закрытые заявки. 1С подвисала почти каждую неделю, инженер исправно перезапускал ее: час работы, заявка в счет. Искать причину было невыгодно, ведь меньше сбоев означало меньше оплаченных часов. Тогда в договор внесли метрику доступности 1С в рабочее время. У подрядчика появилась мотивация решить проблему. А причиной оказался сервер 2016 года, не тянувший выросшую базу. Сервер заменили, подвисания прекратились. Заказчик перестал терять часы на закрытии месяца, от подрядчика отказались, ведь проблемы не стало. Но в один прекрасный момент 1С легла так, что мало не показалось. Подрядчика вернули, поняли важность наличия сопровождения и почему нужно платить, даже когда все работает.

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

И напоследок негативный пример. Производственная компания перешла на минимальное обслуживание подешевле, по классической транзакционной модели «починим, когда сломается». При переезде уронили старый сервер, резервные копии лежали на том же массиве, что и боевые данные. Восстановление заняло четверо суток. Дешевый подрядчик честно отработал свои деньги. Он и не обещал, что сервер не упадет, он получал оплату за активность, а не за результат.

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

1. За что я плачу: за закрытые заявки и часы или за то, что бизнес работает без простоев? Если за первое, у подрядчика нет причины уменьшать число сбоев.

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

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

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

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

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