Назовите нестандартизированные концепции моделирования бизнес процессов - Контакты компаний и предприятий на Atlaso.ru

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

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

Мы привели в пример самый безобидный кейс, но принцип понятен. Чтобы вы не остались у разбитого корыта после автоматизации, мы составили пошаговый план и правила моделирования бизнес-процессов – так, как их видит команда Forward Telecom.

ВИДЫ МОДЕЛИРОВАНИЯ

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

Функциональное. Модель бизнес-процесса состоит из диаграмм, текста и глоссария. Каждый элемент может ссылаться на другой. Основа модели – диаграммы, которые отображают последовательность функций, связанных общими объектами. Плюсы функционального моделирования в графической простоте, потому что оно базируется на двух элементах – функциональном блоке и интерфейсной дуге, которая связывает блоки между собой.
Процессное. Ключевой принцип – отображение последовательности. Определяется цепочка совокупности бизнес-процессов, которые увеличивают конечную стоимость услуг или товаров. Процессное моделирование лежит в основе популярных нотаций IDEF3, DFD и ARIS, о которых мы поговорим позже.
Ментальное. . Этим типом моделирования владеет каждый из нас. Под ним подразумеваются графические наброски схем в свободной форме, которые помогают структурировать и упорядочить спутанные представления о бизнес-процессах и делаются в основном «для себя».

ЭТАПЫ МОДЕЛИРОВАНИЯ

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

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

Как это сделать на практике? Разберем на примере моделирования бизнес-процесса согласования счета на оплату финансовым директором.

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

В результате моделирование бизнес-процессов должно наполнить полученные модели следующей информацией:

Набор бизнес-функций;
Порядок выполнения;
Принципы контроля и управления в рамках бизнес-процесса;
Исполнители
Входящие и исходящие документы;
Ресурсы;
Документация или условия, регламентирующие выполнение бизнес-функции;
Общая характеристика процесса.

Информация в модели может варьироваться в зависимости от используемой нотации.

НОТАЦИИ

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

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

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

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

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

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

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

РЕЗУЛЬТАТЫ

На выходе вы должны получить:

Процессную карту бизнес-процессов компании с их взаимосвязью;
Диаграмму ролей сотрудников;
Модель «как есть» каждого бизнес-процесса.

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

Источник

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

Эти методологии можно
представить в виде своего рода
промежуточного слоя между бизнесом и
ИТ. Гибридность же заключается в том,
что в условиях, например, диверсификации
бизнеса перед ИТ встают новые задачи
по ИТ-поддержке бизнеса, то есть развивать
ИТ в компаниях нужно в том же темпе, в
котором развивается бизнес. Таким
образом, в этих методологиях представлено
одновременное сочетание сервисного
подхода с проектным. Рассмотрим кратко
две наиболее популярные методологии:
IDEF0 и ARIS.

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

IDEF0
— методология и графическая нотация,
предназначенная для формализации и
описания бизнес-процессов. Методологию
IDEF0 можно считать следующим этапом
развития хорошо известного графического
языка описания функциональных систем
SADT (Structured Analysis and Design Teqnique).

Исторически IDEF0 как стандарт
был разработан в 1981 г. в рамках обширной
программы автоматизации промышленных
предприятий, которая носила обозначение
ICAM (Integrated Computer Aided Manufacturing) и была предложена
департаментом Военно-Воздушных Сил
США. Собственно семейство стандартов
IDEF унаследовало свое обозначение от
названия этой программы (IDEF — ICAM
DEFinition). Последняя его редакция была
выпущена в декабре 1993 г. Национальным
Институтом по Стандартам и Технологиям
США (NIST).

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

