Статьи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важнейшую роль в обеспечении хороших финансовых результатах «Сбера» в 2022 году сыграл проект миграции на импортонезависимую CRM, поддерживающую работу всех В2В-компаний группы. Он позволил не только обеспечить непрерывность процессов, но и существенно повысил их качество. О его реализации и результатах рассказывает Евгений Горбачев, руководитель проектов Центра корпоративных решений «Сбера» и номинант на премию Data Award.

— Что стало причиной реализации проекта?

Наша команда представляет Центр корпоративных решений – контакт-центр «Сбера», поддерживающий юридических лиц по банковским продуктам и продуктам компаний нашей группы. У нас на поддержке более 50 дочерних обществ и партнеров банка, а это более 200 продуктов компаний B2B в различных сферах и отраслях, с разными бизнес-моделями и процессами. Мы предоставляем им и сервис, и платформу для организации поддержки продуктов.

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

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

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

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

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

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

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

— Из каких вариантов выбирали?

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

По итогам анализа приняли решение разрабатывать свой софт, а для ускорения реализации использовать open source решение OTRS. В результате мы получили функционал для гибкой настройки бизнес-процессов обработки обращений в офлайн-режиме, а для онлайн-обращений доработали решение OTRS на базе платформы Platform V «Сбера». Нашу разработку мы назвали «Единая CRM для обращений клиентов компаний B2B группы Сбер».

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

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

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

— Что удалось лучше всего?

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

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

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

Если говорить о влиянии на бизнес и клиентский опыт, то омниканальность решения позволяет гибко управлять ресурсами, формировать единую историю взаимоотношений с клиентами, единый клиентский путь, обеспечивать доступность поддержки продукта. Единый профиль клиента позволяет нам развивать продукты, повышать уровень сервиса. После перехода на новую CRM уровень удовлетворенности в части поддержки продуктов компаний В2В группы «Сбер» вырос с 74,3% до 81,1%. И мы не останавливаемся на достигнутом.

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

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

— А что говорит персонал?

Удобный интерфейс единого рабочего места позволяет минимизировать трудозатраты наших операторов. По проведенным опросам, удовлетворенность рабочим местом по 10-ти бальной шкале выросла и сейчас достигла 8,5-8,6 баллов.

— Какими финансовыми эффектами можете похвастаться?

Благодаря автоматизации и интеграции с внешними системами сокращено время обработки обращений по всем каналам с 6,2 до 4,2 минут. При объеме в 400 тыс. обращений в месяц это дает экономию компаниям группы в 150 млн руб. в год. Кроме того, как и планировали, произошло сокращение затрат на доработки.

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

Уже к началу второго квартала 2022 года более 700 сотрудников из 30 компаний B2B группы «Сбер» подключились к работе в новой CRM. В единой системе сотрудники увидели профиль клиента и его запросы по всем продуктам компаний. На основе аналитики по запросам клиентов можно предугадывать их потребности и превентивно предлагать новые продукты и услуги.

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

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

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

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

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

Визуализация – основа быстрого принятия решений на основе даже самых сложных данных. В компании Luxms разработали универсальную переносимую систему BI-аналитики для визуализации больших данных на любых пользовательских устройствах. О ее построении рассказывает Дмитрий Дорофеев, главный конструктор ГК Luxms и номинант на премию Data Award.

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

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

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

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

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

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

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

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

— В чем инновационность решения?

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

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

Основные идеи и подход описаны в нашей научной статье в журнале Transactions of the ACM.

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

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

— Что вы считаете главным достижением, чем гордитесь?

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

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

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

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

— Где уже нашло применение решение? Насколько оно востребовано?

Наша платформа позволяет компаниям контролировать процессы, оптимизировать затраты и повысить эффективность бизнеса. Мы уже успешно реализовали проекты в таких компаниях, как ОАО «РЖД», ПАО «Газпромнефть», НМИЦ им. В.А. Алмазова, а также в двух крупных коммерческих банках и в федеральных операторах сотовой и фиксированной связи. Клиентская база продолжает расти: только за прошлый год нами был выигран ряд крупных тендеров и заключены контракты с ведущими компаниями страны. Банк ПАО «ВТБ», АО «Почта России», АО «Открытие Брокер», ПАО «Россети Северо-Запад» приобрели лицензии Luxms BI в 2022 году.

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

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

— В чем роль решения для российского рынка?

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

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

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

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

Миграция и оптимизация аналитических ландшафтов

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

