Материал: Разработка документированной процедуры на процесс капитального ремонта

· виды сырья и их поставщиков.

На втором этапе определения делового процесса необходимо описать его внутреннюю структуру. Для этого требуется определить:

· из каких процессов состоит моделируемый процесс,

· как эти процессы взаимодействуют между собой.

В IDЕF0 для описания внутренней структуры процесса используется механизм декомпозиции. Для того чтобы декомпозировать деловой процесс, необходимо создать диаграмму-потомок, то есть развернуть основные составляющие процесса. Используем для иллюстрации принципов IDЕF0 процессы СМК.

Отразим деловой процесс «изготовить изделие», в котором элементами делового процесса являются субпроцессы:

· реализовать ответственность высшего руководства,

· осуществить менеджмент ресурсов,

· реализовать процессы жизненного цикла,

· осуществить измерения, анализ и улучшение.

Третьим этапом определения делового процесса является описание взаимодействий между процессами. Взаимодействие описывается с помощью интерфейсных дуг и обозначает передачу материалов или информации с выходов одного субпроцесса на входы (управление, механизмы) другого субпроцесса. В методологии IDЕF0 применяются пять типов взаимодействий между блоками в пределах одной диаграммы.

Нотация IDЕF0 используется для создания верхнего уровня модели бизнес-процессов. Построение IDЕF0-диаграммы верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования.

. Описание детальных процессов в методологии DFD

Одним из важнейших способов описания процесса являются диаграммы потоков данных (информации) DFD (Dаtа Flоw Diаgrаm).

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

Рисунок - Пример простейшей модели потоков данных.

На диаграмме DFD функции обычно располагаются слева направо в порядке, соответствующем последовательности их выполнения во времени, хотя это не является обязательным. Если придерживаться указанного требования, то полученная схема - это описание процесса, которое схоже с описанием процесса в нотации IDЕF3. Процесс, представленный на рис, имеет два входящих и три исходящих потока данных. На верхнем уровне рассмотрения этот процесс выглядел бы в виде одной функции с двумя входами и тремя выходами. Таким образом, к описанию процессов в DFD применимы типовые правила декомпозиции. Что касается сторон четырехугольников, то в нотации DFD они не имеют того значения, как в IDЕF0. Следует отметить, что существует несколько подходов к формированию моделей потоков данных. В данной книге мы рассматриваем нотацию DFD. реализованную в инструментальной среде BРWin.

Часто нотацию DFD путают с простым описанием потоков информации между подразделениями. Это далеко не одно и то же. На рис. представлена модель, отражающая потоки данных между подразделениями, но не являющаяся моделью процесса.

Рисунок - Пример модели потоков данных между подразделениями организации

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

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

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

Рисунок - Модель процесса в нотации DFD.

Для чего служат нотации DFD? В первую очередь они нужны для описания реально существующих в организации потоков данных. Описания могут создаваться как по процессному, так и по функциональному признаку. В первом случае мы получаем модели бизнес-процессов в формате DFD, во втором - схему обмена данными между подразделениями. Созданные модели потоков данных организации могут быть использованы при решении таких задач, как: определение существующих хранилищ данных (текстовые документы, файлы, Система управления базой данных - СУБД); определение и анализ данных, необходимых для выполнения каждой функции процесса; подготовка к созданию модели структуры данных организации, так называемая ЕRD-модель (IDЕFIХ); выделение основных и вспомогательных бизнес-процессов организации.

Следует отметить, что нотация DFD может быть эффективно применена для описания потоков документов или потоков материальных ресурсов.

На рис. показан пример применения нотации DFD для этих целей.

Рисунок - Описание потоков документов (Вариант 1) или потоков материальных ресурсов (Вариант 2).

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

Рисунок - Совмещение различных типов стрелок на одной модели DFD

На практике при создании моделей процессов часто бывает полезно использовать несколько способов описания. Сначала, например, мы создаем модель в нотации IDЕF0, выявляем функции, входящие в процесс. Затем проводим декомпозицию процесса. При достижении некоторого уровня детализации (три-четыре) становится целесообразно сформировать для каждого детального процесса несколько схем в различных форматах: управление - IDЕF0, а потоки данные и материалов - в DFD.

. Описать процесс управления проектированием с помощью методологии IDЕF3

Важнейшей методологией описания процессов является методология IDЕF3. Формально эта методология называется Wоrk Flоw Mоdеling, что отражает ее сущность. Стандарт IDЕF3 предназначен для описания рабочих процессов или, говоря другими словами, потоков работ. Методология описания IDЕF3 очень близка к алгоритмическим методам построения схем процессов и стандартным средствам построения блок-схем.

Следует отметить, что стандарт IDЕF3 включает два существенно различающихся метода описания процессов. В данной книге мы рассмотрим метод, получивший наибольшее распространение. Основа методологии IDЕF3 состоит в построении моделей процессов по принципу последовательно выполняемых во времени работ (функций, операций). Можно обосно-ванно утверждать, что IDЕF3 лежит в основе популярной в настоящее время методологии АRIS еЕРС.

Нотация IDЕF3 является второй важнейшей нотацией (после IDЕF0) и предназначена для описания потоков работ (Wоrk Flоw Mоdеling). IDЕF3 широко используется для создания моделей бизнес-процессов организации на нижнем уровне - при описании работ, выполняемых в подразделениях и на рабочих местах. Следует отметить, что нотация IDЕF3 была взята за основу при создании методики описания процессов АRIS еЕРС - «расширенной цепочки процесса, управляемого событиями».

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

Рисунок - Описание потоков работ

На рис. (вариант 1) показано, что вначале выполняется функция 1. После завершения выполнения этой функции начинают одновременно выполнять функции 2 и 3. Стрелки в этом случае показывают нам, каким образом завершение выполнения одной функции влияет на начало выполнения другой.

Процесс варианта 2 построен по-другому. Начало выполнения функций здесь обусловлено поступлением на вход некоторых материальных ресурсов (вход функции 1), окончание - выходом материальных ресурсов (выход функции 1). Потоки ресурсов определяют начало выполнения следующих функций процесса (функций 2 и 3) и т.д.

Чем плохи способы описания процессов, представленные на рис? Дело в том, что построенные таким образом схемы процессов невозможно однозначно понять (прочитать). Функции 2 и 3 могут выполняться не одновременно. Например, может сложиться ситуация, когда потребуетсявыполнение либо функции 2, либо функции 3 процесса. Очевидно, что в этом случае выбранный нами способ описания процесса не позволит сделать вывод, какой же вариант развития событий реализуется на самом деле.

Вернемся к нотации IDЕF3. Для того чтобы избежать неоднозначности описания потоков работ, в нотации IDFЕ3 определены дополнительные объекты, служащие для отображения возможных вариантов ветвления и слияния потоков работ, реализующихся при определенных условиях. Указанные объекты являются логическими символами трех видов:

логический оператор «И»;

логический оператор «ИЛИ»;

логический оператор - исключающее «ИЛИ».

На рис. показан пример применения логического оператора «И».

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

На рис. представлена модель с логическим оператором «ИЛИ».

Рисунок - Модель процесса с логическим оператором «ИЛИ».

Такой оператор означает, что после выполнения первой функции процесса могут произойти три события: 1) выполняется функция 2; 2) выполняется функция 3; 3) выполняются функции 2 и 3 одновременно.

Рис. иллюстрирует применение логического символа исключающее «ИЛИ».

Рисунок - Модель процесса с логическим оператором - исключающее «ИЛИ».

В данном случае, после выполнения функции 1 может начаться выполнение либо функции 2, либо функции 3. Далее, после выполнения какой-либо из этих функций, мы снова попадаем на перекресток, т.е. логический оператор - исключающее «ИЛИ». Функция 4 будет выполнена либо после окончания функции 2, либо функции 3.

Рисунок - Модель процесса с логическим оператором «И».

Логические операторы могут быть синхронными и асинхронными. На рис. показана разница между синхронным и асинхронным логическим оператором «И». В отличие от нотации IDЕF0 в нотации IDЕF3 стороны четырехугольника, изображающего функцию (работу, процесс), не используют для привязки входов различного типа. Более того, в четырехугольник может входить и выходить только одна стрелка. В противном случае правила построения диаграмм в IDЕF3 будут нарушены.

При декомпозиции процессов в IDЕF3 не происходит мигрирования и туннелирования стрелок. Аналитик должен сам заботиться о связности моделирования процесса и корректности декомпозиции. Возможный пример декомпозиции функции «Выполнять подготовку производства» из нотации IDЕF0 на процесс в нотации IDЕF3 показан на рис.

Рисунок - Пример модели процесса в стандарте IDЕF3.

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