Автоматизируем документооборот с помощью новой платформы. Часть 1. Канцелярия. Работа с «Входящими Документами»

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

Мы также добавили возможность разрабатывать дополнительную бизнес логику в виде add-on скриптов, написанных на Python (их использование в нашей системе скорее исключение, чем правило)".

"Наша система обрабатывает несколько десятков типов Событий, и мы это постоянно расширяем, если встречаем какие-то уникальные случаи у наших заказчиков. Большинство других систем обрабатывает только два события – Создание (Create) и Изменение (Change)".

"Новая платформа предоставляет возможность сформировать неограниченное количество различных Действий, если что-то встречается нестандартное, то можно написать скрипт на Python и выполнить его, если произошло определенное Событие".

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

Но лучше один раз показать, чем 10 раз рассказать.

Простой «электронный документооборот» не в состоянии удовлетворить потребности организаций. Заказчиков больше не устраивает классический функционал бизнес приложений, они хотят получить инструменты, с помощью которых они будут решать свои задачи, связанные с управлением бизнесом. А управление – это в большей степени процессный подход, чем учетный.

В настоящее время в функциональном развитии ИТ-продуктов по автоматизации прослеживаются тренды:

• все больше набирают популярность универсальные BPM системы, которые позволяют автоматизировать совершенно разные сквозные процессы предприятия;
• классические системы СЭД, CRM, ERP начинают обзаводиться функционалом по управлению процессами и перестают быть только учетными системами;
• функционал одних систем начинает проникать в другие системы, и мы можем видеть CRM системы с подсистемой документооборота или ERP систему с подсистемой управления процессами.

Вот некоторые востребованные функции, дополняющие СЭД:

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

В наших обзорах мы будем рассматривать следующие возможные области автоматизации на основе нашей новой платформы Flexbby Parametric:

ОбластьПроцессы/Документы

Канцелярия/ Делопроизводство	Входящие, Исходящие, Доверенности, Протоколы, Приказы, Внутренняя нормативная документация, Распоряжения, Служебные записки, Пояснительные записки, Поручения и др.
Договорная работа	Согласование шаблонов договоров, Согласование договоров, Согласование контрагентов, Контроль исполнения договоров, Пролонгация и автопролонгация договоров
Электронный архив	Хранение бумажных копий документов, Потоковый ввод документов (оцифровка бумажных документов), Заявки на получение оригиналов
Финансовые документы	Создание актов, выставление счета, контроль получения оригиналов бухгалтерских документов, автоматизация контроля платежей. Контроль бюджетов
Продажи, CRM	Работа с клиентской базой, Работа с лидами (Lead), Работа со сделками (возможностями продаж), Работа с заказами и продажами, Работа с активностями

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

Начнем по порядку с Канцелярии, так как это типичный функционал СЭД.

Разберем простой пример – «Входящие документы».

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

Типичный проект складывается следующим образом:

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

Проектируя механизмы настроек и модификации наших продуктов (Flexbby Договоры, Flexbby Продажи, Flexbby Сервис, Flexbby One), мы сразу вкладывали в них Agile подход, что позволяет нам:

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

Проектируя Flexbby Parametric, мы реализовали возможность настраивать большинство процессов в организации с использованием уже существующих Обработчиков событий и Действий платформы.
Мы также добавили возможность разрабатывать дополнительную бизнес логику в виде add-on скриптов, написанных на Python (их использование в нашей системе скорее исключение, чем правило).

Но лучше один раз показать, чем 10 раз рассказать.

Для начала опишем, что выяснилось при обследовании процесса «Входящие документы» при работе с несколькими заказчиками.

Документ движется по следующему процессу:

Роли в этом процессе*:

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

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

На этапе тестирования пилотного решения по работе с Входящими документами мы выявили ряд важных моментов:

1. Каждый входящий документ имеет определенную категорию, и на ее основе можно настроить правила автоматического добавления Исполнителя и Ознакомителя, тем самым разгрузив существенно Руководителя, который назначал Исполнителей.
2. Иногда входящие документы необходимо регистрировать задним числом, но не все сотрудники могут это делать.
3. Иногда входящий документ относился к категории Договоры. Поэтому его нужно было связать с объектом Договор;
4. Необходимо было настроить множество проверок, чтобы минимизировать ошибки пользователя при вводе документа.

Перед настройкой Процесса типа Документа в системе настраиваем два Справочника: Состояния и Роли.

Состояния – это простой справочник в системе, который един для всех процессов:

Настраиваем Роли:

Одним из преимуществ Flexbby Parametric является то, что процесс настраивается отдельно и потом связывается с типом документа. Настроенный процесс можно использовать для неограниченного количества настраиваемых типов документов, что существенно упрощает и удешевляет настройку. Обычно в компании выделяется 3-4 шаблонных Процесса, по которым двигаются документы. В основном большая часть документов незначительно отличается параметрами и шаблонами друг от друга. Поэтому Процессы можно настроить один раз, а затем без ограничений использовать и доопределять в документах.

Теперь настраиваем процесс Входящего документа:

Так выглядит настроенная схема процесса в системе. Цифры в скобках показывают сколько документов находится в данном Состоянии.

Мы преднамеренно делам скриншоты из рабочего варианта внедряемой системы.

Красные квадратики показывают, что есть документы в Состояниях, из которых никуда нет перехода.

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

Основное в настройках – это настройка Ролей в Процессе и настройка Переходов.

Начнем с настройки Ролей.

Мы уже определили Роли в глобальном справочнике в системе.

