Статьи

«Сбербанк Факторинг» начал реализацию проекта построения системы управления данными. Решение SBF DM призвано автоматизировать и упорядочить процессы по работе с данными, сделать их более прозрачными и доступными для всех сотрудников компании. О ходе проекта рассказывает Михаил Пекер, директор ИТ-проектов «Сбербанк Факторинг» и номинант на премию Data Award.

— Что привело к созданию системы по управлению данными в «Сбербанк Факторинг»? В чем заключались проблемы?

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

— Какой был выбран подход для решения этих проблем?

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

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

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

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

Для начала нам пришлось определить и описать существующие в компании данные, витрины и отчеты, согласовать владельцев, разграничить доступы. Уже затем мы перешли к автоматизации. На этом шаге и появилась наша система по Sberfactoring data management (SBF DM).

— На каких технологиях реализован проект?

Учитывая существующие ограничения и риски, было принято решение строить SBF DM на открытых технологиях, с возможностью самостоятельно развивать и сопровождать систему. Это потребовало определенных навыков от команды, которые, впрочем, не были заоблачными: в первую очередь требовался опыт программирования на Python и важное качество «искать способы, а не причины».

— Каких результатов удалось достичь? Чем можно похвастаться?

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

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

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

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

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

— Как вы намерены бороться за качество данных? Как будете его измерять?

Чтобы повысить качество данных, требуется вовлечение не только ИТ, но и бизнес-подразделений. На первом этапе будут сформированы требования к качеству данных. Затем определены и реализованы необходимые проверки. Следом будет подключен мониторинг, с помощью которого мы будем видеть отклонения от допустимого уровня качества данных и оперативно их устранять.

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

Основная роль решения «SBF DM. Система управления данными» – помогать сотрудникам и руководству компании принимать быстрые и правильные решения на основе качественных данных, которые отразятся на получении прибыли и снижении затрат компании.

— Каковы планы по развитию платформы управления данными?

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

Сохранение клиентов всегда было приоритетной задачей любой компании. Ключевой проблемой здесь является выявление тех клиентов, которые по каким-то причинам собираются уйти, и определение среди них ценных, которых важно удержать. О реализации такого проекта рассказывает Валентина Литвинова, руководитель направления Дивизиона «Малый и Микро "Сбербанк"» и номинант на премию Data Award.

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

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

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

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

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

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

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

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

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

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

— Какие технологии использовали?

Это классическая задача бинарной классификации. Мы использовали алгоритм градиентного бустинга. Он реализован на языке Python c использованием библиотеки LightGBM. Глубина данных для обучения модели составила 24 месяца.

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

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

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

— Приведите пример неожиданных инсайтов, появившихся в ходе проекта.

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

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

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

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

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

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

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

В итоге, за 2022 год нам удалось снизить долю оттекающих доходных клиентов на 17%. Увеличение среднего срока жизни клиента в банке составило 20%.

— Насколько это соответствовует ожиданиям? Возможно ли результат улучшить, и за счет чего?

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

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

Сохранение чистого операционного дохода по оттекающим клиентам за 2022 год составило несколько миллиардов рублей.

— В чем роль этого проекта для бизнеса?

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

Заправочные станции «Газпромнефти» взяты под контроль системы мониторинга, которая в режиме реального времен отслеживает все оборудование и призвана не допустить остановки бизнес-процессов. Решение разрастается до масштабной интеграционной платформы, позволяющей развивать новые продукты. О его создании и перспективах рассказывает Ирина Бойкова, руководитель направления развития систем мониторинга и контроля активов «Газпромнефть» и номинант на премию Data Award.

— Какую бизнес-проблему пытались решить с помощью единой системы мониторинга?

При появлении автоматических АЗС появилась необходимость создания Удаленного диспетчерского центра (УДЦ) для контроля параметров технологического оборудования. Это послужило отправной точной для создания всей системы мониторинга АЗС. Со временем функции УДЦ от сбора остатков нефтепродуктов только на автоматических станциях переросли в единый мониторинговый центр всей сети автозаправок «Газпромнефти» с возможностью удаленного приема нефтепродуктов, отслеживания количества и качества нефтепродуктов, управления инцидентами и мониторинга технологического и ИТ-оборудования.

— Почему это было критически важно для компании?

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

