С чего начинается описание бизнес процесса в методике idef0

Описание нотации IDEF0

IDEF0, нотация для описания структуры, или верхнего уровня бизнес-процесса

Пример верхнеуровневой структуры деятельности представлен на рисунке ниже. Именно так хочется называть – «верхнеуровневая структура», «функциональная структура». В этом, на наш взгляд, суть нотации IDEF0.

Система обозначений IDEF0 довольно проста.

Бизнес-процесс в обозначениях IDEF0 – прямоугольник (блок), его связи с элементами внешней среды или другими процессами – это стрелки. Это базовый минимум, с которого можно начинать знакомиться с нотацией, пробовать фиксировать в ней какие-то первые процессы «в карандаше». Внутри прямоугольника (блока) вписывается название функции/процесса и его номер.

Стрелки в IDEF0 могут быть:

Как на рисунке выше, стрелки подписываются наименованием соответствующих потоков объектов, которые они перемещают: входы (документы, информацию) и выходы, механизмы и управляющие потоки.

К базовому, начальному уровню понимания нотации IDEF0, постепенно можно добавить еще несколько элементов из системы обозначений, чтобы полноценно владеть данным «языком» графического описания бизнес-процессов.

Внешняя ссылка – элемент нотации, который обозначает некий субъект, некую сущность, которая находится вне границ моделируемой системы, за границами описываемого процесса. Внешняя ссылка выступает как приемник или как источник стрелок в IDEF0 и обозначается на моделях (диаграммах) в виде маленького квадрата.

Междиаграммная ссылка – элемент нотации, обозначающий другую диаграмму (модель). Стрелка, поступающая на междиаграммную ссылку переходит на соответствующую диаграмму.

Процесс-ссылка – это элемент нотации, обозначающий ссылку на типовую модель процесса, в которую «зашита»/свернута модель наиболее часто повторяющегося процесса.

Сноска – элемент нотации, предназначенный для вынесения в сторону от основных элементов диаграммы каких-либо комментариев.

Правила нотации

Правила нотации IDEF0 также не представляют глобальной и сложной истории.

Функции/процессы (прямоугольники) классически располагаются по диагонали слева направо и сверху вниз – это так называемый принцип доминирования. Понимается это так, что блоки (функции/процессы), расположенные вверху слева доминируют над остальными. Доминируют – оказывают большее влияние.

Бизнес-процессы верхнего уровня, смоделированные в IDEF0, могут быть декомпозированы до процессов нижних уровней как в той же нотации IDEF0, так и в других: BPMN 2.0 и EPC.

Источник

Два способа построения моделей бизнес-процессов в IDEF0

Проблемы построения моделей в IDEF0

Специалисты многих предприятий России используют стандарт IDEF0 и программные продукты, его поддерживающие, для построения моделей деятельности. Эти модели используются для анализа, представления руководству, использования в нормативно-методических документах при документировании деятельности, при подготовке к внедрению информационных систем и т.д. Несмотря на широкую распространенность и относительную простоту стандарта IDEF0, во многих компаниях специалисты испытывают существенные затруднения при построении и последующем использовании моделей. Часто модели получаются сложными, запутанными, плохо соответствующими реальной деятельности. Глядя на такие модели, руководители предприятий не только не могут с ними эффективно работать, но и не способны указать, в каком именно направлении нужно их совершенствовать, чтобы получить приемлемых для практических целей результат. В чем здесь проблема? В сложности самого стандарта IDEF0 или в недостаточном его знании сотрудниками и руководителями? Думаем, что нет. Собственный опыт применения IDEF0 и примеры использования его различными компаниями указывают на то, что это не главные причины. На наш взгляд, причина заключается в отсутствии четкого и последовательного методического подхода к применению стандарта IDFE0 для практических задач описания, анализа и документирования деятельности предприятия. В рамках данной статьи мы рассмотрим два методических подхода к построению моделей при помощи стандарта IDEF0. В первом случае построение модели осуществляется на основе организационной структуры компании. Во втором случае — на основе цепочек создания ценности, при помощи которых компания производит продукты (услуги) для своих потребителей.

Метод построения моделей в IDEF0 на основе организационной структуры

Достаточно часто собственники или руководители верхнего уровня ставят задачу разобраться с текущей ситуацией и выяснить целесообразность существующей на предприятии организационной структуры, четко определить функции подразделений, понять, кто за них отвечает, с какой эффективность выполняется работа и т.п. Такая постановка задачи означает, что нужно подвергнуть анализу деятельность всего предприятия, в первую очередь руководителей крупных структурных подразделений. Модель в IDEF0 может помочь в этом случае четко расписать выполняемые функции, структурировать их по подразделениям. Построенную модель можно подвергнуть анализу и предложить изменения как в части структуры подразделений, так и по составу выполняемых ими функций. Модель может быть использована для обсуждения с собственниками 1 и последующего принятия решений по реорганизации компании. Обратим внимание, что при постановке указанной выше задачи никоим образом не говорится о процессном подходе или других технологиях управления. Задача сугубо конкретная. Способы ее решения должны быть максимально просты, и в то же время эффективны. При таком подходе можно строить модель в IDEF0, опираясь на схему организационной структуры предприятия.

На рисунке 1 показан фрагмент схемы организационной структуры относительно небольшого предприятия.

Рисунок 1. Фрагмент организационной структуры компании

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

Рисунок 2. Фрагмент модели в IDEF0, построенной на основе организационной структуры компании. Диаграмма А0.

В качестве примера рассмотрим блок 1 на диаграмме А0 более детально. Это означает, что мы должны рассмотреть деятельность Службы сбыта при помощи отдельной диаграммы следующего, более детального уровня. На рисунке 3 показана модель деятельности Службы сбыта, построенная на основе организационной структуры этой службы. Диаграмма А1 (рисунок 3) содержит несколько блоков, в именно: блок, отображающий деятельность Директора по сбыту, блок деятельности Отдела маркетинга, блок деятельности Отдела сбыта и блок деятельности Склада готовой продукции. Так же как и на рисунке 2 показаны потоки документов, при помощи которых осуществляется взаимодействие между отделами Службы сбыта.

Рисунок 3. Фрагмент модели в IDEF0, построенной на основе организационной структуры компании. Диаграмма А1.

Что будет, если мы выполним детализацию, например блока 2, на диаграмме А1? Мы построим диаграмму, на которой нужно будет указать процессы (функции, работы, операции), которые выполняются в Отделе маркетинга. Допустим, что в этом отделе работает 4 сотрудника. В среднем, каждый сотрудник может выполнять 6-8 функций. Таким образом, необходимо будет указать на диаграмме от 24 до 32 функций (блоков). Очевидно, что это чрезмерное количество. Выход из ситуации в том, чтобы выявить процессы, которые выполняются в этом подразделении и именно их указать на диаграмме. В каждом таком процессе может участвовать несколько сотрудников отдела маркетинга. При построении системы процессов отдела удобно пользоваться матрицей ответственности (см. таблицу 1.).

Отв. — отвечает за выполнение процесса;
Уч. — участвует в выполнении процесса;
Ин. — получает информацию по процессу.

Итак, деятельность Отдела маркетинга мы описали, выделив 5 процессов. Это означает, что достаточно четко удалось определить состав работ, выполняемых в отделе, степень участия и ответственности каждого сотрудника.

Подчеркнем, что на диаграмме А12 деятельность показана в виде взаимодействующих процессов, а не подразделений. В каждом процессе участвуют несколько сотрудников.

Для выполнения каждого процесса, представленного в таблице 1 и на рисунке 4, нужно выполнить определенное количество операций, которые могут быть подробнее описаны на следующих уровнях диаграммы.

Метод построения моделей в IDEF0 на основе цепочек создания ценности

Рассмотрим деятельность предприятия с точки зрения цепочек создания ценности. Для этого необходимо выявить цепочку последовательно выполняемых бизнес-процессов, на выходе которой появляются продукты (услуги) предприятия. В такую цепочку процессов, как правило, включаются не только процессы предприятия, но и процессы, выполняемые его внешними контрагентами. На рисунке 5 представлен фрагмент цепочки создания ценности рассматриваемого предприятия.

Рисунок 5. Фрагмент цепочки ценности.

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

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

Бизнес-процессы на диаграмме А0 (рисунок 6) сгруппированы по трем категориям на основе анализа движения материальных потоков — сырья, полуфабрикатов, готовой продукции. Далее в качестве примера показано детальное представление процесса «Производить, хранить и доставлять сырье» (см. рисунок 7).

Рисунок 6. Фрагмент модели в IDEF0, построенной на основе цепочек создания ценности. Диаграмма А0.

На рисунке 7 белым цветом показаны бизнес-процессы, выполняемые предприятием, а серым цветом — бизнес-процессы, выполняемые внешними контрагентами. Видно, что бизнес-процесс «Закупать сырье», по сути, управляет всеми остальными бизнес-процессами в рассматриваемой части цепочки создания ценности. Выполняется этот процесс Отделом закупок Службы снабжения. Так же в этом процессе участвует подразделение «Транспортный отдел» (оно не показано на схеме организационной структуры на рисунке 1). Хотя данное подразделение не входит в Службу снабжения, но выполняет часть рассматриваемого процесса. Таким образом, на диаграмме А2 представлен «сквозной» или межфункциональный (даже можно сказать межорганизационный) бизнес-процесс.

У читателя может возникнуть вопрос: почему на диаграмму А2 не попал бизнес-процесс хранения сырья на складе предприятия, выполняемый Складом сырья Службы снабжения? Этот процесс был условно отнесен в блоку процессов «Хранить и перерабатывать сырье и полуфабрикаты» (диаграмма А0, рисунок 6). Здесь мы коснулись вопроса определения границ «сквозных» или межфункциональных бизнес-процессов. Поскольку такие процессы не локализованы внутри отдельных подразделений (или даже организаций), определение их границ является достаточно субъективным и зависит от ряда критериев, которые, как правило, вырабатывается при проведении анализа бизнеса компании на основе установленных целей и задач.

Рисунок 7. Фрагмент модели в IDEF0, построенной на основе цепочек создания ценности. Диаграмма А2.

Выводы

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

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

Москва, февраль 2005 г.

1 Кто-то из читателей наверняка скажет, что для собственников это слишком сложно. Однако наш опыт работы показывает, что профессионально построенная модель в IDEF0 вполне может использоваться для обсуждения и принятия решений не только на уровне специалистов, но и на уровне собственников.

2 Состав функций и распределение их по сотрудникам являются условными. Таблица дается в качестве примера.

3 Конечно, такое разделение процессов является субъективным.

4 Если конечно не приравнивать деятельность крупных структурных подразделений бизнес-процессам, как это делают некоторые авторы.

5 Более подробно методы построения цепочек ценности смотри в других статьях автора.

6 Это проблема не только IDEF0, но и любого другого способа графического представления бизнес-процессов.

Источник

Опыт использования стандарта IDEF0

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

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

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

Примером стандартов проектирования бизнес-процессов может служить семейство стандартов IDEF (Госдепартамент и BBC США), RUP (компания Rational Software), Catalysis (компания Computer Associates). Отраслевыми стандартами являются модели, разрабатываемые государственными и международными общественными организациями (рекомендации ISA, APICS, ISO, TM Forum и др.). Стандарты предприятия обычно составляют подмножество стандартов (1) и (2), обогащенное процедурными правилами разработки и согласования моделей бизнес-процессов, принятых на предприятии.

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

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

Не станем ограничиваться рассмотрением одной из целей моделирования, а попытаемся сосредоточиться на аспектах моделирования бизнес-процессов, имеющих общую значимость. Исходный контекст статьи – это абстрактный проект, целью которого является разработка модели бизнес-процессов, а предмет обсуждения – задача «настройки» ограничений (3-4) на этот проект. Фактически речь идет о процессе приспособления стандарта (tailoring process) и точек зрения проектировщика, который, как правило, содержит огромные возможности для привнесения субъективных решений, как по воле проектировщика, так и по воле заказчика. Поэтому необходимы дополнительные методические рекомендации, которые сузили бы область творческого «произвола» при модификации стандартов проектирования бизнес-процессов.

Рассмотрим рекомендации по конкретизации языков моделирования бизнес-процессов в контексте методологии IDEF0. Данный выбор не является принципиальным, а лишь отражает субъективные пристрастия автора. При этом следует иметь в виду, что предлагаемые принципы формирования рекомендаций и логику их применения легко распространить на отличные от IDEF0 методики проектирования бизнес-процессов с учетом трех аспектов моделирования бизнес-процессов: функционального моделирования, моделирования событий и ресурсов и унификаций описания бизнес-процессов.

Функциональная модель бизнес-процессов

Любой стандарт проектирования бизнес-процессов базируется на исходных понятиях – смысловых примитивах. Так, стандарт IDEF0 использует понятие «Работа» (Activity) для обозначения действия, а также обозначения интерфейсов «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), которые составляют графическую конструкцию (A), изображенную на рис. 1.

К сожалению, в IDEF0 эти примитивы определяются в общем виде, поэтому пользователи стандарта обычно прибегают к интерпретациям примитивов. Например, только на первый взгляд конструкция из рис. 1 выглядит логичной, а формирование дополнительных концептуальных установок – ненужным. Как правило, у начинающего пользователя возникает недоумение, куда ему необходимо отнести понятие «Распоряжение»: к интерфейсу «Управление» или к интерфейсу «Вход»? Или куда отнести понятие «расходные материалы» при моделировании работы канцелярии: к «Входу» или «Механизму»? Дальше – больше. Стандарт IDEF0 исполнителей «Работ» (одушевленных и неодушевленных) относит к интерфейсу «Механизм». На уровне бытового сознания это не вызывает вопросов, однако, если вдуматься в суть понятия «исполнение», то становится ясным, что исполнитель «Работ» является активатором «Работ», составляющих данную «Работу» и приводящих к ее исполнению. Между тем, активатором «Работ» согласно IDEF0 является «Вход».

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

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

Все «Работы» принадлежат одному классу – обладают одинаковым набором свойств и поведением.

Все связи между «Работами» принадлежат классу «Ресурс». Например, электронное издание «Налогового кодекса РФ» является реализацией (или экземпляром) общедоступного информационного ресурса, а уборщица Иванова И.И. является экземпляром ресурса «Уборщица офиса 202».

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

1. Признак изменчивости экземпляров ресурсов при исполнении «Работы»:

Нетрансформируемые ресурсы могут быть неизнашиваемыми или изнашиваемыми (устаревающими). Так, значительная часть информационных ресурсов в электронной форме являются неизнашиваемыми (библиотека нормативных документов организации и др.). Примером изнашиваемых ресурсов могут служить вспомогательные инструменты, персонал. Описанные признаки относятся к экземплярам ресурсов, а не к самим ресурсам: понятия как абстрактные классы не изнашиваются.

2. Признак блокировки экземпляра ресурса «Работой», исключающий возможность использования экземпляра ресурса другими «Работами»:

Правила разводки ресурсов, классифицируемых по описанным признакам, по интерфейсам, заданным стандартом IDEF0, иллюстрируются на примере “Общая модель бизнес-процессов (В)” (рис. 1). Предлагаемая интерпретация смыслового содержания интерфейсов IDEF0-стандарта не только полностью соответствует требованиям этого стандарта, но и лишена возможных логико-лингвистических противоречий, свойственных ряду других интерпретаций.

События и ресурсы

Важнейший компонент моделирования бизнес-процессов – оценка материальных, стоимостных и временных ресурсов, необходимых для исполнения всего множества процессов. В современных инструментах проектирования, поддерживающих IDEF0, для этих целей используется функционально-стоимостной анализ, а расчеты производятся методом непосредственной имитации исполнения «Работ». Можно встретить мнение, что одним из недостатков IDEF0-моделей, в которых по тем или иным причинам не определяются моменты активации работ, является ошибка функционально-стоимостного анализа, вызванная фактором нарушения последовательности «Работ». Эта ошибка считается допустимой для приближенных расчетов. Для более точных расчетов предлагается использовать иные инструменты; так, в BPwin наличествует возможность экспорта данных в систему EasyABC. Однако это слишком дорогое решение для такой простой задачи. Что мешает нам более четко определить моменты активации «Работ» на IDEF0-диаграммах?

