Референтная модель бизнес процесса это

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

В телекоммуникационных компаниях России давно уже прижилась практика применения референтной модели Enhanced Telecom Operations Map (eTOM), ориентированной на бизнес-процессы операторов услуг и других представителей индустрии информационно-коммуникационных технологий. Модель используется как шаблон для управления и реорганизации процессов, а так же для упрощения взаимодействия с партнерами и другими операторами услуг.

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

Референтные модели ИТ

Целью моей статьи является привлечение внимания к одной из таких моделей, а именно, к референтной модели BIAN, о которой пойдет речь ниже.

В своей статье для верхнеуровнего обзора стандарта BIAN я прибегну к частичному переводу документа «BIAN How-to Guide – INTRODUCTION TO BIAN V6.0» с акцентом на ключевые аспекты стандарта. Ознакомиться с документом можно по ссылке. Также при переводе я буду позволять себе делать отступления от оригинала и давать свои комментарии там, где посчитаю это необходимым.

Обновление: опубликована вторая статья с детальным обзором структуры домена.

1. Введение в BIAN (Banking Industry Architecture Network)

Banking Industry Architecture Network (BIAN) – это ассоциация архитекторов банков, поставщиков банковского программного обеспечения и провайдеров услуг с общей целью создания стандартной семантической среды банковских сервисов. По ожиданиям разработчиков BIAN классификация бизнес-функций и взаимодействий внутри любого банка в оформленном стандарте принесёт значительную пользу отрасли.

Основные документы, составляющие и дополняющие стандарт BIAN:

• высокоуровневая карта сервисов «BIAN Service Landscape» — «Ландшафт сервисов»;
• коллекция документов «BIAN How-to Guide»;
• метамодель «BIAN Metamodel»;
• определение бизнес-сценариев «BIAN Business Scenario»;
• классификация на бизнес функции/области (сервис-домены) и их услуги (сервис-операции) «BIAN Service Domain Definitions»;
• бизнес-словарь «BIAN business vocabulary»;
• и объектная модель «BIAN Business Object Model».

Часто стандарт участниками ассоциации именуется как «BIAN Service Landscape». Более формальное название – «BIAN SOA Framework». Описание для разработчиков самого стандарта представлено во втором документе BIAN «How to Guide – Developing Content».

Документы «How-to Guide» описывают подходы работы со стандартом. В состав руководств на момент написания статьи входит:

1. BIAN How-to Guide – INTRODUCTION TO BIAN V6.0
2. BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0 – Документ ориентирован на бизнес-архитекторов и системных архитекторов. Здесь объясняются подходы для применения и реорганизации процессов с помощью стандарта BIAN.
3. BIAN How-to Guide – DEVELOPING CONTENT V6.0 – Документ предназначен для участников рабочей группы BIAN. Объясняет принципы, шаблоны и инструменты, используемые при разработке стандарта.
4. BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 – Целевой аудиторией документа являются технические специалисты, которым предстоит применение подходов BIAN при непосредственном внедрении (развертывании) систем.
5. BIAN How-to Guide – SEMANTIC API V6.0 — Данный документ описывает, как стандарт BIAN может использоваться для разработки интерфейса прикладных программ (API). В ближайшее время планируется практическое руководство для разработчиков.

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

Далее приводится краткий обзор по документам из серии «BIAN How-to Guide» под номерами 2, 3 и 4 из списка выше.

2. Принципы и методы проектирования (Design principles and techniques)

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

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

Рисунок 1. Принципы и методы проектирования

С детальным описанием каждого блока на схеме можно ознакомиться непосредственно в BIAN How-to Guide – INTRODUCTION TO BIAN V6.0.

3. Разработка стандарта (Developing Content)

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

Рисунок 2. Разработка стандарта BIAN

С детальным описанием каждого блока схемы рисунка 2 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Также любой элемент BIAN описывается в самом же стандарте. Например, диаграмма классов базовых элементов стандарта BIAN представлена на рисунке ниже.

Рисунок 3. Разработка содержимого стандарта BIAN

4. Применение стандарта BIAN (BIAN How-to Guide – Applying the BIAN Standard)

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

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

Рисунок 4. Применение стандарта BIAN

С детальным описанием каждого блока схемы рисунка 4 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Экскурсия по стандарту

И здесь же я хочу привести пример, демонстрирующий некоторые описываемые подходы из приведенных диаграмм руководства.

Карта сервисов «BIAN Service Landscape» иерархически сформирована из следующих представлений:

1. Business Area (Бизнес – направление);
2. Business Domain (Бизнес – область);
3. Service Domain (Сервисный домен).

Рассмотрим бизнес-направление «Поддержка бизнеса». В частности, посмотрим на бизнес-область «Направления бизнеса» с акцентом на сервисный домен (функцию) «Business Architecture» (Рисунок 5).

Рисунок 5. BIAN Service Landscape

При навигации по карте сервисов «BIAN Service Landscape» перейдем к обзору сервисного домена «Бизнес-архитектуры».

Рисунок 6. Обзор сервисного домена «Business Architecture»

Домен «Business Architecture» выделяет одноименный объект (Asset) «Business Architecture» с функциональным паттерном работы (pattern) над ним «Design». Артефактом будет являться спецификация «Specification».

Важно отметить, что любой домен на карте сервисов «BIAN Service Landscape» раскладывается на составляющие, описываемые в семантических терминах (таких как Asset Type, Functional pattern и др.) и переиспользуемые в других доменах.

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

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

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

(Обновление: здесь вы можете ознакомиться со второй статьей, посвященной BIAN).

• architecture
• bank
• reference architecture
• bian
• international business
• microservices

• Анализ и проектирование систем
• IT-стандарты
• Исследования и прогнозы в IT
• Бизнес-модели
• Микросервисы

Источник: habr.com

Построение референтной модели или точка отсчета

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

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

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

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

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

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

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

Референтная модель – это эталонная модель производственной системы.

Главное преимущество референтной модели состоит в том, что производство рассматривается одновременно с нескольких точек зрения: с точки зрения более эффективной модели и с точки зрения ее взаимодействия с информационной системой.

Построение модели базируется на следующих понятиях:

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

Разработка адекватной референтной модели происходит в пять этапов:

1. Сбор информации и аудит производственных бизнес-процессов;
2. Построение модели AS-IS (как есть) по методологии IDEF0 (Integration Definition for Function Modeling);
3. Разработка стратегической концепции развития компании;
4. Формирование референтной модели TO-BE (как будет) по методологии IDEF0;
5. Утверждение плана мероприятий.

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

Важно! Процесс сбора информации включает в себя определение требований рынка.

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

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

Важно! Если в процессе моделирования возникает противоречие в оценке, то такое противоречие должно быть в обязательном порядке преодолено, чтобы получить модель, представляющую объект моделирования адекватно.

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

В процессе выбора стратегии следует учитывать основные факторы:

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

Стратегия модернизации производства должна отражать степень готовности выпускаемой продукции удовлетворить потребительский спрос. Это означает определение скорости реагирования на получаемые заказы и планирование будущего статуса предприятия в определенном рыночном сегменте.

На четвертом этапе, принимая во внимание принятую стратегию развития, составляется референтная модель производства TO-BE (как будет).

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

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

Любая референтная модель состоит из трех видов документов:

1. Графическая диаграмма;
2. Текст;
3. Глоссарий

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

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

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

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

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

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

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

Совет: Если хотите добиться действительно впечатляющих результатов, то не приглашайте внешних консультантов, сделайте все сами (привлеките весь коллектив предприятия).

Источник: up-pro.ru