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

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

Основные понятия

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

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

Рабочий процесс

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

Реинжиниринг бизнес-процессов

Реорганизация бизнес-процессов (BPR) была первоначально задумана Хаммером и Давенпортом как средство повышения эффективности и производительности организации. Это может включать начало с «чистого листа» и полное воссоздание основных бизнес-процессов или сравнение процесса «как есть» и процесса «как есть» и отображение пути изменения от одного к другому. Часто BPR будет включать использование информационных технологий для обеспечения значительного повышения производительности. К сожалению, этот термин стал ассоциироваться с корпоративным «сокращением» в середине 1990-х годов.

Управление бизнес-процессами (BPM)

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

Управление знаниями

Управление знаниями - это определение знаний, которые сотрудники и системы используют для выполнения своих функций, и поддержание их в формате, доступном для других. Duhon и Gartner Group определили его как «дисциплину, которая продвигает интегрированный подход к идентификации, регистрации, оценке, извлечению и совместному использованию всех информационных активов предприятия. Эти активы могут включать базы данных, документы, политики, процедуры и ранее незарегистрированные знания и опыт отдельных работников ».

Полное управление качеством

Тотальное управление качеством (TQM) возникло в начале 1980-х годов, когда организации стремились улучшить качество своей продукции и услуг. В середине 80-х за ним последовала методология шести сигм , впервые представленная компанией Motorola. Шесть сигм состоят из статистических методов для улучшения бизнес-процессов и, таким образом, уменьшения дефектов в результатах. «Бережливый подход» к управлению качеством был внедрен Toyota Motor Company в 1990-х годах и сосредоточен на потребностях клиентов и сокращении потерь.

Информационные технологии как инструмент управления бизнес-процессами

Достижения в области информационных технологий на протяжении многих лет изменили бизнес-процессы внутри предприятий и между ними. В 1960-х операционные системы имели ограниченную функциональность, и любые используемые системы управления рабочими процессами были адаптированы для конкретной организации. В 1970-1980-х годах были разработаны подходы, основанные на данных, по мере совершенствования технологий хранения и поиска данных. Отправной точкой для построения информационной системы было моделирование данных, а не моделирование процессов. Бизнес-процессы пришлось адаптировать к информационным технологиям, поскольку моделированием процессов не уделялось должного внимания. Сдвиг в сторону процессно-ориентированного управления произошел в 1990-х годах. Программное обеспечение для планирования ресурсов предприятия с такими компонентами управления рабочими процессами, как SAP, Baan, PeopleSoft , Oracle и JD Edwardsпоявились, как и системы управления бизнес-процессами (BPMS) позже.

В мире электронного бизнеса возникла потребность в автоматизации бизнес-процессов в организациях, что, в свою очередь, вызвало потребность в стандартизованных протоколах и языках компоновки веб-сервисов, понятных для всей отрасли. Моделирование бизнес - процессов нотация (BPMN) и Business Motivation Model (ВММ) широко используются стандарты для бизнес - моделирования. Целевая группа по бизнес-моделированию и интеграции (BMI DTF) - это консорциум поставщиков и компаний-пользователей, который продолжает работать вместе над разработкой стандартов и спецификаций для содействия сотрудничеству и интеграции людей, систем и процессов. и информация внутри и между предприятиями.

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

Моделированме

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

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

Модель бизнес-процесса

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

• набор составляющих процесс шагов — бизнес-функций;
• порядок выполнения бизнес-функций;
• механизмы контроля и управления в рамках бизнес-процесса;
• исполнителей каждой бизнес-функции;
• входящие документы/информацию, исходящие документы/информацию;
• ресурсы, необходимые для выполнения каждой бизнес-функции;
• документацию/условия, регламентирующие выполнение каждой бизнесфункции;
• параметры, характеризующие выполнение бизнес-функций и процесса в целом.

Для моделирования бизнес-процессов можно использовать различные методы. Метод, или методология, моделирования включает в себя последовательность действий, которые необходимо выполнить для построения модели, т. е. процедуру моделирования, и применяемую нотацию (язык). Наиболее популярной методологией бизнес-моделирования является ARIS, но также известны Catalyst компании CSC, Business Genetics, SCOR (Supply \
Chain Operations Reference), POEM (Process Oriented Enterprise Modeling) и др. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов). В теории и на практике существуют различные подходы к построению и отображению моделей бизнес-процессов, основными из которых являются функциональный и объектно-ориентированный. В функциональном подходе главным структурообразующим элементом является функция (бизнес-функция, действие, операция), и система представляется в виде иерархии взаимосвязанных функций. При объектноориентированном подходе система разбивается на набор объектов, соответствующих объектам реального мира и взаимодействующих между собой посредством посылки сообщений.

