Мы с удовольствием работаем над нестандартными и сложными задачами.

Наши постоянные клиенты — представители крупной энергетической государственной компании из Черногории Cedis — обратились к нам за очередной доработкой коробочного решения Б24.

Компания Cedis обрабатывает большой поток входящих заявок абонентов, на подключение, подачу документов, различные запросы населения. Им не удобно использовать в своей работе с СРМ задачи, так как с задачей сложно работать последовательно по этапам. 

Поэтому основной инструмент для них — сделки. 

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

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

Одна стадия может инициироваться несколько раз

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

Например:

1. сделка в стадии Х (1 день);

2. сделка переходит в стадию Y;

3. возвращается на стадию X (2 ч).

Отсюда возникает сразу несколько вопросов:

1. Правильно ли рассчитывать суммарное время, которое сделка проводит на определенной стадии или разбивать время в таблице? 

2. Будет ли тогда длительность нахождения сделки в стадии X равна 1 дню и 2 часам или 26 часам — если рассматривать суммарное время?

Клиент хотел видеть полную историю по этапам. 

Однако, для расчетов трудозатрат, а также вычислений времени требуется также суммировать время.  

Учет времени по текущей сделке

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

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

Для этого они использовали бизнес-процесс со множеством пользовательских полей и функцией datediff.

По процессу обновление времени происходило только после перехода сделки в другую стадию. 

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

Специалисты ИНТЕРВОЛГИ реализовали вариант подсчета времени, в котором поле Transition OUT остается пустым для сохранения видимости, что сделка все еще находится в текущей стадии и время на нее еще расходуется.

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

Пользовательские поля и количество стадий сделки

Мы предложили и реализовали вариант хранения данных о продолжительности нахождения сделки на стадии в пользовательских полях.

Для каждой стадии каждой сделки мы добавили 2 пользовательских поля (длительность в стадии, время в стадии).

Но у этого метода были недостатки:

У клиента существовало около 20 направлений сделок, в каждом из которых было разное количество стадий (максимальное не превышало 15). Это значило, что нужно создать ~200 пользовательских полей.

Пользовательские поля не привязаны к направлениям, т.е. каждая сделка может иметь свой набор полей.

Мы решили эту задачу: 

1. Модуль проверяет все направления;

2. Для каждого направления модуль подсчитывает существующие этапы и находит максимум;

3. Затем модуль создает Пользовательские поля до тех пор, пока количество Пользовательских полей не будет соответствовать максимальному количеству Этапов;

4. При каждом обновлении модуль проверяет, требуется ли больше полей. Если это так, модуль создает новые поля, а затем выполняет обновление.

Стадии можно менять и удалять без особых трудностей. Это может привести к потере данных в пользовательских полях. Например, администратор или ответственный за сделку может удалить какое-нибудь поле по ошибке. 

Чтобы избежать потери данных, поля модуль только добавляет, но не удаляет.  

Что реализовали:

1. Автоматическое создание пользовательского поля при установке модуля (для каждого направления);

2. Модуль автоматически проверяет новые этапы и отслеживает информацию по ним;

3. Возможность обновления затраченного времени для одной Сделки;

   

4. Возможность обновления затраченного времени для нескольких сделок по направлению;

   

5. возможность пересчета затраченного времени для всех сделок;

Выводы

Мы реализовали новый механизм работы со сделками. 

Сделки стали более информативными, теперь можно вести учет времени сотрудников и считать их KPI, чтобы планировать график компании и видеть узкие места.

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

Автор статьи: Киреева Дарья.