Затем для конкретного Процесса мы определяем, кто эту Роль может исполнять.

Это может быть пользователь в системе, это может быть сотрудник организации, это может быть штатная единица без привязки к конкретному сотруднику (ФИО).

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

Далее для Процесса настраиваются Переходы и определяется Роль/Роли, которые могут осуществлять Переходы.

Для Перехода определяется начальное Состояние и конечные Состояния, в которые будет осуществлен Переход.

Для Перехода определяется название кнопки Перехода

и результат Перехода, который будет записываться в историю Документа:

Следующей важной настройкой является условие Перехода:

Допустимый участник

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

Самый простой случай, когда у нас один участник, и он один принимает решение.

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

Достигнутый процент

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

Максимальный процент

Решение, которое принимается большинством голосов.

Участник с наивысшим приоритетом

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

Автопереход в случае отсутствия участников

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

Например, шаблонный договор согласуется юристами и бухгалтером, только в том случае, если к нему есть протокол разногласия. Следовательно, с помощью обработчика Flexbby Parametric можно настроить добавление Cогласователей в случае, если инициатор договора подгрузил протокол.

Если протокол не подгружен, то система автоматически согласует шаблонный договор и отправит его на подписание.

Закрыть диалог при принятии данного решения

Настраивает автоматическое закрытие диалога (окна) документа, когда принято решение.

Запомнить решение участника в случае повторного решения

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

Дождаться решений всех участников

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

Завершим рассматривать Процесс. Есть еще некоторые интересные настройки и “use cases”, но об этом мы напишем в отдельном посте. Можно, например, разобрать настройку Процесса договора, когда есть выделенная Роль «Администратор договоров», который имеет право двигать договор в любые Состояния, но обычные пользователи видят этого участника процесса. Практика внедрения показывает, такой участник процесса нужен, так как пользователи делают много ошибок, из-за которых останавливаются или идут не в том направлении Процессы.

Следующая настройка, которую необходимо сделать, это собственно настроить тип Документа.

В настройке типа Документа определяются следующие параметры:

- Процесс, по которому ходит Документ (настроили выше):

- Тип связи, который рассмотрим отдельно ниже, – очень важный элемент платформы Flexbby Parametric. Он позволяет гибко настраивать связи между объектами в системе и Роль объектов в Документах. Область применения – многосторонние договоры или сложные b2b продажи, где кроме покупателя, еще есть 3-4 юридических лица, вовлеченных в сделку, и продавцу необходимо учитывать влияние всех сторон.

- Далее настраиваются Бизнес Правила, Интерфейс, Типы файлов, Шаблоны печатных форм, Параметры, переопределяются Участники Ролей процесса.

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

И начнем с настроек Связи.

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

Сначала настраивается Роль Связи. В нашем случае надо настроить две Роли: «От кого» и «Договор».

Роль «От кого» – может включать для рассматриваемого кейса 3-х участников (в нашем случае это классы обьектов, и я планирую подробности по работе Flexbby Parametric выделить в отдельный пост).

Внутри Роли много настроек, в деталях описывать не будем.

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

Пример таблицы доступных классов обьектов:

Пример отображения реализованного класса на Python в Интерфейсе системы:

Далее настраиваем саму Связь, которая и будет уже указываться в настройках объекта (в типе Документа):

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

Настройки и возможности, которые предоставляет Связь, мы рассмотрим в отдельном посте.

Результат, как это выглядит в карточке объекта, если настройка Связи – «От кого» + «Договор»:

Если просто «От кого» без Договора:

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

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

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

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

Настраиваемые параметры

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

Как это выглядит в настройках.

Список всех параметров.

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

Обработчики мониторят события, которые происходят в системе, и в зависимости от Условий производят определенные Действия.

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

Разберем простой Обработчик, который обрабатывает необходимость внесения даты ответа на входящее, если выбрано «Требует ответа» (чуть выше мы завели эти параметры).

Он срабатывает на событие, когда Процесс меняет Состояние – Событие «Move».

Наша система обрабатывает несколько десятков типов Событий, и мы это постоянно расширяем, если встречаем какие-то уникальные случаи у наших заказчиков. Большинство других систем обрабатывает только два события – Создание (Create) и Изменение (Change).

Дальше мы накладываем Условия, и проверяем значения полей связанных объектов.

И прописываем Условия срабатывания Обработчика и Действия, которые должны выполниться.

Flexbby Parametric предоставляет возможность сформировать неограниченное количество различных Действий, если что-то встречается нестандартное, то можно написать скрипт на Python и выполнить его, если произошло определенное Событие.

О Событиях, которые обрабатывает Flexbby Parametric, и Действиях мы также напишем в отдельном посте.

Самое главное – как это выглядит в Карточке объекта.

При нажатии кнопки «Зарегистрировать» отображается Уведомление, и Процесс не переходит в следующее Состояние до тех пор, пока не будут внесены все данные.

Немного о настройках интерфейса

Flexbby Parametric позволяет скрывать объекты Карточки Документа в зависимости от Условий, состояния Процесса, Роли пользователя и т.п. Можно гибко настраивать различные бизнес правила.

Данная настройка скрывает таблицу Исходящие документы, если значение параметра требует ответа «Установлено «Нет»».

Как выглядит Карточка Документа.

Параметр требует ответа «Установлено «Да».

Параметр требует ответа «Установлено «Нет»».

Спасибо всем, кто дочитал до конца.

BE FLEXBBY!

Источник: https://habrahabr.ru/company/flexbby/blog/335844/