Является продолжением предыдущих публикаций. Основное назначение публикаций — демонстрация возможностей 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 позволило оперативно и элегантно ее решить, при этом создать удобные АРМ для обычных бизнес-пользователей. И с точки зрения промышленного программирования тоже все ок: пакетирование, документирование функций средствами roxygen, автотесты, логирование, все что можно обложено онлайн проверками и ассертами. Теперь, имея надежный фундамент, можно спокойно переходить к прогнозированию и операционной аналитике. Ответ на вопрос "при чём здесь платяной шкаф?", увы весьма прозаичен. Потому что из него посыпались скелеты, которые тщательно скрывались операторами колл-центра. А R+Shiny послужили ключиком для его открывания. Предыдущий пост: А вы уже применяете R в бизнесе? Data Science