Proof of Concept: целесообразность внутреннего ML проекта01.02.2019 16:19

Недавно в уютном чатике дата сатанистов подняли вопрос, как правильно «продавать» внутренние проекты по машинному обучению. Оказалось, что многие из нас весьма брезгливо относятся к экономическому обоснованию своей деятельности. Меж тем, чтобы провести минимальную оценку рентабельности проекта, никакого MBA не нужно — в небольшой статье (10 страниц текста, ке-ке-ке) я расскажу вам, что такое рентабельность инвестиций, как оценить её для внутреннего проекта, какую роль в этом играет Proof of Concept, и почему в реальной жизни всё может пойти не так. Делать мы всё это будем вокруг вымышленного проекта по автоматизации составления расписаний для колл-центра. Добро пожаловать под кат!

Наш вымышленный проект

В колл-центре работает 100 операторов. Они работают по плавающему расписанию, выходя на работу сменами по 8 или 12 часов. Смены начинаются в разное время и расставлены так, чтобы обеспечивать дежурство множества людей в часы пик и малого количества людей в холодные часы по ночам и выходным. Расписание планирует дежурный супервайзер колл-центра темными пятничными вечерами, на глазок планируя нагрузку на следующую неделю.

Один 8-часовой день работы оператора колл-центра стоит компании 2.000 руб. Если считать, что в году 250 рабочих дней, то колл-центр обходится компании в 100 х 2.000 х 250 = 50 млн руб в год. Если мы автоматизируем составление расписания, мы сможем прогнозировать почасовую нагрузку и расставлять смены так, чтобы варьировать число дежурных операторов в зависимости от прогнозной нагрузки. Если наш прогноз и расстановка смен окажется хотя бы на 10% лучше, чем прогноз и расстановка супервайзера, получится экономия аж 5 млн руб. в год. Если нам действительно удастся выжать 10% улучшения, проект однозначно окупится. Или нет?… Давайте подумаем, как вообще принимать такие решения.

Как считают ROI

Прежде, чем начинать большой проект, неплохо бы оценить его экономическую целесообразность. Хрестоматийный способ сделать это — посчитать возврат на инвестиции, ROI.
ROI (Return on Investment) — это показатель доходности проекта, равный отношению доходов к затраченным инвестициям. ROI < 100% означает, что проект не окупится.

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

«Мгновенных доходов» у ML проектов, как правило, нет. Доходы у проекта только операционные, т.е. во времени. Например, в случае с нашим колл-центром, доход формируется как экономия расходов на операторов. Если операционные расходы проекта превышают доходы, проект не окупится никогда.

Из-за «мгновенных» капитальных расходов на старте проекта ROI будет зависеть от времени, на котором мы оцениваем доходность. Обычно для расчета ROI используется или год, или горизонт планирования, или время жизни системы. С годом все понятно — это простой способ понять, окупится проект за год или нет. Горизонт планирования — это временной интервал, на который планируется стратегия компании и составляются бюджеты. В малых и динамичных компаниях горизонт редко переваливает за год, в крупных и стабильных может составлять от трёх до десяти лет.

На далеком горизонте планирования можно окупить любой хлам, но на стражу здравого смысла встаёт время жизни системы. Обычно система через несколько лет перестаёт отвечать требованиям бизнеса, и её либо заменяют новой, либо выкидывают, либо (чаще всего) оставляют гнить на вечном саппорте. При быстром росте бизнеса система не всегда может прожить полгода, на устойчивом рынке система без доработок устаревает за 3–5 лет, а больше 10 может прожить только очень консервативная коробка в очень консервативной среде. Ставки дисконтирования, амортизацию и прочую бухгалтерскую магию оставим профессиональным финансистам.

Таким образом, расчет ROI делается по следующей формуле:

Proof Of Concept

Откуда мы вообще можем знать, что новое внедрение увеличит показатель на 10%?

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

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

Даже на опыте одного единственного внедрения можно сделать гораздо более осмысленный прогноз, чем на «чуйке». Смелое следствие из этого — кажется, что даже единственное незаконченное внедрение даст нам огромную фору перед «чуйкой». Так мы приходим к идее Proof of Concept, или PoC.

PoC нужен для того, чтобы подтвердить или опровергнуть работоспособность гипотезы, а также оценить её эффективность. PoC не предполагает завершенного внедрения, а значит, его можно провести быстро и дешево. Какие способы ускориться есть в Data Science проектах?