По типу методологий моделирования выделяют:

- средства структурного моделирования (BPwin);

Аспект	BPWin	Rational Rose	ARIS Toolset
Функции бизнеса	IDEF0, DFD	Use case	Дерево функций, дерево целей, ...
Логика бизнес-процессов	IDEF3	Диаграмма деятельности	Событийная цепочка EPC, офисный процесс, ...
Исполнители процессов, другие ресурсы	IDEF0	Д-ма последо-вательности, кооперации	Событийная цепочка д-ма окружения функции, организационная схема ...
Данные, информация	Связь с Erwin	Диаграмма классов	М. технических терминов, ER-модель, ....

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

Бизнес-функция

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

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

Важным понятием любого метода моделирования бизнес-процессов являются связи (как правило, в графических нотациях их изображают в виде стрелок). Об этом говорит сайт https://intellect.icu . Связи служат для описания взаимоотношений объектов и/или бизнес-функций друг с другом. К числу таких взаимоотношений могут относиться: последовательность выполнения во времени, связь с помощью потока информации, использование другим объектом и т.д.

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

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

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

В общих чертах, согласно фон Розингу и др., Бизнес-процессы можно разделить на три типа:

1. Операционные процессы, которые составляют основной бизнес и создают основной поток создания ценности, например, прием заказов от клиентов, открытие счета и производство компонента.
2. Управленческие процессы , процессы, которые контролируют операционные процессы, включая корпоративное управление , бюджетный надзор и надзор за сотрудниками
3. Вспомогательные процессы, которые поддерживают основные операционные процессы, например бухгалтерский учет , набор персонала , колл-центр , техническую поддержку и обучение технике безопасности.

Несколько иной подход к этим трем типам предлагает Кирчмер:

1. Операционные процессы, которые направлены на правильное выполнение операционных задач организации; здесь персонал «добивается своего»
2. Управленческие процессы, обеспечивающие надлежащее выполнение операционных процессов; именно здесь менеджеры «обеспечивают эффективные и действенные рабочие процессы»
3. Процессы управления, обеспечивающие полное соответствие деятельности организации необходимым правовым нормам, руководящим принципам и ожиданиям акционеров; именно здесь руководители обеспечивают соблюдение «правил и рекомендаций для достижения успеха в бизнесе».

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

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

Важное раннее (1776 г.) описание процессов было сделано экономистом Адамом Смитом в его знаменитом примере булавочной фабрики. Вдохновленный статьей в « Энциклопедии Дидро» , Смит описал изготовление булавки следующим образом:

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

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

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

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

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

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

Таблица 1.1

Начало первого этапа относят к 1920-м гг. XX в. и связывают с именем Фредерика Тейлора и его
книгой «Принципы научного управления». В этот период впервые была осознана необходимость
исследовать бизнес-процессы, описывать их в различных документах и действовать в соответствии с
этими описаниями. Описание бизнес-процессов производится в текстовом, табличном и графическом
виде, причем последний все более формализуется.
В период «первой волны» для моделирования бизнес-процессов используются блок-схемы,
ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе
определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англ. литературе
— ANSI flowcharts) остаются и сегодня простейшим, но практически важным формальным графическим языком моделирования бизнес-процессов. Пример описания процесса с помощью блоксхемы приведен на рис. 1.1. Блок-схемы позволяют быстро и наглядно показать шаги бизнес-процесса
в понятной каждому форме, однако их нотация не предусматривает формализованного описания
многих деталей процесса, в частности исполнителей бизнес-функций.
О методологиях SADT и IDEF мы подробно поговорим в следующей главе. Что же касается сетей
Петри, то использование этого аппарата непосредственно для описания бизнес-процессов хотя и
имеет своих сторонников, но не завоевало широкой популярности, так как его графическая нотация
не является интуитивно понятной (с ней сложно работать бизнес-аналитикам и менеджерам).
Кроме того, есть процессы, которые невозможно описать с его помощью. Однако, забегая
вперед, отметим, что сети Петри лягут в основу ряда языков, специально разработанных для
моделирования бизнес-процессов в рамках «третьей волны».
В 1980-х гг. предпринимаются первые попытки автоматизации бизнес-процессов (уточним: не
отдельных шагов, а хода процесса в целом) путем реализации в программном обеспечении для

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

