Лекции по "Бизнес планирование"

Если ПЭО  считает заказ выполнимым, то проводится детальный расчет себестоимости выполнения и определяется его цена. Определяются возможные сроки выполнения заказа (функция «Рассчитать себестоимость, цену и возможные сроки выполнения заказа»). Далее указанные выше расчетные цифры согласовываются с клиентом – выполняется функция «Согласовать условия поставки с клиентом». Снова возможны два варианта – используется оператор логического «исключающего ИЛИ». В случае если клиента не устраиваю финансовые условия, он отказывается от заказа, а мы вносим этот заказ в статистику неудовлетворенного спроса (нижняя ветка процесса). Если клиент готов работать на наших условиях, то процесс заканчивается. Выходом процесса служит «Согласованная заявка клиента» и данные по рассчитанным параметрам заказа (на схеме процесса не показаны).

Обратим внимание, что данный процесс в учебном Блоке 2.3 приводится в виде модели в нотации ARIS eEPC (Рис. 2.3.8), для сравнения возможностей двух нотаций по описанию одного и того же процесса. Также для сравнения способов представления одной и той же информации о процессе, в разделе 3.2 данного блока этот процесс изображен с разделением по зонам ответственности и видам объектов в нотации ARIS PCD (Process Chain Diagram).  

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

Методология DFD

Важнейшим способом описания бизнес-процесса являются диаграммы потоков данных (информации) DFD (Data Flow diagram). Диаграммы этого типа содержат, как правило, два типа графических объектов: четырехугольники и стрелки. Первые описывают функции (работы, процессы), вторые – потоки данных между этими функциями. Простейшая схема процесса в формате DFD показана на следующем рисунке.

Рис. 2.2.2. Схема  процесса в нотации DFD

 

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

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

 

Рис. 2.2.3. Модель процесса в нотации DFD

 

Для чего служат нотации DFD? В первую очередь они нужны для описания реально существующих в организации потоков данных. Описания могут создаваться как по процессному, так и по функциональному признаку. В первом случае мы получаем модели бизнес-процессов в формате DFD, во втором случае – схему обмена данными между подразделениями [2]. Созданные модели потоков данных организации могут быть использованы при решении таких задач, как:

5. определение существующих хранилищ данных (текстовые документы, файлы, СУБД);
6. определение и анализ данных, необходимых для выполнения каждой функции процесса;
7. подготовка к созданию модели структуры данных организации;
8. выделение основных и вспомогательных бизнес-процессов организации.

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

 

Рис. 2.2.4. Отображение  потоков данных и материальных потоков  с помощью нотации DFD.

 

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

Другие  методологии описания бизнес-процессов

Описание процессов при помощи блок-схем

 

Простейшим, но практически важным, способом описания бизнес-процессов является методика составления блок-схем. Данный подход имеет много общего с графическими языками описания алгоритмов программного обеспечения. С точки зрения методологии, формирование блок-схем проводится так же, как в нотации IDEF3, хотя для упрощения символы логики могут опускаться. Для разработки блок-схем могут быть использованы стандартные офисные программные продукты, например MS Word или Visio. Основные графические объекты языка описания процессов при помощи блок-схем представлены в следующей таблице 2.2.2.

 

Таблица 2.2.2. Графические  объекты блок-схемы процесса.

 

Пример описания процесса при помощи блок-схем представлен  на следующем рисунке 2.2.5.

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

 

 

Рис. 2.2.5. Пример блок-схемы процесса.

 

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

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

Диаграммы класса Swim Lane

Диаграммы класса Swim Lane строятся по классификации блоков и/или признакам ответственности за выполнение функций (работ). Поле диаграммы разделяется по горизонтали и/или вертикали на параллельные «плавательные дорожки» (отсюда и название диаграммы). Блоки функций располагаются по зонам ответственности (дорожкам). Последовательность выполнения работ отображается стрелками-связями между ними. Такая диаграмма позволяет однозначно распределить ответственность за выполнение функций и оценить степень загрузки каждого ответственного. Диаграммы класса Swim Lane строятся в программных продуктах BPWin 4.0 (DFD) и ARIS Toolset (ARIS PCD) [4]. На следующем рисунке 2.2.6 приведен пример построения диаграммы Swim Lane в нотации ARIS PCD.

 

