Чем больше у вас сбоев, тем больше зарабатывает подрядчик. И это не злой умысел. Так устроена типовая модель оплаты, где исполнителю платят за закрытые заявки и отработанные часы. У него просто нет причины сокращать количество заявок. Разберем, почему «чинить быстро» и «сделать, чтобы не ломалось» — две разные бизнес-модели и как достичь того, чтобы аутсорсер работал по второй. Также поделимся почему дело не столько в модели, сколько в зрелости обеих сторон.
Парадокс, который не замечают
Представьте, что у вас падает 1С раз в неделю. Подрядчик каждый раз быстро поднимает ее за час-другой, инцидент закрыт. Вы платите за обращения, он их закрывает. Все довольны.
Кроме одного. Если подрядчик найдет корневую причину проблемы и решит ее, обращений станет меньше — а с ними упадет и его выручка. Получается, что стабильная работа вашего ИТ напрямую бьет по его доходу. Чем реже у вас ломается, тем беднее его счет.
Кейт Витасек, исследователь Университета Теннесси, назвала это «ловушкой активности». Подрядчику платят за действие, а не за результат, поэтому ему выгодно, чтобы действий было больше. Дело не в том, что подрядчик плохой, а в том, что так устроен договор.
Из обычной жизни есть показательный пример. Французская администрация в Ханое когда-то платила за каждый крысиный хвост, чтобы извести грызунов. Стимул сработал, но не в ту сторону. Местные жители начали разводить крыс. В ИТ-аутсорсинге происходит то же самое, только вместо крыс тут заявки, инциденты и часы поддержки.
Почему вы оплачиваете ненужные действия
Основная причина в том, за что именно вы платите. В большинстве договоров единица оплаты — активность: количество рабочих мест на обслуживании, закрытые тикеты, выезды инженеров, часы работ. Чем больше активности, тем больше счет. Эффективность подрядчика при таком подходе работает против него: оптимизировал процесс, убрал лишние операции и заработал меньше.
В связи с чем возникает несколько типичных проблем.
Бесконечная гонка за экономией. Заказчик каждый год выбирает подрядчика подешевле, меняет одного на другого, но экономит только на бумаге. На практике это замкнутый круг: тендер, переход, снова тендер. Подрядчики устают, что их работу обнуляют ради чужого ценника, и уходят к более спокойным клиентам. Витасек приводит пример компании, которая за пять лет перебрала почти всех сильных поставщиков и осталась с теми, кто послабее. Сэкономила на цене, но потеряла в качестве.
Микроменеджмент вместо доверия. Заказчик не верит, что подрядчик сделает хорошо сам, и устанавливает ему жесткий SLA (соглашение об уровне сервиса), создавая контроль ради контроля. Подрядчик становится ответственным за результат, но лишается права на инициативу, делает только то, что прописано, даже если знает решение лучше. Нанимают эксперта и тут же запрещают ему быть экспертом.
Спад после «медового месяца». В начале отношений подрядчик старается изо всех сил. Дальше, по наблюдениям Gartner, удовлетворенность падает, т.к. поднимать уровень сервиса незачем, по договору за это не платят. Сервис тихо деградирует, пока заказчик не решает сменить подрядчика, и цикл запускается заново.
Итог закономерный. По оценке Aberdeen Group, до 75% запланированной экономии от аутсорсинга растворяется за первые полтора года. Кажется, что просчитали экономику и аутсорсинг позволит экономить, а деньги утекают через перекосы — микроменеджмент, дополнительные простои и работы из-за снижения качества сервиса.
Что значит «аутсорсинг на результат»
Альтернатива простая на словах и сложная на деле: платить не за активность, а за результат. Не за закрытые заявки, а за то, что бизнес работает без простоев. Эту модель Витасек описала как Vested Outsourcing. У подрядчика появляется заинтересованность в вашем результате, а не в объеме отгруженных услуг.
Меняется не состав работ. Серверы все так же надо администрировать, заявки отрабатывать. Меняется единица, за которую вы платите, а вместе с ней и мотивация подрядчика. Если он зарабатывает на доступности ваших систем, ему впервые становится выгодно, чтобы у вас ничего не ломалось.
На уровне собственника модель сводится к нескольким принципам.
Главное — платить за итог, а не за процесс. Метрика теперь не «сколько заявок закрыто», а «сколько часов простоя было», «какая доступность у критичных систем», «как быстро бизнес восстанавливается после сбоя».
Дальше вы говорите подрядчику, что вам нужно, а как именно он это сделает — уже его забота. Вы ведь передали ИТ на сторону, потому что внутри дорого или некому. Странно после этого диктовать эксперту каждый шаг.
Целей должно быть немного. И все они должны быть измеримы. Не сто метрик, а пять, по которым обе стороны заранее определили критерии достижения.
Предмет договора прописывается так, чтобы аутсорсеру было выгодно вкладываться в надежность. Подрядчик снизит число сбоев и заработает больше. Тогда он сделает это сам, без вашего контроля.
И последнее. Управление строится на понимании, а не на надзоре. Доверять эксперту и держать над ним армию контролеров — разные вещи. Хороший договор дает прозрачность, а не превращает вас в надсмотрщика.
Подход не новый. В оборонном ведомстве США по похожей модели работает больше двухсот контрактов. Их результативность на 40–70% выше, чем у обычных договоров.
Как это выглядит у среднего бизнеса
Большому холдингу проще, у него есть кому писать сложные договоры с разделением рисков. Но и среднему бизнесу на 50–500 человек доступен переход на оплату за результат. И причина в том, что иностранные вендоры ушли, зарплаты в ИТ резко выросли, и при этом профессионалов все еще не хватает. Сбербанк оценивает нехватку до 2030 года примерно в миллион человек. Своя ИТ-команда нужного размера для среднего бизнеса не всегда экономически оправдана, а когда есть бюджет — найди людей на рынке соответствующих компетенций очень сложно.
В этих условиях аутсорсинг становится одним из способов обеспечить функционирование ИТ-инфраструктуры. Надежность не купишь почасовой оплатой. Ее покупают через ответственность за результат. На практике это выглядит так:
в договоре прописана доступность критичных систем и финансовая ответственность подрядчика за простой, а не только за реакцию на заявку;
успех описан несколькими понятными показателями, а не толстым регламентом;
подрядчик имеет право предлагать решения, которые уменьшают число инцидентов, и зарабатывает на этом, а не теряет.
Дело не в модели, а в зрелости обеих сторон
Пока что картина выходит слишком черно-белой. Почасовая оплата сама по себе не делает подрядчика заинтересованным в ваших сбоях. «Ловушка активности» срабатывает только там, где в договоре нет финансовой ответственности за результат. Уберите эту ответственность — и любая модель скатится в погоню за лишними заявками; впишите ее — и почасовая оплата перестанет работать против вас.
Поэтому выбирать стоит не «плохую» и «хорошую» модель, а смотреть на две ее характеристики сразу.
Зрелость заказчика. Готовы ли вы управлять подрядчиком через метрики: договориться о показателях, смотреть на доступность и время восстановления, держать SLA под контролем, а не считать закрытые заявки. Без такого управления даже модель на результат превращается в формальность.
Зрелость подрядчика. Выстроены ли у него процессы: ITIL, управление проблемами (а не только решение инцидентов), финансовая ответственность и гарантии в договоре. Если это есть, повременная модель со SLA дает клиенту тот же результат, что и оплата за результат, — зрелый подрядчик и так сводит число сбоев к минимуму, потому что отвечает за доступность рублем.
Иными словами, дело не в том, почасовая оплата или за результат, а в том, прописана ли в договоре ответственность за итог и хватает ли обеим сторонам зрелости эту ответственность держать.
Когда оплата за результат не нужна
Модель «на результат» подходит не для всего. Витасек предлагает делить ИТ-функции по двум осям — ценность для бизнеса и собственная экспертиза.
То, что составляет ядро вашего бизнеса, и где вы сильны сами, наружу не отдают вовсе. Простые бизнес-процессы, которые не создают ценности и мало влияют на надежность инфраструктуры, спокойно отдают на обычный почасовой аутсорсинг. Городить вокруг них модель результата незачем. А вот где функция важна, но своей экспертизы не хватает (резервное копирование, информационная безопасность, непрерывность инфраструктуры), оплата за результат работает лучше всего. Что именно и как делить — тема отдельного разговора.
Что показывает практика
Разница между «платим за активность» и «платим за результат» видна на типовых ситуациях.
Дистрибьютор платил подрядчику за закрытые заявки. 1С подвисала почти каждую неделю, инженер исправно перезапускал ее: час работы, заявка в счет. Искать причину было невыгодно, ведь меньше сбоев означало меньше оплаченных часов. Тогда в договор внесли метрику доступности 1С в рабочее время. У подрядчика появилась мотивация решить проблему. А причиной оказался сервер 2016 года, не тянувший выросшую базу. Сервер заменили, подвисания прекратились. Заказчик перестал терять часы на закрытии месяца, от подрядчика отказались, ведь проблемы не стало. Но в один прекрасный момент 1С легла так, что мало не показалось. Подрядчика вернули, поняли важность наличия сопровождения и почему нужно платить когда все работает.
Другая ситуация. Розничная сеть платила за выезды: чем чаще ломается касса или сеть в магазине, тем больше счет за обслуживание. Перешли на оплату за непрерывность работы точек. Подрядчик сам поставил мониторинг и организовал планово-предупредительное обслуживание, потому что теперь простой кассы бил по его вознаграждению, а не приносил выручку. Сбоев на кассах стало заметно меньше. В плюсе обе стороны.
И на последок негативный пример. Производственная компания перешла на минимальное обслуживание подешевле, по классической транзакционной модели «починим, когда сломается». При переезде уронили старый сервер, резервные копии лежали на том же массиве, что и боевые данные. Восстановление заняло четверо суток. Дешевый подрядчик честно отработал свои деньги. Он и не обещал, что сервер не упадет, он получал оплату за активность, а не за результат.
По какой модели работает ваш подрядчик
Чтобы понять, в какой модели вы живете, не нужен аудит. Достаточно честно ответить на три вопроса.
За что я плачу: за закрытые заявки и часы или за то, что бизнес работает без простоев? Если за первое, у подрядчика нет причины уменьшать число сбоев.
Выгодно ли подрядчику, чтобы у меня стало меньше инцидентов? Если его выручка падает вместе с числом обращений, то он не союзник в обеспечении надежности, как бы хорошо ни работал.
Кто отвечает за простой критичной системы рублем? Если в договоре есть реакция на заявку, но нет ответственности за результат, риск простоя по-прежнему целиком на вас.
Аутсорсинг не обязан быть игрой, где подрядчик выигрывает за ваш счет. Когда обе стороны зарабатывают на одном и том же, а конкретно на том, что у вас все работает, это перестает быть торгом за часы и становится партнерством, направленным на результат.
Материал подготовил Авдей Мартынович, руководитель направления среднего и малого бизнеса ALP ITSM. Больше разборов про ИТ-аутсорсинг и инфраструктуру — в блоге ALP ITSM на Хабре и в нашем Telegram-канале.
Как найти надежного ИТ-партнера
Как найти надежного ИТ-партнера, который уже живет по этим принципам? Выбор подрядчика — это не просто сравнение цен. Это выбор союзника, который разделит ответственность за результат. Мы подготовили чек-лист с рекомендациями по выбору ИТ-аутсорсера, чтобы вы могли избежать ошибок на старте.
📌 Забрать рекомендации по выбору подрядчика в нашем Telegram-канале. Без заполнения форм, ПД и других сложностей.
