Как ИТ-отдел превратил маленький магазин запчастей в агрегатор и сделал его лидером рынка

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

Отмотаем время на четыре года назад. Мы с семьёй как раз вернулись с отдыха на Кипре, а через два дня пришла «радостная» новость о том, что нашу команду сокращают. Конечно, это немного выбило меня из колеи, но через неделю я устроился на новую работу. Это был стартап по туризму market.travel.

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

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

В то время магазин состоял из склада и двух отделов — закупки и продаж. У них был сайт (коробочное решение на «Битриксе») и самописная программа на Delphi.

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

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

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

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

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

Если бы мы сразу разрабатывали highload-систему, то мы бы уже точно там не работали (участники стартапов меня поймут). За три месяца мы написали ядро системы и главную функциональность. На процесс переноса данных ушло две–три недели. Как раз перед этим мы удачно дополнили команду хорошим тестировщиком, нам тогда это очень помогло. Ещё месяц мы потратили на исправление багов и мелкие доработки.

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

Случалось, что мы продавали одну деталь несколько раз из-за неактуальности базы. Конечно, недовольные клиенты после такого уходили навсегда. Также у нас были несовершенные каталоги. То есть приложение требовало серьёзной доработки бизнес-процессов. На этом этапе мы смогли повысить эффективность сотрудников, но в целом до хорошего продукта было как до луны.

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

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

Это было «весёлое» время, мы пытались не превратить проект в свалку, а бизнес требовал постоянного расширения функциональности. Доходило до криков и ругани на совещаниях. В результате мы переключались с задачи на задачу, их приоритет постоянно менялся. Обстановка была накалена до предела. Попытки внедрить Agile разбивались о непонимание.

Как это ни печально, но такое положение вещей обычно для бизнеса в России.

В то время запчасти закупались у страховых компаний (покупались с машин, пострадавших в ДТП). Все детали вносились в сервис вручную, а с учётом того, что каталоги запчастей были откровенно кривые, время этой обработки было катастрофически велико — несмотря на целый отдел из 12 человек.

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

Так мы получили уже что-то вменяемое. На внедрение новых каталогов ушёл месяц. Затем мы переработали процесс ввода запчастей в систему. Уже благодаря этим маленьким вещам, стали справляться 7 человек вместо 12, остальные занялись более важной работой.

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

Кроме того, были сложности, связанные с тем, что покупали мы у страховщиков, а забирали детали на станциях технического обслуживания (СТО). Принадлежали они первым, а физически находились у вторых, где разбирали битые машины. В итоге часто нам отдавали совершенно другие запчасти. Этот процесс был очень тяжёлым, так как все участники хотели заработать.

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

В сфере продаж новых запчастей есть популярный сервис Tecdoc, созданный в 1994 году. В нём есть VIN-номера автомобилей, номера оригинальных запчастей и аналогов и отличная кроссировка (сопоставление номеров аналогичных деталей).

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

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

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

Проблема с каталогами никуда не делась, пришлось все позиции сопоставлять вручную в таблицах Exсel. Невероятно выручил глава отдела снабжения, который проделал титаническую работу. Этот этап вместе с тестированием и баг-фиксом занял полтора месяца, а ведь это было подключение только первого партнёра. Рассчитывали на две недели...

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

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

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

Это сократило время подключения партнёра до одной недели. Уже можно было как-то жить. В то время мы подключали по два партнёра в месяц.

На следующем шаге хотелось повысить посещаемость сайта и увеличить количество лидов. Тогда у нас были запущены кампании в «Яндекс.Директе», а также мы выкладывали детали «Авито», причём вручную.

Как раз в тот момент «Авито» выкатили новую функциональность загрузки XML-файлов. Мы реализовали простые выгрузки, которые обновлялись раз в сутки, и скармливали их «Авито». Мы за один день загрузили весь свой ассортимент, а потом он постоянно обновлялся.

Целевой аудитории стало больше, но на сайт по-прежнему было больно смотреть. Он оставался на «Битриксе» и включал в себя крайне неудобный стандартный модуль по подбору запчастей. Количество отказов было высоким. Посетителям, которые умудрялись дойти до конца и оформить онлайн-заказ, впору было ставить памятники.

Следующим этапом стала полная переработка сайта. Требования обозначили следующие:

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

Клиентскую часть написали на React и Node.js. А потом мы полтора месяца убили на доработку юзабилити сайта. Но оно того стоило, сайт прыгнул на два уровня вверх по качеству. Было приятно наблюдать, как люди по нему ходили и что-то искали, а главное — делали заказы.

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

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

Назрела ситуация, когда нужно было что-то менять: старые подходы, которые работали с маленькой командой, потеряли эффективность. У разработчиков появилось непонимание многих задач, не все были погружены в процесс. Я пробовал внедрять разные методологии разработки. Лучше всего у нас прижился Kanban, и мы стали использовать Trello.

