"В работе" - это не статус, а погода
Клиент пишет: в акте не сходится сумма.
В системе создают задачу, назначают ответственного и ставят статус «в работе». На экране всё выглядит спокойно: задача не потеряна, срок вроде не сорван, рядом даже есть фамилия человека.
Очень содержательно.
Через три дня статус тот же.
Если открыть задачу, выясняется, что бухгалтер ждёт расшифровку от менеджера проекта, менеджер проекта ищет, кто согласовал дополнительные работы, юристу нужно понять, было ли письмо от клиента, а руководитель видит в системе «в работе» и считает, что вопросом занимаются.
Клиенту от этого не легче.
С каждым днём у него меньше терпения и всё больше вопросов к компании, которая не может объяснить расхождение в собственном акте.
Формально задача живёт.
Практически она стоит в тумане.
Статус «в работе» схлопывает в одно слово слишком разные состояния: ждём данные, проверяем сумму, согласуем корректировку, готовим ответ, ищем письмо, вспоминаем договорённость.
Для системы всё это одно и то же.
Для управления - совсем нет.
Потому что в одном случае следующий шаг за клиентом. В другом - за бухгалтерией. В третьем - за менеджером проекта. В четвёртом - решение вообще ждёт согласования.
Если всё это называется одинаково, руководитель видит не процесс, а табличку на двери: «где-то внутри чем-то занимаются».
Это почти прогноз погоды внутри компании: местами активность, возможны уточнения, точный маршрут движения не сообщается.
Хорошие статусы не придумывают на встрече по настройке CRM.
Они появляются из логики процесса.
Сначала нужно понять, какие реальные состояния проходит работа, где она ждёт, кто должен сделать следующий шаг и что переводит её дальше. И только потом давать этим состояниям названия в системе.
Я бы проверял такие статусы одним вопросом: что руководитель может понять о задаче, не открывая переписку и не начиная личное расследование?
Если только то, что она «в работе», статус сообщает лишь одно: задача где-то существует.
А если таких задач в компании сотни, стоит посмотреть не на настройки CRM, а на процесс, который за ними спрятан.
Иначе система будет показывать не процесс, а прогноз погоды.
Ещё больше обо мне | sergey-suslov.ru
· 23.08
За задачей должен быть закреплён ответственный. Все вопросы к нему. Он дёргает всех причастных, ищет ответы, если дело зашло в тупик, и должен владеть полнотой данных о задаче.
Как мне кажется, тут вопрос не в деталях настройки бизнес процесса, а в самом подходе к управлению. Нужно не плодить максимально детализированные регламенты, а строить бизнес процесс который делает всю эту мелкую бюрократию бессмысленной.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 24.08
Павел, как по мне, то, что вы описали, называется ручным управлением. И моя практика показывает не сильно большую эффективность такого подхода, особенно в крупных компаниях.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 24.08
Если таких задач много, то да эффективность потеряется. Человек не сможет одновременно вести 20 таких задач.
Тогда можно внедрить функционал подзадач. В основной задаче каждый отдел создаёт свои задачи по заголовку которой сразу видно кто чем занят. Выводим заголовки подзадач в одном списке в карточке задачи и сразу видно кто что сделал (закрытые подзадачи) и кто что сделает и когда (открытые подзадачи).
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 24.08
Вот именно поэтому я и говорю своим клиентам и клиентам партнеров-интеграторов, насколько важно сначала понять и описать процесс, а потом уже передавать его разработчику на автоматизацию
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён