Статьи

В «Северстали» использовали передовые практики управления данными для области технологических данных. В рамках проекта решена задача сбора технологических данных с датчиков и обогащения их метаданными: технические места, единицы измерения, связи с проектами, владельцами данных. Наличие полной информации о них помогает сэкономить время на коммуникации и поиски в ходе дата-проектов. О роли достоверных и прозрачных технологических данных для компании рассказывает Евгений Курильщиков, владелец продукта «Управление данными» «Северстали» и номинант на премию Data Award.

- Почему управление технологическими данными было выделено в отдельное направление, которое требует дополнительных усилий?

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

- В чем заключается особенность решаемой задачи?

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

- Почему это важно для «Северстали»?

Здесь нам поможет Льюис Кэролл: «Ну а здесь, знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же месте. Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!». Чтобы быть конкурентоспособными, нужно быстро принимать решения о том, как улучшить производительность, повысить качество, сократить незапланированные простои. Мы уже реализовали много проектов, используя технологические данные, и понимаем, что при реализации проекта уходит много времени на поиск тех самых 10-20 параметров работы оборудования, которые необходимы для реализации ML-модели. Имея хорошо описанные данные, мы сокращаем время разработки дата-продукта.

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

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

- Кто может быть владельцем технологических данных?

Как показывает практика, это технологический персонал: инженеры АСУТП, КИПиА, специалисты по ремонту и техническому обслуживанию – то есть сотрудники, которые занимаются обслуживанием оборудования, установкой и настройкой сбора данных в технологической сети.

- Как определяется политика сбора и хранения данных?

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

- Что было сделано в рамках проекта?

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

- Как боретесь за качество данных?

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

- Каковы результаты?

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

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

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

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

- Какова роль проекта для компании?

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

- Каковы дальнейшие направления развития?

Основная задача – распространить практику описания сигналов на все цеха и агрегаты. Это и даст возможность перейти к созданию цифровой копии комбината.

- Как проект отразится на дальнейших дата-проектах «Северстали»?

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

Платформа речевой аналитики является важным инструментом контроля качества коммуникаций с клиентами. Компании ЭНКО – крупнейшему девелоперу Тюменской области – за счет внедрения платформы Voice AI в процессы взаимодействия с клиентами удалось достичь лучшего понимания их потребностей и повысить эффективность продаж. О реализации этого проекта рассказывает Максим Иванов, директор по искусственному интеллекту OOO «Сбер Бизнес Софт» и номинант на премию Data Award.

— Как компания ЭНКО пришла к необходимости реализации этого проекта?

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

Чтобы понять, насколько эти коммуникации эффективны, девелопер долгое время проводил оценку звонков вручную. Однако специалисты по контролю качества успевали обработать не более 12% всех диалогов. При этом проверки обходились компании довольно дорого, а их результаты часто были субъективными.

— Какие задачи требовалось решить?

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

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

— Какое решение было выбрано?

Один из продуктов «Сбер Бизнес Софт» – платформа речевой аналитики Voice AI. Это решение аккумулирует, обрабатывает и глубоко анализирует устные и письменные диалоги, поступившие из любых каналов, – будь то чаты, звонки или аудиобейджи. Благодаря использованию решения бизнес может качественно контролировать уровень коммуникации с клиентами. Платформа давно используется внутри «Сбера» и доказала свою способность стабильно работать под высокой нагрузкой и обрабатывать сотни тысяч коммуникаций ежедневно.

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

— Что собой представляет решение?

Voice AI использует технологию обработки естественного языка (Natural Language Processing, NLP) и понимает речь так же, как и люди. Чтобы научить платформу находить нужные сообщения, были созданы специальные словари – в частности, словарь выражений, которые оператор контакт-центра использует для выявления потребностей клиента.

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

Обучение искусственного интеллекта – непрерывный процесс, поэтому Voice AI продолжает дорабатываться и получать новые данные. Ключевые сотрудники отдела продаж и контакт-центра ЭНКО вносят обратную связь о работе платформы, чтобы улучшить результаты ее работы.

— В чем заключались главные проблемы, как их решали?

Внедрение системы осуществлялось поэтапно, и в ходе проекта ЭНКО перешла на новую систему телефонии, при том, что уже была выполнена интеграция с предыдущей. Это повлекло за собой необходимость срочно настраивать интеграцию платформы с другим источником данных. Также в ходе детальных обсуждений проекта с ИТ-отделом компании выяснилось, что взаимодействие с облачной версией нейросети для распознавания голоса для части решения не подходит. Чтобы реализовать проект, потребовалась установка отдельного сервиса автоматического распознавания речи (Automatic Speech Recognition, ASR) в контур компании, что повлекло дополнительные работы с точки зрения инфраструктуры.

— Как новое решение было воспринято сотрудниками (в том числе теми, чьи разговоры контролируются) и руководством компании?

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

— Какие результаты достигнуты в результате проекта?

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

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

— В чем роль проекта для компании?

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

— Каковы перспективы развития проекта речевой аналитики в ЭНКО?

В ЭНКО планируют расширить использование речевой аналитики и внедрить ее в офисах продаж. Voice AI будет получать записи с аудиобейджей – небольших диктофонов, которые сотрудники носят в течение рабочего дня, переводить разговоры в текст, проверять их на соответствие правилам, анализировать и находить закономерности.

В Альфа-Банке запущена универсальная экосистема для разработки и внедрения моделей машинного обучения. С ее помощью удалось за короткие сроки радикально ускорить процессы создания и запуска моделей, что повысило показатели банка. О реализации проекта рассказывает Павел Николаев, начальник управления технологий машинного обучения Альфа-Банка и номинант на премию Data Award.

