Моделирование бизнес процессов linux

Выбор CASE инструмента для разработки процессов в BPMN

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

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

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

Visio

Решение от Microsoft, наиболее доступное из платных продуктов, самое распространенное и имеющее максимальное количество специалистов, им владеющих. Для того, чтобы разрабатывать процессы в Visio с максимальной эффективностью, необходимо обратить внимание не только на версию продукта но и на его редакцию. Рисовать процессы можно в любой версии, но наличие шаблонов BPMN процессов и проверка схемы на корректность согласно нотации возможна только в Microsoft Visio 2010 в редакции премиум или Microsoft Visio 2013 в редакции профессиональная и выше. Программа платная.

Рисование схем процессов.

По удобству, одна из лучших. Основным замечанием по программе является отсутствие полной поддержки BPMN в профессиональной редакции Microsoft Visio 2010. Как следствие – неполное соответствие нотации (некоторые элементы отсутствуют) и отсутствие проверки схемы. Полный комплект элементов можно получить, если установить дополнительную библиотеку элементов, например: www.orbussoftware.com/downloads/free-visio-stencils/bpmn-20-visio-stencil-and-template (использование бесплатно) – в ней есть недостающие элементы, дополнительные возможности работы с пулом и т.д.
Для более продвинутых пользователей есть широкие возможности кастомизации, такие как, ведение своей библиотеки заготовок фрагментов процессов, оформление и др.
Схемы получаются красивыми и что немаловажно, могут быть вставлены в документ WORD в качестве встроенных объектов, что позволяет менять их прямо у Заказчика. В целом, данный продукт, возможно, является лучшим выбором для тех, кто ограничивается использованием BPMN в качестве красивых картинок в документах.

Проверка и симуляция

Проверка есть, но не во всех версиях. Симуляции выполнения процесса нет.

Автоматизация процессов.

Есть, в рамках интеграции с Business Studio. К сожалению, нет возможности выгрузить процесс в общепринятых форматах, таких как XPDL и BPEL, для использования в сторонних программах – будьте внимательны при выборе!

Enterprise architect 11.4

Решение от IBM, одного из столпов, кто активно участвует в разработке и продвижении BPMN. Строго говоря, у IBM есть целая линейка различных продуктов, в которых в разной степени поддержана работа с BPMN процессами. Я начал знакомство с продуктами компании с «Enterprise architect». Несмотря на столь солидную фирму и внушительную цифру в номере версии, продукт сначала несколько изумляет, потом вызывает шквал вопросов, и наконец, по мере получения ответов, изумление сменяется полным разочарованием. Классическая ситуация «Сапожник без сапог» — Enterprise architect сейчас – это пережиток далекого, весьма уважаемого прошлого, которое совершенно непригодно к применению в современных реалиях. Программа платная.

Рисование схем процессов.

Epic Fail – этими двумя словами все сказано. Продукт требует от пользователя по крайней мере в 3 раза больше времени на рисование процесса, чем остальные инструменты. Поддержка нотации BPMN 2.0 скудная. Копипаста нет – при выполнении копирования и последующей вставки объекта, программа сообщает, что не может вставить его по причине того, что на схеме уже есть объект с таким именем. Вставить группу скопированных объектов с любыми случайными именами программа не может, потому что это противоречит общей концепции. Автоматическое выравнивание – это аналог предложения процессу «убиться об стенку». Все дело в том, что граничные события никак не привязаны к своим задачам, они просто висят сверху и при автоматическом выравнивании отправляются в ад теряют форматирование. По этой же причине, ни о какой проверке правильности процесса и речи быть не может.
Вообще все сделано плохо, очень неудобно и просто некрасиво, работая с этим инструментом, не покидает ощущение, что это какая-то альфа версия программы, потенциал есть, но предстоит доделать еще очень много. Дополняет картину очень неудобный пользовательский интерфейс а-ля прошлое тысячелетие.

Проверка и симуляция

Проверки нет. Симуляции выполнения процесса нет.

Автоматизация процессов.

Enterprise architect позиционируется как корпоративное решение для управления процессами предприятия и я полагал, что получу множество «best practice», когда дойдет черед именно до автоматизации процессов. Но, автоматизации нет – совсем. Смотрим продукты IBM, вот оно – есть продукт IBM BPM – именно он позволяет выполнить автоматизацию! Логично предположить, что разработанные в Enterprise architect процессы сразу заработают в IBM BPM, ибо у них один разработчик. Но они не работают…, и с напильником не работают…, наконец, Вы узнаете, что эти продукты полностью несовместимы! Чтобы автоматизировать процессы, Вам нужно изначально разрабатывать их в IBM BPM (в котором BPMN чуть больше, чем ничего).
В завершении, в качестве некоторого плюса, хочу сказать, что крупные компании по ряду причин тяготеют к решениям IBM и, не смотря на все его минусы, этот инструмент используется. Аналитиков, которые согласны умеют работать с Enterprise architect не так много, поэтому владея этим инструментом можно рассчитывать на весьма высокий уровень компенсации.

ELMA BPM 3.2

Решение от ELMA, одного из ведущих Российских интеграторов. Хочется сказать отдельное спасибо ELMA за перевод нотации BPMN 2.0 на русский язык. Итак, ELMA BPM – это система управления бизнес-процессами. Это как раз тот случай, когда схемы разрабатываются не для картинок, а для автоматизации. Программа платная, для ознакомления можно установить бесплатную версию.

Рисование схем процессов.

