Моделирование бизнес-процессов в проектах внедрения корпоративных информационных систем

Подробности

Опубликовано: 30.06.2023 12:25

Автор: Катасонова Наталья Сергеевна

Просмотров: 751

Аннотация: в статье анализируются два случая проектирования бизнес-процессов. Делается вывод о том, что моделирование процессов при внедрении ERP-системы и для целей оптимизации существующих бизнес-операций решает совершенно иные задачи, поэтому порядок использования графических нотаций так же различается. Для проектов имплементации ERP-систем предлагается проектировать операции лишь для визуализации, только в схеме «Как будет» и на низком уровне декомпозиции (3-5), используя нотацию BPMN2.0. Кроме того, рекомендуется не моделировать процессы верхнего уровня, а описывать их в карте бизнес-процессов.
Скачать: PDF (статья), PDF (выпуск №22).
Ключевые слова: системы моделирования бизнес процессов, нотации моделирования бизнес процессов, моделирование бизнес процессов bpmn, методологии моделирования бизнес процессов, анализ бизнес процессов, case средства, case средства проектирования, case технология, анализ case средств, организационное проектирование бизнес процессов, системы проектирования бизнес процессов, методы проектирования бизнес процессов, проектирование бизнес процессов, реинжиниринг бизнес процессов предприятия, технология реинжиниринга бизнес процессов, методы реинжиниринга бизнес процессов, реинжиниринг бизнес процессов, реинжиниринг информационной системы, реинжиниринг системы управления, реинжиниринг системы.

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте.

Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3].

Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

Табл. 1. Функциональная насыщенность нотаций низкого уровня для моделирования процессов

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

• оптимизация и усовершенствование процессов, которые обычно ведутся после внедрения информационных систем с целью выявления «узких мест» работы компании и их устранения;
• демонстрация и визуализация операций, позволяющая детально понять будущий бизнес-процесс, формирующийся в ходе внедрения ERP-решения.

Следует отметить, что имплементация ИТ-решения также может вестись по двум сценариям:

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

В обоих случаях визуализация бизнес-операций приветствуется [4].

Закономерно, что оптимизация операций и оргструктур требует глубокого анализа и понимания существующих процессов. Именно поэтому, не смотря на высокие трудозатраты: более 10 000 операций к описанию, ведется их моделирование в заданной графической нотации в схеме «Как есть». При этом моделированию подлежат операции на всех уровнях декомпозиции 1-8, так как коллизии и противоречия могут находиться где угодно. В этом случае службу внутреннего контроля, а обычно именно она занимается подобными задачами, не пугает ни высокий объём работ для проектирования, ни постоянно меняющиеся регулярные процессы («Как есть» процессы претерпевают обновления в виду изменений законов РФ и внутренних регламентов). Более того описание бизнес-процессов компании свидетельствует о высоком уровне зрелости организации, позволяющим улучшать как свои, так и процессы вовлеченных контрагентов (рис. 1). Таким образом, моделирование операций и оргструктур оправдано, не взирая на большой объем работ [6].

Рис. 1. Уровни зрелости компании с точки зрения описания процессов

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

Посмотрите на верхнеуровневое и низкоуровневое описание процессов, продемонстрированных на рис. 2-3. Несмотря на то, что применяются различные графические нотации (ARIS VACD и BPMN2.0), схема процесса из рис. 2 выглядит достаточно обобщенно, без каких-либо деталей, чего нельзя сказать о модели бизнес-процесса, отображенного на рис. 3. Закономерный вопрос, действительно ли нам нужно проводить описание операций на верхнем уровне? Добавьте к этому и трудозатраты, которые вы неминуемо понесете при использовании даже самой простой верхнеуровневой графической нотации, хотя из нее вам важен лишь единственный визуальный элемент – операции (рис. 2). Постепенно мы подходим к термину карты бизнес-процессов. Следуя нотации верхнего уровня IDEF0, карта процесса представляется в виде иерархического дерева (рис. 4). В реальных ERP-проектах число бизнес-операций велико, поэтому карта из древовидного представления преобразовывается в матрицу. Как видно из рис. 5, карта процессов, представленная в виде таблицы, содержит операции, декомпозированные до 3-5 уровней детализации, где последний уровень задает элементарную операцию, выполняемую ответственным лицом.