- Что привело к необходимости перевести работу с ML-моделями на промышленные рельсы?

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

- Почему это важно для Альфа-банка?

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

- Какой подход был выбран?

Мы создали централизованные общебанковские платформы разработки моделей (MDP) и исполнения моделей (СИМ). Доставка моделей между ними автоматизирована, с несколькими стадиями проверок на тестовых средах, идентичных промышленной. Кроме того, мы разработали систему быстрой доставки данных для этих моделей – Feature Store. Важно отметить, что системы дорабатывались параллельно и при этом активно эксплуатировались.

- Что представляют собой созданные решения?

Среда исполнения моделей (СИМ) – универсальная гибкая система, позволяющая внедрять модели любой сложности в промышленном режиме и с высочайшей отказоустойчивостью. Система позволяет внедрять нестандартные и сложные модели, работающие как в онлайн-режиме, так и в потоковом режиме (stream-модели). Отдельно можно выделить появившуюся возможность пакетного (одновременного) вывода моделей, с помощью которой было выведено более 140 моделей, посвященных ценности клиента и доходу. При этом СИМ не только быстрая, но и сверхнадежная система: ее стабильность для наиболее критичных моделей составила 99,98% в 2023 году.

Среда разработки моделей – это единая платформа для разработки и обучения моделей, в которой разрабатываются все модели Центра продвинутой аналитики (ЦПА). В MDP регулярно работают более 100 специалистов, из них 20% не дата-сайентисты.

Платформа объединяет в себе все современные, привычные для специалиста data science инструменты в единой среде. Разработанные модели развертываются в online, batch, stream и каскадных режимах, что позволяет полностью протестировать все аспекты модели до перехода ее на интеграционное и нагрузочное тестирование.

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

- На каких ИТ-платформах (крупными мазками) базируются эти решения?

Использована аналитическая система Hadoop Datalake, а также Kubernetes, Kafka и т.д.

- Как изменилась жизнь специалистов, занимающихся разработкой моделей?

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

- Какие результаты достигнуты?

Благодаря масштабированию и развитию наших систем в прошлом году мы сократили время внедрения моделей более чем вдвое. Теперь онлайн-модели внедряются в среднем за 2,5 недели. Параллельно выстроили промышленные процессы поддержки моделей и реагирования на инциденты – например, итоговая доступность онлайн-моделей в 2023 году составила 99,98%.

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

В среде разработки моделей количество пользователей увеличилось в 2,5 раза. За счет нашей передовой инфраструктурной доработки Spawner JupyterHub мы экономим значимую часть вычислительных ресурсов в среде разработки моделей (без этого потребовалось бы в 2,5-3 раза больше вычислительных ресурсов). При этом пользователи получают гарантированные выделенные ресурсы: CPU, RAM, диски, GPU. Высокие стандарты поддержки разрабатываются – что нетипично – и на среду разработки, среднее время реакции на инцидент в среде разработки моделей составляет менее одного часа.

Количество факторов для моделей в Feature store за год увеличилось более чем в два раза, теперь Feature Store включает в себя данные всех основных бизнес-линий, использующих модели машинного обучения. Реализован полноценный CI/CD процесс по разработке и доставке алгоритмов формирования факторов моделей из среды разработки в среду применения. Факторы бесшовно внедряются для пакетных моделей и онлайн моделей, использующих внутренние данные посредством интеграции с горячим онлайн хранилищем.

- А с точки зрения финансового эффекта?

В результате снижается время и стоимость разработки моделей, а также риски, связанные с работой с некачественными данными.

- В чем роль проекта для развития банка?

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

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

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

- Каковы направления развития проекта?

В этом году у нас амбициозная цель: реализация онлайн Feature Store. Хотим сделать внедрение всех факторов для онлайн-моделей – в том числе для данных, приходящих непосредственно в момент запроса модели бизнес-приложением, – бесшовным, что значительно сократит время на внедрение онлайн-моделей.

Одной из важнейших составляющих «Системы-112» Московской области является аналитическая подсистема. Именно она дает возможность выявлять точки концентрации инцидентов, реагировать на массовые вызовы и контролировать качество работы службы. О реализации решения, построенного на российской BI-платформе Visiology, рассказывает Николай Муравьев, руководитель направления ИАС компании «ПолиАналитика» и номинант на премию Data Award.

- Какие цели стояли перед «Центром 112»? Ради чего затевался проект?

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

- Какие задачи решались при создании системы?

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

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

- Какие принципы пытались соблюсти, формируя решение?

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

- Почему была выбрана именно платформа Visiology?

Аналитическая платформа Visiology была выбрана как раз исходя из принципов, описанных выше. Платформу характеризует отличная производительность и гибкий аналитический инструментарий, что позволяет в максимально сжатые сроки обеспечить решение всех поставленных задач. Важно отметить, что в данном проекте большую роль сыграло то, что у платформы есть собственные наработки по разметке данных и составлению прогнозных моделей. Недавно, в последнем рейтинге TAdviser она вышла на первое место по продажам лицензий, показав максимальную скорость роста в год.

- Какие сроки и ресурсы потребовались на реализацию проекта?

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

- Что собой представляет созданное решение, из каких элементов оно состоит?

Каждый входящий вызов фиксируется в «Системе-112». Ему автоматически присваиваются атрибуты: время начала, время окончания, координаты, индекс инцидента, а комментарии и другие детали оператор вводит вручную. После этого данные автоматически попадают в аналитическую подсистему.