Рисование довольно удобное, однако соответствие нотации неудовлетворительное (очень многих элементов не хватает, однако если сравнить ее с IBM BPM 8.5.0.0, то производит очень благоприятное впечатление), программа позволяет использовать только те элементы, которые в состоянии автоматизировать. Поэтому ELMA BPM в качестве инструмента для рисования процессов по нотации BPMN не подходит.

Проверка и симуляция

Проверка есть. Симуляции выполнения процесса в бесплатной версии нет.

Автоматизация процессов.

Есть. Судя по количеству внедрений, с этим у ELMA все в порядке. К сожалению никак не могу оценить удобство внедрения и полноту достижения целей бизнеса, т.к. сам с этим ни разу не сталкивался.

BPM 2.0 modeler for Visio 4.1.1

Решение от Trisotech является надстройкой для Visio и добавляет ту функциональность, которой так не хватает в самой Visio. Решение платное, для ознакомления с BPM 2.0 modeler for Visio можно установить пробную версию на 30 дней.

Рисование схем процессов.

Для BPM 2.0 modeler for Visio актуально все то хорошее, что было сказано про Visio. Для разработки схем процессов используется своя библиотека элементов, полностью соответствующая нотации BPMN 2.0. Рисуется быстро и приятно, это все тот же Visio!

Проверка и симуляция

Проверка есть. Для симуляции выполнения процесса требуется установка дополнительного ПО.

Автоматизация процессов.

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

Bizagi Process Modeler 2.6

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

Рисование схем процессов.

Рисование довольно удобное (очень похоже на ELMA), соответствует нотации почти полностью (некоторых элементов не хватает). Пока схемы простые, рисовать их одно удовольствие, однако с увеличением сложности схемы, начинаются затруднения у пользователя, например: потеря описаний событий и потоков, причудливое извивание потоков управления, и, что особенно огорчило – групповая потеря форматирования объектами (при копировании объекты сбиваются в кучу, случайно цепляясь к ближайшим потокам управления) – при этом отменить это безобразие невозможно, волшебное Cntr+Z не работает, иногда единственный выход – загрузка с диска предыдущей версии схемы! Bizagi Process Modeler может быть успешно использован в качестве инструмента для рисования процессов по нотации BPMN, если помнить о его «недокументированных особенностях».

Проверка и симуляция

Проверка есть, даже две, но они недоделаны и могут использоваться только на простых процессах. Одна проверка доступна по кнопке, другая выполняется автоматически перед симуляцией. К сожалению, эти проверки выдают разный результат, проверка по кнопке может вернуть «все ОК», а проверка перед симуляцией вернуть ошибку процесса, при этом какая именно ошибка не пишется.
Симуляция есть, ее тоже можно использовать только на простых процессах. Для симуляции существует большое количество ограничений: не удалось заставить работать прикрепленные события, подпроцессы в симуляции не участвуют, поток сообщений между пулами, от промежуточного сообщения к промежуточному, токен не передает – работает передача токена только к стартовому событию и т.п. В общем на симуляции можно было бы поставить крест, однако, если вспомнить про ограничение на использование элементов нотации, существующие у ведущих автоматизаторов «IBM BPM» и «ELMA BPM», тогда и к имеющимся возможностям симуляции в бесплатном продукте начинаешь проникаться уважением.

Modelio 3.0.1

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

Рисование схем процессов.

Не самая лучшая реализация разработки процессов, требует вдвое больше времени на разработку процесса, чем лидеры. Соответствие нотации почти полное (некоторые возможности нотации не поддерживаются), однако имеет ряд недочетов (например, у граничного события при свойстве «CancelActivity=True» граница рисуется штрихом, что неверно).
Не очень получается и конечный результат – такое чувство, что картинки получаются с очень низким разрешением. Также, нет возможности выгрузить процесс в общепринятых форматах, таких как XPDL и BPEL, для использования в сторонних программах – будьте внимательны при выборе! Я бы не стал рекомендовать использовать эту программу в качестве средства разработки процессов.

Проверка и симуляция

Проверка есть, реализована очень неплохо, но со своими тараканами. Симуляции выполнения процесса нет.

ARIS Express 2.4

Решение от IDS Scheer, очень качественный продукт, удобный и полностью бесплатный. ARIS Express настолько удобный, что бросает вызов Visio в номинации лучшего средства разработки процессов в BPMN нотации. Решение бесплатное.

Рисование схем процессов.

По удобству, одна из лучших. Соответствие нотации почти полное (небольшая часть возможностей нотации не поддерживается). Из минусов можно отметить ограничение добавления элементов на схему в соответствии с заложенными в программу правилами, например, если не заложена возможность проассоциировать поток сообщений с артефактом, то сделать это невозможно. Процессы рисуются быстро и красиво.
В программе есть возможность ведения своей библиотеки заготовок фрагментов процессов (Fragments) – работать с библиотекой очень удобно.
Схемы процессов, сохраненные в формат «adf» могут быть перенесены в полнофункциональную версию ARIS, а вот выгрузка в форматах XPDL или BPEL отсутствует. Следует использовать эту программу с осторожностью, чтобы после разработки 50+ процессов, Вы не столкнулись с ситуацией «Ну все, выгружайте все процессы в BPEL формате а мы пока документы подпишем…». Ущербность форматов выгрузки – основной минус этого решения.

Проверка и симуляция

Проверка есть, выполняется в процессе моделирования. Симуляции выполнения процесса нет.

Источник

Моделирование бизнеса. Основные подходы

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

Я уже писал о моделировании при помощи 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-систем, так и сотрудников, движения товаров и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

Источник