5 ошибок при переходе на IT-аутсорсинг

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

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

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

Экономия как единственный критерий выбора

Компании сравнивают предложения подрядчиков по одной цифре — стоимости в месяц. Логика понятная: раз задачи вроде одинаковые, зачем платить больше.

За разницей в цене почти всегда стоит разница в объеме реальной работы. Один подрядчик держит инженера на телефоне и реагирует за час, другой берет заявки через тикет-систему и отвечает на следующий день. Формально оба называются «IT-аутсорсинг».

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

Передача дел, которой не было

Штатного администратора увольняют, аутсорсер подключается — и по документам все выглядит гладко. На практике знания о том, как устроена инфраструктура компании, часто существуют только в голове уходящего сотрудника.

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

Разрыв между «старый специалист еще не ушел» и «новый уже разобрался» — самое уязвимое место всего перехода. Именно в эту паузу чаще всего и происходят сбои, которые потом приписывают некомпетентности нового подрядчика.

Договоренности на словах вместо зафиксированных правил

Собственник и подрядчик на словах обсуждают, что тот будет делать. Кажется, что этого достаточно — стороны вроде бы поняли друг друга.

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

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

Выбор подрядчика по знакомству, а не по процессу

«Нам порекомендовали толкового парня» — вполне рабочий способ найти хорошего специалиста. Проблема начинается, когда за этой рекомендацией не стоит проверка того, как вообще устроена работа подрядчика.

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

Хороший подход к IT-аутсорсингу строится на процессах, которые не зависят от одного конкретного специалиста — примерно так это описано на странице https://itspectr.ru/it-outsorsing/. Без этого компания просто меняет одну точку зависимости на другую, только теперь чуть менее заметную.

Ожидание, что аутсорсинг сам наведет порядок

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

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

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

Что это значит для собственника

За всеми пятью ошибками стоит одна и та же логика: переход на аутсорсинг воспринимают как техническое переключение — было плохо, стало хорошо, — а не как процесс, которым нужно управлять.

IT нельзя ставить на паузу на время перехода. Бизнес продолжает работать, пока меняется схема поддержки, и любой провал в этот период бьет по текущим процессам, а не по абстрактному будущему.

Система, построенная на регламентах и зафиксированных договоренностях, всегда устойчивее договоренности на доверии — даже если на словах доверие звучит спокойнее.