рис 1.1. пример описания бизнесс процесса в виде блок-схемы

Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи -Реинжиниринг
корпорации: манифест революции в бизнесе», которая возродила в управленческой среде
интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки —
реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей
бизнес-процесса: как есть (англ. as is) и как должно быть (англ. to be), а затем внедрение
последней на предприятии.
Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг. появляются
системы управления потоками работ WfMS (Workflow Management System) второго
поколения, предназначенные для маршрутизации потоков работ любого типа в рамках
бизнес-процессов компании. Эти системы снабжены средой разработчика, которая
теоретически может использоваться для моделирования различных нестандартных бизнес-процессов, однако на практике в большинстве случаев внедрение нового или изменение
имеющегося процесса требовало привлечения труда программистов. Еще более ограниченные возможности по настройке и изменению процессов предоставляли
поддерживающие управление потоками работ системы планирования ресурсов предприятия
ERP (Enterprise Resource Planning). Внесение любых существенных изменений в бизнеспроцесс превращалось в весьма дорогостоящий и долгосрочный проект по проектированию и
разработке программного обеспечения, а модели бизнес-процессов, построенные
аналитиками, использовались для более четкой формулировки требований, которые затем
передавались программистам. В качестве примера методологии и средства автоматизации
бизнес-процессов второго поколения можно назвать соответственно ARIS и
распространенную ERP-систему SAP R/3.
Негибкость моделей и средств автоматизации, их неспособность обеспечить оперативное
реагирование на постоянные изменения в бизнес-среде стали основными недостатками
систем «второй волны», стимулировавшими разработку в начале 2000-х гг. методологий
следующего — третьего — поколения. Манифестом «третьей волны» в моделировании
бизнес-процессов можно по праву назвать книгу Г. Смита и П. Фингара «Управление
бизнес-процессами: третья волна»1
. На смену радикальному реинжинирингу приходит
системное и «плавное» управление. Изменчивость бизнес-процессов, возможность их
корректировки в ответ на изменения в бизнесе становятся главным критерием
использования информационных технологий как средства, позволяющего получить
преимущества на рынке.
Идея методологий и инструментов моделирования третьего поколения состоит в том,
чтобы позволить руководству и сотрудникам компании создавать и самим внедрять новые
процессы «на лету». Автоматизация процессов производится посредством так называемых
систем управления бизнес-процессами BPMS (Business Process Management System), которые
дают возможность непосредственно реализовывать бизнес-процессы в соответствии с
построенной формальной моделью и не требуют разработки дополнительного программного
обеспечения.
Для разработки понятных машине «исполняемых» моделей требуются более точные
методы моделирования. К таким методам относятся языки моделирования на базе XML:
BPML, BPEL, XPDL. Однако построение моделей непосредственно на этих языках
неудобно для бизнес-пользователей. В этой связи большое внимание разработчики
программного обеспечения уделяют средствам конвертирования графических моделей
бизнес-процессов в исполняемые. Это позволяет бизнес-аналитику или менеджеру
строить модели бизнес-процессов с использованием графической нотации, а затем
преобразовывать построенную модель (пока нередко с помощью технического
специалиста) в исполняемый вид.
Следует понимать, что графические модели, предназначенные для преобразования в исполняемые,
должны быть гораздо более строгими и формальными по сравнению с моделями, создаваемыми в
аналитических целях. Например, графическую модель, построенную в виде блок-схемы с
обширными текстовыми комментариями, автоматически конвертировать в исполняемый формат не
удастся. В качестве языка, позволяющего построить наглядную, понятную неподготовленному
пользователю модель, которую затем можно однозначно преобразовать в исполняемый язык
(изначально это был 3PML), выступила нотация BPMN. Она поддерживает описание таких <
программистских» функций, как обработка событий и ошибок, откат транзакций и т. п.
«Третья волна» принесла в моделирование бизнес-процессов стремление к стандартизации.
Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по
стандартизации и международными консорциумами:

• OASIS (Organization for the Advancement of Structured Information Standards, осн. в 1993 г.) выпускает спецификации ebXML и BPEL, а также различные стандарты для электронного бизнеса на базе XML и веб-сервисов;
• OMG (Object Management Group, осн. в 1989 г.) выпускает стандарты BPMN и UML, а также MDA и CORBA;
• W3C (World Wide Web Consortium, осн. в 1994 г.) выпускает стандарты WS-CDL, WSCI, а также спецификации XML, технологии веб-сервисов и многие другие;
• WfMC (Workflow Management Coalition, осн. в 1993 г.) выпускает стандарты Wf-XMLи XPDL.

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

