Границы бизнес процесса это

Границы БП – граница входа, которая предшествует первой операции процесса, и граница выхода, которая следует за его последней операцией.

Начальная граница процесса – предшествует первой выполняемой функции процесса.

Конечная граница процесса – располагается за последней функцией процесса.

Интерфейс БП – организационный, информационный и технический механизм, посредством которого БП взаимодействует с предшествующим и последующим БП.

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

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

1. Архитектура процессов (уровни представления). Понятие «продукт». Категории продукции.

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

Продукт – результат процесса (ISO 9000:2005)

4 категории продукции:

 Услуга является результатом по меньшей мере одного действия, обязательно осуществляемого при взаимодействии поставщика и потребителя. Она, как правило, нематериальна.

 Программные средства содержат информацию, являются нематериальными.

 Технические средства материальны, и их количество выражается исчисляемой характеристикой.

 Перерабатываемые материалы являются материальными и их количество выражается непрерывной характеристикой.

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

1. Системный анализ как основа описания деятельности. Понятия «система», «цель», «система целей». Классификация целей по признаку «интервал планирования». Классификация целей по качественному признаку решения проблем бизнеса.

1. Основные свойства системы. Понятие «системный подход». Задачи, для решения которых применяется системный подход.

 Целенаправленность – определяет поведение системы

 Сложность – зависит от множества входящих в нее компонентов

 Делимость – система состоит из ряда подсистем, выделенных по определенному признаку

 Целостность — функционирование всех элементов системы подчинено единой цели

 Многообразие элементов системы и различие их природы

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

1. Понятия «бизнес-система», «структурный анализ», «структура организации», «подсистема организации».

Бизнес-система – это система для организации и ведения бизнеса. Бизнес-систему необходимо рассматривать в неразрывной связи с внешней средой.

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

Структура организации – устойчивая картина взаимных отношений подсистем организации.

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

1. Задачи структурного анализа. Понятие «методология».

Задачи структурного анализа организации:

 Выявление структуры как относительно устойчивой совокупности отношений

 Частичное отвлечение от развития объектов

 Графическое модельное представление объектов, которое начинается с общего обзора и затем детализируется

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

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

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

1. Понятия «структурный объект», «связь». Методологии структурного анализа.

Структурный объект – неделимая наименьшая часть системы (на данном уровне рассмотрения).

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

1. Основные шесть методов структурного анализа. Семейство стандартов IDEF.

1. Понятие «документирование деятельности». Важнейшие требования к документированию деятельности.

1. Роль CASE-систем в структурном анализе, привести примеры CASE систем. Привести примеры основных БП. Понятие «моделирование деятельности организации».
2. Понятие «бизнес-моделирование» как составляющая моделирования деятельности. Объект моделирования при описании деятельности организации. Предмет моделирования (объект управления в конкретной организации).
3. Комплекс проектов по совершенствованию деятельности: состав и очередность.
4. Управление проектами в соответствии с PMI PMBOK. Понятия «проект», «проектный треугольник», «управление проектами». Программные продукты, позволяющие автоматизировать деятельность по управлению проектом.
5. Понятия «стратегическое планирование», «стратегическое управление», «система стратегического управления», «система сбалансированных показателей» (Balanced Scorecard).

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

Пять элементов стратегии (Г.Минцберг):

• стратегия как план;
• стратегия как позиция;
• стратегия как приём;
• стратегия как паттерн действий;
• стратегия как перспектива.

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

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

Ключевые моменты стратегического планирования:

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

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

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

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

1. Назначение BSC и основания для ее внедрения.
2. Порядок разработки системы показателей BSC.Понятия «дерево целей», «перспектива», «стратегическая карта», «ключевой показатель эффективности», «измеритель достижимости цели», «показатель эффективности бизнес-процесса», «вес ключевого показателя эффективности», «источник данных для показателя», «мероприятие» (инициатива), «ответственный за мероприятие».
3. Контроль достижения целей в методике BSC.Реализация принципа обратной связи в BSC. Основное отличие методики BSCот простого набора показателей.
4. Цели и логика разработки соглашения по моделированию БП как основы для документирования деятельности.
5. Структура соглашения по моделированию.
6. Методы получения информации о деятельности организации в рамках проекта по описанию бизнес-процессов.
7. Порядок описания существующих бизнес-процессов. Виды документов, разрабатываемых на основе бизнес-модели и регламентирующих деятельность.
8. Основные результаты проекта по описанию бизнес-процессов.
9. Этапы проекта по совершенствованию бизнес-процессов.
10. Результаты проекта по совершенствованию бизнес-процессов.
11. Метод моделирования SADT. Назначение метода. Структура бизнес-модели по уровням декомпозиции.

Для моделирования БП используются несколько различных методов. Основой этих методов является как структурный, так и объектно-ориентированный подходы. Однако деление методов на структурный и объектный является достаточно условным, потому что наиболее развитые методы используют оба подхода. К числу наиболее распространенных методов относятся:

-метод функционального моделирования SADT(IDEF0)

-метод моделирования процессов из семейства методов IDEF3

-метод моделирования потоков данных

-метод моделирования, используемый в технологии RUP

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

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

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

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

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

-описание элементарной бизнес-операции. Осуществляется посредством задания алгоритма и его выполнения.

Метод SADT разработан Дугласом Россом в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, промышленных и коммерческих организаций США для решения задач:

-долгосрочное стратегическое планирование;

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

-разработка программного обеспечения для оборонных систем;

-управление финансами и материально-техническим снабжением.

Метод SADT поддерживается мин обороны США, которое было инициатором разработки семейства стандартов IDEF. Метод SADT реализован в одном стандарте этого семейства — 0.

Данный стандарт утвержден в качестве федерального стандарта США в 1993г. Существует также российская версия данного стандарта [9]. Вместе со стандартом IDEF0 обычно используется стандарт IDEF3 и стандарт моделирования данных IDEF1X.

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

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

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

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

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

Источник: studfile.net

Бизнес-процессы. Моделирование, внедрение, управление

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

Границы процесса – событие (совокупность событий), инициирующее и завершающее процесс.

Событие – наступление определенной ситуации (времени, перехода ответственности за ресурсы).

Инициирующее событие – событие, при наступлении которого начинается процесс.

Завершающее событие – событие, которым завершается процесс.

Пусть ресурс «А» является результатом преобразования в некотором процессе (рис. 1.2.2). С точки зрения владельца этого процесса ресурс «А» – выход. С точки зрения владельца процесса-потребителя ресурс «А» – вход. В момент передачи ресурса «А» от одного процесса к другому происходит переход ответственности за этот ресурс между владельцами процессов.

Факт движения ресурса, сопровождающийся переходом ответственности, может быть идентифицирован при помощи события. С точки зрения владельца первого процесса это событие завершает процесс, с точки зрения владельца второго процесса – инициирует его. Одно и то же событие может быть сформулировано по-разному при описании границ двух рассматриваемых процессов. Первый владелец скажет, что ресурс «А» передан, а второй – что ресурс «А» получен. Чтобы при описании процессов было удобнее увязывать их в единую систему, лучше определять одно событие и давать ему примерно такую формулировку: «Ресурс “А” передан из процесса 1 в процесс 2» . В любом случае формулировки событий должны быть обязательно согласованы между владельцами процессов при регламентации границ.

Рис. 1.2.2. Границы процессов

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

• «Товар помещен в зону хранения»;

• «Продукция упакована и передана покупателю»;

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

• «Поступил заказ клиента»;

• «Руководитель дал отмашку».

Последний пример приведен в шутку. С практической точки зрения такая формулировка события недопустима. Лучше сформулировать так: «Поступило распоряжение руководителя приступить к выполнению работы» (желательно в письменной форме или хотя бы по e-mail).

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

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

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

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

Еще пример: рассмотрим отправку какого-либо документа по корпоративной электронной сети. Факт отправки документа сотрудником можно описать событием «Документ отправлен по e-mail». Однако сотрудник, которому отправлен данный документ, может его получить не сразу или вообще не получить (сбой сети, случайное удаление и т. п.). Значит, инициировать процесс второго сотрудника будет событие «Получен документ по e-mail». Очевидно, что это два разных события. В данном случае можно:

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

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

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

Итак, для четкого определения границ процесса необходимо:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом отлично может помочь инструмент, под названием «Диаграмма SIPOC»

Управление бизнес-процессами
Построение диаграммы SIPOC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

Для того, чтобы правильно определить границы бизнес процесса, необходимо:

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

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

Источник: deep-vision.one