Ещё одним правильным решением был полный отказ от сомнительных и непонятных задач в духе «сделайте как-нибудь». Мы использовали следующий подход: решали задачу на скорую руку и сразу выводили в продакшн (тратили не на неё не три дня, а пару часов).

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

Мы стали проводить стендапы, каждый член команды начал понимать, что он делает и зачем. Потом мы внедрили приёмы из других методологий, со временем сформировали принципы, удобные команде: стали делить процесс разработки на спринты, проводить ретроспективы, создали backlog для задач.

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

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

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

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

На первых порах всё работало неплохо, но с ростом бизнеса и увеличением штата информация терялась между людьми, из-за этого клиенты уходили. Сотрудникам было неудобно переключаться между нашим сервисом и amoCRM. К тому времени компания открыла несколько точек продаж. По каждому мелкому вопросу менеджеру приходилось звонить на склад для уточнения нюансов по деталям.

Мы решили сделать свою мини-CRM внутри сервиса, чтобы можно было раздавать задачи в онлайне. При проектировании сложнее всего было вникнуть в процессы, потому что никто до конца не понимал, как правильно и удобно. Пришлось поработать «в поле»: мы ездили в отдел продаж и на склад, вникали в логистику и погружались в процесс продаж. Через муки мы в итоге смогли сформулировать адекватное ТЗ.

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

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

В дальнейшем таким образом были автоматизированы все бизнес-процессы. Аналитика показала, что это сократило время обработки клиента в четыре раза!

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

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

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

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

Но с другой, было довольно тяжело, потому что автобизнес формировался в 90-е годы и с тех пор далеко не ушёл. Людям приходилось объяснять, почему наше решение может им помочь. Я сам общался с представителями мелкого бизнеса, и оказалось, что есть две проблемы. Они либо не понимают, что это может им дать, либо хотят сначала увидеть результат.

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

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

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

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

Первым делом мы решили автоматизировать сопоставление номеров деталей-аналогов, так как это всё ещё делалось вручную. Экспериментировали с Elasticsearch, кое-что получалось, но результат был далёк от идеала. Подключили сторонний сервис Detectum и совместно разработали систему автоматического сопоставления.

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

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

Затем нам пришлось переделать механизм загрузки запчастей, некоторые части функциональности переписали с PHP на Golang. В результате мы получили детальный разбор ошибок, и смогли быстро находить несоответствия в загрузках баз деталей, а раньше приходилось искать руками.

Также выросла сама скорость загрузки больших файлов с 30 до 5–8 минут. Проблемы остались только с фотографиями, они могли грузиться до двух недель, но тут мы упирались в ресурсы партнёров.

Все эти меры дали потрясающий результат: подключение каталогов партнёров сократилось до одного дня! Проблему с разными форматами данных решили с помощью отдельного сервиса, написанного на Node.js. Он умел преобразовывать практически любые файлы в нужный нам формат. Это избавило нас от навязывания дополнительных условий при подключении других компаний.

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

Взяв за основу собственные каталоги, Tecdoc и нашу самообучающуюся систему, мы написали небольшой сервис, который мог определять запчасть по оригинальному номеру и прикреплять к ней автомобили, с которыми она совместима. Этим мы уменьшили время ввода запчасти в систему и сократили число ошибок. Эффективность была не идеальной, но в 60–70% случаев это срабатывало.

Вместе с ассортиментом росли и бюджеты на рекламу. И использовались они далеко не всегда рационально. Коллега из отдела продаж как-то обмолвился о внедрении новых механизмов на «Авито» и предложил их подключить хотя бы для тестов.

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

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

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

Ещё нам удалось поработать с порталом Auto.ru, у них есть раздел запасных частей. Но далеко не все могли там размещаться из-за баз плохого качества. У нас же с ними получилось отлично работать, а тех клиентов, у кого были проблемы, Auto.ru направляли к нам.

Дальше мы взялись за механизм продаж. Там было не всё гладко, из-за отсутствия истории каждого клиента и несовершенного механизма распределения звонков (один и тот же звонок мог приходить к разным менеджерам). Решили делать полноценную CRM с историей клиентов и оценкой работы менеджеров.

Сложности начались уже с ТЗ, мы накидали ту часть, которую понимали, а чтобы написать остальную… сели продавать вместе с менеджерами. Так мы увидели все проблемы на практике.

Кроме того, это подтолкнуло нас к новым экспериментам. Например, мы пробовали открывать колл-центр, но потом отказались от него. Ещё мы осознали, что в существующем на тот момент решении не хватало гибкости. Благодаря такому опыту мы смогли составить ТЗ, учитывающее все потребности менеджеров.

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

Что касается телефонии, то сначала мы попробовали писать свою с нуля, но потом вышли на проект AQ.Telephone. Мы оказались первым крупным клиентом у ребят и здорово совместно поработали над той функциональностью, которая была нам необходим.

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

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

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

P.S.

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