Потребности в автоматизации бизнес-процессов взаимодействия между предприятиями возникли еще в 60-х гг. прошлого века. Первое поколение электронных систем В2Ввзаимодействия описывает стандарт UN/EDIFACT, или ЭДИФАКТ ООН (Правила ООН Электронного Обмена Данными в Управлении, Торговле и на Транспорте, ISO 9735), который, несмотря на высокую конкуренцию со стороны XML-систем в последние годы, до сих пор довольно широко применяется в Европе во многих секторах экономики.

Развитие сети Интернет послужило толчком к созданию новых методов и технологий в области электронного обмена данными. Одним из наиболее удачных методов электронного обмена является появившаяся в 1998 г. методология консорциума RosettaNet. Данная технология описывает открытую платформу электронного взаимодействия, основанного на стандарте XML, и позволяет сторонам, участвующим во взаимодействии, обмениваться бизнес-информацией через Интернет. Первоначально стандарт был разработан для индустрии высоких технологий й (информационные технологии и электроника), однако предложенный подход послужил основой механизмов взаимодействия предприятий и других отраслей. В рамках методологии RosettaNet разработаны стандарты более сотни процессов бизнес-взаимодействия между различными компаниями или подразделениями внутри одного предприятия. Эти стандартизованные процессы получили название процессов интерфейса взаимодействия с партнером (Partner Interface Process, PIP) и специфицируют транзакции между двумя бизнес-системами в форме диалога на основе стандарта XML.

Еще одной современной технологией автоматизации межкорпоративного взаимодействия является ebXML (Electronic Business using extensible Markup Language, ИСО 15000). Работа над технологией ebXML началась в 1999 г. по инициативе СЕФАКТ ООН (Центр ООН по поддержке процедур и практики управления, коммерции и транспорта) и консорциума OASIS, накопившего большой опыт в сфере организации ведения бизнеса в Интернете на базе XML. Целью данного проекта является разработка инфраструктуры электронного бизнеса — полного набора спецификаций, позволяющего осуществлять бизнес-взаимодействия через единообразную XML-среду. С появлением ebXML компании получили стандартизованный де-факто метод обмена данными и бизнессообщениями, а также единые условия информационной поддержки торговых отношений.
Архитектура ebXML объединяет спецификации формата сообщений, модели бизнес-процессов, пакет синтаксически нейтральных базовых компонентов и распределенные хранилища данных (репозитории). Стандарт ebXML получает все более широкое распространение с внедрением технологии веб-сервисов (Web Services).

Важность технологической цепочки

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

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

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

1. вручную
2. с помощью систем обработки бизнес- данных, таких как системы ERP

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

Политики, процессы и процедуры

Вышеупомянутые области улучшения в равной степени применимы к политикам, процессам, подробным процедурам (подпроцессам / задачам) и рабочим инструкциям . Улучшения, сделанные на более высоком уровне, имеют каскадный эффект от улучшений, сделанных на более низком уровне. ^[26]

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

Отчетность как важная основа для исполнения

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

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

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

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

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

• Точно определить результат бизнес-процесса и оценить его значение для бизнеса.
• Определить набор действий, составляющих бизнес-процесс. Ясное определение набора задач и действий, которые необходимо выполнить, чрезвычайно важно для детального понимания процесса.
• Определить порядок выполнения действий. Действия в рамках одного бизнес-процесса могут выполняться как последовательно, так и параллельно. Очевидно, что параллельное исполнение, если оно допустимо, позволяет сократить общее время выполнения процесса и, следовательно, повысить его эффективность.
• Произвести разделение зон ответственности: определить, а затем отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.
• Определить ресурсы, потребляемые бизнес-процессом. Точно зная, кто какие ресурсы использует и для каких операций, можно повысить эффективность использования ресурсов посредством планирования и оптимизации.
• Понять суть взаимодействий между участвующими в процессе сотрудниками и подразделениями компании и оценить, а затем повысить эффективность коммуникации между ними.
• Увидеть движение документов в ходе процесса. Бизнес-процессы производят и потребляют различные документы (в бумажной или электронной форме). Важно разобраться, откуда и куда идут документы или информационные потоки, и определить, оптимально ли их движение и действительно ли все они необходимы.
• Определить потенциальные узкие места и возможности для улучшения процесса, которые будут использованы позже для его оптимизации.
• Более эффективно внедрить стандарты качества, например ИСО 9000, и успешно пройти сертификацию.
• Использовать модели бизнес-процессов в качестве руководства для новых сотрудников.
• Эффективно произвести автоматизацию бизнес-процессов в целом или отдельных их шагов, включая автоматизацию взаимодействия с внешней средой — клиентами, поставщиками, партнерами.
• Разобравшись в совокупности бизнес-процессов компании, понять и описать деятельность предприятия в целом.

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

