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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут есть одна важная особенность, если в задаче по шаблону 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.

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

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