Мы с удовольствием работаем над нестандартными и сложными задачами.
Наши постоянные клиенты — представители крупной энергетической государственной компании из Черногории Cedis — обратились к нам за очередной доработкой коробочного решения Б24.
Компания Cedis обрабатывает большой поток входящих заявок абонентов, на подключение, подачу документов, различные запросы населения. Им не удобно использовать в своей работе с СРМ задачи, так как с задачей сложно работать последовательно по этапам.
Поэтому основной инструмент для них — сделки.
Для учета трудозатрат, KPI сотрудников и повышения, в конечном счете, эффективности работы, требовалось разработать способ расчета времени, в течение которого сделки находятся на определенной стадии работы.
![Учет времени сделки на каждой стадии для подсчета KPI Учет времени сделки на каждой стадии для подсчета KPI](https://habrastorage.org/getpro/habr/upload_files/510/2c0/71b/5102c071b0ec30049432875d8e4b0bfb.png)
Мы с интересом взялись решать эту задачу, и сразу выделили несколько важных аспектов, о которых расскажем в статье.
Одна стадия может инициироваться несколько раз
Во-первых, необходимо было учитывать, что сделка может находиться на определенной стадии более одного раза.
Например:
сделка в стадии Х (1 день);
сделка переходит в стадию Y;
возвращается на стадию X (2 ч).
Отсюда возникает сразу несколько вопросов:
Правильно ли рассчитывать суммарное время, которое сделка проводит на определенной стадии или разбивать время в таблице?
Будет ли тогда длительность нахождения сделки в стадии X равна 1 дню и 2 часам или 26 часам — если рассматривать суммарное время?
Клиент хотел видеть полную историю по этапам.
![Расчет трудозатрат Расчет трудозатрат](https://habrastorage.org/getpro/habr/upload_files/25b/8b1/f13/25b8b1f13f26e1298689eb1e0c33942e.png)
Однако, для расчетов трудозатрат, а также вычислений времени требуется также суммировать время.
![Затраты по времени Затраты по времени](https://habrastorage.org/getpro/habr/upload_files/73d/fc9/4ae/73dfc94ae28963f6f7c53998ea6307c5.png)
Учет времени по текущей сделке
Во-вторых, важно было учитывать, что пока сделка находится в текущей стадии — время на нее расходуется, и его тоже нужно учитывать, чтобы исключить подвисание сделок.
Наш клиент пытался самостоятельно реализовать необходимый ему расчет времени, которое сделка проводит на одной стадии.
Для этого они использовали бизнес-процесс со множеством пользовательских полей и функцией datediff.
По процессу обновление времени происходило только после перехода сделки в другую стадию.
Из-за этого узнать время, уже затраченное на текущий этап сделки было нельзя.
Специалисты ИНТЕРВОЛГИ реализовали вариант подсчета времени, в котором поле Transition OUT остается пустым для сохранения видимости, что сделка все еще находится в текущей стадии и время на нее еще расходуется.
Модуль также добавляет агента в настройках для автоматических обновлений раз в час — скрипт проходит по открытым сделкам и обновляет затраченное время по стадиям.
Пользовательские поля и количество стадий сделки
Мы предложили и реализовали вариант хранения данных о продолжительности нахождения сделки на стадии в пользовательских полях.
Для каждой стадии каждой сделки мы добавили 2 пользовательских поля (длительность в стадии, время в стадии).
Но у этого метода были недостатки:
У клиента существовало около 20 направлений сделок, в каждом из которых было разное количество стадий (максимальное не превышало 15). Это значило, что нужно создать ~200 пользовательских полей.
![Сделки в работе в CRM Битрикс24 Сделки в работе в CRM Битрикс24](https://habrastorage.org/getpro/habr/upload_files/8e9/ba6/f9a/8e9ba6f9afa69291f3a84c45cc36ec1e.png)
Пользовательские поля не привязаны к направлениям, т.е. каждая сделка может иметь свой набор полей.
Мы решили эту задачу:
Модуль проверяет все направления;
Для каждого направления модуль подсчитывает существующие этапы и находит максимум;
Затем модуль создает Пользовательские поля до тех пор, пока количество Пользовательских полей не будет соответствовать максимальному количеству Этапов;
При каждом обновлении модуль проверяет, требуется ли больше полей. Если это так, модуль создает новые поля, а затем выполняет обновление.
Стадии можно менять и удалять без особых трудностей. Это может привести к потере данных в пользовательских полях. Например, администратор или ответственный за сделку может удалить какое-нибудь поле по ошибке.
Чтобы избежать потери данных, поля модуль только добавляет, но не удаляет.
![Поля модуля для избежания потери данных Поля модуля для избежания потери данных](https://habrastorage.org/getpro/habr/upload_files/34f/736/319/34f736319a4e7d570a9798dbfdc9eb63.png)
Что реализовали:
Автоматическое создание пользовательского поля при установке модуля (для каждого направления);
Модуль автоматически проверяет новые этапы и отслеживает информацию по ним;
-
Возможность обновления затраченного времени для одной Сделки;
Возможность обновления затраченного времени для одной Сделки -
Возможность обновления затраченного времени для нескольких сделок по направлению;
Возможность обновления затраченного времени для нескольких сделок по направлению возможность пересчета затраченного времени для всех сделок;
![Возможность пересчета затраченного времени для всех сделок Возможность пересчета затраченного времени для всех сделок](https://habrastorage.org/getpro/habr/upload_files/92f/93b/1a8/92f93b1a8545422b32ec2fac2c0bd8a2.png)
Выводы
Мы реализовали новый механизм работы со сделками.
Сделки стали более информативными, теперь можно вести учет времени сотрудников и считать их KPI, чтобы планировать график компании и видеть узкие места.
Мы не только хорошо программируем, но и умеем разбираться в сути бизнеса, чтобы найти наиболее подходящее решение для каждой задачи.
Автор статьи: Киреева Дарья.
sotoros
В чем суть хранения в БД вычисляемых полей и их обновлении скриптом? Не выгоднее в момент отрисовки посчитать?
stepan_ovchinnikov Автор
минимизируем время показа клиенту. иногда это долго, особенно если разрешить видеть сразу список сделок с их временем или строить отчет.
решили что глядя в будущее правильно считать и хранить. некая денормализация