Вход, Управление или Механизм?

Согласен с положениями статьи Сергея Рубцова «Опыт использования стандарта IDEF0» (2003, № 1), однако часть «Функциональная модель бизнес-процесса», где автор предлагает свою оригинальную интерпретацию стандартных интерфейсов методологии IDEF0, вызывает у меня ряд возражений.

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

Напомню, что в статье вводится классификация ресурсов.

1. Признак изменчивости "Ресурса" при исполнении "Работы".
1.1. "Ресурсы", подлежащие трансформации в другие виды "Ресурсов".
1.2. Нетрансформируемые "Ресурсы".
1.2.1. Неизнашиваемые "Ресурсы". Например, большая часть информационных "Ресурсов" в электронной форме являются неизнашиваемыми.
1.2.2. Изнашиваемые (устаревающие) "Ресурсы". Например, вспомогательные инструменты, персонал.
2. Признак блокировки "Ресурса" "Работой", исключающий возможность использования "Ресурса" другими "Работами".
2.1. "Ресурсы", которые не могут блокироваться "Работами" ("Ресурсы" общего пользования).
2.2. Блокируемые "Ресурсы".

Далее показывается, к какому из трех возможных входов следует относить ресурс в зависимости от места, занимаемого им в предложенной классификации. Вот здесь, как мне кажется, и содержатся некоторые неувязки.

1. Нетрансформируемый, неизнашиваемый и неблокируемый ресурс по схеме автора безусловно относится к Управлению. Однако данному критерию отвечает, например, любая программная система. Действительно, программная система при выполнении некоего бизнес-процесса не трансформируется (если только этот бизнес-процесс не является разработкой или отладкой программной системы), не изнашивается (здесь не рассматривается моральное старение) и не блокируется - программная система одновременно используется разными пользователями в совершенно разных бизнес-процессах. Но вряд ли кто будет утверждать, что программная система может быть отнесена к Управлению. Все-таки это больше похоже на Механизм.
2. Не определено, к какому входу относить нетрансформируемый, неизнашиваемый и блокируемый ресурс. Таким ресурсом является, например, любой справочный файл, используемый при выполнении некого бизнес-процесса программной системой в монопольном режиме.
3. Не определено, к какому входу относить трансформируемый, неизнашиваемый и неблокируемый ресурс. Таким ресурсом является, например, файл проводок, в который записываются бухгалтерские проводки при выполнении разных бизнес-процессов разными пользователями.
4. Не определено, куда (Управление или Вход) относить трансформируемый, неизнашиваемый и блокируемый ресурс. Таким ресурсом является, например, файл проводок, в который записываются бухгалтерские проводки при выполнении разных бизнес-процессов разными пользователями, но используемый программной системой в монопольном режиме.
5. Не определено, к какому входу относить трансформируемый, изнашиваемый и неблокируемый ресурс. Судя по всему, такой комбинации возникнуть не должно - понятие "изнашиваемый", мне кажется, может относиться только к материальному объекту. Но материальный объект физически не может находиться одновременно в двух и более местах - перерабатываться в одном бизнес-процессе (быть трансформируемым) и как-то использоваться в другом бизнес-процессе (не быть блокированным). Однако строгого доказательства невозможности такого факта нет, поэтому наличие такой неопределенности, по-моему, нежелательно.

Приведу примеры, в которых следование данной классификации не приводит к желаемому результату.

Пример 1. Рассмотрим очень простой бизнес-процесс: операционист принимает платежное поручение, проверяет его, вводит информацию в базу и откладывает платежку для помещения в документы дня банка в конце рабочего дня. (Процесс намеренно упрощен). В этом случае, по классификации Сергея Рубцова, я отношу платежное поручение к нетрансформируемым, неизнашиваемым и блокируемым ресурсам. Строго говоря, куда относить такой ресурс, у автора не определено. Но, судя по нумерации пунктов, признак трансформации имеет приоритет над признаком блокировки и, зная, что ресурс НЕтрансформируемый (не Вход), относим его к Управлению или Механизму. Вспоминая, что платежка — еще и неизнашиваемый ресурс, относим ее к Управлению. Итак, в данном случае платежка — это Управление!

Теперь чуть изменим процесс. Операционист принимает платежное поручение, проверяет его, подписывает, вводит информацию и откладывает платежку для помещения в документы дня банка в конце рабочего дня. Теперь уже по анализируемой классификации платежное поручение — трансформируемый, неизнашиваемый и блокируемый ресурс, и должен быть отнесен либо ко Входу, либо к Управлению. Вспоминая о приоритете признака трансформируемости, относим платежку к Входу. Итак, в данном случае платежка — Вход!

Но ведь ничего не произошло! Между двумя процессами нет никакой разницы ни в смысле подготовки к ним, ни в смысле результата. Платежка как должна была попасть к операционисту так, ровно в том же виде, к нему и попадет. Единственное что изменилось — это на схеме декомпозиции этого процесса добавилась еще одна работа «Визирование платежки». Так почему же платежка поменяла статус?! Непонятно. Было бы правильнее в обоих случаях считать платежное поручение Входом.

Пример 2 (обратный). Токарь вытачивает на станке простую серийную деталь. Чертеж ее, конечно, где-то существует, но реально он токарю, который их делает сотнями, не нужен. В другом случае токарь изготавливает сложную уникальную деталь, поминутно сверяясь с чертежом. В обоих случаях по предложенной классификации чертеж — нетрансформируемый, неизнашиваемый и блокируемый ресурс. С помощью рассуждений, аналогичных рассуждениям в первой части примера 1, убеждаемся, что в обоих случаях чертеж необходимо отнести к Управлению.

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

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

Указанных недостатков лишена другая классификация ресурсов.

1. Ресурс-исполнитель - любой ресурс, исполняющий бизнес-процесс или его часть. Понятие "исполняющий" интуитивно понятно. При этом необходимым признаком ресурса-исполнителя является то, что он при исполнении бизнес-процесса не перерабатывается и служит только лишь "катализатором" процесса, и ни он сам и никакая его часть не могут быть составной частью результата исполнения процесса.
2. Ресурс-активатор - любой ресурс, который не является ресурсом-исполнителем и физическое наличие которого необходимо для того, чтобы процесс мог закончиться.
3. Ресурс-справка - любой ресурс, который не является ни ресурсом-исполнителем, ни ресурсом-активатором. Ресурс-справка накладывает на процесс определенные ограничения, которые необходимо соблюдать и которым необходимо следовать при выполнении данного бизнес-процесса.
4. Других видов ресурсов не существует.

Правила соотнесения типов ресурсов и трех возможных входов бизнес-процесса могли бы для такой классификации выглядеть следующим образом.

1. Механизм - любой ресурс-исполнитель независимо от других его свойств.
2. Вход - любой ресурс- активатор независимо от других его свойств.
3. Управление - любой ресурс-справка.

Легко убедиться, что в этом случае будут устранены все недостатки и неопределенности изложенные ранее .