Основные бизнес процессы Озон

Для начала разберемся в том, как устроены процессы, которые предстоит моделировать.

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

В сутки на Ozon 2 млн человек выбирают из 2,5 млн товаров и делают более 100 тысяч заказов. И каждый из этих заказов мы должны доставить как можно быстрее, а для этого развиваем инфраструктуру логистики — фулфилмент-фабрики, сортировочные центры, сеть пунктов выдачи заказов и постаматов.

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

Бизнес на Ozon: Что нужно знать перед началом работы?

При чем тут модели

Имитационное моделирование — метод исследования, при котором система заменяется моделью, с достаточной точностью описывающей реальную систему (построенная модель описывает процессы так, как они проходили бы в действительности), с которой проводятся эксперименты с целью получения информации об этой системе.

RB рекомендует лучших поставщиков цифровых решений для вашего бизнеса — по ссылке

Именно возможность анализировать модель в действии отличает имитационное моделирование от других методов, например, от использования Excel или линейного программирования.

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

Как строится модель

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

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

В своей работе мы использовали AnyLogic — один из самых продвинутых инструментов имитационного моделирования. Мы выбрали именно его из-за гибкости, наличия готовых отраслевых библиотек, интеграции с ГИС-картами и возможности запускать модели в облаке.

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

И как ее использовать

Теперь можно менять вводные. Например, увеличить количество посылок, которые должен обработать фулфилмент (в реальности такой эксперимент провести сложно и рискованно).

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

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

Кейс: как мы делили Москву

Год назад в Москве у Ozon было шесть сортировочных центров: два больших площадью 2-3 тысячи кв. м., и четыре маленьких — по 200-400 кв. м. Сейчас их семь, а через месяц будет девять — причем новые сортировочные центры будут площадью 4-5 тысяч кв. м.

В сезон площадь сортировочного центра будет утилизирована на 95%, поэтому нужно иметь сбалансированную систему, которая будет равно пропорционально загружена, чтобы потом не пришлось что-либо менять. Любое изменение инфраструктуры влечет за собой перенастройку множества систем — от работы фулфилмента до маршрутов курьеров.

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

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

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

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

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

При каких условиях полезны модели

Моделирование можно использовать:

• когда учесть все ограничения в рамках простых инструментов невозможно и когда есть большой процент случайности. Так, со случайностями всегда связано человеческое поведение — в зависимости от опыта специалиста один и тот же процесс может занимать 5 или 25 минут;
• когда нужно протестировать сценарий, а в реальности сделать это слишком дорого или невозможно. Например, как изменятся пассажирские потоки, если изменить расписание рейсов в аэропорту — достаточно ли терминалов, стоек регистрации и зон досмотра;
• когда одни и те же люди в течение суток выполняют разные задачи. В грузовых терминалах портов одни и те же люди заняты на разгрузке прибывающих по железной дороге контейнеров и загрузке судов;
• когда есть пиковая загрузка. Например, как должен работать светофор на перекрестке, если утром и вечером поток машин выше, причем утром большая их часть движется в одном направлении, а вечером — в противоположном.

Фото в материале: Unsplash

Фото на обложке: Rusbase

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

После выступления аудитория задавала спикерам вопросы. Мы публикуем «публичное интервью» с Максимом.

Использовали ли опыт Amazon? Какие решения дают больший эффект, а какие оказались неприменимы в силу российского менталитета?

Опыт Amazon мы, конечно, используем – то есть смотрим, что они делают. Их решения связаны с темой моего доклада «Как развивать инфраструктуру». Заказ в Amazon, может разбиться на десять частей, и они поедут отдельно. Эту логику мы использовали у себя. А вот использовать технологии, заменяющие ручной труд, не получается.

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

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

Можно, но вряд ли это будет выгодно. Особенно, если ты приехал на эту баржу на машине. Туда ты едешь в одно место, а оттуда – в другое.

Почему возникают ситуации, когда в один день два заказа «Озона» приносят два разных курьера?

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

Но со временем таких случаев становится меньше.

Как выстроен бизнес-процесс взаимодействия вашего подразделения с бизнес-заказчиком и кто определяет приоритеты. Что сейчас исследуем?

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

Учитываются ли пробки?

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

До Подмосковья курьеры тоже из центра едут?

Сейчас – да. За «Бетонку» сейчас едем из хабов, которые находятся в Красногорске, Люберцах, до некоторых зон едем из Москвы.

Связаны ли с внедрением изменений недавние проблемы «Озона» с доставкой? Были ли они заранее спрогнозированы и ожидаемы?

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

