Также данная книга доступна ещё в библиотеке. Запишись сразу в несколько библиотек и получай книги намного быстрее.
Как читать книгу после покупки
Посоветуйте книгу друзьям! Друзьям – скидка 10%, вам – рубли
По вашей ссылке друзья получат скидку 10% на эту книгу, а вы будете получать 10% от стоимости их покупок на свой счет ЛитРес. Подробнее
Стоимость книги: 488 ₽
Ваш доход с одной покупки друга: 48,80 ₽
Чтобы посоветовать книгу друзьям, необходимо войти или зарегистрироваться Войти
- Объем: 160 стр. 93 иллюстрации
- Жанр:п росто о бизнесе, п рочая образовательная литература, р уководстваРедактировать
Разработка архитектуры бизнес-процессов компании в Business Studio
Шрифт: Меньше Аа Больше Аа
Создано в интеллектуальной издательской системе Ridero
1. Введение. Зачем нужна архитектура процессов компании?
1.1. Для кого и для чего написана эта книга
Вы держите перед собой книгу – краткое практическое пособие по построению архитектуры бизнес-процессов компании с использованием нотаций IDEF0, BPMN и программного продукта Business Studio. В книге достаточно подробно разобраны правила использования нотации IDEF0. Нотация BPMN рассматривается только в части интеграции схем BPMN в общую архитектуру процессов компании. Читателям, которые хотели бы начать использовать BPMN, рекомендую обратиться к книге [3] в «Списке рекомендуемой литературы».
Мастер-класс «Построение архитектуры бизнес процессов компания в Business Studio» от 20 мая 2021
Книга посвящена системному подходу к построению архитектуры процессов, а не методу описания некоторых абстрактных упрощенных процессов в нотации IDEF0. Материал требует внимательного, вдумчивого изучения.
Архитектура бизнес-процессов является частью общей модели бизнеса и представляет собой базу, платформу для системного внедрения технологий процессного управления в компании.
Кроме построения архитектуры, другие методы и инструменты внедрения Системы управления бизнес-процессами компании рассматриваться не будут, так как по этой теме есть ряд вполне актуальных книг (см., например, [1]).
Данная книга поможет вам:
1. научиться использовать нотацию IDEF0 для проектирования бизнес-процессов;
2. освоить базовый функционал программы Business Studio в части создания моделей процессов в нотации IDEF0;
3. построить архитектуру бизнес-процессов своей компании, используя представленные в книге методики и рекомендации.
Книгу могут использовать как подготовленные читатели (специалисты по орг. развитию, бизнес-аналитики), так и все желающие изучить метод проектирования бизнес-процессов с использованием нотации IDEF0 (нотация BPMN рассматривается только в части интеграции с моделями в IDEF0).
Представленные подходы могут быть использованы при построении архитектуры бизнес-процессов в других нотациях (например, в ARIS VAD) и программных продуктах после некоторой адаптации.
Применение методики создания архитектуры бизнес-процессов в книге показано на упрощенном примере некоторой торгово-производственной компании.
Архитектура бизнес-процессов
1.2. Функциональный и процессный подходы к управлению
Кратко остановимся на различиях между функциональным и процессным подходом к управлению. На рис. 1 слева показан взгляд на процессы, выполняемые в функциональных подразделениях организации. Можно назвать эти процессы функциональными. Причем это именно процессы, имеющие четкие границы, а не просто абстрактные функции типа «Маркетинг» или «Производство».
Функциональный процесс – это полноценный процесс, имеющий входы и выходы, технологию и ресурсы. Но выполняется он целиком в рамках конкретного функционального подразделения (отдела, департамента).
Рис. 1. Функциональный и процессный взгляд.
Как правило, функциональный процесс сам по себе не создает законченный результат ни для компании в целом, ни для ее клиентов. Этот результат носит промежуточный, частичный характер. Только несколько функциональных процессов, определенным образом взаимодействующих между собой, могут создавать результат, действительно важный для организации и/или ее клиентов (в широком смысле).
Справа на рисунке 1 показано, как из функциональных процессов «собраны» два сквозных процесса – А и Б. Часть функциональных процессов невозможно (либо нерационально) отнести к сквозным процессам, но их можно определенным образом сгруппировать в рамках архитектуры. (Чуть ниже я дам определение сквозного процесса).
Суть процессного управления в масштабах компании – определение сквозных процессов и организация управления этими процессами за счет назначения владельцев процессов, определения их ответственности и полномочий, выполнения проектов оптимизации процессов, разработки и использования соответствующих целей и показателей для оперативного управления процессами, автоматизации процессов.
При этом никто не мешает руководителям подразделений применять базовые методы процессного управления к своим функциональным процессам. Четкое определение их границ, регламентация и автоматизация помогут повысить эффективность работы организации. Эффект, безусловно, будет. Но не такого масштаба, как от оптимизации и управления сквозными процессами масштаба компании в целом или ее крупных сегментов.
1.3. Необходимые определения
При построении архитектуры все участники проекта и вовлеченные сотрудники компании должны говорить на одном языке, т.е. использовать одни и те же термины, вкладывая в них соответствующие смыслы. В качестве рабочего варианта можно предложить следующую систему терминов.
Архитектура бизнес-процессов – совокупность определенных в компании взаимосвязанных бизнес-процессов различного уровня, представленных в виде моделей в нотациях IDEF0 и BPMN (eEPC), созданных с использованием программного продукта Business Studio (ARIS, iGrafx, Elma и т.п.).
Приведу еще определение архитектуры системы из Википедии:
Архитектура системы – принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.
Если во втором определении заменить слово «элемент» на «бизнес-процесс», то получится хорошее определение архитектуры бизнес-процессов компании. Далее в книге вы сможете ознакомиться как раз с принципами методологии построения такой системы с использованием нотации IDEF0 и программного продукта Business Studio.
Можно дать и другие определения архитектуры. Вам важно выбрать какое-то одно и постоянно использовать его при выполнении проекта.
Построение архитектуры возможно только с учетом функциональных особенностей и ограничений соответствующего программного продукта. Возможности построения архитектуры в Power Point, на бумаге или в виде липких желтых листочков на стене офиса не рассматриваются в качестве серьезного варианта, хотя могут использоваться на первых порах в рамках групповой работы.
Архитектура состоит из процессов. Приведу рабочее определение:
Бизнес-процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.
На рис. 2 бизнес-процесс схематично представлен, как объект управления. Предложенная схема является универсальной и может применяться для процесса любого уровня сложности там, где это целесообразно.
Чтобы определить бизнес-процесс, необходимо установить его границы. Для этого нужно определить входы и выходы, а также условия начала и завершения процесса (события).
Для процессов большого масштаба (например, «Продажа» в крупной компании), определять стартовые и завершающие события можно весьма укрупненно, для содержательного анализа. Для процессов на нижнем уровне (т.н. операционных процессов), определение четких стартовых и завершающих событий является обязательным, в том числе для решения задачи автоматизации.
Замечу, что при создании графических диаграмм в нотации IDEF0, понятие «Событие» не используется, так как нотация IDEF0 не является нотаций типа Work Flow 1 .
Рис. 2. Бизнес-процесс, как объект управления.
Входы и выходы – это информационные или материальные объекты: файлы с информацией, документы на бумажном носителе, материалы для производства и т. п. Требования к каждому входу/выходу должны быть четко определены (специфицированы) в документах и согласованы со всеми заинтересованными сторонами: с поставщиками и потребителями процесса, руководством вышестоящего уровня и, в некоторых случаях, с государством.
Кроме входов/выходов важно определить условия начала и завершения процесса. Процесс может «запускаться» в определенное время («по таймеру») или при получении управляющего сообщения (например, устного распоряжения руководителя). Наличие готовых (например, сложенных горкой) входов еще не означает, что процесс нужно запускать. Так же необходимо четко определить условия завершения процесса, т.е. в каких случаях можно считать, что процесс завершен. Например, документы переданы, товар упакован и помещен на место хранения, клиент подтвердил получение документа и т. п. Опять же, условия завершения не являются выходами процесса.
На рис. 2 показано, что бизнес-процесс выполняется по определенной «технологии». По сути, это продуманная система действий, выполнение которых приводит к получению результата с заданными, повторяющимися характеристиками. Для практического выполнения нужны ресурсы – люди, оборудование, информационные системы и проч.
Они связаны между собой в том смысле, что отсутствие необходимого оборудования или людей повлечет за собой изменение технологии. Наоборот, цель изменения (оптимизации) бизнес-процесса может повлечь за собой изменения в требованиях к ресурсам.
Технология выполнения бизнес-процесса хранится, как минимум, в виде знаний и навыков в головах сотрудников, которые его выполняют. Как правило, знания о технологии выполнения процесса фиксируются в регламентах (положениях, инструкциях). Кроме того, требования к выполнению процесса могут быть «зашиты» в информационные системы, которые используются для автоматизации. Но как показывает практика, наличие автоматизации процессов не исключает необходимости создания системы регламентов, по которым выполняется работа. Сотрудники компании должны иметь к ним быстрый и легкий доступ, например, через внутренний web-портал.
Слева на рис. 2 показан график нагрузки на бизнес-процесс. Объекты («Входы»), которые нужно обрабатывать, поступают с определенной интенсивностью в течение определенного времени. Например, необходимо обрабатывать партию из 5 деталей каждые 2 минуты. В этом случае график нагрузки будет дискретным – с равномерным интервалом.
Другой пример – суточный график количества посетителей для супермаркета, на котором будут видны периоды пиковой нагрузки.
Итак, нагрузка на бизнес-процесс – это количество объектов, поступающих на вход процесса, которое нужно обработать за единицу времени. Однако, возможности процесса ограничены, в первую очередь, по ресурсам.
Используемая технология выполнения процесса и ресурсы (оборудование, люди) определяют производительность процесса – возможность преобразовывать определенное количество объектов за единицу времени. На рис. 2 снизу показан график производительности процесса. На нем видны ступеньки. Это может быть, например, из-за того, что вводилось/выводилось из эксплуатации оборудование, добавляли людей в рабочие смены и т. п.
Что будет с объектами, которые бизнес-процесс не в состоянии пропустить через себя из-за ограничений по производительности? Они встанут в очередь – см. соответствующий график на рис. 2.
Нагрузка на процесс и его текущая производительность определяют, сколько входящих объектов могут быть обработаны на единицу времени. На рис. 2 справа показан график выходов (результатов) процесса.
На рис. 2 показаны цели и показатели, а также владелец бизнес-процесса. Цели и показатели нужны для управления процессом. Производительность является одним из ключевых показателей. Кроме нее, важно измерять результативность (план/факт по полученным результатам), эффективность (отношение результата к затраченным на его получение ресурсам), показатели качества (например, уровень дефектов в выходах процесса).
Для организации, как системы ориентированной на достижение целей во внешней среде, важно не просто преобразовывать входы в выходы, а делать это эффективно, т.е. с прибылью для себя. Это означает, что крайне важно измерять и улучшать показатели эффективности процесса. Ответственным за это является владелец процесса:
Владелец бизнес-процесса – руководитель, который имеет в своем распоряжении выделенные ресурсы, управляет ходом бизнес-процесса, несет ответственность за достижение поставленных целей.
Владельцу подчиняются все выделенные ресурсы процесса. От используемого в компании метода распределения ресурсов зависит степень самостоятельности владельца процесса: от мониторинга процесса, до полноценного управления всеми ресурсами (вплоть до привлечения инвестиций).
Цели процесса и показатели, которые служат для измерения этих целей, владелец процесса сам себе определять не имеет права. Это должны делать руководители вышестоящего уровня, которые понимают роль этого процесса в общей системе работы организации и в состоянии правильно установить цели и выбрать показатели для измерения степени их достижения (на практике с этим часто бывают проблемы).
Источник: www.litres.ru
Архитектура процессов: Определение, преимущества и примеры
Архитектура процессов — это диаграмма или структура, которая описывает этапы, компоненты, системы организации и то, как они влияют друг на друга. Разработка и понимание архитектуры процессов может помочь вам определить ценности и процессы, которые управляют бизнесом или системой. Архитектура процессов может помочь вам принимать решения и оставаться последовательными в своих процедурах.
В этой статье мы объясним определение архитектуры процессов, опишем ее преимущества, приведем характеристики эффективной архитектуры и дадим примеры методов, которые вы можете использовать для разработки собственной архитектуры.
Что такое архитектура процессов?
Архитектура процесса — это структурная схема процессов и компонентов системы или организации и их влияния друг на друга. Такие отрасли, как вычислительная техника, бизнес и управление проектами, используют архитектуру процессов для отображения и настройки каждого компонента своих процессов. Диаграмма архитектуры процесса — это визуальная карта иерархии и потока процессов в системе и их взаимодействия. Архитектура процессов может помочь обеспечить постоянство результатов деятельности компании или системы.
Преимущества архитектуры процессов
Архитектура процессов может принести пользу компаниям следующими способами:
Принятие решений
Стандартная архитектура процессов может помочь руководителям компании при принятии решений. Архитектура процессов обычно описывает цели, методы и ценности бизнеса. Возможность проконсультироваться по этим идеям и их уровням важности может облегчить оценку возможных решений и того, как они вписываются в структуру. Размещение потенциальных решений или изменений в потоке структуры может также показать, какое влияние они могут оказать на другие элементы системы.
Прогнозирование последствий
Поддержание архитектуры процессов помогает прогнозировать и планировать влияние изменений в системе. Архитектура процессов обычно представляет собой блок-схему, связывающую факторы и этапы бизнес-операций. Эта блок-схема дает возможность вставлять недавние изменения и отслеживать их влияние через остальные процедуры и результаты. Визуальное представление влияний и системных циклов может помочь спрогнозировать потенциальные решения и решить, где внедрять изменения.
Соблюдение последовательности
Архитектура процессов создает и поддерживает последовательность как в системе, так и в бизнесе. Если каждый сотрудник четко представляет себе процедуру и иерархию своей организации, это позволяет всем сосредоточиться на одной конечной цели. Аналогичным образом, если вы программируете системы с одинаковой архитектурой процессов, они могут производить более последовательную продукцию.
Как только вы разработали структуру архитектуры, вы можете обновлять ее и рассматривать как базу данных. Доступ к этим структурам процессов позволяет сотрудникам ссылаться на них при необходимости и гарантирует, что все следуют одним и тем же процедурам для достижения общих целей.
Выявление улучшений
Создание архитектуры процессов требует глубокого понимания людей, отделов, процессов, систем и переменных, присутствующих в бизнесе. Идентификация и соотнесение этих элементов может облегчить понимание того, какие факторы являются избыточными или неэффективными. Возможно, вы сможете устранить процессы, которые присутствуют на схеме, но имеют мало смысла или не имеют связи с основными целями. Существует также возможность объединения похожих процессов или включения новых, более эффективных. Совершенствование даже незначительных процедур может помочь повысить успешность и производительность труда.
Ключевые характеристики эффективной архитектуры процессов
Ниже приведены некоторые черты, которыми может обладать полезная архитектура процессов:
Высокоуровневый
Архитектуры процессов направлены на представление бизнес-циклов, в которых участвует вся организация, поэтому полезно, чтобы они были простыми и высокоуровневыми. Поразмышляйте над основными этапами разработки и распределения продукции, которые выполняют различные отделы. Не забывайте сосредоточиться на описании того, что происходит на каждом этапе, а не на том, как или почему. Эти детали могут быть важны для команд, но сохранение простоты архитектуры процессов может помочь вам уменьшить беспорядок и улучшить ясность.
Ориентированность на клиента
Архитектура процессов направлена на описание всего бизнес-цикла, заканчивающегося поставкой продукта или услуги клиенту. По этой причине важно сосредоточиться на результатах ваших процессов. Это может помочь вам выбрать шаги и меры, которые помогут вам обеспечить большую ценность для клиента и усовершенствовать ваши стандарты качества, чтобы лучше соответствовать его потребностям.
Соответствующими целям организации
Архитектура процессов должна отражать то, как вся организация смотрит на бизнес. Не забудьте включить каждый важный процесс и то, как он взаимодействует с другими процессами. Также полезно рассмотреть, соответствуют ли процессы целям организации. Просмотрите диаграмму архитектуры процессов, чтобы найти пробелы в процессах и заполнить их значимыми действиями, которые связывают бизнес-деятельность.
Четкий
Важно описывать процессы просто и точно, чтобы каждый сотрудник организации мог понять архитектуру процесса. Эти представления обычно представляют различные отделы и уникальные процессы, которые они выполняют. Четкая коммуникация может помочь людям за пределами каждого отдела понять, какой вклад вносят другие команды.
5 примеров архитектуры процессов
Вот пять распространенных примеров подходов к архитектуре процессов:
1. Основанная на целях
Основанный на целях подход к архитектуре процессов начинается с определения основных целей системы и того, как эти цели влияют друг на друга. После определения целей, создание архитектуры процессов соединяет шаги, необходимые для достижения этих целей. В этом процессе цели также располагаются в иерархии по степени важности, показывая, какие цели имеют приоритет при принятии сложных решений. Отслеживание процессов, ведущих к достижению цели компании, может показать вам, какие элементы требуют большего внимания, и помочь вам определить цели, которые могут потребовать корректировки для приведения в соответствие с общими целями компании.
2. Основанный на действии
Архитектура процессов на основе действий начинается с определения повседневных действий бизнеса и их взаимосвязи друг с другом. Предприятия обычно представляют это с помощью диаграммы или потока, который описывает шаги, предпринимаемые сотрудниками при предоставлении клиенту или заказчику услуги или продукта от начала до конца. Наличие документированной процедуры ваших действий помогает визуализировать элементы успешного бизнес-процесса и позволяет добавлять или вычитать шаги для повышения производительности. Разработка определенного плана действий также способствует последовательности в бизнес-операциях, гарантируя, что все будут следовать одним и тем же основным принципам.
3. Объектно-ориентированная
При построении объектно-ориентированной архитектуры процессов первым шагом является составление списка существующих в организации объектов. Эти объекты обычно включают клиентов, заказы, запросы и услуги. После идентификации этих объектов архитектура процесса структурирует их в соответствии с их отношением к бизнес-процессу и ролью в нем. Эта диаграмма отслеживает поток операций и то, какие отделы ими занимаются. Эта архитектура отображает все компоненты, составляющие основные цели бизнеса или системы, и полезна для выявления потенциальных пробелов или ошибок.
4. Основанная на функциях
Архитектура процессов на основе функций представляет собой визуальную иерархию функций бизнеса. Архитектура на основе функций демонстрирует основные возможности организации и разделяет каждую из них на более подробные, более мелкие функции, которые она включает в себя. Эта структура может помочь вам понять, как каждая функция работает на целенаправленном уровне и какие элементы необходимы для успешного процесса.
5. На основе эталонной модели
Архитектура процессов на основе эталонной модели использует существующую архитектуру в качестве точки отсчета для построения диаграмм новых систем и разработок. Для этих архитектур измените конфигурацию исходной диаграммы, чтобы отобразить изменения в вашей деятельности или структуре. Эти изменения могут представлять собой новые цели, объекты, действия или функции, а подход эталонной модели может использовать один из других упомянутых подходов. Для создания новой архитектуры процессов можно использовать существующую внутреннюю структуру в качестве образца или проанализировать внешний шаблон аналогичной организации.
Ключевые слова:
- indeed.com
Источник: hr-portal.ru
Разработка архитектуры бизнес-процессов компании в Business Studio
При построении архитектуры все участники проекта и вовлеченные сотрудники компании должны говорить на одном языке, т.е. использовать одни и те же термины, вкладывая в них соответствующие смыслы. В качестве рабочего варианта можно предложить следующую систему терминов.
Архитектура бизнес-процессов – совокупность определенных в компании взаимосвязанных бизнес-процессов различного уровня, представленных в виде моделей в нотациях IDEF0 и BPMN (eEPC), созданных с использованием программного продукта Business Studio (ARIS, iGrafx, Elma и т.п.).
Приведу еще определение архитектуры системы из Википедии:
Архитектура системы – принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.
Если во втором определении заменить слово «элемент» на «бизнес-процесс», то получится хорошее определение архитектуры бизнес-процессов компании. Далее в книге вы сможете ознакомиться как раз с принципами методологии построения такой системы с использованием нотации IDEF0 и программного продукта Business Studio.
Можно дать и другие определения архитектуры. Вам важно выбрать какое-то одно и постоянно использовать его при выполнении проекта.
Построение архитектуры возможно только с учетом функциональных особенностей и ограничений соответствующего программного продукта. Возможности построения архитектуры в Power Point, на бумаге или в виде липких желтых листочков на стене офиса не рассматриваются в качестве серьезного варианта, хотя могут использоваться на первых порах в рамках групповой работы.
Архитектура состоит из процессов. Приведу рабочее определение:
Бизнес-процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.
На рис. 2 бизнес-процесс схематично представлен, как объект управления. Предложенная схема является универсальной и может применяться для процесса любого уровня сложности там, где это целесообразно.
Чтобы определить бизнес-процесс, необходимо установить его границы. Для этого нужно определить входы и выходы, а также условия начала и завершения процесса (события).
Для процессов большого масштаба (например, «Продажа» в крупной компании), определять стартовые и завершающие события можно весьма укрупненно, для содержательного анализа. Для процессов на нижнем уровне (т.н. операционных процессов), определение четких стартовых и завершающих событий является обязательным, в том числе для решения задачи автоматизации.
Замечу, что при создании графических диаграмм в нотации IDEF0, понятие «Событие» не используется, так как нотация IDEF0 не является нотаций типа Work Flow.
Рис. 2. Бизнес-процесс, как объект управления.
Входы и выходы – это информационные или материальные объекты: файлы с информацией, документы на бумажном носителе, материалы для производства и т. п. Требования к каждому входу/выходу должны быть четко определены (специфицированы) в документах и согласованы со всеми заинтересованными сторонами: с поставщиками и потребителями процесса, руководством вышестоящего уровня и, в некоторых случаях, с государством.
Кроме входов/выходов важно определить условия начала и завершения процесса. Процесс может «запускаться» в определенное время («по таймеру») или при получении управляющего сообщения (например, устного распоряжения руководителя). Наличие готовых (например, сложенных горкой) входов еще не означает, что процесс нужно запускать. Так же необходимо четко определить условия завершения процесса, т.е. в каких случаях можно считать, что процесс завершен. Например, документы переданы, товар упакован и помещен на место хранения, клиент подтвердил получение документа и т. п. Опять же, условия завершения не являются выходами процесса.
На рис. 2 показано, что бизнес-процесс выполняется по определенной «технологии». По сути, это продуманная система действий, выполнение которых приводит к получению результата с заданными, повторяющимися характеристиками. Для практического выполнения нужны ресурсы – люди, оборудование, информационные системы и проч.
Они связаны между собой в том смысле, что отсутствие необходимого оборудования или людей повлечет за собой изменение технологии. Наоборот, цель изменения (оптимизации) бизнес-процесса может повлечь за собой изменения в требованиях к ресурсам.
Технология выполнения бизнес-процесса хранится, как минимум, в виде знаний и навыков в головах сотрудников, которые его выполняют. Как правило, знания о технологии выполнения процесса фиксируются в регламентах (положениях, инструкциях). Кроме того, требования к выполнению процесса могут быть «зашиты» в информационные системы, которые используются для автоматизации. Но как показывает практика, наличие автоматизации процессов не исключает необходимости создания системы регламентов, по которым выполняется работа. Сотрудники компании должны иметь к ним быстрый и легкий доступ, например, через внутренний web-портал.
Слева на рис. 2 показан график нагрузки на бизнес-процесс. Объекты («Входы»), которые нужно обрабатывать, поступают с определенной интенсивностью в течение определенного времени. Например, необходимо обрабатывать партию из 5 деталей каждые 2 минуты. В этом случае график нагрузки будет дискретным – с равномерным интервалом.
Другой пример – суточный график количества посетителей для супермаркета, на котором будут видны периоды пиковой нагрузки.
Итак, нагрузка на бизнес-процесс – это количество объектов, поступающих на вход процесса, которое нужно обработать за единицу времени. Однако, возможности процесса ограничены, в первую очередь, по ресурсам.
Используемая технология выполнения процесса и ресурсы (оборудование, люди) определяют производительность процесса – возможность преобразовывать определенное количество объектов за единицу времени. На рис. 2 снизу показан график производительности процесса. На нем видны ступеньки. Это может быть, например, из-за того, что вводилось/выводилось из эксплуатации оборудование, добавляли людей в рабочие смены и т. п.
Что будет с объектами, которые бизнес-процесс не в состоянии пропустить через себя из-за ограничений по производительности? Они встанут в очередь – см. соответствующий график на рис. 2.
Нагрузка на процесс и его текущая производительность определяют, сколько входящих объектов могут быть обработаны на единицу времени. На рис. 2 справа показан график выходов (результатов) процесса.
На рис. 2 показаны цели и показатели, а также владелец бизнес-процесса. Цели и показатели нужны для управления процессом. Производительность является одним из ключевых показателей. Кроме нее, важно измерять результативность (план/факт по полученным результатам), эффективность (отношение результата к затраченным на его получение ресурсам), показатели качества (например, уровень дефектов в выходах процесса).
Для организации, как системы ориентированной на достижение целей во внешней среде, важно не просто преобразовывать входы в выходы, а делать это эффективно, т.е. с прибылью для себя. Это означает, что крайне важно измерять и улучшать показатели эффективности процесса. Ответственным за это является владелец процесса:
Владелец бизнес-процесса – руководитель, который имеет в своем распоряжении выделенные ресурсы, управляет ходом бизнес-процесса, несет ответственность за достижение поставленных целей.
Владельцу подчиняются все выделенные ресурсы процесса. От используемого в компании метода распределения ресурсов зависит степень самостоятельности владельца процесса: от мониторинга процесса, до полноценного управления всеми ресурсами (вплоть до привлечения инвестиций).
Цели процесса и показатели, которые служат для измерения этих целей, владелец процесса сам себе определять не имеет права. Это должны делать руководители вышестоящего уровня, которые понимают роль этого процесса в общей системе работы организации и в состоянии правильно установить цели и выбрать показатели для измерения степени их достижения (на практике с этим часто бывают проблемы).
Источник: www.livelib.ru