- PVSM.RU - https://www.pvsm.ru -
Является продолжением предыдущих публикаций [1]. Основное назначение публикаций — демонстрация возможностей R по решению различных "рутинных" задач по обработке данных, возникающих в бизнесе. Основной акцент ставится на создание законченного решения для конечного пользователя, а не на принципиальное решение частной задачи набором команд в консоли. Схематический прототип и продукт с конвейера имеют больше различий чем сходства.
По тонкой механике R есть огромное количество специализированных блогов, книг, а также github. Но обращаются к ним обычно только после того, как видят, что решение задачи средствами R возможно и весьма элегантно.
В целом, начальная ситуация весьма типична для компаний у которых есть хоть какое-либо подобие колл-центр, обслуживающего запросы внешних пользователей. Есть PBX (в нашем случае — несколько географически разнесенных Asterisk инстансов, версия 13LTS). Есть информационная системасистемы в которые операторы вносят то, что услышали от пользователей. И есть кипа автоматизированных бизнес-процессов по обработке запросов пользователей.
Еще есть вертикаль руководства от руководителя колл-центра до топ-менеджмента, а также смежные подразделения, например, маркетинг, которые для стратегического управления требуют сводку о том "как живет народ", как себя ведут KPI и "куда движется бизнес". И вот тут желания и возможности друг друга находят себя очень слабо.
Если в части сервис деска какой-то генератор отчетов уже был, то у Asterisk изначально ничего кроме логов и cdr не было.
Попробовали пойти по стандартному пути, посмотрели существующие для Asterisk инструменты. В качестве первого приближения остановились на бесплатных версиях программ:
Стало немного лучше. Требуемую аналитическую сводку ответственные сотрудники, наконец, смогли готовить. Однако качество этой отчетности сильно хромало по нескольким причинам:
Взялись за самостоятельный анализ cdr и log файлов. В качестве инструмента анализа использовали R. По самой сути данных не очень много. Несколько тысяч звонков в ЧНН дают в результате 1-2 Гб записей в пакованном виде на год работы. Для современных ноутбуков — это полная ерунда, не говоря уж о серверном оборудовании.
И тут начались интересные вещи. Даже самый беглый взгляд различные срезы данных вызвал массу технически вопросов, приведших к тюнингу астерисков.
Но это только техническая сторона вопроса. После внимательного изучения данных было принято решение отказаться от использования cdr (слишком уж неполные и недостоверные данные там записывались, а радикально дорабатывать логику формирования cdr на продуктиве ни у кого не вызывало оптимизма. Поэтому перешли на модель анализа call-flow по данным, получаемым из лога очередей (queue log) со следующей логикой:
В целом, дальше следует автоматическая генерация штатного набор бизнес-артефактов: дашборды, отчеты, выгрузки (xls, pdf, csv, doc, ppt, ...)
Сам АРМ для начальника колл-центра построен на Shiny.
Важно, что после такой "чистки" данных можно было сесть за стол с бизнесом и обсудить метрики (KPI) и методику их расчета. Считать ли время пребывания абонентом во внутреннем IVR в длительность звонка или нет? Считать ли CONNECT последующий мгновенный возврат в очередь ответом оператора или нет? Как декомпозировать по KPI операторов и очереденй пребывание абонента в нескольких очередях? Как соотносить среднее время ожидания в очереди со временем суток и количеством операторов в смене? Какие типовые сценарии "оптимизации" у операторов? И масса других вопросов. Самое приятное, что на все вопросы можно дать четкий и однозначный ответ.
Дополнительным плюсом к переходу на событийный анализ call-flow является возможность изучения сценариев работы колл-центра (process mining). По сути, реверс-инжиниринг бизнес-процессов по их следам в логах колл-центра. Любопытные вещи обнаруживаются!
Переход на анализ AMI событий. В целом, это самый универсальный способ, однако требующий чуть больше вычислительных мощностей. После незначительной юстировки логов очередей, для отдельно взятого астериска острота в анализе AMI пропала, но хранение их в контексте исторической работы астериска (траблшутинг) остается полезным. Также работа с AMI обеспечивает независимость от частных настроек отдельного астериска что будет актуально при подключении следующих. Для обеспечения скорости работы с AMI мы "сваливаем" все 151 тип событий с 619 возможными полями в ClickHouse.
Как многие могут отметить, задача весьма частная, объемы данных невелики. Но от этого, значимость этой задачи для бизнеса никак не уменьшается. Применение же R позволило оперативно и элегантно ее решить, при этом создать удобные АРМ для обычных бизнес-пользователей.
И только теперь, имея надежный фундамент, можно переходить к прогнозированию и операционной аналитике.
Ответ на вопрос "причем здесь платяной шкаф", увы весьма прозаичен. Потому что из него посыпались скелеты, которые тщательно скрывались операторами колл-центра. А R+Shiny послужили ключиком для его открывания.
Предыдущий пост: А вы уже применяете R в бизнесе? [4]
Автор: Илья Шутов
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/data-mining/267472
Ссылки в тексте:
[1] предыдущих публикаций: https://habrahabr.ru/post/335576/
[2] Asterisk Call Center Stats: https://asterisk-pbx.ru/wiki/soft/call_center/asternic-call-center-stats
[3] Asterisk CDR Viewer Mod: http://prog-it.github.io/Asterisk-CDR-Viewer-Mod/
[4] А вы уже применяете R в бизнесе?: https://habrahabr.ru/post/340316/
[5] Источник: https://habrahabr.ru/post/341668/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.