Считается, что основным отличием стандартов, нацеленных на функциональное или процессное моделирование, являются их возможности по описанию событий и последовательности исполнения «Работ» во времени. В известном руководстве [4] пользователям стандартов IDEF0 и IDEF3 настойчиво навязывается идея о различном их назначении, говорится об отличиях интерпретации стрелок в IDEF0 и в моделях потока работ [5]. Покажем, что это утверждение далеко от действительности.

В качестве базовой посылки примем положение о том, «что не запрещено стандартом, то разрешено». Покажем, что IDEF0 не запрещает изображать события и определять последовательность «Работ» с помощью стрелок. Будем исходить из того, что в IDEF0 активаторами работ определены стрелки [5]. К сожалению, сущность такой активации в стандарте не поясняется. Логично предположить, что активация – это принуждение к исполнению «Работы» или, как минимум, изменение состояния «Работы», которое тоже можно толковать как начало исполнения. При этом активация может толковаться широко. Например, отсутствие информации на входе «Работы» тоже может рассматриваться как активация.

Однако в стандарте, как это ни странно, синтаксически не различаются «Работы», находящиеся на различных уровнях декомпозиции. Различия же между ними существенны. Согласно положению стандарта о том, что активаторами «Работ» являются стрелки, а на нижнем уровне декомпозиции бизнес-процессов стрелки описывают последовательность исполнения «Работ» [5], можно утверждать, что каждая «Работа» на нижнем уровне декомпозиции модели активируется только при активации всех ее входов. К сожалению, из текста стандарта не следует, что считать условиями активации «Работы» более высокого уровня. Стандарт рекомендует проектировщику, по возможности, не задумываться над этой проблемой, однако не настаивает на этом определенно [5].Читатель стандарта может в этом самостоятельно убедиться, если не вырывать фразы из контекста.

Существует еще аспект времени, который стандартом замалчивается, – момент завершения «Работы». Без его знания функционально-стоимостной анализ, основанный на моделировании, не будет завершен. Можно прятать голову в песок и не определять условие активации «Работы», но момент ее завершения мы видеть обязаны. К счастью, ответ на вопрос о моменте завершения «Работы» тривиален: «Работа» не может быть завершена, пока все ее входы не будут активированы. Теперь и нематематику должно быть ясным, что известные условия активации «Работ» на диаграммах нижнего уровня и известные условия окончания «Работ» на верхних уровнях позволяют однозначно восстановить информацию об условиях активации «Работ» на всех уровнях. Иначе говоря, условия активации «Работ» в IDEF0 являются предопределенными.

Рассмотрим теперь один из возможных вариантов конкретизации описания событий в IDEF0.

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

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

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

1. Исполнение «Работы» безусловно инициируется событием «Поступление Ресурса». Это соответствует классическим представлениям о том, что любое воздействие влечет реакцию. Не бывает воздействий без рефлексии на него. Поэтому поступление любого ресурса является управляющим воздействием.

2. Необходимым (но не достаточным) условием завершения «Работы» является свершение полного набора событий «Поступление Ресурса», связанных с интерфейсами «Работы».

Приведенная установочная концепция делает изобразительные свойства стандарта IDEF0 не только достаточными для описания ситуаций и условий исполнения «Работ» при моделировании организации, но и более выразительными, простыми и эффективными.

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

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

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

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

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

Заключение

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

Насколько предложенный подход к унификации описания бизнес-процессов будет полезен конкретному проектировщику, сильно зависит от его личных пристрастий, опыта реализованных проектов и иных обстоятельств. Большое значение имеет и область применения разрабатываемой модели. Так, для описания документооборота возможно, целесообразнее использовать Swim Lane – диаграммы, строящиеся в Bpwin на основе IFEF3-диаграмм, или сразу начинать проектирование с DFD-диаграмм. Предложенные «рецепты» являются выжимками приобретенного автором опыта при разработке процессных моделей нескольких организаций, для которого широта IDEF0 стандарта стала источником проектного «шума». Сущность приведенных рекомендаций выражается в направленном сужении стандартов организационного проектирования с целью «погружения» проектировщика в мир строгих абстракций, предлагаемых системной идеологией и общей теорией управления. Данные рекомендации окажутся полезными директорам информационных служб при постановке задач системным аналитикам и определении требований к стандартам разработки информационных систем.

Источник