Привет! Как и обещали в предыдущем посте, продолжаем рассказывать про то, как внедряем удобные дашборды для разных департаментов СИБУРа. На очереди — логистика.
За что отвечает логистика? Это не очень очевидно, но логистика — это неотъемлемая часть клиентского сервиса. И хороший дашборд для логистики — это рабочий инструмент для принятия эффективных решений по сокращению затрат и по обеспечению клиентского сервиса. Меня зовут Максим Коровин, я отвечаю за дашборды в логистике, и в этом посте расскажу, как всё устроено.
На какие вопросы отвечают такие дашборды и для кого они?
Целевая аудитория этих дашбордов довольно широкая. Это и управленческий персонал конкретного склада (скажем, директор склада или складского аналитического центра), и диспетчерский центр всей компании, и директор по логистике, и курирующие члены Правления. В общем, запросы и уровни доступа у всех разные, но удобно должно быть всем.
Для этого мы выделяем 3 взаимодополняющие группы дашбордов по предназначению: тактический монитор для менеджеров среднего и высшего уровня, операционный инструмент для текущей поддержки линейной деятельности и факторный анализ для выявления причин отклонений ключевых показателей от плановых значений. Мы стараемся делать так, чтобы дашборд был не просто красивым выводом табличных данных, а являл собой рекомендательную систему, к которой сотрудник мог прийти с вопросом, а выйти — с готовой дорожной картой по исправлению/улучшению здоровья как отдельных операций и процессов, так и всей функции, компании в целом. Ну или как минимум с вектором действий по получению эффекта — увеличению уровня логистического сервиса или же сокращению затрат.
У нас есть три смысловых блока, на которых строятся дашборды.
Автомобильная логистика.
Складская логистика.
Мультимодальная морская логистика.
Пример вопросов к дашборду по складской логистики: какую вместимость законтрактовать на каждом из складов? Как с этого склада распределить объемы по другим складам, сделав это максимально эффективно и наименее затратно? На какой склад следует остановить потоки из-за того, что он в ближайшее время будет перегружен? Какая часть запасов на складе приоритетна к продаже из-за истекающего срока годности? Похожая логика для дашбордов авто логистики – по каким направлениям предоставляемый уровень сервиса, например, услуга срочной доставки, приносит доп. прибыль? На какие направления нужно срочно привлечь больше транспорта для выполнения уровня сервиса?
Хочу подчеркнуть — мы даем людям не просто дашборд (держи тебе картинки красивые вместо таблиц неудобных), мы выдаем предельно конкретные рекомендации как действовать. Мы заранее прорабатываем с экспертами сценарии принятия ими решений в зависимости от соотношения разных показателей и проектируем UX/UI дашборда соответственно. Также мы стараемся автоматически определять верхнеуровневые причины (1-2 уровни «5 почему») и зоны ответственности отклонений фактических значений от ожидаемых. Раньше у эксперта уходило по несколько часов на расследование, почему, например, превышен бюджет – сейчас эксперт заходит на наш дашборд и видит, что отклонение в зоне ответственности блока внешних РФ складов, а причина на 20% в увеличении объемов, на 30% - в росте ставок хранения, 50% - в неэффективном планировании резервных мощностей.
Сам экран дашборда – это только верхушка айсберга – под капотом сложная многослойная инфраструктура озера данных, питающегося данными не только учетных систем, но и аналитических сервисов. Например, в компании внедрена система календарного планирования потоков, которая определяет на каждый день на год вперед, сколько какому клиенту с какого склада отгрузить по критерию максимизации маржинального дохода. Этот план обновляется ежедневно и используется всеми функциями компании в качестве ориентира для ежедневных задач – и именно на нашем дашборде эти данные находят потребителя – эксперт может посмотреть плановые остатки на неделю, месяц вперед, заметить, например, профицит и перераспределить остатки на другие направления
Также в процессе разработки дашборда мы определяем потенциалы дальнейшей автоматизации и предлагаем внедрять и выводить на дащборд результаты работы, например, оптимизатора складской сети - с его помощью можно посмотреть, в какой точке страны лучше разместить склад, какие у него должны быть параметры, чтобы все идущие через него потоки делали это с минимальными затратами. Или оптимизатора подачи и загрузки контейнеров, который автоматически выберет контейнеры под направление, зная актуальные продукты и объемы к отгрузке и действующие ограничения и запросы морских линий и клиентов
Полезные эффекты и работа с заказчиком
Ради полезного эффекта же всё и затевается. Итак, мы хотим, чтобы на базе наших дашбордов и связанных с ними рекомендательных систем у человека сформировался план оптимизационных мероприятий. Мы заранее договорились с заказчиками, что сформированные на основе дашборда такие оптимизационные мероприятия засчитываются как эффект от самого дашборда.
Мы смогли выстроить процессы так, что работаем с заказчиком непосредственно в команде, а не в привычной парадигме “Заказчик — ТЗ — идите делайте”. Это помогает нам вместе улучшать качество продукта, причем делать это оперативно и непрерывно. Заказчик участвует во всём цикле создания продукта, помогает управлять приоритетами и оценивать результаты. В общем, мы взяли и полноценно встроили заказчика в продуктовую команду. Всем советую.
Наш заказчик сам прошел путь отмирания старых дашбордов на Excel и пробовал делать собственные дашборды в рамках нашей Школы Аналитики. Пока пробовал, лично понял, что это сложно и что для этого нужен набор определенных компетенций. Теперь нам с точки зрения владельца продукта сильно проще донести до заказчика, почему решение конкретной задачи занимает определенное время, или почему нам на конкретном этапе нужны те или иные ресурсы. Глупых вопросов не возникает, как и долгих обоснований.
Мы постарались сделать работу продуктовой команды максимально творческой — проводим небольшой консалтинг перед тем, как засесть за создание дашборда, занимаемся системным анализом, набрасываем на бумаге процесс так, как мы его видим.
В чем плюс. С одной стороны, кажется, будто мы просто делаем дашборды. В другой — из-за плотного погружения в процесс мы ещё при создании дашборда замечаем ряд потенциальных улучшений, бутылочные горлышки, возможные нестыковки и прочее. А так как у нас в команде и сам заказчик, исправить замеченное становится сильно проще. Вот и получается, что любой член продуктовой команды на любом этапе создания продукта может предложить какие-то улучшения, которые скажутся не только на создаваемом дашборде, а на работе всего СИБУРа в целом.
Ещё одна наша задача (кроме создания удобного продукта) — сделать так, чтобы каждый в команде занимался не только тем, чем умеет, но и тем, что ему нравится. Нравится человеку общаться с заказчиками — пожалуйста. Больше по душе сидеть и заниматься аналитической работой — на здоровье. Интересен консалтинг и продумывание процессов — вперёд. Есть люди (серьезно, есть) которым искренне нравится просто сидеть и разбирать техдолг, обеспечивать чистоту кода, гарантировать отказоустойчивость.
Микроменеджмент мы свели до нуля — никто не будет сидеть и следить, как сотрудник пишет код (и как долго по времени). Мы за самоорганизацию. Каждый сотрудник — product owner своего собственного процесса, того кусочка общей задачи, за который он отвечает. Да, у него есть базовые ограничения по срокам, как иначе, но в рамках корпоративных стандартов и технических правок он волен делать всё, что хочет.
А ещё мы регулярно обмениваемся опытом внутри команды. Иногда и не только внутри — у нас время от времени проводятся небольшие ротации, а также cross code review, когда один специалист смотрим, что сделал другой, и предлагает какие-то улучшения или делится лучшими практиками. Справедливо как для случая “специалист—специалист”, так и на уровне “команда—команда”: общие сессии, вебинары для обмена опытом и многое другое.
В общем, в процессе создания дашбордов для бизнеса у нас вишенкой на торте получилось создать структуру, в которой заказчик является неотъемлемой частью продуктовой команды, а каждый член этой команды максимально свободен. Насколько это возможно без ущерба для командных KPI и самого продукта.