— Какой подход был выбран для решения?

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

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

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

— Что представляет собой разработанное решение, каков его функционал?

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

— Какие платформы используются?

Мониторинговый центр АЗС реализован на российской интеграционной платформе интернета вещей АggreGate, полностью соответствующей критериям импортозамещения.

На старте проекта УДЦ была использована система мониторинга платежных терминалов (Outdoor Payment Terminals, OPT). Однако после появления новых запросов бизнеса стало понятно, что данная система не подходит для глобального мониторинга всей сети АЗС. В результате анализа платформенных решений была определена в качестве целевого решения платформа промышленного интернет вещей отечественного производства Tibbo AggreGate. Сочетание единой архитектуры решения и low-code разработка позволяют нам быстро адаптироваться под потребности бизнеса и создавать уникальные алгоритмы и фреймворки для мониторинга активов.

— Low-code – это принципиальное решение? Как его ограничения соотносятся с преимуществами?

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

— А как система мониторинга выглядит для пользователей?

Это веб-интерфейс собственной разработки, кастомизированный под нужды каждого взятого в отдельности направления.

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

На данный момент на платформе запущены рабочие места Эксплуатации, Метрологии, Управляющего АЗС, ИТ, Логистики. В интерфейсах системы осуществляется мониторинг состояния технологического, торгового и ИТ-оборудования, измерительных систем и систем жизнеобеспечения. Нами реализовано более 10 интеграций, среди которых как внутренние корпоративные системы («1С», Лабораторная информационно-управляющая система и др.), так и внешние информационные системы подрядных организаций.

В периметр мониторинга входит более 1,4 тыс. АЗС, а список пользователей и систем, подключенных к платформе, постоянно растет. Кроме того, наш фокус развития также направлен на проработку новых интеграций платформы с партнерами, производителями оборудования и провайдерами связи для создания прорывных для рынка IoT-продуктов.

— А с финансовой точки зрения?

Сократились операционные затраты на комплексное сервисное обслуживание АЗС, сократились простои станций и потери топлива.

— В чем роль этого проекта для бизнеса компании? Какие новые возможности открыла платформа мониторинга?

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

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

— Планируется ли вывод решения на рынок?

27 апреля 2022 года нами получен патент, в настоящее время направлены документы для регистрации в Минцифры. После регистрации появится обоснование для выхода на внешний рынок.

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

На базе платформы создается единая экосистема мониторинга всей цепочки поставки нефтепродуктов от завода на нефтебазы компании и в итоге до конечного пользователя на АЗС.

На Череповецком металлургическом комбинате запущено решение на базе машинного обучения для оптимизации работы Агрегата непрерывного горячего цинкования №4 (АНГЦ-4). Решение, получившее название «Ангелина», позволило уйти от человеческого фактора и за время эксплуатации уже принесло экономический эффект более 100 млн руб. О построении решения рассказывает Светлана Потапова, директор ООО «Северсталь Диджитал» и номинант на премию Data Award.

— В прошлом году «Северсталь» стала лауреатом Data Award за оптимизацию работы листопрокатного стана 5000. Каковы итоги того проекта? Насколько были достигнуты планы?

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

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

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

— Исходя из чего был выбран АНГЦ-4?

Агрегат непрерывного горячего цинкования №4 расположен в производстве плоского проката, которое является одним из флагманов цифровизации на ЧерМК. Там скоростью непрерывно-травильного агрегата №3 уже успешно управляет наше решение на основе искусственного интеллекта, на двух других агрегатах цинкования модели способствуют улучшению качества нанесения цинкового покрытия и экономии цинка. Поэтому этот проект – логичное продолжение начатого ранее перехода на цифровое управление ключевыми агрегатами. Они достаточно автоматизированы, что позволяет нам собирать нужный объем данных для анализа и осуществлять прямое управление от моделей. Также при принятии решения о старте разработки мы преследовали актуальную на тот момент бизнес-цель по увеличению производительности агрегата.

— В чем принципиальное отличие этого проекта, например, от прокатного стана 5000? В чем его сложность?

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

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

