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

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

Терминология процессного подхода [по Репину, Елиферову]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение ролевых функций управления процессом

В	А	К	Код	Ролевая функция
			1	ПЛАНИРОВАНИЕ
✓	✓		1. 1.	определить ключевую компетенцию процесса в системе процессов организации
✓	✓		1.2.	определить цели процесса и критерии оценки результатов
✓	✓		1.3.	определить процесс как поток создания ценности для внутреннего потребителя
✓	✓		1.4.	определить заинтересованные стороны, имеющие отношение к процессу, их потребности и ожидания
✓	✓		1.5.	установить требования потребителей и структуру ожидаемых выходов процесса, структуру входов и требования к поставщикам
✓	✓	✓	1. 6.	определить критерии для выходов каждого процесса, основанных на критериях для выходов системы, оценивать возможности и производительность каждого процесса
✓	✓		1.7.	определить события процесса (стартовые, промежуточные, финишные)
✓	✓		1.8.	определить последовательность, организационные и информационные взаимодействия процесса
✓	✓		1.9.	определить стандартные операционные процедуры для процесса, включая критерии для их выходов и условий функционирования
✓			1. 10.	определить методы выполнения операций в рамках процесса
✓	✓	✓	1.11.	определить критерии и методы (мониторинга, измерения и соответствующие показатели результатов деятельности), необходимые для результативного функционирования процесса и управления им
✓		✓	1.12.	определить контролируемые пределы вариации для нормального осуществления процесса
✓	✓	✓	1.13.	определить контрольные точки и индикаторы, которые позволяют результативно и эффективно выявлять отклонения параметров процесса
✓		✓	1. 14.	разработать рекомендации по контролю соответствия характеристик продукции и услуг, регулированию хода процесса и устранению несоответствий
✓	✓		1.15.	установить контролируемые пределы вариаций и соответствующие статистические методы для измерения процесса (в ходе перспективного планирования качества продукции и включать их в план управления в границах процесса)
✓	✓		1.16.	определить ресурсы, необходимые для процесса и обеспечить их доступность (человеческие, инфраструктурные, информационные)
✓			1.17.	распределить обязанности, ответственность и полномочия в отношении процесса, назначить ответственного за реагирование на отклонения
✓	✓		1. 18.	определить компетенции и возможности сотрудников для достижения результата процесса, проводить обучение
✓			1.19.	определить методы мотивации участников процесса
✓		✓	1.20.	определить потребности в документации для обеспечения воспроизводимости процесса
✓			1.21.	определить формы документирования информации по потоку создания ценности процесса и записи о соответствии требованиям
✓	✓		1.22.	разработать обязательные документированные процедуры (в границах процесса)
✓	✓		1. 23.	разработать и поддерживать в актуальном состоянии документы, необходимые для обеспечения результативного планирования, осуществления и управления процессом
✓	✓		1.24.	документировать процедуры для процессов производства, измерения, технического контроля, испытаний и технического обслуживания
✓	✓		1.25.	документировать процедуры для процессов наладки, управления, реагирования на неуправляемые условия, поиска отклонений
✓	✓		1.26.	документировать информацию касательно продукции и услуг, на которые распространяются требования
✓	✓		1. 27.	определить внутренние факторы среды, влияющие на способность достигать целевого результата процесса
✓		✓	1.28.	установить риски и возможности процесса, планировать действия для постоянного улучшения по выполнению требований потребителей по качеству, срокам, стоимости и объемам
✓			1.29.	разработать план качества и процедуры по перспективному планированию качества продукции в границах процесса
✓	✓		1.30.	разработать планы действий на случай непредвиденных обстоятельств
		✓	1. 31.	планировать аудиты качества процесса через запланированные интервалы времени
			2	ВЫПОЛНЕНИЕ
✓	✓		2.1.	интегрировать процесс в поток создания ценности
✓			2.2.	осуществлять процесс в управляемых условиях, включая: наличие информации, описывающей характеристики продукции; наличие рабочих инструкций; применение подходящего оборудования; проведение мониторинга и измерений
✓			2.3.	обеспечить процесс необходимыми ресурсами для поддержания процесса в рабочем состоянии и достижения целей
✓			2. 4.	идентифицировать последовательность выпуска продукции и выходов процесса
✓			2.5.	управлять процессами и их взаимодействиями, как системой, чтобы повысить согласованность между процессами
✓			2.6.	управлять рабочей нагрузкой и качеством по входу процесса
✓	✓		2.7.	проводить анализ, подтверждать и документировать способность процесса для выполнения требований потребителя
✓	✓	✓	2.8.	использовать измеримые ключевые показатели деятельности, учитывающие: потребности и ожидания потребителей; значимость продукции и услуг; результативность и эффективность процессов; рентабельность и финансовую результативность; законы и нормативы
✓		✓	2. 9.	обеспечить визуализацию и прозрачность (прослеживаемость) для быстрого обнаружения несоответствий
✓	✓		2.10.	поддерживать требуемую документированную информацию по процессу в актуальном состоянии, обеспечивать ее доступность, пригодность, сохранность и конфиденциальность
✓			2.11.	обеспечить доступность и актуальность документации по процессу на рабочих местах исполнителей
✓		✓	2.12.	периодически анализировать Рабочие инструкции для обеспечения их адекватности и понимания персоналом
✓		✓	2. 13.	представлять заинтересованным сторонам отчеты о параметрах функционирования и возможностях процесса в достижении запланированных результатов
✓			2.14.	вести записи по качеству процесса для предоставления свидетельств соответствия требованиям и результативности процесса
✓			2.15.	демонстрировать лидерство и выполнение взятых на себя обязательств
✓			2.16.	поддерживать компетенции участников процесса и развивать их творческий потенциал
✓			2. 17.	доводить до участников процесса важность выполнения требований и его результативности
✓			2.18.	поощрять инициативу, содействовать и мотивировать участников процесса на постоянное улучшение процесса
✓			2.19.	формировать поведение участников процесса, ориентированное на заинтересованные стороны, постоянное улучшение и снижение потерь
✓			2.20.	избегать наказаний за непреднамеренные ошибки и несоответствия
			3	КОНТРОЛЬ
✓		✓	3. 1.	оценивать удовлетворенность потребителей и восприятие выполнения их требований
✓	✓	✓	3.2.	проводить оценку реальных и потенциальных потерь в потоке создания ценности процесса
✓		✓	3.3.	идентифицировать параметры процесса
✓	✓		3.4.	идентифицировать взаимосвязи между параметрами процесса
✓	✓		3.5.	оценивать результативность, оперативность, ресурсоемкость и управляемость процесса
✓		✓	3. 6.	оценивать возможности системы измерений процесса
✓		✓	3.7.	оценивать возможности процесса по обеспечению соответствующих бизнес-целей
✓		✓	3.8.	оценивать возможности процесса в достижении запланированного выхода (продуктов процесса)
✓		✓	3.9.	оценивать возможности процесса по взаимодействию с другими процессами
✓	✓	✓	3.10.	регулярно анализировать процесс, его взаимодействия и предпринимать соответствующие меры для их улучшения, чтобы обеспечить устойчивость и результативность процессов организации
✓		✓	3. 11.	оценивать возможности и производительность процесса для обеспечения ожидаемой производительности системы, планировать мероприятия по улучшению процесса
✓		✓	3.12.	оценивать риски, связанные с процессом, и принимать необходимые меры для предотвращения, выявления и снижения последствий нежелательных событий
✓		✓	3.13.	регулярно проводить мониторинг процесса для выявления отклонений от нормы и принимать без задержки меры по обнаружению и исправлению изменений в процессе, вызванных этими отклонениями
✓		✓	3.14.	анализировать обмен информацией между участниками процесса
✓		✓	3. 15.	контролировать соблюдение стандартов
✓		✓	3.16.	оценивать эффективность внедрения, поддержания и улучшения процесса
✓		✓	3.17.	анализировать виды и последствия отказов (в границах процесса)
✓		✓	3.18.	определять критерии и методы аудита
✓		✓	3.19.	проводить периодический аудит качества процесса (включая ведение записей)
✓		✓	3. 20.	доводить информацию по результатам аудита до соответствующих руководителей (заинтересованных сторон)
✓		✓	3.21.	предпринимать (корректирующие и предупреждающие) действия по управлению и устранению выявленного несоответствия
✓		✓	3.22.	готовить рекомендации и действия по результатам аудита
✓		✓	3.23.	анализировать результативность предпринятых корректирующих действий
			4	УЛУЧШЕНИЯ
✓	✓		4. 1.	сокращать потери внутри и на стыках процесса
✓	✓		4.2.	минимизировать непроизводительную деятельность в процессе
✓	✓		4.3.	обеспечить поиск и сокращение потерь, направленное на снижение себестоимости
✓	✓		4.4.	повышать стабильность (управляемость) и возможности процесса
✓			4.5.	улучшать процесс на основе управления и снижения вариации (изменчивости) его параметров
✓	✓		4. 6.	повышать эффективность (потока создания ценности) процесса с точки зрения безопасности, качества, сроков, стоимости, объемов, рисков, корпоративной культуры
✓		✓	4.7.	исследовать, как параметры процесса и незавершенной продукции, время и условия использования влияют на параметры готовой продукции
✓			4.8.	осуществлять улучшение процесса в отношении рисков
✓	✓		4.9.	оптимизировать информационные и материальные потоки процесса в системе процессов организации
✓		✓	4. 10.	идентифицировать области потенциального улучшения процесса
✓		✓	4.11.	идентифицировать, документировать и внедрять лучшие практики выполнения процесса
✓	✓	✓	4.12.	разрабатывать предложения по совершенствованию процесса с учетом стратегических целей
✓	✓		4.13.	применять методы проектного управления при улучшении процесса
✓			4.14.	планировать мероприятия по совершенствованию процесса по срокам и ответственным
✓	✓		4. 15.	управлять запланированными изменениями и анализировать последствия непредусмотренных изменений
✓	✓		4.16.	определять порядок действий в процессе по улучшению потока создания ценности (операционная стратегия улучшения процесса)
✓	✓		4.17.	достигать операционного совершенства процесса и улучшения его взаимодействия в соответствии со стратегией и целями организации
✓	✓	✓	4.18.	регулярно анализировать достижение целей улучшения процесса и его взаимодействий, а также влияние на соответствующие цели организации, предпринимать необходимые корректирующие действия
✓		✓	4. 19.	проводить оценку результатов мониторинга и измерения параметров процесса по достижению целей и постоянному улучшению
✓		✓	4.20.	повышать культуру встроенного качества (принцип «не принимай, не делай, не передавай брак»)

Понятие процесса — Энциклопедия по экономике

Понятие процесса управленческого консультирования. Организация процессов управленческого консультирования и их характеристика. Стадии и этапы управленческого консультирования. Начало работы. Первый контакт с клиентом и формирование коммерческого предложения. Диагностирование. Выявление необходимых фактов. Их анализ и синтез. Установление обратной связи с клиентом. Планирование действий. Поиск альтернативных вариантов действий и предложения по их осуществлению. Внедрение консультационного проекта. Контроль за его реализацией. Обучение персонала клиента работе в новых условиях. Завершение работы над проектом. Оценка результатов работы, подведение итогов и расчет по обязательствам, обсуждение планов будущего сотрудничества.  [c.307]

Процесс формирования и оптимизации ОСУ коммерческих банков понятие процессов формирования и оптимизации ОСУ возможные разработчики ОСУ последовательность процесса формирования (оптимизации) ОСУ концептуальные подходы к процессу оптимизации ОСУ методические требования к процессам формирования (оптимизации) ОСУ.  [c.381]

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

В управленческой литературе существует множество определений понятия процесс управления в зависимости от выбранного того или иного ключевого момента.  [c. 62]

