Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Функционально-структурный анализ

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

Процесс декомпозиции ограниченного объекта обычно состоит из следующих шагов:

1. Выбор блока диаграммы.

2. Рассмотрение объекта, определенного этим блоком.

3. Создание новой диаграммы.

4. Выявление недостатков новой диаграммы.

5. Создание альтернативных декомпозиций.

6. Корректировка новой диаграммы.

7. Корректировка всех связанных с ней диаграмм.

Шаги 1-3 представляют созидательную часть процесса. Выполняя их, аналитик концентрирует свои усилия, связанные с выявлением новой информации об объекте, на более высоком уровне детализации, чтобы достичь ясности изложения. Шаги 4-7 составляют этап самостоятельного рецензирования, в ходе которого аналитик, создав новую диаграмму, проверяет, какую она несет информацию и в каком она находится отношении с родительской диаграммой. Затем в созданную диаграмму и соответственно в связанные с ней диаграммы вносятся изменения, чтобы достичь ясности для других. Перед декомпозицией блоков родительской диаграммы необходимо очень хорошо изучить ее функции, чтобы свести до минимума повторную работу при возможных изменениях в диаграммах верхних уровней. Опираясь на хорошо проработанную диаграмму А0, можно сосредоточиться на построении диаграмм А1, А2, А3..., не пытаясь максимально декомпозир-вать одну функцию, строя, например, диаграммы А11, А111 или А21, А211. При выборе блока для декомпозиции необходимо начинать с наиболее «трудного», кото-рый вызывает больше вопросов и затруднений, обращая в то же время основное внимание на доминирующие блоки, которые могут дать дополнительную информацию для уточнения других блоков. Более простые функциональные блоки могут быть декомпозированы позже и приведены в соответствие детальному описанию более сложных блоков. С другой стороны, декомпозиция конкретного функционального блока зависит от целей построения модели. Поэтому не стоит стремиться поддерживать одинаковую глубину рассмотрения для каждой функции. Не откладывая на будущее лучше сразу сделать эскизы декомпозируемых функций (например, А3.2.1). После того, как приработаются более высокие уровни, будет легче вернуться для их более детального рассмотрения. Иногда первая проведенная декомпозиция, в результате которой создается контекстная диаграмма, при детальном рассмотрении даже автором может не соответствовать цели модели. Необходимо на первом этапе создания модели считать более важным обеспечение ясности изложения поставленной цели, даже, чем получение соответствующей модели. Не контекстные диаграммы должны содержать не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков менее трех вызывают серьезные сомнения в необходимости декомпозиции родительской функции. В процесс проведения декомпозиции иногда возникает желание произвести декомпозицию какой-либо функции/данных на большое количество подсистем (более 6), но, как показы-вает опыт, всегда есть возможность произвести объединение нескольких 2-3 функций в одну. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток. Однако при объединении функций и данных желательно ограничиваться разумным уровнем сложности: четыре-пять функциональных блоков, как правило, лучше всего. Слишком много данных и функций часто содержат слишком много информации. Это приводит к запутанным диаграммам. Наоборот, небольшое число блоков дает слишком мало, и диаграмма становится почти бесполезной. Если автор уверен, что достиг желаемого баланса, следует проверить, во всех ли отношениях созданное описание адекватно объекту, определенному блоком и его граничными стрелками на родительской диаграмме. Только после этого можно считать, что уже имеется все необходимое для построения диаграммы. Поэтому для построения модели, адекватной предметной области на всех уровнях абстрагирования после каждого сеанса декомпозиции обязательно проводится сеанс экспертизы - каждая диаграмма проверяется экспертами в данной предметной области, и/или представителями заказчика, и/или людьми, непосредственно участвующими в процессе разработки модели. В дальнейшем аналитик под влиянием коллективных знаний экспертов, читательской аудитории, а также других авторов сможет создать полноценное описание, которое после детализации будет удовлетворять цели модели. Процесс построения модели с использованием методологии IDEF является итерационным, т.к. включает последовательное улучшение описания системы. Но, как при любой инже-нерной деятельности, процесс улучшения всегда в некоторый момент должен быть прекращен. Обычно декомпозиция в IDEF прекращается, когда диаграммы, образующие нижний уровень модели, достаточно детализированы для достижения цели модели, т.е. дальнейшая декомпозиция не требуется, если модель достаточно точна, чтобы отвечать на все вопросы, соответствующие ее цели.

В процессе моделирования очень важно четко определить направление разработки модели – ее контекст, точку зрения и цель. Без ясно очерченного направления моделирования автор в процессе работы может незаметно отклониться от исходной цели. Контекст, точка зрения и цель являются ограничителями, позволяющими построить не просто очень подробную модель процесса, а модель, отвечающую на поставленные вопросы. Например, для обобщенного процесса «Производить партию редукторов» контекст модели (границы процесса) определяется следующим образом:

• входы процесса - спецификации заказа на партию редукторов и исходные материалы со склада;