В рамках проекта реализованы три типа отчетности. Первая из них связана с оперативным информированием. Оперативная аналитика вместе с модулем оповещения позволяют быстро реагировать на внештатные ситуации – например, массовые вызовы или вызовы с отсутствием реакции. Скажем, если с территории в пределах определенного радиуса поступает больше 5-6 вызовов в час, происходит автоматическая эскалация события: через мессенджеры оповещения передаются руководителям региона.

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

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

В настоящее время в состав решения входят восемь разделов и модулей.

- Что, по вашим оценкам, получилось реализовать особенно удачно?

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

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

- Что в ходе проекта было самым сложным?

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

- Каких результатов удалось достичь?

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

- Какую роль играет этот проект для региона?

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

- Каковы направления развития созданного решения?

Систему аналитики планируется развивать в нескольких направлениях. Во-первых, это прогнозная аналитика. Ее главная задача – выявление взаимосвязей между инцидентами, проблемами ЖКХ и погодными условиями. Например, предсказание рисков возникновения ДТП во время гололеда и зон подтопления в паводкоопасный период и действие на опережение. Кроме того, планируется развитие существующих и создание новых аналитических отчетов на базе инструментов голосовой аналитики, применения технологий искусственного интеллекта, а также инструментария оперативного оповещения по ключевым метрикам.

Сеть «Магнит» разработала собственную платформу для таргетинга рекламы, основанную на данных о своих клиентах. В результате был запущен сервис DMP (Data Management Platform), оптимизирующий расходы на рекламу и обеспечивающий доставку покупателям только интересных для них предложений. Основная цель DMP-платформы – получение максимальной пользы и выгоды от данных программы лояльности «Магнита». Подробностями этого проекта делится Василий Мальцев, руководитель управления по клиентской аналитике сети «Магнит» и номинант на премию Data Award.

- В чем заключалась проблема, почему потребовалось создавать платформу для таргетинга рекламы?

В «Магните» накоплено огромное количество знаний о своих пользователях, и создание собственной платформы для таргетинга стало первым шагом к подходу адресной рекламы собственного промо. Затем мы увидели огромный интерес рынка к этим данным, так как данные ретейлера зачастую уникальны. Это не просто люди, которые что-то искали – например, на тему «сыр», а те, кто точно приобретал данный товар в определенный период времени и в определенных магазинах.

- Как решались задачи таргетинга до сих пор?

У нас была платформа, разработанная совместно с компанией-подрядчиком. Система была запущена в 2020 году, и к 2023 году она существенно морально устарела и требовала доработок. При этом было очевидно, что процесс доработки будет длительным и дорогостоящим для нас, так как у нас были неисключительные права на систему в рамках лицензионного соглашения. Также стоит подчеркнуть, что используемый стек технологий в 2022 году стал слишком чувствительным к происходящим в стране изменениям.

- Каких целей пытались достичь?

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

- Почему была выбрана собственная разработка?

Собственная разработка позволяет решить целый комплекс задач. Во-первых, это быстрое внесение изменений и интеграция новых «фишек» для наших клиентов. Буквально за пару месяцев после открытия платформы мы добавили возможность таргетировать и пересекать наши сегменты с собственной CRM-базой клиента, добавили функционал таргетинга по фасетным свойствам товара (например, вкус, тип упаковки, размер упаковки и т.п.) В дальнейшем планируем связать возможность таргетинга с запуском не только на цифровых площадках, но и на оборудовании – TFT-панелях, прайс-чекерах, кассах самообслуживания внутри собственных магазинов.

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

- Какие требования предъявлялись к создаваемой платформе для таргетинга?

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

- Какие силы и ресурсы потрачены на создание платформы?

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

На создание основного функционала ушло 10 месяцев. Еще месяц потребовался для переезда пользователей со старой платформы на новую.

- Что представляет собой созданное решение, кто ее основные пользователи?

Основные пользователи – это собственный маркетинг и рекламные агентства, которые запускают рекламу для поставщиков товаров.

- Что в DMP-платформе удалось лучше всего?

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

- Какое время проходит между появлением у вас значимой информации о событии в жизни клиента и возможностью маркетинговой коммуникации с ним?

Около одного-двух дней, но мы стремимся к сокращению этого времени до четырех часов.

- Как у вас появляется информация о покупательском поведении и привычках людей?

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

- Какие результаты достигнуты?

В нашей платформе работают более 70 компаний, включая собственный маркетинг. Подключено более 400 пользователей. С начала года с помощью платформы заведено более 400 рекламных кампаний, из которых порядка 300 уже успешно завершены. Платформа принесла компании с начала года уже несколько миллионов рублей прямых доходов.

- Какой из них является самым важным?

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

- Каковы направления развития DMP-платформы?

В дальнейшем мы планируем соединить ее с собственной платформой управления рекламными площадями (Supply Side Platform, SSP), с возможностью таргетирования не только на внешних ресурсах, но и на площадках и приложениях «Магнита», а также на нашем внутреннем оборудовании с автоматическим замером вклада медийной рекламы в фактически совершенные покупки (сейлз лифты).

Кроме того, в будущем планируется переход от платформы DMP к DSP (Demand Side Platform), позволяющей выбирать, где и как будет показываться реклама.

Также платформа будет интегрирована и с другими нашими аналитическими решениями, такими как Customers self service, где результат анализа продаж можно будет собрать в сегмент и запустить на него адресную коммуникацию. Например, клиент, проведя анализ приобретенных и потерянных клиентов или анализ перемены предпочтений, сможет собрать людей в «оттоке» по своему бренду в отдельный сегмент для создания персонального промо-предложения.

