Определение процессов.: На первом этапе описания процесса надо определить деловые процессы в

Содержание
  1. Бизнес-процесс
  2. Выделение бизнес-процессов организации: подход, основанный на результатах процессов
  3. Общепринятые подходы к выделению бизнес-процессов
  4. Принципы метода
  5. Модель входов-выходов и классификация входов бизнес-процесса
  6. Принцип классификации процессов по их основным выходам (результатам)
  7. Последовательное выделение процессов, начиная с их результатов
  8. Учёт интересов всех заинтересованных сторон
  9. Начало анализа: предназначение организации, ключевые заинтересованные стороны и результаты
  10. Построение цепочек ценности основных бизнес-процессов
  11. Описание (предварительная спецификация) отдельных процессов
  12. Выделение обеспечивающих бизнес-процессов
  13. Выделение и описание управленческих процессов
  14. Моделирование процессов развития
  15. Объединение процессов в единую сеть
  16. Верификация модели
  17. Кратко о преимуществах и недостатках метода
  18. Бизнес процесс
  19. Шесть вопросов к бизнес процессам
  20. Зачем?
  21. Что?
  22. Из чего?
  23. Когда?
  24. Кто?
  25. Как?
  26. Описание процессов в рамках системы менеджмента качества на основе методологии функционального моделирования IDEF0
  27. Введение
  28. Описание процессов
  29. Классификация процессов
  30. Заключение
  31. Литература
  32. Определение бизнес-процессов
  33. Описание процесса верхнего уровня в методологии IDЕF0
  34. Page 3

Бизнес-процесс

Определение процессов.:  На первом этапе описания процесса надо определить деловые процессы в

Бизнес-процесс

(не моё, см.: http://orgstructura.livejournal.com/1287.html#cutid1)

Зачем нам вообще необходимо понятие «бизнес-процесс»?

Самый первый вопрос, который надо себе задать, очень прост: «Зачем вообще нужен термин «бизнес-процесс»?» Попробуем рассуждать логически.

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

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

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

Более того, если обратиться к англоязычным источникам, никакого бизнес-процесса мы не встретим, а увидим только «business process» — что правильно было бы перевести как «деловой процесс».

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

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

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

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

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

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

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

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

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

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

В результате многолетней пропаганды «бизнес-процесс» стал весьма распространенным и употребляемым термином.

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

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

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

Продолжение

Как определить понятие «бизнес-процесс»?

http://orgstructura.livejournal.com/1578.html#cutid1

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

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

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

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

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

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

Более правильным представляется формирование подразделений для поддержания работы предварительно выделенных подсистем.

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

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

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

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

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

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

Это «рабочий» вариант определения, который в дальнейшем можно улучшить и дополнить.

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

Дополнение из электронного учебно-методический комплекса И.В.Миндалёва «Моделирование бизнес-процессов»

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

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

Примеры определений бизнес-процесса

Бизнес-процесс как деятельность:

Бизнес-процесс как создание продукта /услуги:

Бизнес-процесс как формирование прибавочной и /или потребительной стоимости:

совокупность различных видов деятельности, в рамках которой “на входе” используется один или более видов ресурсов, и в результате этой деятельности “на выходе” реализуется товар, представляющий ценность для потребителя

Понятие «бизнес-процесс» относим ко всем процессам организации.

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

Иерархическая структура бизнес-процесса:

(1) Бизнес-процесс, подпроцесс (субпроцесс ), процедура, функция, транзакция (действие) (Чеботарев В.Г)

(2) Бизнес-процесс, операция, действие, функция (Миндалёв И.В)

3.3. Схема бизнес-процесса
…………………… (рисунки)

3.4. Цели процесса

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

3.5. Организация как совокупность процессов

Миссия Стратегическая цель 1 /выпуск продукта А — Бизнес -процесс 1 Стратегическая цель 2 /предоставление услуги В — Бизнес -процесс 2 Стратегическая цель 3 /внедрение системы качества — Бизнес -процесс 3

3.6. Документирование и описание процессов

Документирование — первый шаг к совершенствованию процессов Цель документирования процессов — описание их текущего состояния . При документировании процессов необходимо стремиться к описанию реального, а не идеального состояния Описание процессов необходимо при документировании, инжиниринге, реинжиниринге и совершенствовании процессов

Цели описания процессов:

1. Разработка системы управления бизнес-процессами 2. Внедрение стандартных методов представления и описания бизнес-процессов 3. Снижение стоимости и повышение качества выполнения бизнес-процессов

4. Стимулирование обсуждения регламентов взаимодействия между подразделениями (это очень актуально — Д.С.)

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

6. Получение возможности повторного использования отдельных процессов в других процессах (использование модульного принципа) (не понял — Д.С.)

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

3.9. Классификация процессов (сомнительная классификация — Д.С.)

1. Основные процессы: * Добавляют качество * Кросс-функциональны в рамках предприятия * Взаимодействуют как с клиентами, так и с партнерами * Через них проходит основной продукт, добавляют продукту ценность, результат получает потребитель В организации выделяются не более 20 основных бизнес-процессов 2. Процессы управления Управление организацией как единой системой: * Целеполагание, планирование, контроль достижения целей * Анализ и выработка корректирующих воздействий * Координация действий отдельных элементов 3. Процессы развития: Определяют тенденции и направления развития основных процессов в зависимости от анализа и прогнозируемых направлений развития организации 4. Вспомогательные процессы

Создают инфраструктуру организации. Не касаются основного продукта, добавляют продукту стоимость, результат получает основной процесс.

Источник: http://www.kgau.ru/istiki/umk/mbp/ch03.html

Источник: http://dps.smrtlc.ru/Copyright/Business_process.htm

Выделение бизнес-процессов организации: подход, основанный на результатах процессов

Определение процессов.:  На первом этапе описания процесса надо определить деловые процессы в

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

В статье описан один из методов выделения бизнес-процессов, опробованный на практике и доказавший свою эффективность. Автор не претендует на какую-либо теоретическую новизну; цель статьи — описание метода как рабочего инструмента. Представляется, что знакомство с описанной методом будет полезно начинающим бизнес-аналитикам.

Общепринятые подходы к выделению бизнес-процессов

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

В качестве референтных моделей могут быть выбраны: универсальная модель процессов OBM от Oracle, 8-процессная модель BKG и 13-процессная модель ИСО/МЭК/ТО 15504 ([3]), референтная модель APQC ([4]).

Можно оттолкнуться от требований стандартов управления качеством ISO 9000:2000 ([5]). Существуют также отраслевые референтные модели (для банков [9], производственных [10], логистических компаний и т. п.).

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

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

Если исследуется нетиповая организация (коммерческая с нетрадиционной моделью бизнеса; некоммерческая; государственная; организация-монополист), то применение референтных моделей затруднено, лучше строить модель процессов «с нуля».

Для этого применимы разные подходы (методы):

  1. Функциональный подход предполагает выделение бизнес-процессов исходя из функций, выполняемых подразделениями ([2], [5]);
  2. Продуктовый подход — исходя из результатов процессов (товаров и услуг, которые производит организация) [7];
  3. Подход, основанный на анализе цепочек создания ценности ([4], [8]);
  4. Матричный подход: модель бизнес-процессов представляет собой матрицу, каждый элемент которой является отдельным бизнес-процессом, отражающим подсистемы и этапы жизненного цикла производимого продукта ([8]).

Предлагаем читателю самостоятельно ознакомиться с сутью этих методов [3], [4], [7],[8].

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

Принципы метода

В методе использованы следующие принципы:

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

Модель входов-выходов и классификация входов бизнес-процесса

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

При этом входы процесса удобно классифицировать на преобразующие, преобразуемые и управляющие.На рисунке 1 изображены входы и выходы процесса, расположенные согласно методологии SADT ([2]) и нотации IDEF0.

Рис. 1. Модель процесса, отражающая входы и выходы с их классификацией

Принцип классификации процессов по их основным выходам (результатам)

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

Рис. 2. Четыре группы бизнес-процессов любой организации

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

При этом взаимосвязь первых трёх групп процессов можно представить следующим образом.

Основные процессы для функционирования требуют ресурсы, которые поступают либо из внешней среды, либо от обеспечивающих процессов:

Рис. 3. Взаимосвязь основных и обеспечивающих процессов

Управленческие процессы связаны с основными в единый контур управления. Деятельность в организации планируется (формально или неформально).

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

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

Рис. 4. Взаимосвязь основных и управленческих процессов в контуре управления

Последовательное выделение процессов, начиная с их результатов

Вышеописанные связи процессов позволяют выделять процессы один за другим, отталкиваясь от результатов деятельности всей организации. Использование этого принципа будет подробно рассмотрено далее.

Учёт интересов всех заинтересованных сторон

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

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

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

Начало анализа: предназначение организации, ключевые заинтересованные стороны и результаты

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

Рис. 5. «Сферическая организация в вакууме»

На этапе предварительного знакомства с организацией можно сделать предположения о её назначении и результатах деятельности (т. е. выходах бизнес-процессов) и заинтересованных сторонах. Часто эта информация есть на корпоративном сайте.

Уже можно выделить результаты деятельности (товары, работы или услуги) и попробовать каким-либо образом их структурировать: по типу, виду, отрасли или сегменту потребительского рынка.

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

Рис. 6. Определены ключевые потребители и результаты деятельности организации

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

Построение цепочек ценности основных бизнес-процессов

Найденные результаты деятельности организации — не что иное, как выходы основных бизнес-процессов (как следует из вышеприведённого определения).

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

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

Рис. 7. Выделены ключевые основные бизнес-процессы. Об остальных пока информации нет

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

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

В методологии ARIS есть специальная нотация — VAD (value added chain — Диаграмма цепочек добавленного качества, [1]), автор обычно рисует цепочки ценности в аналогичном виде при помощи Visio.

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

Рис. 8. Цепочка ценности производственного предприятия

Цепочка ценности строительного предприятия может выглядеть так:

Рис. 9а. Цепочка ценности компании, строящей промышленные объекты (VAD)

Эта же цепочка ценности, созданная в программе Business Studio 4.0 с использованием нотации IDEF0, может выглядеть так:

Рис. 9б. Цепочка ценности компании, строящей промышленные объекты (IDEF0, Business Studio)

Такой путь описания основных бизнес-процессов полностью согласуется с построением потоков стоимости в концепции «бережливого производства»— Lean ([6]), но применимо для любых организаций. Цепочки ценностей торговых компаний или компаний, предоставляющих услуги, обычно намного проще.

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

Описание (предварительная спецификация) отдельных процессов

Теперь необходимо подробнее описать каждый выделенный основной бизнес-процесс (этап цепочки ценности).

Для каждого процесса необходимо выделить ключевые входы и выходы (по-прежнему нет смысла документировать абсолютно всё: задача — определить взаимосвязи бизнес-процессов).

Особое внимание — на входящие и информационные потоки, а также планы и отчётность по процессу. Пример описания бизнес-процесса из первой цепочки ценности приведён в таблице 2.

№  Описываемые входы и выходы Пример для бизнес-процесса «Сборка металлоконструкций»
1Преобразуемые входы
1.1Материальные ресурсы (сырьё)
  • Окрашенные компоненты металлоконструкций;
  • Крепёжный материал;
  • Упаковочный материал.
1.2Информационные потокиЗаказы на производство (электронный документ) со статусом «в производстве»
2Преобразующие входы
2.1Материальные ресурсы (инфраструктура)
  • Помещение сборочного цеха;
  • Погрузчик;
  • Рабочие места сборщиков;
  • Инструменты для сборки;
  • Оргтехника.
2.2Человеческие ресурсы
  • Начальник цеха;
  • Сборщики.
3Управляющие входы
3.1Планы
  • План производства;
  • Бюджет производственных затрат цеха.
3.2Управленческие воздействия
4Выходы (результаты)
4.1Основные материальные выходыСобранные металлоконструкции, готовые к отправке
4.2Побочные материальные выходы
  • Брак;
  • Остатки упаковочного материала.
4.3Информационные потокиЗаказы на производство (электронный документ) со статусом «выполнен»
4.4Отчётность по процессу
  • Отчёт по работе цеха за день;
  • Отчёт по производственным затратам цеха.

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

Результатом этого этапа будут списки входов основных бизнес-процессов. Анализируя эти списки, аналитик выходит на обеспечивающие процессы (их результаты — преобразующие и преобразуемые входы) и на управленческие процессы (их результаты — управляющие входы) согласно взаимосвязям процессов (рис. 3).

Выделение обеспечивающих бизнес-процессов

Выделение и описание границ этих процессов производится аналогично основным. Здесь полезны референтные модели процессов. Обычно выделяются следующие обеспечивающие процессы:

  • Воспроизводство инфраструктуры (производственной, общехозяйственной, транспортной, ИТ и связь и т. п.) — это обычно целый ряд процессов, владельцами которых являются разные подразделения;
  • Воспроизводство персонала;
  • Учёт (в разных аспектах — операционный/производственный, бухгалтерский, управленческий);
  • Управление финансовыми потоками.

Какие нюансы здесь необходимо учитывать?

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

Выделение и описание управленческих процессов

На этом этапе также есть свои нюансы.

Управленческие процессы в этом подходе понимаются как совокупность процессов планирования и регулирования в контуре управления на разных уровнях управления (см. рис. 4).

Классический менеджмент выделяет три уровня управления, каждому соответствует свой контур управления:

Рис. 10. Уровни управления организацией

  • Стратегический (институциональный) уровень: на нём оценивается, насколько организация успешно взаимодействует в условиях внешней среды, устанавливаются стратегические (долгосрочные) цели и принимаются решения стратегического характера;
  • Управленческий (системный) уровень: на нём оценивается соответствие построенных в организации систем (операционных систем, систем контроля, мотивации, управления качеством и т. п.) стратегическим целям, принимаются решения о развитии или изменении этих систем;
  • Операционный (технический, низовой) уровень: на нём оцениваются результаты отдельных процессов на соответствие заданным целям и критериям.

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

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

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

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

Моделирование процессов развития

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

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

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

Объединение процессов в единую сеть

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

Верификация модели

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

цикл «автор-читатель» [2]), а также анализом положений о подразделении и должностных инструкций.

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

Кратко о преимуществах и недостатках метода

По мнению автора, метод обладает следующими преимуществами:

  1. Нацеленность на создание ценности для потребителей организации;
  2. Эффективность: метод позволяет выделить процессы за минимальное время с минимальными затратами времени аналитиков и сотрудников организации.

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

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

Кроме того, метод не очень применим для целей, подразумевающих тотальное описание деятельности компании: внедрение системы менеджмента качества, «сплошная» автоматизация и т. п.

Источники информации

[1] М. Каменнова, А. Громов, М. Ферапонтов, А. Шматалюк. Моделирование бизнеса. Методология ARIS -М.: Весть-МетаТехнология, 2000 [2] Марка Д., МакГоуэн К. Методология структурного анализа и проектирования. — М.: МетаТехнология, 1993

[3] Риб С.И., Кремлева И. В. Различные подходы к выделению и описанию бизнес-процессов

[4] Репин В. В. Бизнес-процессы. Моделирование, внедрение, управление. — М: Манн, Иванов и Фербер, 2013
[5] Репин В.В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.:РИА «Стандарты и качество», 2004
[6] Ротер М., Шук Дж. Учитесь видеть бизнес-процессы. Практика построения карт потоков создания ценности. М.: Альпина Бизнес Букс, 2006
[7] Слепухина И. А. StartUp моделирования бизнес — процессов (универсальная модель предприятия)
[8] Хлебников Д., Яцына, А, Савушкин Л. Матричная модель предприятия
[9] Комплексная типовая бизнес-модель банка (финансовой организации) Версия 5.0
[10] Модель деятельности производственного предприятия (дискретное производство)

Источник: https://www.businessstudio.ru/articles/article/vydelenie_biznes_protsessov_organizatsii_podkhod_o/

Бизнес процесс

Определение процессов.:  На первом этапе описания процесса надо определить деловые процессы в

Конечно же у понятия “Бизнес процесс” существует огромное количество альтернативных определений.

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

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

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

Что же дает нам типовая структура (скелет) бизнес процесса? Опираясь на нее в любой момент времени мы однозначно сможем сказать про любой процесс, формализован он или нет, готов ли он к внедрению или требует доработок. Если требует доработок, то по каким направлениям/параметрам.

Шесть вопросов к бизнес процессам

Типовая структура процесса – это набор простых вопросов, отвечая на которые мы получаем о процессе всю необходимую для его качественного выполнения информацию. Бизнес процесс можно считать полностью описанным, когда его описание дает ответы на 6 следующих вопросов:

  1. Зачем компании нужен этот бизнес процесс? (Цели процесса)
  2. Что этот бизнес процесс производит в качестве результата? (Результаты процесса)
  3. Из чего этот бизнес процесс создает свой результат? (Ресурсы процесса)
  4. Когда этот бизнес процесс должен начаться и произвести результат? (Временные параметры процесса)?
  5. Кто отвечает за результат этого бизнес процесса и принимает участие в выполнении бизнес процесса? (Ответственность за выполнение процесса)
  6. Как должен выполняться этот бизнес процесс? (Алгоритм процесса)

Зачем?

“Самое дорогое у человека — это жизнь. Она дается ему один раз, и прожить ее надо так, чтобы не было мучительно больно за бесцельно прожитые годы”

(Н.А. Островский, “Как закалялась сталь”).

Зачем – это, пожалуй, самый важный вопрос. Зачем нам нужен данный конкретный процесс? На достижение каких целей бизнеса он направлен? Если у процесса нет цели, то всякая деятельность, сосредоточенная в нем, бесцельна.

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

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

Данный процесс направлен на достижение цели “Повышение удовлетворенности клиента”. Достижение данной цели в свою очередь измеряется показателем NPS (Net Promoter Score, индекс потребительской лояльности).

Что?

Отвечая на этот вопрос, мы определяем результаты процесса. При этом результаты появляются не сами по себе, и не в формате “мы всегда это делали”, “исторически сложилось”. Нет. Каждый результат появляется в ответ на конкретный запрос потребителей процесса.

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

Лишние результаты не приносят нашему бизнесу никакой пользы, но при этом потребляют наши ресурсы.

Из чего?

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

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

Для удобства работы с ресурсами их, как правило, разбивают на три группы:

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

Для каждого ресурса определяется его владелец (поставщик).

Когда?

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

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

Если вернуться к нашему примеру: когда процесс “Обработка обращения клиента по линии технической поддержки” будет запущен? Когда поступит обращение в техническую поддержку. Соответственно стартовым событием будет событие: “Поступило обращение в техническую поддержку”.

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

Кто?

Ответ на это вопрос закрепляет ответственность за выполнение процесса.

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

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

Как?

На этом этапе проектируется алгоритм (сценарий) выполнения процесса. Чаще всего он описывается в виде графической схемы. Графический способ описания процесса называется “Нотация”.В настоящий момент существует огромное количество нотаций. С самыми популярными и востребованными мы познакомим наших читателей в следующих статьях.

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

Источник: https://highadvance.org/biznes-process-stroenie/

Описание процессов в рамках системы менеджмента качества на основе методологии функционального моделирования IDEF0

Определение процессов.:  На первом этапе описания процесса надо определить деловые процессы в

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

стандартов ИСО 9000:2000. Статья предназначена для специалистов посистемам качества, а также на аналитиков, специализирующихся в области

функционального моделирования процессов.

Ключевые слова: IDEF0, ИСО 9000, система качества,
процессный подход, процесс, описание процессов, классификация процессов
.

Введение

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

идеологическое лидерство, первенство в средствах и методах реализации.

Между тем «процессный подход» как концепция известен ужедавно как в методологии классического менеджмента, так и в различных еготехниках, таких, например, как структурный анализ сложных систем [6],

ре-инжиниринг деловых процессов [7] и др. 

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

восприятия и анализа описания. 

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

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

потребностями и задачами менеджмента (Рис. 1).

Например, одна и та же организация может быть представлена
как:

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

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

одной из основных «проекций».

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

установления удовлетворенности деятельностью» [3]. 

Описание объекта управления для целей общего руководстваначинают с описания процессов, определяющих миссию, и продолжают до достижениянеобходимой степени «прозрачности», достаточной для корректного анализа и

выработки эффективных управленческих решений.

 Эффективный менеджмент качества через призму процессного
подхода можно представить условно как совокупность двух элементов:

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

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

также неуклонно повышать удовлетворенность потребителей. 

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

они находятся под контролем, т.е. в управляемых условиях.

Описание процессов

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

компонентов и взаимосвязей между ними.

 Моделирование предполагает наличие в обязательном порядкеустановленного набора изобразительных (выразительных) средств и правил – языкаописания объекта. Среди наиболее распространенных языков описания и

соответствующих им моделей можно выделить:

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

Например, ЕСКД (единая система конструкторской документации) – набор средств
и правил получения графического описания объекта, называемого чертеж.

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

так и элементы графической модели (поясняющие схемы, рисунки и т.п.).

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

различные варианты для графического представления процессов. 

Рис. 3Варианты графического представления процессов.

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

организации.

 Описание сети процессов, составляющих деятельностьорганизации – это сложная организационно-техническая задача, для решения которой

требуются специальные средства описания и анализа.

Впервые это обстоятельство было осознано в середине 70-хгодов при реализации комплексных проектов по заказам ВВС США.

В то же время былапредложена и реализована программа комплексной компьютерной поддержкипроизводства (ICAM – Integrated Computer-Aided Manufacturing), в рамках которой,в частности, применялась методология структурного анализа систем.

Позже на базеэтого подхода была разработана методология функционального моделирования IDEF0,которая в 1993 году была принята в качестве федерального стандарта в США [8], ав 2000 году – в качестве руководящего документа по стандартизации в Российской

Федерации [9].

В методологии функционального моделирования IDEF0 [7-9] для
графического представления процесса используется следующая нотация (Рис. 4).

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

необходимых ресурсов (механизмов) в управляемых условиях.

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

 Модель сети процессов в рамках СМК должна отвечать на следующие вопросы:

  • Какие процессы в деятельности организации относятся к системе качества?
  • Какова структура (элементы) этих процессов, включая выходы и потребителей процессов, входы и поставщиков и т.д.?
  • Как процессы взаимодействуют друг с другом?
  • Как в рамках процессов выполняются требования, определенные в МС ИСО 9001:2000 года?

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

IDEF0).

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

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

    их элементы, влияющие на качество конечной продукции.

  2. Функциональная модель должна содержать процессы, определенные как обязательные в рамках требований МС ИСО 9001:2000. Перечень этих процессов

    приведен в МС ИСО 9001:2000 [2, разделы 4-8].

  3. Функциональная модель должна содержать элементы процессов, определенные как обязательные в рамках требований МС ИСО 9001:2000. Перечень таких

    элементов приведен в [2, разделы 4-8].

  4. Функциональная модель должна охватывать все стадии жизненного цикла
    продукции, относящиеся к сфере деятельности организации.

Для того чтобы функциональная модель удовлетворялаперечисленным требованиям, она должна строиться как модель делового процесса

[11].

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

информационные и трудовые ресурсы, поставляемые внешними поставщиками.

Таким образом, функциональная модель делового процесса будетохватывать процессы жизненного цикла, а также связанные с ними вспомогательныепроцессы и процессы менеджмента, входящие в состав деятельности организации. Это

полностью согласуется с требованиями МС ИСО семейства 9000 версии 2000 года.

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

5).

В МС ИСО 9001:2000 к обязательным процессам относятся:

  • Реализация ответственности высшего руководства в рамках системы качества;
  • Менеджмент ресурсов (кадры, инфраструктура, рабочая среда);
  • Менеджмент производственных процессов (процессов жизненного цикла продукции приравненных к ним по степени важности вспомогательных процессовобеспечения);
  • Процессы измерения, контроля и улучшения СК.
  • К обязательным элементам процессов, составляющих деловой процесс, относятся в том числе [2]:
  • Документы, содержащие политику, цели организации в сфере менеджмента качества, руководство по качеству;
  • Документированные процедуры, в том числе документы, содержащие ответственность сотрудников организации;
  • Документация на процессы, необходимая для обеспечения их эффективного планирования, управления и улучшения;
  • Записи качества, и т.д.

Соответственно, функциональная модель должна содержать все
обязательные процессы и элементы в соответствии с требованиями МС ИСО9000:2000.

В нашем примере деловой процесс в швейном ателье будет иметь
следующую структуру (Рис. 6).

  На диаграмме (Рис. 6) процесс представлен в виде четырехвзаимодействующих между собой процессов. Каждый из четырех процессов является

обязательным с точки зрения выполнения требований МС ИСО 9001:2000 [2]. 

Дуги, связывающие функциональные блоки, представляютэлементы, которые передаются с выходов одних процессов на входы других. В томчисле, они представляют обязательные с точки зрения МС ИСО 9000:2000 элементыпроцессов, такие как, например, «Записи качества» или «Политика организации в

области менеджмента качества».

Классификация процессов

Классификация процессов является важным этапом анализадеятельности организации. Одна из целей классификации – определение процессов,

относящихся к системе качества организации.

Функциональная модель состоит из элементов двух типов –функциональных блоков и дуг [8, 9]. Соответственно, классификация процессов,представленных на функциональной модели, сводится к классификации собственно

функциональных блоков и дуг [12].

В рамках IDEF0-модели дуги в зависимости от их положения надиаграмме уже подразделены на четыре категории: входные, выходные, управления и

механизма.

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

категорий могут относиться:

  • Материалы, сырье, продукция, ресурсы;
  • Информация, данные, записи качества, документы;
  • Распоряжения руководства, планы, графики; распорядительные документы;
  • Стандарты, нормативная документация;
  • Ответственные исполнители, сотрудники организации и т.д. 

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

Поскольку дуги на IDEF0-модели представляются прямыми и ломаными линиями,графический стиль для дуг включает соглашение о цвете линии, толщине линии, типелинии (сплошная, пунктирная, штрих — пунктирная, и т.д.

), а также о типе стрелки

на конце дуги.

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

Следует отметить, что установление соответствия междукатегорией объекта (например, «Записи качества») и графическим стилемпредставления этого объекта (зеленая сплошная линия) в функциональной моделииграет не только презентационную роль.

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

документом, в котором появились изменения. 

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

впервые было предложено и реализовано в системе IDEF0/EMTool

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

которые регламентированы в МС ИСО 9001:2000 [2] .

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

по аналогии с соглашениями для дуг. 

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

поддержания в рабочем состоянии и улучшении СМК.

Заключение

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

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

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

выход на мировой рынок.

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

В пользу применения методологии IDEF0 для описания иклассификации процессов говорит не только ее возможность решить эту задачу врамках СМК, но также тот факт, что данная методология также является стандартомдля функционального моделирования в ряде стран, включая США и Россию. Последнееобстоятельство делает возможным использовать методологию IDEF0 в качествеединого языка для обмена информацией между организациями, аудиторами,

экспертами.

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

информационную систему организации.

Литература

  1. Международный стандарт ИСО 9000. Системы менеджмента качества. Основные
    положения и словарь. 2-е изд. 2000-12-15. ISO — 2000.
  2. Международный стандарт ИСО 9001. Системы менеджмента качества. Требования.
    3-е изд. 2000-12-15. ISO – 2000.
  3. Международный стандарт ИСО 9004. Системы менеджмента качества. Руководство
    по улучшению деятельности. 2-е изд.

    ISO – 2000.

  4. ISO 9000 Introduction and Support Package: Guidelines on the Process
    Approach to quality management systems. ISO/TC 176/SC 2/N 544R. 17 May, 2001.
  5. ISO 9000 Introduction and Support Package: Guidance on the Documentation
    Requirements of ISO 9001:2000. ISO/TC 176/SC 2/N 544R. 13 March, 2001.
  6. Давид Марка, Клемент МакГоуэн.

    Методология структурного анализа и
    проектирования. Пер . с англ . М .:1993, 240 с ., ISBN 5-7395-0007-9.

  7. David Vaskevich. “Client\ Server Strategies. A Survival Guide For
    Corporate Reengineers”. \2nd edition,\ IDG Books Worldwide, 1995
  8. INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0).

    Draft Federal Information Processing Standards Publication 183, 1993, December 2.

    www.idef.com .   

  9. Р50.1.028-2001. Методология функционального моделирования. М.: Госстандарт
    России, 2000.
    www.cals.ru  
  10. Менеджмент качества и международные стандарты ИСО 9000 версии 2000 г. Материалы семинара в рамках Программы ИСО для развивающихся стран. Минск, Июль

    2001 г. 79 с.

  11. Framework for Managing Process Improvement. Vol.1. Electronic College of
    Process Innovation. DoD USA. May, 1994.

Андрей Георгиевич КУРЬЯН
Andrew.Kuryan@bykoncept.com

ИП ОРИЕНТСОФТ  
www.orientsoft.by

Павел Степанович СЕРЕНКОВ, к.т.н., доцент
Pavel_Serenkov@mail.ru

Белорусская Государственная Политехническая Академия

Минск, Республика Беларусь Сентябрь, 2001

Источник:www.bigspb.ru

Оцените публикацию

Источник: https://hr-portal.ru/article/opisanie-processov-v-ramkah-sistemy-menedzhmenta-kachestva-na-osnove-metodologii

Определение бизнес-процессов

Определение процессов.:  На первом этапе описания процесса надо определить деловые процессы в


ниже приведены некоторые определения бизнес-процессов:

Бизнес-процесс — совокупность различных видов деятельности, в рамках которой «на входе» используется один или более видов ресурсов, и в результате этой деятельности «на выходе» создается продукт, представляющий ценность для потребителя. (М. Хаммер, Д. Чампи, Реинжиниринг бизнес-процессов)

Бизнес-процесс — совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы. (ISO 9000:2000)

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

Бизнес-процесс — это:

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

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

  • «Выход» описывает то, что создается в результате деятельности, ее конкретную цель (ценность для клиента, ценность для заинтересованных лиц) — в частном случае, это товары и услуги;
  • «Вход» описывает то, что преобразуется или расходуется в процессе деятельности (например, сырье и материалы, заявка на выполнение работ, обращение клиента и т.п.); 
  • «Управление» — описывает целенаправленный характер деятельности и включает все допустимые управляющие воздействия (приказы, распоряжения, задания на выполнение работ и т.п.);
  • «Механизм» («Ресурсы») — описывает ресурсы, используемые для достижения поставленной цели (например, оборудование, человеческие ресурсы). Их отличие от «Входа»  в том, что они используются в производственном цикле многократно;
  • «Функциональный блок» — собственно деятельность компании или ее части, по преобразованию «Входа» в «Выход», преследующего заданную цель, установленную в «Управлении» и использующая для этого имеющиеся «Ресурсы». 

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

Вход бизнес-процесса — ресурс, необходимый для выполнения бизнес-процесса.

Выход бизнес-процесса — результат (продукт, услуга) выполнения бизнес-процесса.

Документооборот — система документального обеспечения деятельности организации.

Заказчик — должностное лицо, имеющее ресурсы и полномочия для принятия решения о проведении работ по описанию, регламентации или аудиту (проверке) бизнес-процесса.

Модель — графическое, табличное, текстовое, символьное описание бизнес-процесса либо их взаимосвязанная совокупность.

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

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

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

Показатели продукта (услуги) — параметры продукта бизнес-процесса.

Показатели (данные) удовлетворенности клиента (потребителя) — параметры удовлетворенности клиента.

Поставщик — субъект, предоставляющий ресурсы.

Потребитель (клиент) — субъект, получающий результат бизнес-процесса.

Потребитель может быть:

а) внутренний — находящийся в организации и в ходе своей деятельности использующий результаты (выходы) предыдущего бизнес-процесса;

б) внешний — находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации.

Операция (работа) — часть бизнес-процесса.

Регламент бизнес-процесса (описание бизнес-процесса) — документ, описывающий последовательность операций, ответственность, порядок взаимодействия исполнителей и порядок принятия решений по улучшениям.

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

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

{НАВЕРХ}

Источник: https://plansys.ru/process/business-process-definition

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

Определение процессов.:  На первом этапе описания процесса надо определить деловые процессы в

< Предыдущая СОДЕРЖАНИЕ Следующая >

Перейти к загрузке файла

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из важнейших способов описания процесса являются диаграммы потоков данных (информации) 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. Формально эта методология называется 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.

Page 3

Перейти к загрузке файла

Методология А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.

Источник: https://studbooks.net/1402555/menedzhment/opisanie_protsessa_verhnego_urovnya_metodologii_idef0

Scicenter1
Добавить комментарий