По словам Вадима Уланова, директора по данным компании «ВсеИнструменты.ру», на тот момент в ландшафте аналитики царил «зоопарк» технологий: PHP, Oracle, PostgreSQL, Golden Gate, Python, ClickHouse, PowerBI и пр. Последний рефакторинг кода проводился более трех лет назад, за это время многие из тех, кто разрабатывал процедуры для хранилища данных, покинули компанию. В результате образовалось значительное количество унаследованных программных модулей, которые были плохо документированы и практически не поддерживались. Их работа была нестабильной (сбои случались часто), поэтому исправления в них приходилось вносить регулярно.

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

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

В компании «ЦЕМРОС» (ранее «Евроцемент Груп») сейчас заканчивается проект перехода с прежней системы управления мастер-данными (MDM) на новую — его планируется завершить к апрелю. Как рассказали Илья Залозных, начальник отдела НСИ департамента информационно-цифровых технологий и архитектуры компании «ЦЕМРОС», и Елена Подгайная, руководитель проектов компании SOFROS, прежде в холдинге использовали решение «Парус» в качестве единой ERP-системы и разработанную своими руками систему MDM. К моменту начала проекта назрела необходимость существенно расширить ее функционал, но стоимость доработки была слишком велика. Кроме того, много сложностей возникало из-за того, что данные справочника материально-технических ресурсов были нечетко классифицированы, неточны или неполны, причем настолько, что однозначно идентифицировать многие позиции справочника было невозможно. Наконец, записи в справочниках нередко дублировались, что затрудняло слаженное функционирование информационных систем и подразделений компании. Если учесть, что число позиций в справочниках НСИ достигало 500 тыс., стало очевидно, что без перехода на новую MDM-систему накопившиеся проблемы решить не удастся.

Было решено переходить на новую систему на базе продукта «1С:MDM». Для ее интеграции с системами «Парус» и «1С:CRM» внедрили интеграционную шину DATAREON ESB.

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

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

Рекомендации на основе лучших практик

Как привлечь внимание бизнеса к повышению качества данных? Для этого надо понять, что качество данных дает бизнесу, считает Андрей Трянин, начальник управления методологии и контроля работы с данными компании X5 Retail Group. Основываясь на этой идее, он и его коллеги решили разделить понятия технического качества данных и их бизнес-качества.

Андрей Трянин: «Зачастую бизнес пытается решить свои проблемы на уровне процессов и людей, но не обращает внимания на слой данных»

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

Предметно заниматься бизнес-качеством данных в X5 Retail Group начали с декабря. Проведенная работа уже дала вполне заметный экономический эффект.

«Мы подтвердили гипотезу, и эффект от внедрения изменений оценивается в 'скромные' 50 млн руб. — отмечает Трянин. — Для компании это немного, но для моей команды это сумма средств на два-три года».

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

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

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

Евгений Виноградов: «Решением проблем с качеством данных может стать формирование документа SLA»

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

«Дело осталось за малым — добиться того, чтобы зафиксированные в SLA договоренности соблюдались», — добавляет Виноградов.

Свой подход к обеспечению качества данных нашли в «М.Видео-Эльдорадо». Как рассказал Алексей Точилов, руководитель продукта Data Governance, в компании в силу исторических причин развиваются два хранилища данных — корпоративное и аналитическое. Они подчиняются разным департаментам, выстроены на базе разных технологических стеков, их сопровождают и поддерживают разные команды. До недавнего времени требования бизнес-заказчиков к данным в разных хранилищах формировались различным образом и проверки качества данных были реализованы по-разному. Неудивительно, что в некоторых случаях возникали расхождения в данных. Немало сложностей возникало и тогда, когда приходилось переносить отдельные активы данных из одного хранилища в другое: могли появляться дополнительные требования, обнаружить которые без выстроенной процедуры их отслеживания было проблематично.

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

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

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

Нередко проблемы с качеством данных возникают из-за того, что не удается снизить их сложность. По словам Федора Медведева, директора департамента компании Naumen, отвечающего за цифровые сервисы и решения в образовании, помочь справиться с этой проблемой могут системы корпоративного поиска. В частности, поисковая система Naumen Enterprise Search, обладающая встроенными механизмами машинного обучения и средствами обработки запросов на естественном языке (Natural Language Processing, NLP), интегрирует разнородные источники. Система поиска использует единое окно доступа к данным, причем не только к внутренним, но и к внешним.

Внедренная в компании «Газпром Нефть» поисковая система Naumen сегодня охватывает около 50 тыс. пользователей, 50 источников данных и 30 млн документов, обрабатывая около 2,5 тыс. запросов ежедневно. В компании «Мосэнергосбыт» на основе такого же продукта выстроен автоматический мониторинг законодательства в области электроэнергетики: система опрашивает источники (внешние сайты) и ищет информацию о подготовке новых изменений в документах регуляторов. Кроме того, система помогает анализировать найденные данные, отслеживать упомянутые в документах сроки и пр. Что важно, она обеспечивает обсуждение найденных документов внутри организации (задействованы более 50 подразделений) и сведение различных позиций к единому мнению.

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