ARIS
(сокр. от англ. Architecture of Integrated Information
Systems) — методология и программный продукт
компании немецкой IDS Sheer для моделирования
бизнес-процессов компании. Методология
ARIS рассматривает предприятие как
совокупность четырех взглядов (views): на
организационную структуру, структуру
функций, структуру данных, структуру
процессов. При этом каждый из этих
взглядов разделяется еще на три подуровня:
описание требований, описание спецификации,
описание внедрения. Таким образом, ARIS
предлагает рассматривать организацию
с позиции 12 аспектов, отображающих
разные взгляды на предприятие, а также
разную глубину этих взглядов. Для
описания бизнес-процессов предлагается
использовать 85 типов моделей, каждая
из которых принадлежит тому или иному
аспекту.

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

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

В сущности, в основе
бизнес-модели корпорации лежат
описательные ответы на следующие моменты
(рис. 4.1):

— бизнес-функции описывают,
что делает бизнес;

— бизнес-процессы, описывают,
как предприятие выполняет свои бизнес
функции;

— организационная структура,
определяет, где исполняются бизнес-функции
и бизнес-процессы;

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

— роли, определяющие, кто
исполняет бизнес-процессы;

— правила, определяющие
связь что, как, где, когда и кто.

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

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

Как правило, в «доинформационную
эпоху» для этого использовались
графические средства в виде схем,
украшавшие стены кабинетов менеджеров,
в которых отражались «организационно-штатная
структура», «диаграммы потоков данных»
(ДПД или DFD — Data Flow Diagramming, предназначенные
для описания потоков данных), документооборот
компании. Эти «телодвижения» менеджеров
стали прообразом методик ДМД-моделирования,
входящих в семейство CASE-технологий
(computer aided software engineering) — компьютерное
проектирование программных систем.

Напомним основные элементы
и понятия IDEF0. В основе графического
языка методологии IDEF0 лежат четыре
основных понятия:

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

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

— верхняя сторона имеет
значение «Управление» (Control);

— левая сторона имеет значение
«Вход» (Input);

— правая сторона имеет
значение «Выход» (Output);

— нижняя сторона имеет
значение «Механизм» (Mechanism).

Каждый функциональный блок
в рамках единой рассматриваемой системы
должен иметь свой уникальный
идентификационный номер.

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

— материальные потоки
(детали, товары, сырье и т.д.);

— финансовые потоки (наличные
и безналичные, инвестиции и т.д.);

— потоки документов
(коммерческие, финансовые и организационные
документы);

— потоки информации (данные
о намерениях, устные распоряжения и
т.д.);

— ресурсы (сотрудники,
компьютеры, машины и т.д.).

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

— Что поступает в подразделение
«на входе»?

— Какие функции, и в какой
последовательности выполняются в рамках
подразделения?

— Кто является ответственным
за выполнение каждой из функций?

— Чем руководствуется
исполнитель при выполнении каждой из
функций?

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

