Как определить, какие бизнес-процессы вынести на аутсорсинг: критерии, риски и пошаговый алгоритм

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

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

Почему деление на «своё» и «чужее» работает не всегда

Классическое правило «core делаем сами, non-core отдаём» работает как первый фильтр, но ломается на практике по трём причинам:

• Контекст этапа бизнеса. Для стартапа разработка продукта — core, а бухгалтерия — non-core. Для зрелой SaaS-компании разработка ядра остаётся core, но DevOps и QA могут стать core, если скорость релизов — главное конкурентное преимущество.
• Экономика масштаба. Передача на аутсорсинг выгодна, когда подрядчик делает это дешевле за счёт специализации и объёмов. Если ваш объём меньше минимально эффективного порога провайдера, вы платите наценку за «хвост» его процессов.
• Риск потери неявных знаний. Даже формально рутинные процессы (например, обработка входящих заявок) могут нести контекст, который формирует качество продукта. Уход этого контекста наружу необратимо снижает качество решения.

Поэтому критерий «core/non-core» нужно дополнять количественной и качественной оценкой по набору параметров.

Пять критериев для первичного скрининга

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

1. Стандартизируемость: Есть ли чёткие входные данные, критерии результата и SLA, которые можно зафиксировать в контракте без потери качества?
2. Рыночная зрелость: Существует ли конкуренция среди провайдеров с доказанным трек-рекордом в вашей отрасли и масштабе?
3. Отсутствие стратегической уникальности: Не создаёт ли выполнение этой функции уникальные данные, процессы или компетенции, которые станут активом компании?
4. Измеримость результата: Можно ли объективно оценить качество работы подрядчика без погружения в операционку?
5. Ограниченность взаимодействий: Минимизированы ли точки соприкосновения с core-процессами, где задержка или ошибка подрядчика парализует основной бизнес?

Функции, проходящие этот фильтр: учёт и налоги, HR-администрирование (кадровый учёт, расчёт зарплат), IT-инфраструктура (хостинг, мониторинг, бэкапы), юридическое сопровождение типовых договоров, логистика и складское дело, колл-центр первой линии, маркетинговые операции (настройка рекламы, SMM-производство), контент-модерация, переводы и локализация.

Функции, которые редко проходят фильтр: продуктовая разработка (если продукт — основной актив), ключевые продажи (enterprise/B2B), стратегический маркетинг и позиционирование, R&D, управление ключевыми клиентами, архитектура безопасности и комплаенс в регулируемых отраслях.

Расчёт реальной стоимости: TCO вместо сравнения зарплат

Самая частая ошибка — сравнивать зарплату сотрудника с чеком подрядчика. Правильная база — Total Cost of Ownership (TCO) за горизонт 12–24 месяцев.

Статья расходов	In-house (в штате)	Аутсорсинг
Прямая оплата труда / чек провайдера	ФОТ + налоги + бонусы	Месячная фиксированная плата или piece-rate
Найм и адаптация	Рекрутинг, онбординг, провал испытательного срока	Время на тендер, переход, передачу контекста
Инфраструктура	Рабочее место, софт, лицензии, безопасность	Часто включено в чек, но проверяйте
Управление и контроль	Время руководителя, 1-on-1, процессы	Vendor management, отчёты, эскалации, аудиты
Риски простоя / текучести	Больничные, увольнения, передача дела	SLA-штрафы, замена менеджера на стороне провайдера
Скрытые издержки	Обучение, сертификация, переработки	Change requests, выход за scope, миграция при смене

На практике TCO аутсорсинга ниже на 15–30% для стандартизированных функций (бухгалтерия, Tier-1 поддержка) и может быть выше на 10–20% для функций с высокой вариативностью (кастомная разработка, сложный контент). Считать нужно в Excel с вашими цифрами, а не по отраслевым усреднениям.

Оценка рисков: матрица «Вероятность × Ущерб»

Каждая передаваемая функция несет специфические риски. Оцените их по шкале 1–5 по двум осям и приоритизируйте митигацию:

• Потеря экспертизы (Knowledge drain): Вероятность высока, если функция требует контекста продукта. Ущерб — стратегический. Митигация: сохранение внутреннего product owner / архитектора, документация, регулярные синки.
• Vendor lock-in: Вероятность растёт с уникальностью стека провайдера и объёмом переданных данных. Ущерб — операционный и финансовый. Митигация: открытые стандарты, права на данные, выходная стратегия в контракте.
• Деградация SLA: Вероятность средняя, ущерб зависит от критичности. Митигация: поэтапный запуск, штрафные санкции, право расторжения за системные нарушения.
• Информационная безопасность: Вероятность утечки растёт с числом людей у подрядчика, имеющих доступ к данным. Ущерб — репутационный, регуляторный. Митигация: DPA, аудит безопасности провайдера, минимизация передаваемых данных (pseudonymization).
• Культурный и коммуникационный разрыв: Вероятность высока при офшоре/неаршоре. Ущерб — скорость, качество, моральная усталость внутренней команды. Митигация: общие ритуалы, единый трекер, чёткий RACI.

