R, Asterisk и платяной шкаф

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


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



    С чего все начиналось


    В целом, начальная ситуация весьма типична для компаний у которых есть хоть какое-либо подобие колл-центр, обслуживающего запросы внешних пользователей. Есть PBX (в нашем случае — несколько географически разнесенных Asterisk инстансов, версия 13LTS). Есть информационная система\системы в которые операторы вносят то, что услышали от пользователей. И есть кипа автоматизированных бизнес-процессов по обработке запросов пользователей.


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


    Если в части сервис деска какой-то генератор отчетов уже был, то у Asterisk изначально ничего кроме логов и cdr не было.


    Шаг №1


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



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


    1. Сценарии обработки в asterisk были весьма сложные и написаны через макросы. Штатно CDR файлы генерируются с упором на минимизацию количества записей. Поэтому в результирующих CDR при "схлопывании" внутренних трансферов и объединения плеч, терялся ряд важных данных. Как A номера (из-за макросов), так и B номера (при объединении плеч, инициированных оператором).
    2. Очереди тоже содержат не полную информацию. Нет записей по IVR, нет информации по трансферу наружу. И еще много чего нет.
    3. Сами программы может и выдают общепринятую статистику по колл-центрам, но применительно к нашим задачам больше половины выводимых результатов были не очень полезны для бизнеса, потому что отвечали не на нужные вопросы.
    4. Бесплатные версии урезаны по функционалу + пришлось еще руками "допиливать" php, чтобы хотя бы не падало. Неправильными подсчетами длительности пренебрегаю, за их незначительностью (~10%). Для простоты списываю это на наши специфические настройки asterisk.
    5. Данные из внешних справочников и систем прицепить нельзя. Все только руками в excel. Например, представить отчет не по номерам, а по ФИО оператора, учитывая график смен.
    6. Нет графического представления, а те, которые предлагаются в платных версиях далеки от того, что требуется.
    7. Разные системы почти всегда давали разные числовые результаты. Иногда разница достигала сотен процентов. Очевидно, что это было вызвано сложностью звонков, а также различиями в алгоритмах расчетов, заложенных в программах.

    Шаг №2


    Взялись за самостоятельный анализ cdr и log файлов. В качестве инструмента анализа использовали R. По самой сути данных не очень много. Несколько тысяч звонков в ЧНН дают в результате 1-2 Гб записей в пакованном виде на год работы. Для современных ноутбуков — это полная ерунда, не говоря уж о серверном оборудовании.


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


    • Почему макросы не выдают нужную информацию при определенных типах разговорах?
    • Почему иногда теряются идентификаторы, позволяющие связать трехстороннии сессии в которых оператор является посредником?
    • Почему временные метрики в cdr не всегда совпадают с реальными временными событиями? Время в IVR не всегда и не в полном объеме надо считать (зависит от логики), да и IVR бывают разные.
    • Почему в очередях нет ряда требуемых параметров?

    Но это только техническая сторона вопроса. После внимательного изучения данных было принято решение отказаться от использования cdr (слишком уж неполные и недостоверные данные там записывались, а радикально дорабатывать логику формирования cdr на продуктиве ни у кого не вызывало оптимизма. Поэтому перешли на модель анализа call-flow по данным, получаемым из лога очередей (queue log) со следующей логикой:


    1. реконструируем все события в рамках call flow, используя идентификаторы первичной сессии и линкованных сессий;
    2. проводим прореживание событий исходя из бизнес-логики расчета kpi (многократные RING NO ANSWER; многократные ENTER QUEUE в эту же очередь или в другую; ATTENDENT TRANSFER\BLIND TRANSFER на внешние номера и пр...);
    3. по выстроенным очищенным call flow пересчитываем реальные длительности всех событий исходя из их временных меток;
    4. обогащаем call-flow данными из внешних источников, в частности, из графика дежурных смен операторов, чтобы из номера оператора получить ФИО;
    5. получаем "чистый" набор "сырых" данных по которым уже строим всю необходимую отчетность.

    call-flow


    В целом, дальше следует автоматическая генерация штатного набор бизнес-артефактов: дашборды, отчеты, выгрузки (xls, pdf, csv, doc, ppt, ...)
    Сам АРМ для начальника колл-центра построен на Shiny.


    dashboard


    Важно, что после такой "чистки" данных можно было сесть за стол с бизнесом и обсудить метрики (KPI) и методику их расчета. Считать ли время пребывания абонентом во внутреннем IVR в длительность звонка или нет? Считать ли CONNECT последующий мгновенный возврат в очередь ответом оператора или нет? Как декомпозировать по KPI операторов и очереденй пребывание абонента в нескольких очередях? Как соотносить среднее время ожидания в очереди со временем суток и количеством операторов в смене? Какие типовые сценарии "оптимизации" у операторов? И масса других вопросов. Самое приятное, что на все вопросы можно дать четкий и однозначный ответ.


    Дополнительным плюсом к переходу на событийный анализ call-flow является возможность изучения сценариев работы колл-центра (process mining). По сути, реверс-инжиниринг бизнес-процессов по их следам в логах колл-центра. Любопытные вещи обнаруживаются!


    process mining


    Шаг №3


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


    Послесловие


    Как многие могут отметить, задача весьма частная, объемы данных невелики. Но от этого, значимость этой задачи для бизнеса никак не уменьшается. Применение же R позволило оперативно и элегантно ее решить, при этом создать удобные АРМ для обычных бизнес-пользователей. И с точки зрения промышленного программирования тоже все ок: пакетирование, документирование функций средствами roxygen, автотесты, логирование, все что можно обложено онлайн проверками и ассертами.


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


    Ответ на вопрос "при чём здесь платяной шкаф?", увы весьма прозаичен. Потому что из него посыпались скелеты, которые тщательно скрывались операторами колл-центра. А R+Shiny послужили ключиком для его открывания.


    Предыдущий пост: А вы уже применяете R в бизнесе?

    • +11
    • 7,8k
    • 4
    Поделиться публикацией

    Похожие публикации

    Комментарии 4
      0
      Картинки аккуратненькие. На чем сделаны, это не plotly?
        0

        Нет, классический ggplot. Когда потом даешь инструмент в руки обычному пользователю избыточный динамизм возвращается бумерангом.
        80% вопросов "шеф, все пропало!" связаны с неловким движением мышки...


        Да и возможностей по визуализации, особенно с учетом расширений, у ggplot куда больше.

          0
          а cel вместо cdr смотрели?
            0

            Как-то уже не особо. В текущей задаче queue log дал практически все, что было нужно. Для полноценного логирования дешевле и проще слушать сокет с AMI событиями, нежели еще одну базейку поднимать и делать постоянный sql update. Шаг №3.


            Собственно говоря, получаем актуальный список событий (а потом разбираем атрибуты команд по соотв. html страницам) в полностью автоматическом режиме, формируем карту событий и атрибутов и на его основе "тупой" парсер весь AMI трафик просто складывает в таблицу с 619 колонками. Для ClickHouse такой объем данных просто фитюлька.


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


            library(rvest)
            ami <- read_html("https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+AMI+Events")
            
            ref <- ami %>% 
              html_nodes(".child-display") %>%
              html_nodes("a") %>%
              html_attr("href")

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

          Самое читаемое