Третьим основным понятием
стандарта IDEF0 является декомпозиция
(Decomposition). Принцип
декомпозиции
применяется при разбиении сложного
бизнес-процесса на составляющие его
функции. При этом уровень детализации
процесса определяется непосредственно
разработчиком модели. Декомпозиция
позволяет постепенно и структурированно
представлять модель бизнеса в виде
иерархической структуры отдельных
диаграмм, что делает ее менее перегруженной
и легко усваиваемой. Модель IDEF0 всегда
начинается с представления бизнеса как
единого целого — одного функционального
блока с интерфейсными дугами,
простирающимися за пределы рассматриваемой
области. Такая диаграмма с одним
функциональным блоком называется
контекстной диаграммой
и обозначается идентификатором «А-0».
В пояснительном тексте к контекстной
диаграмме должна быть указана цель
(Purpose) построения диаграммы в виде
краткого описания и зафиксирована точка
зрения (Viewpoint). Определение и формализация
цели разработки IDEF0-модели является
крайне важным моментом. Различные цели
моделирования предполагают разработку
и различных моделей бизнес-процессов,
то есть, например, цель «оптимизируем
финансовые потоки» приводит к другой
модели, нежели цель «оптимизируем
логистические цепочки». Точка зрения
определяет основное направление развития
модели и уровень необходимой детализации.
Четкое фиксирование точки зрения
позволяет разгрузить модель, отказавшись
от детализации и исследования отдельных
элементов, не являющихся необходимыми,
исходя из выбранной точки зрения на
моделирование бизнеса. Это и понятно,
так как точка зрения, допустим, финансового
директора предприятия может существенно
отличаться от точки зрения главного
технолога на одни и те же бизнес-процессы.
Правильный выбор точки зрения существенно
сокращает временные затраты на построение
конечной модели. В процессе декомпозиции
функциональный блок, который в контекстной
диаграмме отображает систему как единое
целое, подвергается детализации на
другой диаграмме. Получившаяся диаграмма
второго уровня содержит функциональные
блоки, отображающие главные подфункции
функционального блока контекстной
диаграммы и называется дочерней
(Child diagram) по отношению
к нему (каждый из функциональных блоков,
принадлежащих дочерней диаграмме,
соответственно называется дочерним
блоком — Child Box). В свою очередь,
функциональный блок — предок называется
родительским блоком
по отношению к дочерней диаграмме
(Parent Box), а диаграмма, к которой он
принадлежит —
родительской диаграммой
(Parent Diagram). Каждая из подфункций дочерней
диаграммы может быть далее детализирована
путем аналогичной декомпозиции
соответствующего ей функционального
блока. Важно отметить, что в каждом
случае декомпозиции функционального
блока все интерфейсные дуги, входящие
в данный блок или исходящие из него,
фиксируются на дочерней диаграмме. Этим
достигается структурная целостность
IDEF0-модели. Наглядно принцип декомпозиции
представлен на рис. 4.3

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

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

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

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

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

— Анализ бизнес-среды.

— Разработка стратегии
предприятия.

— Формирование общего видения
компании (глобальный уровень).

— Формирование детального
описания процессов компании «как есть»
и «как будет».

— Создание системы целей и
показателей для оценки эффективности
деятельности компании и отдельных
сотрудников.

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

— Описание требований к
информационным системам поддержки
деятельности.

— Проектирование интегрированных
информационных систем.

— Проведение документирования
результатов проекта.

— Проведение анализа
разработанных моделей (количественный
и сравнительный анализ, анализ семантики,
анализ стоимостных и временных
характеристик).

— Интеграция моделей с
функционирующими информационными
системами (актуализация организационной
структуры, номенклатуры, показателей).

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

Этапы процесса
реинжиниринга.
Реинжиниринг бизнес-процессов в целом
можно разделить на пять этапов.

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

Вторым этапом реинжиниринга
является стратегическое
планирование. Высшее
руководство определяет основные цели
реинжиниринга и назначает руководящий
комитет, для которого отбирает основные
объекты инновации и перепроектирования.
Эта группа играет ключевую роль как
«организатор процесса». Она отвечает
за создание внутренних рабочих групп
для проведения анализа реинжинирингового
процесса и составляет рекомендации для
перепроектирования и реструктурирования.
Высшее руководство и руководящий комитет
должны определить приоритетные
направления и последовательность
процедур реинжиниринга, основываясь
на сегодняшних и будущих потребностях.
После того как выбран проект, им следует
сформировать первоначальное стратегическое
направление. И здесь, прежде всего,
необходимо объяснить, как будут протекать
процессы в компании в будущем, насколько
они значимы, определить основные понятия
и ценности, ожидания новых и уже имеющихся
клиентов и т. д. Обоснование заканчивается
постановкой конкретных целей. Они должны
быть очень четко сформулированы.
Последнее, наиболее важное, на втором
этапе — это выбор
команды
перепроектирования в зависимости от
масштабности и комплексности изменении.
Размер группы может быть разным от 6 до
10 или от 12 до 25 человек. Основными
критериями отбора являются знания,
профессионализм и готовность выполнять
роль агентов изменений и инноваторов.

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

— изучение окружающей среды
потребителя,

— выявление требований
клиента,

— определение операциональных
требований,

— выбор проекта,

— проектные уточнения.

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

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

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

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

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

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

Реинжиниринг бизнес-процессов
предприятия проводится в соответствии
с такими этапами, как:

