Диаграмма связей бизнес идей

Юрий Волков | 26.09.2006

ИНСТРУМЕНТАРИЙ

В опубликованной год назад статье «Новый взгляд на описание бизнес-процессов» (см. PC Week/RE, N 34/2005, с. 42), мы рассмотрели описание бизнес-процесса в виде текста (рассказа). Теперь самое время обсудить, как изображать бизнес-процессы на диаграммах (рисунках), какую графическую нотацию выбрать и для чего можно использовать созданные диаграммы.

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

— знакомы нашему клиенту (конечным пользователям автоматизированной информационной системы, далее называемой Системой);

— оперируют понятиями предметной области клиента («покупатель», «заказ», «оплата» и т. п.).

Без обратной связи модель постепенно все меньше соответствует своей реализации в Системе и поэтому становится неактуальной, а следовательно — ненужной.

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

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

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

Описание бизнес-процессов как один из этапов автоматизации

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

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

Цели

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

К этим блок-схемам (диаграммам) мы предъявляем следующие требования.

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

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

Текстовое и графическое представления не нужно рассматривать как нечто взаимоисключающее:

они дополняют друг друга

2. Во-вторых, мы хотим в результате получить нечто большее, чем просто рисунки: мы хотим построить модель процесса, на основе которой можно сгенерировать не только диаграммы, но и, например, текстовые отчеты о составе модели. Именно поэтому для описания процесса мы уже используем не карандаш и бумагу или их компьютерный аналог — графический редактор типа Adobe Photoshop, а специальные инструментальные средства моделирования. Самые популярные из них — продукты ARIS и BPWin. Не следует, однако, слишком тесно связывать способ описания процессов с конкретным продуктом (если только этот способ не является общепринятым стандартом). Более того, подобная зависимость сегодня уже является недостатком как самого способа описания бизнес-процессов, так и созданной с его помощью модели!

Так какими же качествами должна обладать модель бизнес-процесса?

— Она должна, во-первых, позволять автоматически создавать отчеты о ее составе (например, для оценки затрат на разработку Системы).

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

— В-третьих — обеспечивать возможность электронного обмена моделями и диаграммами (а не только «картинками») между различными инструментальными средствами, а также передачу их в Систему.

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

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

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

Сферы применения BPMN и UML однозначно разделены самим разработчиком обеих спецификаций.

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

Начинаем выбирать диаграммы

Наше желание использовать для описания бизнес-процессов диаграммы, одинаково понимаемые различными людьми, заставляет нас выбирать из небольшого числа наиболее популярных их разновидностей, таких, как IDEF, EPC (eEPC), диаграммы деятельности UML и диаграммы BPD (Business Process Diagram), определенные спецификацией BPMN [2].

Верхний уровень в описании процесса разрешения разногласий с помощью голосования по электронной почте

в нотации BPMN — реального процесса, использовавшегося при коллективной разработке самой спецификации BPMN

При всем моем уважении к историческому интеллектуальному наследию диаграммы IDEF и EPC (подробнее о них см. в [1]) — это продукты той эпохи, когда еще не шла речь о непосредственном исполнении описаний бизнес-процессов Системой (аналогично тому, как компьютер исполняет текст программы). Мы полагаем, что от применения этих диаграмм следует отказаться, в первую очередь потому, что они недостаточно выразительны и точны для исполнения в Системе. Дело не в том, что Система — «тупая», а просто на диаграмме не все необходимое указано, а то, что указано, допускает неоднозначную трактовку.

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

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

Например, как отмечают специалисты (в частности, в [1]), работа по созданию модели eEPC должна регламентироваться «соглашением о моделировании», предварительно составляемым командой проекта. Без такого соглашения ценность полученной модели будет минимальна. Если у вас возникнет вопрос: «Как правильно изобразить на диаграмме eEPC то-то или то-то», — то по-настоящему авторитетного ответа вам не найти (если вообще вы найдете какой-либо ответ). В результате вы строите модель в соответствии со своими представлениями о ее корректности, и без ваших комментариев она будет, мягко говоря, малоценной.

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

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

BPMN (Business Process Modeling Notation) [2] — спецификация, содержащая графическую нотацию описания бизнес-процессов, основанную на диаграммах BPD. Она разработана организацией Business Process Management Initiative (BPMI) в 2001-2004 гг. с учетом множества ранее существовавших диаграмм (в том числе всех упомянутых выше). Основной целью данной инициативы было получить нотацию, легко понимаемую всеми пользователями — от бизнес-аналитика, создающего первые наброски описаний процессов, до технических специалистов, отвечающих за реализацию этих процессов в Системе, и менеджеров, управляющих этими процессами и контролирующих их функционирование.

Сам стандарт BPMN не определяет формата файла для сохранения описания и информационного обмена (в том числе и с Системой), однако уже есть как минимум одна спецификация, описывающая этот формат, — это XPDL. В версии XPDL v.2.00 (www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf) явно указано, что одно из ее назначений — служить описанием формата файла для нотации BPMN. Иными словами, XPDL позволяет хранить не только логику процесса (как и BPEL, другая спецификация описания бизнес-процесса, понимаемого машиной), но и его графическое BPMN-представление. Таким образом, формат файла BPMN уже существует, что позволяет «понимать друг друга» различным инструментальным средствам моделирования.

