Недавно мы опубликовали статью о прямом обмене с системой «Честный ЗНАК», в которой рассказали о способах интеграции с государственной системой маркировки. Один из комментариев к статье невольно поднял дискуссионный вопрос: стоит ли выводить часть IT-инфраструктуры на аутсорс или выгоднее развивать внутреннюю разработку?

Комментарий читателя такой:

Звучит как ‘перестаньте кормить своих программистов, лучше давайте кормить наших программистов Клеверенса’. Плавали, знаем. Убогая попытка вывести часть it-инфраструктуры на аутсорс, которая обычно заканчивается жесткими простоями в торговле.

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

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

Откуда берется недоверие к аутсорсингу?

Первое, что мы c коллегами обсудили — почему возникает такое негативное отношение к аутсорсингу разработки. Один из IT-директоров высказал интересную мысль:

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

Эта мысль очень точно отражает ситуацию: речь идет не столько о «выдавливании» внутренних разработчиков, сколько о рациональном распределении ресурсов компании.

Что говорит практический опыт?

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

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

и отметил, что их компания прошла все этапы:

1. Сначала пытались писать решения самостоятельно

2. Затем искали готовые платформы с возможностью доработки

3. В итоге пришли к использованию готовых профессиональных решений с необходимыми настройками

И это не вынужденный компромисс, а осознанное решение, основанное на экономической эффективности.

Миф о контроле

Одним из главных аргументов противников аутсорсинга является «потеря контроля» над разработкой. Однако опыт опрошенных компаний говорит об обратном:

«Мы ошибаемся, если пытаемся сами использовать прямую разработку. У меня был опыт найма программиста напрямую. Транслировать ему задачу приводит к бесконечным ошибкам, потому что я не до конца понимаю, как там всё устроено, да? И не должен понимать. И он не до конца понимает, как устроена у нас система или наши процессы. Соответственно, это ведёт к ошибкам, удлиняется разработка.»

Когда же компания работает с хорошим подрядчиком на аутсорсе, хорошо разбирающемся в предметной области:

«У нас есть менеджер, с которым мы взаимодействуем. Он переводит наши требования на свой язык для разработчика. Мы с ним обсуждаем именно задачу как бизнес-процесс, а не конкретные строчки кода. Менеджер, если мы разговариваем с ним на одном языке, всегда может сказать: ‘Стойте, ребята, подождите. Это можно сделать по-другому. Вы добьетесь того же результата, сделав чуть-чуть по-другому’.»

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

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

Специфика разработки мобильного ПО для ТСД: «не просто код»

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

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

Этот момент часто недооценивается при запуске внутренней разработки. Один из опрошенных нами IT-директоров рассказал о собственном опыте:

Мы столкнулись с тем, что терминал не видел сканирующую голову. Пытались что-то сделать, писали самостоятельно. Нам начали долго отвечать на запросы… И в этот момент я четко понял, что следующего шанса не будет. Я чувствую, что не идет процесс.

Для решения подобных задач компаниям требуются особые специалисты — разработчики, которые одновременно глубоко понимают железо (ТСД):

«У некоторых терминалов мы с трудом вообще заставляем работать сканер— нет у “китайцев” понятного и правильного SDK, не говоря уже о наличии описания API. Сразу вопрос: И кто у меня в IT-отделе сможет написать драйвер под сканер устройства? Это значит звонить китайцам на завод и спрашивать, как работает их SDK. С той стороны линии ответы несложные, но и непонятные: “ну попробуйте вот так, попробуйте вот так…” Это не просто ‘сел по инструкции сделал’, нет.»

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

У компаний, профессионально занимающихся разработкой ПО для ТСД, есть несомненное преимущество:

Например в Клеверенсе  для этого есть целый склад, где лежит каждая модель терминала, которая в России более-менее распространена. Там есть образец, на котором мы, собственно, разрабатываем и гарантируем его правильную работу. Там даже модели 90-х годов лежат до сих пор.

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

Наглядная аналогия: продуктовый магазин vs производитель

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

«Можно сколько угодно критиковать магазины, что у них всё дороже, чем на агрокомплексе. Да, можешь поехать за пятьсот километров на агрокомплекс и купить там очень дешево. Но если ты приобретешь там килограмм помидоров — это будет бессмысленная поездка. Это будут очень дорогие помидоры, если учесть потраченный день, бензин и усилия.

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

Эта аналогия прекрасно объясняет ситуацию с IT-решениями:

«Когда компания занимается своей основной деятельностью — торговлей, производством — у неё хорошо работают расчеты маржинальности, она видит, где создает ценность для клиента. Но когда та же самая торговая компания начинает писать софт для себя или строить здания для своего магазина — она становится как слепой котёнок, потому что там она не видит конкуренции, не применяет у себе чётких метрик эффективности по софту или стройке, какие она применяет в своей основной деятельности по торговле, и часто работает “лишь бы сделать, не важно какой ценой”. Они уже не видят, что платят в 3-4 раза дороже, чем могли бы, потому что у них даже не заточены расчёты под это.

IT в таких компаниях существует только до тех пор, пока основной бизнес нормально генерирует прибыль. Как только он перестаёт это делать, выясняется, что IT деньги не зарабатывал, а только тратил их.»

Эта мысль перекликается с опытом многих компаний: разработка непрофильных IT-решений часто оказывается намного дороже, чем кажется изначально.

Экономическая эффективность: реальные цифры

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

«Мы подсчитывали недавно… для склада в тысячу квадратных метров нам бы потребовалось около 17-18 кладовщиков, если работать без специализированных настроек системы. Сейчас наш склад вырос до нескольких километров, но количество кладовщиков не увеличивается. Они справляются.»

При этом в компании не увольняли сотрудников IT-отдела — просто перенаправили их усилия на задачи, которые действительно критически важны для бизнеса:

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

Что делать при выборе подхода к разработке?

На основе обсуждения с экспертами и IT-директорами компаний, можно сформулировать несколько рекомендаций для компаний, которые задумываются о выборе между внутренней разработкой и аутсорсингом:

1. Определите минимально работающий продукт. Надо определить минимум автоматизации — самый минимально работающий предел цели. Первый шаг был просто, чтобы деталь сканировалась, попадала в какой-то документ. Больше ничего.

2. Проанализируйте рынок готовых решений. Часто люди тратят огромные ресурсы на разработку того, что уже существует в виде готового продукта: «Начали с аутсорсинговой компании, а через какое-то время выяснилось, что подобное решение есть готовое, его надо было просто на нас накинуть, и оно заработало сразу.»

3. Оцените реальную стоимость владения. Не только прямые затраты на разработку, но и стоимость поддержки, масштабирования, риски сбоев: «Любое внедрение дороже стоимости любого решения. Сколько стоит 1С ERP на тысячи пользователей? 5 миллионов. А сколько стоит его внедрение? 45? Может 100 миллионов даже.»

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

Важный момент, который подчеркивают эксперты Клеверенс — не существует универсального правильного ответа:

«Мы не агитируем отказаться от своей разработки и купить готовое решение. Это всегда будет баланс. Стоимость остановки бизнеса на 6 часов может составлять миллионы рублей недополученной прибыли. Поэтому всегда будет эта проблема: хочется, чтобы система работала быстрее и стоила меньше, но риски падения дешевой и быстрой системы должны быть минимальны.»

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

Однозначного вывода не существует, сделайте его сами

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

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

Как метко заметил один из IT-директоров: «Для бизнеса это всё — денежка, денежка, денежка. Тут меньше заплатили, тут быстрее сработали, тут людей меньше надо, производительность увеличилась.»

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

А как вы решаете вопрос выбора между собственной разработкой и готовыми решениями? Поделитесь своим опытом в комментариях.