— Обследование предприятия.

— Идентификация бизнес-процессов
Клиента, оценка состава и объема работ.

— Разработка системы критериев
оценки бизнес-процессов.

— Подготовка проекта по
реинжинирингу бизнес-процессов Клиента.

— Моделирование существующих
бизнес-процессов и проведение их оценки.

— Моделирование бизнес-процессов.

— Документирование
бизнес-процессов.

— Анализ бизнес-процессов.

— Выработка рекомендаций
по оптимизации существующих.

— Подготовка
отчета по Этапу 2.

— Создание новой модели
бизнес-процессов.

— Перепроектирование
существующей модели бизнес-процессов.

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

— Документирование новых
бизнес-процессов.

— Формирование модели данных,
используемых в бизнес-процессах.

— Выработка рекомендаций
по внедрению новой модели бизнес-процессов.

— Подготовка
отчета по Этапу 3.

— Внедрение новой модели
бизнес-процессов

— Организация мероприятий
по изменению (внедрению) бизнес-процессов.

— Осуществления контроля
качества исполнения мероприятий.

— Осуществление необходимых
корректировок в новой модели
бизнес-процессов.

— Подготовка
отчета по Этапу 4.

— Завершение реинжиниринга.

— Оценка проделанной работы.

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

Основные этапы
реинжиниринга:

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

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

Разрабатывается модель
нового бизнеса.
Происходит перепроектирование текущего
бизнеса — прямой реинжиниринг. Для
создания модели обновленного бизнеса
осуществляются следующие действия:

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

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

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

Производится тестирование
новой модели — ее
предварительное применение в ограниченном
масштабе.

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

Источник

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

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

Моделирование бизнес-процессов — это подробное описание деятельности компании.

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

Цели

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

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

Условно, моделирование всех бизнес-процессов можно подразделить на 3 основных этапа:

Первый начался в 20 году прошлого века с выходом в свет “Принципов научного управления” американского инженера Ф. Тейлора. Внедряется SADT – методология структурного анализа, объединяющая процесс моделирования с управлением конфигурацией проекта. Появляются наглядные блок-схемы и сети Петри. В 80-х гг. предпринимаются первые попытки автоматизации. Однако используемые методики несовершенны, так как допускают варианты интерпретации.

В 1990 М. Хаммер и Д. Чампи выпускают “Реинжиниринг корпорации: манифест революции в бизнесе”, которая до сих пор изучается во всех ведущих бизнес-школах мира. Рождается новый подход к моделированию. С этого момента строится две модели: одна описывает существующие процессы, вторая — оптимальные (как должно быть). Продолжаются работы по автоматизации. Основная задача — моделирование нестандартных бизнес-процессов, для чего требуется привлекать программистов и вкладывать средства. Если хотите подробнее узнать о реинжиниринге – читайте эту статью.

2000 гг. ознаменовались появлением работы Г. Смита и П. Фингара “Управление бизнес-процессами: третья волна”. Новый подход предполагает разработку инструментов, которые дадут возможность менеджерам предприятий не только вносить корректировки в схемы бизнес-процессов, но и самим их создавать.

Работа по усовершенствованию способов моделирования бизнес-процессов продолжается. Специалисты отмечают тенденцию к упорядочиванию и стандартизации.

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

Работа по моделированию бизнес-процессов включает в себя 5 этапов:

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

Виды

Поскольку анализ схем, состоящих из большого числа элементов, затруднен, принято строить несколько моделей по видам:

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

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

Основных принципов пять:

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

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

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

Агрегирования. Наиболее эффективно строить сложные модели из простых элементов, которые также можно назвать подсистемами. Правильно подобранные блоки позволяют вносить изменения в систему, не переписывая всю модель в связи с изменением данных.

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Методы моделирования

Методов построения моделей довольно много, среди них:

IDEF — построенная на основе методологии SADT модель состоит из графических схем, облегчающих анализ системы.

DFD — используется при проектировании информационных систем. Показывает взаимосвязи между элементами, процесс передачи данных. Удобна для выявления причин изменени.