1. Взять данные вручную, грязно, напрямую из тех мест, откуда их проще всего анализировать. Даже если для продакшена этот источник будет не приемлем, это не важно.
2. Использовать самые тупые эвристики как бейзлайн. Например, бейзлайн для прогноза нагрузки на следующий день — нагрузка за сегодня. Еще круче — средняя нагрузка за последние 5–7–30 дней. Вы удивитесь, но такую эвристику не всегда удается превзойти.
3. Оценивать качество бек-тестированием — не проводить новых долгоиграющих экспериментов. Все данные уже есть в истории, оценим эффект по ним.
4. Не пытаться сделать переиспользуемый код. Весь код после PoC’а будет выброшен в ведро. Повторяем это каждое утро перед тем, как сесть кодить.
5. Не пытаться сделать крутую модель. Ставить себе жесткие дедлайны — один-три-пять дней на модель. За такие сроки не получится «закопаться» в сложную реализацию, зато получится перебрать много простых вариантов. По этим вариантам получится надежная оценка снизу.
6. Агрессивно искать грабли, наступать на все нелепые места, тестировать опасные идеи. Чем больше грабель мы соберем на этапе PoC, тем меньше рисков будет при продакшен разработке.

Этапы PoC

Длительность PoC’а обычно варьируется от недели до пары месяцев. Над задачей будет работать один человек, ведущий дата сатанист. Проведение PoC’а требует также много внимания бизнес-заказчика — на разговоры в начале PoC’а и на осмысление результатов в конце. Итого, PoC будет стоить нам до двух месяцев работы ведущего DS и несколько дней работы бизнес-заказчиков. Вот и первый индикатор — если заказчик не нашел время на PoC, то и результат большого проекта не будет по-настоящему востребован.

Итак, этапы.

1. Перейти от «хотелок» и базз-вордов к конкретным бизнес-требованиям. Это традиционная задача бизнес-аналитика, но очень желательно, чтобы DS проводил её сам. Так он сможет точнее понять потребности заказчика и выполнить второй этап…
2. Сформулировать эксперимент. Правильная формулировка — залог успешности проекта. DS должен определить, в каком месте бизнес-процесса принимается автоматизированное решение, какая информация доступна на входе, что ожидается на выходе, к какой задаче машинного обучения это можно свести, какие данные потребуются при обучении и в продакшене, какие технические и бизнесовые метрики использовать для оценки успешности.
3. Разобраться с данными. DS должен понять, какие вообще данные нам доступны. Оценить их атрибутивный состав, полноту, глубину истории, непротиворечивость. Быстренько собрать вручную датасет, достаточный для построения модели и проверки гипотезы. Неплохо бы сразу осознать, будут ли данные в продакшене отличаться от того, что доступно в трейне, и что мы тут собрали.
4. Наинженерить фич и построить модель. Юные сатанисты с младых ногтей думают только о моделях (ЕВПОЧЯ), так что комментарии излишни.
5. Оценить качество модели. Правильно провести кросс-валидацию, посчитать технические и бизнесовые метрики, а также оценить пределы, в которых они могут колебаться в продакшене. Это все тоже должен делать DS.
6. Оценить полученный ROI — ради этого всё и затевается. Для оценки можно привлекать представителей заказчика и кого-то, кто умеет в фин. модели.

Проведем вымышленный PoC на основе нашего вымышленного проекта.

Этап 1. Перевод «хотелок» в задачу

Вот формулировка «хотелки»:
Кажется, если мы автоматизируем составление расписания, мы не только сэкономим время на планировании, но ещё и научимся варьировать число смен в зависимости от нагрузки.

Что это значит на самом деле?

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

Метрика эффективности прогноза нагрузок — ошибка по числу обращений в квант времени.
Метрика эффективности утилизации нагрузки — 95ый перцентиль длительности ожидания.
Экономическая метрика — число смен за учетный период.

Задача развалилась на две — как прогнозировать нагрузку, и как расставить смены.

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

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

Этап 2. Формулировка эксперимента

Задача 1. Прогнозирование нагрузки

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

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

Сведем задачу к регрессии. Для каждого часа в истории будем строить feature-вектор и прогнозировать по нему нагрузку в этот час. Пусть метрикой успешности будет MAPE (или WAPE, по ходу разберемся). Кросс-валидироваться «в лоб» на временных данных нельзя — будем заглядывать в будущее. Обычный выход — разбить историю на пересекающиеся фолды со сдвигом в неделю (четыре недели?), и последнюю неделю считать контрольной. Критерий успешности — если наш WAPE (или кто там ещё?) удастся держать в рамках разумных границ. Над разумными границами, опять же, подумаем по ходу эксперимента.

Задача 2. Расстановка смен

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

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

Похоже, что задачу удастся свести к обратной задаче о рюкзаке, т.н. Bin Packing Problem. Это NP-полная задача, но есть алгоритмы ее субоптимального решения. Задачей эксперимента будет подтвердить или опровергнуть их применимость. Целевой метрикой будет число смен в комбинации, граничными условиями — средняя или максимальная длительность ожидания (или какой-то перцентиль). Длительность ожидания мы будем вынуждены моделировать как функцию от числа обращений и числа операторов в работе.

Этап 3. Изучим доступные данные

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

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

Сразу подумаем, что, вероятно, чем больше у нас клиентов — тем больше нам звонят. Пригодится историческая информация о числе клиентов или объеме выпуска — так мы сможем учесть макро-тренды. Сходим еще раз к администраторам CRM или ERP и попросим у них выгрузку по объемам продаж, числу клиентов или типа того. Допустим, удалось раздобыть данные о подписках. Теперь сможем построить таблицу, где для каждой даты видно число активных клиентов.

Итого, у нас есть три сущности, удобно разложенные в три таблички:

• Обращение в колл-центр — номер, дата и время, длительность, идентификаторы клиента и оператора.
• Рабочая смена оператора — номер, дата, время начала, длительность, идентификатор оператора.
• Макро-тренд нагрузки — дата, число активных клиентов

Этап 4. Сгенерируем признаки и обучим модель

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

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

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

1. Для начала, воспользуемся календарной природой наших данных. Добавим признаки дня недели, часа, дня месяца. Их можно замкнуть в кольца.
2. Добавим число обращений в час по таким дням и в такие часы. Можно брать число обращений в последнюю неделю, а также среднее за месяц и за год.
3. Добавим аналогично число обращений в точно такой же час и день недели.
4. Возьмем окно агрегации пошире — добавим среднее число обращений в такой день недели и в такое время суток.
5. Попробуем сразу отнормировать числа обращений на тренд нагрузки. Протестируем как на нормированных, так и на сырых значениях.
6. Добавим сезонность — число обращений в месяц в прошлом году, нормированное на тренд нагрузки.
7. На всякий случай, добавим также «сырые» данные о тренде нагрузки. Причем возьмем как значение в текущий момент, так и «смещенные» значения — неделю назад, месяц назад.

Попробуем не только «обычную» функцию ошибки RMSE, но и WAPE — она больше подходит по смыслу задачи. Для валидации мы не сможем использовать обычную K-fold кросс-валидацию — появится шанс заглянуть в будущее. Поэтоиу будем использовать Nested Folds разбиение, причем зафиксируем размер тестового фолда равным, скажем, 4-м неделям ровно. И границы фолдов будем устанавливать точно в полночь понедельника.

Для PoC’а попробуем две модели — линейную с L1 регуляризацией и самую любимую деревяшечку. Для линейной модели не забудем стандартизировать (и логарифмировать, где нужно) признаки, а для деревяшечки — выкрутить параметры регуляризации поагрессивнее.

Этапы 5 и 6. Оценим качество модели и экономический эффект

Итак, все приготовления завершены, и мы, наконец, можем перейти к самой интересной части PoC’а — анализу результатов и принятию решений.
К сожалению, весь пример был умозрительным, без реальных данных, так что и результаты будут высосаны из пальца. Чтобы не было так стыдно, я взял похожие по порядку цифры из книги «Call Center Optimization» за авторством Ger Koole (я нечаянно нашел ее, пока писал эту статью ¯\_(ツ)_/¯). Картинка оттуда же — на ней пример прогноза нагрузки.

