Файл: Применение процессного подхода для оптимизации бизнес-процессов.pdf
Добавлен: 06.04.2023
Просмотров: 81
Скачиваний: 2
СОДЕРЖАНИЕ
Глава 1. Понятие процессного подхода в управлении
1.1. Предназначение бизнес-процессов, основные определения и классификация
1.2. Инструментальные системы моделирования бизнес-процессов
Глава 2. Методологии моделирования бизнес-процессов
2.1. Моделирование в нотации IDEF
2.2. Моделирование в нотации BPMN
Методология IDEF, являющаяся официальным стандартом США, представляется совокупностью методов, правил или процедур, предназначенных для реализации функциональной модели объекта предметной области.
Функциональная модель IDEF может отображать функциональную структуру объекта, то есть производимые им действия, связи между этими процессами.
Основными характеристиками для указанной модели являются:
– Владелец процесса – должностное лицо или коллегиальный орган управления, имеющий в своем распоряжении некоторые ресурсы, необходимые при выполнении процесса, и несущий всю ответственность за результат некоторого процесса.
Владелец БП ведет управление процессом, а также является неотъемлемой частью процесса. В дальнейшем построения БД будут основываться на такой схеме взаимодействия процессов и его владельцев.
– Процессы – потоки работы, у них есть границы, другими словами, как начало, так и конец. Для практически любого отдельно взятого процесса такие границы установлены начальными, первичными, входами, для которых он начинается.
Указанные входы открываются только первичными поставщиками процесса. Процессы заканчиваются выходом, который выдает результаты первичным клиентам процесса.
– Входы бизнес-процесса – это продукт, который при выполнении процесса преобразуется непосредственно в выход.
Вход должен иметь всегда своего поставщика. К типичным входам процесса относятся:
– сырье;
– документация;
– материалы;
– персонал;
– полуфабрикаты;
– информация;
– услуги и т.п.
– Выход (продукт) – это информационный или материальный объект или услуга, которая является результатом выполнения некоторого процесса и потребляемый разными внешними по отношению к БП клиентами.
Выход процесса всегда имеет своего потребителя. В случае, когда потребителем является иной процесс, для него данный выход является входом. Отметим, что выход (продукт) процесса может также использоваться в качестве некоторого ресурса при выполнении следующего процесса. К выходам процессов могут относиться [35]:
– готовая продукция;
– документация;
– информация;
– персонал;
– услуги и т.п.
Ресурс бизнес-процесса – это информационный или материальный объект, постоянно используемый при выполнении процесса, но не считается входом.
К ресурсам процесса относятся [40]:
– информация;
– оборудование;
– персонал;
– инфраструктура;
– программное обеспечение;
– транспорт;
– среда;
– связь и пр.
Владелец процесса при его планировании и управлении производит распределение или перераспределение ресурсов для достижения самого лучшего результата.
Принадлежность информации одновременно и к входам, и к ресурсам процесса не считается ошибкой.
Выходы, входы, ресурсы обозначаются существительными, поскольку они являются разного рода материальными объектами.
Окно программы показано на рисунке 1:
Рисунок 1 – Окно АllFusion Data Modeler
Основные возможности BPwin:
– поддерживает три стандартные нотации: IDEF0, DFD и IDEF3. Эти 3 основных ракурса позволяют описать предметную область наиболее точно и комплексно;
– позволяет выполнять оптимизацию процедуры в компании;
– поддерживает методы расчета себестоимости хозяйственной деятельности;
– интегрирован с ERwin, Paradigm Plus и др.;
– интегрирован с средством имитационного моделирования под названием Arena;
– содержит собственный генератор для отчетов.
Набор инструментальных средств под названием Oracle Designer предлагает решение для разработки систем корпоративного уровня для веб и клиент-серверных приложений [4].
Oracle Designer участвует практически в каждой фазе ЖЦ разработки ПО – от моделирования БП до внедрения. Применение репозитория, делает возможным применение любых его компонентов для быстрой разработки кросс-платформных, масштабируемых распределенных приложений.
Основной задачей Oracle Designer является выполнение сбора данных о потребностях разных пользователей и автоматизация гибких графических приложений.
Окно Oracle Designer показано на рисунке 2:
Рисунок 2 – Окно Oracle Designer
Oracle Designer используется не лишь для создания приложений, но и для ведения учета изменений, неизбежно происходящих при внедрении системы. Графические модели для определений проекта, интегрированные с репозиторием существенно облегчают взаимодействие с Oracle Designer[7].
В настоящее время наблюдается тенденция к интеграции разнообразных методов для анализа и моделирования систем, проявляющаяся в формах создания интегрированных средств для моделирования. Одним из таких средств является программный продукт ARIS, разработанный германской компанией IDS Scheer.
Методика проектирования ARIS основывается на ранее разработанной профессором А. Шером теории интегрированных ИС, определяющей основные принципы визуального отображения аспектов функционирования компаний.
ARIS поддерживает 4 типа моделей,отражающие различные аспекты системы. Интерфейс системы показан на рисунке 3:
Рисунок 3 – Окно системы ARIS
Система ARIS представляет комплекс средств моделирования и анализа деятельности предприятия.
В процессе написания первой главы ВКР рассмотрены основные определения теории моделирования бизнес-процессов, главных принципов процессного подхода для управления организацией, дана подробная характеристика понятия управления процессами, описаны самые популярные примеры инструментального ПО для моделирования БП.
Глава 2. Методологии моделирования бизнес-процессов
2.1. Моделирование в нотации IDEF
На основе методологии SADT разработана методология IDEF0. Она была утверждена как федеральный стандарт США в 1992 г.
Методологию IDEF0 считают следующим этапом развития известного графического языка для описания функциональных систем под названием SADT.
Исторически IDEF0 был разработан как стандарт в 1981 г. в рамках обширной исследовательской программы, когда ВВС предложили и реализовали программы интегрированной компьютеризации производства под названием ICAM,направленную на возрастание эффективности промышленных предприятий с помощью широкого внедрения компьютерных технологий 8].
Реализация программы ICAM требовала создания адекватных способов анализа, проектирования производственных систем, а также способов обмена данными между специалистами.
Для удовлетворения этих потребностей в рамках ICAM была разработана специальная методология IDEF (от словосочетания ICAM Definition), позволяющая выполнить исследование структуры, параметров и характеристик производственно-технических или организационно-экономических систем[31].
Для этого широта и глубина практического обследования процессов в системах определяется самим разработчиком, а это позволяет не перегружать созданную модель излишними данными.
Описание системы при помощи IDEF0 называется функциональной моделью.
Каждая функциональная модель используется для описания существующих БП, в котором используются естественный и графический языки.
При передаче информации о конкретной системе некоторым источником графического языка считается сама методология IDEF0.
Методология IDEF0 предписывает построение специальной иерархической системы под названием «диаграмма - единичное описание фрагментов системы»[2].
Сначала выполняется описание системы в целом, ее взаимодействия с внешней средой (контекстная диаграмма), далее проводится функциональная декомпозиция, то есть система разбивается несколько подсистем, и каждая подсистема может описываться отдельно (диаграммы декомпозиции).
Потом каждая подсистема разбивается далее на более мелкие до достижения нужного уровня подробности и однозначности моделирования системы.
В основе данной методологии лежат 4 основных понятия [3]:
– функциональный блок;
– декомпозиция;
– интерфейсная дуга;
– глоссарий.
Функциональный блок (англ. Activity Box) представляется некоторой конкретной функцией в рамках рассматриваемой моделируемой системы. По требованиям стандартов название каждого такого функционального блока должно формулироваться в глагольном наклонении (к примеру, «производить услуги»).
На диаграмме (рисунок 4) функциональный блок изображается в качестве прямоугольника[19].
Каждая из 4-х сторон функционального блока использует свое определенное значение (или роль), а также:
– верхняя сторона – "Управление";
– левая сторона – "Вход";
– правая сторона – "Выход";
– нижняя сторона – "Механизм".
Рисунок 4 – Схема контекстной диаграммы
Интерфейсная дуга отображает элемент системы. Он обрабатывается функциональным блоком и оказывает иное влияние на функции, представленные данным функциональным блоком [17].
Такие интерфейсные дуги часто называются потоками или же стрелками.
При помощи интерфейсных дуг отображаются различные объекты, в разной степени определяющие процессы системы.
Такими объектами считаются элементы реального мира (вагоны, детали, сотрудники и т.п.) или потоки информации (данные, документы, инструкции и т.п.).
В зависимости от того, с каких сторон функционального блока будет подходить данная интерфейсная дуга, ее можно назвать:
– "входящей";
– "исходящей";
– "управляющей".
Надо отметить, что каждый функциональный блок по существующим требованиям стандарта имеет, по крайней мере только управляющую интерфейсную дугу.
Это вполне понятно – каждый из процессов должен происходить по правилам (отображаемым хотя бы одной управляющей дугой), должен выдавать результат (выходящая дуга), по другому его рассмотрение не будет иметь никакого смысла.
Обязательное наличие таких управляющих интерфейсных дуг считается одним из основных отличий стандарта IDEF0 от иных методологий классов DFD и WFD.
Декомпозиция является главным понятием стандарта IDEF. Принцип декомпозиции применяется в разбиении сложного процесса на компоненты его функции. Также уровень детализации процесса может определяться непосредственно разработчиком.
Декомпозиция позволяет структурировано и постепенно представлять модель системы с помощью иерархической структуры, что и делает ее легко усваиваемой[6].
Последним из понятий нотации IDEF0 является глоссарий. Для каждого с элементов IDEF0, функциональных блоков, диаграмм, интерфейсных дуг, рассматриваемый стандарт подразумевает поддержание и создание набора соответствующих определений, изложений,ключевых слов и т.д., что характеризуют объект, который отображен данным элементом. Указанный набор называется глоссарием, а также является описанием сущности элемента.
Глоссарий дополняет гармонично наглядный графический язык, при этом снабжая диаграммы самой необходимой информацией[9].
Функциональные блоки на диаграммах изображаются в виде прямоугольников, означающими поименованные процессы, задачи или функции, которые происходят в течение некоторого определенного времени и имеют результаты.
IDEF0 требует, чтобы в диаграммах было не менее 3 и не более 6 блоков. Эти ограничения также поддерживают сложность диаграмм, модели на уровне, который доступен для чтения, а также понимания и использования[18].
В IDEF0 различают 5 типов стрелок:
– Вход – это объекты, преобразуемые и используемые работой для получения выхода. Допускается, что работа не имеет ни одной стрелки для входа.
– Управление – это информация, управляющая разными действиями работы. Обычно такие управляющие стрелки несут данные, которые указывают, что должна выполнять конкретная работа.
– Выход – это объекты, в которые будут преобразовываться входы. Каждая из работ должна иметь хотя бы 1 стрелку выхода, что рисуется как исходящая с правой грани.
– Механизм – это ресурсы, выполняющие указанную работу. Стрелка механизма может быть нарисована как входящаяв нижнюю грань работы.
– Вызов – это специальная стрелка, что указывает на другую модель блока. Стрелка вызова рисуется исходящей из нижней части блока и используется для указания некоторой работы за пределами моделируемой системы.