Уникальность решений и максимизация эффектов, действительно, зависят от возможности кастомизации, учета особенностей агрегата и технологического процесса. Однако при проектировании архитектуры решения и в разработке мы активно используем типовые для нас компоненты и накопленные наработки. К примеру, в быстром запуске цифровых решений нам помогает библиотека собственной разработки Typed Blocks, которую мы выложили в открытый доступ на GitHub. В основе библиотеки лежит event-driven подход, благодаря чему решения удобно дополнять и масштабировать в зависимости от целей проекта и можно собрать приложение, как конструктор.

— В чем заключались проблемы АНГЦ-4, какие задачи требовалось решить?

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

— Какие технологии использовали?

Решение построено на нашем озере данных. Сбор данных с источников осуществляется с помощью NiFi и сервисов собственной разработки на Java. В качестве шины данных используется Kafka, для долгосрочного хранения данных – Hadoop. Решение написано на языке Рython и обернуто в docker-контейнер, оркестрация организована в Kubernetes.

— Что собой представляет созданное решение, каковы его возможности?

Решение, получившее название «Ангелина», сочетает в себе модели на основе правил технологии, физического моделирования, машинного обучения, а также модели регулирования с обратной связью.

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

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

— Какие сложности возникали?

При переходе на автоматическое управление скоростью мы выявили ряд недостатков в существующей системе управления нагревом, приводящих к потерям производительности. Поэтому приняли решение дополнительно разработать модель управления нагревом для поддержания заданной температуры полосы и стабильности процесса. Для этого была реализована модель управления нагревом в камере безокислительного нагрева печи термохимического обжига. Управление мощностью камеры реализовано на основе физической модели тепловых процессов, подхода Model Predictive Control (MPC) для расчета управления и подхода Moving Horizon Estimation (MHE) для идентификации параметров физической модели.

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

— Насколько хорошо решение воспринял персонал?

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

— Часто компании очеловечивают искусственный интеллект, чтобы было проще воспринимать его рекомендации, и дают решениям человеческие имена. Систему назвали «Ангелина» из-за этого?

Эта традиция пошла от «Евы» – нашей первой нейросети для классификации дефектов металлопроката, названной так с отсылкой к библейскому персонажу. Некоторые последующие модели тоже получили свои имена. Например, модель «Аделина», которая задает скорость управления НТА-3, названа так в честь математика Ады Лавлейс, известной тем, что создала описание вычислительной машины и составила первую в мире программу для этой машины. «Ангелина» так названа из-за созвучия с аббревиатурой агрегата АНГЦ-4. Количество решений неизменно растет, дать имена всем будет непросто, но некоторые приживаются и используются.

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

Производительность АНГЦ-4 за три месяца увеличилась на 3,4%. Ввиду сложных экономических условий в первой половине 2022 года загрузка агрегата несколько снижалась, но это не сказалось на качестве работы модели и частоте ее использования операторами. Даже с учетом сниженной загрузки экономический эффект за время эксплуатации решения составил более 100 млн руб. Автоматизированная система не только существенно ускоряет производительность агрегата, но и повышает комфорт работы операторов, передавая часть рутинных операций цифровым инструментам.

— В чем роль этого проекта для бизнеса?

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

— А что дальше? Каковы ближайшие планы?

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

Снижение количества ДТП и связанное с этим благоустройство улично-дорожной сети всегда являлись приоритетной целью для всех регионов. В последнее время с появлением новых аналитических возможностей эта работа основывается на объективных данных и потому приобретает все более осмысленный и логичный вид. В Удмуртской Республике создали геоаналитическую систему, с помощью которой анализируют причины ДТП и факторы, влияющие на них, а также проводят мероприятия по снижению аварийности. О реализации этого проекта рассказывает Тимур Меджитов, министр цифрового развития Удмуртской Республики и номинант на премию Data Award.

— Какова история проекта? Как пришли к его реализации?

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

В мировой практике есть примеры эффективного снижении смертности от ДТП до показателя 3-5 погибших на 100 тыс. населения. В Удмуртской Республике на 2021 год наблюдалось 9,6 погибших на 100 тыс. населения. Очевидно, это число нужно было снижать, и важную роль в этом должны играть результаты анализа данных и прогнозирования ДТП.

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

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

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

— Как была сформулирована цель проекта?

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

— Как была выстроена работа, из каких этапов она состояла?