Когда речь заходит о некоммерческих организациях (НКО), у многих в сознании всплывают призывы «отправь смс по такому-то номеру» и прозрачные боксы на кассах магазинов для сборов на благотворительность. Однако эти расхожие образы не вполне отвечают действительности. НКО в России недаром называют «третьим сектором экономики», наряду с государственным и коммерческим бизнесом, с достаточно большим оборотом капитала. В благотворительные фонды выделяются огромные деньги и из бюджета, и со стороны частных доноров. Как следствие, у НКО высока потребность в цифровизации и обеспечении прозрачности и эффективности работы.

Бизнес-аналитика и прогнозирование с использованием машинного обучения становятся для НКО хорошим шансом повысить доверие к себе, привлечь большие объемы средств, и в результате помочь большему числу нуждающихся. В благотворительном фонде «Дети-бабочки» с этой целью внедрили BI-систему Analytic Workspace. О реализации этого проекта и его роли для организации рассказывает Михаил Греков, директор по развитию BI-системы Analytic Workspace «БАРС Груп» и номинант на премию Data Award.

- Какую задачу решали в ходе реализации проекта?

Благотворительный фонд «Дети-бабочки» с 2011 года помогает детям, страдающим генными дерматозами – поражающими кожу наследственными заболеваниями. Одна из главных задач фонда – наладить эффективную систему оказания медицинской помощи больным. Для этого в фонде внедрена система «Регистр генетических и других редких заболеваний», поддерживающая базу по подопечным фонда: персональные данные, медицинские показания, информация по оказанной помощи и прочее – более 1 тыс. характеристик.

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

- Почему это важно для организации?

Если поднять цифры, фонд «Дети-бабочки» за несколько лет своей работы оказал помощь на 3,5 млрд руб. И поскольку это некоммерческая организация, к ней предъявляются особые требования: все, что есть у фонда, – это его репутация, которую он может монетизировать для того, чтобы собрать деньги с частных доноров и организаций в виде грантов. В связи с этим критически важно прозрачно показывать структуру и отчетность по объему и тратам пожертвований. Внедрение BI в НКО призвано обеспечить максимальную прозрачность отчетности и принятие правильных управленческих решений по распределению средств.

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

- С какими данными ведется работа?

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

Второй важный источник – система учета взаимоотношений с жертвователями. Сюда поступает финансовая информация из систем CloudPayments, «1C: Бухгалтерии», MixPlat. Наконец, как и в большинстве организаций, есть Excel-файлы, где хранятся архивные и исторические данные фонда.

- Какая платформа была выбрана и почему?

Аналитическое решение создано на базе BI-платформы Analytic Workspace. У нее есть несколько важных особенностей. Во-первых, это развитая функциональность машинного обучения в моделях, позволяющая реализовывать довольно сложные сценарии прогнозной аналитики. Во-вторых, высокий уровень self-service, в том числе автоматические ETL-блоки для самостоятельной глубокой обработки данных. Стоит отметить ролевую модель с разграничением доступа, позволяющую обеспечить высокий уровень безопасности конфиденциальных медицинских данных. Кроме того, имеет значение низкий технический порог входа для пользователей, что обеспечивается дружелюбным интерфейсом. А для некоммерческих организаций предусмотрена облегченная ценовая и лицензионная политика.

- Что представляет собой созданное решение?

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

Так, информационная панель «Эпидемиология» дает представление о том, какие мутации встречаются в каких регионах страны, в каком возрасте, у людей каких национальностей и т.д. Здесь собраны данные по половозрастной структуре с автоматическим пересчетом данных в динамике времени. Обеспечено распределение подопечных по диагнозам, список которых постоянно расширяется. Реализован drill-down и фильтрация данных друг относительно друга.

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

Информационная панель «Медицина» дает возможность проанализировать все медицинские данные. В частности, каждый подопечный фонда прошел генетический анализ по секвенированию ДНК. Таким образом собрана огромная база данных, визуализация которых дает возможность определить, какова популяционная частота возникновения мутаций, как мутация в определенной нуклеотидной замене влияет на развитие клинической картины заболевания и т.д.

- Что в ходе проекта было самым сложным?

Определенную сложность при работе с медицинскими данными представляет их объем и разрозненность их представления, что потребовало глубокой обработки и трансформации данных на этапе построения логической модели. Analytic Workspace обладает мощным встроенным ETL-модулем на базе связки сервисов Apache Spark и Apache Airflow. Без ложной скромности хочу сказать, что мы добились одной из лидирующих позиций на российском рынке по ETL благодаря разработке и внедрению автоматических ETL-блоков для самостоятельной обработки данных, в том числе блока ML-прогнозирования. Возможности ETL-модуля позволяют решать весьма сложные задачи обработки данных.

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

- Каких фактических результатов удалось достичь?

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

- В чем роль этого проекта?

Благодаря внедрению BI-системы Analytic Workspace с функцией ML-прогнозирования у фонда «Дети-бабочки» появились данные, которые позволяют планировать свою деятельность. Простыми словами – у каждого подопечного фонда имеются определенные проблемы с кожей. Система умеет автоматически предсказывать, какие объемы денежных средств и необходимой терапии потребуются конкретному ребенку, исходя из его клинической динамики и результатов анализов ДНК для достижения максимально благоприятного результата.

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

- Каковы перспективы развития проекта?