Для начала, нам удалось предсказывать почасовую нагрузку с WAPE = 14%. Удалось достичь ошибки меньше 10% на 43% часов, меньше 20% на 70% часов.
Вообще, это очень неплохо — мы достаточно точно ловим и суточные колебания, и недельные циклы, и среднесрочные тренды. Обжигаемся только на случайных флуктуациях, и, скорее всего, избежать их не удастся.

По нагрузке мы сможем легко вычислить число операторов, которые должны быть в смене в данный час. Мы написали жадный неоптимальный алгоритм планировщика смен и вычислили, что что нам удается сэкономить 10% смен на прогнозной нагрузке. При этом оказалось, что если мы в дополнение к 12-часовым сменам введем 8-часовые и умно расставим их по суткам, можем сэкономить еще 5%.

Переводим показатели в деньги. Текущая стоимость годового содержания колл-центра — 50 млн руб в год. Наш эксперимент показал, что мы можем уменьшить эту сумму на 15%, что приведет к экономии до 7,5 млн руб в год, а за весь срок жизни — до 22,5 млн руб.

Это очень хороший эффект, и так и хочется признать PoC успешным. Давайте, однако, задержимся и проанализируем, что может пойти не так.

Риски, влияющие на экономический эффект

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

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

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

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

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

Разработка и сопровождение, их стоимость и риски

По ходу проведения PoC нам стало понятно, что нужно делать для промышленной реализации решения.

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

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

В-третьих, для работы всего этого потребуется инфраструктура — сервера приложений, базы, балансировщики и мониторинг. Как хорошо, что мы делаем это не в первый раз и знаем, что это займет где-то неделю. Если накосячим с оборудованием, то две. Сопровождение инфраструктуры будет занимать у нас от силы один-два человеко-дня в месяц, пфффф!… Но за три года набежит до пары полных месяцев, ой. Кроме того, надо заложить дообучение и перевыкладку модели раз в полгода — итого 2–5 раз, каждый раз по 3–5 дней.

Просуммируем расходы в оптимистичном, реалистичном и пессимистичном вариантах.

Пусть средний разработчик обходится компании в 20 тыс. руб. в день.

Оптимистичный — 5 дней на CRM, 40 дней на систему управления расписанием, 5 дней на прогнозирование, 10 дней на составление расписаний, 5 дней на инфраструктуру, 3×12х0,5 дней на ее поддержку, и 2×3 дней на редкие дообучения модели. Итого 65 рабочих дня на разработку, 24 дня на поддержку. Итоговая стоимость решения — 1,3 млн руб на разработку + 0,48 млн руб на поддержку за 3 года.

Реалистичный — 10 + 60 + 10 + 20 + 10 + 3×12х1 + 5×3 = 110 разработки и 51 поддержки, 2,2 + 1,02 млн руб.

Пессимистичный — это когда все пошло не так. 20 + 80 + 20 + 40 + 10 + 3×12х2 + 5×5 = 170 разработки и 97 поддержки, 3,4 + 1,94 млн руб.

Отметим, что около 40% стоимости уходит на поддержку, как ни крути.

Оценка ROI и целесообразности проекта

При оптимистичной оценке мы получали 15% экономию на рабочей силе, что приводило нас к экономии 22,5 млн руб за срок жизни проекта, из которых 7,5 млн руб сваливалось на нас в первый год. Оптимистичная оценка расходов показывала всего 1,3 + 0,48 млн руб, что дает +6,2 млн (+377% ROI) в первый год и +21 млн руб (+1160% ROI) за время жизни. Божественно.

Однако, если реализуется хотя бы часть рисков, ситуация изменится. Если окажется, что на часы пик выпадает 50% смен, и мы захотим поддерживать 10%-ный резерв, мы тут же потеряем 5% эффекта. Еще 2,5% расходов на неэластичность штата — и вот мы потеряли в сумме 7,5% из 15% эффекта. Получаем всего 3,75 млн руб доходов в год, 11,25 млн за срок жизни. Это реалистичная оценка доходов.

Вычтем из этого расходы по реалистичной оценке — 2,2 млн на разработку и 1,02 на поддержку. Получим +55% ROI в первый год, +252% за срок жизни. Результат все равно достойный, но вывод о внедрении выглядит уже не таким однозначным.