• выходы процесса - готовая редукторы, предназначенная для отправки на склад, и техническая документация, создаваемая на различных стадиях процесса;

• порядок исполнения рассматриваемого процесса регламентируется технологической доку-ментацией, должностными инструкциями, а также производственным заданиями, создавае-мыми в рамках процесса;

• цель моделирования – отразить структуру процесса производства партии редукторов и его соответствие требованиям заказчика;

• точка зрения – генеральный директор.

Степень точности модели зависит от поставленной цели. Цель – это конкретное назначение модели, вытекающее из ее формального определения, и дающее полное, точное и адекватное описание моделируемой системы, для получения ответов на некоторую совокупность вопросов, возникших при проведении анализа моделируемого объекта. Цель отражает причину создания модели и определяет ее назначение. Целью модели является получение ответов на совокупность вопросов, которые неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Четко определенная цель становится критерием окончания моделирования. Таким образом, цель модели – это: набор вопросов, на которые должна ответить модель и критерий окончания моделирования. При этом все взаимодействия в модели рассматриваются именно с точки зрения достижения поставленной цели. При моделировании каждый шаг должен сверяться с поставленной конечной целью. Даже очень подробно построенная модель, не отвечающая на поставленные вопросы (не достигающая цели), практически бесполезна. Необходимо помнить, что все цели в рамках конкретных моделей должны быть связаны с общей целью. Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Цель определяет области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем ИС, такая модель будет существенно отличаться от той, кото-рую мы разрабатывали бы для того же самого предприятия, но с целью оптимизации логистических цепочек. После детального ознакомления с постановкой задачи и кратким описанием процессов системы, на самом раннем этапе проектирования, системный аналитик должен составить расширенный список вопросов, позволяющий конкретизировать цели модели. На основе этих во-просов производится создание модели, которая должна дать ответы на эти вопросы с заданной степенью точности, достигаемой, если основная суть каждой описанной в модели функции излагается в одной-двух фразах, максимум в одном абзаце текста. Затем, на основе проведенного анализа, необходимо из этих фраз составить одно предложение, которое определит цель модели. Сформулированная цель позволяет команде аналитиков сфокусировать усилия в нуж-ном направлении. Разумная степень точности достигается, если каждая описанная в модели функция излагается в одном абзаце. Цель должна отвечать на следующие вопросы:

• почему процесс должен быть смоделирован?

• что должна показывать модель?

• какую информацию может получить читатель модели?

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

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

• выбирается с целью получить как можно больше полезной информации о субъекте и форму ее подачи;

• определяет, что будет рассматриваться и под каким углом зрения;

• определяет уровень рассмотрения моделируемого процесса, расстановку акцентов и ис-пользуемую терминологию.

Такой подход к моделированию позволяет обеспечить высокое качество описания системы, однозначно выделить одни аспекты системы и игнорировать другие. Четкое определение точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных, необязательных в данном случае, элементов. Качество созданного дескриптивного описания системы снижается, если она сфокусирована ни на чем. Разрабатываемая модель должна рассматриваться все время с одной и той же точки зрения, которую можно представить как взгляд с позиции определенного человека, который ответственен за моделируемую систему в целом и видит систему в нужном для моделирования аспекте. Только с такой фиксированной точки зрения можно создать адекватное описание системы, таким образом, чтобы разрабатываемая модель не имела в себе несвязанных описаний. Правильно выбранная точка зрения диктует автору модели выбор нужной информации о субъекте и формирование ее подачи. Иногда точка зрения непосредственно связана с конкретной ролью, выполняемой этим человеком, который является частью системы. Выбор одной точки зрения обеспечивает согласованность терминологии - выделение определенных аспектов системы и применение определенной терминологии. Без правильно расставленных акцентов и терминологии согласованное изложение практически невозможно. Одна из сложнейших задач автора в IDEF0 -оставаться в рамках выбранной точки зрения, поскольку выявленное множество подробностей о работе системы, которые не вписываются в принятую точку зрения, вызывают сильное искушение изложить их. В принципе всегда можно произвести достаточно полное описание, но всегда возника-ет вопрос о достаточности описания этой операции. Точка зрения диктует автору модели правила выбора нужной информации. Например, будут существенно отличаться по направленности и детализации функциональные модели одного и того же машиностроительного предпри-ятия с точки зрения главного технолога, финансового директора менеджера, инженера-проектировщика или производственного рабочего. Финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисо-ванные схемы финансовых потоков, инженера-конструктора мало волнуют проблемы обеспечения производственными ресурсами, а для рабочего одним из основных является наличие заготовки и инструмента для ее обработки.

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

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

• рабочего, участвующего описываемой операции. Рабочему проще описывать некоторую реальную ситуацию, в которой он сам участвовал или наблюдал со стороны, но вероятнее всего его описание производственной операции будет иметь свои недостатки. Проблема оценки полученного описания от рабочего заключается в ответе на вопрос: не будет ли эта ситуация слишком частной, кроме того любая конкретная ситуация, которую скорее всего и будет описывать рабочий, всегда излишне детализирована.