Если суммарный риск по матрице превышает порог (например, >12 из 25), либо готовите план митигации с бюджетом и сроками, либо оставляете функцию in-house.

Пошаговый алгоритм принятия решения

1. Инвентаризация функций. Составьте реестр всех повторяющихся процессов с указанием: объём (часы/месяц), текущая стоимость, критичность для клиента, степень стандартизации, текущая команда.
2. Применение фильтра 5 критериев (раздел выше). Отсеките очевидные non-core.
3. Расчёт TCO для кандидатов. Соберите котировки от 3+ провайдеров, посчитайте внутренний TCO, сравните за 24 месяца с учётом инфляции зарплат и курсов валют.
4. Оценка рисков матрицей. Для каждого кандидата заполните таблицу рисков, определите меры митигации и их стоимость.
5. Пилот / Proof of Concept. Передайте ограниченный объём (один регион, одна продуктовая линия, 20% трафика) на 2–3 месяца. Измерьте: качество по SLA, скрытые затраты на управление, скорость реакции на инциденты, удовлетворённость внутренних стейкхолдеров.
6. Решение: Scale / Modify / Reject. На основе пилота — масштабируете, меняете модель (например, hybrid: контрольные точки in-house, операционка outsource) или отказываетесь.
7. Контрактуализация. Закрепите: SLA с измеримыми метриками, режим отчётности, права на IP и данные, процедуру смены ключевых сотрудников провайдера, условия выхода (transition period 30–90 дней, передача артефактов).
8. Постоянный vendor management. Ежемесячные QBR (Quarterly Business Review), ежегодный пересмотр тарифов и scope, план B на случай банкротства/ухудшения качества провайдера.

Гибридные модели: когда не всё черное или белое

Часто оптимальным оказывается не бинарный выбор, а комбинация:

• Core-контроль + операционный аутсорсинг. Внутренний архитектор / tech lead задаёт стандарты, ревьюит PR, управляет бэклогом; команда подрядчика пишет код по спекам.
• Внутренний product owner + внешняя delivery-команда. Для маркетинга: стратегия, бренд, позиционирование — внутри; производство креативов, настройка кампаний, отчётность — агентство.
• Follow-the-sun / Tiered support. L1 (скрипты, FAQ) — аутсорс 24/7; L2/L3 (экспертиза продукта) — in-house.
• Staff augmentation vs Managed services. Augmentation: вы управляете людьми провайдера как своими (гибкость, контроль). Managed services: провайдер отвечает за результат по SLA (меньше управления, больше доверия). Выбор зависит от зрелости ваших процессов управления.

Типичные ошибки и как их избежать

Ошибка	Причина	Последствие	Правильная альтернатива
Передача «как есть» без документированных процессов	Надежда, что провайдер «сам разберётся»	Долгий запуск, несовпадение ожиданий, переработки за свой счёт	Сначала опишите AS-IS, согласуйте TO-BE, зафиксируйте входы/выходы/SLA
Выбор по минимальной цене	Сравнение только чек-amount без TCO	Низкое качество, высокие скрытые затраты на управление, частая смена вендоров	Тендер с весовыми коэффициентами: цена 30%, экспертиза 30%, SLA 20%, безопасность 20%
Отсутствие внутреннего ответственного (Vendor Manager)	Экономия на FTE, «поручим HR/финансисту на досуге»	Потеря контроля, накопление проблем, сложный выход	Назначьте ответственного с KPI по качеству взаимодействия, выделите 10–20% времени
Передача функции, генерирующей уникальные данные	Неосознание ценности данных (логи поддержки, поведение пользователей)	Потеря инсайтов для продукта, зависимость от отчётов провайдера	Оставьте владение данными и аналитику внутри, передайте только операционную обработку
Контракт без exit-стратегии	Оптимизм на старте отношений	Месяцы хаоса при смене, потеря артефактов, юридические споры	Пропишите transition period, форматы передачи, права на исходники, штрафы за задержку выхода

Чек-лист готовности к передаче функции

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