рис. 1.2 Шаги построения модели бизнесс-процесса

На рис. 1.2 показаны основные шаги при построении модели бизнес-процесса.
Важной частью построения модели бизнес-процесса является исследование аспектов его эффективности. Сюда входят использование ресурсов, время выполнения работ сотрудниками, возможные задержки и простои. Необходимо разработать систему показателей, или метрик, для оценки эффективности процесса. Частично в качестве метрик могут быть взяты используемые в компании KPI (Key Performance Indicator), однако могут потребоваться и дополнительные характеризующие рассматриваемый процесс показатели.

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

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

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

•  Процессная карта, показывающая связь между различными бизнес-процессами и их взаимодействия. На процессной карте, как правило, каждый бизнес-процесс компании изображен в виде прямоугольника, стрелками показаны связи между ними (например, зависимость одного процесса от другого, или замена одного процесса другим при выполнении некоторого условия), а также представлены различные документы, которые передаются из процесса в процесс или регламентируют их ход (стандарты, инструкции и т.п.).
•  Диаграмма ролей, показывающая роли при выполнении процесса и связи между ними. Диаграмма ролей не является иерархической. Она представляет такие связи, как участие в группе, руководство, коммуникацию, замещение одной роли другой и т. д.
•  Модель «как есть» каждого рассмотренного бизнес-процесса, детально описывающая процесс и отражающая ход процесса, действия, роли, движение документов, а также точки возможной оптимизации.

Такая модель включает в себя:

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

На практике хорошо зарекомендовал себя следующий состав группы, осуществляющей
моделирование бизнес-процесса:

• владелец бизнес-процесса и один-два сотрудника того же подразделения компании,помогающих ему;
• специалист по управлению качеством;
• бизнес-аналитик(и);
• представитель ИТ-подразделения;
• внешний консультант (не обязательно).

Возможности инструментальных средств

Основные функциональные возможности средств моделирования:

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

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

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

Критерии выбора инструментального средства:

• Функциональные возможности и методология.
• Должны соответствовать потребностям. Не следует с «переплатой» приобретать инструмент с избыточными возможностями.
• Если предполагается построение информационных систем поддержки бизнес-процессов, то больше подходят Oracle Designer, Power Designer и Rational Rose.
• Если нужно средство моделирования бизнеса, небольшого по масштабу, не слишком сложного, то лучше подходит Bpwin.
• Если выполняется крупный проект по реинжинирингу бизнеса, требующий тщательного анализа предполагаемых вариантов реконструкции бизнеса (обсчета временных, стоимостных и других количественных показателей) и последующей их оптимизации, то лучше подходит ARIS Toolset.

Уровень подготовки персонала.

Как правило, чем шире возможности инструментальной среды, тем выше выдвигаются требования к пользователям.Для работы со сложными в освоении инструментальными средствами (например, Rational Rose, ARIS), требуется обучить персонал или нанять уже подготовленных квалифицированных специалистов. Это требует дополнительных затрат и удлиняет сроки разработки.Поэтому лучше использовать сравнительно простые в освоении средства (Design/IDEF, Bpwin), если их возможности соответствуют потребностям

Стоимость инструментальных средств

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

Характеристики программно-аппаратной платформы.

При выборе инструментальной среды необходимо оценить:

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

Рис. Инструментальное средство BPwin

Вау!! 😲 Ты еще не читал? Это зря!

• бизнес процесс , реинжиринг , обзор методологий проектирования бизнес процессов , eepc ,
• epc , event-driven process chain , событийная цепочка процессов , eepc ,
• Бизнес- анализ
• Патент на бизнес- метод
• Автоматизация бизнес-процессов
• Метамодель определения бизнес-процесса
• Отображение бизнес-процессов
• Аутсорсинг бизнес -процессов

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