Свои дорогие, весьма дорогие айтишники

«Женить» интернет-магазины и службы доставки пытались и пытаются многие, но получается не у всех: ApiShip, CheckOut, Delivia справляются, а вот, например, Dinvio не смогла. С руководителями первых двух – Денисом Иванниковым и Германом Ивкиным «Логирусу» еще предстоит встретиться и поговорить, а с Андреем Крыловичем, операционным директором Delivia – уже, прошу убедиться, удалось.

Андрей Крылович развивает Delivia около года, а до этого занимался преимущественно крупными проектами: операционным аудитом деятельности предприятий, анализом эффективности бизнес-процессов и внедрению комплексных информационных систем, возглавлял системный интегратор TOPS Business Integrator, занимал должность вице-президента венчурного фонда Ru-net Holdings. И вдруг стартап. С чего бы?

Почему вы решили перейти в проект, который находился в стадии разработки? Вроде бы масштаб-то не ваш.
– Последние шесть лет я посвятил работе в области интернет-бизнеса, использования и продвижения облачных сервисов в области CRM и логистики, мне близок рынок e-commerce своей динамичностью. Когда мне предложили заняться Delivia, основным аргументом в пользу проекта было то, что мне интересна сама идея, я очень в нее верю.

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

Ко всем пришло это понимание?
– А это не всем и надо. Потребность в подобных решениях зависит от размеров и особенностей бизнеса: если интернет-магазин обрабатывает до 100 отправлений в месяц, и основные объемы складываются из заказов по Москве, вполне рабочая схема – собственные курьеры и одна служба доставки под регионы. Но большая часть онлайн-ритейлеров пользуются услугами нескольких подрядчиков. Причин много: распределение рисков, несколько способов доставки – через курьеров, пункты самовывоза или почтоматы, максимальное географическое покрытие, более выгодные тарифы при решение различных задач.

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

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



Неужели так сложно интегрироваться «своими руками»?
– Тут самая частая проблема – готовые, но не проработанные интеграции с подрядчиками.

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

Ну, хорошо: что можно легко решить своими силами, а что – нет?
– С точки зрения технической реализации, каждая интеграция – это новая отдельная задача для ИТ, потому что API сильно отличаются: все имеют свои характерные черты, передаваемые данные сильно разнятся. Например, система статусов СПСР состоит из 146 статусов, многие из которых дублируют друг друга. У DPD 12 основных статусов, но есть 64 дополнительных значения, которые их уточняют. При этом статусы прямого и обратного движения совпадают. Почта России передает недокументированные статусы, а в IML конечные статусы не являются конечными – возможны их многократные повторения.

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




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

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

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

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

Посчитаем прямо сейчас?
Давайте: например, стоимость месяца работы разработчика, осуществляющего интеграции и занимающегося поддержкой API - 100 000 руб./месяц, а со всеми налогами и затратами на офис – 153–155 тысяч. Выходит, при объемах отправлений 10 000 в месяц стоимость поддержки обходится 15 руб./посылка.

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

И даже если вы останавливаете выбор на том, чтобы делать все своими силами, все равно стоит продиагностировать unit economics. В идеале динамика сокращения расходов на логистическую эко-систему должна выглядеть так: переменные затраты на заказ – стоимость работы службы доставки – не изменяются с ростом количества отправлений или незначительно снижаются, а внутренние постоянные затраты – работа ИТ, менеджеров по работе со службами доставки, склад, бухгалтерия – должны снижаться с ростом количества отправлений.




Что надо сделать, чтобы снизить расходы?
– Логистическая эко-система в интернет-магазинах – это все, кто так или иначе задействован в процессе организации доставки: это и сотрудники колл-центра, которые подтверждают заказы по телефону и потом отвечают на вопросы «Где заказ?», это менеджеры, которые занимаются подготовкой товаров к отгрузке, отслеживанием отправлений и трудоемкой подготовкой отчетов по доставке.

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



Ситуация на рынке сейчас за самостоятельность или за аутсорсинг?
– Внешние предпосылки говорят о росте востребованности аутсорсинга: на текущий момент 80% отправлений приходятся на 8 крупных игроков, остальные 20% рынка распределены между региональными и локальными службами доставки, работать с которыми будет существенно проще в рамках единого инструмента. LR