Куда движется рынок ИТ-решений в транспорте и логистике — Пять проблем и их решений11.02.2016 23:38

1. Агрегаторы агрегаторов

Проблема

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

Затем появляются технологии, а следом ― агрегаторы поставщиков. На них собираются потребители и поставщики.

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

Решение

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

2. Динамическая сборка продукта

Проблема

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

Но представим: есть продукт, который формируется через рабочий процесс из пяти стадий. Доставка из точки A в точку B ― это первая миля, сортировка, магистраль, сортировка, последняя миля. Представить себе интеграцию сразу пяти компаний-провайдеров (для каждой стадии) сложно.

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

Решение

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

Совету директоров Tesсo (вторая по величине компания-ритейлер в мире) была продана такая история. Вы дома, хотите заказать продукты из супермаркета Tesсo. Заходите в приложение, выбираете своего любимого шопера. Он едет в супермаркет на автобусе и покупает продукты. Выходит из магазина и понимает, что ему тяжело ехать на автобусе. Заходит в приложение и видит ― на стоянке напротив магазина стоит машина сотрудника Tesсo, которую он сдает в каршеринг (краткосрочную аренду) на время своей работы в магазине, а сам работает еще 3 часа.

Шопер берет машину, привозит на ней продукты для вас. Так как машину нужно возвращать, он снова заходит в приложение, становится водителем Uber и Gett и выбирает заказ на поездку с конечным пунктом в районе магазина Tesсo, куда надо вернуть машину. Это достаточно простой сценарий, однако для его реализации недостаточно одноранговой интеграции двух сервисов.

Раньше у вас было четкое понимание, что есть потребители, провайдеры и цепочки между ними. Сейчас есть множество всех, и каждый в один момент времени окажется потребителем, в другой ― провайдером. Это может происходить с помощью «шины», которая позволяет разным сервисам (покупки продуктов, каршеринга, такси) и их потребителям обмениваться данными.

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

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

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

3. Открытые системы вместо закрытых

Проблема

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

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

Решение

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

4. Краудсорсинг

Проблема

У краудсорсинга плохой имидж: все думают, что штатные сотрудники дадут общее качество сервиса на порядок выше. В определенный момент в Bringo было достаточно много штатных курьеров. Мы ввели понятие «негативная нотификация» ― когда что-то в процессе доставки пошло не так, и мы не уложились в SLA.

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

Решение

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

5. Совместное использование (пулинг) ресурсов

Проблема

Чтобы оставаться в прибыли, показатель утилизации инфраструктурных ресурсов у компаний должен быть не менее 85–90%. Если грузовики логистической компании едут наполовину пустыми, доставка обходится компании в убыток.

Например, в Германии в один ТЦ привозят товар несколько служб доставки: у одного магазина контракт с DHL, у другого с DPD. Если у каждой из этих компаний не набирается товара в эту точку на целый грузовик, для них это не выгодно.

Решение

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

Это решение уже много лет используется в судоходстве: часто контейнер, которым владеет компания, А, стоит на судне компании B, при этом перевозку осуществляет компания C. Судоходная индустрия более затратная, нежели курьерская служба, незаполненные грузами судна обычно приносят колоссальные убытки.

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

Для пулинга ресурсов нужна система или оператор пула, который является независимым и берет деньги только за управление процессом (передачу информации между участниками пула). Запрос на пулинг ресурсов сейчас актуален как никогда: объемы падают, у всех есть лишняя инфраструктура, а что с ней делать, никто не знает. Так что оператор/платформа для оперирования пулом ― очень нужная история.