Конечно же, мы начали со сбора и систематизации данных. Следом был проведен анализ данных, а также прогнозирование количества ДТП и тяжести их последствий. Анализ включал оценку влияния на интенсивность ДТП множества факторов: временной фактор (динамика по годам, сезонность, влияние дня недели, динамика в течение дня), территориальный фактор (место ДТП, категории дорог и улиц), видовой фактор (выявление наиболее значимых типов ДТП), факторы инфраструктуры (объекты и недостатки УДС, освещенность, состояние погоды и проезжей части, наличие камер фотовидеофиксации), человеческий фактор (водительский стаж, степень опьянения, использование ремня безопасности и детского сидения, нарушение ПДД), технический фактор (тип транспортного средства, положение руля, тип привода, год выпуска, марка и модель, неисправности).

Следующий очевидный шаг – выявление мест концентрации ДТП. Для этого был реализован интеллектуальный алгоритм кластеризации (иерархический метод). В работе алгоритма используются ограничения по определению мест концентрации ДТП, которые предполагают выявление в городе зон с радиусом в 200 м, а на межмуниципальных дорогах – до 1 км. Затем мы построили профили мест концентрации ДТП. Они состоят из сводных характеристик места, рассчитанных на основе информации о совершенных в данном участке аварий.

Благодаря этому удалось сформировать список рекомендуемых мероприятий по снижению аварийности на местах концентрации ДТП. Для создания такого списка используются «Методические рекомендации по выбору эффективных некапиталоемких мероприятий по снижению аварийности…» (Росавтодор ОДМ 218.6.025-2017). Предложенные в рекомендациях мероприятия с использованием разработанной нами экспертной системой автоматически соотносятся с построенными профилями мест концентрации ДТП, и в результате появляется список наиболее эффективных мероприятий.

На заключительном этапе была проведена визуализация результатов анализа в виде тепловой карты ДТП.

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

В качестве исходных данных использовались публичные данные о ДТП в Удмуртской Республике в период 2015-2022 годы, полученные с сайта Госавтоинспекции stat.gibdd.ru.

При разработке системы применён язык программирования Python (библиотеки pandas, sklearn, xmltodict, numpy, matplotlib), среда разработки pyCharm Community, база данных PostgreSQL и облачная BI-система Yandex DataLens. С помощью фреймворков языка Python и среды разработки PyCharm Community разработан механизм, преобразующий входные данные в удобный для исследования вид. Обработанные данные хранятся в базе данных PostgreSQL, а Yandex DataLens позволяет визуализировать преобразованные данные.

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

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

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

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

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

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

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

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

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

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

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

На текущий момент реализованы лишь несколько из предложенных мероприятий по снижению аварийности на ряде мест их концентрации, однако это позволило полностью избавиться от аварийности на данных участках дорог. Общее количество ДТП в 2022 году на территории Удмуртской Республики снизилось на 8,8%, а количество пострадавших – на 10%. Мы считаем эти показатели значительными.

— А какие эффекты ожидаются в дальнейшем?

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

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

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

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

Платформа «N3.Аналитика» играет важную роль в рамках федерального проекта «Инцидент №38», призванного обеспечить качество сервиса «Запись на прием к врачу». О том, как анализ ошибок помогает исправлению проблем, рассказывает Яна Зверева, руководитель направления «N3.Аналитика» компании «Нетрика Медицина» и номинант на премию Data Award.

— Какова история вашего участия в проекте «Инцидент №38»?

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

В 2022 году Минцифры проверило качество работы сервиса «Запись на прием к врачу» через ЕПГУ. Результатом стало выявление технических и организационных ошибок, совершаемых при оказании услуги. По итогам проверки были составлены списки регионов с наибольшим и наименьшим количеством ошибок по этому показателю.

В сентябре 2022 года для решения возникающих проблем при записи пациентов с портала ЕПГУ был запущен федеральный проект «Инцидент №38». Он призван помочь в исправлении организационных и технических ошибок. В регионах, где внедрена платформа «N3.Аналитика», анализ проблем и выявление причин были выполнены с ее помощью.

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

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

На базе «N3.Аналитика» разработан инструмент – программный робот, который помогает выполнять оперативный анализ организационных ошибок по доступности свободной записи на прием к врачу. Например, можно посмотреть данные – сколько талонов к терапевту было доступно пациентам в 10:00, сколько из них было предоставлено к записи на следующий день. Таким образом, специалистами компании разработана методология массовой выгрузки и анализа ошибок свободных записей к врачам.

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

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

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

