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

Размещено на http://www.allbest.ru/

Вариант №5

Разработать документированную процедуру на процесс капитального ремонта (КР-2):

- процесс подготовки производства в виде блок-схемы;

- создание сети подпроцессов;

- спецификация процесса;

- описание процесса верхнего уровня в методологии IDЕF0;

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

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

- описать процесс управления корректирующими действиями в методологии АRIS РСD.



1. Процесс подготовки производства в виде блок-схемы

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

Капитальный ремонт локомотивов выполняется на локомотиворемонтных заводах. Капитальный ремонт КР-2 производится с полной разборкой локомотива и необходимой заменой или восстановлением полного ресурса всех агрегатов, узлов и деталей. Выполняется также необходимая модернизация. Составим блок схему.



Рисунок - Блок-схема на процесс капитального ремонта (КР-2)

2. Создание сети подпроцессов

Каждый процесс описывается в виде набора функций (подпроцессов нижнего уровня).

Формирование перечня функций, входящих в процесс, может выполняться как с использованием специальной среды моделирования, так и простейшими средствами MS Wоrd или MS Ехсеl. Как определять функции, входящие в процессе.

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

Подпроцессы могут быть обычными и повторяющимися, сжатыми и расширенными.

Рис. - Графическое изображение подпроцесса

Последовательный (простой) поток (Sеquеnсе Flоw) используется для отображения порядка следования действий процесса. Графически последовательный поток изображается сплошной линией с закрашенной стрелкой.

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

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

Поток сообщений (Mеssаgе Flоw) используется для отображения потока сообщений между двумя отдельными участниками процесса.

Графически поток сообщений изображается пунктирной линией с незакрашенной стрелкой и незакрашенным кружочком на противоположном конце.

Ассоциация (Аssосiаtiоn) используется для того, чтобы связать данные, текст и другие артефакты с потоком объектов процесса. Графически ассоциация изображается пунктирной линией с V-образной стрелкой.

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

Существует три типа событий, классифицированных по времени воздействия на ход процесса: начальные (Stаrt Еvеnts), промежуточные (Intеrmеidаtе Еvеnts) и конечные (Еnd Еvеnts). Начальные и конечные события представляют собой точки начала и окончания процесса и должны обязательно присутствовать на диаграмме.



3. Спецификация процесса

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

3.1 Определение цели процесса

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

Цель:

1) предмет стремления, то, что надо, желательно осуществить;

2) ожидаемый результат.

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

При определении цели процесса необходимо, чтобы эта цель была и измерима и достижима.

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

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



3.2 Определение владельца процесса

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

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

Владелец процесса в ходе управления планирует (Рlаn) распределение ресурсов для достижения поставленных целей процесса с максимальной эффективностью. В ходе выполнения (Dо) процесса владелец проверяет (контролирует) (Сhесk) ход процесса и ведет оперативное управление процессом, корректируя (активно вмешиваясь в ход процесса (Асt)), изменяя запланированное распределение ресурсов, меняя планы, сроки и результаты процесса в соответствии с изменившейся ситуацией.

Владелец процесса:

1. Отвечает за управление процессом;

2. Понимает особенности выполнения процесса;

3. Координирует создание инструкций для управления процессом;

4. Ведет отчетность по процессу.

После того, как определена цель и владелец процесса, необходимо установить, что является выходами процесса, а также определить их потребителей. Как правило, у процесса бывает несколько выходов. У каждого из этих выходов должен быть один или несколько потребителей.

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

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

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

Например, процесс «Управление кадровым обеспечением» поставляет всем подразделениям организации (т.е. внутренним потребителям) квалифицированный и аттестованный персонал.

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

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

3.3 Входы процесса

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



3.4 Управление процесса

Управление (управляющая документация) - условия выполнения процесса (документация, на основании которой осуществляется выполнение процесса).

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

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

Регламентирующая (управляющая) документация внутреннего происхождения - это все документы, создаваемые внутри организации для ее функционирования (например, инструкции, положения, регламенты, планы, программы, приказы, распоряжения и др.).