Сейчас для нужд фонда проводится внедрение машинного обучения, которое расширит существующую прогнозную аналитику и откроет новые возможности: прогнозирование развития заболевания у подопечного, прогнозирование требуемых объемов помощи, what-if анализ с учетом прогнозной модели.

- А как начет проектов в подобных организациях? Вероятно, их потребности схожи.

Благотворительный фонд «Дети-бабочки» стал нашим первым НКО-проектом. Поскольку он оказался весьма успешным и полезным для решения задач фонда, сейчас BI-система внедряется в других НКО. Так, в благотворительном фонде «АиФ. Доброе сердце» нами вместе с нашим постоянным партнером по работе с НКО компанией «Редермио» реализована сквозная аналитика с применением ML-прогнозирования для повышения эффективности фандрайзинга.

Для демократизации средств машинного обучения (ML) важным шагом должно стать создание self-service инструментов, которые позволяют провести всю работу силами одного аналитика. В «БАРС Груп» создали в своем BI-решении Analytic Workspace готовые автоматические блоки для выстраивания предиктивной аналитики на базе машинного обучения. Об одном из первых проектов – прогнозировании выручки и количества чеков, реализованном в аптечной сети «Губернские аптеки», – рассказывает Александр Кварацхелия, ведущий архитектор BI-системы Analytic Workspace компании «БАРС Груп» и номинант на премию Data Award.

- Какая проблема стояла перед «Губернскими аптеками»?

«Губернские аптеки» — это крупная государственная аптечная сеть, имеющая более 400 филиалов на территории Красноярского края, Республики Тыва и Хакассии. Перед ней ежегодно вставала задача прогнозирования розничной выручки – от его результатов зависит ряд других бизнес-процессов на предприятии. Например, качество прогноза розничной выручки влияет на будущую наценку, товарооборот, KPI для структурных подразделений, формирование бюджета, мотивацию фармацевтов и т.д.

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

- Какой подход вы предложили?

Предиктивная аналитика как возможность заглянуть в будущее открывает перед бизнесом массу перспектив – от прогнозирования и оптимизации процессов до выявления паттернов и предотвращения проблем. Однако до сих пор предиктивная аналитика являлась серьезным технологическим вызовом для BI-систем: внедрение машинного обучения требовало коллективной работы data-инженеров, DevOps-специалистов, системных администраторов и BI-разработчиков самой высокой квалификации.

Мы решили шагнуть дальше и создать готовые автоматические блоки для self-service ML-прогнозирования, которые позволяют провести всю работу силами одного аналитика. Analytic Workspace делает машинное обучение доступным для прогнозирования широким массам пользователей BI.

- В чем его особенность?

Реализация self-service ML-прогнозирования в нашем решении стала возможной благодаря новому подходу к построению ETL-процессов, который основан на создании автоматических программных ETL-блоков, или «блоков-декораторов». Такие блоки представляют собой управляющие скрипты, каждый из которых производит определенную операцию с данными таблицы.

Важно, что библиотека декораторов доступна «из коробки», и пользователь может самостоятельно привести свои данные к необходимому виду без дополнительного программирования. Таким образом, из небольшого количества простых ETL-блоков можно конструировать большие логические модели с неограниченным количеством уровней вложенности для решения самых сложных аналитических задач.

Среди набора ETL-блоков имеются блоки ML-прогнозирования. Например, блок «ML-модель в ручном режиме» выполняет применение модели машинного обучения для обогащения вложенного объекта. «Прогнозирование временного ряда» позволяет построить прогноз вперед или назад на основании исторических данных. «Классификация/регрессия с ML-моделью» выполняет предсказание (классификацию, регрессию) для вложенной в него таблицы на основе ML-модели из внутреннего реестра моделей.

- Какие этапы включал в себя проект?

За основу прогнозной модели для «Губернских аптек» были взяты те ключевые факторы, которые должны определять значения розничной выручки с точки зрения бизнеса. Это исторически сложившаяся динамика выручки и чеков c 2019-го по 2023 год, льготный рецептурный сегмент, вид аптечного пункта и его структура продаж, конкурентное окружение в населенных пунктах присутствия, площадь торгового зала.

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

- Как фактически выглядит процесс создания модели для пользователя?

Процесс работы по созданию модели ML-прогнозирования проходит в три этапа. После подключения источников данных и предварительной ETL-обработки данных во внутреннем хранилище системы, реализованном на базе Clickhouse, формируется датасет (аналитическая витрина данных) для обучения. Затем этот датасет передается на интегрированный интерфейс Jupiter Notebook, где происходит обучение прогнозной модели. Наконец, обученная ML-модель автоматически попадает в реестр моделей системы, после чего она применяется к промышленному набору данных для прогнозирования.

- Что уже успели сделать в рамках реализации проекта?

На первом этапе работы была произведена оценка качества данных, которые используются для обучения ML-модели. Точность прогнозов может быть весьма чувствительной к наличию пропущенных значений за некоторые периоды. В нашем случае такие пропуски были вызваны, например, периодическим закрытием аптек, расположенных на территории роддомов или больниц, в связи с закрытием этих медучреждений на плановую мойку. Восстановление данных было проведено с помощью автоматического ETL-блока «Функция» с использованием библиотеки Prophet. Восстановленных таким образом данных было достаточно для обучения базовой модели временного ряда.

Подготовка данных для обучения моделей «градиентный бустинг» и «нейронная сеть» проводилось путем построения матрицы признаков множественной регрессии также с помощью ETL-блоков внутри Analytic Workspace.