Кейс был представлен 4 октября 2019 года на конференции Ai Stories, организованной Rusbase. Все выступления и подробный отчет доступны тут. Организационный партнер: Deworkacy Big Data.

Материал дополнен 16 октября в 9:40

• Искусственный интеллект
• Ai Stories
• Большие данные
• Бизнес
• Кейсы
• Электронная коммерция
• Машинное обучение
• Колонки

Источник: rb.ru

Как есть слонов по кусочкам в крупных популяциях, или как мы работаем с большими проектами

Привет, Хабр! Давайте поговорим о проектном управлении в продуктах Ozon.

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

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

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

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

Жизненный цикл слона: композиция vs декомпозиция

В классическом проектном управлении часто можно встретить принцип декомпозиции.

В стратегическом же планировании и управлении распространена концепция композиции. Разные источники рассказывают об этом в разных терминах: Helicopter View, Бык Пикассо, Пять почему. Объединяет всё это универсальный принцип композиции: выбора, агрегации, отсева и упрощения значимых элементов.

• в бизнесе: Идея → Коридорные исследования → Декомпозиция → Количественное исследование → Синтез → Анализ → Композиция → Презентация и защита → Проект;
• в IT: Проект → Декомпозиция → Системная и бизнес-аналитика → Спецификация → Задачи → Реализация → Внедрение → Композиция → Ретроспектива → Запуск.

Команда по разведению слонов: бизнес и IT

Давайте теперь более пристально всмотримся в две вертикали Ozon — бизнес и IT.

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

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

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

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

В IT-вертикали — всё как в условном Google: используется доменная архитектура, в которой команды и отделы строятся вокруг функциональных блоков и модулей приложения. Например, может быть отдел, задачей которого является поддержание в актуальном состоянии какого-то одного API или таблицы данных.

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

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

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

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

Откуда берутся слоны: генерация продуктовых гипотез

Давайте посмотрим, откуда же берутся слоны?

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

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

Процесс проведения предварительных исследований и аналитики выглядит примерно так:

1. Генерация идей.
2. Выбор и приоритизация.
3. Коридорное исследование.
4. Разработка гипотезы, оценка влияния на целевую метрику (что надо сделать, чтобы гипотеза подтвердилась).
5. Оценка вероятности подтверждения гипотезы.
6. Качественное и количественное исследования (если возможно).
7. Разработка бизнес-требований к реализации.
8. Технический и продуктовый UX-дизайн.
9. Построение сиквенс-диаграммы;
10. Декомпозиция до уровня доменных проектов.
11. Верхнеуровневая оценка сложности реализации и размера проекта.
12. Разработка презентации проекта.
13. Защита проекта перед своим руководителем, получение бюджета на реализацию (счастливый номер пункта — случайность).

Если схему еще упростить, получим классический цикл непрерывных изменений (PDCA)

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

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

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

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

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

Формируем меню из слонов: технические комитеты

Окей, проекты для слонов у нас есть. Что дальше?

Распределение ресурсов на производство слонов происходит на техническом комитете или просто техкоме.

Бизнес-заказчик (менеджер продукта) приносит на техком один свой приоритетный проект. В рамках презентации он даёт прогноз влияния своего проекта на бизнес-показатели и продуктовые метрики. Одна из наиболее важных метрик — Gross Merchandise Volume (GMV), валовая выручка по заказам.

Если продукт не самый прибыльный, то и относительное увеличение GMV на условные 200% может принести заметно меньше выручки, чем увеличение целевой метрики на 5% в другом продукте, который уже приносит значительную прибыль. Поэтому проекты менее прибыльных продуктов по умолчанию могут получить более низкий приоритет. Однако «авторитетные» (в смысле прибыльности) бизнес-заказчики могут уступать приоритет менее прибыльным проектам, которые они считают важными.

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

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

Обзорная экскурсия по местам обитания слонов — продолжается

В этой статье мы рассмотрели, как в Ozon устроена работа с большими проектами-слонами, на первых шагах.

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

А как регламентированы процессы разработки у вас?

В следующий раз я расскажу о том, как мы автоматизировали проектное управление (техкомы). Оставайтесь на связи с нашей экскурсионной группой!

• hadi
• pdca
• управление проектами
• структура компании
• ozon
• продуктовая разработка
• купи слона

• Блог компании Ozon Tech
• Управление разработкой
• Управление проектами
• Управление продуктом
• IT-компании

Источник: habr.com