Файл: Применение процессного подхода для оптимизации бизнес-процессов (Понятие процессного подхода к управлению предприятием).pdf

Следующим этапом развития графического языка описания функциональных систем SADTсчитаютметодологию IDEF0, которая исторически была разработана в 1981 году в ходекрупной программы автоматизации промышленных предприятий. Данная программа носила название ICAM (IntegratedComputerAidedManufacturing) и была предложена департаментом Военно-Воздушных Сил США.

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

В процессе поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений. В основном эти изменения носили ограничивающий характер. Последняя редакция стандарта была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

На сегодняшний момент IDEF0 является независимым от частных организаций стандартом,он получил достаточно широкое распространение ипринят в качестве стандарта в нескольких международных организациях, в том числе в НАТО и МВФ.

Методология IDEF0 успешно применяется в самых различных отраслях, проявив себя как эффективное средство анализа, проектирования и представления деловых бизнес-процессов. В настоящее время методология IDEF0 широко используется не только в США, но и во всем мире. В России IDEF0 успешно применяется в государственных учреждениях (к примеру, в Государственной Налоговой Инспекции), в аэрокосмической промышленности (при проектировании космодрома в Плесецке), в Центральном Банке и коммерческих банках России, на предприятиях нефтегазовой промышленности и предприятиях других отраслей [3].

Следующая методология ARIS, разработанная специалистами немецкой компании IDS Scheer AG, базируетсяна том, что любая организация рассматривается как единая система, описание которой предусматривает четыре основные группы моделей:

- модели организационной структуры;

- модели данных (потоки и структура);

- модели функций (функциональные иерархии);

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

Архитектура ARIS включает достаточное количество типов моделей, которые используют различные графические объекты для построения разноплановых моделей организации. Большинством предприятий на практике применяется ограниченное число нотаций архитектуры ARIS, например популярная нотация eEPC, которая является расширением методологии IDEF3 за счет использования такого понятия, как событие (Event). Кроме нотации eEPC, ARIS предоставляет аналитику и многие другие средства описания процессов организации.

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

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

UML имеет четырехуровневую архитектуру:

- мета-метамодель;

- метамодель;

- модель;

- пользовательские объекты.

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

1.3 Основные принципы моделирования бизнес-процессов

Современная методология IDEF0 предоставляет аналитику достаточно широкие возможности для описания бизнеса компании на верхнем уровне. Данная нотация позволяет отражать в модели процессов обратные связи различного рода – по управлению, информации, движению материальных ресурсов и др.В IDEF0 существуют удобные механизмы декомпозиции каждой модели процессов.Следует,однако, отметить, что модели в данной нотации предназначены для высокоуровневого описания бизнес-процессов компании. Их главное преимущество состоит в возможности описывать управление процессами. Графический язык нотации IDEF0 достаточно прост и понятен, отличается гармоничностью. В основе методологии IDEF0 лежат четыре основных понятия [7].

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

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

Рисунок 2 – Функциональный блок

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

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

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

Рассмотрим смысловое значение интерфейсных дуг:

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

- управление (Control) – это правила, процедуры, стратегии или стандарты, которыми руководствуется процесс;

- выход (Output) – это материал или информация, производимые процессом;

- механизм (Mechanism) – это ресурсы, которые необходимы для выполнения работы, например станки, персонал, устройства и т.д.

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

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

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

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

Модель в нотации IDEF0 начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, показывающими связь системы с внешней средой. Такая диаграмма называется контекстной и обозначается в модели идентификатором «А-0». Контекстная диаграмма определяет границы моделирования [9].

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

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

В процессе декомпозиции модели, функциональный блок, который на контекстной диаграмме показывает рассматриваемую систему как единое целое, подвергается детализации на нижележащей диаграмме. В этом случае получается диаграмма второго уровня, которая содержит функциональные блоки, отображающие основные подпроцессы функционального блока контекстной диаграммы. Такая диаграмма называется дочерней (Childdiagram) по отношению к вышестоящему блоку. В свою очередь, функциональный блок-предок называется родительским блоком по отношению к дочерней диаграмме (ParentBox), а диаграмма, к которой он принадлежит – родительской диаграммой (ParentDiagram)[3].

Рисунок 3 – Декомпозиция функциональных блоков

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

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

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

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

2.1. Построение модели в системе AllFusionProcessModeler

Моделирование бизнес-процессов, как правило, выполняется с помощью Case-средств. К таким средствам относятся BPwin (PLATINUMtechnology) или новая версия AllFusionProcessModeler, Silverrun (Silverruntechnology), Oracle Designer (Oracle), RationalRose (RationalSoftware), Aris, Business Studio и др.

Рассмотрим программную систему AllFusionProcessModeler.

AllFusionProcessModeler имеет достаточно простой и интуитивно понятный для пользователяинтерфейс.

AllFusionProcessModeler поддерживает три методологии моделирования - IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В AllFusionProcessModeler возможно построение смешанных моделей, т.е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD.