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

Решается классическая для Планфикса задача - распределение, контроль, отчет, ничего экстравагантного. Но есть мелкие детали, отличающие от "обычной", по которым прошу подсказать "как правильнее", чтобы не переделывать 100 раз (именно направить в правильном направлении, не сделать все за меня - это еще и учебный продукт для меня)

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

ЖЦ задачи достаточно обычный Особенности (лениво рисовать, схему не придумал): у задач всегда есть дедлайн, контроль может ничего не делать или же вернуть на доработку, возврат переносит дедлайн на сутки (рабочего дня) от времени возврата на доработку. Если контроль принял (нет возврата), то через 5 календарных дней от времени выполнения задача переходит в статус закрытой

Финотчет
В отчет по итогам месяца попадают задачи, закрытые в данном месяце (независимо от даты выполнения)

Что уже сделал
Поскольку формат задач единый - используется общий стандартный шаблон, в который (будет) добавлен дополнительный атрибут: собственно цена задачи для исполнителя
Типы задач не разделены на проекты, поскольку общие процессы и общий шаблон задач
Отчет тоже вопросов не вызывает (пока) - просто вводится дополнительное условие фильтрации при выборке

Где возникли вопросы/сомнения
1. Как правильнее реализовать матрицу цен в справочнике, чтобы:
а) ее было удобно редактировать в процессе (я правильно понимаю, что это придется делать строго руками без какой-либо автоматизации?)
б) постановщику задачи было комфортно и с минимумом возможных ошибок выбирать нужное значение из справочника (или не выбирать, а вытягивать из справочника?!) при создании задачи... Если второй вариант, то какие дополнительные измнения могут быть нужны?
2. Цена задачи - кастомное поле задачи или аналитика?
3. Как реализовать автоматический перенос дедлайна при возврате (с учетом рабочих/выходных дней)
4. Как реализовать автоматическую смену статуса задачи с контроля на закрытая по времени

По первому и второму вопросу у меня предложение рассмотреть немного другую методику, которая, на мой взгляд, существенно упростит работу в принципе (не только в плане автоматизации в ПФ): уйти от сложной матрицы к системе, при которой:
- у задачи есть базовая стоимость (кастомное поле);
- у исполнителей есть личный коэффициент (кастомное поле);
- итоговая стоимость задачи получается умножением базовой стоимости на коэффициент сотрудника (в отчете или еще одно кастомное (вычисляемое) поле в задаче).


Какие вижу плюсы:
- легко администрировать (не нужен справочник вообще);
- получаем бонус в виде "уровня" исполнителя, выражаемого в его коэффициенте;
- получаем инструмент стимулирования исполнителя "Вот сейчас у тебя коэффициент 1 и ты за эту задачу получаешь 100 рублей, а если сделаешь {нечто} и получишь следующий коэффициент 1.5 то будешь получать уже 150. А вообще у нас есть ребята с коэффициентом 10"

3. Как реализовать автоматический перенос дедлайна при возврате (с учетом рабочих/выходных дней)

Вот таким сценарием можно:

4. Как реализовать автоматическую смену статуса задачи с контроля на закрытая по времени

Вот такие сценарием:

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

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

Вариант с матричным справочником помимо того что сложен в обслуживании (добавление сотрудника или категории требует добавления десятка или более записей и/или добавление нового поля в структуру справочника и проставления цифр), так еще и плохо обрабатывается инструментами ПланФикса.

Дмитрий Гончаренко писал(а): ↑

30.09.2019 09:23

В справочнике категорий 2 поля: название категории и базовая стоимость. Когда в задаче выбирается категория, появляется возможность оперировать (в формулах, отчетах и т.п.) в том числе базовой стоимостью выбранной категории.

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

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