Ключевые сущности (объекты) системы PlanFix. Часть 1

Добрый день, Уважаемые коллеги. Продолжаю цикл статей на тему “Он вам не CRM!” про систему управления задачами ПланФикс.

Количество сущностей которыми предлагают оперировать разработчики ПланФикс меньше чем в других аналогичных системах. Например в нём нет сущности (понятия) сделка, задание, письмо и т.п. все это “задача”. Несмотря на это, вместить даже краткое описание всех ключевых сущностей в одну статью - проблема, описание будет выполнено в двух статьях.

Данная сущность предназначена для высокоуровневой группировки задач. По сути это аналог “папки” в файловой системе. Внутри папки могут быть расположены папки (иерархия проектов, подпроекты) и задачи (которые в свою очередь тоже могут иметь иерархию, подзадачи).

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

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

• группы проектов (аналог диск в файловой системе);
• иерархия проектов;
  
• автоматическое назначения Участников, Аудиторов, Исполнителей проекта в задачи проекта;
  
• отображение задач в планировщиках или фильтрах по текущему проекту или его подпроектам при перемещении по “дереву проектов”;
  
• возможность настройки уведомлений по задачам проекта, отличных от настроек по-умолчанию;
  
• автоматическое создание задачи или пула задач при создании проекта (при выполнении определенных настроек).
  

Часто, компании которые не ведут именно проектную деятельность, используют проекты для упорядочивания задач по зонам ответственности отделов компании. Например заводят в качестве проектов отделы: Отдел продаж, Отдел закупок, Бухгалтерия, Служба персонала. И при создании задач указывают проект в зависимости от того какой отдел отвечает за результат исполнения задачи.

Однако, данный подход не всегда целесообразен, если задача относится к одному из проектов, то все её подзадачи также будут относится к этому проекту и, например, задача “Сделка” относящаяся к проекту Отдел продаж, может иметь подзадачи (договор, счета на оплату, акты выполненных работ и т.п.) выполнение которых зона ответственности другого отдела и получается что часть задач для Бухгалтерии находятся в проекте Отдел продаж, а часть задач в проекте Бухгалтерия.

Упорядочивание задач по проектам позволяет отображать все задачи проекта в виде диаграммы Ганта или группировать задачи и суммировать числовые метрики задач в отчетах.

Например, в задачах проекта, ведется учет сумм доходов (оплаты от Заказчика) и сумм расходов (выплаты подрядчикам) связанных с выполнением задачи. В отчете по проекту данные из этих полей можно суммировать и получать представление о финансовой составляющей проекта.

В настоящий момент (апрель 2023) для проектов не предусмотрена автоматизация в том виде как она реализована в процессах задач или процессах контактов. Например, нельзя сделать в проекте поле аналогичное полю задачи сумма подзадач и автоматически получать в это поле сумму значений из полей задач проекта. Это значит что формирование агрегированных показателей в режиме онлайн (например доходы проекта) - затруднительно и получать такие данные можно другими средствами, например формированием отчета.

PlanFix гибкая система и данный недостаток можно решить через использование функционала задач.

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

Задача это объект управления, в рамках которого Постановщик ставит цели исполнителю (Исполнителям), а Исполнители и другие Участники, выполняют действия направленный на достижение цели задачи.

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

Одно и то же поле, может быть включено в несколько шаблонов задач (аналогичная логика реализована для “шаблона контактов”).

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

Об этом надо помнить, потому что в тарифных планах планфикс есть ограничения на количество полей которые можно добавить в аккаунте.

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

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

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

Также такая иерархия позволяет, например, суммировать в поле надзадачи значения поля типа число из её подзадач.

Например, в моем аккаунте для управления доходными договорами, реализована следующая структура задач:

В данном примере итоговая сумма акта формируется по суммам оплаченных счетов. Данный подход позволяет в конце периода (даты действия акта) получать готовые файлы актов выполненных работ “одним кликом”.

Процесс эта этапы/статусы через которые проходит задача и сценарии для выполнения различных действий над задачами (и контактами). Для каждого процесса задач настраиваются.

Набор статусов:

• перечень статусов через которые может (должна) проходить задача процесса;
• правила перехода между статусами;
  
• права доступа пользователей на смену статусов в зависимости от его роли по отношению к задаче;
  
• отображение дополнительных “кнопок смены статусов”.
  

Сценарии процесса: набор правил (триггеров) для запуска сценариев с описанием выполняемых действий.

Кнопки процесса: условия отображения и логика действия (сценарий) кнопки (не доступны на бесплатном и начальном тарифе Профессионал).

Количество процессов, сценариев и кнопок в процессе зависит от тарифного плана аккаунта.

Понятие статуса по отношению к задачам, если смотреть на задачу с точки зрения процессного управления (алаверды учебе в АНХ по специальности бизнес-аналитик), это показатель достижения цели задачи. Чем “дальше статус” по порядку тем ближе задача к конечной цели процесса.

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

В идеале название и назначение статуса должно подсказывать Исполнителю какие дальнейшие шаги необходимо сделать чтобы задача попала в следующий статус.

У контактов тоже есть процессы, но они не предполагают использование набора статусов. Процессы контактов могут использоваться для настройки сценариев и кнопок.

Сценарии процесса выполняются в зависимости от наступления условий их выполнения, это различные события происходящие с задачей (или контактом). Примеры таких событий:

• Создана задача и соответствует условиям;
• Задача изменена и соответствует условиям;
  
• Наступила дата задачи;
  
• Изменено поле задачи;
  
• Добавлен комментарий и т.п.
  

Сценарии процесса могут выполнять различные действия как непосредственно с самой задачей по которой возникло настроенное событие, там и над другими объектами прямо или косвенно связанными с задачей.

Примеры вариантов действий сценария:

• Изменить эту задачу;
• Изменить другую задачу (надзадачу, задачу из поля, задачу связанную с текущие иерархией);
  
• Изменить другие задачи;
  
• Создать задачу;
  
• Создать контакт;
  
• Послать HTTP запрос и т.п.
  

В одном сценарии можно настроить выполнение разных типов операций, например сначала изменить эту задачу, а потом и

Шаблон задачи это визуальная форма представления содержимого задачи которая определяет:

• набор полей используемых в этой задаче (в том числе группировка полей по панелям);

• поля отображаемые на основной форме задачи (какие именно поля и порядок их расположения);

• процесс задачи.

Как правило, в рамках одного процесса, используется один шаблон, но в некоторых проектах возникает необходимость по мер уточнения полей задачи выполнять смену шаблона в котором добавлены дополнительные поля.

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

Если по данной задаче снова будет выполнена замена шаблона на тот в котором есть поле 1, то в нем отобразится то значение которое было заполнено ранее.

Этот подход позволяет визуально менять форму представления задачи для пользователя и акцентировать внимание на тех свойствах/полях задачи которые важны для её выполнения в текущий момент.

Комментария это средство коммуникации как внутри задачи (между пользователями системы) так и с внешними контактами.

Для ведения переписки с контактами или сотрудниками в задаче используется функционал “комментариев”. Это универсальный инструмент переписки и фиксирования каких-то договоренностей. Канал по которому сообщения отправляются “уведомляемым” определяется каналом задачи.

Например, если задача была создана по письму из почты или непосредственно в ПланФикс то каналом переписки будет - электронная почта. Eсли задача создана через интеграцию (Telegram, WhatsApp, FaceBook и т.п.) то сообщения будут уходить в тот канал по которому была создана задача.

Помимо инструмента "коммуникации" *переписки) комментарий может использоваться как:

• напоминание;
• регистрации и редактирования аналитик комментариев;
  
• формирование по шаблону и/или прикрепления файлов .
  