— Как насчет визуализации данных?

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

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

— Вы говорите об «ошибках при записи к врачу». Что они собой представляют?

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

Ошибки, которые происходят в процессе взаимодействия, мы бы классифицировали следующим образом. Первая группа – технические ошибки. Например, сервис прикрепления территориального фонда обязательного медицинского страхования (ТФОМС) распознал пациента, а в информационной системе медицинской организации нет данных о таком пациенте. Причин отсутствия данных может быть несколько: пациент прибыл из другого региона и его данные еще не поступили, при регистрации были допущены ошибки. Вторая группа – организационные ошибки. Бывает, что все информационные системы отработали корректно, но результат не соответствует нормам. Такое возможно, например, если медицинская организация в своем расписании не предоставила для записи ни одного врача-невролога. Или в течение 14 дней нет ни одного талона к оториноларингологу. Еще одна группа – инфраструктурные проблемы, которые не связаны с работой информационных систем. Например, недоступны каналы связи, или возникли проблемы с центром обработки данных. Наконец, ситуационные ошибки, которые нередко возникают при записи: пока один пользователь на ЕПГУ выбирал удобный для себя талон к врачу, другой пациент позвонил в контакт-центр и успел записаться на этот же самый талон. Поскольку запись двух пациентов на одно и то же время не допускается, первый пользователь получит на ЕПГУ информацию об ошибке в записи, и ему придется выбирать другую дату и время талона.

— С чем эффективнее всего удается бороться?

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

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

Здесь мы проделали большую работу вручную. Мы выбрали всех пользователей портала с такой проблемой, направили их данные на проверку в ТФОМСы, где их проверили по базе, идентифицировали с указанием допущенных ошибок при регистрации. Сделав аналитику, мы предложили проверять таких пациентов по другим дополнительным ключам – например, по СНИЛС. В результате количество ошибок сократилось на 20-30%.

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

Наша разработка – региональная подсистема «N3.Запись на прием к врачу» логирует данные федеральных, региональных запросов и ответов. Она выступает в качестве источника данных. Информационные системы медицинских организаций предоставляют через интеграционные сервисы сведения по доступному расписанию для записи на прием к врачу. Подсистема «N3.Аналитика» получает эти данные, выполняет ETL-преобразования (раскладывает в структуры, пригодные для анализа), визуализирует в виде отчетов и дашбордов.

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

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

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

На основании отчетов, предоставляемых платформой «N3.Аналитика», специалисты МИАЦ в регионах выявили и устранили часто повторяющиеся ошибки при записи пациентов. И действительно, отмечено существенное снижение технических и ряда организационных ошибок. Как следствие, произошло повышение доступности записи на прием к врачу во всех регионах, внедривших нашу систему. Средний показатель доли успешных записей к врачу по регионам к началу февраля 2023 года вырос на 20%, положительная динамика продолжается.

В данный момент решение в рамках федерального проекта «Инцидент №38» развернуто в 11 регионах России: в Санкт-Петербурге, Кемерово, Ставропольском, Забайкальском, Хабаровском, Краснодарском краях, Мурманской, Ленинградской, Архангельской, Курской областях, а также в республике Калмыкия. Продолжается работа по внедрению решения в других регионах, где уже установлена и работает платформа «N3.Аналитика».

— Есть ли целевой показатель доли успешных записей?

В соответствии с установленными Министерством здравоохранения нормативами, 70% записей на прием к врачу должны быть успешными. Оставшиеся 30% отводится на возможные ошибки, которые делятся в следующем соотношении: допускается не более 10% технических ошибок, а остальные 20% – организационные ошибки. Хотелось бы отметить, что в начале нашей работы статистика была совсем иной: мы наблюдали в некоторых регионах около 70% технических ошибок, а сегодня – порядка 20-40%. Мы продолжаем эту работу, и я полагаю, что к нужному показателю выйдем к лету 2023 года. Делать такой прогноз нам позволяет именно аналитическая система.

— Может ли быть показатель 100%, и что для этого нужно?

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

