Компания Особое конструкторское подразделение «АРС» занимается проектированием и строительством крупных инфраструктурных научных объектов по заданию Института солнечной и земной физики Сибирского отделения РАН.
Весной 2024 года в компании был создан «Процессный офис» в рамках Управления персоналом и организационного развития. На сегодняшний день в организации работают: процессный архитектор, процессный методолог и два бизнес-аналитика. В качестве платформы для внедрения системы управления бизнес-процессами используется программный продукт Business Studio 6.
Для целей повышения операционной эффективности компании было принято решение внедрить «1C-ERP» и автоматизировать ключевые процессы организации с использованием «1С:Документооборот». Был приглашен руководитель проекта и программисты «1С». Далее мы рассмотрим методический подход и опыт реализации проекта автоматизации бизнес-процессов.
Ресурсы компании ограничены и их нужно расходовать эффективно. Эти аспекты повлияли на выбор метода выполнения проекта автоматизации. Так, например, было принято решение не привлекать внешних подрядчиков, а проектировать и внедрять процессы своими силами по технологии Agile, то есть путем создания и последующего тестирования прототипов автоматизированных процессов. Проблема состояла в том, что немногие руководители и специалисты имели опыт использования «1С:Документооборот» и четко себе представляли, как всё это работает.
В случае ограничения по ресурсам (персонал, сроки) и невозможности писать объемные технические задания, работа по автоматизации строится, как показано на рис. 1.
Бизнес-заказчик (руководитель компании, руководитель управления) определяет приоритетные процессы для автоматизации, например, создание и проверка нового контрагента, согласование и подписание договоров, управление входящими и исходящими документами, выпуск приказов и СЗ и проч. Далее руководитель проекта внедрения «1С:Документооборот» проводит ряд встреч (интервью) с руководителями и специалистами, фиксирует требования (в Word, Excel) и дает задание на разработку программисту «1С». После разработки решения проводится его презентация заказчику и последующая доработка. Ключевым минусом такого подхода является то, что бизнес-процессов в целом никто не видит. У каждого – свое представление относительно того, как должен «работать» процесс. Что-то делается в «1С», но в целом картина не ясна.
Рис. 1. «Типовой» подход к автоматизации в «1С:Документооборот».
Поэтому в компании был принят следующий подход к проектированию и автоматизации бизнес-процессов в «1С» – см. рис. 2..
Рис. 2. Методический подход к проектированию и автоматизации бизнес-процессов в ОКП «АРС».
Создавались рабочие группы по соответствующим процессам. После проведения интервью бизнес-аналитик проектировал процессы в нотации BPMN в Business Studio с использованием четкого методического подхода, в том числе на схемах показывали потоки документов со статусами и проч. После этого схему(ы) распечатывали и обсуждали на совещаниях рабочей группы с участием руководителя проекта (РП) внедрения «1С».
Как правило, после обсуждения приходилось вносить изменения в проект процесса. После 1-3 итераций постановка задачи по автоматизации становилась понятной всем участникам.
Проект бизнес-процесса в виде схемы в нотации BPMN давал возможность всем заинтересованным сторонам целиком увидеть процесс и понять, как он должен работать. После этого программисты «1С» настраивали систему.
Далее Процессный методолог, РП и участники рабочей группы тестировали решение, в первую очередь на соответствие разработанному проекту процесса, и фиксировали необходимые задачи по доработке. Затем на совещаниях проводили презентацию готового решения бизнес-заказчику.
Мы считаем важным наше достижение, что каждый руководитель умеет читать и понимать схемы процессов в нотации BPMN. Это универсальный язык общения, мостик между представителями бизнеса и специалистами по информационным технологиям.
На рис. 3 показана модель бизнес-процесса создания и проверки нового контрагента. Модель процесса в BPMN делается для бизнеса, то есть она содержит задачи, которые должны выполнять сотрудники для достижения бизнес-результата, и логику их исполнения. Документы, которые показаны на схеме, необходимы для получения этого результата. То есть ключевой принцип разработки – это «Документ (информация) для процесса».
Рис. 3. Процесс в BPMN и в «1С:Документооборот».
Но внутри «1С:Документооборот» сотрудник видит только отображение реального бизнес-процесса на действия внутри системы. В «1С:Документооборот» процессы создаются и выполняются для конкретных классов документов. Можно сказать, что используется принцип «Процесс для документа». Но для бизнеса этот принцип не всегда удобен. В «1С» работник делает только часть задач, которые есть в реальном бизнес-процессе. Поэтому полного соответствия процесса в BPMN и маршрута в «1С:Документооборот» нет.
Еще один аспект, который приходится учитывать – это, что одна задача на схеме процесса в BPMN в «1С:Документооборот» состоит из нескольких последовательных действий пользователя в различных экранных формах «1С». Очевидно, что было бы излишне описывать все элементарные действия пользователя в виде задач на схеме в BPMN. Наоборот, можно для одной задачи в BPMN сделать текстовое описание с экранными формами из «1С:Документооборот», то есть, фактически создать инструкцию по работе пользователя в системе. В этом случае, модель бизнес-процесса в нотации BPMN дает общее четкое представление о процессе, а описание задачи – инструкцию по действиям пользователя в системе.
В дальнейшем мы планируем выводить информацию о процессах с соответствующими инструкциями для пользователей в гипертекстовом виде с использованием приложения BS Portal. Гипертекстовая база знаний будет основана на архитектуре бизнес-процессов, уже разработанной в ОКП «АРС».
Для того, чтобы сделать модели процессов наглядными и понятными для руководителей и специалистов мы используем статусы документов. На рис. 5 показан пример схемы процесса подписания договора в бумажном виде для случая, когда первым подписывает контрагент. Для ускорения процессов в компании было принято решение работать с поставщиками по сканам договоров. Такой формат требует четкой организации и закрепления ответственности. Кстати, задачи, связанные с ручной передачей документов показаны на рис. 5 оранжевым цветом с маркером «ладошки».
На рис. 4 показаны примеры статусов документов. Четкое понимание статусов важно, в первую очередь, для бизнеса. Например, на каждой стадии взаимодействия с контрагентом должно быть понятно, в каком статусе находится договор: «Подписан контрагентом» и предоставлен в виде скана, «Подписан АРС» и отправлен контрагенту в виде скана подписанной скан-копии и т.п.
Рис. 4. Примеры статусов документов.
Но, с точки зрения «1С:Документооборот» и задачи ее настройки, такие статусы могут показаться лишними. Здесь возникает, в определенном смысле, конфликт интересов бизнес-пользователя и программиста «1С:Документооборот», который стремиться выполнить настройку процесса быстрее и с минимальным количество доработок штатного функционала, в том числе маршрутов.
Мнения каждой заинтересованной стороны, конечно, можно обосновать определенными аргументами. Но главное – это создание решений (проекты бизнес-процессов, маршруты в «1С:Документооборот», регламенты, инструкции пользователей), которые не только удобны работникам, но решают задачи бизнеса.
Приведем пример статусов, настроенных в «1С:Документооборот»: «Утвержден, Подписание договора: Подписан, Ознакомление с подписанием: Ознакомление завершено, Прикрепить оригинал: Исполнен, Подписание сторонами: Подписан».
Видно, что статусы в «1С:Документооборот» не отражают всех ситуаций, которые возникают при выполнении бизнес-процесса, а только некоторые ключевые моменты, стадии прохождения маршрута.
По ходу настройки автоматизированных процессов приходится идти на определенный компромисс: что-то делается не так, как было в моделях процессов.
Главное – создать удобное для пользователя решение. Но после настройки и ввода в эксплуатацию процесса в «1С:Документооборот», в Business Studio необходимо приводить модель процесса (включая названия документов и формулировки статусов) в соответствие с реализованным программным решением. Кстати, это требование сформулировано приказом по компании.
Рис. 5. Схема процесса подписания договора.
В качестве примера рассмотрим процесс согласования и подписания договора. В «1С:Документооборот» – это один маршрут для конкретного типа договора, включающий в себя как согласование, так и подписание документа.
Этап подписания договора в «1С:Документооборот» включает в себя всего три шага:
Но в реальности процесс гораздо сложнее. На рис. 6 показано четыре разных сценария подписания договора в виде схем в нотации BPNN:
Рис. 6. Модели бизнес-процессов подписания договора для четырех сценариев.
Нужны ли эти сценарии, если уже есть автоматизированный маршрут в «1С:Документооборот»? Да, нужны. Они показывают задачи, которые должны выполнить участники бизнес-процесса, в том числе «оффлайн».
Модели бизнес-процессов в BPMN могут и должны использоваться для разработки регламентов, по которым работают сотрудники.
В целом, видно, что маршрут в «1С:Документооборот» и реальный бизнес-процесс компании не совпадают. Это факт еще раз подтверждает мнение, что автоматизация не заменяет собой нормальную, качественную регламентацию деятельности организации.
Наш опыт в ОКП «АРС» говорит о том, что выполнение проекта автоматизации процессов в «1С:Документооборот» с использованием моделей бизнес-процессов в нотации BPMN в Business Studio помогает:
Закончить статью хотим слоганом, которые придумал Владимир Репин:
«Если хочешь перемен, изучай BPMN!».
Ноябрь 2024 г.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
Введите поисковый запрос:
Сообщение успешно отправлено