Flow Chart Diagram — метод моделирования бизнес-процессов посредством символов. Отличается гибкостью.

Сети Петри – показывают динамику изменения процессов.

Инструменты

AllFusion Process Modeler. Позволяет строить модели и производить анализ с использованием стандартных инструментов IDEF0, DFD и пр.
ELMA BPM. Позволяет отслеживать выполнение процессов в реальном времени. Для построения моделей используется нотация BPMN 2.0.
Draw io. Сервис позволяет строить огромное количество диаграмм и имеет большой набор элементов. Возможно связывать модели через гиперссылки. Кроме того, можно к элементам присоединять файлы из облачных хранилищ данных.

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

Специфика применения моделирования бизнес-процессов на практике

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

Значение моделирования бизнес-процессов для предприятий

Если работа проведена правильно, на выходе компания получит:

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

Как видим, правильное и осознанное моделирование бизнес-процессов только упрощает работу руководства и персонала компании.

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: Марина Ступакова, эксперт компании iTeam

Источник

Моделирование бизнес-процессов: цели, методы и результаты

Моделирование бизнес-процессов предприятия — важнейший инструмент грамотного и результативного управления.

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

Моделирование бизнес-процессов: основные понятия

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

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

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

Зачем моделировать бизнес-процессы

К чему приводит отсутствие формализованных бизнес-процессов?

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

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

Наличие моделированных процессов позволяет изменить ситуацию, решив несколько задач:

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

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

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

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

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

Имитационное моделирование — в этом случае процессы представляют через примеры их поведения в разных условиях, анализируя свойства в динамике.

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

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

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

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

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

Работа над проектом включает несколько этапов моделирования бизнес-процессов организации, которые выполняются последовательно.

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

Последний этап по сути не оканчивается — созданная модель будет постоянно дорабатываться с учетом внутренних и внешних изменений.

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

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

Количество методов достаточно велико. В числе основных можно назвать следующие.

IDEF — класс методов (IDEF0, IDEF1 и т.д.), основанных на методологии SADT. Модель позволяет описывать в виде графических схем разные стороны процессов. Так, IDEF0 создает модель функций процесса, а IDEF3 —
поведенческую модель.
VAD — нотация дает общий взгляд на бизнес-процессы, которые непосредственно участвуют в создании ценности, т.е. продукта или услуги.
EPC — нотация позволяет создать диаграмму процессов нижнего уровня, в которой для всех событий и функций определены участники, материальные и информационные потоки, стартовые и финишные точки.
BPMN — нотация, которая моделирует шаги запланированного бизнес-процесса от начала до завершения. Наглядная блок-схема отображает полную последовательность операций и информационных потоков.
Data Flow Diagram отображает передачу информации (не материалов) между операциями в рамках процесса. С помощью DFD можно разбить процесс на более мелкие подпроцессы, поэтому его применяют для структурного анализа.
Role Activity Diagram используют для моделирования процесса как совокупности ролей, имеющих определенные функции, и их взаимодействия.
Flow Chart Diagram строится с помощью набора символов, которые обозначают элементы процесса: процедуры, инструменты, данные и т.д. Метод отличается гибкостью, позволяя представить процесс как логическую последовательность
действий множеством способов.
Сети Петри позволяют отобразить динамическое изменение процессов. Модель представляет собой граф, вершины которого — это действия процесса, а дуги — события, определяющие изменение состояния процесса.

Существует ряд программных продуктов, которые могут быть использованы в качестве инструментов моделирования бизнес-процессов с применением описанных методов: ARIS, Business Studio, MS Visio, Bizagi Process Modeler и др.

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

Результаты бизнес-моделирования

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

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

Моделирование способно принести компании видимые преимущества:

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

Моделирование и анализ бизнес-процессов предприятия — действенный инструмент для оптимизации деятельности, повышения прибыли и успешного развития. Но все эти цели будут достигнуты при условии грамотного описания и
последовательного внедрения.

Источник