Решить проблему нехватки ИТ-кадров для развития цифровой экономики взялись создатели AI Talent Hub, запущенного ИТМО и Napoleon IT. Это онлайн-магистратура «Инженерия машинного обучения», с помощью которой планируется подготовить к 2025 году более 700 мидл-специалистов в сфере искусственного интеллекта. О предпринятых шагах и первых полученных результатах рассказывает Дмитрий Ботов, руководитель проекта AI Talent Hub, Data Science Partner компании Napoleon IT, номинант на премию Data Award.

— Как родился этот проект?

Я занимаюсь преподавательской деятельностью уже более 10 лет: создавал и факультативы для одногруппников, и курсы, и образовательные программы. В то же время за моими плечами выстраивание отделов Data Science с нуля в крупных телеком-компаниях. Своими глазами видел, насколько стандартное ИТ-образование отличается от того, что необходимо бизнесу, и как выпускникам вузов тяжело вникнуть в реальные ИТ-процессы после учебы. Поэтому моим основным мотивом пойти в преподавание стало осознание того, что текущая модель ИТ-образования работает совсем не так, как должна. В 2015 году я познакомился с сооснователем компании Napoleon IT Павлом Подкорытовым. Вместе мы сделали совместный курс для студентов бакалавриата по разработке мобильных приложений под Android. Уже позже, в 2021 году, Павел позвал меня в ИТМО — запускать совместную специализацию «Компьютерное зрение» для магистрантов. Именно тогда мы познакомились с первым проректором ИТМО Дарьей Козловой, и она предложила мне сделать «перевернутую» магистратуру.

— Что представляет собой AI Talent Hub?

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

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

— Какие задачи вы ставите перед собой?

У нас амбициозная цель: подготовить к 2025 году более 700 мидл-специалистов в сфере искусственного интеллекта. В 2022 году были набраны первые 109 магистрантов со всей страны. В 2023 году планируется отобрать более 200 кандидатов на магистерскую программу. Сейчас мы стали одной из самых крупных магистерских программ по искусственному интеллекту в России как по числу бюджетных мест, так и по конкурсу на одно место. В 2022 году конкурс составил 4,2 человека на место – на отбор было подано более 430 заявок.

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

Уникальность онлайн-магистратуры AI Talent Hub в том, что это не очередная образовательная программа по искусственному интеллекту с набором разрозненных дисциплин с упором на лекции и лабораторные работы от теоретиков. Это пример перевернутого образования: за два года студенты проходят все этапы создания сервисов машинного обучения, разбираются с «грязными» данными, неполной документацией и технологическим стеком для решения реальных бизнес-задач партнеров проекта. По итогам обучения каждый из студентов создаст свой MVP и защитит его перед представителями бизнеса и экспертами из индустрии. В учебном плане студенты могут выбрать дисциплины по технологическому предпринимательству и управлению ИИ-продуктами.

Обучение происходит полностью онлайн с применением дистанционных цифровых технологий – Zoom, Discord.

— Как выстроена программа? Кто участвует в ее разработке?

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

За первый год работы проекта для развития сообщества мы привлекли десятки партнеров из ведущих ИТ-компаний, которые занимаются разработкой и внедрением решений с искусственным интеллектом – МТС, VK, «Яндекс», «Сбер», «Газпромнефть-Цифровые решения», «Татнефть», Napoleon IT, Huawei и другие. Для образовательных программ российских вузов такое количество партнеров на одной программе подготовки является новаторством.

— Кто является вашей целевой аудиторией?

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

— Какие технологии и направления охвачены программой?

Применяются практически все актуальные для индустрии на сегодняшний момент стеки технологий работы с данными – в зависимости от образовательного курса или проекта от партнеров, в который вовлечены магистранты. От реляционных СУБД до Apache Spark, Hadoop и ClickHouse. Используются инструменты MLOps: ClearML, MLFlow, DVC. Применяются open source библиотеки на Python, а также PyTorch как основной фреймворк для глубокого обучения.

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

Направления (треки) подготовки на программе: инженер по компьютерному зрению, инженер по обработке естественного языка, инженер по рекомендательным системам, MLOps-инженер, инженер по данным (Data Engineer), руководитель продуктовых команд в Data Science (AI Product Manager), инженер в области Data Driven Biotechnology.

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

