Является продолжением предыдущие публикации .
Основная цель публикаций — продемонстрировать возможности R для решения различных «рутинных» задач обработки данных, возникающих в бизнесе.
Основной упор делается на создание полноценного решения для конечного пользователя, а не на фундаментальное решение той или иной проблемы с помощью набора команд в консоли.
Схематический прототип и изделие, сошедшее с конвейера, имеют больше различий, чем сходства.
По тонкой механике R существует огромное количество специализированных блогов, книг, а также github. Но к ним обычно обращаются только после того, как увидят, что решение задачи с помощью R возможно и очень элегантно.
Где все началось В целом исходная ситуация весьма типична для компаний, имеющих хоть какое-то подобие колл-центра, обслуживающего запросы внешних пользователей.
Имеется АТС (в нашем случае несколько территориально разнесенных экземпляров Asterisk версии 13LTS).
Есть информационная система\системы, в которую операторы заносят то, что слышат от пользователей.
И есть куча автоматизированных бизнес-процессов обработки запросов пользователей.
Также существует вертикаль лидерства от руководителя колл-центра до топ-менеджмента, а также смежных отделов, например, маркетинга, которым для стратегического управления требуется резюме того, «как живут люди», как ведут себя KPI и «где бизнес».
двигается.
" И здесь желания и возможности друг друга обнаруживают себя очень слабо.
Если в службе поддержки уже был какой-то генератор отчетов, то в Asterisk изначально не было ничего, кроме логов и cdr. Шаг 1 Мы попытались пойти стандартным путем и рассмотрели существующие инструменты для Asterisk. В первом приближении мы остановились на бесплатных версиях программ:
Стало немного лучше.Ответственные сотрудники наконец смогли подготовить необходимое аналитическое заключение.
Однако качество этой отчетности было очень низким по нескольким причинам:
- Скрипты обработки в asterisk были очень сложными и писались с помощью макросов.
По умолчанию файлы CDR генерируются с упором на минимизацию количества записей.
Поэтому в полученных CDR при «схлопывании» внутренних трансферов и объединении вооружений был потерян ряд важных данных.
И числа А (из-за макросов), и числа В (при объединении вооружений, инициируемых оператором).
- Очереди также не содержат полной информации.
Никаких записей IVR, никакой информации о переводах наружу нет. И еще много чего не хватает.
- Сами программы могут выдавать общепринятую статистику по колл-центрам, но применительно к нашим задачам более половины выдаваемых результатов оказались не очень полезны для бизнеса, поскольку не отвечали на нужные вопросы.
- Бесплатные версии ограничены в функционале + пришлось вручную «допиливать» php, чтобы хотя бы не крашился.
Я пренебрегаю неправильными расчетами длительности ввиду их незначительности (~10%).
Для простоты я связываю это с нашими конкретными настройками звездочки.
- Данные из внешних каталогов и систем прикрепить невозможно.
Все делается вручную в Excel. Например, подавать отчет не по номерам, а по ФИО оператора с учетом графика смен.
- Графического представления нет, а те, что предлагаются в платных версиях, далеки от того, что требуется.
- Различные системы почти всегда давали разные числовые результаты.
Иногда разница достигала сотен процентов.
Очевидно, это было вызвано сложностью вызовов, а также различиями в алгоритмах вычислений, заложенных в программы.
Мы использовали R в качестве инструмента анализа.
По самой своей природе данных не так уж и много.
Несколько тысяч обращений в CHNN дают 1-2 ГБ упакованных записей за год работы.
Для современных ноутбуков это полная ерунда, не говоря уже о серверном оборудовании.
И тут начались интересные вещи.
Даже самый беглый взгляд на различные срезы данных вызывал массу технических вопросов, что привело к настройке звездочек.
- Почему макросы не предоставляют информацию, необходимую для определенных типов разговоров?
- Почему иногда теряются идентификаторы, позволяющие связать трехсторонние сессии, в которых посредником является оператор?
- Почему временные метрики в cdr не всегда соответствуют событиям в реальном времени? Время в IVR не всегда нужно считать полностью (зависит от логики), да и IVR бывают разные.
- Почему очереди не содержат ряд обязательных параметров?
После тщательного изучения данных было решено отказаться от использования cdr (там данные были записаны слишком неполными и недостоверными, а радикального улучшения логики генерации cdr в продакшне никто не надеялся.
Поэтому мы перешли на вызов- модель анализа потоков на основе данных, полученных из журналов очередей (журнала очереди) со следующей логикой:
- реконструировать все события в потоке вызовов, используя идентификаторы основного сеанса и связанных сеансов;
- Прореживаем события, исходя из бизнес-логики расчета kpi (множественный ЗВОНОК НЕТ ОТВЕТА; множественный ВХОД в ОЧЕРЕДЬ в ту же очередь или в другую; ПЕРЕВОД ОТВЕТСТВЕННОГО\СЛЕПОГО ПЕРЕДАЧИ на внешние номера и т.д.);
- На основе сформированных очищенных потоков звонков мы пересчитываем реальную длительность всех событий на основе их временных меток;
- обогащаем обзвон данными из внешних источников, в частности, из графика дежурств операторов, чтобы по номеру оператора получить ФИО;
- Мы получаем «чистый» набор «сырых» данных, из которых уже строим всю необходимую отчетность.
В общем, далее следует автоматическая генерация стандартного набора бизнес-артефактов: дашбордов, отчетов, загрузок (xls, pdf, csv, doc, ppt,.
)
Само рабочее место руководителя колл-центра построено на Shiny. 
Важно, чтобы после такой «чистки» данных можно было сесть за стол с бизнесом и обсудить метрики (KPI) и методику их расчета.
Следует ли засчитывать время пребывания абонента во внутреннем IVR как продолжительность разговора или нет? Следует ли рассматривать CONNECT как последующий немедленный возврат в очередь в качестве ответа оператора или нет? Как разложить присутствие абонента в нескольких очередях на основе KPI операторов и очередей? Как соотнести среднее время ожидания в очереди со временем суток и количеством операторов в смене? Каковы типичные сценарии «оптимизации» для операторов? И много других вопросов.
Самое приятное то, что на все вопросы можно дать четкий и однозначный ответ. Дополнительным преимуществом перехода на анализ событий потока вызовов является возможность изучения сценариев работы колл-центра (process Mining).
По сути, это обратный инжиниринг бизнес-процессов по их следам в журналах колл-центра.
Обнаруживаются любопытные вещи! 
Шаг 3 Переход к анализу событий ОИМ.
В целом это самый универсальный метод, но требует немного большей вычислительной мощности.
После небольшой корректировки логов очереди, для одиночной астериска резкость в анализе AMI пропала, но сохранение их в контексте исторической работы астериска (устранение неполадок) остаётся полезным.
Также работа с AMI обеспечивает независимость от приватных настроек отдельного астериска, что будет актуально при подключении последующих.
Чтобы обеспечить скорость работы с AMI, мы «сбрасываем» в ClickHouse все 151 тип событий с 619 возможными полями.
Послесловие Как многие могут заметить, задача очень специфическая, объемы данных небольшие.
Но это не умаляет важности данной задачи для бизнеса.
Использование R позволило быстро и элегантно решить ее, создав при этом удобные рабочие места для обычных бизнес-пользователей.
И с точки зрения промышленного программирования тоже все ок: упаковка, документирование функций с помощью roxygen, автотесты, логирование, все, что можно покрыть онлайн-проверками и утверждениями.
Теперь, имея прочный фундамент, можно смело переходить к прогнозированию и оперативной аналитике.
Ответ на вопрос «при чем тут гардеробЭ», увы, весьма прозаичен.
Потому что из него вывалились скелеты, которые тщательно прятали операторы колл-центра.
И R+Shiny послужил ключом к его открытию.
Предыдущий пост: Вы уже используете R в бизнесе? Теги: #наука о данных #Интеллектуальный анализ данных #asterisk #Большие данные #r
-
Преимущества Онлайн-Рекламной Кампании
19 Oct, 24 -
Qlean.ru — Сервис Заказа Уборки Дома
19 Oct, 24 -
Создайте Простой Чат В Реальном Времени
19 Oct, 24 -
Как Работает Один Python-Разработчик
19 Oct, 24