Понятие процесс управления отражает динамическую сторону управления — это необходимая последовательность действий, из которых складывается воздействие менеджера на коллектив, управляющей системы на управляемую.  [c.63]

Функциональный подход. Он значительно повышает эффективность анализа функционирования логистических систем и подсистем. При его использовании оперируют двумя основными комплексными понятиями процессом функционирования системы и законом функционирования системы.  [c.55]

Здесь и далее по тексту под снабжением предприятия маркой материального ресурса или поступлением ее на предприятие подразумевается один и тот же процесс по физическому смыслу. Аналогично считаются здесь и далее по тексту синонимами понятия процесс расхода марки материала и отпуск ее со склада в цех на производственные, эксплуатационные, ремонтные и хозяйственные нужды .  [c.227]

Сущность управления различными авторами рассматривается как совокупность следующих понятий процесс управления, информация и организация управления. Об организации управления можно говорить, когда выделены цель и объект управления. Информация — это описывающая информация о наличии, состоянии и функционировании компонентов системы мотивирующая информация, обусловливающая выбор данного целенаправленного воздействия инструкция — информация, оказывающая целенаправленное воздействие на управляемый объект. Организация управления — это содержание (люди, машины), структура (совокупность отношений между компонентами системы при выполнении ее целей), связи (взаимосвязь между компонентами системы), процесс принятия решений (способ и методы выработки инструкций на базе мотивации). Процесс управления — анализ и синтез (построение дерева целей (функций), количественное определение состояния системы или ее разработка синтез — это сборка системы), прогнозирование (предвидение будущего состояния системы и ее компонентов), планирование (упреждающее управление или разработка планов), организация процессов (координация работ по выполнению планов), учет и контроль (сопоставление плановых и фактических состояний параметров систем).  [c.10]

Сам вид функции // (иг), характеризующий одно и то же понятие, процесс или объект разные специалисты могут формировать по-разному. Один считает, что для данного объекта она симметрична и имеет вид равнобедренного треугольника, другой — что это трапеция, а третий — что она имеет вид фигуры неправильной формы. В этом принципиальное отличие функции А(и от функции распределения в теории вероятностей. Сотнями экспериментов установлено, что рассеивание снарядов артиллерийских орудий подчиняется закону рассеивания Гаусса. И ни один специалист не имеет права считать, что оно подчиняется какому-нибудь другому закону распределения, например Эрланга. Если он так считает, он должен это доказать. Таким образом, функция JUA(UJ) — это функция, определяющая субъективное  [c.287]

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

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

Объяснение понятия процесс . Процесс состоит из отдельных ступеней на пути к решению проблемы.  [c.79]

В настоящее время выявлено многообразие отношений между понятиями процесс и предмет, следствие и причина, свойство и процесс и т. д.  [c.20]

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

Следующий уровень тезауруса организации представляет, пожалуй, наиболее широко и разнообразно применяемые понятия процесса и системы, отражающие соответственно динамику и статику окружающего мироздания. При этом если в понимании термина процесс определяющими положениями являются последовательности и изменения, то в определении, представлении, восприятии, понимании, а главное, в применении термина система наиболее существенное, решающее значение имеют элементы и связи.  [c.80]

Определение процесса как последовательности изменений отражает его общее, универсальное, начальное представление. Оно описывает любые, прежде всего объективные, процессы. Если же попытаться определить понятие процесса с позиции осуществляющего его субъекта, то наиболее точно будет так.  [c.81]

В ряде случаев термин структура применяется и к понятию процесса с целью отражения, исследования и представления частных, специфических, системно или объектно ориентированных особенностей его внутреннего строения.  [c.82]

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

Любая субъективная организация осуществляется в условиях сложившейся и развивающейся объективной организации как процесс и система, что определяет их неизбежную конвергенцию. Это явление отражается понятием процесса смешанной организации, к которому относится большинство практически осуществляемых человеком действий. Причем такая конвергенция не является запланированной, а порой и желаемой или ожидаемой [83,24]. Она становится неизбежным этапом и результатом процесса развития современного мироздания, в котором все большую и далеко не всегда конструктивную роль играет человек. Именно это обстоятельство предопределяет ведущее место и постоянно возрастающую роль смешанной организации в современном мире.  [c.208]

Подобные разработки должны опираться как на теоретические построения, так и на анализ адаптации практического материала и быть направлены не столько на представление взаимосвязи отдельных понятий процессов и систем организации и управления, сколько на формирование универсальной и эффективной модели их соотношения и взаимодействия.  [c.310]

В системах управления и повседневной жизни человек постоянно сталкивается с ситуациями, связанными с необходимостью целенаправленного выбора определенного варианта поведения, поступка, акта, действия и т. п. из множества возможных альтернативных (взаимоисключающих) вариантов в конкретной ситуации. Результат выбора принято называть решением, а последовательность действий — разработкой и принятием решения. Поскольку указанная последовательность действий выполняется во времени (выполнение каждого действия требует определенных затрат времени), то вводится понятие процесса разработки и принятия решения.  [c.111]

Индивидуальная оценка недвижимости — это оценка конкретного объекта на определенную дату. Индивидуальная оценка проводится в несколько этапов, объединенных в понятие процесс оценки , на заключительном этапе которого осуществляется согласование результатов, полученных с использованием различных подходов к оценке недвижимости.  [c.28]

Индивидуальная оценка проводится в несколько этапов, объединенных в понятие процесс оценки , на заключительном этапе которого осуществляется согласование результатов, полученных с использованием различных подходов к оценке недвижимости.  [c.25]

Модель включает основные понятия процесса мотивации и показывает, насколько важно объединить такие понятия, как усилия, способности, роль в процессе труда, результаты, удовлетворение и восприятие в рамках единой взаимоувязанной системы. Она демонстрирует необходимость учета всех особенностей мотивации, которые ведут к удовлетворению работника.  [c.90]

И, наконец, эта математическая теория дает строгие определения понятия процесса и способов построения процессов. Эти определения лежат в основе алгебраических законов, реализаций и правил доказательства.  [c.6]

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

В гл. 3 станет очевидно, что DO — не вполне достаточное определение понятия процесса, поскольку в нем никак не представлена возможность недетерминированного поведения, следовательно, нам потребуется более общее и более сложное определение. Все законы для недетерминированных процессов справедливы также и для детерминированных. Но детерминированные процессы  [c.51]

Хотя понятие «процесс» («бизнес-процесс») является в данном контексте наиболее важным, его трудно объяснить менеджерам, так как большинство из них привыкло иметь дело с задачами, работами, структурами, людьми, но не с процессами.  [c.16]

БПР стараются избегать использования понятия «процесс» при описании внутренних организационных шагов. Будем рассматривать разработку бизнеса как объект, точнее, как агрегат объектов. Разработка бизнеса может быть частью различных задач компании. Среди этих задач — реинжиниринг бизнеса (одна из наиболее интересных задач) и усовершенствование бизнеса.  [c.99]

Есть и другие аспекты бизнеса, которые не описываются П-моделью. Очевидно, что бизнес не должен заниматься ничем, что нельзя соотнести с бизнес-процессом неверно думать, что все, что надо выразить, можно выразить в терминах бизнес-процессов. Специалисты наблюдали много попыток бизнес-инжиниринга, когда пытались исказить понятие процесса так, чтобы этим словом можно было обозначить что угодно. Очевидно, что в расчет следует принимать не только требования, регулирующие бизнес-процессы, но и другие например, качество продукции (а не качества самого процесса), структура управления компанией, информация, сообщаемая сотрудникам компании. Можно называть все эти вещи процессами, но это не будет иметь особого смысла. Подобные аспекты будем описывать во внутренней модели.  [c.135]

Следуя этим новым настроениям, и религиозная литература обратилась к критике «примитивного экономизма», опустошения личности, к которому ведет жизнь по формуле «производить, чтобы потреблять». Однако способы действия предлагались различные. Одни религиозные деятели считали, что надо предоставить производству развиваться прежним путем, создавая материальные ценности, но дополнить этот процесс утверждением вне производства моральных ценностей.[39] Другие — прежде всего представители модернизированного буддизма — определили период, начавшийся со второй половины 70-х годов как время размышлений уже не о способах, а о целях развития производства, когда к понятию «экономический рост» все чаще прилагаются вопросы «зачем «, «для чего «. [40]  [c.77]

Управление производством обязательно связано с конкретными календарными датами начала и окончания отдельных операций. В этом динамика управления. Основная задача его в широком смысле слова — поддержание производственного процесса в заданных параметрах исходя из общей цели производства. Для этого существует целый арсенал средств и методов, объединенных понятием система управления наблюдение, подача команд, контроль за их исполнением.  [c.5]

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

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

Приведенные в терминологическом словаре толкования можно, при необходимости, изменять, вводя в них производные признаки, раскрывая значение используемых в них терминов, указывая объекты и процессы, входящие в объем определяемого понятия.  [c.4]

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

Слово «труд» в экономической науке обозначает два понятия «процесс труда» и «ресурсы труда». В первом случае речь идет об умственных или физических усилиях человека (см. разд. 6.1) во втором — о людях, участвующих в производстве благ1. Очевидно, что ни названные усилия, ни люди в современной экономике не могут продаваться-покупаться.  [c.228]

В отечественной и зарубежной литературе существует в целом единообразный подход к понятию процессы — это связанный набор повторяемых действий (функций), преобразующих исходный материал и/или информацию в конечный продукт (услугу) в соответствии с предварительно установленными правилами.  [c.11]

В главе 2 данной работы сказано, что процесс управления является общей суммой всех функций управления. Выполнение функций управления требует определенных затрат времени и сил, в результате которых управляемый объект приводится в заданное или желаемое состояние. Это и составляет основное содержание понятия процесса управления. Таким образом, под ним понимается определенная совокупность управленческих действий, которые логично1 связываются друг с другом, чтобы обеспечить достижение поставленных целей путем преобразования ресурсов в продукцию или услуги1.  [c.62]

TQM — это в значительной мере тот виток диалектической спирали, который возвращает нас к Саратовской системе, когда управление качеством было ориентировано в первую очередь на человека и на его роль в производственном процессе. Потом стали делать акцент на технологию и конструкцию (НОРМ, КАНАРСПИ), управление производством по критериям качества (КС УКП, ИСО 9000). TQM же, аккумулируя все это, возвращает нас к качеству труда, причем не только производственного персонала, но и всех, кто трудится на предприятии — от высшего менеджмента до уборщицы. Кроме того, TQM распространила понятия потребитель и поставщик на партнеров по процессу «справа» и «слева», как это делается в Японии, а понятие процесс не только на технологические процессы производства, но и на последовательность действий, выполняемых при любой работе — от ее начала до получения конечного результата и передачи его на следующий этап петли качества. И еще. TQM подразумевает установление определенных взаимовыгодных отношений не только с партнерами, но с обществом, например, в области защиты окружающей среды.  [c.198]

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

Понятие процесс управления тесно связано с понятием структура управления , рассмотренным в предыдущей главе. Они соотносятся между собой так же, как общеметодологиче-г.кие категории форма и содержание . Структура отражает форму управляющей системы предприятия — порядок расположения, подчиненность составных элементов управляющей системы (отделов, бюро, групп), ее внутреннюю организацию, позволяющую выполнять необходимые функции управления. Содержание процессов управления отражается в функциях, представляющих собой вид управленческой деятельности, совокупность обязанностей, закрепленных за определенным лицом, подразделением, назначение конкретного органа, звена управляющей системы. Следовательно, функции управления объективно определяются содержанием самого процесса производственной деятельности. Они представляют собой специфический вид работ, характеризующихся соответствующим назначением, необходимой однородностью и повторяемостью.  [c.197]

Система workflow обязана поддерживать все компоненты процесса и их различные взаимосвязи (ролевые, информационные, временные, маршрутные и т.д.), поэтому ее функциональная наполненность отражает структуру процесса, его элементы и большая часть понятий и определений workflow базируется на понятиях процесса. В приложениях workflow используется несколько уровней различных категорий деятельности по организации управления информацией процессы, функции, экземпляры процессов и функций, рабочие задания, участники, приложения и информация  [c.172]

Бизнес-процесс — это множество внутренних шагов (видов) деятельности, начинающихся с одного или более входов и заканчивающихся созданием продукции, необходимой клиенту. Назначение каждого бизнес-процесса состоит в том, чтсбь предложить клиенту товар или услугу, т.е. продукцию, удовлетворяющую его по стоимости, долговечности, сервису и качеству. Термин клиент следует понимать в широком смысле. Это может быть действительно просто клиент, а может быть и другой процесс, протекающий во внешнем окружении компании, например у партнеров или субподрядчиков. В понятии процесса нет ничего нового. Каждая компания всегда имела свои процессы. Проблема состоит в том, что процессы не удается описывать так же легко, как организационные иерархические структуры. У организационных подразделений есть «имена» («производство продукции», «доставка продукции»), с ними связаны ответственные должностные лица («президент», «начальник подразделения»). Процессы же обычно невидимы, не имеют описаний и имен. Однако понятие «процесс» возникает более естественным образом, чем организационные иерархии тогда, когда люди коопери-  [c.16]

Часть рынка, характеризующаяся однородной по своему экономическому поведению группой покупателей. С.р. является ключевым понятием концепции маркетинга, ориентированного на спрос. Знание С.р. обеспечивает предприятию выработку точной стратегии маркетинга, правильный выбор его инструментов, экономию средств при осуществлении коммерческой деятельности. С.р. обычно выявляется в результате специальных исследований, в процессе которых определяются лица, принимающие решение о покупке, мотивы приобретения тех или иных товаров, требования различных контин-гентов потребителей к качеству товара, его цене, уровню торгового обслуживания и т.п. Критериями сегментирования рынка товаров для населения считают его уровень доходов, место проживания, семейные традиции, половозрастные и национальные характеристики. В производственной сфере важными факторами являются отраслевая принадлежность предприятия, его размеры, тип производства и характер материалопотребления.  [c.328]

Как правильно определить границы процесса

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

Не стоит недооценивать значимость определения границ бизнес процессов.

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

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

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

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

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

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

Завершение одного процесса всегда является началом другого.

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

Вход – это то, что процесс берет в работу, перерабатывает и из чего производится продукт процесса.

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

Так вот. Это неверно!

Определить границы процесса – это решить несколько задач. Одна из них – установить, в каком случае процесс начинает свое выполнение и когда можно сказать, что процесс завершен. Можно ли сказать, что процесс всегда начинается при поступлении в него входа? Нет. Вход необходим для «производства» продукта, но поступление входа вовсе не означает, что процесс сразу же начнет работу. Процесс может начаться задолго до или после поступления входа. И на это может оказывать влияние куча факторов.

Входы, выходы и события границ процесса

Простой пример.

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

Событие начала

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

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

То же самое касается завершения процесса. Любой процесс должен завершаться событием окончания, которое удобно рассматривать как условие, при наступлении которого мы считаем, что процесс завершен.
Опять же, процесс может не заканчиваться производством своего продукта. В нашем примере с обедом продуктом процесса является удовлетворенный голод. Но означает ли это, что процесс “Обед” будет завершен тогда, когда вы наелись? Конечно же, нет. Более того, есть несколько событий, которыми может закончится обед. Это может быть истечение установленного времени, возвращение на рабочее место или нечто иное.

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

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

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

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

Не все события, которые начинают процесс, формальны

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

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

С событиями разобрались. Теперь вернемся ко входам и продуктам процессов.

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

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

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

Переход права собственности на продукт процесса.

И тут начинается самое интересное.

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

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

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

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

Участники бизнес процесса

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

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

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

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

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

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

Управление или осуществление управленческого цикла процесса

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

• Подпроцессы планирования
• Операционные подпроцессы
• Подпроцессы контроля
• Подпроцессы, связанные с изменением операционной части.

Да, мы говорим сейчас о цикле Деминга – PDCA.

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

Пример

Процесс производства можно разбить на:

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

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

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

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

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

Как правильно определить границы процесса

Резюме

Для того, чтобы правильно определить границы бизнес процесса, необходимо:
1. Определить, к какому типу относится процесс на верхнем уровне – основной, вспомогательный или процесс управления.
2. Конкретизировать продукты процесса и процессы, которые дальше используют эти продукты.
3. Формализовать механизм перехода права собственности продукта процесса.
4. Понять, какие части процесса относятся к непосредственному выполнению операций по производству продукта процесса, а какие к управлению.
5. Определить входы и источники входов процесса.
6. Обозначить события начала и окончания процесса.
7. Определить владельцев процесса и его участников.
8. Понять, какие ресурсы использует процесс и откуда их получает.
9. Дать название процессу, определяющее его суть.

Теперь вы знаете, что нужно делать, чтобы правильно определить границы процесса.

О том, как составить список процессов компании, можно прочитать здесь и здесь.

Глава 6. Работа с процессами в Python

Данная глава является самой первой из трёх глав по применение совместной обработки посредством многопроцессного программирования в Python.
Мы рассмотрели различные образцы процессов, используемых в совместном и параллельном программировании. В этой главе вы получите введение в формальное
определение процесса, а также модуль Python multiprocessing. Данная глава пройдёт некоторыми наиболее
распространёнными способами работы с процессами с применением API этого модуля multiprocessing, такими как
класс Process, класс Pool и инструментами межпроцессного взаимодействия,
такими как класс Queue. Эта глава также рассмотрит ключевые отличия между многопоточностью и множеством
процессов в совместном программировании.

В данной главе будут рассмотрены следующие темы:

• Само понятие процесса в контексте совместного программирования в информатике

• Основы API модуля Python multiprocessing

• Как осуществлять взаимодействие с процессами и те расширенные функции, которые предоставляет модуль
  multiprocessing

• Как модуль multiprocessing поддерживает взаимодействие между процессами

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

Технические требования

Вот перечень предварительных требований для данной главы:

• Убедитесь что на вашем компьютере уже установлен Python 3

• Выгрузите необходимый репозиторий из GitHub

• На протяжении данной главы мы будем работать с вложенной папкой, имеющей название Chapter06

• Ознакомьтесь со следующими видеоматериалами Code in Action

Понятие процесса

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

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

Например, интернет браузер Google Chrome обычно управляет неким процессом с названием Google Chrome
Helper в качестве его основной программы чтобы снабжать веб просмотр и прочие процессы помощью в различных целях. Самый простой способ
увидеть различные процессы вашей системы состоит в запуске и управлении, вовлекающим в себя использование
Task Manager для Windows,
Activity Monitor для iOS и
System Monitor для операционных систем Linux.

Ниже приводится экранный снимок моего Activity Monitor. В этом списке можно обнаружить
множество процессов с названием Google Chrome Helper. В колонке
PID (что является сокращением от process
ID) сообщается значение уникального идентификатора, который имеет каждый такой процесс:

Сопоставление процессов и потоков

Одной из самых распространённых ошибок, которую делают программисты при разработке совместных или параллельных приложений состоит в путанице
имеющейся структуры и функций процессов и потоков. Как мы уже видели в Главе 3, Работа с потоками
в Python, некий поток является наименьшим элементом программного кода и обычно он является каким- то компонентом процесса. Более того,
внутри одного и того же процесса может быть реализовано более одного потока для доступа и совместного использования памяти и прочих ресурсов, в то
время как различные процессы не взаимодействуют таким образом. Такая взаимосвязь отображена на следующей схеме:

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

• Некий образ (или копия) того кода, который подлежит исполнению из своей родительской программы.

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

• Дескрипторы для тех ресурсов, которые выделены этому конкретному процессу со стороны ео операционной системы. Мы видели некий пример этого —
  файловые дескрипторы — в Главе 4, Применение оператора with в потоках.

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

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

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

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

Множественность процессов

Многозадачность в информатике является распространённым понятием. При многозадачности некая операционная система просто переключается между
различными процессами на высокой скорости создавая видимость что эти процессы исполняются одновременно, даже несмотря на то, что обычно имеет
место исполнение только одного процесса в единственном ЦПУ (CPU,
central processing unit) в определённый момент времени. В противоположность этому,
метод множества процессов применяет более одного ЦПУ для исполнения какой- то задачи.

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

Эта взаимосвязь показана на следующей схеме:

Мы уже видели в Главе 3, Работа с потоками в Python что многопоточность разделяет нечто
аналогично определению многопроцессности. Многопоточность означает, что используется только один процессор, а сама система переключается между
задачами в пределах этого процессора (что также именуется разделением времени,
квантованием времени — time slicing), в то время как многопроцессность как правило выражается в реальном совместном/ параллельном исполнении множества процессов
с применением множества процессоров.

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

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

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

• Безопасность при крушениях: Поскольку процессы не зависят друг от друга как в терминах
  вычислительных процедур, так и в отношении ввода/ выода, отказ одного из процессов не оказывает воздействия на исполнение другого в программе со
  множеством процессов, при должной обработке. Это подразумевает, что программисты могут быть в состоянии порождать большое число процессов (которые
  всё ещё способна обрабатывать их система) и получаемые шансы крушения всего приложения целиком при этом не растут.

Сказав всё это, стоит также сказать и о недостатках применения множества процессов, которые следует учитывать и которые перечислены далее:

• Требуется множество процессоров: И снова, многопроцессность требует наличия у операционной
  системы более одного ЦПУ. Даже хотя хотя множество процессоров достаточно распространено в вычислительных системах в наши дни, если у вас нет в
  наличии более одного, тогда данная реализация множества процессов будет невозможной.

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

Вводный пример на Python

Для иллюстрации примера запуска множества процессов в операционной системе давайте рассмотрим быстрый пример на Python. Давайте
остановимся на своём файле Chapter06/example1.py, отображаемом ниже:

# Chapter06/example1.py

from multiprocessing import Process
import time


def count_down(name, delay):
    print('Process %s starting...' % name)

    counter = 5

    while counter:
        time.sleep(delay)
        print('Process %s counting down: %i...' % (name, counter))
        counter -= 1

    print('Process %s exiting...' % name)


if __name__ == '__main__':
    process1 = Process(target=count_down, args=('A', 0.5))
    process2 = Process(target=count_down, args=('B', 0.5))

    process1.start()
    process2.start()

    process1.join()
    process2.join()

    print('Done.')
 	   

В этом файле мы намерены вернуться обратно к своему примеру обратного отсчёта, который мы уже рассматривали в
Главе 3, Работа с потоками в Python, когда мы рассматривали понятие потоков. Наша функция
count_down() получала некую строку в качестве идентификатора процесса и какой- то диапазон задержки.
Затем она выполняла обратный отсчёт от 5 до 1, засыпая между итерациями на то число секунд, которое было определено в её параметре
delay. Данная функция также выводила на печать при каждой итерации некое сообщение с идентификатором
соответствующего процесс.

Как мы уже говорили в Главе 3, Работа с потоками в Python, основным моментом, демонстрируемым данным
примером является демонстрация природы одновременности исполнения отдельных задач в одно и то же самое время. причём на этот раз проходя
отличными процессами с применением класса Process из модуля multiprocessing.
В своей основной программе мы инициализируем одновременно два процесса чтобы реализовать два одновременных отдельных обратных отсчёта на основе времени.

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

> python example1.py
Process A starting...
Process B starting...
Process B counting down: 5...
Process A counting down: 5...
Process B counting down: 4...
Process A counting down: 4...
Process B counting down: 3...
Process A counting down: 3...
Process B counting down: 2...
Process A counting down: 2...
Process A counting down: 1...
Process B counting down: 1...
Process A exiting...
		

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

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

Обзор модуля multiprocessing

Модуль multiprocessing является одной из самых распространённых реализаций многопроцессного программирования в
Python. Он предлагает методы для порождения процессов и взаимодействия с ними при помощи API аналогичного API модуля
threading (как мы обнаружили уже это с методами start() и
join() в своём предыдущем образце). Согласно его документации на вебсайте, данный метод допускает как локальную, так
и удалённую совместные обработки и действенно избегает global interpreter lock
(GIL) в Python (которая будет обсуждаться более подробно в
Главе 15, Глобальная блокировка интерпретатора) применяя субпроцессы вместо потоков.

В модуле multiprocessing процессы обычно порождаются в классе Process
и управляются им. Каждый объект Process представляет некое действие, которое исполняет какой- то отдельный
процесс. Для удобства объект класса Process эквивалентен методам и API, которые можно отыскать в соответствующем
классе threading.Thread.

В частности, применяя объектно- ориентированный подход программирования, класс Process из
multiprocessing предоставляет следующие ресурсы:

• run(): Данный метод исполняется при инициализации и запуске нового процесса.

• start(): Этод метод запускается и инициализируется вызывая объект Process
  посредством запроса соответствующего метода run().

• join(): Данный метод ожидает завершения данного вызываемого объекта Process
  прежде чем продолжить исполнение оставшейся части программы.

• isAlive(): Метод возвращает Булево значение, указывающий исполняется ли в настоящий момент данный
  объект вызова Process.

• name: Этот атрибут содержит собственно название данного объекта вызова
  Process.

• pid: Данный атрибут содержит идентификатор процесса вызываемого объекта
  Process.

• terminate(): Метод прекращает исполнение данного объекта вызова
  Process.

Как вы могли видеть в предыдущем примере, при инициализации некоего объекта Process мы можем
передать параметры в какую- то функцию и исполнить её в отдельном процессе, определив саму target (для такой
целевой функции) и параметры args (в качестве аргументов целевой функции). Отметим также, что можно переопределить
установленный по умолчанию конструктор Process() и реализовать свою собственную функцию
run().

Поскольку он является основным игроком в модуле multiprocessing и в совместной обработке Python в целом,
мы рассмотрим вначале класс Process в своём следующем разделе снова.

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

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

Данная задача решается обсуждаемым классом Pool: имеющиеся методы Pool.map()
и Pool.apply() следуют соглашениям традиционных методов Python map()
и apply(), гарантируя, что все возвращаемые значения упорядочиваются в точности в том порядке, как они
поступают на вход. Тем не менее, эти методы блокируют свою основную программу до тех пор, пока процесс не завершит обработку. Вследствие этого,
класс Pool также имеет функции map_async() и
apply_async() для лучшего обслуживания одновременной обработки и параллелизма.

Определение значения текущего процесса, ожидание и завершение процессов

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

Определение значения текущего процесса

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

Однако нет необходимости для каждого объекта Process иметь некий параметр
name (с каким- то значением по умолчанию), которое можно изменять. Процесс именования является наилучшим способом
оставлять на глазу исполняемые процессы нежели передавать некий идентификатор в свою целевую функцию саму по себе (как мы это делали ранее), в
особенности в приложениях с различными типами процессов, исполняемыми в одно и то же время. Одной из мощных функций, предоставляемых модулем
multiprocessing является его метод current_process(), который вернёт
тот объект Process, который в настоящий момент исполняется в любой точке программы. Это иной способ
эффективно и без усилий отслеживать запущенные процессы.

Давайте рассмотрим это более подробно при помощи некоего примера. Перейдите к файлу Chapter06/example2.py,
который показан в следующем коде:

# Chapter06/example2.py

from multiprocessing import Process, current_process
import time


def f1():
    pname = current_process().name
    print('Starting process %s...' % pname)
    time.sleep(2)
    print('Exiting process %s...' % pname)

def f2():
    pname = current_process().name
    print('Starting process %s...' % pname)
    time.sleep(4)
    print('Exiting process %s...' % pname)


if __name__ == '__main__':
    p1 = Process(name='Worker 1', target=f1)
    p2 = Process(name='Worker 2', target=f2)
    p3 = Process(target=f1)

    p1.start()
    p2.start()
    p3.start()

    p1.join()
    p2.join()
    p3.join()
 	   

В этом примере у нас имеются две функции пустышки, f1() и f2(),
каждая из которых выводит на печать название того процесса, которые исполнял данную функцию до и после сна в течении заданного промежутка времени.
В нашей основной программе мы выполнили инициализацию трёх отдельных процессов. Первые два мы озаглавили Worker 1
и Worker 2, а самый последний мы целенаправленно оставили пустым, чтобы предоставить ему устанавливаемое по
умолчанию название (то есть, 'Process-3'). После запуска данного сценария вы должны получить вывод аналогичный
такому:

> python example2.py
Starting process Worker 1...
Starting process Worker 2...
Starting process Process-3...
Exiting process Worker 1...
Exiting process Process-3...
Exiting process Worker 2...
		

Мы можем обнаружить что наш current_process() успешно помог нам выполнить доступ к верному процессу,
который исполнил все функции и наш третий процесс, которому было назначено по умолчанию соответствующее название
Process-3. Другой способ отслеживать все запущенные в вашей программе процессы это просматривать соответствующие
индивидуальные идентификаторы процессов при помощи модуля os. Давайте рассмотрим некий видоизменённый пример
из файла Chapter06/example3.py, как это показано в следующем коде:

# Chapter06/example3.py

from multiprocessing import Process, current_process
import time
import os


def print_info(title):
    print(title)

    if hasattr(os, 'getppid'):
        print('Parent process ID: %s.' % str(os.getppid()))

    print('Current Process ID: %s.\n' % str(os.getpid()))

def f():
    print_info('Function f')

    pname = current_process().name
    print('Starting process %s...' % pname)
    time.sleep(1)
    print('Exiting process %s...' % pname)


if __name__ == '__main__':
    print_info('Main program')

    p = Process(target=f)
    p.start()
    p.join()

    print('Done.')
 	   

Наше особое внимание для этого примера это функция print_info(), которая применяет функции
os.getpid() и os.getppid() для идентификации данного текущего процесса
с помощью его идентификатора процесса. В частности, os.getpid() возвращает сам идентификатор процесса, а
os.getppid() (который доступен только в системах Unix) возвращает значение идентификатора его
родительского процесса. Ниже мой вывод после запуска данного сценария:

> python example3.py
Main program
Parent process ID: 14806.
Current Process ID: 29010.

Function f
Parent process ID: 29010.
Current Process ID: 29012.

Starting process Process-1...
Exiting process Process-1...
Done.
		

Значение идентификатора процесса может меняться от системы к системе, однако их относительное взаимодействие должно оставаться тем же самым.
В частности, в моём выводе мы можем видеть, что в то время как идентификатором для основной программы был 29010,
идентификатором его родительского процесса было значение 14806. Воспользовавшись
Activity Monitor я выполнил проверку иным способом и подключил его к своему Терминалу
и профилю Bash, что имеет смысл сделать, так как я запустил этот сценарий Python из своего Терминала. На приводимом ниже снимке экрана вы можете видеть
отображаемые результаты:

Помимо своей основной программы мы можем также вызвать print_info() внутри своей функции
f(), у которой идентификатором процесса было значение 29012.
Мы также можем обнаружитьЮ что тем процессом, который запустил исполнение нашей функции f()
на самом деле является наш основной процесс, идентификатором которого являлось значение 29010.

Ожидание процесса

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

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

Такие процессы именуются процессами демонов. Класс
Process также предоставляет некий простой параметр для определения того будет ли некий процесс являться
демоном посредством соответствующего атрибута daemon, который принимает Булево значение. Значением по
умолчанию для такого атрибута daemon является False, следовательно
установка его в значение True превратит такой процесс в некоего демона. Давайте рассмотрим это подробнее,
воспользовавшись примером из файла Chapter06/example4.py, который показан в следующем коде:

# Chapter06/example4.py

from multiprocessing import Process, current_process
import time


def f1():
    p = current_process()
    print('Starting process %s, ID %s...' % (p.name, p.pid))
    time.sleep(4)
    print('Exiting process %s, ID %s...' % (p.name, p.pid))

def f2():
    p = current_process()
    print('Starting process %s, ID %s...' % (p.name, p.pid))
    time.sleep(2)
    print('Exiting process %s, ID %s...' % (p.name, p.pid))


if __name__ == '__main__':
    p1 = Process(name='Worker 1', target=f1)
    p1.daemon = True
    p2 = Process(name='Worker 2', target=f2)

    p1.start()
    time.sleep(1)
    p2.start()
 	   

В этом примере у нас имеется некая функция с длительным временем жизни (представленная f1(), у которой период
сна составляет 4 секунды) и более быстрая функция (которая представляется f2()
с периодом засыпания всего на 2 секунды). У нас таже имеются два отдельных процесса, которые перечисляются
следующим списком:

• Процесс p1, который является процессом демона, который назначен для исполнения
  f1().

• Процесс p2, который является процессом демона, который назначен для исполнения
  f2().

В своей основной программе мы запускаем оба процесса без вызова соответствующего метода join() в любой из них
в самом конце этой программы. Так как процесс p1 обладает длительным временем жизни, он скорее всего не завершит
своего исполнения прежде чем завершится p2 (который является более быстрым процессом из этих двух). Мы также
знаем, что p1 является процессом демона, следовательно наша программа должна выполнить выход до того как
завершит исполнение. После запуска данного сценария Python ваш вывод должен быть похож на такой:

> python example4.py
Starting process Worker 1, ID 33784...
Starting process Worker 2, ID 33788...
Exiting process Worker 2, ID 33788...
		

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

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

Такое комбинирование процесса демона и соответствующего метода join() из модуля
multiprocessing может помочь нам реализовать такое решение, в частности, учитывая что пока наш метод
join() блокирует на неопределённое время исполнение нашей программы (или, по крайней мере, пока не завершится
соответствующая задача), также имеется возможность передать некий параметр таймаута для определения необходимого числа секунд на выполнение ожидания
перед выходом. Давайте рассмотрим некую изменённую версию своего предыдущего примера в Chapter06/example5.py.
Обладая теми же самыми функциями f1() и f2() в своём следующем примере,
мы меняем тот способ, при помощи которого мы обрабатываем свой процесс демона в основной программе:

# Chapter06/example5.py

if __name__ == '__main__':
    p1 = Process(name='Worker 1', target=f1)
    p1.daemon = True
    p2 = Process(name='Worker 2', target=f2)

    p1.start()
    time.sleep(1)
    p2.start()

    p1.join(1)
    print('Whether Worker 1 is still alive:', p1.is_alive())
    p2.join()
 	   

Вместо прекращения без ожидания своего процесса демона, в данном примере мы вызываем метод join() для
обоих процессов: мы даём одну секунду для p1 на завершение, в то время как мы блокируем свою основную программу
пока не завершится p2. Если p1 не завершит исполнение после этой одной секунды,
наша основная программа продолжит исполнять то что в ней осталось, в то время как мы видим, что p1 — или
Worker 1 — всё ещё жива. После исполнения данного сценария Python ваш вывод будет похож на такой:

> python example5.py
Starting process Worker 1, ID 36027...
Starting process Worker 2, ID 36030...
Whether Worker 1 is still alive: True
Exiting process Worker 2, ID 36030...
		

Мы видим, что p1 на самом деле всё ещё жив, в то время как основная программа проследовала далее после
ожидания одной секунды.

Прекращение процесса

Метод terminate() из обсуждаемого класса multiprocessing.Process
предлагает некий способ быстрого прекращения процесса. При вызове данного метода не будут исполняться обработчики выхода, завершающие положения или
аналогичные ресурсы, предписанные в соответствующем классе Process или некотором перекрывающем классе.
Однако процессы потомки не будут прекращены. Такие процессы именуются сиротскими процессами
(orphaned).

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

Один из моментов, который следует отметить при применении метода terminate(), состоит в том, что даже
несмотря на то, что соответствующий объект Process действенно уничтожается после вызова данного метода, важно
что вы вы также вызываете в этом методе также и join(). Поскольку состояние
alive объекта Process порой не обновляется немедленно после соответствующего
метода terminate(), данная практика даёт своей системе в фоновом режиме возможность реализовать обновление
самого себя в ответ на прекращение своих процессов.

Взаимодействие между процессами

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

В этом разделе мы изучим применение очередей, в частности класса Queue из обсуждаемого модуля
multiprocessing. Имеющаяся реализация класса Queue в действительности
сохраняет и поток, и процесс, причём мы уже видели применение очередей в Главе 3,
Работа с потоками в Python. Посредством объекта Queue могут передаваться любые пригодные к маринованию
объекты Python; в данном разделе мы будем применять очереди для передачи сообщений взад и вперёд между процессами.

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

Передача сообщения для отдельного исполнителя

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

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

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

• get(): Этот метод возвращает следующий элемент в вызываемом объекте
  Queue

• put(): Данные метод добавляет передаваемый ему параметр в качестве некоторого дополнительного
  элемента в сам вызываемый объект Queue

Давайте рассмотрим образец сценария, показывающего пример использования некоторой очереди в Python. Переместитесь к своему файлу
Chapter06/example6.py и откройте его, что показано в приводимом далее коде:

# Chapter06/example6.py

import multiprocessing

class MyWorker():
    def __init__(self, x):
        self.x = x

    def process(self):
        pname = multiprocessing.current_process().name
        print('Starting process %s for number %i...' % (pname, self.x))

def work(q):
    worker = q.get()
    worker.process()

if __name__ == '__main__':
    my_queue = multiprocessing.Queue()

    p = multiprocessing.Process(target=work, args=(my_queue,))
    p.start()

    my_queue.put(MyWorker(10))

    my_queue.close()
    my_queue.join_thread()
    p.join()

    print('Done.')
 	   

В этом сценарии у нас имеется некий класс MyWorker, который получает в некотором числе
x параметр и выполняет некое вычисление на его основе (в данном случае это всего лишь вывод на печать
этого числа). В своей основной функции мы инициализируем некий объект Queue из модуля
multiprocessing и добавляем какой-то объект MyWorker со значением
числа 10в нём. У нас также имеется соответствующая функция work(),
которая при её вызове получит самый первый элемент из данной очереди и обработает его. Наконец, у нас есть процесс, чья задача состоит в
вызове такой функции work().

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

> python example6.py
Starting process Process-1 for number 10...
Done.
		

Обмен сообщениями межу несколькими исполнителями

Как уже упоминалось ранее, наша цель состоит в обладании структурой, в которой существует несколько процессов постоянно запускающих исполнителей
из некоторой очереди и, когда некий процесс завершает выполнение одного исполнителя, тогда он подхватывает нового. Для этого мы будем применять
некий подкласс Queue с названием JoinableQueue, который будет
предоставлять свои дополнительные методы task_done() и join(), как
это определено в данном списке:

• task_done(): Данный метод сообщает нашей программе что вызываемый объект
  JoinableQueue завершён.

• join(): Этот метод выполняет блокирование до тех пор, пока все элементы в его вызываемом
  объекте JoinableQueue не будут обработаны.

Теперь основная цель здесь, опять же, состоит в наличии некоего объекта JoinableQueue, содержащего
все те задачи которые должны быть исполнены — мы именуем это своей очередью задач — а также неким числом процессов. До тех пор пока в нашей
очереди задач имеются элементы (сообщения), имеющиеся процессы будут в свою очередь на исполнение такие элементы. У нас также будет иметься
некий объект Queue для сохранения всех результатов возвращаемых из исполняемых процессов — мы будем
называть её очередью результатов.

Перейдём к своему файлу Chapter06/example7.py и переключимся на рассмотрение класса
Consumer и класса Task, которые отображены в следующем коде:

# Chapter06/example7.py

from math import sqrt
import multiprocessing

class Consumer(multiprocessing.Process):

    def __init__(self, task_queue, result_queue):
        multiprocessing.Process.__init__(self)
        self.task_queue = task_queue
        self.result_queue = result_queue

    def run(self):
        pname = self.name

        while not self.task_queue.empty():

            temp_task = self.task_queue.get()

            print('%s processing task: %s' % (pname, temp_task))

            answer = temp_task.process()
            self.task_queue.task_done()
            self.result_queue.put(answer)

class Task():
    def __init__(self, x):
        self.x = x

    def process(self):
        if self.x < 2:
            return '%i is not a prime number.' % self.x

        if self.x == 2:
            return '%i is a prime number.' % self.x

        if self.x % 2 == 0:
            return '%i is not a prime number.' % self.x

        limit = int(sqrt(self.x)) + 1
        for i in range(3, limit, 2):
            if self.x % i == 0:
                return '%i is not a prime number.' % self.x

        return '%i is a prime number.' % self.x

    def __str__(self):
        return 'Checking if %i is a prime or not.' % self.x
 	   

Приводимый класс Consumer, который является неким переопределением подкласса имеющегося класса
multiprocessing.Process, составляет логику нашей обработки, которая получает некую очередь задач и
какую- то очередь результатов. Будучи запущенным, каждый объект Consumer получает следующий элемент из
своей очереди задач, исполняет его и наконец вызывает task_done() и помещает возвращаемые результаты в
его очередь результатов. Каждый элемент в такой очереди задач является в свою очередь представителем соответствующего класса
Task, чья основная функциональность состоит в первичной проверке его параметра
x. Так как один экземпляр нашего класса Consumer взаимодействует с
одним экземпляром соответствующего класса Task, он также выводит на печать некое вспомогательное
сообщение для нас чтобы легче отслеживать какой из потребителей какую из задач исполняет.

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

# Chapter06/example7.py

if __name__ == '__main__':
    tasks = multiprocessing.JoinableQueue()
    results = multiprocessing.Queue()

    # spawning consumers with respect to the
    # number cores available in the system
    n_consumers = multiprocessing.cpu_count()
    print('Spawning %i consumers...' % n_consumers)
    consumers = [Consumer(tasks, results) for i in range(n_consumers)]
    for consumer in consumers:
        consumer.start()

    # enqueueing jobs
    my_input = [2, 36, 101, 193, 323, 513, 1327, 100000, 9999999, 433785907]
    for item in my_input:
        tasks.put(Task(item))

    tasks.join()

    for i in range(len(my_input)):
        temp_result = results.get()
        print('Result:', temp_result)

    print('Done.')
 	   

Как мы уже сказали ранее, мы создали в своей основной программе некую очередь задач и очередь результатов. Мы также создали какой-то перечень
объектов Consumer и запустили их все; общее число созданных процессов соответствует общему числу ЦПУ,
доступных в нашей системе. Далее, из некоего списка входных данных, которые требуют тяжёлых вычислений в нашем классе
Task, мы инициализируем некий объект Task для каждого входного данного и
помещаем их все в свою очередь задач. На этот момент наши процессы — наши объекты Consumer —
начнут исполнять эти задачи.

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

> python example7.py
Spawning 4 consumers...
Consumer-3 processing task: Checking if 2 is a prime or not.
Consumer-2 processing task: Checking if 36 is a prime or not.
Consumer-3 processing task: Checking if 101 is a prime or not.
Consumer-2 processing task: Checking if 193 is a prime or not.
Consumer-3 processing task: Checking if 323 is a prime or not.
Consumer-2 processing task: Checking if 1327 is a prime or not.
Consumer-3 processing task: Checking if 100000 is a prime or not.
Consumer-4 processing task: Checking if 513 is a prime or not.
Consumer-3 processing task: Checking if 9999999 is a prime or not.
Consumer-2 processing task: Checking if 433785907 is a prime or not.
Result: 2 is a prime number.
Result: 36 is not a prime number.
Result: 193 is a prime number.
Result: 101 is a prime number.
Result: 323 is not a prime number.
Result: 1327 is a prime number.
Result: 100000 is not a prime number.
Result: 9999999 is not a prime number.
Result: 513 is not a prime number.
Result: 433785907 is a prime number.
Done.
		

Всё кажется работающим, но если мы приглядимся внимательнее к тем сообщениям, которые наши процессы вывели на печать, мы заметим, что
большая часть задач исполнялась либо Consumer-2, либо Consumer-3, а
Consumer-4 выполнил только одну задачу, в то время как Consumer-1
отказал вообще в исполнении. Что здесь происходит?

По существу, когда один из наших потребителей — допустим Consumer-3 — завершил исполнение некоторой
задачи, он пытается отыскать другую задачу для исполнения сразу после этого. В большинстве случаев он получит приоритет перед остальными потребителями
так как он уже исполнялся нашей основной программой. Поэтому в то время как Consumer-2 и
Consumer-3 постоянно завершали исполнение своих задач и прихватывали на исполнение прочие задачи,
Consumer-4 смог «выдавить» из себя это всего один раз, в то время как
Consumer-1 отказался это делать вовсе.

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

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

Для реализации этой техники нам необходимо добавить в своё значение tasks в нашей основной программе
особых объектов, по одному на потребителя. Кроме того, в нашем классе Consumer также требуется реализация
особой логики для обработки таких специальных объектов. Давайте рассмотрим свой файл example8.py
(некую модификацию версии нашего предыдущего примера, содержащую соответствующую реализацию техники ядовитой пилюли), в частности в нашем классе
Consumer и в нашей основной программе, как это отображено в следующем коде:

# Chapter06/example8.py

class Consumer(multiprocessing.Process):

    def __init__(self, task_queue, result_queue):
        multiprocessing.Process.__init__(self)
        self.task_queue = task_queue
        self.result_queue = result_queue

    def run(self):
        pname = self.name

        while True:
            temp_task = self.task_queue.get()

            if temp_task is None:
                print('Exiting %s...' % pname)
                self.task_queue.task_done()
                break

            print('%s processing task: %s' % (pname, temp_task))

            answer = temp_task.process()
            self.task_queue.task_done()
            self.result_queue.put(answer)

class Task():
    def __init__(self, x):
        self.x = x

    def process(self):
        if self.x < 2:
            return '%i is not a prime number.' % self.x

        if self.x == 2:
            return '%i is a prime number.' % self.x

        if self.x % 2 == 0:
            return '%i is not a prime number.' % self.x

        limit = int(sqrt(self.x)) + 1
        for i in range(3, limit, 2):
            if self.x % i == 0:
                return '%i is not a prime number.' % self.x

        return '%i is a prime number.' % self.x

    def __str__(self):
        return 'Checking if %i is a prime or not.' % self.x

if __name__ == '__main__':

    tasks = multiprocessing.JoinableQueue()
    results = multiprocessing.Queue()

    # spawning consumers with respect to the
    # number cores available in the system
    n_consumers = multiprocessing.cpu_count()
    print('Spawning %i consumers...' % n_consumers)
    consumers = [Consumer(tasks, results) for i in range(n_consumers)]
    for consumer in consumers:
        consumer.start()

    # enqueueing jobs
    my_input = [2, 36, 101, 193, 323, 513, 1327, 100000, 9999999, 433785907]
    for item in my_input:
        tasks.put(Task(item))

    for i in range(n_consumers):
        tasks.put(None)

    tasks.join()

    for i in range(len(my_input)):
        temp_result = results.get()
        print('Result:', temp_result)

    print('Done.')
 	   

Наш класс Task остаётся тем же самым, что и в нашем предыдущем примере. Мы можем обнаружить что
:нашей ядовитой пилюлей является значение None: в своей основной программе мы добавляем в
None значения числа, равного общему числу потребителей, которых мы породили в своей очереди задач;
в своём классе Consumer, если текущая подлежащая исполнению задача содержит значение
None, тогда объект данного класса будет выводить на печать некое сообщение с указанием на ядовитую пилюлю,
вызовет task_done() и завершит исполнение.

Запустите этот сценарий, ваш вывод должен походить на такой:

> python example8.py
Spawning 4 consumers...
Consumer-1 processing task: Checking if 2 is a prime or not.
Consumer-2 processing task: Checking if 36 is a prime or not.
Consumer-3 processing task: Checking if 101 is a prime or not.
Consumer-4 processing task: Checking if 193 is a prime or not.
Consumer-1 processing task: Checking if 323 is a prime or not.
Consumer-2 processing task: Checking if 513 is a prime or not.
Consumer-3 processing task: Checking if 1327 is a prime or not.
Consumer-1 processing task: Checking if 100000 is a prime or not.
Consumer-2 processing task: Checking if 9999999 is a prime or not.
Consumer-3 processing task: Checking if 433785907 is a prime or not.
Exiting Consumer-1...
Exiting Consumer-2...
Exiting Consumer-4...
Exiting Consumer-3...
Result: 2 is a prime number.
Result: 36 is not a prime number.
Result: 323 is not a prime number.
Result: 101 is a prime number.
Result: 513 is not a prime number.
Result: 1327 is a prime number.
Result: 100000 is not a prime number.
Result: 9999999 is not a prime number.
Result: 193 is a prime number.
Result: 433785907 is a prime number.
Done.
		

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

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

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

В своей следующей главе мы обсудим более передовые функции Python — снижение числа операций — а также как это поддерживается в многопроцессном
программировании.

• Что такое процесс? В чём состоят ключевые отличия между процессами и потоками?

• Что такое многопроцессность? В чём состоят ключевые отличия между многопроцессностью и многопоточностью?

• Какие варианты API предоставляются модулем multiprocessing?

• В чём состоят ключевые отличия между классом Process и классом Pool
  из модуля multiprocessing?

• Какие имеются варианты для определения значения текущего процесса в какой- то программе Python?

• Что такое процесс демона? В ч1м состоит их цель в терминах ожидания процессов в некоторой программе со множеством процессов?

• Как вы завершаете процесс? Почему порой приемлемо прекращать процессы?

• Каковы способы снабжения межпроцессного взаимодействия в Python?

Дальнейшее чтение

Для получения дополнительных сведений вы можете воспользоваться следующими ссылками:

• Наш перевод 2 издания Python
  Parallel Programming Cookbook, Джанкарло Законне, Packt Publishing Ltd, сентябрь 2019

• Learning Concurrency in Python:
  Build highly efficient, robust, and concurrent applications, Элиот Форбс, Packt Publishing Ltd, 2017

• Python Module of The Week. «Communication Between
  Processes», содержит функции, которые вы можете применять для определения текущего процесса.

50.1.069-2009 «Менеджмент риска. Рекомендации по внедрению. Часть 2. Определение процесса менеджмента риска»

Менеджмент риска

РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ

Часть 2

Определение процесса менеджмента риска

Цели и принципы
стандартизации в Российской Федерации установлены Федеральным законом от 27
декабря 2002 г. № 184-ФЗ «О техническом
регулировании», а правила применения национальных стандартов Российской
Федерации — ГОСТ Р
1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о рекомендациях

1 РАЗРАБОТАНЫ Автономной некоммерческой
организацией «Научно-исследовательский центр контроля и диагностики технических
систем» (АНО «НИЦ КД»)

2 ВНЕСЕНЫ
Техническим комитетом по стандартизации ТК 10 «Перспективные производственные
технологии, менеджмент и оценка рисков»

3 УТВЕРЖДЕНЫ И
ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому
регулированию и метрологии от 15 декабря 2009 г. № 1259-ст

4 ВВЕДЕНЫ ВПЕРВЫЕ

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

СОДЕРЖАНИЕ

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

Настоящие рекомендации
содержат описание процесса менеджмента риска.

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

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

— миссию, стратегию,
политику и цели организации в области менеджмента риска;

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

— основные процессы и
процессы менеджмента организации;

— установленные и
используемые методы анализа и оценки риска;

— законодательные
требования;

— условия эксплуатации
продукции.

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

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

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

Дата введения — 2010-12-01

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

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

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

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

ГОСТ Р 51898-2002
Аспекты безопасности. Правила включения в стандарты

ГОСТ Р ИСО 15489-1-2007
Система стандартов по информации, библиотечному и издательскому делу.
Управление документами. Общие требования

В
настоящих рекомендациях применены термины и определения по ГОСТ Р 51898, ГОСТ Р 51897,
Р
50.1.068, а также следующие термины с соответствующими определениями:

3.1 риск (risk):
Сочетание вероятности события и его последствий.

Примечания

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

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

3 Применительно к безопасности см. ГОСТ
Р 51898.

[ГОСТ Р 51897-2002, ст.
3.1.1]

3.2 менеджмент риска (risk management): Скоординированные
действия по руководству и управлению организацией в отношении риска, которые
направлены на реализацию потенциальных возможностей организации и снижение
негативных последствий опасных событий.

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

[Адаптировано из ГОСТ Р
51897-2002, ст. 3.1.7]

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

Примечания

1 Входами к процессу обычно являются выходы
других процессов.

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

3 Процесс, в котором подтверждение
соответствия конечной продукции затруднено или экономически нецелесообразно,
часто относят к «специальному процессу».

[ГОСТ Р ИСО
9000-2008, ст. 3.4.1]

3.4 процесс
менеджмента риска (risk management process):
Систематические действия по управлению политикой, процедурами и методами,
направленными на обмен информацией,
установление целей применения, идентификацию, оценку, обработку, мониторинг и
анализ риска (3.1).

3.5 оценка
риска (risk assessment):
Общий процесс идентификации (3.7), анализа риска (3.6) и проведения
сравнительной оценки риска (3.9).

3.6 анализ риска (risk analysis): Систематическое
использование информации для определения источников и количественной оценки
риска.

Примечания

1 Анализ риска обеспечивает основу для
проведения оценки риска и принятия решений об обработке риска.

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

[ГОСТ Р 51897-2002, ст.
3.3.2]

3.7 идентификация риска
(risk identification):
Процесс определения риска, составления перечня риска и описания каждого из
элементов риска.

[Адаптировано из ГОСТ Р
51897-2002, ст. 3.3.3]

3.8 количественная
оценка риска (risk estimation):
Процесс присвоения значений вероятности и последствий риска.

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

[Адаптировано из ГОСТ Р
51897-2002, ст. 3.3.5]

3.9 сравнительная оценка риска (risk evaluation): Процесс сравнения
количественной оценки риска с установленными критериями риска для определения
значимости риска.

Примечания

1 Сравнительная оценка риска может быть использована
для содействия решениям по принятию или обработке риска.

2 Применительно к безопасности см. ГОСТ
Р 51898.

[Адаптировано из ГОСТ Р 51897-2002,
ст. 3.3.6].Р
50.1.069-2009

3.10 обработка риска (risk treatment): Процесс выбора и
осуществления мер по модификации или сокращению риска (3.1).

Примечания

1 Термин «обработка риска» иногда используют
для обозначения самих мер.

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

[Адаптировано из ГОСТ Р 51897-2002,
ст. 3.4.1]

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

3.12 система (system): Совокупность
взаимосвязанных и взаимодействующих элементов

[ГОСТ Р ИСО
9000, ст. 3.2.1]

4.1 Краткий обзор процесса
менеджмента риска

Основные элементы
процесса менеджмента риска приведены на рисунке 1.

К основным элементам
процесса менеджмента риска относят следующие:

а) обмен информацией и
консультации:

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

б) установление целей:

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

в) идентификация риска:

Рисунок 1 — Общая схема процесса менеджмента риска

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

г) анализ риска:

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

д) сравнительная оценка
риска:

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

е) общая оценка риска:

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

ж) обработка риска:

Следует провести идентификацию
набора вариантов обработки риска, оценку этих вариантов, а также подготовку и
выполнение планов обработки риска.

з) мониторинг и анализ:

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

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

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

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

Подробное описание
элементов процесса менеджмента риска приведено в 4.2 — 4.8 и в приложении
А.

4.2 Обмен информацией и консультации

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

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

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

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

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

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

4.3 Установление целей и
области применения

4.3.1 Общие положения

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

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

4.3.2 Установление
внешней области применения

Этот этап определяет
внешние условия, в которых работает организация.

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

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

— сильные и слабые
стороны, возможности и угрозы организации;

— внешние причастные
стороны;

— ключевых деловых
партнеров.

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

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

4.3.3 Установление
внутренней области применения

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

— культура;

— внутренние причастные
стороны;

— структура организации;

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

— цели и задачи, а также
стратегии, необходимые для их достижения.

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

Установление внутренней
области применения важно в силу того, что:

— деятельность в области
менеджмента риска осуществляется в рамках общих целей и задач организации;

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

— политика и цели
организации, а также ее стратегические и иные интересы являются основой для
определения политики в области менеджмента риска организации;

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

4.3.4 Установление
целей в области менеджмента риска

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

Установление области и
границ применения менеджмента риска включает в себя:

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

— определение характера
решений, которые должны быть выполнены;

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

— идентификацию всех сфер
и/или объектов, исследование которых необходимо, а также исследование их
области применения, задач и требуемых ресурсов;

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

Могут также быть
обсуждены особые вопросы, которые охватывают:

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

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

4.3.5 Разработка
критериев риска

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

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

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

4.3.6 Определение
структуры остальной части процесса

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

4.4 Идентификация риска

4.4.1 Общие положения

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

4.4.2 Выявление
опасных событий

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

4.4.3 Выявление причин
появления события

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

4.4.4 Инструменты и
методы идентификации риска

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

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

4.5 Анализ риска

4.5.1 Общие положения

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

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

4.5.2 Оценка
существующих средств управления

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

4.5.3
Последствия и вероятность

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

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

— данные прошлых лет;

— данные практического
опыта и экспериментов;

— литературные данные;

— анализ рыночной
конъюнктуры;

— результаты общественных
консультаций;

— опытные образцы и
прототипы;

— экономические,
инжиниринговые или другие модели;

— мнения специалистов и
экспертные оценки.

Методы включают в себя:

— структурированные
интервью с экспертами в области исследований;

— привлечение
междисциплинарных групп экспертов;

— индивидуальные оценки с
использованием анкетных опросов;

— использование моделей и
компьютерного моделирования.

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

Должны быть точно
определены все предположения, сделанные при анализе риска.

4.5.4 Типы анализа
риска

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

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

Ниже приведено подробное
описание различных типов анализа риска.

а) Качественный анализ

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

Качественный анализ может
быть использован:

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

— в ситуации, когда этот
вид анализа является наиболее подходящим для принятия решений;

— если доступные числовые
данные или ресурсы не позволяют провести количественный анализ.

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

б) Псевдоколичественный
анализ

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

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

а) Количественный анализ

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

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

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

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

4.5.5
Анализ чувствительности

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

4.6 Сравнительная
оценка риска

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

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

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

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

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

4.7 Обработка риска

4.7.1 Общие положения

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

4.7.2 Идентификация
вариантов обработки риска с положительными результатами

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

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

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

— Изменение вероятности
появления события, направленное на увеличение вероятности позитивных
результатов.

— Изменение последствий
события, направленное на увеличение прибыли.

— Разделение преимуществ.

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

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

— Сохранение остаточных
преимуществ.

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

4.7.3 Идентификация вариантов обработки риска с отрицательными
результатами

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

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

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

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

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

— Разделение риска.

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

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

— Сохранение риска.

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

4.7.4 Оценка вариантов
обработки риска

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

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

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

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

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

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

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

4.7.5 Подготовка и
выполнение обработки риска

Цель плана обработки
риска состоит в документальном оформлении выбранных вариантов обработки. Планы обработки должны включать в
себя:

— предложенные действия;

— необходимые ресурсы;

— распределение
ответственности, обязанностей и полномочий;

— выбор времени
обработки;

— критерии качества
выполнения работы;

— отчетность и мониторинг
требований.

Планы обработки риска
должны быть объединены с процессами менеджмента
и процессами по бюджетированию организации.

4.8 Мониторинг и
анализ риска

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

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

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

4.9 Записи по процессу
менеджмента риска

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

Записи по таким процессам
являются важным аспектом успешного корпоративного
управления.

Решения относительно
создания и регистрации записей должны учитывать:

— юридические и деловые
потребности в записях;

— стоимость создания,
ведения и хранения записей;

— преимущества
многократного использования информации (см. ГОСТ Р ИСО 15489-1).

Рисунок А. 1 -
Подробное описание процесса менеджмента риска

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

Что такое бизнес-процесс: определение, виды, характеристика

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

Что такое бизнес-процессы компании

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

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

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

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

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

Характеристики бизнес-процессов

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

Основные характеристики обязательны. К ним относятся:

Часто эти элементы объединены в одно, так как из названия операции четко видна цель. Они должны быть конкретными и понятными для участников. Например: название «Заключение договора купли-продажи с клиентом» и аналогичная цель.

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

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

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

Это результат проделанной работы — товар или услуга. На выходе не всегда получается то, что было изначально запланировано. Цель может измениться. 

Дополнительные характеристики не обязательны, поэтому их может не быть в структуре. К ним относятся: 

Классификация бизнес-процессов

Бизнес-процессы классифицируются в зависимости от факторов:

1. 
   По содержанию:

• 
  Основные бизнес-процессы. Это задачи, ориентированные на производство товара или оказания услуги, которые в дальнейшем принесут прибыль. Например: для мебельного завода основной бизнес-процесс — изготовление предметов интерьера.

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

• 
  Вспомогательные процессы. Направлены на поддержание основного процесса. Например: обслуживание и ремонт производственного оборудования на заводе.

• 
  Обеспечивающие процессы. Направлены на поддержание жизнедеятельности исполнителей и возможности производства. Например: финансовое обеспечение, кадровая деятельность.

• 
  Управляющие процессы. Направлены на контроль. Например: работа управляющих менеджеров по планированию и распределению кадров.

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

1. 
   По форме:

• 
  Внешние процессы. Основная работа субъекта на рынке непосредственно с потребителем (ведение переговоров с клиентом, рекламная деятельность и пр.)

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

2. 
   По функции:

• 
  Функциональные процессы. Направлены на выполнение поставленной задачи (изготовление товара, поиск клиентов, продвижение продукции).

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

Описание бизнес-процесса


Описание бизнес-процесса — это описание определения действий, которые должны выполнить сотрудники для достижения поставленной задачи.


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


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


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


Существуют специальные программы нотаций с условными обозначениями, которые понятны пользователям. Бизнес-процесс — это совокупность большого количества специфических действий, которые сложно представить наглядно. Для этого используют программы, такие как  BPMN, IDEF3, UML и EPC, которые преобразуют задачи в удобные схемы и таблицы.


Нужно четко распределить задачи между кадрами, чтобы каждый понимал, чем заняться и какой блок задач закреплен за ним.


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

Управление бизнес-процессами


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

1. 
   Моделирование. 


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

1. 
   Исполнение. 


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

1. 
   Контроль. 


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

1. 
   Улучшение. 


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


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

Заключение


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

Определение процесса Merriam-Webster

процесс

| \ ˈPrä-ˌses

, ˈPrō-, -səs

\

множественные процессы \
ˈPrä- ˌse- səz
, ˈPrō-, — sə-, — sēz

\

2а (1)

: природное явление, отмеченное постепенными изменениями, ведущими к определенному результату.

процесс роста

(2)

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

такие жизненные процессы как дыхание

б

: серия действий или операций, приводящих к завершению

особенно

: непрерывная работа или обработка, особенно при производстве

б

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

4

: выступающая или выступающая часть организма или органической структуры.

костный отросток нервно-клеточный отросток

обработанный; обработка; процессы

переходный глагол

б (1)

: , чтобы вызвать

(2)

: для вручения повестки в

2а

: подлежат специальной обработке или обработке (как в процессе производства или проявления пленки)

б (1)

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

обрабатывать страховые претензии

(2)

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

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

(3)

: подлежать изучению или анализу

компьютеры обрабатывают данные

c

: превратить (волосы) в конус

1

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

2

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

3

: иллюзорных эффектов, обычно возникающих при обработке пленки, или связанных с ними.

процесс

| \ prə-ˈses

\

обработанный; обработка; процессы

Определение и значение процесса | Словарь английского языка Коллинза

Примеры «процесса» в предложении


процесс


Эти примеры были выбраны автоматически и могут содержать конфиденциальный контент.Читать далее…

Это самая сложная часть процесса, но наберитесь терпения.

Times, Sunday Times (2016)

Но мы, несомненно, что-то потеряем в процессе.

Smithsonian Mag (2017)

Ваша мать — серьезная потеря, и на ее обработку уходит много времени.

Солнце (2017)

Этот процесс происходит в мгновение ока.

Times, Sunday Times (2016)

Этот процесс изменений требует действий от всех нас.

Times, Sunday Times (2016)

Их больше беспокоил результат, чем процесс.

Times, Sunday Times (2017)

Это требование соответствия касается технологий, людей и процессов.

Computing (2010)

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

Times, Sunday Times (2017)

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

Times, Sunday Times (2016)

Ваша личная информация будет обработана для выполнения вашего запроса.

Солнце (2012)

Подробнее…

Процесс ухаживания начался не очень хорошо.

Times, Sunday Times (2011)

Было две вещи, которые он знал и обрабатывал, когда готовился нанести удар.

Times, Sunday Times (2016)

Этот процесс просто позволяет людям пройти по спирали вопросов.

Христианство сегодня (2000)

Пищевая промышленность, производство автомобилей и текстиля — все выросло.

Times, Sunday Times (2013)

Процесс отбора также был окутан тайной.

Times, Sunday Times (2009)

Можно внедрить интеллект в системы и процессы, с которыми мы работаем.

Times, Sunday Times (2009)

Однажды он смешивал химикаты, готовые для обработки пленки.

Эйдан Хартли ЗАНЗИБАРСКИЙ СУНДУК: Воспоминания о любви и войне (2003)

Мы видим точно такие же процессы в действии, когда дело касается артериального давления.

Times, Sunday Times (2015)

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

Low, Николай Политика, планирование и государство (1990)

Тогда это был процесс ликвидации.

Times, Sunday Times (2007)

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

Майкл Боултер ИСКЛЮЧЕНИЕ: Эволюция и конец человека (2002)

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

Holford, Patrick The Family Nutrition Workbook (1988)

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

Times, Sunday Times (2014)

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

Форстнер, Хельмут, Балланс, Роберт Конкуренция в глобальной экономике (1990)

Родственники обвиняемых жаловались на судебный процесс.

Times, Sunday Times (2011)

Этот процесс также будет происходить в контексте трех «фаз» революционной войны.

Макиннес, Колин и Шеффилд Г.Д. (ред.) Война в двадцатом веке (1988)

Употребление четырех или более напитков в течение двух часов шокирует иммунную систему.

The Sun (2008)

Когда они смешиваются, начинается процесс химического отверждения.

Chapman, C. & Horsley, M. & Small, E. Technology Basic Facts (1990)

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

Торрингтон, Дерек Управление персоналом: новый подход (1991)

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

Клок, Пол Дж. (Редактор) «Планирование землепользования в сельских районах в развитых странах» (1989)

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

Stanway, Dr Andrew Miracle Micronutrients (1987)

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

Times, Sunday Times (2006)

Определение процесса — обзор

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

Процесс Серендип определяется для достижения бизнес-цели потребителя (или группы потребителей). Организация может иметь более одного определения процесса для обслуживания нескольких целей нескольких потребителей. Во время выполнения процессы запускаются на основе этих определений процессов. Важной характеристикой Serendip является то, что общий и единственный составной экземпляр повторно используется для определения нескольких процессов.Сходства фиксируются с точки зрения многократно используемых единиц поведения в пределах одного экземпляра организации. Это важно для поддержки мультиарендности с одним экземпляром, необходимой для разработки приложений SaaS [47, 89] [47] [89].

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

G_823.1.

Определите новое определение процесса для достижения бизнес-целей каждого потребителя (группы потребителей).

G_823.2.

Для данного определения процесса

a.

Определите единицы поведения, на которые необходимо сослаться.

б.

Определите условия запуска (CoS) для активации экземпляров процесса. Никакие два определения процесса не должны использовать один и тот же CoS.

г.

Определите условия завершения (CoT) для завершения экземпляров процесса.

г.

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

G_823.3.

Обеспечьте правильную формулировку определенного процесса, построив граф процесса с помощью среды выполнения Serendip, как описано в Разделе 5.5.

В сценарии RoSAS существует три типа групп потребителей: серебро, золото и платина. Мы разрабатываем три определения процесса для удовлетворения требований этих трех групп потребителей (G_823.1). Назовем эти три определения pdGold , pdSilv и pdPlat , как показано в листинге 8.6.

Листинг 8.6. Определения процесса.

Следующим шагом является определение поведения, на которое необходимо ссылаться в каждом определении процесса (G_823.2.a). Серебряным участникам требуются только функции буксировки и ремонта, в то время как золотым членам требуются функции буксировки, ремонта и такси как часть помощи на дороге. Кроме того, участникам платинового уровня требуются бесплатные услуги по размещению в подходящем отеле. Эти различия отражены в определениях процессов pdSilv , pdGold и pdPlat , соответственно, в терминах ссылок на единицы поведения.Следовательно, pdSilv относится только к b Жалоба , bTowing и b Ремонт ; pdGold относится к b Жалоба , bБуксир , b Ремонт и bТаксиПредоставление ; и pdPlat относится к b Жалоба , bTowing , b Ремонт , bTaxiПредоставление и bAccommodationProvicing .

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

После определения ссылок на единицы поведения необходимо определить CoS и CoT для каждого определения процесса (G_823.2.b и G_823.2.c). CoS используется механизмом оркестрации для активации нового экземпляра процесса соответствующего типа. Например, если запускается eComplainRcvdSilv , то механизм знает, что необходимо активировать новый экземпляр процесса pdSilv . Это событие запускается договорными правилами в контракте CO_MM путем интерпретации запроса от автомобилиста к ответственному за дело, который содержит идентификатор участника или любую другую форму идентификации. Это означает, что сложность идентификации инициируемого события (а значит, и типа определения) регулируется правилами (Раздел 8.3.1). На уровне процессов процессы выполняются на основе таких событий, как eComplainRcvdSilv . Никакие два определения процесса не могут иметь одно и то же событие, что и CoS , чтобы избежать конфликтов применения. Например, если и pdSilv , и pdGold имеют один и тот же CoS , то механизм не может определить, какое определение использовать для активации экземпляра процесса. CoT указывается с использованием шаблона событий, фиксирующего безопасное состояние, при котором процесс может быть завершен.eExceptionHandled — это CoT для экземпляра процесса pdSilv , который указывает либо комбинацию событий eMMNotifDone, eTTPaid и eGRPaid , либо событие eExceptionHandled должно быть инициировано.

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