— Как вы сами оцениваете эти результаты? Что удалось хорошо, а что могло бы быть сделано лучше?

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

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

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

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

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

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

— Есть ли планы по развитию созданного решения?

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

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

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

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

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

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

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

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

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

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

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

С одной стороны, создаваемая платформа должна была решить задачи аналитиков и владельцев-продукта. Это ускорение проверки маркетинговых гипотез – от постановки гипотезы владельцем продукта до результатов A/B-тестов, ускорение оптимизации целевой аудитории, уменьшение времени на объяснение ожидаемых результатов и сравнение плана с фактом. С другой стороны, требовалось решить и задачи бизнес-заказчиков: объяснение причин принятия покупателем решения о покупке и объяснение успеха или проигрыша маркетингового промо.

При первом подходе к решению мы обратили внимание, что причинно-следственный анализ популярен в сферах, где бизнес близко соприкасается с результатами моделей машинного обучения. Многие даже используют фразу «Корреляция не подразумевает причинно-следственной связи» (в оригинале – «Correlation doesn't imply causation»). Однако практическое применение таких подходов минимально. На рынке есть библиотеки на Python и R для регрессионного анализа, позволяющие реализовать четыре основных причины отклика покупателя: обратная причинность (анализ корреляций); анализ пропущенных переменных; анализ смещений в выборках, которые были в обучении и фактических данных пользователя перед отправкой предложения; анализ ошибок при измерении данных – например, если пользователь неправильно указал свои данные.

Но нам было этого недостаточно. Во-первых, все эти анализы были сложны для понимания. Чтобы объяснить бизнес-заказчику результаты по этим методам, его необходимо обучать. Бизнес же, как известно, хочет получать ответы быстро и на том языке, который он понимает. Во-вторых, использование существующих методов требует жестко определенного плана, где каждое маркетинговое промо должно проверять определенное влияние, все должно проходить через A/B-тесты. Как мы знаем, если хочешь выжить – меняйся быстро.

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

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

Платформа позволяет пользователям в web-интерфейсе совершать ряд действий. Она дает возможность автоматически использовать и строить скоринговые процессы над пользователями, причем использовать можно все модели машинного обучения из «зоопарка моделей» нашей компании. Важно, что это процесс drag&drop или, как это сейчас модно называть, no-code: пользователь просто выбирает из списка нужную модель и перетаскивает ее на рабочее поле. Блоки активны и могут взаимодействовать друг с другом.

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

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

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

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

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

Для работы используются данные программы лояльности, объединенные в нашем проекте Customer360. Само решение выстроено в «Яндекс.Облаке» (PySpark, GreenPlum, Linux) и реализовано на Python.

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

По итогам 2022 года втрое ускорено тестирование маркетинговых промо (квартал к кварталу). Произошло увеличение коэффициента возврата маркетинговых инвестиций на 30%. Маркетинговые промо стали стабильнее, с IV квартала 2022 года у нас уже не было отрицательных промо.

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

- А чего можно ожидать в обозримом будущем?

Мы ожидаем увеличения влияния проекта на EBITDA компании: затрат на промо будет меньше, а эффект должен быть больше. Как минимум, должны заметно улучшиться прошлогодние результаты, так как проект был интегрирован в процессы в конце III квартала 2022 года, а полноценно запущен в конце 2022 – начале 2023 года.

- Что получилось особенно удачным, а над чем еще можно работать?

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

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

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

Наша платформа позволит компании получить преимущество не только за счет рекомендаций товара, но и обеспечив простой доступ к инсайтам над данными покупателей. Это решит очень большое количество проблем. Самое главное – знание инсайтов позволяет выстраивать коммуникации и изменения в товаре, получая постоянные ответы на вопросы «Почему?».

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

Другое открытие заключалось в том, что внутри сегмента «Покупатель с ребенком» есть девушки, которые используют детское пюре как перекус. Ответом на него стала организация в магазинах «Магнит Go» прикассового пространства с пюре.

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

- Что было самым сложным, какие уроки вы извлекли из реализации этого проекта?

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

Считаю, что основные уроки нас еще ждут.

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

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

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

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

— В чем суть решаемой вами задачи?

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

— Как приступили к решению?

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

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

— В этом случае на помощь тоже приходит машинное обучение?

Да, мы построили модель, которая предсказывает, насколько удовлетворен клиент, исходя из его фактического опыта взаимодействия с банком. Эта модель получила название Smart RTFB (Smart Real Time Feedback).

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

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

— А как вы оценили соответствие предсказаний реальному положению дел?

Мы проводили количественные исследования клиентов и задавали им вопросы относительно их удовлетворенности обслуживания в банке. Более 90% ответов клиентов совпали с предсказанием модели.

— Итак, вы узнали степень удовлетворенности клиентов…

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

Далее мы убедились, что в каждой группе у клиентов, у которых нет жалоб и низких оценок, чистый операционный доход (ЧОД) растет. После этого проверили гипотезу о том, что жалоба и низкая оценка являются тем триггером, после которого ЧОД падает. Гипотеза подтвердилась.

Наконец, мы взяли временные ряды ЧОД клиентов с негативом и без него, и сравнили их. Получилась определенная «дельта» между временными рядами. Эта разница и составляет тот недополученный доход, который в случае образования жалобы или негатива имеет банк.

— Что «под капотом»? На какой математике базируется решение?

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

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

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

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

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

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

— Пытались ли оценить финансовый эффект от новых знаний?

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

— Каково значение этого проекта?

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

Кроме того, разработанная модель Smart RTFB позволила получить больше знаний о том, как к нам относятся все наши клиенты, без исключения.

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

На текущий момент прорабатывается встраивание модели в общий контур работы с негативными сценариями (комплексная система компенсаций). Дополнительно мы встроим модель в общую систему замеров удовлетворенности, а в дальнейшем, возможно, откажемся от ряда опросов, которые мы направляем клиентам.

— Дорогу каким новым инициативам это может открыть?

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

Создание и внедрение собственной аналитической платформы «всё в одном» создало в компании SberDevices возможности для перехода к модели data-driven. Проект был начат в конце 2021 года с целью оптимизации затрат на управление данными и аналитику и запуска новых сценариев применения данных для развития бизнеса компании. В феврале прошлого года он превратился в антикризисный с приоритетной целью срочной миграции с иностранных решений. О реализации проекта и полученных в результате возможностях рассказывает Андрей Евтихов, управляющий директор SberDevices и номинант на премию Data Award.

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

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

Следующий вопрос касался снижения будущих затрат на все типы решений для управления данными. Запланированный рост собираемых объемов данных на 2022-2023 годы приводил к значительному нелинейному росту затрат.

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

— Главной целью создания аналитической платформы вы называете переход к data-driven компании. Что вы понимаете под data-driven применительно к SberDevices? И почему пока компанию таковой нельзя назвать?

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

На данный момент SberDevices находится в процессе перехода к полной data-driven организации. Как минимум, нам требуется накопление исторических данных для обучения точных аналитических моделей для прогнозов и дальнейшее развитие системы A/B-экспериментов, накопление практического опыта применения конкретных продуктовых показателей для принятия объективных и эффективных решений. Важна дальнейшая демократизация инструментов аналитики для расширения возможностей их использования со стороны тимлидов, руководителей команд и подразделений, руководителей старшего уровня. Внедрение подходов data-driven идет последовательно для отдельных продуктов, ожидается полный их охват до конца 2023 года.

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

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

— Что требовалось реализовать в ходе проекта?

С технической точки зрения было необходимо подключить к единому хранилищу данных все источники данных, реализовать интеграции с потребителями обработанных данных. При этом требовалось обеспечить хранение и возможности использования «по запросу» всех собранных сырых данных в течении как минимум пяти лет с учетом запланированного роста объемов собираемых данных. Еще одна важная задача – создание аналитических витрин для всех продуктов (по состоянию на момент старта проекта их было более 60) и их поддержка в актуальном состоянии. И, конечно, возможность проведения аналитики за любой период до миграции на новое решение. Это подразумевало бесшовную интеграцию исторических данных из заменяемых систем с «новыми» данными

— Объем работ велик. В какой последовательности и в какие сроки планировалась миграция?

Плановые сроки миграции на старте проекта были оценены в 12 месяцев. Разработка и внедрение платформы осуществлялись внутренними ресурсами компании.

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

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

— В марте проект стал «антикризисным». Как это повлияло на его реализацию, что изменилось?

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

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

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

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

— Какие решения были выбраны и почему?

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

В итоге сбор данных с источников осуществляется с помощью собственных продуктов Device+Mobile DataSDK и DataAPI. Основными решениями, используемыми для построения платформы данных, стали Kafka – для доставки потоковых данных с источников, Hadoop и S3 – для хранения данных, Spark и Airflow – для обработки данных, Postgres и ClickHouse – для создания витрин данных и отчетности, Metabase, Grafana и Superset – для визуализации, Elastic – для поиска, Jupyterhub – для исследования данных.

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

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

Стоит отметить автоматизированное выявление объектов, требующих оптимизации и исправления (ETL-процедуры, представления, физические таблицы, аналитические витрины, ad-hoc запросы к данными), а также отслеживание отклонений от среднего времени выполнения для регулярных ETL-процедур и времени обновления аналитических витрин. Широко изучаются показатели использования платформы со стороны пользователей, в том числе показатели аудитории самой платформы в разрезе сотрудников отдельных продуктов и подразделений.

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

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

— Каких результатов удалось достичь за 2022 год? Что можете считать самым важным?

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

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

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

— А каких эффектов еще можно ожидать?

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

Кроме того, ожидаем рост показателей юнит-экономики продуктов за счет использования «умных» рекомендаций типа cross-sale, up-sale, down-sale. Это должно привести к ускорению роста среднего чека и частоты покупок с помощью наших умных устройств.

— Пытаетесь ли вы оценивать финансовые эффекты? Сколько удалось сэкономить и заработать?

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

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

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

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

— Каковы направления развития платформы? И какие возможности она открывает в будущем?

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

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

Все собираемые данные будут соответствовать критериям ML-ready (адаптация массивов данных для использования в моделях машинного обучения). Это позволит нам значительно улучшить результаты работы аналитических моделей и вывести «мозг» нашей компании на новый уровень интеллектуальной поддержки нашего бизнеса.

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

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

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

Портфель продуктов и услуг Сбера достаточно велик и разнообразен. Каждый продукт довольно сложен для изучения, поэтому, формируя группы операторов, мы разделяем их по знанию конкретных продуктов банка. Это сильно усложняет задачу маршрутизации: классическое «тональное» (DTMF) меню будет для клиента слишком сложным и объемным, а при общении с голосовым ассистентом клиенты могут неверно сформулировать вопрос, что повлечет за собой некорректное распределение вызова. Также в 10% случаев клиенты напрямую просят подключить оператора либо молчат.

- Почему это важно для вас?

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

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

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

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

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

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

- Как была поставлена задача?

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

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

- На каких технологиях построено решение?

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

Данные для сервиса поставляются в потоковом режиме из Apache Hadoop. Обработка потоковых данных реализована на фреймворке Apache Flink, который преобразует их в триггеры, влияющие на маршрутизацию, и затем сохраняет в NoSQL СУБД Cassandra.

Ансамбль из двух AI-моделей (линейная регрессия и нейросеть) исполняется в банковской среде MEF. Результат классификации затем через брокер сообщений Kafka отправляется в интеграционный тракт с платформой IVR контакт-центра.

- Какой математический аппарат используется?

При создании сервиса большое внимание мы уделили определению цели для маршрутизации звонка, по которой далее будет обучаться AI-модель. Мы разметили пул звонков в контакт-центре за прошедший год, в результате чего появились порядка 60 проблематик, которые легли в основу целевой модели. Для корректного их предсказания нам пришлось интегрировать нашу рекомендательную систему с большим количеством источников данных, среди которых системы дистанционно-банковского обслуживания, сайт Сбера, CRM-системы, данные по транзакциям, уведомлениям, получаемым клиентом, системы service desk, обращения в контакт-центр и пр.

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

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

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

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

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

Сервис позволяет существенно экономить на содержании контакт-центра: за счет короткого IVR экономия на телефонном трафике составляет 1,3 млн минут в год.

Кроме того, снижается нагрузка на контакт-центр: за прошлый год за счет более точной маршрутизации мы разгрузили 88 операторов, что в свою очередь позволило снизить стоимость обслуживания клиентов на 6%. А для наших клиентов за 2022 год это вылилось в экономию 7 лет рабочего времени.

- В каком направлении продолжит развиваться платформа?

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

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