Пять проблем и их решения На утреннем мероприятии Ранние пташки от ФРИИ и #цех Александр Доманицкий, специалист по антикризисному управлению в сфере ритейла, IT и логистики, поделился своим видением развития логистического рынка.
Контент выступления подготовила для vc.ru контент-маркетолог акселератора ФРИИ Мария Любимцева.
1. Агрегаторы агрегаторов
Проблема
Во многих отраслях, в том числе в логистике, рынок прошел несколько стадий развития.Поначалу потребители искали поставщиков услуг (и наоборот) самостоятельно.
Затем появляются технологии, а за ними — агрегаторы поставщиков.
Они объединяют потребителей и поставщиков.
Правда, это не обеспечивает доступ ко всем участникам рынка, хотя потребители и поставщики разных агрегаторов могут пересекаться.
Например, одна часть драйверов работает только для Яндекса.
Такси», другой — только в Uber, а третий — и туда, и туда.
То же самое и с потребителями: у одних два приложения-агрегатора, у других одно.
Данная модель не решает проблему выбора наиболее оптимального поставщика.
Решение
Следующий этап – появление агрегаторов агрегаторов.Это уже произошло в сфере продажи авиабилетов.
Но даже супермегаагрегатор не может охватить весь рынок: каким бы большим ни был такой игрок, всегда найдется причина, по которой некоторые игроки рынка не захотят с ним работать.
2. Динамическая сборка продукта
Проблема
ИТ-сервисы в логистике уже научились интегрировать.Интернет-магазины могут включать шлюзы оплаты и доставки.
Когда для создания конечного продукта требуется интеграция двух сервисов, это происходит быстро и легко.
Многие уже имеют паблик API .
Но давайте представим: есть продукт, который формируется в ходе рабочего процесса из пяти этапов.
Доставка из пункта А в пункт Б – первая миля, сортировка, шоссе, сортировка, последняя миля.
Трудно представить интеграцию сразу пяти компаний-провайдеров (по каждому этапу).
И если мы хотим иметь хотя бы двух провайдеров на каждом этапе, нас ждет бесконечное количество интеграций.
При этом на каждом этапе необходимо иметь достаточное количество провайдеров, чтобы конкуренция между ними могла сформировать оптимальное предложение для клиента.
Скорее всего, провайдеры, как и таксисты, будут динамически решать, хотят ли они участвовать в «борьбе» за тот или иной заказ.
Решение
В результате наш динамический продукт в любой момент времени будет состоять из нескольких разных (в зависимости от выбранного провайдера) компонентов.Пока не существует системы, которая решит эту проблему, не интегрируя всех со всеми.
Совету директоров Tesco (второго по величине ритейлера в мире) понравилась такая история.
Вы находитесь дома и хотите заказать продукты в супермаркете Tesco. Зайдите в приложение, выберите понравившийся шопер.
Он едет в супермаркет на автобусе и покупает продукты.
Он выходит из магазина и понимает, что ему трудно ехать на автобусе.
Он заходит в приложение и видит, что на стоянке напротив магазина стоит машина сотрудника Tesco, которую он сдает в каршеринг (краткосрочную аренду) на время своей работы в магазине, пока он работает у другого.
3 часа.
Покупатель берет машину и привозит для вас продукты.
Поскольку машину нужно вернуть, он снова заходит в приложение, становится водителем Uber и Gett и выбирает заказ на поездку с конечным пунктом в районе магазина Tesco, куда ему нужно вернуть машину.
Это достаточно простой сценарий, но для его реализации недостаточно одноранговой интеграции двух сервисов.
Раньше у вас было четкое понимание, что между ними есть потребители, поставщики и цепочки.
Теперь всех стало много, и каждый окажется в один момент времени потребителем, а в другой — поставщиком.
Это может произойти с помощью «автобуса», который позволяет различным сервисам (магазинам продуктов, совместному использованию автомобилей, такси) и их потребителям обмениваться данными.
Есть несколько примеров отраслей, в которых конечный продукт теперь можно собирать динамически.
Например, туризм (билеты, отели, трансферы, экскурсии и т.д.), строительство (от проектирования до отделки).
В этих областях пользователь может на лету собрать уникальный пакет, отвечающий его потребностям.
Это возможно не только благодаря большому количеству поставщиков, но и правильной передаче информации между ними.
Система, способная этим управлять, должна решить три задачи: обеспечить качество предоставляемых услуг, быть центром расчетов всех участников со всеми и обеспечить достаточное количество поставщиков.
3. Открытые системы вместо закрытых
Проблема
Закрытая система построена так: мы сами выбираем наиболее оптимальных и качественных поставщиков и на их основе собираем конечный продукт. Тот момент, когда вы только что собрали закрытую систему от лучших поставщиков, является оптимальным.Но через какое-то время что-то на рынке изменится, и поставщики могут не адаптироваться.
Мы их утверждаем один раз, а потом мы их заложники.
Система перестает быть оптимальной.
Решение
Почему открытые системы выиграют? Открытая система построена по принципу: мы делаем максимально простым и легким подключение поставщиков и доступ к системе, а кто выиграет, решает слепая рука рынка.Общий уровень системы в открытой среде и конкуренции всегда на порядок выше.
4. Краудсорсинг
Проблема
У краудсорсинга плохой имидж: все думают, что штатные сотрудники обеспечат на порядок более высокое общее качество обслуживания.В какой-то момент у Бринго было довольно много штатных курьеров.
Мы ввели понятие «негативное уведомление» — когда в процессе доставки что-то пошло не так и мы не выполнили SLA. При штатных курьерах у нас было в два раза больше негативных уведомлений, чем при краудсорсинге, а уровень негативных уведомлений при краудсорсинге был существенно ниже самых жестких SLA крупных логистических провайдеров.
Решение
Независимые экономические агенты могут работать более эффективно, чем штатные сотрудники под принуждением или зарплатой.Вопрос в правильных механизмах: что нужно для их мотивации.
Ничего нельзя заказать краудсорсерам.
Вы можете создать для них правильные условия, и они сами будут работать в правильном направлении.
С точки зрения качества результат будет лучше.
5. Совместное использование (объединение) ресурсов
Проблема
Чтобы оставаться прибыльными, компании должны иметь коэффициент использования ресурсов инфраструктуры не ниже 85–90%.Если грузовики логистической компании ездят полупустыми, доставка обходится компании в убыток.
Например, в Германии несколько служб доставки доставляют товары в один торговый центр: у одного магазина договор с DHL, у другого с DPD. Если у каждой из этих компаний на данный момент нет целой фуры с товаром, им это невыгодно.
Решение
Компании объединяют свои грузопотоки, и в результате в торговый центр приезжает одна фура с товарами от нескольких служб доставки.Это называется объединением ресурсов.
Каждой компании выгоднее держать меньше грузовиков, которые загружены на 100%.
Объединение ресурсов в пулы увеличивает коэффициент использования или нагрузку на инфраструктуру.
Такое решение используется в судоходстве уже много лет: зачастую контейнер, принадлежащий компании А, сидит на судне компании Б, а перевозку осуществляет компания С.
Судоходная отрасль обходится дороже, чем курьерская служба, и грузы не доставляются.
наполненные грузом, обычно приводят к колоссальным потерям.
Но есть и проблема.
Когда две компании хотят совместно использовать грузовики, каждая хочет контролировать этот процесс.
Доверить часть своих процессов конкурирующей компании — значит подвергнуть себя риску: есть риск, что конкурент отберет часть ваших клиентов.
Все попытки создать пул на базе одного из участников этого пула чаще всего заканчиваются ничем.
Для пула ресурсов нужен оператор системы или пула, независимый и взимающий деньги только за управление процессом (передачу информации между участниками пула).
Запрос на объединение ресурсов сейчас актуален как никогда: объемы падают, у всех есть лишняя инфраструктура, и никто не знает, что с ней делать.
Так что оператор/платформа для эксплуатации пула — это очень нужная история.
-
Фейербах, Людвиг
19 Oct, 24 -
Что Говорили О Javascript В 1995 Году
19 Oct, 24 -
В Беларуси Назревает Революция... Ит
19 Oct, 24 -
Как «Моторика» Делает Протезирование Детям
19 Oct, 24 -
Эмулятор Javascript Commodore 64
19 Oct, 24 -
Виртуальная Реальность: Новый Интерфейс
19 Oct, 24 -
Ошибка 8 Килобайт
19 Oct, 24
