В современных условиях рыночной экономики в основе успешной деятельности любой компании в нашей стране лежит повышение эффективности управления [1].
На современном этапе развития всё чаще организации внедряют эффективные инструменты управления, и одним из них является процессное управление в сочетании с его основными методами.
Для того чтобы эффективно управлять, следует четко представлять сущность и назначение предприятия, характеристики построения и функционирования, происходящие в нем процессы, особенности, стадии жизненного цикла, влияние внутренней и внешней среды [2].
Чтобы совершенствование деятельности организации прошло успешно, необходимо осуществлять качественный анализ системы управления и принимать обоснованные решения. Но при процессном подходе без правильно выстроенной архитектуры бизнес-процессов это невозможно, поскольку отсутствует прозрачность протекающих процессов, нет возможности проводить исследования для оптимизации и повышения эффективности деятельности организации.
В свою очередь, отсутствие целенаправленно и последовательно выстроенной архитектуры бизнес-процессов снижает качество управления, что приводит в дальнейшем к потере рентабельности организации.
Цель – исследование понятия архитектуры бизнес-процессов, а также анализ целей и алгоритма её разработки.
В большинстве российских организаций по-прежнему используют функциональный подход к управлению, при котором за каждым подразделением закрепляется ряд отдельных функций. В таких организациях очень слабые горизонтальные связи и, как следствие этого, сотрудники не осведомлены о том, что происходит в соседних отделах, и целью их деятельности является выполнение своей работы таким образом, чтобы было довольно начальство, а не конечный потребитель их работы.
При процессном подходе такие связи сильные и ориентация идёт на качество произведенной работы для удовлетворения конечного клиента. Кроме того, процесс управления непрерывен, благодаря правильной стыковке бизнес-процессов по входам и выходам. При этом сотрудник отвечает не только за свои функции, но и за те бизнес-процессы, в которых он задействован [3].
Ключевой единицей процессного подхода к управлению является бизнес-процесс, представляющий собой упорядоченную совокупность видов деятельности, направленных на преобразование входов в выходы с целью удовлетворения потребителя [4].
При внедрении процессного подхода в управление важным этапом является разработка архитектуры бизнес-процессов.
Модель бизнес-процесса всегда должна создаваться с определенной целью. Если цель не ставится, то существует риск моделирования того, что организации не требуется.
При этом графическая схема не является моделью, поскольку модель, помимо схемы, включает в себя определенные дополнительные элементы, атрибуты и параметры, на основании которых можно принимать взвешенные решения.
Таким образом, модель – представление некоторого реального процесса, устройства или концепции [5]. В свою очередь моделирование – это инструмент, направленный на создание такой модели.
Архитектура бизнес-процессов – совокупность определенных и взаимосвязанных процессов различного уровня, представленных в виде моделей в определенных нотациях и созданных с использованием выбранных программных продуктов [5].
Бизнес-архитектура содержит в себе: цели бизнеса, бизнес-процессы, организационную структуру, информационные системы, ресурсы и данные [6].
Чтобы создать архитектуру бизнес-процессов, требуется создание структурных моделей, которые представляют собой модели, включающие в себя взаимосвязанные части процесса, связи между ними и потоки объектов. Помимо этого, структурная модель показывает замкнутые контуры управления и не показывает цепочку операций, развернутую во времени.
Модель показывает, как процессы взаимодействуют между собой, какой процесс доминирует над другим, как возникают обратные связи. Если обратных связей нет, то и управления нет.
Данная модель создается на первом-четвертом уровне декомпозиции, а целью ее создания является разработка архитектуры бизнес-процессов.
Структурные модели чаще всего строятся в нотациях IDEF0 (методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов), DFD, Value-added Chain Diagram (VAD).
При этом структурная модель показывает не модели бизнес-процессов, а их системы.
При моделировании таких моделей в нотации IDEF0, в наименовании стрелок для верхнего уровня принято использовать бизнес-терминологию, а при декомпозиции на нижние уровни – переходить на термины документов.
Формируя абстрактные модели верхнего уровня, необходимо так же абстрактно называть связи между элементами системы либо кодировать их в числовом формате при создании инженерной модели.
Декомпозиция представляет собой деление целого на части, например разделение одной большой и сложной задачи на несколько взаимосвязанных более простых задач. Деление должно происходить по общему признаку для всех частей, поскольку применить единый принцип для всех типов бизнес-процессов невозможно.
Выделяют следующие признаки, по которым проводится декомпозиция:
- структурные признаки: вид схемы, способы и т.д.;
- функциональное назначение частей;
- конструктивное устройство: вид материала, форма поверхности и т.д.;
- виды этапов и процессов: жизненный цикл, физическое состояние и т.д.;
- предметные характеристики: экономические, информационные, технологичес- кие [7].
Отсутствие декомпозиции приводит к созданию громоздких и нечитаемых схем, при этом уровень и подробности описания должны определяться степенью необходимости и удобства восприятия данных пользователями.
Выделяют следующие правила деком- позиции:
- рекомендуется от восьми до десяти групп процессов;
- группы должны быть одного размера, времени выполнения и со схожим количеством требуемых ресурсов;
- группы бизнес-процессов должны иметь чёткие границы, то есть увязаны по входам и выходам;
- декомпозированные модели должны соответствовать определенному уровню, чтобы получались системные архитектурные модели.
На рисунке представлена иерархия бизнес-процессов компании, за исключением самого верхнего уровня – контекстной диаграммы бизнеса, которая символизирует собой всю организацию в целом. Кроме того, рисунок представляет собой упрощенную схему, поскольку для удобства восприятия отсутствуют линии, демонстрирующие связи.
Иерархия бизнес-процессов
Проблема декомпозиции модели бизнес-процесса – ключевая для разработки архитектуры процессов предприятия, без ее решения невозможно снизить число неудач проектов по внедрению новых ИТ [8].
Таким образом, согласно модели Cross Industry Process Classification Framework (PCF) компании APQC, существуют следующие уровни процессной архитектуры:
1. Категория – общность бизнес-процессов, объединенных в соответствии с типом, ресурсоемкостью и временем выполнения процесса. Также категории определяются в зависимости от групп бизнес-процессов.
2. Группы бизнес-процессов – общность бизнес-процессов, объединенная в соответствии с критериями формирования категорий и групп процессов.
3. Процессы – третий уровень иерархии. Может содержать необходимые для процесса элементы.
4. Операции – отдельные составляющие бизнес-процесса.
5. Задачи – раздробленные и зависящие от отрасли элементы.
На практике архитектуру бизнес-процессов принято моделировать в специализированных BPM-системах, поскольку они обладают рядом преимуществ, например: создается единое поле для всей информации о бизнес-процессах, есть возможность проводить мониторинг выполнения сотрудниками процесса, можно выявлять «узкие места», чтобы в дальнейшем улучшить процесс, а также работа в BPM системе позволяет получить представление о возможности значительного снижения издержек на основе постоянного совершенствования процессов.
Архитектуру бизнес-процессов обычно разрабатывают в целях получения следующих положительных эффектов: объединение имеющихся подсистем в единую модель, возможность определения четкой структуры, границ бизнес-процессов, зон ответственности, возможность удобного управления системой бизнес-процессов.
Также созданная архитектура позволит получить «прозрачную» карту деятельности всей организации и на ее основе принимать более обоснованные управленческие решения. Кроме того, благодаря ей и использованию автоматизированного программного обеспечения можно поддерживать регламенты в актуальном состоянии и создавать базу по реализации и оптимизации бизнес-процессов.
Алгоритм разработки архитектуры бизнес-процессов обычно включает в себя восемь этапов, но их количество и смысл могут меняться в зависимости от используемой BPM-системы.
На первом этапе происходит разработка организационной структуры организации. В процессе выполнения данного этапа необходимо определить ответственных лиц и исполнителей, в их числе могут быть и отдельные подразделения и должности.
Второй этап заключается в группировке всей информации об имеющихся бизнес-процессах. Таким образом, здесь проводится анализ деятельности всех бизнес-процессов, формируется их реестр на двух-трех уровнях декомпозиции.
На данном этапе в BPM-системе создаются следующие справочники:
- Документы.
- Информация.
- Материальные ресурсы.
- Базы данных и терминов.
При этом информация в справочниках группируется так, чтобы имеющиеся материалы относились к конкретным подразделениям либо бизнес-процессам.
Далее, на третьем этапе, начинается формирование моделей бизнес-процессов верхнего уровня. Для этого необходимо четко определить границы, входы и выходы, поставщиков, потребителей. Моделирование происходит в нотации IDEF0.
Четвертый этап заключается в повторном анализе деятельности компании и определении принципов группировки бизнес-процессов. То есть, согласно модели компании APQC, происходит формирование первого уровня архитектуры, где выявляются типы протекающих бизнес-процессов, ресурсоемкость и длительность их выполнения. Так же, как и на предыдущем этапе, моделирование происходит в нотации IDEF0.
На пятом этапе формируются модели бизнес-процессов из групп процессов, а именно для второго уровня модели компании APQC, и также в нотации IDEF0.
На шестом этапе группы процессов моделируются как отдельные бизнес-процессы. Информация для их построения берется из справочников, составленных на втором этапе. Декомпозиция осуществляется на один-два уровня.
Седьмой этап, он же четвертый уровень модели компании APQC, заключается в разработке моделей операций или операционных бизнес-процессов. Для удобства на данном этапе и последующих этапах переходят от нотации IDEF0 к моделированию в нотации BPMN (нотация и модель бизнес-процессов, включающая в себя систему условных обозначений или нотаций, а также их описания в XML для моделирования бизнес-процессов). Как и на шестом этапе, декомпозиция осуществляется на один-два уровня.
И на восьмом, заключительном этапе происходит изменение первоначально составленных справочников к уже сформированной процессной модели.
При этом на этапах три – шесть моделируются структурные диаграммы, а на этапе семь – уже диаграммы потока работ, что объясняет переход к нотации BPMN, которая на нижних уровнях позволяет создавать удобные и понятные модели для любого участника любых бизнес-процессов.
После начала работы по разработанной архитектуре бизнес-процессов необходимо проводить мониторинг и определять проблемные места. Согласно исследованию Г.Р. Нива [9] можно проводить анализ и оптимизацию любого процесса, опираясь на цикл PDCA:
- Планирование.
- Действие.
- Проверка.
- Стандартизация или перепланирование.
Заключение
Таким образом, разработка архитектуры бизнес-процессов включает в себя восемь этапов: разработка организационной структуры компании, формирование и группировка всей информации об имеющихся в организации процессах, формирование моделей верхнего уровня, моделирование категорий процессов, моделирование групп процессов, моделирование процессов, моделирование операционных процессов, изменение первоначальных справочников и приведение их к новой процессной модели.
При этом моделирование на шагах 3–6 происходит в нотации IDEF0, а шаг 7 уже моделируется в нотации BPMN.
Наличие целенаправленно и последовательно выстроенной архитектуры бизнес-процессов повысит качество управления, что приведет в дальнейшем к повышению уровня рентабельности организации.