Подготовленные таким образом данные были переданы в интерфейс Jupiter Notebook, где базовые модели обучились по отдельности и были объединены ансамблирующей моделью для повышения точности прогноза, поскольку объем данных был недостаточен для использования какой-либо одной базовой ML-модели.

Затем обученные модели были возвращены в интерфейс Analytic Workspace и применены к данным «Губернских аптек» для построения логической модели данных, включающей прогноз на 2024 год, и последующей визуализации.

- Что было сложнее всего?

При создании self-service решений основную сложность представляет соблюдение баланса между простотой использования инструмента и сохранением достаточной функциональности. Мы решили эту проблему следующим образом. В Analytic Workspace представлен набор автоматических блоков ML-прогнозирования «из коробки», и этот список от релиза к релизу расширяется. С помощью этих блоков можно (даже на бесплатной демоверсии) осуществлять распространенные сценарии прогнозирования.

Однако для сложных случаев мы оставляем возможность создания и обучения модели машинного обучения в интегрированном Jupiter-подобном интерфейсе, который в разных модификациях используют дата-сайентисты и аналитики-специалисты для работы с ML-моделями. Так, для «Губернских аптек» потребовалось применение трех различных моделей машинного обучения и ансамблирующей модели, поскольку объем данных был недостаточным для точного прогноза с помощью какой-либо одной модели.

- Каковы первые результаты?

Уже сейчас получены результаты первого месяца работы компании, которые позволяют оценить точность ML-прогнозирования: расхождение план-факт составляет менее 10% (точность 93,6%), что является отличным результатом.

- Эффект каких масштабов можно ожидать в дальнейшем? Как точность прогнозирования может отразиться на бизнесе?

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

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

- В чем заключается роль этого проекта?

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

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

Разумным и эффективным способом оптимизации производства молока является подход к учету и кормлению коров в соответствии с их индивидуальной продуктивностью. Разделение животных по группам и предоставление им соответствующего рациона, реализованное в решениях татарстанской компании РИВЦ для агропредприятий, позволяет максимально использовать их потенциал. О решении этой задачи рассказывает Нияз Халиуллин, генеральный директор АО РИВЦ и номинант на премию Data Award.

— В чем заключается суть предлагаемого вами подхода?

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

— Почему это важно?

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

— Как родилась идея создания решения, реализующего «индивидуальный подход» к уходу за животными?

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

— Как вы вообще оцениваете уровень автоматизации агрохозяйств? К чему они готовы, а к чему – пока нет? Какие решения ими в целом наиболее востребованы?

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

— Какие требования и принципы пытались соблюдать при создании системы?

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

— Что собой представляет созданное вами решение? Какие элементы оно включает?

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

— Что, по вашему мнению, удалось особенно хорошо?

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

— Приведите примеры использования решения в агрохозяйствах. Каких результатов удалось достичь?

Ярким примером использования решения может служить хозяйство «Сурнай» в Балтасинском районе Республики Татарстан. Оно внедрило систему индивидуального учета молока и за год сократило затраты на кормление на 10%, увеличило среднюю продуктивность коров на 15% и снизило количество заболеваний на 20%.

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

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

— Какие эффекты можно считать наиболее показательными?

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

— В чем роль проекта для отрасли?

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

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

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

— Какими аргументами можно убедить собственников инвестировать в ИТ?

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

— В каком направлении будет развиваться решение?

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

В Ростелекоме реализован проект Self-Service Analytics Platform, в результате которого удалось создать платформу для работы с данными, которую можно быстро и без серьезных затрат развернуть в любом достаточно крупном бизнес-подразделении. При этом фактически используется формат франшизы – команда проекта снабжает подразделение всем необходимым для выстраивания функции. О реализации проекта и его роли для компании рассказывает Дмитрий Тарасов, директор центра разработки аналитических решений «Ростелеком Корпоративные Системы» и номинант на премию Data Award.

- Расскажите об истории проекта.

Проект Self-Service Analytics Platform (SSAP) изначально родился как ответ на вызов, связанный с острой потребностью в аналитических решениях и интерактивной отчетности. Он реализовывался для сверхкрупной функции работы с дебиторской и кредиторской задолженностью «Ростелекома» и стартовал более трех лет назад. В силу большого количества процессов, данных и постоянно меняющейся обстановки в процессах, традиционная разработка «в граните и на века», очень плохо ложилась на потребности стейкхолдеров, выглядела крайне дорогостоящей и весьма тяжелой. Усугубляла ситуацию и классическая проблема крупных, слабо централизованных компаний – необходимых данных либо вовсе не было в доступе, либо они были фрагментарные и не сказать, что очень качественные. Выход был найден в создании развитой self-service функции работы с данными и аналитикой, которую пришлось делать значительно более «прокачанной» технически, чем это обычно принято.

- В чем заключалась проблема?

Часто под self-service ограниченно понимают возможность самостоятельно обратиться к готовым данным и сформировать несложный дашборд или выгрузку. В нашем случае все обстояло куда печальнее – нам нужно было упаковать в self-service весь цикл работы с данными: от обследования систем-источников и интеграционных решений до развитого хранилища данных и BI-подсистемы. При этом система должна была остаться гибкой для изменений, обладать сравнительно дешевой стоимостью владения, не требовать сверхквалифицированных специалистов для обслуживания и развития, позволять бизнесу вести классическую self-service аналитику, формировать регламентные отчеты с высоким качеством данных (до четырех «девяток» включительно) и оставаться масштабируемой.

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

- Успешный «взлет» обычно провоцирует повышенный интерес к решению…

Да, довольно быстро мы поняли, что получившаяся функция работы с данными востребована не только внутри подразделения, работающего с дебиторской задолженностью. Она очень хорошо подходит для всех кейсов, когда разработка «Большого ИТ» или использование вендорских решений не подходит – по финансовым, организационным или политическим причинам. И таких зон в крупной организации много, гораздо больше, чем нам изначально казалось. Максимальная их концентрация, что весьма логично, пришлась на Общий центр обслуживания (ОЦО), как держателя функций поддержки, которые обычно не могут себе позволить тратить слишком много на ИТ-решения. И на этом этапе перед нами встал новый вызов – как масштабировать подразделение, работающее с данными, и его функционал на совершенно новые предметные области, которые еще и по объему данных дадут нам десятикратный прирост.

- Какой подход выбрали к решению задачи?

Нас спасли изначально верно подобранная архитектура, хорошо масштабируемая организационная модель и упаковка решения в контейнеры – в прямом и переносном смысле. Технические решения были виртуализированы почти сразу, для используемых инструментов развернут единый репозиторий, процесс разработки адаптирован под CI/CD поставки параллельных команд, а для команд, работающих над техническими решениями, введена специализация на предметных областях.

Кстати, команды зачастую формировались непосредственно из бизнес-среды вокруг сильного ядра. Например, команда, работающая над задачами аналитики и отчетности операционных подразделений HR, формировалась полностью из аналитиков внутри самого HR. Ребята прошли обучение производственному процессу, подтянули технические навыки, поработали 2-3 месяца с выделенными наставниками и вышли в «свободное плавание». Само собой, соблюдая требования и нормы процесса и оставаясь в зоне контроля основной команды.

Говоря в общем, мы стандартизировали процессы подготовки и развития команд self-service разработки, внутри них внедрена специализация сотрудников: бизнес-аналитик, дата-инженер, BI-разработчик. Были стандартизированы и кодифицированы принципы управления – от формата ведения плана до графика регламентных встреч. При этом мы постарались максимально сохранить сильные стороны self-service: гибкость, отзывчивость к изменениям, низкую стоимость владения, хороший показатель time-to market.

- Что в итоге получилось?

Как итог, мы получили уникальный, как нам кажется, продукт, который позволяет разворачивать функцию self-service работы с данными практически в любых условиях, не имея ограничений на тип источников, сложность интеграций, особенности ИТ-ландшафта. Решение не сильно требовательно к инфраструктуре, не сильно нуждается в «звездах» ИТ. Причем, что важно, мы не ограничиваемся только технической стороной вопроса. В нашем подходе учитываются вопросы подбора, развития, встраивания новой функции в организационную модель, настроенный процесс работы и даже работа с комьюнити в области данных.

Использованный нами технологический стек либо входит в реестр отечественного ПО, либо относится к open source, а процесс легко стыкуется с функцией RPA, развитием Data Science решений и с разработкой средств малой автоматизации.

- Как новое решение отразилось на бизнес-результатах?

За счет внедрения эффективных средств анализа работы с дебиторской и кредиторской задолженностью, своевременного выявления возможных и уже случившихся проблем с оплатой, выявления проблем и ошибок в данных, ежегодный прямой эффект составил более 100 млн руб. С учетом срока полезного использования системы в 10 лет, суммарный эффект превысит миллиард дополнительного денежного потока.

Эффект на оптимизацию резерва на сомнительные долги достигает более 50 млн руб. в год, то есть более 0,5 млрд руб. за срок жизни решения компания получит плюсом в операционный доход до вычета амортизации основных средств и нематериальных активов (OIBDA) и валовую маржу.

Аналитическая платформа работы с качеством процессов уже позволила улучшить ситуацию с качеством внутреннего сервиса на 8-10%, прогнозируется дальнейший рост показателя. Аналитика производительности сотрудников позволила высвободить более 40 FTE (full-time employee — «эквивалент сотрудника с полной занятостью»), и это еще не предел. В ходе внедрения системы выявлялось и исправлялось огромное количество неоптимальностей в процессах, внедрялись цифровые метрики, вводились автоматизированные KPI.

Сроки подготовки отчетности улучшились от 12% до 1000% – часть отчетности и аналитики стала формироваться до 10 раз быстрее. Как пример – если для подготовки отчетности о движении дебиторской задолженности с локализацией проблем до клиента и договора ранее требовалось до 45 дней с момента готовности данных (долгая консолидация данных, медленный анализ, выверка и исправление ошибок), то теперь на это уходит не более двух дней, из которых один – машинное время отработки конвейеров расчета и подготовки данных.

Выросло качество данных за счет постоянного их использования и внимания к результатам в цифрах. Нам удается поддерживать этот показатель на уровне не ниже 99%.

- Как новые технические возможности отразились на корпоративной культуре?

У нас сформировалось устойчивое дата-комьюнити, уже способное решать достаточно серьезные технические задачи. В значительной степени завершен процесс перехода на data-driven модель управления процессами в ОЦО. Фокус внимания аналитических подразделений сместился с бесконечной подготовки данных и формирования полу ручных отчетов на саму аналитику, то есть выявление и исправление проблем и «бутылочных горлышек». Кое-где функция дозрела до полноценной предиктивной аналитики, да и накопленные данные уже позволяют ею заниматься.

Если говорить о внутренних метриках, то за три года количество регулярных пользователей BI-отчетности приблизилось к 5 тыс. человек, а количество просмотров отчетов в месяц перевалило за 30 тыс.

