Статьи

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

— Что привело к реализации проекта? Почему потребовалось замещать ETL?

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

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

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

При выборе решения мы основывались на стратегических целях компании по развитию бизнеса. Чтобы определиться с решением, мы разработали комплексный подход по оценке потенциальных решений на базе многих критериев. Конечно, нас интересовала возможность работы с нашими объемами данных, надежность и масштабируемость решения. Очень важна минимизация рисков, связанных с санкциями, и наличие экспертизы в России – это критично для возможности быстро создать команду и не испытывать проблем при разработке нового функционала. К этому можно добавить наличие стабильной поддержки вендора на территории России. С технической точки зрения необходима возможность работы с реляционными и нереляционными источниками данных, наличие готовых коннекторов к различным базам данных – Oracle, PostgreSQL, MS SQL, Vertica, Greenplum, ClickHouse. Наконец, всем важна стоимость внедрения и эксплуатации, а также соответствие требованиям информационной безопасности.

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

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

— Какие рассматривали варианты, что выбрали?

В рамках выбора решения мы рассматривали как технологии open source, так и проприетарные отечественные решения. Изначально в списке было около 12 кандидатов, но по результатам тестов в шорт-листе оказались FormIT и комплекс Kafka +Debezium. По совокупности всех критериев мы выбрали отечественное решение FormIT.

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

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

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

В рамках проекта были развернуты тестовый и продуктивный контуры FormIT. В настоящее время ETL-платформа поддерживает более 1,2 тыс. потоков данных, число которых постоянно возрастает.

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

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

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

— Какие изменения успел почувствовать бизнес?

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

— Какое место занимает проект среди других инициатив, какие возможности открывает?

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

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

— Чем занимается ферма, что привело к необходимости ее цифровизации?

«Бородулинское» – молочная ферма в Свердловской области. На ней содержится 1260 животных черно-пестрой голштинизированной породы, из них порядка 600 дойных коров. По состоянию на 2020 год средний надой фермы не превышал 10,5 тонн молока в сутки, что объективно немного – он может быть гораздо выше. На ней отсутствовал постоянный мониторинг производственных процессов, была низкая управляемость, ферма не имела устойчивости. Совладельцами фермы была поставлена задача поиска решения этих проблем.

— Чего именно хотели добиться?

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

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

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

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

— Каковы инвестиции в этот проект? Какой видится окупаемость проекта?

Инвестиции не превышают 25% от дополнительно полученной за год прибыли по молоку. Они еще не закончены, но получаемые результаты позволяют обосновывать и получать эти инвестиции у собственников. На данный момент нами были проведены инвестиции в систему управления стадом DairyComp305, в систему кормоподготовки и кормораздачи TMR Tracker, в сервисы Dairy Production Analytics (DPA) и Business Scanner компании «АЛАН-ИТ», в климатические датчики, в ошейники Heatime. В данный момент заканчивается подготовка обоснования для инвестиций в систему автоматизации управления климатом, освещением, сбором телеметрии по объемам производства молока.

— Из каких этапов состоял проект, сколько времени на него потребовалось?

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

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

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

— Рассматривались ли какие-либо альтернативы созданию «цифровой фермы»?

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

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

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

— Как изменились бизнес-процессы и принятие решений? За счет чего рост показателей?

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

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

— А были ли благодаря анализу данных инсайты, которых совсем не ожидали?

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

— На какие бизнес-результаты рассчитывали, создавая решение? Как они соотносятся с реальностью?

Мы рассчитывали на увеличение валового надоя молока на 20% за год, а в итоге результат превзошел наши ожидания. Если раньше мы доили на том же стаде около 10-11 тонн молока в сутки, то сейчас надои составляют 17-18 тонн, обеспечив рост прибыли по сырому молоку к показателям 2021 года более чем на 40 млн руб. Остальная экономика на ферме выглядит примерно также.

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

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

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

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

— Как вообще ферма видит свое будущее?

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

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

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

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

Замеры удовлетворенности в Альфа-Банке осуществляются с помощью платформы Voice of Customer (VOC) – собственной разработки, позволяющей запрашивать оценки клиентов в режиме реального времени по итогу взаимодействия с сотрудником или процессом в любом канале. VOC – основная метрика опыта клиента (Customer Experience, CX), используемая в банке. Результаты опросов хранятся в системах банка и представляются руководителям каналов и продуктовых команд в формате автоматизированных дашбордов с разными уровнями детализации.

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

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

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

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

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

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

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

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

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

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

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

У нас огромное количество оценок VOC, дополнительно мы запрашиваем категории негативных и положительных оценок. Они помогают нам верхнеуровнево отслеживать, в каких каналах и продуктах, какие тематики требуют улучшений. Для того, чтобы понимать причины негатива более конкретно, все негативные оценки обзваниваются экспертами отдела по сохранению лояльности (ОСЛК). По итогу звонка заполняется экспертиза – краткое экспертное заключение с описанием причин негатива по заданным параметрам. С начала 2022 года удалось накопить более 150 тыс. экспертиз.

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

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

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

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

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

Улучшение клиентского опыта — это непрерывный процесс, который оказывает влияние на лояльность клиентов в долгосрочной перспективе. Мы внедрили этот процесс, отслеживаем результаты и накапливаем данные. В целом увеличили скорость поиска инсайтов и оперативной передачи информации в бизнес-подразделения для внедрения конкретных улучшений. Сегодня мы можем диагностировать, что мы вернулись к «докризисному» уровню оценки VOC. На текущий момент клиенты чаще ставят более высокие оценки по результатам общения с человеком (персонализированные каналы коммуникаций) и более низкие оценки по роботизированным каналам коммуникаций (голосовой помощник, чат-бот). Средняя доля положительных оценок VOC составляет около 85%

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

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

— Пытались ли оценить финансовый результат проекта?

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

— Какие возможности открыл этот проект Альфа-Банку?

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

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

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

— А может ли этот проект повлиять на рынок в целом?

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

«Сбербанк Факторинг» начал реализацию проекта построения системы управления данными. Решение 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. Первые шаги планируем сделать к лету. До этого будем публиковать статьи о причинно-следственных связях и их поисках с визуализациями из нашего проекта.