Моделирование бизнес-процессов — это деятельность, в ходе которой формируются модели функционирования организаций, в которой описываются различные процессы, связи между ними, информационные системы, персонал, ресурсы и многое другое.
Моделирование деятельности подразумевает создание модели, адекватно отражающей реальный объект — организацию. [7]
При помощи моделирования бизнес-процессов можно анализировать как внутреннюю деятельность организации (деятельность организации в целом, деятельность отдельных структурных подразделений), так и внешнюю (проанализировать ее взаимодействие с внешними заказчиками, поставщиками). На мой взгляд, наличие таких данных о внешней и внутренней деятельности организации необходимо для руководства, поскольку оно позволяет быть более компетентным в вопросах улучшения работы компании.
Наличие комплексной модели предприятия является основой для выполнения следующих работ:
- · проведения анализа, оценки и внесения предложений по совершенствованию деятельности предприятия;
- · разработки автоматизированной системы управления предприятием;
- · разработки системного проекта и внедрения корпоративной информационной системы (КИС), поддерживающей систему управления;
- · подготовки и проведения процедуры сертификации предприятия в соответствии с требованиями международных стандартов качества серии ИСО 9000 [8]
Поскольку процессный подход предполагает изменение направления вектора труда от вертикального (на начальника) к горизонтальному (на заказчика), моделирование бизнес-процессов помогает лучше понимать рядовым сотрудникам и руководству, на что ориентирован результат их деятельности.
Лучшие практики построения процесса закупок. SCOR-модель
Преимущество моделирования бизнес-процесса заключается в том, что избегаются риски получения неудовлетворительных результатов при использовании новых приемов ведения бизнеса. Модель можно изменять и наблюдать результат, не прибегая при этом к реальным изменениям в процессах компании. Это значит, что моделирование бизнес-процессов может сократить издержки на совершенствование деятельности компании, которое является вынужденным мероприятием в современном мире.
Моделирование деятельности организации — это процесс документирования работы предприятия в целом или какой-либо предметной области предприятия, его целей, задач, различных ресурсов. Такое определение можно использовать, если самой модели деятельности еще не существует. В противном случае, в моделирование помимо документирования можно отнести также процессы анализа и оптимизации работы.
Моделирование бизнес-процессов основывается на некоторых принципах. Таким образом, модель строится с учетом целей моделирования, поэтому в ней должны быть четко определены методы, которые будут использоваться.
При моделировании деятельности организации необходимо руководствоваться эталонными и референтными моделями. Эталонные модели — это такие модели, которые уже включают себя базовый набор процессов верхнего уровня, построенный на основе лучших практик в бизнесе. Референтную же модель можно рассматривать как частный случай эталонной, различие заключается в том, что эталонная модель может быть использована для любой организации, а референтная модель привязана к какой-либо отдельной отрасли.
Источник: studwood.net
Концепции моделирования бизнес-процессов
Термин «моделирование» во многих случаях применяется в двух трактовках: как процесс создания модели системы и как процесс изучения модели ее функционирования. Помимо этого, есть такое понятие, как «имитационное моделирование». Оно поддерживается рядом инструментальных средств (ARIS, Business Studio и др.).
Наличие моделей, включающих все подпроцессы организации, может составлять основу для выполнения таких работ, как:
анализ, оценка и внесение предложений, направленных на оптимизацию функционирования организации;
разработка АСУ организацией, проекта запуска комплексной информационной системы организации;
подготовка и проведение сертификации организации согласно требованиям качества ISO серии 9000: 2000.
В моделировании бизнес-процессов эталонные и референтные модели.
Эталонная модель — это модель, основанная на базе экспертного мнения ведущих консалтинговых и коммерческих учреждений на совокупность необходимых процессов в организации. Она считается обобщением передового международного опыта управления коммерцией в различных сферах экономической деятельности.
В качестве примера эталонных моделей можно привести предложенную Международной бенчмаркинговой палатой (International Benchmarking Clearinghouse) 12-процессную модель, которую можно использовать для определения системы бизнес-процессов в отдельной организации в качестве отправной точки (рисунок 1.2).
Рисунок 1.2 — Процессная эталонная модель бизнес-процессов
Референтная модель считается эталонной моделью создания и управления бизнесом для конкретной сферы экономической деятельности. Данное представление (референтная модель) возникла в среде консалтинговых организаций в сфере управления процессами и внедрения ERP-систем. В этих моделях представлены типовые бизнес-процессы, применимые для различных областей деятельности. В качестве примера референтной модели можно привести модель цепи поставок (SCOR — Supply Chain Operations Reference model). Она основана на 4 процессах: планирование (Plan), снабжение (Supply), изготовление (Make) и распределение советом по цепям поставок (Supply Chain Counsil, SCC) в качестве межотраслевого стандарта управления цепями поставок.
В данных моделях разработаны типовые бизнес-процессы верхнего уровня, а также связи (горизонтальные и вертикальные). Второй тип моделей (референтные модели) применяется организациями с целью разработки собственных моделей, используя референтные модели в качестве отправной точки.
Существенные достоинства применения референтных моделей заключаются в том, что можно не тратить усилия, финансы и время на создание новой процессной модели. Достаточно взять уже существующую референтную модель и изменить ее применительно к конкретной организации. При этом немаловажно принять во внимание, что референтная модель может включать далеко не все процессы, а также вертикальные и горизонтальные связи, которые должны быть в конкретном бизнесе. В итоге можно сказать, что референтные модели — это отправная точка для формирования собственной процессной модели каждой конкретной организации.
ARIS содержит ряд различных методологий моделирования и обеспечивает системный подход к их интеграции между собой. Она поддерживает 5 классов моделей:
организационные модели — включают описание организационной структуры, различных подразделений, типов должностей (отдельных лиц) и связей между ними и ряд других элементов организационной структуры компании, а кроме того обеспечивают прикрепление подразделений организаций к их физическому расположению;
модели данных — описывают всю совокупность и структуру информации, используемой при анализе работы компании;
модели функций — включают описание совокупности целей деятельности компании, функций, выполнение которых обеспечит достижение установленных целей, и ряда других функциональных аспектов деятельности компании;
модели процессов — объединяют в единое целое сведения из различных моделей с целью предоставления единого комплексного видения деятельности компании в разрезе формализованных бизнес-процессов;
модели входов/выходов (продуктов и услуг).
В бизнес-процессах открываются организационные, структурные и технические проблемы, и кроме того обнаруживаются ресурсы для их улучшения.
При использовании ARIS Strategy Platform возможно формирование целевых систем сбалансированных показателей (Balanced Scorecard) и ориентация на них бизнес-процессов. Вместе с этим достигается прозрачность расходов, связанных с выполнением процессов в организации, что гарантирует возможность выполнения внутреннего бенчмаркинга. Кроме того, при этом обнаруживаются потенциальные возможности по увеличению производительности.
ARIS Strategy Platform дает следующие возможности:
стратегическое планирование деятельности организации на основе показателей;
введение системы сбалансированных показателей в масштабах предприятия;
прозрачность затрат при планировании и контроллинге процессов;
анализ типа «что, если» (What-if) для принятия стратегических решений.
Итак, после описания процессов верхнего уровня возможен переход к очередному уровню детализации — сценариям процессов. В зависимости от используемого сценария процесс будет протекать по-разному.
В таблице 1.2 представлена сравнительная характеристика методик моделирования бизнес-процессов.
Таблица 1.2 — Характеристика методик моделирования бизнес-процессов
Достоинства и недостатки
Функционирует на основе стандартов ISO9000. Результатом моделирования является схема, которая описывает бизнес-процесс в привязке к структуре управления предприятия.
Легкое и четкое описание бизнес-процессов. Накопленный опыт применения
SADT/ IDEF0, IDEF3
Схема является основным компонентом модели. Данная методика применяется в случаях формирования новых бизнес-процессов для введения ограничений к бизнес-процессам, а затем при разработке бизнес-процессов. Методика позволяет работать с существующими бизнес-процессами по средствам анализа выполняемых ими функций и документирования механизмов, которыми достигается поставленные цели.
Предоставляет возможность демонстрации управленческих воздействий на анализируемые процессы. Разрабатываемые модели легко интерпретируются в отличие от других методик. Методика не может применяться при описании динамики исполнения анализируемого процесса.
Предусматривается системный подход к описанию бизнес-процессов с четко обозначенными абстракциями, описания. Разрабатываются и предлагаются механизмы совершенствования бизнес-процессов.
Существуют языковые трудности. Отсутствует качественный перевод и адаптация на русский язык. Методика не описывает сложные исследуемые бизнес-процессы. Упрощает работу руководителя процесса в управлении им.
Используются при описании системы документооборота и обработки необходимой информации. Позволяет анализировать функции обработки информации, документы, объекты, персонал, которые участвуют в подготовке и обработке информации, а также таблицы для хранения документов. Для описания набора работ.
Эффективное и простое описание процесса документооборота.
Используется высокий уровень проектирования с применением специфики, визуализации, конструирования и документирования. Применяются схемы классов, кооперации, взаимодействия, активности.
Вносит ряд ограничений в процесс кодировки и позволяет устанавливать стандарт разработки программного кода.
Позволяет описывать деятельность в динамике и отражает последовательность выполнения отдельных процедур (функций). Данная модель включает следующие модели: организационная структура управления; процессы на высшем уровне иерархии; функции руководителей различных уровней управления предприятием; функции руководителей подразделений по управлению и выполнению отдельных процессов; действия сотрудников по выполнению исследуемого процесса.
Модели громоздкие и плохо читаемы. Отсутствует возможность визуального отражения деятельности выполнения проводимых шагов действий. Не отражает прямых управленческих воздействий, управление компанией отражено при указании входящих документов.
ЯМТ (язык моделирования Тушкало)
Методика дает возможность отказаться от традиционной текстовой формы записи интервью с функциональными исполнителями бизнес-процессов в графическую форму схем бизнес-процессов с использованием CASE-средства, но без участия исполнителей. ЯМТ схемы бизнес-процессов имеют одноуровневую линейную структуру представления, в виде линии с нанесением временной оси или в виде набора отдельных листов.
Предназначена для описания бизнес-процессов различной степени сложности и подробности. Дает оценку качества создаваемой модели бизнес-процессов по восемнадцати нормативным правилам. Отмечается простота и доступность средств схематического изображения оцениваемых бизнес-процессов
Бизнес-процессы состоят из видов деятельности (операций), скоординированное осуществление которых предполагает достижение конкретной бизнес-цели.
Эти виды деятельности могут составлять системные операции, взаимодействие пользователей или ручные операции. Последние не поддерживаются информационными системами.
Взаимодействие пользователей идет еще дальше: это операции, в которых знания исполнителей реализуются с использованием информационных систем. Это не предполагает участие физической деятельности. В связи с тем, что люди используют информационные системы для выполнения этих операций, необходимо наличие приложений с соответствующими пользовательскими интерфейсами, чтобы гарантировать успешную работу. Данные приложения должны быть подключены к концепциям серверных приложений, которые хранят введенные данные и должны быть легкодоступными для использования в перспективе.
Определенная деятельность выполняется во время проведения «ручного» бизнес-процесса, однако изменения состояния включаются в систему управления бизнес-процессами взаимодействием пользователей.
Фактическая поставка необходимой информации в логистике бизнес-процессов требует предоставления должным образом информационных систем.
Имеется серия типов событий во время процесса логистики. Они зачастую доступны для пользователей как отслеживание информации. Во время ручных операций информационная система — система отслеживания — получает информацию о настоящем состоянии процесса.
Можно утверждать, что поток операций не является подклассом бизнес-процесса, потому что рабочий процесс реализует его часть; таким образом, рабочий процесс не является «экземпляром» отношения с бизнес-процессом, это только объединение.
Источник: vuzlit.com
Референтная модель BIAN. Что нового и полезного для корпоративной архитектуры банка она предлагает?
BIAN… как мало в этом звуке для сердца русского… Да, я не случайно перефразировала всем известного классика. В России популярность референтной модели BIAN все еще низкая, особенно в сравнении с моделью Enhanced Telecom Operations Map (eTOM), распространенной в опережающей по своему развитию телекоммуникационной отрасли. А между тем, модель BIAN развивается, совершенствуется и набирает популярность за пределами России и в международном сообществе банковской индустрии.
Не стану более отвлекать читателя на лирические отступления, скажу только, что обзор модели BIAN и сопроводительных документов стандарта есть в первой моей статье о BIAN, здесь же постараюсь рассказать, чем BIAN может быть полезен бизнес-менеджерам, бизнес-архитекторам, корпоративным архитекторам, архитекторам решений, ИТ-специалистам и всем другим лицам, интересующимся управлением всей архитектуры финансового предприятия. А также о его ключевых полезных трансформациях, на мой взгляд.
Что нового и интересного?
BIAN стал доступнее
Одним из самых важных и кардинальный изменений, случившихся с референтной моделью BIAN, на мой взгляд, стал перевод ее в нотацию Archimate. Ее стало проще читать. Разработчики BIAN, видимо, не смогли не признать необходимость использования стандартной нотации для ее описания в целях дальнейшего распространения в профессиональных кругах.
Модель для восприятия стала понятнее архитекторам, так как она описана на понятном архитекторам языке. Таким образом, версия BIAN 8.0 представлена на языке ArchiMate 3. Модель лежит в открытом доступе. Зарегистрировавшись в www.opengroup.org, каждый может самостоятельно скачать описание модели BIAN и всех ее компонентов в нотации Archimate.
Имплементация BIAN в API
Следующий важный аспект, о котором стоит говорить, — это то, что Независимая некоммерческая ассоциация стандартов (Banking Industry Architecture Network (BIAN)) поддерживает и обновляет хранилище API для своих бизнес-доменов ландшафта.
Разработчики BIAN нацелены на то, чтобы создать доступное хранилище качественных API и микросервисов, чтобы помогать банкам быстро и экономически эффективно модернизироваться.
Исходные файлы для API из хранилища также опубликованы и доступны для скачивания после регистрации на портале (если у кого-то возникнут сложности с регистрацией — попробуйте зарегистрироваться в режиме «инкогнито» вашего браузера).
Далее подробнее изучим метамодель BIAN в нотации Archimate и ее имплементацию в виде API.
Метамодель BIAN в нотации Archimate
В данной части я предлагаю рассмотреть текущую структуру ландшафта BIAN в нотации Archimate с опорой на документ от OpenGroup. Этот документ предлагает варианты гибкой, бережливой и стабильной разработки банковской архитектуры с использованием языка ArchiMate и BIAN.
Итак, начнем с описания метамодели BIAN.
Элементы ландшафта BIAN
Рисунок 1. Наложение BIAN Service Landscape на метамодель
- Business Area (Бизнес – направление) — зеленый;
- Business Domain (Бизнес – область) — оранжевый;
- Service Domain (Сервисный домен) — голубой.
- справочные данные;
- продажи и обслуживание;
- операции и исполнение;
- риски и комплаенс (+аналитика);
- поддержка бизнеса.
Бизнес–области (Business Domains) архитекторы банковских предприятий определяют как разложение банковского бизнеса на совокупность взаимоисключающих, в своей совокупности полностью исчерпывающих бизнес-возможности предприятия. Бизнес–области определяют сегменты банка, рассматриваемые архитекторами банковского бизнеса с функциональной и архитектурно-технической точки зрения.
Сервисный домен (Service Domain) — это элементарный или атомарный функциональный строительный блок в рамках ландшафта BIAN.
Каждый сервисный домен предлагает набор сервисов (Service Group). Этот набор включает в себя сервисные операции (Service Operation). Сервисный домен — это набор сервисных операций, которые совместно управляют полным жизненным циклом некого ресурса (Asset Type).
Рисунок 2. Ключевые элементы сервисного домена на метамодели BIAN
Functional Pattern, Asset Type и Action Term
Главный прием, используемый для «изоляции» сервисного домена BIAN (т.е. выделения его в качестве атомарной, неделимой единицы ландшафта), заключается в применении функционального шаблона (Functional Pattern) к ресурсу (Asset Type).
Если мы посмотрим определение элементов Archimate, то увидим, что для Functional Pattern используется Business Interaction, а для Asset Type — бизнес-объект.
Asset Type — какая-либо материальная или нематериальная вещь, на которую банк имеет право собственности и/или влияние, и имеет одно или несколько неотъемлемых видов использования или целей, создающих коммерческую ценность.
Functional Pattern — поведение или механизм, который может быть применен к какому-либо ресурсу при осуществлении коммерческой деятельности (например, проектировать, направлять, управлять, регистрировать и т.д.)
Рисунок 3. Выделенные функциональные шаблоны
BIAN также определил стандартный набор действий (Action Term), характеризующих различные виды сервисных операций. Каждая сервисная операция выполняет ровно одно действие.
Полный список Action Term (представленных в виде бизнес-функций ArchiMate) приведен ниже.
Рисунок 4. Стандартный набор действий (Action Term)
Набор действий (Action Term), которые вместе образуют повторяющийся тип поведения, называется функциональным шаблоном.
В стандарте BIAN приводится очень удобная и наглядная матрица связи функциональных шаблонов и стандартных операций:
Рисунок 5. Связь функциональных паттернов и стандартных операций
Т.е. в чем основная идея? Мы можем практически любую деятельность банка спроектировать и реализовать через заданный, ограниченный набор операций!
Каждый сервисный домен при этом содержит только один основной функциональный шаблон с одним типом ресурса. И мы получаем ресурс, к которому мы можем применить тот или иной шаблон. При этом число шаблонов также конечно и весьма не велико в сравнении с числом бизнес-доменов на ландшафте!
Далее мы видим из метамодели BIAN, что функциональный шаблон, агрегирующий в себе некий набор стандартных операций как раз и реализует сервисные операции (фиолетовым обозначено на рисунке ниже), включенные в сервисную группу, также реализующую функциональность сервисного домена:
Рисунок 6. Связь функциональных паттернов и сервисных операций
А как мы уже выяснили выше, набор сервисных операций совместно управляют полным жизненным циклом некого ресурса (Asset Type).
Итого, мы получаем связь: Service Domain — сервисный домен (функциональность, которая нам нужна для бизнеса) -> Asset Type — заданный ресурс сервисного домена (с чем мы будем работать для реализации нашей задачи, например, ипотечный кредит) -> Functional Pattern — функциональный шаблон (поведение, характеризующее действия с нашим ресурсом)».
Generic Artifact и Control Record
Теперь рассмотрим еще одну группу элементом метамодели, обозначенных на рисунке ниже выделением цветом. 
Рисунок 7. Общий артефакт и контрольная запись
Функциональный шаблон — это достаточно высокий уровень абстракции (из метамодели также ясно, что он реализуется более конкретными сервисными операциями, но об этом я еще скажу позже, когда мы рассмотрим связь на конкретном примере).
И поэтому артефакт, на который он непосредственно воздействует, также абстрактен. Он называется общим артефактом (Generic Artifact). Для каждого функционального шаблона BIAN определил один общий артефакт, как показано на рисунке ниже: 
Рисунок 8. Набор общих артефактов
Контрольная запись (Control Record) представляет собой информацию, необходимую для решения внутренних задач сервисного домена. Это некий журнал сведений о жизненном цикле ресурса, к которому обращается функциональный шаблон в соответствии с экземпляром общего артефакта или в результате которого он создается.
Если, например, ресурс — «текущий счет», функциональный шаблон — «выполнение», а связанный общий артефакт — «Обязательство», то конкретная Контрольная запись — ”Обязательство выполнения (задач для) текущего счета».
Имя контрольной записи — это объединение имени ресурса и имени общего артефакта. Сервисный домен «текущий счет» будет предоставлять услуги, связанные с «организацией исполнения текущего счета».
Контрольную запись можно рассматривать как информацию о жизненном цикле «квалифицированного ресурса», где квалификатором является общий артефакт.
Рисунок 9. Пример домена «текущий счет»
Service Operations
«Сервисная операция» — это конкретное действие, исполненное на заданном ресурсе. Это элементарная услуга.
В примере сервисного домена «текущий счет» сервисный домен способен выполнять «intiateCurrentAccountFulfillment», «executeCurrentAccountFulfillment» и т. д., которые представляют собой термины действия, агрегированные в функциональном шаблоне и применяемые к контрольной записи.
Т.е. если мы наложим сервисные группы на матрицу с операциями, то будет понятно, какие действия нам необходимо выполнять с нашим ресурсом:
Рисунок 10. Пример наложения Action Term на Service Group
Сервисные операции по исполнению «текущего счета» являются производными от условий действия функционального шаблона. Сервисные операции организованы в сервисные группы.
Message и Condition
Исполнение сервисных операций возможно только через четко определенные интерфейсы. Каждая сервисная операция требует возникновения события, чтобы иметь возможность «доставить» услугу. Этим событием будет тип сообщения, который называется входящим сообщением(Message).
Сервисная операция будет реализована посредством некоторой внутренней обработки, возможно, делегирования некоторых задач другим сервисным операциям. В результате сервис выдаст ответ в качестве выходящего сообщения. Сообщение, которое является входным сообщением для одной операции обслуживания, может быть выходным сообщением для другой операции обслуживания.
Рисунок 11. Входящие/исходящие сообщения и условия исполнения сервисных операций
В описании сервисного домена также приводятся существующие зависимости от других доменов.
В частности, пример списка сервисных доменов, из которых ожидаем получения входящего сообщения:
Рисунок 12. Пример связи с другими доменами для «Текущего счета»
Итого, мы рассмотрели все элементы метамодели BIAN. И пора уже переходить к имплементации модели BIAN на API. Но перед тем, как это сделать, хочу обратить внимание, что модель содержит в себе гораздо больше представлений ее описания. Есть как объектное описание, диаграммы последовательностей, wireframes и другие.
Предлагаю читателям ознакомиться с ними самостоятельно по ссылке.
А также с сравнением модели и фреймворка Togaf.
Реализация модели BIAN через API
Как и было сказано выше, сообществом разработчиков BIAN разрабатывается и регулярно пополняется хранилище REST сервисов, соответствующих принципам стандарта BIAN.
Для ознакомления, необходимо зарегистрироваться на портале, перейти в хранилище и либо скачать исходные файлы, либо для ознакомления перейти в консоль.
Рисунок 13. Пример навигации по хранилищу API BIAN
В режиме консоли возможно ознакомиться с документацией в Swagger: 
Рисунок 14. Пример навигации по хранилищу API BIAN для сервисного домена Current Account
Либо поработать с кодом: 
Рисунок 15. Доступ к исходным файлам API хранилища BIAN
Для упрощения понимания, как воспользоваться интерфейсами API, можно прочесть документ. Предлагаю читателям и разработчикам уже освоить эту часть работы с BIAN самостоятельно, либо участвовать в вебинаре, который состоится в ближайшее время, где будет возможность получить информацию из первых уст, и задать интересующие вопросы в конце вебинара.
На вебинаре будет представлен основной контент и освещены изменения, усовершенствования и расширения, внесенные в стандарт BIAN в последней редакции.
Возможный подход к применению стандарта
- Т.е. ландшафт — это некий набор высоуровневых кирпичиков (сервисных доменов),
- каждый домен имеет свой набор инструментов (сервисных операций)
- для работы с некими артефактами (ресурсами).
В компании возможно:
1. подробно изучить ландшафт, выделить на нем визуально (цветом, рамочками или другим образом) те домены, которые нужны ей по своему функциональному назначению (можно и на системный уровень наложить и понять, в каких системах идет дублирование данных, к примеру. Это один из сложных вопросов, на мой взгляд, который встает при проектировании микросервесной архитектуры, а модель BIAN предлагает еще на бизнес-уровне подумать об этом).
2. Изучить метамодель BIAN, чтобы понять, как функционирует каждый из доменов (в этом, я надеюсь, вам поможет мой обзор, который я сделала выше по метамодели).
3. Скачать нужные API с портала (или удостовериться сначала, что нужный набор уже присутстует).
4. Изучить другие представления модели BIAN.
4. Нарисовать карту миграции с учетом текущей архитектуры в компании для ее перехода на микросервисную.
- Open source
- Анализ и проектирование систем
- IT-стандарты
- API
- Микросервисы
Источник: habr.com