- Какова роль этого проекта для бизнеса «Ростелекома»?

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

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

При этом мы не претендуем на роль «Большого ИТ», наша платформа вполне позволяет уживаться «на одной поляне» и с ним, и с командами бизнес-подразделений, выстраивая тесную координацию и симбиоз. Более того, именно так мы всегда и рекомендуем делать, отдавая в «Большой ИТ» системные и наиболее тяжелые интеграционные решения, а также системы с критической и закритической стоимостью рисков. А командам «на земле» можно оставить функцию классического self-service, отработку быстрых гипотез, ad-hoc задачи и непосредственно анализ.

- Каковы направления дальнейшего развития проекта?

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

С другой стороны, мы планируем и далее развивать нетехнические стороны проекта: внедрить полноценную школу self-service команд, улучшить обучение владельцев продуктов, развивать комьюнити. Продолжаем систематизировать процесс продвижения разработанных продуктов и сервисов, обучение работе с ними для конечных пользователей. Развиваем площадку для кросс-коммуникаций self-service команд внутри компании.

Безусловно, будем уделять время росту качества self-service решений и контролю их соответствия общей ИТ-стратегии «Ростелекома» и стратегии работы с данными. В это отношении уже проделана большая работа, причем мы внимательно следим за балансом, стараясь не допустить излишней бюрократии или избыточного утяжеления процессов разработки.

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

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

В условиях динамичного развития инфраструктуры крайне важно контролировать этот процесс, обеспечивая заинтересованных специалистов необходимыми данными. В Сбере с этой целью разработали и запустили «Единую аналитическую систему данных об инфраструктуре», обеспечивающую сквозную аналитику по ключевым процессам жизненного цикла ИТ-инфраструктуры. О реализации этого проекта рассказывает Анастасия Евланова, главный эксперт Управления внедрения технологий защиты инфраструктуры Департамента инфраструктурных решений «Сбера» (SberInfra) и номинант на премию Data Award.

— Что стало причиной создания системы? Какие проблемы требовалось решить?

За последние годы «Сбер» качественно и количественно вырос как в своих прежних банковских продуктах, так и в новых инициативах для клиентов. На каждый продукт, систему, инновацию требуется ИТ-инфраструктура.

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

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

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

— Какой выбрали подход, какие требования предъявлялись к создаваемому решению?

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

Для нашей системы ключевыми были требования по автоматизации сбора данных из множества внутренних систем, связи этих данных между собой, расчетам метрик и объединении детализированных данных ИТ-инфраструктуры в одном месте – единая система.

Дополнительно, мы сразу закладываем возможность по переходу на self-service аналитику: разовые или неприоритетные аналитические исследования данных важны для конкретных задач, но с ними пользователи могут справиться и самостоятельно после предоставления доступа и обучения.

— В чем суть созданного решения?

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

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

— Какие данные охватывает система?

Мы получаем данные из внутренних систем, которые собирают информацию о текущем состоянии ИТ-инфраструктуры. К ним относятся данные о загрузке ИТ-инфраструктуры из систем инфраструктурного мониторинга и сбора метрик, данные о характеристиках конфигурационных элементов и их связях с системами банка, информация по управлению этими элементами из системы управления и автоматизации ITIL- и ITSM-процессов банка.

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

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

— На какой платформе реализовано решение?

Центром системы стало хранилище для сырых и преобразованных данных на платформе Hadoop, стандартных обвязок с базой метаданных PostgreSQL, сервисами журналирования и мониторинга. Аналитика и визуализация данных реализована на BI-платформе Qlik в виде информационных панелей и дашбордов, логически связанных между собой. Так как конечный пользователь взаимодействует именно с BI-платформой, то ролевая модель с разграничением видимости данных реализована тоже в Qlik.

— Что является «фишкой» решения? Чем можно гордиться?

У нас 16 различных источников данных по ИТ-инфраструктуре, которые мы изучили, связали между собой, рассчитали, автоматизировали сбор, агрегировали, визуализировали и на все это еще и написали документацию. При этом в каждой системе есть свои нюансы, нужно «вычищать» сырые данные от ошибок сканирования или некорректных записей, отлавливать систематические отклонения от процессов и проводить корректировки, понимать и применять методологию расчета, которую нам рассказывают аналитики систем.

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

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

— Приведите пример того, как изменились работа пользователей благодаря системе.

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

— Какие результаты достигнуты и ожидаются?

Мы автоматизировали получение прозрачных и детальных данных обо всех этапах жизненного цикла элементов ИТ-инфраструктуры, начиная от подготовки оборудования до вывода его из эксплуатации, благодаря чему было найдено legacy – неиспользуемое устаревшее оборудование в ЦОДах, а также оптимизировано и перераспределено недостаточно утилизированное используемое оборудование.

Так как данные и соответствующие показатели стали доступнее и прозрачнее для всех участников процесса подготовки новой ИТ-инфраструктуры, то количество выданного оборудования в требуемый срок увеличилось с 58% до 97%.

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

— Пытались ли оценить эти эффекты в деньгах? И вообще о каких масштабах оптимизации может идти речь?

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

Объем самой компании «Сбер» колоссальный, для ее функционирования требуется много серверов, систем хранения данных, баз данных. Точные цифры я не могу называть из-за условий неразглашения, но у «Сбера» самый большой ЦОД в России, и при этом он не единственный. И теперь данные об этом оборудовании сведены в одной системе.

— Каковы перспективы развития проекта?

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

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

И, конечно, мы планируем перенести BI-платформу на продукт российского вендора или внутренний продукт.