Рис. 2. Пример моделирования процесса на верхнем уровне в ARIS VACD

Рис. 3. Пример проектирования бизнес-процесса на нижнем уровне в BPMN 2.0

Рис. 4. Пример иерархического дерева процесса на основе IDEF0

Рис. 5. Пример карты бизнес-процессов в матричном виде

Карта позволяет увидеть набор низкоуровневых операций, задающих бизнес-процесс без каких-либо деталей, присущих графическим нотациям. Поэтому, применение нотаций на верхних уровнях не дает преимуществ. Наоборот, использование CASE-технологий на низких уровнях обеспечивает необходимую степень наглядности для понимания процесса в целом. Следовательно, в проектах внедрения ERP-систем с целью экономии трудозатрат моделирование операций рекомендуется проводить только на нижних 3-5 уровнях декомпозиции, а описание процессов на верхних уровнях легко компенсируется применением карты бизнес-процессов. Моделирование преимущественно ведется только в модели «Как будет». В качестве графических нотаций нижнего уровня обычно применяют те, которые позволяют однозначно разграничить ответственность между сотрудниками: UML AD, BPMN 2.0, ARIS eEPC, поддерживающие концепцию плавательных дорожек SLD (Swim Lane Diagram).

Посмотрите пример описания процессов в двух нотациях: BMPN 2.0 и ARIS eEPC (рис. 3 и 6). Легко заметить, что нотация ARIS eEPC, содержит большое число графических элементов для всевозможных целей, массивна и громоздка с точки зрения визуализации. Несмотря на то, что ARIS eEPC часто применялась в проектах внедрения решений SAP (последняя выкупила компанию IDS Sheer, владеющую ARIS), сегодня это не кажется хорошей идеей. В виду критичности вопроса разграничения ответственности, популярностью пользуются нотации низкого уровня, основанные на концепции SLD, в частности, BPMB 2.0. Внедрение ERP-системы по умолчанию решает задачу оптимизации процессов, а визуализация и моделирование организационной структуры предприятия обычно не требуется.

Рис. 6. Пример моделирования процесса в нотации ARIS eEPC

Подведем итоги анализа применения графических нотаций в проектах имплементации ERP-систем. Суммируем следующие рекомендации:

• проектируйте для визуализации, а не оптимизации;
• моделируйте процессы только в модели «Как будет»;
• проектируйте только процессы на низком уровне декомпозиции (3-5);
• в качестве графической нотации используйте те, что поддерживают концепцию SLD, например, BPMN2.0;
• не моделируйте процессы верхнего уровня, но описывайте их в карте бизнес- процессов, которая ведется в матричном виде;
• схемы процессов ведите и согласуйте в документах проектных решений или их аналогах.

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

Литература

1. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. М.: Лань, 2019. – 164 с.
2. Грекул В.И. Проектирование информационных систем. М.: Юрайт, 2023. – 385 с.
3. Ходоровский Л.А. Проектирование информационных систем. СПб.: Нобель Пресс, 2012. – 121 с.
4. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
5. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
6. Степанов Д.Ю. Методы проектирования организационной структуры и бизнес-процессов предприятия при внедрении ERP-систем (часть 1) // Корпоративные информационные системы. – 2018. – №4 – С. 50-60. – URL: https://corpinfosys.ru/archive/2018/issue-4/134-2018-4-processes.

Выходные данные статьи

Катасонова Н.С. Моделирование бизнес-процессов в проектах внедрения корпоративных информационных систем // Корпоративные информационные системы. – 2023. – №2 (22) – С. 1-7. – URL: https://corpinfosys.ru/archive/2023/issue-22/226-2023-22-businessprocessmodelling.

Об авторе

Катасонова Наталья Сергеевна – выпускник кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Применение каскадной, итерационной и спиралевидной моделей внедрения информационных систем для автоматизации городской больницы». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №22

1. Agile Feature Driven Development для автоматизации МПЗ (часть 1);
2. Каскадная методология для разработки мобильных приложений (часть 1);
3. Кастомные и коробочные программные решения;
4. Моделирование бизнес-процессов в ERP-проектах;
5. Стратегия выхода на рынок программного обеспечения.