• [ ] Процесс задокументирован: входы, выходы, исключения, эскалации, RACI.
• [ ] Определены измеримые KPI/SLA с базовыми линиями (текущие показатели in-house).
• [ ] Проведен тендер минимум от 3 провайдеров с одинаковым RFP.
• [ ] Посчитан TCO на 24 месяца с учётом рисков и митигации.
• [ ] Оценены риски по матрице, для критических — план митигации с бюджетом.
• [ ] Назначен внутренний Vendor Manager с зафиксированной ответственностью.
• [ ] Контракт включает: IP rights, data ownership, DPA, exit clause, change request procedure, penalty/bonus за SLA.
• [ ] Запланирован пилот 2–3 месяца с критериями успеха/провала.
• [ ] Команда информирована, обучена работе с провайдером, понимает новые процессы.
• [ ] Есть план Б: как вернуть функцию in-house или переключиться на резервного провайдера за 30 дней.

Сценарии: как действовать в типовых ситуациях

Сценарий 1: Рост нагрузки превышает найм

Ситуация: Тикетов в поддержку приходит в 3 раза больше, нанять и обучить людей за 2 недели невозможно.

Действие: Быстрый пилот с провайдером Tier-1 поддержки по готовым скриптам. Оставьте in-house L2/L3 и knowledge base management. Контракт на 6 месяцев с автопродлением, KPI — CSAT не ниже текущего, FRT < 1 час.

Сценарий 2: Необходима редкая экспертиза

Ситуация: Нужен аудит безопасности / внедрение 1С / настройка сложной аналитики. В штате нет компетенции, нанимать на полную ставку нерационально.

Действие: Проектный контракт (Time & Materials или Fixed Price с чёткими этапами). Критерий выбора — кейсы именно в вашей отрасли и стеке. Внутренний куратор — обязателен для приёмки результатов.

Сценарий 3: Оптимизация затрат в зрелой компании

Ситуация: Бухгалтерия, HR-операции, IT-хелпдеск держат штат 15 человек, затраты растут выше инфляции.

Действие: Тендер на managed services. Параллельно готовите внутренний переход: сохраняете 1–2 ключевых сотрудника как vendor managers / экспертов предметной области. Пилот по одной функции (например, расчёт зарплат), затем каскадный перенос.

Сценарий 4: Стратегическая неопределённость

Ситуация: Непонятно, станет ли новая маркетинговая активность постоянной или это тест гипотезы на 3 месяца.

Действие: Аутсорсинг идеален для тестов: гибкость, быстрый старт, нет обязательств по найму. Контракт — месяц в месяц или по спринтам. Если гипотеза подтвердилась — решаете: нанимать команду или масштабировать агентство.

Как проверить качество работы подрядчика на практике

Не ограничивайтесь отчётами провайдера. Внедрите независимые точки контроля:

• Mystery shopping / тестовые заявки — еженедельно для поддержки, ежемесячно для продаж.
• Случайный аудит артефактов — код-ревью 10% PR, проверка 5% бухпроводок, прослушивание 3% звонков.
• Опрос внутренних потребителей (NPS по работе с вендором) — раз в квартал.
• Сравнение метрик до/после на одних и тех же сегментах клиентов/продуктов.
• Участие в инцидент-ревью — обязательное присутствие вашего технического лида на разборе критических сбоев у провайдера.

Если качество падает — запускайте процедуру улучшения (CAPA) с дедлайнами, а не сразу ищите нового. Смена вендора стоит 3–6 месяцев переходного периода.

Когда аутсорсинг точно не поможет

Есть ситуации, где передача наружу усугубит проблему:

• Процесс сломан внутри: нет регламентов, все держат в голове. Подрядчик получит хаос и вернёт хаос за деньги.
• Функция требует ежедневных решений по нестандартным ситуациям, которые невозможно формализовать в SLA.
• Объём слишком мал для интереса качественных провайдеров — попадете на «хвост» низкоквалифицированных исполнителей.
• Регулятор требует персональную ответственность конкретного сотрудника компании (некоторые виды комплаенса, подпись отчётности).
• Команда в состоянии хаоса/перестройки — добавление внешней зависимости увеличит когнитивную нагрузку менеджмента.

В этих случаях сначала наведите порядок внутри (процессы, инструменты, метрики), а потом решайте про аутсорсинг.

Практический следующий шаг

Начните с инвентаризации: выгрузите из трекера/HR-системы/финансов список всех повторяющихся функций с часами и затратами. Пробежитесь по фильтру из 5 критериев. Выберите 2–3 кандидата с наибольшим потенциалом экономии или снятия боли. Для каждого соберите RFP, запустите тендер, посчитайте TCO. Не пытайтесь решить всё сразу — итеративный подход снижает риск стратегической ошибки.

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

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