Затем ограничения уровня процесса, которые должны быть сохранены, должны быть определены в соответствующих определениях процесса.Подобно ограничениям поведения, ограничения процесса указываются на языке TCTL. Например, ограничение, указанное в процессе pdGold , гласит, что за событием eComplainRcvdGold должно в конечном итоге следовать событие eMMNotif .

Наконец, необходимо обеспечить правильную формулировку определенного процесса (G_823.3), поскольку могут быть проблемные зависимости между задачами определенных единиц поведения. Эти проблемы могут быть обнаружены с помощью проверки корректности на основе цепочки процессов, управляемых событиями (EPC) (Раздел 5.5). Если обнаружена проблемная зависимость , то сначала необходимо ее разрешить. Например, задача tTow указывает свой шаблон перед событием как eTowReqd * eDestinationKnown . Если оба эти события не инициированы какой-либо из упомянутых задач, tTow не будет инициирован. Тем не менее, событие eDestinationKnown — это , а не , инициированное в блоке поведения bTowing . Это проблемная зависимость .Как показано в листинге 8.6, все определения процессов используют модуль поведения bRepairing вместе с bTowing как комбинацию, так что запуск eDestinationKnown всегда возможен. Если новое определение процесса определяется с помощью bTowing , то по крайней мере одна из других единиц поведения должна содержать задачу, которая запускает событие eDestinationKnown (например, новое поведение, которое позволяет автомобилисту сообщить адрес назначения).Желательно ограничить количество зависимостей от других единиц поведения. Однако, чтобы обеспечить лучшую гибкость, зависимости указываются декларативно и не ограничиваются в пределах поведенческого блока строгими условиями входа и выхода, в некоторой степени ставящими под угрозу модульность поведенческих блоков. При необходимости можно использовать события, инициированные в других единицах поведения. Фактически должна быть хотя бы одна такая зависимость (иначе задачи поведенческих единиц не связаны с остальной частью процесса).Однако не рекомендуется чрезмерно связывать задачи двух блоков поведения. Такое избыточное соединение может указывать на возможную комбинацию двух единиц поведения в одну.

process1_1 существительное — Определение, изображения, произношение и примечания по использованию

1. ряд действий, которые выполняются для достижения определенного результата
   • процесс консультации / планирования
   • Каждый раз, когда мы должны принимать все решение- делая процесс снова.
   • Повторяйте этот процесс, пока вся область не будет выложена плиткой.
   • Боюсь, что изменение вещей будет медленным процессом.
   • Прекращение приема препарата было для него долгим и болезненным (= трудным) процессом.
   • умственные / когнитивные / мыслительные процессы
   • процесс что-то делать Они начали сложный процесс реформирования системы образования.
   • порядок действий Компания ввела новый процесс обработки жалоб.
   • Определите, на какие продукты у вас аллергия, с помощью процесса устранения.
   • в процессе что-то делаем Мы в процессе продажи нашего дома.
   • в процессе Я перемещал мебель и при этом выкрутил лодыжку (= пока я это делал).

   см. Также мирный процесс Дополнительные примеры

   • Любой процесс проектирования со временем развивается по мере появления новой информации.
   • В рамках процесса регистрации заявитель сообщит определенную информацию.
   • Церкви играют ключевую роль в демократическом процессе.
   • Споры и переговоры замедлили процесс.
   • Я начал понимать его мыслительные процессы.
   • Протесты сорвали избирательный процесс в южном регионе.
   • Студенты используют мыслительные процессы и навыки, чтобы получить знания по истории.
   • В компании нет официального процесса подачи жалоб.
   • Весь процесс был завершен менее чем за 24 часа.
   • Процесс отбора занимает две недели.
   • Эти процессы требуют тщательного планирования.
   • Все они должны пройти проверку.
   • Это часть процесса создания музыкальных произведений.
   • судебный процесс по борьбе с мошенниками
   • кропотливый процесс проб и ошибок
   • тупик в мирном процессе
   • мест, где процесс урбанизации обращен вспять
   • процесс торгов за права СМИ
   • долгий обзор процесс для его приложения
   • утомительный процесс создания квитанций и счетов-фактур
   • Это простой процесс, но он может занять некоторое время.
   • Это был сложный процесс, состоящий из четырех или более шагов.

   Темы Закон и справедливостьa2Oxford Collocations Dictionary прилагательное глагол + процесс

   • пройти
   • пройти
   • ускорить
   • …

   процесс + глагол процесс исключения

2. этап в процессе
3. …

См. запись полностью

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

   Oxford Collocations Dictionary прилагательное глагол + процесс

   • пройти
   • пройти
   • ускорить
   • …

   процесс + глагол

   • процесс для
   • процесс

   фразы

   • процесс

   часть процесса исключение

   • стадия в процессе
   • …

   См. полную запись

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

   см. Также четырехцветный процесс Процесс процесса банка языков Описание процесса

   • • Эта диаграмма иллюстрирует процесс изготовления бумаги. / Эта диаграмма показывает, как производится бумага.
   • • В первую очередь бревна доставляются на бумажную фабрику, где удаляется кора и древесина режется на мелкую стружку.
   • • Next / Second, древесная щепа измельчается либо с использованием химикатов, либо в варочной машине.
   • • Варка целлюлозы разрушает внутреннюю структуру древесины и позволяет удалить натуральные масла.
   • • Один раз / после обработки древесины целлюлоза отбеливается для удаления примесей. /… Отбеливается, чтобы можно было удалить загрязнения.
   • • Следующим этапом является подача целлюлозы в бумагоделательную машину, где она смешивается с водой, а затем выливается на проволочную конвейерную ленту.
   • • Когда пульпа движется по конвейерной ленте, вода стекает.Это заставляет твердый материал опускаться на дно, образуя слой бумаги.
   • • На этом этапе новая бумага еще влажная, поэтому ее пропускают между большими нагретыми роликами, которые отжимают оставшуюся воду и одновременно сушат бумагу /… одновременно сушат бумагу.
   • • Заключительный этап — намотка бумаги на большие рулоны. / Наконец, бумага наматывается на большие рулоны.

   обратите внимание, во-первых, наконец, банк языков в заключение, во-первых Дополнительные примеры

   • Большая часть процесса автоматизирована.
   • Его работа — разрабатывать новые продукты и процессы.
   • Процесс был изобретен в 19 веке.
   • Они изготавливаются с использованием самых современных производственных процессов.

   Oxford Collocations Dictionary прилагательное глагол + процесс

   • пройти
   • пройти
   • ускорить
   • …

   процесс + глагол исключение

6. стадия в процессе
7. …

См. полную запись

см. также надлежащую правовую процедуру

Происхождение слова Среднеанглийский язык: от старофранцузского процесса, от латинского processus ‘прогрессия, курс’, от глагола processdere, от pro- «вперед» + cedere «идти».Современные значения глагола относятся к концу 19 века.

См. Процесс в Oxford Advanced American Dictionary См. Процесс в Oxford Learner’s Dictionary of Academic English

Определение процесса и полезное использование в вашей компании

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

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

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

См. Также:

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

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

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

Понять определение процессов и три основные категории:

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

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

Что такое бизнес-процесс? Определение и примеры из жизни!

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

Что такое бизнес-процесс?

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

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

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

История бизнес-процесса

Чтобы объяснить смысл бизнес-процесса, вы должны немного покопаться в истории.Когда вы это сделаете, вы можете обнаружить упоминание о человеке по имени Адам Смит и его цитату из 1827 года, упомянутую в его книге «Исследование природы и причин богатства народов»:

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

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

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

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

Каковы ключевые компоненты бизнес-процесса?

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

1. Иметь четко определенные границы — вы должны знать, что входит, а что должно выходить
2. Определите свою структуру — в идеальном сценарии любой бизнес процесс должен следовать четкому порядку
3. Знайте своего клиента — если вы следуете бизнес-процессу, вы должны знать, кто находится на стороне получателя и обслуживать его
4. Несите очевидную ценность — если вы обслуживаете своих клиентов, используя бизнес-процессы, это должно их приносить ценить и облегчать им жизнь
5. Позвольте процессу стать частью вашей организации — ваша организация не может жить без вашего процесса, и наоборот
6. Сделайте свой процесс универсальным — если вы тщательно планируете, один процесс может обслуживать не один, а несколько различных клиенты
7. Избегайте разрозненности любой ценой — вы не хотите, чтобы ваши серверные разработчики следовали процессу, который знают только они и могут объяснить

9 0410 Определите владельца процесса — кто-то должен контролировать проект и нести полную ответственность за его выполнение и улучшение.

В следующем разделе мы разделим бизнес-процессы на три основные категории.

Категории и примеры бизнес-процессов

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

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

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

Примеры операционных процессов:

Вспомогательные процессы

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

Примеры вспомогательных процессов:

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

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

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

Кто-то должен контролировать, как работает компания. У менеджеров наверняка есть свои правила и процессы, которым они следуют.

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

Примеры процессов управления:

• бюджетирование
• управление (в соответствии с правовыми нормами и внутренними руководящими принципами)
• инфраструктура

Важность бизнес-процессов

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

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

Один мудрец однажды сказал:

«Если не можешь измерить, то не справишься».

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

Измерение соответствия бизнес-процессов

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

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

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

Интеллектуальный анализ процессов как важная основа для создания отчетов о процессах

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

Process Mining помогает реструктурировать бизнес-процессы, но на этом не заканчивается. Вы можете установить жизненно важные KPI (ключевые показатели эффективности), чтобы измерить эффективность или найти узкие места в процессе. Если вас интересуют дополнительные темы о том, как интеллектуальный анализ процессов может помочь вам и вашей организации, вы можете узнать больше в нашей последней статье по этой теме!

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

Обзор соответствия бизнес-процессов

Бизнес-процесс — это только начало

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

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

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

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

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

Документ с описанием процесса — средство коммуникации

♥ 0

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

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

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

Но в чем была настоящая причина отказа? Разработчику никогда не предъявлялись требования к процессу.Поскольку не было документа определения процесса (PDD) .

В документе с описанием процесса подробно описаны необходимые шаги автоматизации. Это инструмент коммуникации, позволяющий разделять единое видение процесса автоматизации. Уровень детализации должен быть таким, чтобы можно было понять этап автоматизации только одним способом. Плохой пример: «Модератор удаляет сообщение». Хорошим примером может быть: «Модератор переходит на страницу сведений о публикации. Модератор нажимает кнопку «Удалить сообщение».Откроется всплывающее окно с вопросом «Вы действительно хотите удалить сообщение?» С кнопками «Да» и «Нет». Модератор нажимает «Да». Сообщение удалено и не отображается в индексе ». Чем меньше двусмысленности, тем лучше.

Также должны быть задокументированы различные пути программы. Что происходит, когда пользователь нажимает кнопку «Далее», но форма сведений о пользователе заполнена только наполовину? Должно ли появиться всплывающее окно с надписью «Пожалуйста, заполните эту информацию»? Визуализируйте программные пути с помощью блок-схемы. Попробуйте подумать о счастливом пути, а затем отклонитесь от него .Что может пойти не так? Вы можете разделить возможные исключения на две категории: логические исключения и системные исключения. Логические исключения — это ошибки в логике программы, например, единичные ошибки. Системные исключения случаются, когда система вышла из строя или находится вне досягаемости, например, в случае сбоя сетевого подключения. Автоматизация должна быть подготовлена ​​к системным исключениям и иметь обходные пути для продолжения процесса автоматизации. Логические исключения должны быть исправлены, системные исключения должны быть подготовлены.

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