Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [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].

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

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

Карта позволяет увидеть набор низкоуровневых операций, задающих бизнес-процесс без каких-либо деталей, присущих графическим нотациям. Поэтому, применение нотаций на верхних уровнях не дает преимуществ. Наоборот, использование CASE-технологий на низких уровнях обеспечивает необходимую степень наглядности для понимания процесса …

Литературный источник, полный текст статьи

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