Форум сервиса Планфикс

Каким образом можно организовать указание произвольных связи/ассоциации между задачами?
Надзадача/подзадачи - это понятно. Но вот как, например, указать (системно дать ссылку), что одна задача является предысторией другой?
 

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

Да, вот именно. Даешь СВЯЗИ!!! Причем везде, и в контрагентах и в справочниках и в задачах.

Уже писал:

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

У задачи может быть несколько связанных задач.
Пример:
Задача, исходные данные из другой задачи: так и укажем что данные взяты из задачи такой то, только не просто в комментарии, а в списке примерно таком же как подзадачи, только это не подзадачи, а связанные. Желательно чтобы связь имела имя, возможно срок действия.

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

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

• учет/фиксация всех входящих Обращений (поступивших по телефону, по почте)
• далее какие-то из этих обращений классифицируются как Лиды (потенциальный заказ)
• далее какая-то часть Лидов конвертируется в Заказы (при в первом приближении видится представлять Лиды и Заказы разными задачами)
• далее, видимо, возникающие подзадачи по заказу можно привязывать непосредственно как подзадачи к заказу и вообще видимо использовать ПланФикс как CRM

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

И еще пару моментов полезных было бы:

• возможность делать ссылки на задачи в тексте (аналогично ссылкам на справочники) - то есть вставлять не просто ссылку вручную, а вставлять "управляемую" ссылку на задачу (отображается названием задачи и при нажатии на которую миникарточка как в планировщике открывается), при этом чтобы было легко эти ссылки вставлять (например, в том числе по номеру задачи)
• возможность искать и открывать задачу по номеру (например как в системе http://trac.edgewall.org/ если мы вводим в поле поиска #100 - то нам откроется карточка задачи номер 100)

Поддерживаю по всем пунктам.

Мы хотим реализовать примерно следующее:
 

• учет/фиксация всех входящих Обращений (поступивших по телефону, по почте)
• далее какие-то из этих обращений классифицируются как Лиды (потенциальный заказ)
• далее какая-то часть Лидов конвертируется в Заказы (при в первом приближении видится представлять Лиды и Заказы разными задачами)
• далее, видимо, возникающие подзадачи по заказу можно привязывать непосредственно как подзадачи к заказу и вообще видимо использовать ПланФикс как CRM

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

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

С мусорными обращениями, которые даже до статуса Лид не доходят, можно поступить разными способами:
1. Сразу удалять на этапе обработки.
2. Завести для них отдельный статус "Мусор" - тогда можно будет обрабатывать статистику мусорных обращений, если она нужна.

Конвертация Лида в Заказ будет заключаться просто в переводе статуса из Лид в следующий в цепочке, например "Подтверждение заказа". Главный плюс такого подхода: вся история общения с клиентом хранится в одном месте и доступна без переходов по связям. То есть, тема этого поста в принципе становится неактуальной (и это нормально, т.к. идеальная система это система, которой нет, но ее функция при этом выполняется).

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

Подсчет и отображение конвертации Лидов в Заказы можно сделать в виде отчета по задачам, в который будут отбираться задачи, созданные за нужный период и отображаться по статусам, с подсчетом количества задач в каждом статусе (а можно и суммы, если вывести ее в отдельное кастомное поле задачи).

Как Вам такой вариант?

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

Собственно, перед нами стоит выбор - или начинать автоматизацию основного процесса в ПланФиксе или потихоньку начинать пилить свою собственную систему автоматизации обработки заказов. Было бы интересно сделать в ПланФиксе (это должно быть явно быстрее разработки). При этом часть процесса у нас уже автоматизируется в МоемСкладе (и эта часть остается там).

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

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

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