Рис. 2.2.6. PCD диаграмма процесса «Обработка заявки клиента».

 

На рис. 2.2.6 описан то же процесс «Обработка заявки клиента», что и на рис 2.2.1 в методологии IDEF3 но объекты расположены в виде столбцов таблицы. В первом столбце расположены события и некоторые символы логики, во втором – функции, в третьем – входящие и исходящие документы, в четвертом – виды прикладного программного обеспечения, в пятом – должности, задействованные в процессе. Такое представление процесса лучше подходит для целей документирования процессов. Однако представление PCD обладает существенным недостатком – его можно эффективно применять для простых (не более 5-8 функций), желательно линейных процессов. Сложные процессы с разветвленной логикой отображать при помощи PCD неудобно, что наглядно видно на рисунке 2.2.6.

На следующем  рисунке 2.2.7 изображена часть диаграммы Swim Lane, нарисованная с помощью MS Word. Такие диаграммы удобны для документирования простых рабочих операции, которые охватывают деятельность нескольких различных подразделений. На это следует обратить внимание, поскольку подавляющее количество процессов при их выполнении пресекает границы функциональных подразделений. Как правило, до 85% проблем возникает на стыках функциональных подразделений из-за несогласованности взаимодействий между функциональными подразделениями. Подробнее вопросы межфункционального взаимодействия будут рассмотрены в учебном Модуле 3.

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

Рис. 2.2.7 Swim Lane диаграмма для «Инструкции по приемке товара» Оператора системы в торгово-закупочной организации.

 

 

 

 

   
Методология проектирования бизнес-процессов ARIS

Общая структура методологии ARIS

 

В данном учебном  блоке мы рассмотрим методологию ARIS (Architecture of Integrated Information Systems – Архитектура Интегрированных Информационных систем). Методология разработана в компании IDS Scheer AG, Германия. В настоящее время на рынке инструментальных средств моделирования бизнес-процессов представлено одноименное ПО ARIS, включающее такие модули, как: ARIS Easy Design, ARIS Toolset, ARIS Server и др. [1].

Методология ARIS включает в себя несколько различных нотаций для описания деятельности организации с различных точек зрения. В методологию были интегрированы существующие стандарты и спецификации описания процессов и данных, например: IDEF3, ERD, DFD, UML и т.д. Основная концепция ARIS по описанию организации показана на следующем рисунке 2.3.1.

 

Рис. 2.3.1 «Домик ARIS»

 

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

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

• нотация Value-added chain diagram (диаграмма цепочки процесса, добавляющего стоимость);
• нотации extended Event-driven Process Chain – eEPC (расширенная нотация цепочки процесса, управляемого событиями) и PCD (диаграмма цепочки процесса);
• нотация Organizational chart (организационная диаграмма);
• нотация Function tree (дерево функций);
• нотация Product tree (дерево продуктов).

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

А) для своей реализации требуют наличия инструментальной среды ARIS Toolset, которая является дорогостоящей и достаточно сложной в использовании;

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

2. Нотация Value-added chain diagram (VAD)

 

На следующем рисунке представлена одна из важнейших нотаций ARIS – нотация Value-added chain diagram. Диаграмма цепочки процесса, добавляющего стоимость, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, использующие ARIS, рекомендуют выделять 6-8 бизнес-процессов верхнего уровня и описывать их в нотации VAD. Затем проводится декомпозиция полученных процессов верхнего уровня, при этом используется либо нотация VAD, либо eEPC. Рассмотрим основные объекты нотации VAD, представленные на рисунке 2.3.2.

Основным объектом нотации VAD является объект «Value added chain». Фактически это процесс или некоторая группа функций организации, которая служит для получения добавленной стоимости. Объекты соединяются между собой пунктирной стрелкой, которая имеет тип «is predecessor of» - «является предшественником». Этот тип связи показывает, что один процесс является предшественником другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные связи. Поэтому термин «is predecessor of», на наш взгляд, является неудачным.

Рис. 2.3.2. Внешний вид  бизнес-процесса, описанного в нотации Value-added chain diagram (VAD).