Теперь давайте перестрахуемся и добавим 20%-ный резерв в часы пик. Мы потеряли еще 5% эффекта, осталось всего 2,5% сокращения расходов, или 1,25 млн в год, 3,75 млн за срок жизни. Это пессимистичная оценка эффекта, но эффект всё ещё хотя бы есть. Теперь при реалистичной оценке расходов проект не окупается в первый год, и только на горизонте в 3 года немного выходит в +17% ROI. Кажется, положить деньги на депозит выглядит надёжнее. Таким образом, при реалистичной оценке доходов и расходов мы уже не можем себе позволить 20%-ную перестраховку.

При реализации пессимистичного сценария разработки расходы составят 3,4 млн руб в первый год. Приемлемый ROI +121% мы получим только в самом радужном случае. На горизонте 3х лет также окупится с +108% ROI «средний» по доходам сценарий.

Таким образом, видно, что реалистично ждать от проекта ROI +55% в первый год и +252% за все время жизни, однако, мы будем вынуждены сильно ограничивать себя в резервах. И если мы не уверены в компетенциях собственной разработки, то проект лучше вообще не начинать.

Сценарий дохода	Сценарий расхода	Income	Dev	Support	ROI 1 г	ROI 3 г
Optim	Optim	7,5	1,3	0,5	+4x	+11x
Optim	Real	7,5	2,2	1,0	+2x	+6x
Optim	Pessim	7,5	3,4	1,9	+85%	+3x
Real	Optim	3,75	1,3	0,5	+155%	+5х
Real	Real	3,75	2,2	1,0	+48%	+2,5х
Real	Pessim	3,75	3,4	1,9	-7%	+112%
Pessim	Optim	1,25	1,3	0,5	-14%	+108%
Pessim	Real	1,25	2,2	1,0	-50%	+17%
Pessim	Pessim	1,25	3,4	1,9	-69%	-29%

P.S. Делать свое или купить готовое

Живой менеджер изучил бы альтернативные решения еще до внедрения PoC, но у нас же умозрительный проект, да? К тому же, про сторонние закрытые решения статью не напишешь…

Существуют десятки решений для управления колл-центром, они состоят из кучи модулей, и многие из них содержат модуль WFM, WorkForce Management. Он делает как раз то, что мы описали — составляет расписание, а иногда даже предиктит. Обычно решение для колл-центра продается всё целиком, и софт, и железо. Рабочее место целиком стоит от $1000 до $2500. Модули WFM ставятся или сразу до кучи, или потом вдогонку. Таким образом, в реальной жизни менеджер пошел бы за WFM решением к вендору своего колл-центра. Давайте же немного порассуждаем, а есть ли вообще смысл делать кастомное решение?

Для начала, есть очень важный стоп фактор — каким будет исход разработки, сильно зависит от компетенций компании. Если компания не уверена в своих разработчиках и DS’ах, вероятность пессимистичного исхода слишком велика. В этом случае нужно однозначно использовать решение от вендора. Просто исходя из этого соображения, просто по этому пути идут все нетехнологические компании. Технологические компании отличаются тем, что сила их команды даёт шансы на оптимистичный исход. Вот тут начинается математика.

Решения от вендоров биллятся, исходя из стоимости аренды рабочего места. По нашей «реалистичной» оценке дохода в 7,5%, мы экономим на одном рабочем месте 37,5 тыс. руб в год. Это и есть максимальная стоимость решения. Если решение стоит дешевле — оно принесет положительный ROI. С собственной разработкой все сложнее — окупаемость зависит от числа операторов. За первый год положительный ROI возможен при расходах на операторов в 26,66 млн в год, что достигается при 53 операторах. За три года положительный ROI начинается от 27 операторов.

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

Что из этого важно — решать вам.

Выводы

1. Готовый WFM уже есть в любом приличном провайдере колл-центров. Скорее всего, вы собирали колл-центр не с нуля. Взять модуль WFM у вашего вендора — самое лучшее решение.
2. Если у вас нет проверенной команды разработчиков и дата сатанистов — не надо делать своего решения.
3. Если вы сильны и там, и тут, то зачем вы вообще читаете эту статью? всё равно не спешите бросаться в бой, а сначала проверьте жизнеспособность идеи с помощью PoC’а.
4. Добавьте к результатам PoC’а побольше безысходности и пессимизма и честно посчитайте, а стоит ли оно того?
5. Если и это вас не остановило — ждите продолжение истории на телеграм-канале автора.

© Habrahabr.ru