Секреты моделирования
Автор: Сергей Рубцов
Настоящая статья является развитием статьи [1], в которой обсуждались свойства CASE-инструментов как фильтров проектного «шума» или разнообразия по Биру и отстаивалась идея о необходимости последовательного применения мета-стандартов организационного проектирования, сужающих творческую свободу проектировщика. В отличии от предыдущей статья носит более прикладной и практический характер. Автор делится мнением о полезных, на его взгляд, мета-стандартах, направленных на сужение стандартов проектирования и сформулированных в виде установочных концепций. Реализация способов снижения разнообразия иллюстрируется на примере стандарта IDEF0. Приведенные рекомендации базируются как на личном опыте проектной работы автора, так и на общезначимой логике системных исследований.
Сергей Рубцов
Общие положения
Чтобы приготовить блюдо, недостаточно знать его ингредиенты и их пропорции. Необходимы еще знания технологий изготовления продукта. Объективно, современные методики организационного проектирования предлагают лишь описание ингредиентов и очень приближенное описание технологий получения продукта, оставляя широкое поле для творчества проектировщика. И это, наверное, правильно. Ведь субъективные интерпретации и детализации этих методологий могут быть не менее ценными, чем сами методологии.
Многообразие возможных точек зрения на принципы моделирования и содержание понятия “бизнес-процесс” (БП), с которым сталкивается проектировщик бизнес-процессов, с одной стороны, возбуждает его центры креативности, а, с другой стороны, существенно осложняет решение проектной задачи в заданные сроки. В статье [1] автор отстаивал точку зрения на то, что проектировщику следует активизировать свою креативность в максимально узких рамках. Творческая свобода проектировщика ограничивается:
(1) стандартом проектирования БП,
(2) отраслевыми стандартами БП,
(3) ранее принятыми стандартами проектирования БП предприятия и
(4) установочными концепциями.
Например, стандартами проектирования БП являются семейство стандартов IDEF (Госдепартамент и BBC США), RUP (Rational Software), Catalysis (Computer Associates). Отраслевыми стандартами являются модели, разрабатываемые государственными и международными общественными организациями (рекомендации ISA, APICS, ISO, TM Forum и др.). Стандарты предприятия обычно составляют подмножество стандартов (1) и (2), обогащенное процедурными правилами разработки и согласования моделей БП, принятых на предприятии.
Какими бы ни были жесткими нормативные ограничения всегда найдутся неопределенная ими область творчества для постановщика задачи и ее исполнителя, а также возможности по интерпретации этих ограничений. Согласованные точки зрения постановщика и исполнителя проектной задачи дополняющие и непротиворечащие нормативным ограничениям назовем установочными концепциями. Ими могут быть:
цели моделирования (реинжиниринг БП, автоматизация БП и внедрения информационных систем, системные исследования БП и др.);
интерпретация стандартов (1 - 3) как заказчиком проектных работ, так и сами проектировщиком;
принципы формирования словаря проекта и соглашения об основных понятиях, неопределенных стандартами (1 - 3) или нуждающиеся в уточнении.
Установочные концепции апробированные на практике могут являться основой для разработки предложений по совершенствованию стандартов предприятия.
Автор не ограничивается рассмотрением одной из целей моделирования, а концентрируется на аспектах моделирования БП, имеющих общую значимость. Исходным контекст статьи - это абстрактный проект, цель которого - разработка модели БП, а предметом обсуждения является задача «настройки» ограничений (3-4) на этот проект. Фактически речь идет о процессе приспособления стандарта (tailoring process) и точек зрения проектировщика, который, как правило, содержит огромные возможности для привнесения субъективных решений - как по воле проектировщика, так и заказчика проектных работ. Поэтому автор видит необходимость в дополнительных методические рекомендациях, которые сузили бы область творческого «произвола» при модификации стандартов проектирования БП. В частности, такие рекомендации должны быть даны и в отношении конкретизации языков моделирования БП.
Чтобы сопроводить мнение автора по этому вопросу конкретными примерами и мотивировками требуется определенный контекст. Рассмотрим рекомендации по конкретизации языков моделирования БП в контексте методологии IDEF0. Данный выбор не является принципиальным, а лишь является отражением субъективных пристрастий автора. При этом следует иметь в виду, что предлагаемые принципы формирования рекомендаций и логика их применения могут быть легко распространены на отличные от IDEF0 методики проектирования БП с учетом трех аспектов моделирования БП: функционального моделирования, моделирования событий и ресурсов и унификации описания БП.
Функциональная модель БП
Любой стандарт проектирования БП базируется на исходных понятиях – смысловых примитивах. В частности, стандарт IDEF0 в качестве таких примитивов использует понятия “Работа” (Activity) – для обозначения, собственно, действия, а также следующие обозначения интерфейсов: “Вход” (Input), “Выход” (Output), “Управление” (Control) и “Механизм” (Mechanism), которые составляют графическую конструкцию “Общая модель БП (А)”, изображенную на Рис.1. К сожалению, в стандарте IDEF0 эти примитивы определяются довольно обще. Поэтому пользователи стандарта обычно прибегают к интерпретациям примитивов. Например, только на первый взгляд кажется конструкция (Рис.1) логичной, а формирование дополнительных концептуальных установок - ненужным. Как правило, у начинающего пользователя, возникает недоумение, когда ему необходимо отнести понятие “Распоряжение” или к интерфейсу “Управление”, или к интерфейсу “Вход”. Или другой пример. Куда отнести понятие “расходные материалы” - к “Входу” или “Механизму” при моделировании работы канцелярии? Далее больше… Стандарт IDEF0 исполнителей “Работ” (одушевленных и неодушевленных) относит к интерфейсу “Механизм”. На уровне бытового сознания это не вызывает вопросов. Однако, если вдуматься в суть понятия “исполнение”, то становится ясным, что исполнитель “Работ” является активатором “Работ”, составляющих данную “Работу” и приводящих к ее исполнению. Однако, активатором “Работ” согласно IDEF0 является “Вход”.
Таких логико-лингвистических противоречий во встречающихся интерпретациях профессиональные пользователи стандарта IDEF0 могут привести много. Приведенные примеры говорят о том, что проектировщику так или иначе придется заузить стандарт IDEF0, если для него важна непротиворечивость модели.
Для практического удобства может быть предложена иная (зауженная) интерпретация исходных примитивов стандарта IDEF0 (см. Рис.1 “Общая модель БП (В)”). Основная идея предлагаемой рекомендации по конкретизации языков моделирования БП состоят в следующем:
(1) Все “Работы” принадлежат одному классу, т.е. обладают одинаковым набором свойств и поведением. Этот важный и часто нарушаемый принцип отдельно обсудим ниже.
(2) Все связи между “Работами” относятся к классу “Ресурс”. Например, электронное издание “Налогового кодекса РФ” является общедоступным информационным ресурсом.
(3) Для однозначной “привязки” ресурсов к трем возможным входам БП на множестве “Ресурсов” вводится следующая классификация.
1. Признак изменчивости “Ресурса” при исполнении “Работы”.
1.1. “Ресурсы”, подлежащие трансформации в другие виды “Ресурсов”.
1.2. Нетрансформируемые “Ресурсы”.
1.2.1. Неизнашиваемые “Ресурсы”. Например, большая часть информационных “Ресурсов” в электронной форме являются неизнашиваемыми.
1.2.2. Изнашиваемые (устаревающие) “Ресурсы”. Например, вспомогательные инструменты, персонал.
2. Признак блокировки “Ресурса” “Работой”, исключающий возможность использования “Ресурса” другими “Работами”
2.1. “Ресурсы”, которые не могут блокироваться “Работами” (“Ресурсы” общего пользования)
2.2. Блокируемые “Ресурсы”
Рис.1. Общая модель БП
Правила разводки “Ресурсов”, классифицируемых по описанным выше признакам, по интерфейсам, заданным стандартом IDEF0, иллюстрируются на примере “Работы” “Общая модель БП (В)” (см. Рис.1). При желании можно убедиться, что предлагаемая интерпретация смыслового содержания интерфейсов IDEF0-стандарта, не только полностью соответствует требованиям этого стандарта, но и лишена возможных логико-лингвистических противоречий, свойственных иным интерпретациям.
События и ресурсы
Важнейшей компонентой моделирования БП является оценка материальных, стоимостных и временных ресурсов, необходимых для исполнения всего множества процессов. В современных инструментах проектирования, поддерживающих стандарт IDEF0 используется для этих целей функционально-стоимостной анализ (ФСА), а расчеты производятся методом непосредственной имитации исполнения “Работ”. Можно встретить мнение, что одним из недостатков IDEF0-моделей, в которых по тем или иным причинам не определяются моменты активации работ, является ошибка ФСА, вызванная фактором нарушения последовательности “Работ”. Эта ошибка считается допустимой для приближенных расчетов. Для более точных расчетов предлагается использовать иные инструменты. Например, в BPwin наличествует возможность экспорта данных в систему EasyABC. На взгляд автора, это слишком дорогое решение для такой простой задачи. Что мешает нам определить более четко моменты активации “Работ” на IDEF0-диаграммах?
Считается, что основным отличием стандартов, нацеленных на функциональное или процессное моделирование, является их возможности по описанию событий и последовательности исполнения «Работ» во времени. В известных руководствах [4] пользователям стандартов IDEF0 и IDEF3 настойчиво навязывается идея различном их назначении, говорится об отличиях интерпретации стрелок в IDEF0 и в моделях потока работ [5, стр. 9]. Покажем, что это очень далеко от действительности.
Для справки тексты из стандарта:
«Arrows do not represent flow or sequence as in the traditional process flow model. Arrows convey data or objects related to functions to be performed [5, стр. 9].
«Arrows on an IDEF0 diagram represent data or objects as constraints. Only at low levels of detail can arrows represent flow or sequence, when the modeled subject is sufficiently detailed to treat specific changes made to specific data items or objects» [5, стр. 17].
«A box may perform various parts of its function under different circumstances, using different combinations of its input and controls and producing different outputs. These different performances are called the different activations of the box» [5, стр. 17].
«Think control and constraint, not flow. A basic rule for layout of the arrow structure is «constrain, don’t sequence.» That is, make the diagram structure show relationships that must be true no matter which sequence is followed. Even though something must progress from stage to stage to reach some desired end result, try to express the constraints that must be satisfied or the invariant properties. that must be true rather than some one specific sequence of steps that will yield that result. The reason is that all boxes may be active simultaneously. Thus, sequence has no meaning. It is always more powerful to constrain than to sequence. Wherever possible, diagrams should be created that say the right thing regardless of what steps are taken first. Clearly, this is better than restricting to only one of the possible sequences» [5, стр. 58].
Во-первых, будем исходить из положения - «что не запрещено стандартом, то разрешено им». Следуя этому правилу покажем, что IDEF0 никак не запрещает изображать события и определять последовательность «Работ» с помощью стрелок.
Начнем с базового замечания о том, что в IDEF0 активаторами работ определены стрелки [5, стр. 17]. К сожалению, сущность такой активации в стандарте не поясняется. Логично напрашивается предположение, что активация – это принуждение к исполнению «Работы» или, как минимум, изменение состояния «Работы», которое можно тоже толковать как начало исполнения «Работы». При этом, активация может толковаться широко. Например, отсутствие информации на входе «Работы» может рассматриваться тоже как активация. Тут нет нарушений логики.
Однако, стандарте существуют неразъясняемые странности. Например, синтаксически не различаются «Работы», находящиеся на различных уровнях декомпозиции. Отличия же между ними существенны. Согласно, положению стандарта о том, что активаторами «Работ» являются стрелки, а на нижнем уровне декомпозиции БП стрелки описывают последовательность исполнения «Работ» [5, стр. 17], можно утверждать, что каждая «Работа» на нижнем уровня декомпозиции модели активируется только при активации всех ее входов. К сожалению, из текста стандарта никак не следует, что считать условиями активации «Работы» более высокого уровня. Стандарт рекомендует проектировщику, по возможности, не задумываться над этой проблемой, однако не настаивает на этом определенно [5, стр. 58]. Если не «вырывать» фразы из контекста, то читатель стандарта может в этом самостоятельно убедиться.
Существует еще аспект времени, который стандартом замалчивается – момент завершения «Работы». Без его знания ФСА, основанный на моделировании, не будет завершен. Можно «прятать голову в песок» и не определять условие активации «Работы», но момент ее завершения мы видеть обязаны. Следовательно, к временному фактору мы подходим с другого конца. К счастью, ответ на вопрос о моменте завершения «Работы» тривиален. «Работа» не может быть завершена пока все ее входы не будут активированы. Теперь и нематематику должно быть ясным, что известные условия активации «Работ» на диаграммах нижнего уровня и известные условия окончания «Работ» на верхних уровнях позволяют однозначно восстановить информацию об условиях активации «Работ» на всех уровнях. Т.е. условия активации «Работ» в IDEF0 являются предопреленными. Может быть именно в этом был смысл пожеланий стандарта не задумываться над этой проблемой?
Итак, мы показали, что, с одной стороны, пожелание неисполнимо… при попытке проведения корректного ФСА, а с другой - пожелание не есть запрет. Основываясь на этом выводе, рассмотрим один из возможных вариантов конкретизации описания событий в IDEF0.
В жизни организации происходит огромное множество событий. Обыденное сознание мирно уживается с этим фактом. Система ARIS именно использованием смыслового примитива “Событие” часто приводит в восторг специалистов, имеющих опыт разработки программных продуктов и вовлеченных по тем или иным причинам в организационное проектирование.
И все же существуют серьезные сомнения в необходимости не моделирования событий, а использования примитива “Событие” для целей моделирования событий. Это обусловлено тем, что мы имеет дело не с самими явлениями, а с информацией о явлениях, воспринимаемой как событие. Такое событие является информационным “Ресурсом”. Т.к. БП обмениваются друг с другом только “Ресурсами” и ничем иным, то абсолютно ясно, что класс “Событие” является вырожденным. Т.е. в “жизни” БП существует только один подкласс событий – “Поступление Ресурса”, а сами “События” различаются видом “Ресурса”. Другими словами, стрелки на IDEF0-диаграммах однозначно соответствуют “Событиям”, а включение примитива “Событие” в любой стандарт проектирования БП ничем не оправдано и является избыточным, по меньшей мере, тогда, когда мы придерживаемся ресурсной концепции управления организацией. Собственно, этот же вывод целиком распространяется на объекты, называемые “перекрестками” в стандарте IDEF3.
Итак, формулировка еще одной установочной концепции выглядит так.
Исполнение “Работы” безусловно инициируется событием “Поступление Ресурса”. Это соответствует классическим представлениям о том, что любое воздействие влечет реакцию. Не бывает воздействий без рефлексии на него. Это аксиома. Поэтому поступление любого ресурса является управляющим воздействием.
Необходимым (но не достаточным!) условием завершение “Работы” является свершение полного набора событий “Поступление Ресурса”, связанных с интерфейсами “Работы”.
На мой взгляд, приведенная установочная концепция делает изобразительные свойства стандарта IDEF0 не только достаточными для описания ситуаций и условий исполнения “Работ” при моделировании организации, но и более выразительными, простыми и эффективными.
Об унификации описания БП
В качестве первой установочной концепции, выше озвучивалась идея о принадлежности “Работ” одному классу объектов, обладающих одинаковым набором свойств и поведением. Для чего это нужно? Во-первых, для того, чтобы различные “Работы” могли общаться друг с другом на одном языке. Только в этом случае БП может быть открытой системой. О необходимости придерживаться идеологии открытых систем при проектировании модели БП, как необходимом условии реализации принципа последовательных модернизаций писалось не раз [1, 2]. Только открытым системам свойственен низкий уровень издержек при сопровождении и доработках систем.
На моделирование БП согласно методологии IDEF и первым ее интерпретациям был ориентирован стандарт IDEF3. Основным его отличием от стандарта функционального моделирования IDEF0 была возможность задавать последовательность “Работ” с помощью дуг и условия на последовательность исполнения “Работ” с помощью логики “перекрестков” (синхронные и асинхронные ИИЛИ, исключающее ИЛИ). Предполагалось, что проектировщик, не вдаваясь в описание логики взаимодействия “Работ” разработает функциональную IDEF0-модель до определенного уровня декомпозиции “Работ”, а затем на нижних уровнях прейдет на моделирование БП в соответствии со стандартом IDEF3, уже отображая логику взаимодействия “Работ”. Поскольку уровень декомпозиции IDEF0-модели, на котором осуществляется переход на стандарт IDEF3, определяется проектировщиком субъективно, то говорить о какой-либо универсальности представлений БП при таком подходе не приходится.
Как было показано, предлагаемая конкретизация положений IDEF0 в части описания событий и, следовательно, логики, делает его неуступающим по функциональности стандарту IDEF3. Например, в рамках ресурсной концепции управления организацией дуги в стандарте IDEF0 также могут показывать последовательность исполнения “Работ”, а условия исполнения “Работ” задаются событиями “Поступление Ресурса”. Возможно, это явилось одной из причин, почему в популярном BPwin (Computer Associates) диаграммы, поддерживающие стандарт IDEF0, называются “Business Process Diagram”. Одно можно сказать точно, что одновременное использование стандартов IDEF0 и IDEF3 в рамках одного проектного процесса никак не способствует однозначному пониманию понятия БП в системе стандартов IDEF.
Что такое “Работа” интуитивно ясно. Сложнее обстоит дело с БП, описываемого «Работами». В статье автора [3] приведено 10 различных определений БП, добытых из авторитетных источников, и показано, на сколько сложен логико-лингвистический анализ определений БП на смысловую непротиворечивость. Там же приводится авторское определение БП и доказывается его преимущество. Поскольку читатель может ознакомиться с работой [3] самостоятельно, в данной статье для лучшей наглядности поступим иначе – дадим определение БП, используя графическую нотацию IDEF0 и рекомендации по адаптации языка, сформулированные ранее. При разработке общей модели БП автором использовались следующие установочные концепции, заимствованные из модели взаимодействия открытых систем, методических материалов ассоциаций документарной электросвязи и телекоммуникационного сообщества:
На вход БП поступают с выходов БП-контрагентов ресурсы, которые преобразуются в БП в другие виды ресурсов, поставляемые БП-контрагентам.
Все БП в организации объединены одной задачей – оказанием услуг друг другу на основе анализа запросов о поставке услуг. В частности услугой может быть изготовление и поставка продукта.
Оказание услуг друг другу БП осуществляют согласно единой для всех БП процедуре.
Рис.1. Универсальная модель БП
На Рис.2 представлена универсальная IDEF0-модель БП, в которой показана сущность интерфейсов “Работы”, как правило, не раскрываемая проектировщиками БП при моделировании БП. Особенностью этого графического определения является акцентирование его на интерфейсах БП, описываемых в виде отдельных “Работ”. Часто осознание в необходимости интерфейсов приходит к проектировщику с запозданием, вынуждая его переделывать модель или возлагать функции интерфейсов рассматриваемого БП на БП-контрагенты. На взгляд автора, является желательным при декомпозиции БП на составляющие «принудительно» создавать сначала промежуточную IDEF0-диаграмму, на которой изображены «Работы» - входные и выходные интерфейсы БП и «Работа», отражающая сущность БП (последняя - то, чем обычно ограничивается неопытный проектировщик). Этого можно не делать только в случае, если проектировщиком четко осознанно отсутствие необходимости разрабатывать интерфейсы БП.
Замечу, что структура предложенной модели БП не является изобретением автора, а соответствует современным представлениям о структуре систем, в том числе и систем управления.
Концепции, перечисленные выше, довольно жестко ограничивают множество возможных способов унификации БП. Один из них представляет БП в виде триады “Работ”: “Анализ реакции внешней среды”, “Моделирование”, “Воздействие на внешнюю среду”. Эта идея изложена в [1] и основана на предположении, что организация – это система процессов “рефлексии”. Важнейшим элементом БП является “Моделирование”. Выбор этого термина диктуется точкой зрения автора на то, что БП обмениваются друг с другом не объектами «реального» мира, а представлениями о них. Только эта точка зрения позволяет адекватно переходить к задаче оценки стоимости услуг или продуктов.
Моделирование - “Работа”, отвечающая за непосредственное преобразование поставляемых БП “Ресурсов” и формирование новых “Ресурсов” (натурное моделирование), поставляемых другим БП. Другой важнейшей функцией этой “Работы” является планирование (или программирование) поставок “Ресурсов” другим БП. План поставок строится для рассматриваемого БП с использованием модели его внешней среды (например, на основе заявок на поставку ресурсов). Входным интерфейсом БП является “Анализ реакции внешней среды” - “Работа”, обеспечивающая на основе модели внешней среды и правил наблюдения “фильтрацию” поступающих “Ресурсов” и формирование необходимых спецификаций (описаний) “Ресурсов”, необходимых для исполнения “Моделирования”. Выходным интерфейсом БП является “Воздействие на внешнюю среду” - “Работа”, осуществляющая поставку “Ресурсов” БП-контрагентам на основе плана поставок, а также направляющая отчеты о поставках “Моделированию”.
Заключение
Механическое следование требованиям стандарта IDEF0 приводит, как правило, к игнорированию интерфейсов БП или к неполноте их описания. Основная беда состоит не в том, что большая часть логики БП оказывается упущенной (ее можно восстановить позже), а в том, что логика операций, которые должны принадлежать одному из БП, часто возлагается проектировщиком на другие БП. Тем самым еще больше разрушается структурная однородность и универсальность представления БП.
Следование проектировщиком предложенному выше способу унификации описания БП, по мнению автора, позволяет избежать таких неприятностей.
На сколько предложенный подход к унификации описания БП будет полезен конкретному проектировщику БП, зависит в сильной степени от его личных пристрастий, опыта успешно реализованных проектов и иных обстоятельств. Что касается автора, то предложенные им “рецепты” являются выжимками приобретенного опыта при разработке процессных моделей нескольких организаций. Сущность рекомендаций выражается в направленном сужении стандартов организационного проектирования. Целью такого сужения является “погружение” проектировщика в мир строгих абстракций, предлагаемых системной идеологией и общей теорией управления. Автор надеется, что рекомендации окажутся полезными директорам информационных служб при постановке задач системным аналитикам и определении ими требований к стандартам разработки информационных систем или, по меньшей мере, послужат катализатором конструктивной критики.