Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Разработка архитектуры бизнес-процессов компании в Business Studio
Опрос

Вы используете

Библиотека

05.07.2016 09:21
  от автора
  DirectumRX

Автоматизация процесса согласования в СЭД. Настройка или разработка?

Оценки за материал: 5.00 (1)

«Коробочные» решения набирают все большую популярность среди малых и средних компаний. Но как наиболее оптимально адаптировать систему под специфику организации: заказная разработка или использование возможностей настройки? Их и разберем, но прежде углубимся в сам процесс согласования.
Автор: Денис Колесников
«Коробочные» решения набирают все большую популярность среди малых и средних компаний. Такой вариант выгоден как клиенту, так и вендору: оба могут сократить свои расходы на поддержку за счет поставки типовой конфигурации. Однако даже в небольших компаниях, при всей их готовности менять процессы под систему, есть свои особенности. И тут уже возникает вопрос, как наиболее оптимально адаптировать систему под специфику организации? Рассмотрим на примере процесса согласования документов и его реализации в системе DirectumRX.

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

Вариации согласования


До 30% всех процессов в организации – это процедуры согласования тех или иных документов. В зависимости от вида документа меняются согласующие, сроки, порядок рассмотрения – все это зафиксировано, как правило, во внутренних регламентах.

Упростив и обобщив имеющийся опыт, получим примерные вариации процессов согласования:

Внутренние документы, требующие утверждения (Приказы, распоряжения)
1.Согласование
2.Печать
3.Утверждение
4.Регистрация
5.Исполнение или ознакомление

Внутренние документы, требующие рассмотрения адресатом (Служебные записки)
1.Согласование (если требуется)
2.Рассмотрение адресатом
3.Исполнение (если требуется)

Исходящая корреспонденция (Официальные письма)
1.Согласование
2.Печать
3.Подписание
4.Регистрация и отправка корреспонденту

Договорные документы (Договоры, дополнительные соглашения, спецификации)
1.Согласование
2.Печать
3.Подписание
4.Регистрация
5.Отправка контрагенту
6.Контроль возврата

Бухгалтерские документы (Входящие счета на оплату)
1.Согласование
2.Утверждение оплаты
3.Исполнение (оплата)


Итого, на каждую компанию приходится как минимум 6 разных процессов. Попытаемся справиться с ними с помощью механизма настройки.

Настраиваем процесс согласования документов

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



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

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

Разберем настройку согласования договорного документа.

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



1.Первым согласовывает непосредственный руководитель инициатора.

2.Если договор нетиповой – его согласовывает руководитель технического отдела и доп. согласующие.

3.Если договор нетиповой, и его сумма больше 100 000 руб. – дополнительно согласовывает главный бухгалтер.

4.Далее юрист печатает два экземпляра договора и передает на подпись.

5.Директор подписывает договор.

6.Юрист регистрирует договор и передает для отправки в секретариат.

7.Секретарь отправляет оба экземпляра договора контрагенту.

8.Юрист отслеживает возврат подписанного контрагентом экземпляра договора.

9.По возвращении договор отправляется на исполнение.

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



Разрабатываем процессы согласования документов


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

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

Пример бизнес-процесса для разработки: нужно добавить для бухгалтера возможность принять к оплате входящий счет и сразу провести документ в 1С.Для этого в системе потребуется добавить новый тип задания.
Также нужно добавить возможность настраивать новый этап обработки счета бухгалтером. Чтобы система могла понять, кто такой «бухгалтер» нужно добавить вычисляемую роль. И еще нужно реализовать защиту от ошибочных ситуаций: чтобы нельзя было добавить этап принятия к оплате для приказов или служебных записок.

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

Настройка vs. Разработка

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

Критерий сравнения / Настройка / Разработка
Требования к квалификации
- Все настройки производит администратор или бизнес-пользователь, ответственный за процесс
- Требуется обученный разработчик или привлечение сторонних разработчиков (вендора или партнера)

Трудоемкость реализации
- От 0,5 часа на процесс
- От 8 часов на процесс

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

Поддержка новых версий продукта
- Добавленные вендором возможности будут доступны автоматически
- Новый функционал типовой версии нужно адаптировать с привлечением разработчика

Полнота покрытия
- Может не закрыть специфичные процессы
- Полная кастомизация, закрывает 100% кейсов


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

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

Подробнее о том, как это реализовано в DirectumRX можно посмотреть в роликах:
- Правила согласования. Корреспонденция и внутренние документы (DirectumRX 2.3)
- Правила согласования. Договорные документы (DirectumRX 2.3)

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

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

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений