Привет, меня зовут Александр Окороков, я основатель и генеральный директор ИТ-компании и автор медиа вАЙТИ. Мы помогаем заказчикам выстроить оптимальную стратегию принятия управленческих решений, чтобы эффективно использовать ресурсы и не терять деньги. Именно эту задачу решает data-driven-подход к принятию решений и управлению продуктом с опорой на данные.

Что такое data driven

Есть разные подходы к принятию управленческих решений. Например, best practices, когда в своей работе компания руководствуется общепринятыми стандартами отрасли. Еще одна стратегия — highest paid person’s opinion (HiPPO), или принятие решений на основе интуиции руководителя. Полное название концепции, о которой мы говорим сегодня, — data driven decision making (DDDM), дословно «принятие решений на основе данных». 

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

Как избежать «болота данных»

Чтобы использовать DDDM, нужны не только сами данные, но и методика их использования. Задача сбора данных предполагает построение цифрового ядра бизнеса. Каждый происходящий в компании процесс должен оставлять цифровой след, с которым в дальнейшем можно работать. На основании цифрового следа формируется data lake (озеро данных) и строится методика, которая позволяет оцифровать и визуализировать полученные данные в виде, пригодном для принятия решений.

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

Именно поэтому здесь возникает второй момент. У вас должен быть рабочий алгоритм анализа данных и регламент принятия решений. Без этого метод data driven работать не будет. А значит, подходить к процессу цифровизации нужно следующим образом:

  • понять, какие именно решения вы хотите принимать, основываясь на данных;

  • понять, по каким принципам эти решения будут приниматься;

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

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

Всё это делать проще, если бизнес изначально цифровой. Однако сегодня DDDM применяется в любых сферах деятельности. Просто его реализация в части фиксации цифрового следа физических процессов немного сложнее. Может потребоваться связь онлайн- и офлайн-процессов через интернет вещей, различные трекинги, машинное зрение и пр. — всё, что позволяет зафиксировать след физического процесса в цифре.

Data driven: кейсы

Реализация продуктов питания

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

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

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

Производственная компания

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

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

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

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

Заключение

Внедрение DDDM — достаточно сложный и многоуровневый процесс. Он должен быть досконально проработан на всех этапах, начиная с технического задания. Постановка задачи начинается с определения тех решений, ради которых затеян весь процесс, следом идет разработка регламента принятия этих решений, которая дает нам понимание о наборе необходимых данных, и, наконец, построение цифрового ядра, позволяющего эти данные собирать. Двигаясь от простого к сложному, от частных задач к стратегическим, можно постепенно расширить применение data driven на все процессы в компании. Однако, когда мы говорим, что этот метод наиболее передовой и эффективный, это не значит, что все остальные подходы нужно отбросить и забыть. Каждый из них имеет свои области применения.

Например, если вы открыли кофейню в новом районе, то у вас нет другого способа оптимально составить первоначальное меню, кроме best practices. Позднее, собрав данные о предпочтениях местных потребителей, вы сможете использовать DDDM. Применение HiPPO мы видим на примере многих компаний, создающих уникальные продукты, таких как Apple, Google, Amazon или Yandex. Но и они на следующих этапах разработки используют DDDM. Искусство бизнеса — найти оптимальный баланс в применении различных стратегий управления и использовать каждую по назначению.

вАЙТИ — DIY-медиа для ИТ-специалистов. Делитесь личными историями про решение самых разных ИТ-задач и получайте вознаграждение.


Еще больше статей

#Разработка

Выбрали лучшие практики архитектуры высоконагруженных систем
Краткий список инструментов, решений и подходов, которые мы используем в Umbrella IT при разработке highload-систем.

Бизнес-моделирование: как и зачем его использовать в разработке
Разбираю, чем помогают бизнесу диаграммы процессов и когда процессы реально нужно оптимизировать.

Интеграция с внешними системами через электронную почту (PHP IMAP)
Делюсь способом автоматизировать рутинные задачи с помощью PHP-библиотеки.

#Сети

Как мы настроили удаленную инфраструктуру для ритейлера через VPN
Рассказываю, как мы создавали для клиентов удаленные рабочие места и объединяли офисы через защищенную сеть.

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

Практика построения корпоративных VPN в одном чек-листе
Написал чек-лист по настройке корпоративных VPN на основе своей практики.

Комментарии (1)


  1. Adgh
    17.12.2024 14:13

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

    Статья - пустышка, про практику Data driven в ней ни слова