Спецификация BPMN — это книга размером в 300 страниц, которая содержит множество графических иллюстраций с подробными комментариями: всего около 130 рисунков! Кроме того, в документе в качестве примера приводится подробное описание реального процесса разрешения разногласий с помощью голосования по электронной почте (см. рисунок). Этот процесс применялся BPMI при создании самого стандарта.

Познакомившись более детально со спецификацией BPMN (которую бесплатно может загрузить любой желающий), я наконец-то увидел диаграммы для описания бизнес-процессов такого качества и такого уровня проработки, что их немедленно можно использовать на практике. Да и по отзывам людей, мало знакомых с нотациями моделирования бизнес-процессов, диаграммы BPMN действительно понятны на интуитивном уровне. Для самых «занятых» есть и короткие выжимки из спецификации, похожие на комиксы (www.bpmn.org/Documents/BPMN%20Fundamentals.pdf).

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

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

Некоммерческая международная организация OMG (www.omg.org), являющаяся разработчиком UML, в 2005 г. взяла «под свое крыло» спецификацию BPMN, а в феврале нынешнего опубликовала ее уже как собственную, слегка подкорректировав документ, полученный от BPMI.org, и добавив в него ссылки на OMG [2].

В недавно выпущенном документе (www.omg.org/news/newsletters/OMG-Standard-Spring_2006.pdf) OMG разъясняет свои представления о сервисно-ориентированной архитектуре (SOA) и описаниях бизнес-процессов как части архитектуры, управляемой моделями (Model Driven Architecture). Там же показывается соответствие стандартов OMG (в том числе BPMN и UML) уровням моделей SOA.

Так вот, BPMN, согласно OMG, применяется на самом верхнем уровне — уровне бизнес-процессов, а UML — на уровне компонентов программного обеспечения (для описания интерфейсов между компонентами ПО и бизнес-сервисами).

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

OMG планирует подвести под BPMN метамодель Business Process Definition Metamodel (BPDM), оперирующую понятиями уровня бизнес-процессов, а не программного обеспечения. И только там, где есть пересечения c уже существующей метамоделью UML 2, предполагается использовать элементы этой последней в метамодели BPDM. В этом, пожалуй, и состоит очень существенное отличие диаграмм BPMN от диаграмм деятельности UML: элементы их моделей имеют разную семантику. Вот почему более корректно моделировать бизнес-процессы, используя диаграммы, обладающие соответствующим смыслом (семантикой), т. е. BPMN.

Во избежание недоразумений хотел бы отметить, что диаграммы стандарта BPMN не заменяют полностью аналогичные конструкции UML или ARIS. Они предпочтительны именно для описания бизнес-процессов (а не процессов любого типа). Следует помнить, что в реальном проекте одними диаграммами описания бизнес-процессов вам не обойтись: необходимо использовать также методологии процесса разработки (например, Extreme Programming или Rational Unified Process). Но это уже предмет отдельной статьи.

Литература

1. Репин В. В. Сравнительный анализ нотаций 2001. www.interface.ru/fset.asp? Url=/ca/an/danaris1.htm.

2. OMG. BPMN (Business Process Modeling Notation) v.1.0, 2006. www.omg.org/ technology/documents/bms_spec_catalog.htm.

С автором статьи можно связаться по адресу: yvolk@yurivolkov.com.

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Основные подходы

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

Функциональный;
Процессный;
Ментальный (с применением ментальных карт).

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

Функциональное моделирование

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

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

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

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

Некоторые путают описание процесса и функциональную модель. Например, в системе Business Studio функцию называют процессом, хоть это и не совсем верно. Все же описание функций и процессный подход – несколько разные вещи. И я лично считаю, что функциональное моделирование оптимально реализовано в нотации IDEFO. Сам я для такого варианта работы использую именно ее, и всем также рекомендую.

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

Процессное моделирование (моделирование бизнес процессов)

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

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

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

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

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

Например, в BPWIN или Business Studio в процессе детализации каждой функции происходит переход от функционального подхода к процессному. Т.е. в общем, мы рассматриваем модель с точки зрения – возможностей и желаемого результата, а когда переходим к решениям для каждой функции, здесь уже практикуется явно процессный подход, т.е. пошаговый алгоритм действий для достижения результата.

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

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

Ментальный подход (ментальные карты)

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

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

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

Плюсы применения таких ментальных карт очевидны:

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

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

В результате для понимания модели и заложенных в ней идей требуется присутствие и комментарии ее разработчика (аналитика).

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

Методология и языки бизнес-моделирования

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

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

Здесь напрашивается сравнение с программированием вообще и применением конкретного языка программирования. Программирование включает в себя и построение алгоритма, и выбор подходящего языка программирования, и реализацию алгоритма программы в рамках того или иного языка. А, например, программирование на языке Си++ – это уже заведомо ограничение определенными рамками, так как средствами определенного языка можно решить только четко ограниченный круг задач, и, одновременно, даже если задачу можно решить средствами Си++ совсем не обязательно, что именно этот язык будет в конкретном случае оптимальным. В общем, разницу между понятием «программирование» и «программированием в рамках определенного языка», я думаю, большинство понимают даже без таких пояснений.

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

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

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

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

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

Преимущества разработки моделей бизнеса

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

На самом деле, стандарты и правила – это огромный плюс:

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

Применение моделей бизнеса на практике

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

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

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

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

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

Источник