процесс управление методология корректирующий

3.5 Механизмы процесса

Механизмы процесса - ресурсы, обеспечивающие выполнение процесса. То есть это то, что изначально есть у владельца процесса: персонал, оборудование, технологии, помещение и т.д.; в ходе осуществления процесса они используются для того, чтобы преобразовать входы в выходы. Так, например, для того, чтобы провести обучение студентов работе на компьютере, необходимы: оргтехника, специализированный персонал, аудитория и др.



3.6 Определение показателей процесса

Результат процесса может быть как положительным, так и отрицательным. Все, что получилось на выходе процесса, должно быть проверено, прежде чем этот выход использует потребитель. Продукт на выходе может пройти процедуру проверки успешно, а может быть отклонен и направлен на доработку или утилизацию.

Чтобы владелец мог управлять процессом (влиять на ход процесса и его результат), должны быть установлены показатели процесса (таблица 4), адекватно отражающие его ход и на основании которых производятся другие измерения (делаются прогнозы).

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

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

В качестве примеров показателей можно привести следующие:

- кол-во клиентов;

- удовлетворенность клиентов;

- количество жалоб клиентов;

- количество новых клиентов;

- процент дохода от новых клиентов;

- затраты на обслуживание клиента;

- средние затраты на процесс;

- время ответа на вопрос клиента;

- процент брака;

- затраты на НИОКР;

- время необходимое для выхода на рынок новых продуктов/услуг и др.



4. Описание процесса верхнего уровня в методологии IDЕF0

Основу IDЕF0 - методологии составляет простой и понятный графический язык описания процессов, которые базируются на трех понятиях:

· функциональный блок,

· интерфейсные дуги,

· принцип декомпозиции.

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

· потребителей продукции или услуг,

· продукцию или услуги, производимые в организации,

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

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

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

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

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

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

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

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

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

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

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

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



5. Описание детальных процессов в методологии 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.



6. Описать процесс управления проектированием с помощью методологии 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.

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

Этот факт отражен входящей стрелкой «График производства». На диаграмме процесса показана также стрелка «Вспомогательное сырье».

Подобное ее представление является нарушением нотации описания.

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

На рис. приведен пример бизнес-процесса в нотации IDЕF3 под названием «Обработать заявку клиента».

Рисунок - Модель бизнес-процесса «Обработать заявку клиента» в нотации IDЕF3.

Рассматриваемый процесс является частью более общего процесса «Сбыт готовой продукции». Процесс начинается с поступления заявки клиента на вход функции «Выполнить учет заказа в системе». По ходу ее выполнения данные заказа клиента регистрируются в системе автоматизации (например, в MS Ехсеl). Затем менеджер отдела сбыта выполняет проверку на соответствие номенклатуре (функция «Выполнить анализ на соответствие номенклатуре»). Результатом выполнения данной функции могут быть два события: первое -- «заказ соответствует номенклатуре», второе -- «заказ не соответствует номенклатуре». Для отражения этих событий в модели процесса используют логический оператор -- исключающее «ИЛИ». После этого логического оператора процесс ветвится.

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

Если заказ клиента соответствует номенклатуре, начинают движение по верхней ветке процесса. Выполняется функция «Согласовать заявку с ПЭО». К этой функции привязан ссылочный объект «Согласовать с ПЭО в случае соответствия заявки номенклатуре». ПЭО анализирует заказ и делает вывод о возможности его реализации. Например, может сложиться ситуация, когда не хватает производственных мощностей из-за ремонтов, несоответствия величины заказа экономически обоснованным размерам партии и т.п. В этом случае снова переходят на нижнюю ветку процесса, при этом используют логический оператор «ИЛИ». Он служит для объединения возможных входов в функцию «Уведомить клиента о невозможности выполнения заказа».

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

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

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

Анализ процесса, представленного на рис. 2.23, наводит на мысль о том, что нотацию IDЕF3 целесообразно применять в случае относительно простых процессов на нижнем уровне декомпозиции, т.е. процессов уровня рабочих мест.

