Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте.
Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3].
Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.
Исходя из практического опыта, можно выделить две основные цели моделирования процессов и организационных структур:
- оптимизация и усовершенствование процессов, которые обычно ведутся после внедрения информационных систем с целью выявления «узких мест» работы компании и их устранения;
- демонстрация и визуализация операций, позволяющая детально понять будущий бизнес-процесс, формирующийся в ходе внедрения ERP-решения.
Следует отметить, что имплементация ИТ-решения также может вестись по двум сценариям:
- кардинальное изменение программного продукта под бизнес-процессы заказчика (реинжиниринг ПО);
- и наоборот, принятие стандартного программного решения и подстраивание процессов под него (реинжиниринг процессов).
В обоих случаях визуализация бизнес-операций приветствуется [4].
Закономерно, что оптимизация операций и оргструктур требует глубокого анализа и понимания существующих процессов. Именно поэтому, не смотря на высокие трудозатраты: более 10 000 операций к описанию, ведется их моделирование в заданной графической нотации в схеме «Как есть». При этом моделированию подлежат операции на всех уровнях декомпозиции 1-8, так как коллизии и противоречия могут находиться где угодно. В этом случае службу внутреннего контроля, а обычно именно она занимается подобными задачами, не пугает ни высокий объём работ для проектирования, ни постоянно меняющиеся регулярные процессы («Как есть» процессы претерпевают обновления в виду изменений законов РФ и внутренних регламентов). Более того описание бизнес-процессов компании свидетельствует о высоком уровне зрелости организации, позволяющим улучшать как свои, так и процессы вовлеченных контрагентов (рис. 1). Таким образом, моделирование операций и оргструктур оправдано, не взирая на большой объем работ [6].
Рис. 1. Уровни зрелости компании с точки зрения описания процессов
Вернемся к вопросу внедрения ERP-систем. Если проект имплементации сопровождается реинжинирингом программной системы, переделываемой полностью под заказчика, то, по-видимому, клиент категорически уверен в оптимальности существующих регулярных бизнес-процессов и неоптимальности коробочного программного решения. Следовательно, потребность в моделировании процессов для целей их оптимизации отсутствует: они и так оптимальны по мнению заказчика. Если же мы говорим о реинжиниринге бизнес-процессов, то здесь дело обстоит схожим образом: часто внедрение системы ERP рассматривают как способ улучшения процессов. Таким образом, предлагаемое программное решение оптимально по умолчанию. И в первом, и во втором случаях проектирование процессов может пригодиться, но не с точки зрения улучшения бизнес-операций, а для обеспечения наглядности.
Полный текст статьи: https://corpinfosys.ru/archive/2023/issue-22/226-2023-22-businessprocessmodelling
