Об унификации описания бизнес-процессов

В качестве первой установочной концепции озвучивалась идея о принадлежности «Работ» одному классу объектов, обладающих одинаковым набором свойств и поведением. Для чего это нужно? Прежде всего, для того чтобы различные «Работы» могли общаться друг с другом на одном языке. Только в этом случае бизнес-процесс может быть открытой системой. О необходимости придерживаться идеологии открытых систем при проектировании модели бизнес-процессов как необходимом условии реализации принципа последовательных модернизаций писалось не раз [1, 2]. Только открытым системам свойственен низкий уровень издержек при сопровождении и доработках.

На моделирование бизнес-процессов, согласно методологии IDEF и первым ее интерпретациям, был ориентирован стандарт IDEF3. Основным его отличием от стандарта функционального моделирования IDEF0 была возможность задавать последовательность «Работ» с помощью дуг и условия на последовательность исполнения «Работ» с помощью логики «перекрестков» (синхронные и асинхронные И\ИЛИ, исключающее ИЛИ). Предполагалось, что проектировщик, не вдаваясь в описание логики взаимодействия «Работ», разработает функциональную IDEF0-модель до определенного уровня декомпозиции «Работ», а затем на нижних уровнях перейдет на моделирование бизнес-процессов в соответствии со стандартом IDEF3, отображая уже логику взаимодействия «Работ». Поскольку уровень декомпозиции IDEF0-модели, на котором осуществляется переход на стандарт IDEF3, определяется проектировщиком субъективно, то говорить о какой-либо универсальности представлений бизнес-процессов при таком подходе не приходится.

Как было показано, предлагаемая конкретизация положений IDEF0 в части описания событий и, следовательно, логики, не уступает по функциональности стандарту IDEF3. Так, в рамках ресурсной концепции управления организацией дуги в стандарте IDEF0 также могут показывать последовательность исполнения «Работ», а условия исполнения «Работ» задаются событиями «Поступление Ресурса». Возможно, это явилось одной из причин, почему в популярном инструментарии BPwin диаграммы, поддерживающие стандарт IDEF0, называются Business Process Diagram. Одно можно сказать точно: одновременное использование стандартов IDEF0 и IDEF3 в рамках одного проектного процесса никак не способствует однозначному пониманию понятия «бизнес-процесс» в системе стандартов IDEF.

Что такое «Работа», интуитивно ясно. Сложнее обстоит дело с бизнес-процессом, описываемым «Работами». В статье [3] собрано 10 различных определений бизнес-процесса и показано, насколько сложен логико-лингвистический анализ определений бизнес-процесса на смысловую непротиворечивость; там же приводится авторское определение. Для большей наглядности дадим определение бизнес-процесса, используя графическую нотацию IDEF0 и рекомендации по адаптации языка, сформулированные ранее. При разработке общей модели автором использовались установочные концепции, заимствованные из модели взаимодействия открытых систем, методических материалов ассоциаций документарной электросвязи и телекоммуникационного сообщества.

1. На вход бизнес-процесса поступают с выходов процессов-контрагентов ресурсы, которые преобразуются в бизнес-процессе в другие виды ресурсов, поставляемые контрагентам.

2. Все бизнес-процессы в организации объединены одной задачей — оказанием услуг друг другу на основе анализа запросов о поставке услуг. В частности, услугой может быть изготовление и поставка продукта.

3. Оказание услуг друг другу бизнес-процессы осуществляют согласно единой процедуре.

На рис. 1. представлена универсальная IDEF0-модель бизнес-процесса, показывающая сущность интерфейсов «Работы»; как правило, проектировщики бизнес-процессов при их моделировании ее не раскрывают. Особенность этого графического определения — его акцентирование на интерфейсах бизнес-процессов, описываемых в виде отдельных «Работ». Часто осознание необходимости интерфейсов приходит к проектировщику с запозданием, вынуждая его переделывать модель или возлагать функции интерфейсов рассматриваемого бизнес-процесса на его контрагенты. В этом случае желательно «принудительно» создавать сначала промежуточную IDEF0-диаграмму, на которой изображены «Работы»: входные и выходные интерфейсы бизнес-процесса и «Работа», отражающая сущность бизнес-процесса (ею обычно ограничивается неопытный проектировщик). Этого можно не делать только в случае, если проектировщиком осознанно отсутствие необходимости разрабатывать интерфейсы бизнес-процессов. Структура предложенной модели бизнес-процессов соответствует современным представлениям о структуре систем, в том числе и систем управления.

Перечисленные концепции довольно жестко ограничивают множество возможных способов унификации бизнес-процессов. Один из них представляет бизнес-процессы в виде триады «Работ»: «Анализ реакции внешней среды», «Моделирование», «Воздействие на внешнюю среду». Данная идея изложена в [1] и основана на предположении, что организация — это система процессов «рефлексии». Важнейшим элементом является «Моделирование». Выбор этого термина диктуется точкой зрения автора на то, что бизнес-процессы обмениваются друг с другом не объектами «реального» мира, а представлениями о них. Такая точка зрения позволяет адекватно переходить к задаче оценки стоимости услуг или продуктов.

Моделирование — «Работа», отвечающая за непосредственное преобразование поставляемых бизнес-процессом «Ресурсов» и формирование новых «Ресурсов», поставляемых другим бизнес-процессом. Другой важнейшей функцией этой «Работы» является планирование (или программирование) поставок «Ресурсов» другим бизнес-процессом. План поставок строится для рассматриваемого бизнес-процесса с использованием модели его внешней среды (скажем, на основе заявок на поставку ресурсов). Входным интерфейсом бизнес-процесса является «Анализ реакции внешней среды» (т.е. «Работа», обеспечивающая на основе модели внешней среды и правил наблюдения «фильтрацию» поступающих «Ресурсов» и формирование необходимых спецификаций «Ресурсов», требуемых для исполнения «Моделирования»). Выходным интерфейсом бизнес-процесса является «Воздействие на внешнюю среду» (т.е. «Работа», осуществляющая поставку «Ресурсов» контрагентам на основе плана поставок, а также направляющая отчеты о поставках «Моделированию»).