Руководство администратора

В "Первой Форме" для настройки бизнес-процессов используются категории. Как правило, одному БП соответствует одна категория и наоборот. Экземпляр бизнес-процесса в "Первой Форме" называется задачей, алгоритм выполнения  — маршрутом, а этапы выполнения — статусами.

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

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

Пользователи, группы, орг.структура

Для удобства администрирования пользователи объединяются в группы. Группам выдаются права доступа к разным объектам в системе, для групп настраиваются интерфейсы и пр.

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

Основные параметры задачи

У любой задачи должны быть следующие элементы:

•заказчик – сотрудник, который поставил задачу и напрямую заинтересован в результатах ее выполнения. Задача всегда имеет одного заказчика;

•исполнитель – сотрудник, ответственный за исполнение задачи и предоставление ее результатов заказчику. Пользователь может поставить задачу самому себе, т.е. быть одновременно и заказчиком, и исполнителем;

•срок – дата, к которой исполнитель должен выполнить задачу и предоставить результаты ее выполнения заказчику;

•описание – информация, необходимая и достаточная исполнителю для выполнения поставленной задачи.

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

Заказчик, исполнители, срок, текст задачи называются основными параметрами задачи.

Особенности назначения исполнителей

Чтобы четко прослеживать ответственность за выполнение задачи, продумывайте назначение исполнителей.

Если несколько исполнителей работают над задачей одновременно, используйте один из следующих подходов:

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

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

Если исполнители работают над задачей последовательно, используйте один из следующих подходов:

•передавайте исполнение при переходе на следующий этап маршрута выполнения задачи — очищайте список прежних исполнителей и назначайте новых;

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

Другие участники задачи

Помимо заказчика и исполнителей, задача может иметь других участников:

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

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

Дополнительные параметры задачи

Вся остальная информация, необходимая для выполнения задачи — суммы, числа, текстовые описания, вложенные документы, ссылки на другие задачи и справочники, и т.п. — хранится в дополнительных параметрах (ДП). Набор ДП может очень сильно различаться в разных категориях, т.к. соответствует особенностям конкретного бизнес-процесса. Могут быть категории, в которых ДП нет совсем.

Маршрут

Статусы

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

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

Рекомендации по названиям статусов:

•Название статуса должно отображать текущее состояние БП и должно обозначать либо длящееся во времени действие (например, Подготовка договора), либо факт выполнения (например, Счет оплачен).

•Название статуса должно согласоваться с наименованием сущности. Например, если сущность называется Поручение, то статус должен называться Завершено или Отклонено, а если сущность называется Договор, то статусы должны быть Завершен или Отклонен.

•Название статуса должно помогать пользователю понять, что от него требуется. Например, в категории Договоры статус Новый будет мало информативен, а вот статус Подготовка проекта договора скажет пользователю больше.

Переходы

Рекомендации по названиям кнопок переходов:

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

•Рекомендуется в названии кнопок использовать глаголы в неопределенной форме (например, Начать согласование, Завершить задачу) или краткие прилагательные (например, Счет оплачен, Проблема устранена).

Подписи

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

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

Моделирование БП

Простой БП

Простые БП без труда разделяются на этапы и имеют интуитивно понятные переходы.

Сложный БП

Понять, что мы моделируем сложный БП, можно по следующим признакам:

•БП имеет большое количество этапов и переходов;

•БП имеет нелинейную структуру, с ветвлениями и возвратами на предыдущие этапы;

•на очередном этапе БП выполнение передается другому исполнителю;

•в выполнение БП вовлечено несколько функциональных подразделений организации;

•отдельные этапы БП длятся достаточно долго (более 2 недель);

•для отдельных этапов БП есть свои сроки.

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

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

Особенности декомпозирования

Если вы декомпозируете сложный БП на подзадачи, нужно предусмотреть следующие моменты:

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

•если подзадач несколько и они выполняются последовательно одна за другой, не стоит создавать все подзадачи сразу — лучше при завершении одной задачи создавать следующую.

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

Порядок настройки БП

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

1.Определить название и содержание БП.

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

3.На каждом этапе маршрута:

a.определить исполнителей и других участников и их права доступа;

b.определить, какую информацию необходимо внести, т.е. какие ДП нужно заполнить.

4.Продумать и настроить маршрут согласования.

5.Спроектировать связи между задачами.

6.Настроить внешний вид карточки задачи и списка задач.

7.Настроить уведомления о важных событиях в БП.

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

Справочники

Отдельный тип категорий — это справочники. Справочники предназначены для хранения данных, а не для выполнения задач. Как правило, в задачах справочных категорий маршрут упрощенный, нет сроков и исполнителей.

Полезные ссылки

Начало работы с системой

Структурирование информации в системе