Задание на 13.03.2020

Лабораторная работа

Теоретические сведения

1.        ОСНОВНЫЕ ПОНЯТИЯ ПРОЦЕССНОГО ПОДХОДА

1.1.   Возникновение процессного подхода

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

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

1.2.   Управление по целям через процессы

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

Основой любого процесса является целенаправленность, взаимодействие и последовательность.

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

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

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

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

Сколько и каких процессов должно быть в компании определяют цели и стратегии их  достижения (рис. 1).

Рисунок 1 - Схема процессного управления Компанией

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

Рисунок 2 - Структура целей и процессов компании

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

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

· цели компании, которые формируются на этапе разработки стратегии;

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

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

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

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

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

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

Существуют также и другие взгляды на классификацию процессов. Например, в методологии системы BANN (BAAN Orgware) выделяется четыре, так называемые, «категории стратегических моделей» в которые входят все процессы компании:

1. Модель финансового управления (взгляд на бизнес с точки зрения движения финансовых средств).

2. Маркетинговая модель (оценка влияния внешней среды на рассматриваемый бизнес).

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

4. Модель управления логистикой (снабжение и сбыт).

Все процессы по методологии ВААN Orgware делятся на основные и детальные.

• Основные процессы (main) - являются специфичными для определенного типа организации и определяются из контрольной модели потока товаров.

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

Методология предлагает следующий перечень детальных (общих) процессов:

ММ - Manufacturing - производство;

ВА - Basic Data Process - основные данные;

SL - Sales Process - процесс продаж;

РU - Purchasing - закупки;

PL - Planning (аll resources) - планирование;

FI - Finance - финансы;

SE - Service - обслуживание;

WH - Warehousing - хранение на складе;

ЕN - Engineering - конструирование;

FR - Formula Мапаgement - управление формулами;

IT - System Management - управление устройствами;

РI - Project Industries - проектные производства;

РS Project Services - обслуживание проектов;

РМ - Рroduct Ваtch Маnagment - управление упаковкой продукции;

QI - Quality Inspection - проверка качества;

QМ - Quality Managment - управление качеством;

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

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

• из чего они состоят;

• какие существуют средства описания и документирования;

• кого назначать ответственными;

• как анализировать эффективность того или иного процесса.

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

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

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

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

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

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

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

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

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

1.5.   Границы и интерфейсы процесса. Клиенты процесса

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

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

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

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

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

Границы процесса - события, начинающие и завершающие процесс.

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

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

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

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

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

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

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

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

1.6.   Принципы процессного управления

1.      Процессное управление основывается на управлении по целям.

2.     Количество и форма процессов определяется целями.

3.     Ответственность за результат и выполнение процесса возлагается на владельца процесса.

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

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

2.        ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ

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

· функции (операции, действия);

· события (в некоторых методиках используется термин «состояния»);

· ресурсы, среди которых, отдельно выделяют две группы:

· исполнители - роли, сотрудники, должности, подразделения

· информационные ресурсы - документы, файлы, архивы и другие носители
информации;

· продукты и услуги.

2.1.   Функции (операции, действия)

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

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

Возможны три варианта структурирования функций на предприятии:

·  по объекту - объектно-ориентированный;

·  по процессу - процессно-ориентированный;

·  по операциям - операционно-ориентированный.

Объектно-ориентированный подход заключается в том, что выделяются все функции, которые воздействуют на один и тот же объект, например, 2заказ» (рис. 4).

При процессно-ориентированном подходе выделяются все функции, задействованные в процессе, например, «обработка заказа» (рис. 5).

При операционно-ориентированной структуре функций внимание сосредотачивается на виде операций, например, «корректировка» (рис. 6).

2.2.   События

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

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

2.3.  Ресурсы

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

2.4.   Исполнители

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

Существуют следующие типы участников процесса:

·  организационные звенья - структурные подразделения - отделы, и т. д.;

·  должности - различные должности из штатного расписания компании, например: Менеджер по продажам, Логистик, Товаровед, Нач. цеха №1;

·  сотрудники - персоналии, работники компании (ФИО), например, Иванов Иван Иванович;

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

Организационные звенья могут использоваться при наиболее общем описании бизнес- процессов всего предприятия или для описания функционала организации. В примере (Табл. 1) приведено распределение функций предприятия по Организационным звеньям.

Таблица 1

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

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

Таблица 2

Использование должностей при описании бизнес процесса

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

·  администратор;

·  пользователь;

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

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

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

·  исполняет (executive) - непосредственно участвует в выполнении действия, причем, если есть несколько исполнителей, то подразумевается, что они взаимозаменяемы и каждый может выполнить действие самостоятельно;

·  утверждает результат - обычно руководящие должности;

· вносит вклад в (contributes to) - непосредственно участвует в исполнении, но, в отличие от исполнения (executive), предполагается обязательное участие всех исполнителей (при отсутствии одного из них функция не выполняется, так как исполнители не взаимозаменяемы, например, для переноса холодильника нужны два грузчика: оба выполняют одну и ту же функцию, но один не сможет выполнить эту функцию без другого);

·  отвечает за ИТ обеспечение - например, системный администратор.

·  консультирует - такой тип связи присутствует при участии внешних консультантов.

·  и др.

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

2.5.   Информационные ресурсы

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

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

Рисунок 7 - Классификация информации

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

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

2.6.   Продукты и услуги

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

2.7.  ПОТОКИ

Представляя однородные элементы процесса в последовательности, получаем потоки:

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

·  информационный поток - показывает перемещение таких объектов как бумажные документы, файлы, записи баз данных и т.д.

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

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

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

2.8.   Уровни описания процессов (декомпозиция)

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

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

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

Каждая из методик моделирования имеет право на существование, а также свои достоинства и недостатки.

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

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

Что же представляет собой многоуровневое моделирование бизнес-процессов? Функция (одно действие) процесса может представлять собой отдельный процесс и раскрываться уровнем ниже в виде отдельного процесса состоящего из нескольких операций (см. Рис. 8).

Рисунок 8 - Декомпозиция

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

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

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

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

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

Анализ проблем бизнеса:

·  по направлениям;

·  по подразделениям;

·  внутри подразделении;

·  на рабочих местах.

Внедрение информационной системы:

·  формулировка требований;

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

·  описание реализации.

В данной Методике основное внимание уделяется описанию бизнес-процессов для анализа проблем управления и внедрению информационных систем на уровне формулировки требований.

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

Рисунок 9 - Диаграмма добавленной стоимости

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

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

3. ФОРМАТЫ И СРЕДСТВА ОПИСАНИЯ БИЗНЕС-ПРОЦЕССА

3.1.            Форматы описания бизнес-процессов

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

Таблица 3

Преимущества и недостатки форматов описания бизнес-процессов

Текстовый формат описания

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

Табличный формат описания

Для описания процесса в таблицах можно использовать следующий формат (см. Табл. 4).

Таблица 4

Табличный формат описания процесса

Графа «№» - показывает порядковый номер функции. Для описания декомпозиции процесса можно использовать разряды номера функции. Например, у функции №7 есть три подфункции, их номера начинаются с номера декомпозируемой функции: 7.1; 7.2; 7.3. Графа «Наименование функции» - включает название работы/ операции.

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

Графы «Ресурсы»  - включают всю совокупность используемых в процессе предметов и средств труда, а также документов.

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

Графические форматы описания

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

IDEF (Integration Definition for Function Modeling - методология функционального моделирования) - семейство совместно используемых методов для процесса моделирования. Первоначально разработаны в военных ведомствах США. На сегодня эта техника описания бизнес-процессов получила наибольшее распространение в мире и принята как стандарт во многих странах. В России на момент написания Методики это зафиксировано в Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования», а также в проекте стандарта: ГОСТ Р ИСО 10303-203 «Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен данными. Протокол применения 203 - Проектирование изделия управляемой конфигурации". Концепция реализована во многих программных продуктах, наиболее популярным из которых на сегодняшний день является пакет ВР WIN/ER WIN.

UML (Unified Modeling Language - унифицированный язык моделирования) – наиболее систематизированный подход к описанию любых систем, в т.ч. и бизнес-процессов. Позволяет перейти от описаний системы непосредственно к написанию компьютерных программ и - в значительной степени - сформировать основу будущего средства автоматизации. UML принят как стандарт для проектирования информационных систем более чем 60-ю ведущими разработчиками программного обеспечения, в т. ч и Microsoft. Разработчик языка - некоммерческий консорциум Object Managment Group (ОМС). Наиболее популярным инструментом, поддерживающими язык UML, является Rational

АRIS (ARchetecture of Information Systems - проектирование интегрированных информационных систем) - германская технология описания предприятий. Разработана профессором Августом Вильгельмом Шеером (компания IDE Scheer АС). Используется как встроенное средство в одну из крупнейших на сегодняшний день систем автоматизации предприятий - SAP R/3. Пока имеет меньшее распространение, чем вышеперечисленные системы. При этом единственная методология, где фирма-разработчик является и производителем одноименного программного продукта, поддерживающего данную методологию. Этим обеспечивается практически единовременное совершенствование методологии и программной поддержки.

3.2.            IDEF

Рассмотрим концепцию IDEF как более простой и доступной в виде большого числа программных продуктов, поддерживающих эту концепцию (BPWIN, БИГ-Мастер, МS Visio и др.).

IDEF технология используется, начиная с конца 1980-х годов. Department of Defence USA (Министерство обороны США) является основным пользователем данной технологии. Ею пользуются также некоторые крупные корпорации в США.

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

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

• Верхняя сторона - управление;

• Нижняя сторона - механизмы (ресурсы);

• Левая сторона - входы;

• Правая сторона - выходы.

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

Рисунок 10 - Графическое представление процесса в IDEFO (сделано в МS Visio ХР)

Стрелками управления могут быть документы, регламентирующие деятельность (стандарты, технические условия и т.п.) Входами, выходами и механизмами могут быть различные ресурсы: люди, станки, материалы, сырье, документы, базы данных и т. п. (см. Рис. 11).

Рисунок 11 - Пример блока IDEF диаграммы

Функции IDEF могут детализироваться в отдельных схемах, это называется декомпозиция. На самом верхнем уровне это может быть все предприятие, отраженное как один блок, а далее - в отдельной схеме - будут раскрыты различные процессы. Декомпозиция обозначается под блоком процесса с правой стороны в виде номера схемы детализации. В отличие от номера блока, расположенного внутри прямоугольного блока функции, номер схемы детализации находится снаружи прямоугольника (рис. 12). На рисунке номер схемы декомпозиции «АО». Уровень вложенности процессов не ограничивается.

Рисунок 12 - Декомпозиция процесса в IDEF

Пример процесса в формате IDEF (см. Рис. 13). Надписи на стрелках сделаны выносками в форме молний.

Рисунок 13 - Пример процесса в формате IDEF

Задание к работе

1.      Законспектируйте теоретическую часть.

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

3.      Проанализировать процесс управления бизнес-процессом «N». Для чего:

а.       Идентифицировать бизнес-процессы описывающие определенную задачу.

б.      Оценить приоритетность бизнес-процессов

в.      Определить ключевые факторы успеха предприятия (КФУ)

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

д.      Оценить важность бизнес-процессов.

е.       Оценить степень проблемности бизнес-процессов.

ж.     Разработать матрицу ранжирования бизнес-процессов.

з.       Оценить возможность проведения изменений в бизнес-процессе.

и.      Провести ранжирование и выбрать приоритетные бизнес-процессы.

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

4.      Оценить эффективность управления бизнес-процессом «N».

5.