Если в комментарии упомянут внешний контакт без доступа, то ему на электронную почту (если задача создана по каналам почта или ПланФикс) уйдет письмо по заранее настроенному шаблону.

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

В данном примере файл ранее уже был сформирован другим сценарием и прикреплен в поле задачи типа файл.

Если в комментарии упомянут “контакт с доступом” или “сотрудник” то, в зависимости от его персональных настроек уведомлений комментарий придет в те каналы на которые оно настроено (почта, хроника планфикс, телеграмм и т.п.).

Например, в тех аккаунтах с которыми я работаю постоянно (примерно 8 аккаунтов) я всегда отключаю уведомления по комментариям на электронную почту (все остальные тоже) и всегда настраиваю уведомления на мой телеграмм.

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

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

Один из плюсов использования Telegram заключается в том что интеграция его с ПланФикс - прямая и бесплатная и не требует использования дополнительных сервисов (как например WhatsApp). Также есть возможность подключать бота telegram в ПланФикс и взаимодействовать с контактом через него (а также использовать API telegram для реализации части функционала взаимодействия, например отправку кнопок, генерации пунктов меню и команд бота и т.п.).

Это инструмент фиксирования информации в привязке к объекту (задача, контакт) в “табличном виде”.

Для тех кто знаком с системой 1С8 можно привести такую аналогию. Аналитика в ПланФикс это “табличная часть” объекта (справочника, или документа). Но в отличии от 1С8 в планфикс создается аналитика, работать с которой (в зависимости от прав доступа) можно в любом из объектов вида задача или контакт.

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

Часть полей аналитики выбирает пользователь при вводе информации, часть полей - могут вычисляться по заданным при настройке полей аналитики формулам. Например, поле стоимость вычисляется по формуле Количество*Цена.

Информацию из аналитики можно вывести в шаблон документа, отчет, динамическое поле.

Это инструмент хранения информации о персонах и компаниях с которыми связаны задачи. Все контакты делятся на два вида: контакт как персона и компания.

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

Основные их отличия заключаются в том что для:

• компаний отображаются прикрепленные к ней контакты;
• контактов отображаются компании к которым прикреплен контакт.
  

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

Но отображение компаний для одного контакта это чисто визуальное представление, в то время как “списки контактов компании” могут использоваться в различных алгоритмах работы с контактами и задачами.

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

В зависимости от того в какой роли используется тот или иной контакт могут быть спроектированы набора полей характеризующие контакт.

Для персон это могут быть поля характеризующие конкретного человека (ФИО, пол, интересы и т.п.), для компаний поля содержащие значимую информацию по компании (юридический адрес, ИНН, ОГРН и т.п.).

Это настройка которая позволяет представлять информацию по задачам/контактам в виде “канбан доски”, где каждая панель планировщика это фильтр отбирающий объекты по заданным условиям и выводящий информацию по задач/контакту в том виде как это настроено в карточке.

Для планировщика могут быть настроены разные варианты представления задач (объектов).

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

Рис. 14. Пример настройки планировщика.

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

В один фильтр могут быть выведены задачи разных шаблонов.

Удобство фильтров заключается в том что более удобно (в отличии от планировщиков) реализована возможность установки фильтра по полю выведенному в таблицу. Также такое представление дает более полную информацию по задаче, чем использование полей карточки задачи выведенную в панель/фильтр планировщика.

В следующей статье будут рассмотрены такие сущности как: справочник, правило почты, web-хук, шаблон письма, шаблон документа, поля задачи/контакта, сотрудник, конфигурация и прочие.

Образование: менеджер проектов, бизнес аналитик (АНХ 2010-2011), прикладная математика (МЭСИ 1993-1998). Опыт работы с системами: ПланФикс,1C 7.7 и 8.x, Axapta 3, Worksection, AmoCRM. Владение методиками и нотациями: SADT (IDEF0), ARIS, UML.

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

Буду рад получить отклики , комментарии и вопросы как по данной статье так и по системе ПланФикс.