Система "Первая Форма" — набор инструментов, гибкий конструктор, который настраивается в точном соответствии с потребностями компании и используется для:
•автоматизации бизнес-процессов компании;
•управления и контроля поручений, проектов и бизнес-процессов;
•организации электронного документооборота в масштабе всей компании или холдинга;
•управления взаимоотношениями с клиентами и контрагентами;
•создания защищенной среды коммуникаций между сотрудниками и контрагентами (электронная переписка, аудио- и видеосвязь).
Для более комфортного администрирования системы рекомендуется ознакомиться также с Руководством пользователя.
Веб-интерфейс
Сейчас "Первая Форма" поддерживает два веб-интерфейса: новый интерфейс SPA, который доступен начиная с версии 2.218, и старый интерфейс. Новым клиентам "Первой Формы" сразу включается новый интерфейс SPA. Поддержка старого интерфейса сохраняется для того, чтобы давние клиенты, которые привыкли работать в старом интерфейсе, могли сами выбрать удобный момент для перехода на новый интерфейс SPA.
Использование интерфейса SPA включается в настройках рабочего места для групп пользователей.
Чтобы в пользовательском и администраторском интерфейсах "Первой Формы" были доступны отдельные элементы интерфейса SPA, должен быть включен ключ EnableSpaSettings в файле web.config, см. Руководство по техподдержке.
Основные понятия
|
|---|
В "Первой Форме" для настройки бизнес-процессов используются категории. Как правило, одному БП соответствует одна категория и наоборот. Экземпляр бизнес-процесса в "Первой Форме" называется задачей, алгоритм выполнения — маршрутом, а этапы выполнения — статусами.
Категории настраиваются в интерфейсе администратора, а работа с задачами осуществляется в интерфейсе пользователя. Данные, связанные с бизнес-процессом, хранятся в основных и дополнительных параметрах категории. Об этом можно прочитать здесь.
Любые настройки категории впоследствии могут быть изменены, даже уже в процессе эксплуатации системы.
Пользователи, группы, орг.структура
|
|---|
Для удобства администрирования пользователи объединяются в группы. Группам выдаются права доступа к разным объектам в системе, для групп настраиваются интерфейсы и пр.
Часто пользователи объединяются в группы исходя из подразделений, в которых они работают, или занимаемых должностей. Поэтому объединение в группы тесно связано с организационной структурой компании.
Основные параметры задачи
У любой задачи должны быть следующие элементы:
Заказчик – сотрудник, который поставил задачу и напрямую заинтересован в результатах ее выполнения. Каждая задача в "Первой Форме" обязательно имеет заказчика и без указания заказчика не может быть создана. Если задача создается вручную, то по умолчанию заказчиком назначается текущий пользователь. Если же задача создается смарт-автоматизацией, то необходимо продумать, кого назначить заказчиком. Как правило, это пользователь, который заинтересован в результате выполнения задачи. Если заинтересованных сотрудников несколько, то один из них назначается заказчиком, а остальные — подписчиками. Они смогут следить за ходом выполнения БП и получать уведомления. Если задача создается автоматически на определенном этапе сложного БП как подзадача, то ее заказчиком обычно назначается заказчик основной (головной) задачи.
Если нет конкретного сотрудника, заинтересованного в том, чтобы контролировать результаты задачи (например, в категориях-справочниках), то заказчиком лучше назначать служебного пользователя Робот 1Ф (Systemrobot).
Исполнитель – сотрудник, ответственный за исполнение задачи и предоставление ее результатов заказчику. Пользователь может поставить задачу самому себе, т.е. быть одновременно и заказчиком, и исполнителем;
Срок – дата, к которой исполнитель должен выполнить задачу и предоставить результаты ее выполнения заказчику;
Текст задачи – информация, необходимая и достаточная исполнителю для выполнения поставленной задачи.
Если хотя бы один из перечисленных выше элементов отсутствует или сформулирован неполно, такая задача не будет выполнена.
Заказчик, исполнители, срок, текст задачи называются основными параметрами задачи.
Особенности назначения исполнителей
Чтобы четко прослеживать ответственность за выполнение задачи, продумывайте назначение исполнителей.
Если несколько исполнителей работают над задачей одновременно, используйте один из следующих подходов:
•один из исполнителей назначается ответственным. В списке исполнителей ответственный всегда указывается первым. Именно на него возлагается ответственность за соблюдение сроков и достижение результата (этот способ используется в системе по умолчанию);
•декомпозируйте задачу на подзадачи, для каждой из которых назначайте своего исполнителя. Головная задача считается выполненной только когда выполнены все подзадачи.
Если исполнители работают над задачей последовательно, используйте один из следующих подходов:
•передавайте исполнение при переходе на следующий этап маршрута выполнения задачи — очищайте список прежних исполнителей и назначайте новых;
•декомпозируйте задачу на подзадачи, для каждой из которых назначайте своего исполнителя и свой срок. При завершении очередной подзадачи головная задача должна автоматически переводиться на следующий этап маршрута, при этом должна стартовать очередная подзадача. Следующая подзадача не может стартовать пока не завершены все подзадачи предыдущего этапа.
Другие участники задачи
Помимо заказчика и исполнителей, задача может иметь других участников:
Подписчики – сотрудники, заинтересованные в том, чтобы получать информацию о ходе выполнения задачи. Подписчики могут принимать участие в обсуждении задачи;
Акцептанты – сотрудники, которые на каком-то этапе оценивают промежуточные результаты (например, документ, подготовленный для отправки контрагенту) или принимают решение о дальнейшем выполнении задачи (например, подтверждают возможность предоставить покупателю скидку). Обычно акцептантами являются руководители различных уровней.
В "Первой Форме" для принятия решения или оценки промежуточного результата запрашиваются подписи, которые можно либо согласовать (акцептовать) если результат устраивает, либо отклонить если результат не устраивает.
Дополнительные параметры задачи
Вся остальная информация, необходимая для выполнения задачи — суммы, числа, текстовые описания, вложенные документы, ссылки на другие задачи и справочники, и т.п. — хранится в дополнительных параметрах (ДП). Набор ДП может очень сильно различаться в разных категориях, т.к. соответствует особенностям конкретного бизнес-процесса. Могут быть категории, в которых ДП нет совсем.
Маршрут
|
|---|
Статусы
|
|---|
С другой стороны, этапы не стоит делать слишком короткими, так как при этом теряется наглядность и удобство получения общего представления о процессе в целом.
Маршрут обязательно должен иметь начальный и конечный статусы. Начальный статус может быть только один, а конечных несколько — например, успешное окончание задачи (заключение договора) и неуспешное (отказ от сделки).
Рекомендации по названиям статусов:
•Название статуса должно отображать текущее состояние БП и должно обозначать либо длящееся во времени действие (например, Подготовка договора), либо факт выполнения (например, Счет оплачен).
•Название статуса должно согласоваться с наименованием сущности. Например, если сущность называется Поручение, то статус должен называться Завершено или Отклонено, а если сущность называется Договор, то статусы должны быть Завершен или Отклонен.
•Название статуса должно помогать пользователю понять, что от него требуется. Например, в категории Договоры статус Новый будет мало информативен, а вот статус Подготовка проекта договора скажет пользователю больше.
Переходы
|
|---|
Рекомендации по названиям кнопок переходов:
•Название кнопки должно быть лаконичным и информативным, позволяющим пользователю однозначно определить, какой переход она осуществляет.
•Рекомендуется в названии кнопок использовать глаголы в неопределенной форме (например, Начать согласование, Завершить задачу) или краткие прилагательные (например, Счет оплачен, Проблема устранена).
Подписи
Для согласования принимаемых решений и документов в системе запрашиваются электронные подписи. Каждая подпись имеет набор возможных резолюций, таких как "Подписать", "Отклонить" и др. Пользователи, у которых запрошена подпись и которые имеют право выносить резолюции по этой подписи, называются акцептантами.
Часто чтобы согласовать какое-то одно решение, нужно запросить несколько подписей. Их можно запрашивать одновременно или последовательно друг за другом. Порядок запроса подписей называется маршрутом согласования.
Моделирование БП
Простой БП
Простые БП без труда разделяются на этапы и имеют интуитивно понятные переходы.
Сложный БП
Понять, что мы моделируем сложный БП, можно по следующим признакам:
•БП имеет большое количество этапов и переходов;
•БП имеет нелинейную структуру, с ветвлениями и возвратами на предыдущие этапы;
•на очередном этапе БП выполнение передается другому исполнителю;
•в выполнение БП вовлечено несколько функциональных подразделений организации;
•отдельные этапы БП длятся достаточно долго (более 2 недель);
•для отдельных этапов БП есть свои сроки.
Сложные БП можно либо делить на этапы в рамках одного процесса, либо декомпозировать (разделять) на более мелкие самостоятельные подзадачи, каждая из которых представляет собой отдельный простой БП.
Подзадачи создаются в момент перехода основной (родительской, головной) задачи в определенный статус. На одном этапе может создаваться одна или несколько подзадач, которые выполняются последовательно или параллельно.
Особенности декомпозирования
Если вы декомпозируете сложный БП на подзадачи, нужно предусмотреть следующие моменты:
•В основной задаче переходы между статусами должны быть автоматическими, возможность ручного перехода нужно исключить. Для этого в настройках перехода нужно отметить опцию Кнопка скрыта. Переход к следующему статусу нужно настроить с помощью смарт-автоматизации и привязать к завершению последней подзадачи;
•Если подзадач несколько и они выполняются последовательно одна за другой, не стоит создавать все подзадачи сразу — лучше при завершении одной задачи создавать следующую.
•Чтобы процесс был прозрачным, нужно иметь возможность из основной задачи контролировать статусы выполнения подзадач. Сделать это лучше всего с помощью блока "Используется".
Порядок настройки БП
При настройке бизнес-процесса мы рекомендуем придерживаться следующего алгоритма:
1. Определить название и содержание БП.
2. Выделить этапы, определить правила перехода между ними — настроить маршрут выполнения, при необходимости произвести декомпозицию БП с выделением подзадач.
3. На каждом этапе маршрута:
•определить исполнителей и других участников и их права доступа;
•определить, какую информацию необходимо внести, т.е. какие ДП нужно заполнить.
4. Продумать и настроить маршрут согласования.
5. Спроектировать связи между задачами.
6. Настроить внешний вид карточки задачи и списка задач.
7. Настроить уведомления о важных событиях в БП.
|
|---|
Например, БП согласования любых договоров, как правило, включают одни и те же этапы и различаются лишь некоторыми реквизитами, а также исполнителями и акцептантами. Поэтому зачастую для реализации БП согласования различных видов договоров целесообразно использовать одну категорию, в которой доступность отдельных ДП, а также списки участников управляются смартами.
Справочники
Отдельный тип категорий — это справочники. Справочники предназначены для хранения данных, а не для выполнения задач. Как правило, в задачах справочных категорий маршрут упрощенный, нет сроков и исполнителей.