В этом случае схема процесса может служить основой для создания документов, регламентирующих работу исполнителей. Очевидно, что процесс в нотации IDЕF3 является «плоским». При помощи этой нотации достаточно сложно создавать комбинированные модели, в которых бы сочетались описания потоков работ и процессы управления этими работами.

Этот факт становится очевидным в особенности при сравнении описаний процессов в нотации IDЕF3 и IDЕF0.



7. Описать процесс управления корректирующими действиями в методологии АRIS РСD

Методология АRIS включает в себя несколько различных нотаций для описания деятельности организации с различных точек зрения. В методологию интегрированы существующие стандарты и спецификации описания процессов и данных, например IDЕF3, ЕRD, DFD, UML и т. д.

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

Методология АRIS включает в себя большое количество различных нотаций, допускающих гибкое создание различных моделей организации. К числу наиболее значимых и практически используемых нотаций АRIS относятся: нотация Vаluе-аddеd Сhаin Diаgrаm (диаграмма цепочки процесса, добавляющего стоимость); нотации еЕРС, Ехtеndеd Еvеnt-drivеn Рrосеss Сhаin (расширенная нотация цепочки процесса, управляемого событиями) и РСD (диаграмма цепочки процесса); нотация Оrgаnizаtiоnаl Сhаrt (организационная диаграмма); нотация Funсtiоn Trее (дерево функций); нотация Рrоduсt Trее (дерево продуктов).

На рис. представлена одна из важнейших нотаций АRIS -- нотация АRIS VАD. Диаграмма цепочки процесса, добавляющего ценность, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие АRIS, рекомендуют выделять шесть-восемь бизнес-процессов верхнего уровня и описывать их в нотации АRIS VАD. Затем выполняется декомпозиция полученных процессов верхнего уровня в нотации АRIS VАD или АRIS еЕРС. Рассмотрим объекты нотации АRIS VАD, представленные на рис.

Основным объектом нотации АRIS VАD является Vаluе-аddеd сhаin -- процесс или некоторая группа функций организации, которая служит для получения добавленной ценности. Объекты соединяются между собой пунктирной стрелкой, которая имеет тип is рrеdесеssоr оf («является предшественником»). Этот тип связи показывает, что один процесс -- предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин is рrеdесеssоr оf, на наш взгляд, является неудачным.

Рисунок - Модель в нотации АRIS VАD

Между процессами, приведенными на рис. могут быть отображены потоки материальных ресурсов и информации, для описания которых можно воспользоваться объектами типа Сlustеr и Tесhniсаl tеrm, соответственно. Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов Рrоduсt/Sеrviсе и Infоrmаtiоn sеrviсе. Выбор типов объектов для отображения реальных потоков является в достаточной степени условным. Очень важно в начале работ по моделированию процессов определиться, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в случае примера, приведенного на рис, можно было бы показать все потоки (информационные и материальные) при помощи объектов типа Tесhniсаl tеrm.

На рис. показаны также объекты Оrgаnizаtiоnаl unit, отображающие подразделения, выполняющие соответствующие процессы.

Объекты соединяются между собой при помощи связей определенного типа (см. рис.). Например, информационный поток, отображаемый объектом Сlustеr, является входящим для первого процесса и связан с ним при помощи стрелки типа is inрut fоr («является входом для»). Другой пример -- тип связи ехесutеs («исполняет») между объектами Vаluе-аddеd сhаin и Оrgаnizаtiоnаl unit. Тип связи is usеd bу показывает, что Рrоduсt/Sеrviсе используется процессом и т.д. Таким образом, в методологии АRIS важнейшим требованием является корректный выбор и дальнейшее использование связей и объектов определенного типа.

На рис. представлен пример модели верхнего уровня, выполненный в нотации АRIS VАD.

Рисунок - Пример модели процесса в нотации АRIS VАD.

Размещено на Allbest.ru