Часто при проектировании бизнес-процесса и его реализации в "Первой Форме" встает вопрос — как лучше хранить связанную информацию, какую сущность лучше использовать для этого: ДП с возможностью множественного выбора (таблицу или multilookup) или отдельную категорию, на которую можно ссылаться через ДП Lookup.
Пример 1: компания регулярно проводит выставки и семинары для своих клиентов. Для подготовки создается задача в категории "Мероприятия", в этой задаче необходимо вести список приглашенных из числа контактных лиц клиентов.
Такой список можно реализовать:
•в виде ДП Multilookup ("Выбор нескольких задач в категории"), содержащем ссылки на задачи категории "Контактные лица",
•в виде ДП "Таблица", где каждая строка будет хранить данные о одном приглашенном,
•создать отдельную категорию "Приглашения", где для каждого потенциального участника будет создаваться отдельная задача; а в категории "Мероприятие" сделать блок "Используется", настроенный на категорию "Приглашения".
Выбор способа реализации зависит от особенностей процесса.
Когда стоит использовать ДП Multilookup
•если для элемента важен только признак "выбран/не выбран" и никакие другие признаки не отслеживаются. Например, для сегментирования клиентской базы для каждого клиента указываются отрасли или сегменты рынка.
ДП "Выбор нескольких задач в категории".
Когда стоит использовать ДП "Таблица"
•если для элемента важны дополнительные характеристики, кроме признака "выбран/не выбран". Например, при формировании заказа нужно вести список выбранных товарных позиций и для каждой позиции указывать количество. Другой пример — в карточке соискателя подсчитывается совокупный опыт работы по специальности.
ДП "Таблица".
Когда стоит использовать БИ
•если у элементов есть свой жизненный цикл, смена статусов. Например, для каждого участника нужно отслеживать статусы "Приглашен", "Принял приглашение", "Оплатил участие" и т.п. При переходе выполняется автоматизация (выставление счета и пр).
•если необходимо обеспечить разделение доступа к элементам. Например, каждый менеджер должен видеть только приглашенных из числа своих клиентов. Для задач такое разделение можно обеспечить с помощью смарт-доступа, а для строк таблицы или содержимого ДП — нельзя.
•если информацию нужно повторно использовать или отображать в разных частях системы. Например, с одной стороны – в карточке мероприятия отображается список участников, с другой стороны – в карточке клиента или контактного лица можно просматривать список мероприятий, в которых он участвовал, или список семинаров, к которым он проявил интерес (это можно учитывать при продажах). Организовать такие перекрестные ссылки удобнее всего с помощью задач и связей по ДП Lookup.
Блок "Используется".
Пример 2 (используются все три способа):
По поручению центрального офиса торговой сети в магазинах регулярно проводятся рекламные акции. Для проведения очередной акции сотрудник центрального офиса создает задачу в категории "Подготовка рекламных акций". В этой задаче в ДП "Выбор нескольких задач в категории" он указывает магазины, которые будут участвовать в этой акции, и отправляет список на согласование.
После согласования списка с помощью автоматизации для каждого выбранного магазина ставится отдельная задача в категории "Поручения магазинам". Эти задачи связаны с исходной задачей с помощью ДП Lookup и отображаются в исходной задаче в блоке "Используется".
В каждой из задач для магазина заполняется ДП "Таблица", в которой последовательно отмечаются даты выполнения отдельных заданий (оформление витрин, раздача листовок и пр.).
Полезные ссылки
