В этой статье описываются обычно выполняемые вручную действия по созданию и представлению концептуальных моделей бизнес-процессов компании на основе экспертных знаний. Для автоматической оценки моделей транзакционных бизнес-процессов на основе цифровых следов в ИТ-системах см. интеллектуальный анализ процессов .
Моделирование бизнес-процессов ( BPM ), в основном используется при управлении бизнес-процессами ; Разработка программного обеспечения или системная инженерия — это действие по сбору и представлению процессов предприятия (т. е. их моделированию ), чтобы текущие бизнес-процессы можно было анализировать, безопасно и последовательно применять, улучшать и автоматизировать. BPM обычно выполняется бизнес-аналитиками, имеющими опыт в области моделирования; экспертами в данной области, обладающими специальными знаниями о моделируемых процессах; или, чаще, командой, состоящей из обоих. Альтернативно, модель процесса может быть получена непосредственно из цифровых следов в ИТ-системах (например, журналов событий) с использованием инструментов анализа процессов .
По словам Андреаса Гадача , моделирование процессов — это «картирование частей реальности из бизнес-сферы в бизнес-процессе с технической и концептуальной точки зрения». [1] (Глава 1.1 Управление процессами) ← автоматический перевод с немецкого
По данным Ассоциации специалистов по управлению бизнес-процессами ABPMP , моделирование бизнес-процессов является одной из дисциплин управления бизнес-процессами , которая включает в себя следующие пять дисциплин: [2] (Глава 1.4 Структура CBOK®) ← автоматический перевод с немецкого языка
Однако полностью раздельное рассмотрение дисциплин невозможно: моделирование бизнес-процессов всегда требует анализа бизнес-процессов для моделирования процессов «как есть» (см. раздел «Анализ бизнес-деятельности») или спецификаций проектирования процессов для моделирования будущих процессов (см. раздел «Анализ бизнес-деятельности»). см. разделы «Реинжиниринг бизнес-процессов» и «Оптимизация бизнес-процессов»).
По мнению Германа Й. Шмельцера и Вольфганга Сессельмана, основное внимание в моделировании бизнес-процессов уделяется представлению потока действий (деятельности) , состоящего «из кросс-функциональной идентификации действий, добавляющих ценность, которые генерируют конкретные услуги, ожидаемые клиентом, и результаты которых имеют стратегическое значение для компании. Они могут выходить за пределы компании и включать в себя деятельность клиентов, поставщиков или даже конкурентов». [3] (Глава 2.1 Отличия процессов от бизнес-процессов) ← автоматический перевод с немецкого
Но также и другие качества (факты), такие как данные и бизнес-объекты (в качестве входных / выходных данных ), формальные организации и роли (ответственные/подотчетные/консультируемые/информированные лица, см. RACI ), ресурсы и ИТ-системы , а также руководящие принципы /инструкции ( рабочее оборудование ), требования , показатели и т.д. могут быть смоделированы.
Чем больше этих характеристик включено в моделирование бизнес-процессов, тем лучше абстракция моделей бизнес-процессов отражает реальность – и тем более сложными становятся модели бизнес-процессов. «Для уменьшения сложности и повышения понятности и прозрачности моделей рекомендуется использовать концепцию представления». [1] (Глава 2.4 Представления о моделировании процессов) ← автоматический перевод с немецкого. Также приводится краткое сравнение концепций представлений пяти соответствующих немецкоязычных школ бизнес- информатики : 1) Август В. Шеер , 2) Хуберт Остерле , 3 ) Отто К. Ферстль и Эльмар Й. Синц , 4) Герман Геринг и 5) Андреас Гадач. Более подробную информацию о концепциях представлений можно также найти в картографии компании (на немецком языке).
Термин « взгляды» ( Аугуст В. Шеер , Отто К. Ферстль и Эльмар Дж. Синц , Герман Геринг и Андреас Гадач ) не используется единообразно во всех школах бизнес-информатики — альтернативными терминами являются измерения дизайна ( Хуберт Остерле ) или перспективы ( Захман ). .
М. Роземанн, А. Швегманн и П. Дельфманн также видят недостатки в концепции представлений : «Можно создавать информационные модели для каждой точки зрения отдельно и, таким образом, частично избыточно. Однако дублирование всегда означает увеличение усилий по обслуживанию и ставит под угрозу согласованность моделей». [4] (Глава 3.2.1 Соответствующие взгляды на модели процессов) ← автоматический перевод с немецкого
По словам Андреаса Гадача , моделирование бизнес-процессов понимается как часть управления бизнес-процессами наряду с определением процессов и управлением процессами . [1] (Глава 1.1 Управление процессами) ← автоматический перевод с немецкого
Моделирование бизнес-процессов также является центральным аспектом целостного картографирования компании (на немецком языке), которое также связано с отображением корпоративной миссии , корпоративной политики/ корпоративного управления , организационной структуры , организации процессов, архитектуры приложений , правил и групп интересов, а также магазин . _
.gif/1280px-Core_process_(quality_management).gif)
По данным Европейской ассоциации управления бизнес-процессами EABPM , «существует три различных типа сквозных бизнес-процессов:
Эти три типа процессов можно выделить в каждой компании и почти без исключения используются на практике в качестве верхнего уровня структурирования моделей бизнес-процессов. [5] Вместо термина « процессы лидерства» обычно используется термин « процессы управления» . Вместо термина « процессы исполнения» широкое распространение получил термин «основные процессы» . [3] (Глава 6.2.1 Цели и концепция) ← автоматический перевод с немецкого, [6] (Глава 1.3 Концепция процесса) ← автоматический перевод с немецкого, [7] (Глава 4.12.2 Различие между основными и вспомогательными целями) ← автоматический перевод с немецкого, [8] (глава 6.2.2 Идентификация и черновой вариант) ← автоматический перевод с немецкого
Если затем основные процессы организуются/декомпозируются на следующем уровне управления цепочками поставок (SCM), управления взаимоотношениями с клиентами (CRM) и управления жизненным циклом продукта (PLM), стандартные модели крупных организаций и отраслевых ассоциаций, такие как модель SCOR, также могут быть использованы. быть интегрированы в моделирование бизнес-процессов.
Методы моделирования бизнес-процессов, такие как блок-схема , функциональная блок- схема , диаграмма потока управления , диаграмма Ганта , диаграмма PERT и IDEF , появились с начала 20-го века. Диаграммы Ганта были одними из первых, появившихся примерно в 1899 году, блок-схемы - в 1920-х годах, блок-схемы функциональных потоков и PERT - в 1950-х годах, диаграммы потоков данных и IDEF - в 1970-х годах. Среди современных методов — унифицированный язык моделирования и модель и нотация бизнес-процесса . Тем не менее, это лишь малая часть методологий, использовавшихся на протяжении многих лет для документирования бизнес-процессов. [9] Термин «моделирование бизнес-процессов» был придуман в 1960-х годах в области системной инженерии С. Уильямсом в его статье 1967 года «Моделирование бизнес-процессов улучшает административный контроль». [10] Его идея заключалась в том, что методы, позволяющие лучше понять системы физического контроля, можно аналогичным образом использовать и для бизнес-процессов . Лишь в 1990-е годы этот термин стал популярным.
В 1990-е годы термин « процесс » стал новой парадигмой производительности. [11] Компаниям предлагалось мыслить процессами , а не функциями и процедурами . Процессное мышление рассматривает цепочку событий в компании от покупки до поставки, от получения заказа до продаж и т. д. Традиционные инструменты моделирования были разработаны для иллюстрации времени и затрат, тогда как современные инструменты ориентированы на кросс-функциональные действия. Число и важность этих межфункциональных видов деятельности значительно возросли из-за роста сложности и зависимости. Новые методологии включают в себя реорганизацию бизнес-процессов , инновации бизнес-процессов, управление бизнес-процессами , интегрированное бизнес-планирование и многое другое, «направленные на улучшение процессов во всех традиционных функциях, составляющих компанию». [11]
В области разработки программного обеспечения термин «моделирование бизнес-процессов» противопоставлялся обычному моделированию процессов программного обеспечения с целью больше сосредоточиться на состоянии практики во время разработки программного обеспечения . [12] В то время (начало 1990-х годов) все существующие и новые методы моделирования для иллюстрации бизнес-процессов были объединены как « языки моделирования бизнес - процессов » . В объектно-ориентированном подходе это считалось важным шагом в спецификации систем бизнес-приложений. Моделирование бизнес-процессов стало основой новых методологий, например, тех, которые поддерживали сбор данных , анализ потоков данных, диаграммы потоков процессов и средства отчетности. Примерно в 1995 году были представлены первые визуально ориентированные инструменты для моделирования и реализации бизнес-процессов.
Целью моделирования бизнес-процессов является — обычно графическое — представление сквозных процессов, при котором сложные факты действительности документируются посредством единообразного (систематизированного) представления и сводятся к содержательным ( качествам ). Здесь также часто играют роль нормативные требования к документированию процессов (например, контроль документации , отслеживаемость или целостность ), например, со стороны управления качеством , управления информационной безопасностью или защиты данных .
Моделирование бизнес-процессов обычно начинается с определения требований к окружающей среде: во-первых, необходимо определить цель моделирования (приложения моделирования бизнес-процессов). Модели бизнес-процессов сейчас часто используются многофункционально (см. выше). Во-вторых, необходимо определить адресатов модели, поскольку свойства создаваемой модели должны соответствовать их требованиям. Далее следует определение бизнес-процессов, которые будут моделироваться.
Качества бизнес-процесса, которые должны быть представлены в модели, задаются в соответствии с целью моделирования. Как правило, это не только функции, составляющие процесс, включая связи между ними, но и ряд других качеств, таких как формальная организация , вход , выход , ресурсы , информация , среда , транзакции , события , состояния , условия . , операции и методы .
Подробно, цели моделирования бизнес-процессов могут включать (ср.: Ассоциация специалистов по управлению бизнес-процессами (ABPMP) [2] (Глава 3.1.2 Характеристики и свойства процессов) ← автоматический перевод с немецкого ):
Поскольку моделирование бизнес-процессов само по себе не вносит прямого вклада в финансовый успех компании, нет и мотивации к моделированию бизнес-процессов, исходя из важнейшей цели компании – намерения получить прибыль . Таким образом, мотивация компании к моделированию бизнес-процессов всегда вытекает из соответствующей цели. Михаэль Роземанн, Ансгар Швегманн и Патрик Дельфманн перечисляют ряд целей в качестве мотивации для моделирования бизнес-процессов:
В рамках обширной исследовательской программы, начатой в 1984 году в Массачусетском технологическом институте под названием «Менеджмент в 1990-е годы», в начале 1990-х годов появился подход к реинжинирингу процессов . Программа исследований была разработана для изучения влияния информационных технологий на то, как организации смогут выжить и процветать в конкурентной среде 1990-х годов и позже. В итоговом отчете Н. Венкат Венкатраман [15] резюмирует результат следующим образом: Наибольшего увеличения производительности можно достичь, когда новые процессы планируются параллельно с информационными технологиями.
Этот подход был подхвачен Томасом Х. Давенпортом [16] (Часть I: Структура инноваций в процессах, Глава: Введение), а также Майклом М. Хаммером и Джеймсом А. Чампи [17] и развил его в переосмыслении бизнес-процессов . инжиниринг (BPR), как мы его понимаем сегодня, согласно которому бизнес-процессы фундаментально перестраиваются с целью достижения улучшения измеримых показателей эффективности, таких как затраты, качество, сервис и время.
Реинжиниринг бизнес-процессов подвергался частичной критике за то, что он начинается с «нулевого поля» и, следовательно, не может быть реализован напрямую для существующих компаний. Герман Й. Шмельцер и Вольфганг Сессельман оценивают это так: «Критика BPR во многих отношениях носит академический характер. … Некоторые из высказанных критических замечаний оправданы с практической точки зрения. Это включает в себя указание на то, что чрезмерно радикальный подход несет в себе риск неудачи. Это особенно проблематично, если организация и сотрудники недостаточно подготовлены к BPR». [3] (Глава 6.2.1 Цели и концепция) ← автоматический перевод с немецкого языка
По мнению Томаса Х. Давенпорта, высокоуровневый подход к BPR состоит из:
.svg/1280px-ISO_Logo_(Red_square).svg.png){kind=logo}
Благодаря ISO/IEC 27001 :2022 стандартные требования к системам менеджмента теперь стандартизированы для всех основных стандартов ISO и носят процессуальный характер.
В стандартах ISO/IEC 9001 , ISO/IEC 14001 , ISO/IEC 27001 это закреплено в главе 4.4 в каждом случае:
Каждый из этих стандартов требует от организации создания, внедрения, поддержания и постоянного улучшения соответствующей системы управления, «включая необходимые процессы и их взаимодействие». [18] , [19] , [20]
При определении стандартных требований к необходимым процессам и их взаимодействию ISO/IEC 9001 в пункте 4.4.1 более конкретен, чем любой другой стандарт ISO для систем менеджмента , и определяет, что «организация должна определять и применять процессы, необходимые для» [18] соответствующая система управления во всей организации, а также перечисляет подробные требования в отношении процессов:
Кроме того, в пункте 4.4.2 ISO/IEC 9001 перечислены некоторые более подробные требования в отношении процессов:
Внедрение стандартных требований к необходимым процессам и их взаимодействию и, в частности, подтверждение реализации стандартных требований адекватной документацией (моделирование бизнес-процессов) является обычной практикой. Это также означает, что стандартные требования к документированной информации также актуальны для моделирования бизнес-процессов как части системы управления ISO.
В стандартах ИСО/МЭК 9001 , ИСО/МЭК 14001 , ИСО/МЭК 27001 требования к документированной информации закреплены в п. 7.5 (детализированы в соответствующем стандарте в пунктах «7.5.1. Общие положения», «7.5.2. Создание и обновление» и «7.5.3. Контроль документированной информации»).
Стандартные требования ISO/IEC 9001, использованные здесь в качестве примера, включены в раздел «7.5.1. Общие положения».
требование в пункте «7.5.2. Создание и обновление»
и требуют в пункте «7.5.3. Контроль документированной информации»
В соответствии со стандартными требованиями,
подготовка к сертификации системы менеджмента по ISO — это очень хорошая возможность внедрить или продвигать моделирование бизнес-процессов в организации.
Герман Й. Шмельцер и Вольфганг Сессельман отмечают, что областью совершенствования трех методов, упомянутых ими в качестве примеров оптимизации процессов (контроль и сокращение общего времени цикла (TCT), Кайдзен и Шесть Сигм ), являются процессы: общее время цикла (TCT) — это бизнес-процессы (сквозные процессы) и подпроцессы , в Кайдзен — это этапы процесса и действия , а в Шести Сигмах — это подпроцессы , этапы процесса и действия . [3] (Глава 6.3.1 Общее время цикла (TCT), КАЙДЗЕН и Шесть Сигм в сравнении) ← автоматический перевод с немецкого языка
Что касается общего времени цикла (TCT) , Герман Й. Шмельцер и Вольфганг Зессельман перечисляют следующие ключевые характеристики: [3] (Глава 6.3.2 Общее время цикла (TCT)) ← автоматический перевод с немецкого языка
Следовательно, моделирование бизнес-процессов для TCT должно поддерживать адекватное документирование барьеров, их обработку и измерение.
Глядя на инструменты Кайдзен , изначально нет прямой связи с бизнес-процессами или моделированием бизнес-процессов. Тем не менее, Кайдзен и управление бизнес-процессами могут принести пользу друг другу. «В контексте управления бизнес-процессами цели КАЙДЗЕН вытекают непосредственно из целей бизнес-процессов и подпроцессов. Эта связь гарантирует, что меры КАЙДЗЕН поддерживают бизнес-цели». [3] (Глава 6.3.3 КАЙДЗЕН) ← автоматический перевод с немецкого
«Шесть сигм» разработана для предотвращения ошибок и улучшения возможностей процесса , чтобы доля результатов процесса, соответствующих требованиям, составляла 6σ — или, другими словами, на каждый миллион результатов процесса происходит только 3,4 ошибки. Герман Й. Шмельцер и Вольфганг Сессельманн объясняют: «Компании часто сталкиваются со значительным сопротивлением на уровне 4σ, что делает необходимым перепроектирование бизнес-процессов в смысле реинжиниринга бизнес-процессов (проектирование для шести сигм)». [3] (Глава 6.3.4 «Шесть сигм») ← автоматический перевод с немецкого Для воспроизводимого измерения возможностей процесса требуется точное знание бизнес-процессов, а моделирование бизнес-процессов является подходящим инструментом для проектирования «Шести сигм». Таким образом, «Шесть сигм» использует моделирование бизнес-процессов в соответствии с SIPOC как важную часть методологии, а моделирование бизнес-процессов с использованием SIPOC зарекомендовало себя как стандартный инструмент «Шести сигм».
Целью моделирования бизнес-процессов между компаниями является учет влияния внешних заинтересованных сторон в анализе или достижение сопоставимости бизнес-процессов между компаниями, например, для обеспечения возможности сравнительного анализа .
Мартин Куглер в этом контексте перечисляет следующие требования к моделированию бизнес-процессов: [21] (Глава 14.2.1 Требования к моделированию внутрифирменных бизнес-процессов) ← автоматический перевод с немецкого языка
Анализ бизнес-деятельности определяет и определяет базовые условия успешного моделирования бизнес-процессов. Именно с этого компания должна начать,
разработать подход к структурированию моделей бизнес-процессов. И соответствующие цели , и стратегия напрямую влияют на карту процесса .
Эту стратегию долгосрочного успеха моделирования бизнес-процессов можно охарактеризовать с точки зрения рынка и/или подхода, основанного на ресурсах. Йорг Беккер и Фолькер Майзе объясняют: «В то время как с точки зрения рынка отрасль и поведение конкурентов напрямую определяют стратегию компании, ресурсно-ориентированный подход предполагает внутренний взгляд, анализируя сильные и слабые стороны компании и определяя направление развития». разработка стратегии исходя из этого». [7] (Глава 4.6. Ресурсный взгляд) ← автоматический перевод с немецкого И далее: «Альтернативный характер, первоначально сформулированный в литературе между рыночным и ресурсным взглядами, теперь уступил место дифференцированной перспективе. Подход, основанный на ключевых компетенциях , рассматривается как важный вклад в объяснение потенциала успеха, который используется наряду с существующими рыночно-ориентированными подходами . Таким образом, карта процессов будет представлять собой модели бизнес-процессов с целью развития рынка, с целью оптимизации ресурсов или сбалансированным образом.
После этого бизнес-процессы компании идентифицируются и отличаются друг от друга путем анализа бизнес-деятельности (см. также Анализ бизнес-процессов ). Бизнес-процесс — это совокупность связанных, структурированных действий (действий) , которые производят конкретную услугу или продукт (для достижения определенной цели) для конкретного клиента или группы клиентов.
Европейская ассоциация управления бизнес-процессами EABPM заявляет: «В качестве первого шага в проектировании или реинжиниринге процессов необходимо установить общее понимание текущего процесса и его соответствие целям». [2] (Глава 4 Анализ процесса) ← автоматический перевод с немецкого
Усилия, связанные с анализом процессов «как есть», неоднократно критикуются в литературе, особенно сторонниками реинжиниринга бизнес-процессов (BPR), и предлагается немедленно начать определение целевого состояния.
Герман Й. Шмельцер и Вольфганг Сессельман , с другой стороны, обсуждают и оценивают критику радикального подхода к реинжинирингу бизнес-процессов (BPR) в литературе и «рекомендуют проводить анализ «как есть». Реорганизация должна знать текущие слабые места, чтобы иметь возможность их устранить. Результаты анализа также дают аргументы в пользу необходимости реинжиниринга процесса. Также важно знать исходную ситуацию для перехода от текущего состояния к целевому. Однако усилия по анализу должны находиться в узких пределах. Результаты анализа также не должны слишком сильно влиять на редизайн». [3] (Глава 6.2.2 Критическая оценка БПР) ← автоматический перевод с немецкого
Тимо Фюрманн объясняет: «После того как бизнес-процессы определены и названы, они теперь объединены в общий обзор. Такие обзоры называются картами процессов». [22] (Глава 2.4 Создание карты процесса) ← автоматический перевод с немецкого
Йорг Беккер и Фолькер Майзе приводят следующий список мероприятий по структурированию бизнес-процессов:
Структурирование бизнес-процессов обычно начинается с разграничения процессов управления , основных и вспомогательных процессов .
Поскольку основные бизнес-процессы, очевидно, составляют большую часть идентифицированных бизнес-процессов компании, общепринятой практикой стало еще раз подразделять основные процессы. В зависимости от типа компании и вида деятельности существуют разные подходы к этому. На эти подходы существенное влияние оказывают определенное применение моделирования бизнес-процессов и стратегия долгосрочного успеха моделирования бизнес-процессов .
В случае преимущественно рыночной стратегии часто определяются сквозные основные бизнес-процессы от клиента или поставщика до розничного торговца или клиента (например, «От предложения до заказа», «От заказа до счета», «От заказ – доставка», «От идеи к продукту» и др.). В случае стратегии, основанной на ресурсах, основные бизнес-процессы часто определяются на основе центральных корпоративных функций («Получение заказов», «Закупка и обеспечение материалами», «Разработка продуктов», «Оказание услуг» и т. д.). ).
При дифференцированном взгляде, без четкого акцента на взгляде на рынок или на взгляде на ресурсы, основные бизнес-процессы обычно делятся на CRM, PLM и SCM.
Однако распространены и другие подходы к структурированию основных бизнес-процессов, например, с точки зрения клиентов, продуктов или каналов продаж.
Результатом структурирования бизнес-процессов компании является карта процессов (представленная, например, в виде диаграммы цепочки создания стоимости ). Герман Й. Шмельцер и Вольфганг Сессельманн добавляют: «Между бизнес-процессами существуют связи и зависимости. Они основаны на передаче услуг и информации. Важно знать эти взаимосвязи, чтобы понимать, управлять и контролировать бизнес-процессы». [3] (Глава 2.4.3 Карта процесса) ← автоматический перевод с немецкого
Определение бизнес-процессов часто начинается с основных процессов компании, поскольку они
для компании
Объем бизнес-процесса следует выбирать таким образом, чтобы он содержал управляемое количество подпроцессов, сохраняя при этом общее количество бизнес-процессов в разумных пределах. Пять-восемь бизнес-процессов на бизнес-подразделение обычно охватывают диапазон производительности компании.
Каждый бизнес-процесс должен быть независимым, но процессы взаимосвязаны.
В определение бизнес-процесса входит: Какой результат должен быть достигнут по его завершению? Какие действия необходимы для достижения этой цели? Какие объекты необходимо обрабатывать (заказы, сырье, закупки, продукция...)? Определите начальную и конечную точку. Определение операционных целей.
В зависимости от корпоративной культуры (более открытой для изменений или более защищающей статус-кво) и коммуникации определение бизнес-процессов может быть легкой или сложной задачей – в зависимости от того, готовы ли ответственные члены организации (например, руководители отделов) поддержите это. В этом контексте коммуникация имеет большое значение, и Йорг Беккер и Фолькер Майзе поясняют: «Цель коммуникационной стратегии в мерах организационного проектирования»... (а за моделированием бизнес-процессов обычно следует оптимизация бизнес-процессов, т.е. изменение организация процесса – участвующие стороны знают это)… «должно быть убедить членов организации поддержать запланированную структуру». [7] (Глава 4.15 Влияние на разработку нормативной базы) ← автоматический перевод с немецкого Однако в случае значительного сопротивления для определения бизнес-процессов можно также использовать внешние знания.
Йорг Беккер и Фолькер Мейзе упоминают два подхода ( общая идентификация процесса и идентификация индивидуального процесса ) и утверждают следующее об общей идентификации процесса: «В общем определении процесса предполагается, что существуют базовые, общезначимые процессы, одинаковые во всех компаниях. .» Далее говорится: «Детальные эталонные модели также могут использоваться для общей идентификации процесса. Они описывают отраслевые или прикладные системные процессы организации, которые еще нуждаются в адаптации к индивидуальному случаю, но уже согласованы в своей структуре». [7] (Глава 4.11 Общая идентификация процесса) ← автоматический перевод с немецкого
Йорг Беккер и Фолькер Майзе говорят об идентификации отдельных процессов следующее: «При идентификации индивидуальных или единичных процессов предполагается, что процессы в каждой компании различаются в зависимости от потребностей клиентов и конкурентной ситуации и могут быть идентифицированы индуктивно на основе индивидуальной проблемы. ситуация.» [7] (Глава 4.12 Идентификация индивидуального процесса) ← автоматический перевод с немецкого
Результатом определения бизнес-процессов обычно является приблизительная структура бизнес-процессов в виде диаграммы цепочки создания стоимости .
Грубая структура бизнес-процессов, созданная до сих пор, теперь будет разложена на подпроцессы, которые имеют свои собственные атрибуты, но также способствуют достижению цели бизнес-процесса. На эту декомпозицию должно существенно влиять применение и стратегия для долгосрочного успеха моделирования бизнес-процессов, и ее следует продолжать до тех пор, пока адаптация определенных таким образом подпроцессов способствует реализации цели и стратегии .
Подпроцесс, созданный таким образом, использует модель для описания способа выполнения процедур для достижения намеченных операционных целей компании. Модель представляет собой абстракцию реальности (или целевого состояния), и ее конкретная форма зависит от предполагаемого использования (приложения).
При необходимости дальнейшая декомпозиция подпроцессов может быть произведена в ходе моделирования бизнес-процессов. Если бизнес-процесс можно представить как последовательность этапов, разделенных контрольными точками , то декомпозиция на этапы является обычным явлением. Там, где это возможно, перенос вех на следующий уровень декомпозиции способствует общему пониманию.
Результатом дальнейшего структурирования бизнес-процессов обычно является иерархия подпроцессов, представленная в виде диаграмм цепочек создания стоимости . Обычно не все бизнес-процессы имеют одинаковую глубину декомпозиции. В частности, бизнес-процессы, которые не связаны с безопасностью, не являются затратоемкими и не способствуют достижению операционной цели, разбиваются на гораздо меньшую глубину. Аналогичным образом, в качестве предварительного этапа декомпозиции процесса, запланированного (намного) позже, общее понимание может быть сначала достигнуто с использованием более простых/менее сложных средств, чем диаграммы цепочки создания стоимости , - например, с помощью текстового описания или диаграммы-черепахи [22]. (Глава 3.1 Определение деталей процесса) ← автоматический перевод с немецкого (не путать с изображением черепахи !).
Полные, автономные процессы обобщаются и передаются ответственному лицу или команде. Владелец процесса несет ответственность за успех, создает рамочные условия и координирует свой подход с подходом других владельцев процессов (см. также « Подотчетность» в RACI ). Кроме того, он/она отвечает за обмен информацией между бизнес-процессами. Эта координация необходима для достижения общей целевой ориентации.
Если бизнес-процессы документируются с использованием конкретной ИТ-системы и представления, например, графического, это обычно называется моделированием. Результатом документирования является модель бизнес-процесса .
Вопрос о том, должна ли модель бизнес-процесса создаваться посредством моделирования «как есть» или быть моделированием , существенно зависит от определенного применения и стратегии долгосрочного успеха моделирования бизнес-процессов . Предыдущая процедура с анализом бизнес-деятельности, определением бизнес-процессов и дальнейшим структурированием бизнес-процессов целесообразна в любом случае.
Ансгар Швегманн и Михаэль Ласке поясняют: «Определение текущего состояния является основой для выявления слабых сторон и локализации потенциала для улучшения. Например, можно выявить такие слабые места, как организационные разломы или недостаточное проникновение ИТ». [23] (Глава 5.1 Цель моделирования ) ← автоматический перевод с немецкого языка
Против моделирования говорят следующие недостатки :
Эти аргументы особенно весомы, если реинжиниринг бизнес-процессов (BPR) все равно планируется.
Ансгар Швегманн и Михаэль Ласке также перечисляют ряд преимуществ моделирования «как есть» : [23] (Глава 5.1 Цель моделирования «как есть») ← автоматический перевод с немецкого
Можно найти и другие преимущества, например
Марио Спек и Норберт Шнетгоке определяют задачу моделирования следующим образом: «Целевые процессы основаны на стратегических целях компании. Это означает, что все подпроцессы и отдельные виды деятельности компании должны быть проанализированы на предмет их целевого вклада. Поэтому подпроцессы или виды деятельности, которые не могут быть идентифицированы как добавляющие ценность и не служат хотя бы одной неденежной корпоративной цели, должны быть исключены из бизнес-процессов». [8] (Глава 6.2.3 Захват и документирование моделей )
Они также перечисляют пять основных принципов, которые доказали свою ценность при создании будущих моделей:
Модель бизнес-процесса, созданная методом «как есть» или «будет моделировать», состоит из:
Говорят, что Август В. Шеер сказал в своих лекциях: « Процесс есть процесс есть процесс». Это предназначено для выражения рекурсивности термина, поскольку почти каждый процесс можно разбить на более мелкие процессы (подпроцессы). В этом отношении такие термины, как бизнес-процесс , основной процесс , подпроцесс или элементарный процесс, являются лишь отчаянной попыткой обозначить уровень декомпозиции процесса. Поскольку не существует универсального соглашения о детализации бизнес-процесса , основного процесса , подпроцесса или элементарного процесса , эти термины не имеют универсального определения, но могут быть поняты только в контексте соответствующей модели бизнес-процесса.
Кроме того, в некоторых немецкоязычных школах бизнес-информатики не используются термины процесс (в смысле представления последовательности действий (деятельности) ) и функция (в смысле разграниченной корпоративной функции / области действия (деятельности), то есть явно закреплен за владельцем корпоративной функции ).
Например, в ARIS Августа В. Шеера можно использовать функции из представления функций в качестве процессов в представлении управления и наоборот. Хотя это имеет то преимущество, что уже определенные процессы или функции могут быть повторно использованы повсюду, это также означает, что правильная цель представления функций размывается, и пользователь ARIS больше не может отделять процессы и функции друг от друга.
На первом изображении в виде диаграммы цепочки создания стоимости показано, как бизнес-процесс «Редактирование конвейера продаж» разбит на подпроцессы (в смысле представления последовательности действий (действий) ) на основе его фаз.
На втором изображении показан фрагмент типовых функций (в смысле разграничения корпоративных функций / областей действий (деятельности) , закрепленных за владельцем корпоративных функций ), которые структурированы на основе иерархии областей компетенции и ответственности. В дереве функций отмечены корпоративные функции , поддерживающие бизнес-процесс Редактировать воронку продаж .
Бизнес-процесс можно разложить на подпроцессы до тех пор, пока дальнейшее разложение не перестанет быть значимым/возможным (наименьший значимый подпроцесс = элементарный процесс ). Обычно все уровни декомпозиции бизнес-процесса документируются одной и той же методологией: Символы процесса. Символы процессов, используемые при моделировании одного уровня декомпозиции, обычно относятся к подпроцессам следующего уровня, пока не будет достигнут уровень элементарных процессов . Диаграммы цепочки создания стоимости часто используются для представления бизнес-процессов , основных процессов , подпроцессов и элементарных процессов .
Рабочий процесс — это представление последовательности задач, заявленных как работа человека, простого или сложного механизма, группы людей, [24] организации персонала или машин (включая ИТ-системы). Таким образом, рабочий процесс всегда находится на уровне элементарного процесса. Рабочий процесс можно рассматривать как любую абстракцию реальной работы, разделенную на совместную работу, разделение работы или другие типы упорядочения. В целях контроля рабочий процесс может представлять собой представление реальной работы в выбранном аспекте.
Термин функции часто используется как синоним разграниченной корпоративной функции / области действия (activita) , закрепленной за владельцем корпоративной функции , и атомарной деятельности (задачи) на уровне элементарных процессов . Чтобы избежать двойного значения термина « функция» , термин « задача» можно использовать для обозначения атомарных действий на уровне элементарных процессов в соответствии с именованием в BPMN . Современные инструменты также предлагают автоматическое преобразование задачи в процесс , так что можно в любой момент создать дальнейший уровень декомпозиции процесса, на котором задачу затем необходимо повысить до элементарного процесса .
Графические элементы, используемые на уровне элементарных процессов, затем описывают (временно-логическую) последовательность с помощью функций ( задач ). Последовательность функций ( задач ) внутри элементарных процессов определяется их логической связью друг с другом ( логическими операторами или Шлюзами ), если она еще не задана отношениями ввода/вывода или Вехами . Обычно используются дополнительные графические элементы для иллюстрации интерфейсов, состояний (событий), условий (правил), контрольных точек и т. д., чтобы лучше прояснить процесс. В зависимости от используемого инструмента моделирования используются самые разные графические |представления ( модели ).
Кроме того, функции ( задачи ) могут быть дополнены графическими элементами для описания входов, выходов, систем, ролей и т.п. с целью повышения точности описания и/или увеличения количества деталей. Однако эти дополнения быстро делают модель запутанной. Чтобы разрешить противоречие между точностью описания и ясностью, есть два основных решения: передать дополнительные графические элементы для описания входов, выходов, систем, ролей и т. д. в диаграмму распределения функций (FAD) или выборочно показать/скрыть эти элементы в зависимости от по вопросу/заявке. Схема распределения функций, представленная на изображении , очень хорошо иллюстрирует добавление к функциям ( задачам ) графических элементов для описания входов, выходов, систем, ролей и т. д .
Термин «основные данные» не определен ни The Open Group ( The Open Group Architecture Framework , TOGAF), ни Джоном А. Захманом ( Zachman Framework ), ни какой-либо из пяти соответствующих немецкоязычных школ бизнес- информатики : 1) Август В. Шеер , 2) Хуберт Остерле , 3) Отто К. Ферстль и Эльмар Дж. Синц , 4) Герман Геринг и 5) Андреас Гадач и обычно используется при отсутствии подходящего термина в литературе. Он основан на общем термине для данных , которые представляют собой базовую информацию об оперативно важных объектах и относятся к базовой информации, которая не является первичной информацией бизнес-процесса.
Для Августа В. Шеера из ARIS это будет основная информация представления организации , представления данных , представления функций и представления производительности . [25] (Глава 1. Видение: общий язык для ИТ и менеджмента) ← автоматический перевод с немецкого (см. также «Карта компании» (немецкий))
Для Андреаса Гадача в GPM ( G anzheitliche Prozess modellierung (нем.), означает целостное моделирование процессов ) это будет основная информация о представлении организационной структуры , представлении структуры деятельности , представлении структуры данных и представлении структуры приложения . [1] (Глава 3.2 GPM – Моделирование целостного процесса) ← автоматический перевод с немецкого (см. также «Карта компании» (немецкий))
Для Отто К. Ферстла и Эльмара Дж. Синца в SOM ( модель семантического объекта ) это будет основная информация уровней «Бизнес-план» и « Ресурсы» . (см. также «Карта компании» (на немецком языке))
Основными данными могут быть, например (см. также раздел Определение функциональных требований для моделирования бизнес-процессов):
Добавляя основные данные к моделированию бизнес-процессов, одну и ту же модель бизнес-процесса можно использовать для разных приложений , а окупаемость инвестиций в моделирование бизнес-процессов может быть достигнута быстрее за счет синергии.
В зависимости от того, какое значение придается основным данным при моделировании бизнес-процессов, все равно возможно встроить основные данные в модель процесса без негативного влияния на читаемость модели, или основные данные следует передать в отдельное представление, например, Функция Диаграммы распределения.
Если основные данные систематически добавляются в модель бизнес-процесса, это называется моделью бизнес-процесса, ориентированной на артефакты .
Модель бизнес-процессов, ориентированная на артефакты, стала целостным подходом к моделированию бизнес-процессов, поскольку она обеспечивает очень гибкое решение для сбора эксплуатационных характеристик бизнес-процессов. Особое внимание уделяется описанию данных бизнес-процессов, известных как «артефакты», путем характеристики объектов данных, имеющих отношение к бизнесу, их жизненных циклов и связанных с ними услуг. Подход к моделированию процессов, ориентированный на артефакты, способствует автоматизации бизнес-операций и поддерживает гибкость внедрения и развития рабочих процессов. [26]
Интеграция внешних документов и ИТ-систем может существенно повысить добавленную стоимость модели бизнес-процесса.
Например, прямой доступ к объектам в базе данных знаний или документам в структуре правил может значительно увеличить преимущества модели бизнес-процессов в повседневной жизни и, следовательно, признание моделирования бизнес-процессов. Все задействованные ИТ-системы могут использовать свои конкретные преимущества и взаимно дополнять друг друга (например, связываться друг с другом или стандартизировать структуру документации):
Если все соответствующие объекты базы знаний и/или документы структуры правил подключены к процессам, конечные пользователи имеют контекстно-зависимый доступ к этой информации и не должны быть знакомы с соответствующей структурой файлов подключенных систем.
Прямое подключение внешних систем также можно использовать для интеграции текущих результатов измерений или состояний систем в процессы (и, например, для отображения текущего рабочего состояния процессов), для отображения виджетов и отображения выходных данных внешних систем или для перехода к внешним системам и инициировать там транзакцию с помощью предварительно настроенного диалога.
Дополнительные подключения к внешним системам могут использоваться, например, для электронного обмена данными (EDI).
Речь идет о проверках, нет ли дублирования. Если да, то соответствующие подпроцессы объединяются. Или подпроцессы, которые используются более одного раза, передаются на аутсорсинг для поддержки процессов. Для успешной консолидации модели может потребоваться пересмотреть исходную декомпозицию подпроцессов.
Ансгар Швегманн и Михаэль Ласке поясняют: «Чтобы получить целостную модель, необходима консолидация моделей разных модельных комплексов». [23] (Глава 5.2.4 Консолидация модели) ← автоматический перевод с немецкого Они также перечисляют ряд аспектов, для которых важна консолидация модели:
Цепочка подпроцессов друг с другом и цепочка функций ( задач ) в подпроцессах моделируется с помощью Control Flow Patterns .
Существенные детали цепочки (что предшественник доставляет преемнику?) указываются в интерфейсах процесса, если это предусмотрено.
Интерфейсы процессов определяются для того, чтобы
Как правило, это что и его структура определяются требованиями в последующем процессе.
Интерфейсы процесса представляют собой выход из текущего бизнес-процесса/подпроцесса и вход в последующий бизнес-процесс/подпроцесс.
Таким образом, интерфейсы процессов являются элементами описания для связывания процессов по разделам. Интерфейс процесса может
Интерфейсы процессов согласовываются между участниками вышестоящих/подчиненных или соседних моделей бизнес-процессов. Они определяются и связываются один раз и используются в моделях процессов так часто, как это необходимо .
Интерфейсы могут определяться:
В реальном выражении передаваемые входы/выходы часто представляют собой данные или информацию, но возможны и любые другие бизнес-объекты (материал, продукция в конечном или полуфабрикатном состоянии, документы, такие как накладная). Они предоставляются через подходящие транспортные средства (например, хранилище данных в случае данных).
См. статью Управление бизнес-процессами .
Для внедрения улучшенных бизнес-процессов на практике обычно требуются программы управления изменениями . Благодаря достижениям в разработке программного обеспечения представление о полностью реализуемых моделях BPM (с возможностью моделирования и комплексного проектирования) становится все ближе к реальности.
В управлении бизнес-процессами технологические потоки регулярно пересматриваются и при необходимости оптимизируются (адаптируются). Независимо от того, вызвана ли эта адаптация потоков процессов непрерывным улучшением процессов или реорганизацией процессов ( реинжинирингом бизнес-процессов ), она влечет за собой обновление отдельных подпроцессов или всего бизнес-процесса.
На практике распространены комбинации неформальных , полуформальных и формальных моделей: неформальные текстовые описания для объяснения, полуформальное графическое представление для визуализации и формальное языковое представление для поддержки моделирования и перевода в исполняемый код.
Существуют различные стандарты обозначений; наиболее распространенными являются:
Более того:
Кроме того, также можно использовать типы представления из архитектуры программного обеспечения :
Модель и нотация бизнес-процессов (BPMN) — это графическое представление для определения бизнес-процессов в модели бизнес-процессов.
Первоначально разработанная Инициативой по управлению бизнес-процессами (BPMI), BPMN поддерживается Группой управления объектами (OMG) с момента слияния двух организаций в 2005 году. Версия 2.0 BPMN была выпущена в январе 2011 года, [30] после чего название были внесены поправки в Модель бизнес-процесса и нотацию, чтобы отразить введение семантики выполнения, которая была введена наряду с существующими элементами нотации и диаграмм. Хотя это спецификация OMG, BPMN также ратифицирован как ISO 19510. Последней версией является BPMN 2.0.2, опубликованная в январе 2014 года. [31]
Цепочка процессов, управляемая событиями (EPC), — это тип блок-схемы моделирования бизнес-процессов. EPC можно использовать для настройки выполнения планирования ресурсов предприятия , а также для улучшения бизнес-процессов . Его можно использовать для управления экземпляром автономного рабочего процесса при совместном использовании работы.
Метод цепочки событий, управляемых событиями, был разработан в рамках архитектуры интегрированных информационных систем (ARIS) Августом-Вильгельмом Шеером в Institut für Wirtschaftsinformatik, Universität des Saarlandes (Институт систем бизнес-информации при Университете Саара) в начале 1990-е годы. [32]Сеть Петри , также известная как сеть мест/переходов (PT), является одним из нескольких языков математического моделирования для описания распределенных систем . Это класс дискретно-событийной динамической системы . Сеть Петри представляет собой ориентированный двудольный граф , имеющий два типа элементов: места и переходы. Элементы места изображаются в виде белых кружков, а элементы перехода — в виде прямоугольников. Место может содержать любое количество жетонов, обозначенных черными кружками. Переход разрешен, если все места, подключенные к нему в качестве входов, содержат хотя бы один токен. В некоторых источниках [33] утверждается, что сети Петри были изобретены в августе 1939 года Карлом Адамом Петри — в возрасте 13 лет — с целью описания химических процессов.
Подобно отраслевым стандартам, таким как диаграммы деятельности UML , модель и нотация бизнес-процессов , а также цепочки процессов, управляемых событиями , сети Петри предлагают графическую нотацию для пошаговых процессов, включающих выбор, итерацию и одновременное выполнение . В отличие от этих стандартов , сети Петри имеют точное математическое определение семантики их выполнения, а также хорошо развитую математическую теорию анализа процессов .
Блок -схема — это тип диаграммы , которая представляет рабочий процесс или процесс . Блок-схему также можно определить как схематическое представление алгоритма , пошагового подхода к решению задачи.
На блок-схеме шаги показаны в виде блоков разных типов, а их порядок показан путем соединения блоков стрелками. Это схематическое представление иллюстрирует модель решения данной проблемы . Блок-схемы используются при анализе, проектировании, документировании или управлении процессом или программой в различных областях. [34]
Язык моделирования жизненного цикла (LML) — это язык моделирования с открытым стандартом, предназначенный для системного проектирования . Он поддерживает полный жизненный цикл : этапы разработки, использования, поддержки и вывода из эксплуатации. Наряду с интеграцией всех дисциплин жизненного цикла, включая управление программами , системное проектирование , верификацию и валидацию , развертывание и обслуживание, в одну структуру. [38] LML изначально был разработан руководящим комитетом LML. Спецификация была опубликована 17 октября 2013 года.
Это язык моделирования, такой как UML и SysML , который поддерживает дополнительные возможности управления проектами, такие как анализ рисков и планирование. LML использует общий язык для определения элементов моделирования, таких как сущность, атрибут, график, стоимость и взаимосвязь. [39]Субъектно-ориентированное управление бизнес-процессами (S-BPM) — это взгляд на участников (субъектов), основанный на коммуникации, которые составляют оркестровку или хореографию бизнес-процессов. [40] Парадигма моделирования использует пять символов для моделирования любого процесса и позволяет осуществлять прямое преобразование в исполняемую форму.
Каждый бизнес-процесс состоит из двух или более субъектов , которые обмениваются сообщениями . Каждый субъект имеет внутреннее поведение (капсуляцию), которое определяется как поток управления между различными состояниями, которые принимают и отправляют сообщения и что-то делают . Для практического использования и синтаксического улучшения доступно больше элементов, но это не обязательно.
В 2011 и 2012 годах S-BPM был включен в Hype Cycle компании Gartner .Метод анализа информации на естественном языке с улучшением когнитивных функций (CogNIAM) — это концептуальный метод моделирования, основанный на фактах , целью которого является интеграция различных измерений знаний: данных, правил, процессов и семантики. Для представления этих измерений используются мировые стандарты SBVR , BPMN и DMN от Object Management Group (OMG). CogNIAM, преемник NIAM , основан на работах ученого-знатока Сжира Нейссена . [ нужна цитата ]
CogNIAM структурирует знания, полученные от людей, документации и программного обеспечения, путем их классификации. Для этой цели CogNIAM использует так называемый «Треугольник знаний». [41] Результат CogNIAM не зависит от того, кто его применяет. Полученная модель позволяет выражать знания в схематической форме , а также на контролируемом естественном языке . [42]
Унифицированный язык моделирования (UML) — это язык визуального моделирования общего назначения , предназначенный для обеспечения стандартного способа визуализации проекта системы. [45]
UML предоставляет стандартные обозначения для многих типов диаграмм, которые можно условно разделить на три основные группы: диаграммы поведения, диаграммы взаимодействия и структурные диаграммы.
Создание UML изначально было мотивировано желанием стандартизировать разрозненные системы обозначений и подходы к разработке программного обеспечения. Он был разработан в Rational Software в 1994–1995 годах, а дальнейшая разработка проводилась под их руководством до 1996 года. [45]
В 1997 году UML был принят в качестве стандарта Группой управления объектами (OMG) и с тех пор находится под управлением этой организации. В 2005 году UML был также опубликован Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC) как стандарт ISO/IEC 19501. [46] С тех пор стандарт периодически пересматривался, чтобы охватить последнюю версию UML. [47]
В разработке программного обеспечения большинство специалистов не используют UML, а вместо этого создают неформальные диаграммы, нарисованные от руки; однако эти диаграммы часто включают элементы UML. [48] : 536
IDEF , первоначально аббревиатура ICAM Definition и переименованная в 1999 году в Integration Definition, представляет собой семейство языков моделирования в области системной и программной инженерии. Они охватывают широкий спектр применений: от функционального моделирования до моделирования данных, объектно-ориентированного анализа и проектирования, а также приобретения знаний. Эти языки определений были разработаны при финансовой поддержке ВВС США и, хотя они до сих пор наиболее часто используются ими и другими военными и агентствами Министерства обороны США (DoD), находятся в свободном доступе.
Наиболее широко признанными и используемыми компонентами семейства IDEF являются IDEF0, язык функционального моделирования, основанный на SADT, и IDEF1X, который решает проблемы информационных моделей и проектирования баз данных.
Моделирование процессов по Харбариану (HPM) — это метод получения информации о внутренних процессах организации и последующего документирования этой информации в визуально эффективной и простой форме.
Метод HPM включает в себя два уровня:
Инструменты моделирования бизнес-процессов предоставляют бизнес-пользователям возможность моделировать свои бизнес-процессы, внедрять и выполнять эти модели, а также уточнять модели на основе фактических данных. В результате инструменты моделирования бизнес-процессов могут обеспечить прозрачность бизнес-процессов, а также централизацию корпоративных моделей бизнес-процессов и показателей выполнения. [50] Инструменты моделирования могут также обеспечить возможность совместного моделирования сложных процессов пользователями, работающими в группах, где пользователи могут совместно использовать модели и моделировать их. [51] Инструменты моделирования бизнес-процессов не следует путать с системами автоматизации бизнес-процессов — в обеих практиках моделирование процесса является одним и тем же начальным шагом, и разница в том, что автоматизация процесса дает вам «исполняемую диаграмму», которая радикально отличается от традиционного графического представления. инструменты моделирования бизнес-процессов. [ нужна цитата ]
Программное обеспечение пакета BPM предоставляет программные интерфейсы (веб-сервисы, интерфейсы прикладных программ (API)), которые позволяют создавать корпоративные приложения с использованием механизма BPM. [50] Этот компонент часто называют движком пакета BPM.
Языки программирования, которые вводятся для BPM, включают: [52]
Некоторые языки, специфичные для конкретного поставщика:
Другие технологии, связанные с моделированием бизнес-процессов, включают архитектуру, управляемую моделями, и сервис-ориентированную архитектуру .
Функциональность моделирования таких инструментов позволяет предварительно выполнить моделирование «что, если» (которое имеет особые требования для этого приложения) и симуляцию. Оптимизация после выполнения доступна на основе анализа фактических показателей выполнения. [50]
Справочная модель бизнеса — это эталонная модель, концентрирующая внимание на функциональных и организационных аспектах предприятия , обслуживающей организации или государственного учреждения . В общем, эталонная модель — это модель чего-то, которая воплощает основную цель или идею чего-то и которую затем можно рассматривать как эталонную для различных целей. Справочная бизнес-модель — это средство описания бизнес-операций организации независимо от организационной структуры, которая их выполняет. Другие типы эталонной бизнес-модели также могут отображать взаимосвязь между бизнес-процессами, бизнес-функциями и эталонной бизнес-моделью бизнес-сферы. Эти эталонные модели могут быть построены по слоям и служить основой для анализа компонентов услуг, технологий, данных и производительности.
Наиболее известной эталонной бизнес-моделью является эталонная бизнес-модель федерального правительства США. Эта модель представляет собой функциональную основу для описания бизнес-операций федерального правительства, независимых от агентств, которые их выполняют. Справочная бизнес-модель представляет собой организованную иерархическую конструкцию для описания повседневной деловой деятельности федерального правительства. Хотя существует множество моделей для описания организаций – организационные схемы , карты местоположения и т. д. – эта модель представляет бизнес с использованием функционально-ориентированного подхода. [54]
Бизнес -модель , которую можно рассматривать как разработку модели бизнес-процесса, обычно отображает бизнес-данные и бизнес-организации, а также бизнес-процессы. Показывая бизнес-процессы и их информационные потоки, бизнес-модель позволяет заинтересованным сторонам бизнеса определить, понять и проверить свое бизнес-предприятие. Часть бизнес-модели, связанная с моделью данных , показывает, как хранится бизнес-информация, что полезно для разработки программного кода . На рисунке справа показан пример взаимодействия моделей бизнес-процессов и моделей данных. [55]
Обычно бизнес-модель создается после проведения собеседования, которое является частью процесса бизнес-анализа . Собеседование состоит из того, что ведущий задает ряд вопросов для получения информации о рассматриваемом бизнес-процессе. Интервьюера называют координатором, чтобы подчеркнуть, что информацию о бизнес-процессе предоставляют участники, а не координатор. Хоть фасилитатор и должен обладать некоторыми знаниями предметного бизнес-процесса, но это не так важно, как владение прагматичным и строгим методом интервьюирования бизнес-экспертов. Этот метод важен, поскольку для большинства предприятий необходима группа координаторов для сбора информации по всему предприятию, а результаты всех интервьюеров должны быть собраны и интегрированы после завершения. [55]
Бизнес-модели разрабатываются как определяющие либо текущее состояние процесса (в этом случае конечный продукт называется моделью моментального снимка «как есть»), либо концепцию того, каким должен стать процесс, в результате чего получается модель «как должно быть». Сравнивая и противопоставляя модели «как есть» и «как должно быть», бизнес-аналитики могут определить, являются ли существующие бизнес-процессы и информационные системы надежными и нуждаются лишь в незначительных модификациях, или же для устранения проблем или повышения эффективности требуется реинжиниринг. Следовательно, моделирование бизнес-процессов и последующий анализ могут быть использованы для фундаментального изменения способа ведения деятельности предприятия. [55]
Реинжиниринг бизнес-процессов (BPR) направлен на повышение эффективности и результативности процессов , существующих внутри и между организациями. Он исследует бизнес-процессы с точки зрения «чистого листа», чтобы определить, как лучше всего их построить.
Реинжиниринг бизнес-процессов (BPR) начался как метод частного сектора, призванный помочь организациям фундаментально переосмыслить то, как они выполняют свою работу. Ключевым стимулом для реинжиниринга стала разработка и внедрение сложных информационных систем и сетей. Ведущие организации используют эту технологию для поддержки инновационных бизнес-процессов, а не для совершенствования существующих способов выполнения работы. [56]
См. статью Управление бизнес-процессами .
Программы управления изменениями обычно используются для реализации на практике улучшенных бизнес-процессов. Благодаря достижениям в разработке программного обеспечения идея о том, что модели BPM станут полностью исполняемыми (и способными к моделированию и комплексному проектированию), становится все ближе к реальности.
В управлении бизнес-процессами потоки процессов регулярно пересматриваются и при необходимости оптимизируются (адаптируются). Независимо от того, вызвана ли эта адаптация потоков процессов постоянным улучшением процесса или реинжинирингом бизнес -процессов, она влечет за собой обновление отдельных подпроцессов или всего бизнес-процесса.
{{cite book}}: CS1 maint: несколько имен: список авторов ( ссылка )
СМИ, связанные с моделированием бизнес-процессов, на Викискладе?