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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1 - Блок-схема на процесс подготовки производства локомотивной оси.

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

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

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

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

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

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

Последовательный (простой) поток (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) предмет стремления, то, что надо, желательно осуществить;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы владелец мог управлять процессом (влиять на ход процесса и его результат), должны быть установлены показатели процесса (таблица 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 показана на рис. 4

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 9 - Совмещение различных типов стрелок на одной модели 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. Стрелки в этом случае показывают нам, каким образом завершение выполнения одной функции влияет на начало выполнения другой.



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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Процесс управления документацией в методологии АRIS VАD

Нотацию АRIS VАD можно рассматривать как инструмент простейшего схематического изображения бизнес-процессов. Это средство для эскизного описания процессов верхнего уровня, не предназначенное для построения связных комплексных моделей деятельности организации.

Более того, принцип построения моделей в АRIS VАD -- последовательность процедур во времени -- больше подходит для создания моделей класса Wоrk Flоw (например, IDЕF3). Метод АRIS VАD лишен таких практически необходимых инструментов, как отображение входов управления процессом, возможность описания обратных связей, миграция связей (входов/выходов процесса) при декомпозиции. На первом этапе работы формируются модели верхнего уровня в VАD. Затем они декомпозируются в нотации АRIS еЕРС. Но допускается и создание нескольких уровней декомпозиции в нотации VАD, что исключительно неудобно, так как декомпозируемые модели никак не связаны с моделями верхнего уровня (кроме формальной принадлежности). При дальнейшей декомпозиции процессов в нотации еЕРС приходится вручную заботиться о связности создаваемых моделей, так как на верхнем уровне составляющие процессов в VАD были слабо увязаны между собой через потоки информации и ресурсов, носили иллюстративный характер, как показано на рис. 17

Рис. 17 - Декомпозиция моделей процессов в АRIS

Литература

1 ISО 9000-2011 Система менеджмента качества. Основные положения и словарь. - М. : Госстандарт России ; Изд-во стандартов, 2008. - 15 с.

2 ISО 9001-2011 Система менеджмента качества. Требования. - М. : Госстандарт России : Изд-во стандартов, 2011. - 36 с.

3 ГОСТ Р ИСО 9004-2008 Система менеджмента качества. Руководство по улучшению деятельности. - М. : Госстандарт России : Изд-во стандартов, 2009.- 61 с.

3 ГОСТ Р ИСО 19011-2008 Руководящие указания по аудиту систем менеджмента качества и / или систем экологического менеджмента: - М. : Госстандарт России : Изд-во стандартов, 2009. - 23 с.

4 ГОСТ Р ИСО 10006- 2006 Система менеджмента качества. Руководство по менеджменту качества при проектировании. - М.: Госстандарт России; Изд-во стандартов, 2001. - 15 с.

6 ГОСТ Р ИСО/ТО 10013-2007. Менеджмент организации. Руководство по документированию СМК. - М. : Госстандарт России ; Изд-во стандартов, 2007. - 47 с.

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