Скорее всего, ни одно из этих двух описаний производственной операции не может являться моделью производственной операции, т.к. модель – это форма описания, но не наоборот. Модели необходимы для создания данных прогноза и анализа, что не доступно в описаниях. Такой подход позволяет создать согласованное описание системы таким образом, чтобы модель была конкретной, и в ней не смешивались бы несвязанные единой целью описания. Например, если в модели изделия, предназначенного преобразовывать крутящий момент (редуктор) не зафиксировать определенную точку зрения, то легко можно смешать проблему конструирования (определение геометрических размеров) и процесс изготовления деталей, входящих в состав редуктора. Если это произойдет, то читатель модели столкнется с трудностями при определении конкретных обязанностей разработчиков редуктора (конструктора, расчетчика, технолога и т.д.). Если для создания согласованной модели системы автоматизированного проектирования редуктора встать на точку зрения, конструктора, технолога или расчетчика, то ни одна из них сама по себе не даст модели, которая позволила бы создать именно систему проектирования. Только с позиции главного конструктора проекта (ГКП) можно увидеть все виды функций, выполняемых в процессе автоматизированного проектирования. Именно с его точки зрения, можно проследить взаимосвязи обязанностей различных работников. Точка зрения ГКП позволяет создателю модели определить роль каждого работника в процессе конструкторско-технологической подготовки производства редукторов и описать координацию обязанностей участников проекта.

Язык функционального моделирования IDEF0 основан на правил пунктуации, которые не несут самостоятельного смысла, но служат для ограничения, структурирования и интерпретации применяемых описаний так, чтобы сохранить только то значение, которое имелось в виду. Различные объекты могут быть описаны единой пунктуацией, только путем введения строгой, точной, пригодной для чтения, как человеком, так и машиной письменной формой (это может быть «естественный» язык, такой, как английский, технический жаргон искусственного формального языка, математические формулы или далее изображения форм и очертаний). Выбранная пунктуация должна сама по себе моделировать границу, поведение и сущность любого выбранного объекта. Синтаксис - набор структурных компонент или характеристик языка и правила, которые определяют отношения между ними. Компоненты синтаксиса IDEF0 - блоки, стрелки, диаграммы и правила. Семантика определяет содержание (значение) синтаксических компонентов языка и способствует правильности их интерпретации. Интерпретация устанавливает соответствие между блоками и стрелками с одной стороны и функциями и их интерфейсами - с другой. Любой стандарт проектирования бизнес-процессов базируется на исходных понятиях — смысловых примитивах. Так, стандарт IDEF0 использует понятие «Функция» (Activity) для обо-значения действия, а также обозначения интерфейсов «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism). К сожалению, в IDEF0 эти примитивы определяются в общем виде, поэтому пользователи стандарта обычно прибегают к интерпретациям примитивов. Как правило, у начинающего пользователя возникает недоумение, куда ему необходимо отнести понятие «Нормативная документация»: к интерфейсу «Управление» или к интерфейсу «Вход»? Или куда отнести понятие «расходные материалы» при моделировании работы конструкторского отдела, использующего компьютерную технику: к «Входу» или «Механизму»? Кроме того, стандарт IDEF0 исполнителей функции (одушевленных и неодушевленных) относит к интерфейсу «Механизм». На уровне бытового сознания это не вызывает вопросов, однако, если вдуматься в суть понятия «исполнение», то становится ясным, что исполнитель является активатором функции и приводящих к ее исполнению. Между тем, активатором процесса согласно IDEF0 является «Вход». Подобных логико-лингвистических противоречий в интерпретациях опытные пользователи стандарта IDEF0 могут привести много. Приведенные примеры говорят о том, что аналитику приходится постоянно конкретизировать стандарт IDEF0, если для него важна непротиворечивость модели и собственных представлений о моделируемом объекте.

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

Преобразованию в блоке могут подвергаться материальные и информационные объекты, образующие соответствующие потоки. Материальный поток - непрерывное или дискретное множество материальных объектов, распределенное во времени. Информационный поток - множество информационных объектов, распределенное во времени. Информация, участвующая в процессах, операциях, действиях и деятельности в целом, может быть классифицирована на три группы: ограничительная информация; описательная информация; предписывающая (управляющая) информация. Ограничительная информация - содержится в законах, подзаконных актах, международных, государственных и отраслевых стандартах, а также в специальных внутренних положениях и документах предприятия, в частности, в технических требованиях, условиях, регла-ментах и т.д. Это сведения о том, чего нельзя делать:

• никогда, ни при каких обстоятельствах (кроме, быть может, форсмажорных) в любой фазе и на любом этапе функционирования системы в целом;

• в рамках функционирования конкретного блока.

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

Материальный поток и описывающий его информационный поток везде, где это не вызывает недоразумений, можно изображать одной стрелкой.