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

Американский ученый У. Шухарт впервые описал систему PDCA в 1938 г. в книге «Статистические методы и управление качеством». У. Деминг предлагал использовать PDCA в качестве основного метода достижения НУП. Им же введена модификация цикла PDCA – цикл PDSA (от слова «study» – изучать) [4].

Цикл PDCA в себя включает:

– планирование (plan) – установление процессов и целей, необходимых для достижения эффекта, распределение необходимых ресурсов;

– выполнение (do) – осуществление разного рода запланированных мероприятий;

– проверка (check) – это сбор информации, а также контроль результата и анализ отклонений;

– воздействие (act) – это принятие мер для устранения причин отклонений от планированного результата.

На рисунке 2 приведен пример БП, управляемого на основании цикла PDCA.

Циклы управления БП отражают методику управления процессами организации, а непосредственно технологию управления БП определяет метод BPM.

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

Рис.2. Цикл Шухарта - Деминга

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

Системный подход позволяет:

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

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

– обеспечить понимание всех взаимосвязей между процессами указанной системы;

– проводить непрерывное совершенствование систем посредством измерения их и оценки;

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

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

2.1. Инструментальные системы моделирования бизнес-процессов

В России для анализа и моделирования БП достаточно широко используются средства моделирования [12]:

– Oracle Designer;

– Rational Rose;

– АllFusion Data Modeler;

– AllFusion Process Modeler;

– ARIS.

Зарубежом, помимоужеупомянутых, активноприменяютсясредстваIthink Analyst, System Architect, ReThinkипрочие.

АllFusionDataModeler и AllFusionProcessModeler (BPWin и ERWin) компании СоmputerAssociates входят в пятерку ведущих производителей ПО, предлагая средства резервного копирования, моделирования, управления инфраструктурой предприятия, информационной безопасности и т.д. Пакет BPWin базируется на методологии IDEF, а также предназначен для процесса функционального моделирования, анализа деятельности предприятия [16]:

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

Функциональная модель IDEF может отображать функциональную структуру объекта, то есть производимые им действия, связи между этими процессами.

Основными характеристиками для указанной модели являются:

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

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

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

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

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

Вход должен иметь всегда своего поставщика. К типичным входам процесса относятся:

– сырье;

– документация;

– материалы;

– персонал;

– полуфабрикаты;

– информация;

– услуги и т.п.

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

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

– готовая продукция;

– документация;

– информация;

– персонал;

– услуги и т.п.

Ресурс бизнес-процесса – это информационный или материальный объект, постоянно используемый при выполнении процесса, но не считается входом.

К ресурсам процесса относятся [11]:

– информация;

– оборудование;

– персонал;

– инфраструктура;

– программное обеспечение;

– транспорт;

– среда;

– связь и пр.

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

2.2. Нотации моделирования БП

На основе методологии SADT разработана методология IDEF0. Она была утверждена как федеральный стандарт США в 1992 г.

Методологию IDEF0 считают следующим этапом развития известного графического языка для описания функциональных систем под названием SADT.

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

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

Для удовлетворения этих потребностей в рамках ICAM была разработана специальная методология IDEF (от словосочетания ICAM Definition), позволяющая выполнить исследование структуры, параметров и характеристик производственно-технических или организационно-экономических систем[13].

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

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

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

При передаче информации о конкретной системе некоторым источником графического языка считается сама методология IDEF0.

Методология IDEF0 предписывает построение специальной иерархической системы под названием «диаграмма - единичное описание фрагментов системы» [2].

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

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

В основе данной методологии лежат 4 основных понятия [3]:

– функциональный блок;

– декомпозиция;

– интерфейсная дуга;

– глоссарий.

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

На диаграмме (рисунок 3) функциональный блок изображается в качестве прямоугольника [19].

Каждая из 4-х сторон функционального блока использует свое определенное значение (или роль), а также:

– верхняя сторона – "Управление";

– левая сторона – "Вход";

– правая сторона – "Выход";

– нижняя сторона – "Механизм".

Рис.3. Схема контекстной диаграммы

Интерфейсная дуга отображает элемент системы. Он обрабатывается функциональным блоком и оказывает иное влияние на функции, представленные данным функциональным блоком [17].

Такие интерфейсные дуги часто называются потоками или же стрелками.

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

Такими объектами считаются элементы реального мира (вагоны, детали, сотрудники и т.п.) или потоки информации (данные, документы, инструкции и т.п.).

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

– "входящей";

– "исходящей";

– "управляющей".

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

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

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

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

Нотация поддерживает лишь определенный набор концепций, необходимый для моделирования БП.

Моделирование иных аспектов, кроме БП, находится вне зоны действия BPMN.

К примеру, моделирование следующих аспектов не будет описываться в BPMN[1]:

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

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

При этом выделяют 4 основные категории компонентов:

– объекты потока управления, а именно действия, логические операторы, события;

– соединяющие объекты: поток сообщений, ассоциации, поток управления.

– роли: дорожки и пулы;

– артефакты: группы. текстовые аннотации, данные.

Элементы этих категорий позволяют выполнять построение простейшие диаграммы БП.

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