Магистранты AI Talent Hub вовлечены в более 50 проектов, которые реализуются по реальным задачам компаний-партнеров, либо по инициативным проектам самих студентов (формат «диплом как стартап»). Один из показательных примеров — проведение для компании «Татнефть» обучающего семинара Big Data Workshop «От идеи к продукту» вместе с Передовой инженерной школой ИТМО и компанией Napoleon IT. В его рамках руководители компании вместе со студентами сгенерировали более 150 гипотез по решению задач нефтегазовой отрасли с помощью искусственного интеллекта, 10% из них взяты в работу.

Не менее важным достижением стало развитие комьюнити. Онлайн-сообщество AI Talent Hub насчитывает более 700 специалистов в Data Science различного уровня (от начального уровня до руководителей компаний), заинтересованных в развитии талантливых ребят в области искусственного интеллекта со всей страны. У него есть телеграм-канал, в котором регулярно проводятся прямые эфиры с экспертами в машинном обучении и искусственном интеллекте. Еще один проект – клуб ML Future, созданный студентами онлайн-магистратуры. Каждую неделю в нем выступают приглашенные спикеры и отвечают на вопросы студентов о машинном обучении, карьере и других аспектах их профессиональной деятельности.

Результатом общения партнеров и заказчиков стала «Школа менторов» – онлайн-площадка для обмена опытом и обсуждения вопросов по развитию талантов в сфере Data Science.

– Как проходит обучение на программе?

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

Для студентов доступны более чем 100 курсов по машинному обучению и нейронным сетям, программированию на C++, Python, Java, Scala, Kotlin, технологиям компьютерного зрения и обработке естественного языка, разработке рекомендательных систем, сбору и анализу данных, проектированию интеллектуальных систем, проектированию хранилищ данных и работы с технологиями Big Data (Hadoop, Spark), управлению проектами и продуктами в Data Science, методологии и процессам реализации data driven решений, применению машинного обучения в геномике, химии и биотехнологиях.

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

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

На первом хакатоне по разработке продукта на данных ребята показали отличные результаты: создавали продукты и применяли технологии компьютерного зрения, генеративного искусственного интеллекта, машинного обучения в биотехе и геномике. В результате участники создали более 20 стартапов по разным тематикам. В жюри хакатона присутствовали представители от Комитета по развитию туризма, Комитета по молодежной политике и взаимодействию с общественными организациями, городского-туристического информационного бюро Санкт-Петербурга и высоко оценили разработки участников. Магистранты уже сформировали такие стартапы, как Energy.ai – сервис по увеличению рентабельности электростанций, и Deeploid meta – сервис для анализа метагеномных данных.

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

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

У нас амбициозные планы. К 2024 году планируем, что более 700 талантливых абитуриентов поступят на программы AI Talent Hub на бюджетной или коммерческой основе. Хотим создать более 10 образовательных программ разного уровня: онлайн-магистратуры, дополнительное профессиональное обучение (онлайн-курсы) или микростепени.

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

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

Время руководителя – наиболее ценный ресурс любой компании. Возможность избавить его от рутинных и трудоемких действий по планированию работы сотрудников способна стать серьезным фактором, влияющим на развитие бизнеса. О создании системы автоматизированного планирования «Планер», выполняющей именно эти задачи, рассказывает Александр Кузнецов, руководитель процессного офиса компании White Box Process Management (WBPM), и номинант на премию Data Award.

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

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

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

- Какие были проблемы? Почему это важно?

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

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

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

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

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

Первоначально мы погрузились в процесс судопроизводства, узнали об особенностях работы судов и судебных участков, изучили важные нюансы. Затем с помощью технологии Process Mining определили действия руководителей в процессе планирования, проанализировали их вариативную логику и описали в нотации BPMN 2.0. В ходе исследования соотнесли данные о каждой операции с теми, что хранятся в CRM. Обнаружив их нехватку, изменили структуру базы данных, внеся нужные атрибуты и сущности. Не обошлось и без нормализации данных, а также создания правил их внесения. Иначе было невозможно «пересобрать» верную последовательность этапов: внушительная часть информации не логировалась в системе, а то, что имелось, было сильно «зашумлено».

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

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

- Можете поделиться примерами инсайтов, появившихся в результате использования Process Mining?

Их было достаточно, поделюсь самыми запоминающимися.

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

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

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

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

- Какие принципы соблюдались при создании решения?

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

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

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

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

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

Сервис написан на технологии .Net 7 на языке C#. Взаимодействие с системой происходит через кроссплатформенное WebAPI (Rest).

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

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

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

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

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

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

- Насколько масштабируемым и тиражируемым стал этот опыт?

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

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

- Пытался ли заказчик оценивать финансовый эффект от реализации проекта?

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

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

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

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

- Насколько вообще подобные решения могут быть востребованы рынком?

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

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