О неудержимой жажде кастомов
Занявшись интеграцией, разработчики А25, ожидаемо, столкнулись с неудержимой жаждой кастомов, возможно, в будущем даже будет введён такой термин (НЖК). По удачному стечению обстоятельств, большинство "хотелок" были в шортлисте запланированных внедрений, поэтому с ними вопросов не возникло, однако, было одно пожелание, которое шло вразрез с нашей идеологией системы.
Речь идет о кастомных статусах, которые все хотят создавать на своё усмотрение. Добавлять больше статусов, менять статусы местами и выставлять эти статусы у всего: договоров, счетов, клиентов, проектов. Создается впечатление, что основная задача сотрудника - это корректное выставление статусов, а задача менеджера - придумать как можно больше статусов, наиболее точно отражающих текущее состояние объекта.
В целом, позиция большинства пользователей в отношении статусов ожидаема: открываем любую CRM и видим статусы, которые нам завещано щедрыми разработчиками менять и назначать. Ничего другого не придумано, не освоено и не знакомо обыкновенному пользователю. Мы так привыкли, нас этому научил EXCEL, но на сколько же этот механизм порочен и непрактичен, вы себе не представляете.
- Ручное выставление статусов = генератор случайных ошибок. Где гарантия, что оператор правильно выставит статус?
- Выставление того или иного статуса = трата времени на принятие решение и совершение действия, а это косвенные финансовые потери для бизнеса.
- Статусы однобоки и линейны. Нельзя одновременно обладать несколькими статусами (я нигде такого не видел)
- Польза от наличия статуса = неопределена. Тут поясню подробнее:
Допустим, у нас есть карточка клиента, у которой выставлен статус "горячий".
Если выставление этого статуса не запускает никаких бизнес-процессов (например, в течении 10 минут после выставления этого статуса клиенту должен последовать звонок), то его наличие в карточке никак не влияет на рабочие процессы с этим клиентом. Если у вас есть с клиентом договоренность на определенное действие (например звонок) на 12-30, то, независимо от его статуса вы должны ему позвонить. Аналогично и в проектной работе, если вы получили задачу с установленными сроками, которая не обозначена статусом "горит" - вы должны её выполнить в установленный срок, ровно как, если бы вы получили и горящую задачу, вы бы сделали именно её. И сделали бы её независимо от статуса, а просто потому, что сейчас пришла пора заниматься этой задачей.
Таким образом, кастомные статусы служат одной очевидной простой цели: пометка массива данных с целью его дальнейшего ручного анализа и оценки. И тут возникает резонный вопрос: нужно ли бизнесу столько статистов, или разумнее написать счетчик, который сам будет высчитывать необходимые метрики?
Если же за определёнными статусами следуют конкретные бизнес-процессы, например, при статусе задачи "Просрочена" директор подразделения получает уведомление и бежит за розгами, то данный статус не требует ручной модерации и должен быть запрограммирован на уровне системы и автоматизирован, в том числе и пять ударов розги за просрочку :)
Иными словами, если статусы нужны, то в тех случаях, когда за ними следуют строгие бизнес-процессы, которые необходимо запрограммировать в систему для наибольшей эффективности.
Собственно, тема довольно спорная, холиварная и требует дополнительного изучения, и если кто-то дочитал мой пост до этой части, буду рад услышать ваше мнение на этот счет в комментариях.
Что со статусами?
Было принято решение, заменить статусы на кастомные тэги (пока в карточках клиентов). Тэгирование карточек позволяет решать как статичтические задачи (тег может быть прописан автоматом при событии, так и вручную), так и задачи по автоматизации процессов (при вводе определенного тега срабатывает триггер).
По тегам можно делать шикарные выборки из клиентской базы с разными параметрами, дополняя и исключая группы клиентов из определённых категорий, и строить удобные воронки продаж.
Также, наличие тэгов лишает нас однобокости статусов, позволяя добавлять в карточку клиента любое необходимое количество тегов.
Спасибо, что следите за iDirector! До новых встреч.