что такое событие в моделировании
Моделирование событий и операций
Введение
Допустим, что мы наблюдаем процесс точения детали. Зададимся вопросом: кто точит деталь? Ответом может быть: Иванов, токарь, начальник цеха, друг Петрова. Мы можем сказать, что это один и тот же человек, но потом понимаем, что токарь – не человек, а роль, начальник цеха и друг – тоже. Так кто же точит деталь?
Пусть есть событие «яблоко поспело». До этого события яблоко было зеленым, после этого события яблоко стало красным. Вопрос: каким было яблоко в процессе совершения самого события?
В этой статье я отвечу на эти два вопроса с точки зрения проекционного моделирования.
Как я говорил, две проекции на время и на пространство дают представление о моделируемом пространственно-временном объеме. Существует три способа спроецировать 4-Д объем на время:
С другой стороны, 4-Д объем проецируется и на пространство. Есть три разных способа спроецировать 4-Д объем на пространство в виде:
4-Д объем проецируется на пространство в виде конструкции, то трактовать его можно так: Иванов из заготовки выточил деталь.
Если 4-Д объем проецируется на пространство в виде кучи, то трактовать его можно так: выпущена партия товара.
Как я говорил, трактовкой событий проекционное моделирование не занимается, но создает основу для моделирования трактовок. Его задача – корректно смоделировать 4-Д объемы, чтобы потом поверх этой модели можно было построить трактовку этих объемов. Это значит, что любая трактовка события, такая как например: из заготовки была получена деталь, идет поверх факта о том, что в 4-Д объеме операции присутствует 4-Д объем, трактуемый как деталь и 4-Д объем, трактуемый как заготовка. Почему так сделано? Потому что одну и ту же операцию можно трактовать по-разному, одни и те же части ее – тоже. Два субъекта могут сойтись в том, что в операции участвовали деталь, заготовка, станок и Иванов, но могут разойтись в ее трактовке. Один скажет, что это Иванов выточил деталь на станке, а второй скажет, что это станок выточил деталь под управлением Иванова.
Другой пример: один может сказать, что это была операция по продаже. Другой может сказать, что операция была по покупке. Один продавал амфибию, а второй купил лодку. У каждого в информационной системе зафиксированы и операция, и ее участники, но, чтобы проследить судьбу объекта, трактуемого одним как амфибия, а вторым как лодка, нужно уметь смоделировать 4-Д объем отдельно от его трактовки.
Построить модель трактовки всегда можно поверх модели 4-Д объемов, а вот построить модель 4-Д объемов на основе трактовки – увы, невозможно. Для построения такого рода моделей надо научиться разделять модели 4-Д объемов от модели их трактовок. С этим навыком у современных аналитиков большая проблема. Более того, почему-то считается дурным тоном это делать. Результатом становятся модели, отражающие только одну точку зрения. Когда ее достаточно, модель строится корректно, но, когда надо учесть больше точек зрения, задача становится неразрешимой.
В статье Моделирование активов предприятия при помощи проекционного моделирования я вспомнил пример из практики, когда возникла необходимость построения моделей одновременно с двух разных точек зрения: с точки зрения учета физических объектов и с точки зрения учета функциональных объектов. Напомню, что необходимость их учета возникла из-за того, что один и тот же термин в разных областях деятельности означает разные объекты. Трансформатор для эксплуатации и трансформатор для учета материального учета – разные объекты. Отличие в том, что в трансформатор для материального учета – это груда железа, не обязательно включенная в цепь. Такой трансформатор называют физическим объектом, или единицей оборудования. Для эксплуатации трансформатор должен быть подключен к цепи. Такой трансформатор называют функциональным объектом. Из этого есть следствие. Если мы моделируем операцию, то ее 4-Д часть с разных точек зрения может трактоваться по-разному: как часть физического трансформатора, или как часть функционального трансформатора. То есть, один и тот же 4-Д объем может трактоваться как физический трансформатор или как функциональный трансформатор.
В системной инженерии справляются с этой задачей, используя две предустановленные точки зрения (правда, об этом в стандарте, на мой взгляд, рассказано чрезвычайно запутано и противоречиво). Но, когда двух точек зрения становится недостаточно, системная инженерия пасует. Например, если надо сказать, что узел одновременно выполняет три функции: меряет температуру, скорость движения и скорость вращения вала двигателя, то нельзя сказать, что с одной точки зрения 4-Д объем может трактоваться как функциональный объект под названием термометр, с другой — как функциональный объект под названием спидометр, а с третьей — как функциональный объект под названием тахометр. Поэтому мы вынуждены идти дальше.
Итак, приступим к делу.
Трактовка проекций в виде событий
Для начала возьмем проекцию на пространство в виде объекта. То есть, у нас 4-Д объем проецируется на пространство в виде одного объекта. Как можно трактовать такую проекцию?
Допустим, что необходимо смоделировать событие «машина перекрашена из красного цвета в белый». Как смоделировать этот факт? Начнем с того, что в этом событии участвует некий 4-Д объем. Этот объем трактуется нами как часть 4-Д объема машины. Итак, первая трактовка 4-Д объема – это машина. Другая трактовка в том, что это белый объект и третья – что это красный объект. Это очень похоже на кота Шредингера. До тех пор, пока событие не пройдет, мы не знаем какого цвета машина, и она одновременно в нашем представлении и красная, и белая.
Гладя на эту модель, можно ли из данных о событии вывести, какого цвета будет машина после события? Нет, нельзя. Чтобы понять, какой машина была до, и какой она будет после, нам нужен сценарий: операция до, событие и операция после. Операция до говорит о том, что машина была красная. Операция после говорит о том, что она белая. Тогда, зная сценарий, мы можем вывести тот факт, что внутри события машина изменила цвет.
Это контринтуитивно, но логика говорит, что это так. Я долго не мог понять Крисса Партриджа, в том месте, где он написал, что в операции по созреванию яблоко одновременно и спелое, и неспелое. Только сейчас, пройдя этот путь самостоятельно, я понял, о чем он говорил!
Итак, факт того, что машина сменила цвет с красного на белый может быть выведен только из сценария. Вывести этот факт на основе события невозможно. И это противоречит распространенному утверждению о том, что событие – это изменение состояние чего-то. Изменение – это сценарий, а не операция и не событие.
Но даже зная сценарий, трактовать его можно по-разному. Поэтому вывести факт о том, что машина сменила цвет можно, но нельзя сказать, почему так получилось. Ответ на вопрос «почему» возлагается на интерпретацию события — покраска. Трактуем событие как покраску и на основе этой трактовки делаем вывод, что смена цвета произошла из-за покраски. Но в событии должно быть сказано, покраска чего? И вот тут есть та забавная особенность, на которую стоит обратить внимание. Мы помним, что та часть пространства-времени, которая трактуется в событии как машина, может трактоваться и как красный объект. Вопрос: что же красится в событии? Ответом будет: роль. То есть, роль – это обозначение 4-Д объема, который можно трактовать по-разному в зависимости от точки зрения. Можно трактовать как машину, можно как красный объект. Для этого для операции придумывается Роль1, и говорится, что трактовкой операции будет: Покрасить Роль 1. Теперь, подставляя вместо Роль 1 любую трактовку, мы получим новое утверждение. Так получается, что деталь точил Иванов, токарь и начальник цеха.
На этом моделирование события покраски машины заканчивается. Если мы оставим событие и его трактовку, хватит ли нам знаний для того, чтобы сказать, что машина сменила цвет? Нет, не хватит, потому что операция по покраске могла завершиться неудачно. То, что она завершилась успешно, становится ясно только на основе знаний, полученных вне события – из сценария.
Все участники в операции начинают свое участие одновременно и заканчивают одновременно. Это тоже кажется странным. Например, то, что заготовка и деталь начинают свое участие в операции по точению одновременно с ее началом и заканчивают одновременно с ее окончанием кажется нелепым. То, что в операции по включению света темнота и свет начинают свое участие одновременно и заканчивают одновременно – тоже. Интуиция сопротивляется этому тезису. Но давайте посмотрим, что говорит нам интуиция. Она говорит: в операции по включению света темнота участвует вначале, свет — потом. Свет и темнота не могут пересекаться! То есть, интуиция апеллирует к сценарию! Она говорит: давайте рассмотрим сценарий, в котором сначала темнота, а потом – свет. То есть, давайте уточним модель, чтобы развести по разные стороны темноту и свет. Но, уточняя модель, мы все равно наткнемся на событие, в котором свет и темнота существуют вместе. Такая гонка за точностью может длиться бесконечно. Для тех, кто любит математику: можете представить себе временную последовательность, которую дает нам серия уточняющих моделей, которая в пределе сойдется к какому-то конкретному временному значению. Это значение можно будет назвать сечением между светом и тьмой. Привет сечениям Дирихле!
Заметьте, мы рассмотрели проекцию одного 4-Д объема на время и уже столько невероятных и контринтуитивных следствий! Уверяю вас, это только начало. Я только немного приподнял занавес! Невероятное количество разных возможностей моделирования открывается, если следовать логике.
Определение понятия роли
Можно продолжать давать различные трактовки различным комбинациям проекций, но сейчас я хочу остановиться и вернуться немного назад. Мне хочется поделиться еще одним красивым фактом, следующим из предыдущих рассуждений. Я хочу рассказать про функциональную роль.
Определение термина роль также трудно, как и определение термина функция. Недавно я столкнулся с мнением, озвученном на форуме системной инженерии, о том, что термин функция является базовым и неопределимым понятием. Если это так, то с этим определением мы не сможем даже декомпозировать функцию! А это очень плохо. Я представил такое определение функции, в результате которого с функцией можно делать все, что пожелаешь: рассматривать под разными углами, декомпозировать, синтезировать на ее основе более крупные функции и тд. В данной статье я расскажу, как в функции появляются роли. Это позволит нам работать с ролями так же, как и с функциями: как мы того пожелаем.
В трактовке события есть роль. Ролям присваиваются имена. Самыми распространенными названиями ролей являются названия, заимствованные из теории деятельности. В теории деятельности утверждается, что в каждой деятельности должен присутствовать субъект, которого деятельность называет «исполнитель», объект деятельности: то, над чем производится работа: материал, результат деятельности: результат, инструмент деятельности: инструмент. Иногда вспоминают еще и про цель деятельности: цель. Такой подход к названию ролей является хорошим подспорьем в создании информационных моделей. Типов ролей немного, они унифицированы, почти для любой операции их можно найти. Беда в том, что заимствованы они из теории деятельности. А деятельность описывает психическую функцию субъекта, а не активность механизмов. И использовать указанные названия ролей можно лишь тогда, когда мы рассматриваем активность, в которой присутствует субъект, да еще с точки зрения деятельности. Когда же нам надо описать активность механизмов, или описать активность не с точки зрения деятельности, то теория деятельности перестает быть применимой. Если же мы упорствуем в своем стремлении натянуть презерватив на глобус, появляются модели, в которых механизмы несут в себе свойства одушевленных предметов: могут что-то делать, управлять, совершать действия и проч. Этот обман мало кто понимает, еще меньше понимают причины этого обмана. Я только что вам рассказал о нем. Мне крайне интересно, кто-нибудь понял его? Очень хочется услышать ответ от тех, кто это понял.
Иногда предустановленных ролей из теории деятельности становится недостаточно для описания активности. Тогда люди придумывают специфические роли. Например, исполнителя операции точения называют токарем, исполнителя функции управления заводом – директором. Так появляется множество других ролей. Кругом нас – множество операций, множество функций. Один и тот же 4-Д объем может одновременно участвовать в разных операциях и функциях. Поэтому происходят пересечения, когда начальник отдела и токарь – одно лицо. Просто один 4-Д объем трактуется одновременно и как участник одной функции, и как участник другой.
Спасибо! В следующей статье Продолжение рассказа о моделях. Сложные кейсы я расскажу про более сложные модели.
Моделирование событий
Данная статья поможет раскрыть очень важную тему – моделирование событий. Ведь именно они влияют на наше настоящее и будущее. Многим знакома такая ситуация, когда вы запланировали сделать кучу дел за день, но в самый ответственный момент вам мешают внезапные гости, срочная командировка или простуда.
Причем ничто не предвещало беды. Еще утром все шло по плану и вы были уверены в своих силах. Что же случилось и пошло не так? Давайте разберем все более подробно.
Данное понятие — это четкое представление достигнутой цели мысленно. Как это работает? Когда вы представляете в своем воображении то, что желаете получить, то формируете новую реальность на энергетическом уровне.
Простыми словами: ваше поле помогает вам материализовать все желаемое. Например, если пожелания хорошие и с любовью, то окружающие вас люди на подсознательном уровне начнут помогать вам в реализации будущих планов.
Вы и сами не заметите, как поставленные цели выполняются, а вы не прикладываете к этому особых усилий.
Как делать моделирование событий?
Вы можете смоделировать все что угодно: посещение врача, подписание выгодной сделки, поездку за границу, поход в кафе, найти новую выгодную работы, выйти замуж и так далее.
Однако для реализации всего этого необходимо выполнить несколько простых, но очень эффективных упражнений:
Моделирование ситуаций событий: Видео
Техники моделирования будущего
Сегодня мы поговорим об очень важной вещи, о которой вы, возможно, никогда не задумывались, а может, когда-либо, и слышали о ней. Речь пойдет о моделировании будущего, о программировании и создании нужных событий.
Мы поговорим о том, что в нашей жизни являют собой события: откуда они берутся, кто их программирует и почему так случается, что события, которых вы не ждете, наступают, а те события, которых вы очень хотите, просто страстно жаждете, никак не наступают и не сбываются.
Как оказалось, все события, которые происходят в нашей жизни, они создаются (моделируются) нами самими — нашими мыслями, тем, как мы относимся к тому или иному человеку и к тем или иным предметам, событиям и к тому образу жизни, которым мы живем. Все, что мы получаем в нашей жизни, целиком и полностью зависит от нас.
Сегодня с нами происходит то, о чем мы думали вчера. А завтра будет происходить то, о чем мы думаем с вами сегодня. И не зря мы сегодня с вами об этом говорим, потому что меня многие спрашивают: «Мерлин, а как сделать так, чтобы события в моей жизни происходили так, как я хочу?».
И это оказалось не столь сложным. Оказалось, что уже давно, много веков назад люди умели это делать. Люди умели программировать свои события. И не только прогнозировать, а прямо создавать событийный поток, который приводил их к нужному результату. Этим занимались очень многие духовные практики, в том числе и даосские. Вот как раз о даосских практиках чуть больше я вам сейчас и расскажу.
Как вы уже, наверное, догадались, необходимо что-то делать, чего в жизни вы еще не делали. И необходимо, соответственно, как-то думать, как вы в жизни не думали. Для того, чтобы притянуть в свою жизнь нужные события, нужные суммы денег, нужных людей, нужных партнеров, нужный бизнес, необходимо кое-что у себя перестроить. И, возможно, я вам расскажу то, о чем вы никогда не слышали. Сейчас вы услышите, как это можно сделать вам лично и абсолютно изменить свою жизнь.
Но сначала пару слов о том, как это работает. Работает это следующим образом. Древние даосы заметили, что мысли очень сильно влияют на то, что у нас происходит в жизни. Они в прямом смысле моделируют и программируют наше будущее.
Наверняка вы знаете, что я практик. Давайте сделаем с вами практику. Для этого у меня есть специальные предметы, которые нам помогут. Например, это натуральные рога дикого яка из Тибета. И еще поможет нам пчелиный воск, который пчелы заготавливают. Зачем нам это нужно? Вы, наверное, слышали неоднократно пословицу «Брать быка за рога». Чтоб вам легче было представлять, как эту практику делать, мы с вами будем брать быка за рога.
Для чего это нужно? В этой практике мы будем использовать две стихии – стихию Огня и стихию Воды. Огонь – это сердце, а Вода – это почки. Эти рога будут символизировать связь с природой, с жизненной силой быка. Так вам легче будет представить. Конечно, на самом деле получается немножко не так, все сложнее. Но для того, чтобы вы могли без рогов яка сделать эту практику, представлять будете так.
Техника «Моделирование событий» (практика)
Я беру кусочек воска и кладу его в рот. Немножко разжевываю. Получается своего рода жвачка. Оставляю его во рту. Для чего это делается? Это делается для того, чтобы у меня появилась некая связь с тем пространством жизненным, в котором живут пчелы. И рога я беру таким образом, как будто беру быка за рога. Это лечебные рога. Они используются специально для лечебных целей, существуют практики соскабливания.
Вам тоже нужно сделать жевательные движения, они помогут вам войти в состояние. Дальше необходимо руки вытянуть вперед и сжать рога в кулаки. Представьте, что перед вами бык, и вы держите его за рога. Необходимо сильно сжать кулаки. Сначала пальцы сжимаются, потом сам кулак. Напрягаете эти кулаки. Потом глаза закрываются и тоже сжимаются. Сжимаются челюсти и напрягаются все мышцы лица. И не только это.
Упражнение выполнять нужно стоя. Ступни стоят на поверхности. Пальцы ног сжать так, как будто вы цепляетесь когтями. В цигуне это называется укоренение. И еще нужно будет сжать три группы мышц в промежности. Что мы будем делать? Во-первых, это делается очень быстро, но вы почувствуете всю действенность этого упражнения. Это будет первый шаг к программированию и моделированию ваших событий в жизни. Это такой предварительный вступительный шаг.
Когда вы все сожмете, представьте огонь в своем сердце. Вы должны понимать, огонь в вашем сердце разгорится. Две стихии – Огонь и Вода – будут взаимодействовать, и вы наполнитесь энергией.
Упражнение мы будем делать всего три раза. Поэтому приготовьтесь, встаньте, ноги на ширине плеч, носки ног чуть-чуть внутрь. Пальцы ног как будто вцепились в поверхность, как когти. Нужно будет напрячь все группы мышц, лицо, сжать кулаки. Возможно, у вас лицо покраснеет или вы почувствуете жар, начнет выделяться пот. Это все нормально. Таким образом, вы входите в состояние для создания событий в своей жизни.
И как раз в тот момент, когда вы все это сделаете, зажжете в сердце Огонь, вам необходимо будет почувствовать, как вы соединяете Огонь в сердце с Водой в почках. Все усиливается и в этот момент нужно подумать о том событии, которое вы бы хотели создать.
У нас будет с вами три попытки. Это сделать физически достаточно напряженно, чтоб вы знали. Поэтому приготовьтесь к тому, что будет физическая нагрузка. Итак, приготовились. Руки вытянули вперед, сжали в кулаки. И теперь закрыли глаза, сжали кулаки, лицо, вцепились ногами, укоренились. Напрягли все мышцы промежности. И задержали дыхание.
Представляем Огонь в сердце. Отпустили. Вы чувствуете, как пошла энергия. И второй раз. Закрыли глаза, взяли быка за рога, сжали кулаки, глаза, лицо, мышцы промежности. Ноги вцепились и задержали дыхание. Почувствовали огонь, он разгорается в теле. Остановились второй раз.
И еще третий раз. В нем происходит соединение, которое помогает создать события в вашей жизни. Итак, приготовились. Руки вперед. Взяли быка за рога. Сжали кулаки, мышцы лица, промежности, укоренились. Задержали дыхание. И представили то, что вы хотите. Расслабьтесь.
Это упражнение, которое вы проделали, способствует моделированию будущего и привлечению нужных вам событий, которые вы хотите увидеть в собственной жизни.
Практика «Моделирование событий» (видео)
Смотрите видео, делайте практику и моделируйте нужные вам события — управляйте своей Судьбой!
Пусть ваши желания станут Реальностью!
P.S. Примите в ДАР мощный Цифровой Амулет «ЭКСТРЕННАЯ УДАЧА» :
ПОНРАВИЛОСЬ ТО, ЧТО ПРОЧИТАЛИ? ПОДЕЛИТЕСЬ!
Краткое описание BPMN с примером
О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.
Также я хочу сразу обратить ваше внимание на то, что здесь я буду говорить именно о нотации BPMN, т.е. о языке моделирования бизнес-процессов. Я, конечно, постараюсь максимально просто описать основы BPMN так, чтобы они были понятны даже новичкам. Но также важно понимать, что здесь я буду говорить именно о языке, а не о методологии.
Методология моделирования бизнес-процессов — это понятие очень обширное, по сути, это та самая база, знания которой нужны для практического применения языков моделирования бизнес-процессов. О ней я буду говорить в будущих статьях и не раз. Почему я делаю на этом акцент? Многие люди (и я в свое время также) считают, что достаточно выучить язык бизнес-моделирования, и вы сумеете выстраивать бизнес-процессы. 
Практика показывает, что без базовых знаний здесь не обойтись. И всем, кто только планирует изучение моделирования, я настоятельно советую сначала ознакомиться с методологией, понять общие принципы бизнес-моделирования, получить определенные навыки бизнес-анализа. И только потом приступать к изучению BPMN или любого другого языка.
А для понимания причин появления BPMN и всех нюансов моделирования при помощи этой системы нотаций, понадобится также знание основных проблем, которые решает BPMN, что для работы использовали до появления BPMN, и с какими сложностями сталкивались. Ведь появление новых систем и нотаций невозможно без понимания определенной проблематики. И я считаю, что этот аспект очень важен для понимания сути вопроса, что же такое на самом деле BPMN.
Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.
В то время Bizagi был относительно простым модулем, в котором присутствовал удобный редактор для моделирования (рисования) бизнес процессов, но еще не было никаких инструментов для исполнения бизнес-процессов. Но даже тогда строгие правила BPMN, принятые в системе Bizagi, помогали избегать значительного числа ошибок, столь частых при обычном «рисовании» бизнес-процессов в графических редакторах или на бумаге.
В поисках оптимального решения для себя я изучал ARIS, инструменты 1С для бизнес-моделирования, различные системы моделирования бизнес-процессов, которые были придуманы различными бизнес-консультантами, как российскими, так и зарубежными. И, конечно же, познакомился с нотацией BPMN.
При первом знакомстве BPMN мне во многом понравился, идея была очень хорошей, а вот исполнение на тот момент с моей точки зрения еще было «сырым». И полноценно пользоваться BPMN я начал около 3 лет назад, после того, как задачи, которые я стал решать, усложнились настолько, что IDEF0 применять полноценно никак не получалось. И оказалось, что нотация развивалась, и теперь я активно пользуюсь BPMN в своей работе.
BPM: ОСНОВНЫЕ ПОНЯТИЯ
Для того чтобы разобраться, что такое BPMN, нужно понимать, что часть этой аббревиатуры «BPM» имеет две расшифровки — Business Process Modeling и Business Process Management. В первом случае – это непосредственно моделирование бизнес процесса, а во втором – управление бизнес-процессами, т.е. общая система, частью которой и является Business Process Modeling.
При этом моделирование бизнес-процессов – является основой и основной целью. При помощи моделирования мы можем описать любой бизнес процесс, а исполняться они могут в самых разных системах управления.
Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.
Можно сказать, что BPMN является частью двух важнейших составляющих:
ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ
Когда впервые сталкиваешься с моделированием бизнес-процессов, очень тяжело понять, с чего же тут начать, где искать основу для понимания того, как строятся бизнес-модели. И я также с этим в свое время столкнулся.
А основой здесь является наличие языка описания бизнес-процессов. И важно понимать, что это действительно язык, как и языки программирования или даже языки, на которых говорят люди, он также прост на базовом уровне и сложен, если начинать изучать нюансы. У этого языка есть свои правила, семантика, орфография, свои законы, которые нужно изучить и строго им следовать. С другой стороны, как и любой искусственный язык, предназначенный не для живого общения, а для строгого и однозначного описания каких-то действий и процессов, он в своей основе проще “живых” языков, а его правила — строго логичны.
Кроме того, в силу ограниченности задач, которые стоят перед этим языком, он гораздо более определен в терминологии. Но все же и здесь имеется очень много нюансов, каких-то сочетаний «слов», которые несут собственную смысловую нагрузку. И очень важно строго следовать правилам сочетания разных элементов языка и знать ограничения (что с чем сочетать недопустимо, как начинать описание, чем заканчивать и пр.).
И как любой технологический язык, описание бизнес-процессов имеет собственные специфические конструкции, понять которые без определенного уровня технологических знаний будет крайне затруднительно. А потому для изучения языка описания бизнес-процессов также важно, в первую очередь, понимать сами технологии, для описания которых он предназначен.
Например, для моделирования бизнес-процессов вам понадобится знание таких понятий, как «условия», «цикл», «декомпозиция» и т.д.
Важно понимать: BPMN не является языком описания IT-систем. Эта нотация предназначена для описания предметной области реального бизнеса. И здесь могут быть задействованы как программные системы, так и люди (сотрудники компании, заказчики, поставщики). Это самое главное отличие этой нотации от графических инструментов для описания программ.
НЕМНОГО ИСТОРИИ BPMN
Для большего понимания особенностей моделирования бизнес-процессов и структуры языка моделирования, я хочу немного рассказать об истории появления нотации BPMN. Разработка системы моделирования бизнес-процессов и спецификаций для нее (языка моделирования) ведется относительно давно.
Первая версия BPMN 1.0 была выпущена в мае 2004 года компанией Business Process Management Initiative. Эта версия обладала ограниченными возможностями и была, так сказать, «пробным вариантом», который нуждался в многочисленных доработках.
Следующая версия BPMN 1.1 выходит в январе 2008, и здесь разработкой и поддержкой занималась уже Object Management Group, организация, появившаяся в результате слияния BPMI с другой компанией-разработчиком программного обеспечения.
Еще один релиз появляется всего через год, версия BPMN 1.2 выходит в свет в январе 2009. Разработчик OMG остается прежним. Команда, которая занимается продуктом, после слияния практически не меняется.
В январе 2011 года компания OMG выпускает версию BPMN 2.0, а в декабре 2013 выходит последний на данный момент релиз – BPMN 2.0.2. Именно эта версия предлагается всем пользователям и сегодня, так как система получилась стабильной, возможности моделирования в ней очень широкие, а язык моделирования (набор обозначений) по большей части понятен всем бизнес-пользователям – как бизнесменам, бизнес-консультантам, так и техническим специалистам.
Из истории можно сделать вывод что период изменений в этом языке миновал, и можно спокойно изучать и использовать его на практике.
Сегодня BPMN – это один из наиболее распространенных методов описания бизнес-процессов, которые сегодня уже «понимают» как бизнес-пользователи, так и программные продукты, предназначенные для работы с бизнес-моделями. Т.е. этот язык описания является стандартным также и для создания исполняемых алгоритмов в сфере управления бизнесом.
Я особенно хочу подчеркнуть этот момент, так как и сам столкнулся поначалу с непониманием, зачем те или иные вещи усложнять? Ведь для описания бизнес-процессов, например, при GAP-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.
ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?
И здесь я хочу сделать небольшое отступление. Дело в том, что перевод терминов и понятий с английского языка на русский – занятие сложное. Найти наиболее точное слово обычно может специалист, но переводом занимается совсем другой человек, часто вообще не имеющий понятия о сути тех понятий, которые он переводит. В результате появляется множество неточностей, понятия усложняются, возникает путаница. Об особенностях перевода и сложностях применения терминов в сравнении с графикой я уже писал, например, в статье Знакомство с нотацией IDEF0 и пример использования (см. раздел “Несколько слов о преимуществах графики”).
Я в этой статье буду оперировать теми понятиями и терминами, которые использую сам на практике. И они не всегда будут совпадать с теми словами, которые вы встречали в Википедии или каких-то переведенных руководствах. Причина заключается именно в том, что я, как специалист, в некоторых случаях нашел для себя более точный перевод английского термина. И применение слова, которое выбрал для себя я, помогает понять суть процесса намного быстрее.
Конечно, я буду пояснять всю терминологию по мере необходимости. А потому думаю, что проблем с пониманием и терминами не возникнет. Но все же обратить внимание на этот момент, я считаю правильным.
Язык описания бизнес-процессов опирается на следующие базовые объекты:
Я же остановлюсь только на базовых элементах, без которых не обходится ни одна бизнес-модель. Для первого знакомства с BPMN и понимания основных принципов работы нотаций этого достаточно.
EVENT (СОБЫТИЕ)
Event – это то событие, которое произошло в описании процесса или хореографии (о ней я расскажу отдельно). Эти события могут быть начальными, конечными или промежуточными.
Например, опишем процесс получения заказа от клиента по телефону:
ACTIVITY (ДЕЙСТВИЯ)
Activity – это те действия (задачи), которые должны быть выполнены на определенном этапе бизнес-процесса. Их при моделировании обычно обозначают в виде прямоугольников, в которые вписывают суть действия.
Действия могут быть элементарными, т.е. неделимыми на какие-то более простые действия, так и не элементарными, т.е. такими, которые при детализации делятся на последовательность определенных более простых действий.
Обычно действия делят следующим образом:
GATEWAY (ШЛЮЗ, РАЗВИЛКА)
Gateway – это контрольный узел, который появляется в случае условного ветвления бизнес-процесса. Графически изображается в виде ромба.
Также шлюзы необходимы в случаях, когда порядок действий зависит от тех или иных факторов. Например, при работе с заказчиками шлюз появляется на этапе принятия клиентом решения о покупке – «да или нет». При положительном решении необходимо оформить покупку, при отрицательном – выяснить возможные причины отказа, провести работу с «отказом» и т.д.
FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)
Поток Flow – это последовательность действий, обозначается как стрелка, и показывает, какое действие после какого необходимо совершить.
Message Flows – это пунктирные стрелки в бизнес-модели, которые показывают сообщения, которыми обмениваются участники бизнес-процесса. Например, если заказ переходит от клиента в обработку в отдел продаж, он сопровождается сообщением, которое содержит информацию об этом заказе. Также Message Flows могут связывать два отдельных пула в диаграмме.
Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек. Необходима для того, чтобы показывать артефакты (о них – ниже).
POOL (ПУЛ)
Пул – это объект описывающий какой-то один процесс на диаграмме. Он может быть не изображен на диаграмме, но он всегда есть. На одной диаграмме может быть несколько Пулов. Пул можно развернуть для просмотра деталей.
Пул может также содержать, так называемые, «дорожки». Они нужны для того, чтобы указать участников процессов, которые скрыты в пуле. Например, в процессе работы с клиентами участвует менеджер по продажам, руководитель отдела продаж, возможно, бухгалтер или кассир.
DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)
Объекты данных – это элемент, который показывает, какие данные и документы нужны для того, чтобы какое-то действие запустилось, либо которые являются результатом выполненного действия. Объектом данных может быть сформированный заказ. Для менеджера это будет результат действий, а для склада, который получает заказ – началом действия (сбор товаров и отгрузка).
MESSAGE (СООБЩЕНИЕ)
Этот элемент необходим, чтобы показать коммуникацию между двумя участниками процесса. Это может быть Email, сообщения внутри системы совместной работы, переписка в каком-либо из мессенджеров, которыми пользуются участники процесса, коммуникации на сайте компании, sms-сообщения и т.д.
ARTEFACT (АРТЕФАКТЫ)
Под артефактами в BPMN понимают объекты, не являющиеся действиями и не связанные с действиями напрямую. Это могут быть любые документы, данные, информация, которая не влияет напрямую на исполнение процесса.
Выделяют два вида артефактов:
Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.
ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-ПРОЦЕССЫ
В бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для изучения и демонстрации вариантов работы предприятия.
В принципе, между их построением нет особой разницы, здесь важен исключительно желаемый результат. Либо бизнес-модель будет применяться только для облегчения взаимопонимания между заказчиком (руководителем) и консультантом (исполнителем). Либо эта нотация будет впоследствии использоваться в какой-либо программной среде для организации работы компании. В обычных руководствах вы этого разделения на две части не найдете. Но я лично считаю, что имеет смысл условно так делить бизнес-процессы, так как при различном желаемом результате потребуется различная глубина проработки деталей и выбор возможных инструментов для работы.
Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Исполняемые процессы нужны, например, на предприятиях, где принят процессный подход к деятельности. Программное обеспечение позволяет вести контроль всех процессов в режиме реального времени, и на основе получаемых на каждом из этапов данных, руководитель компании и подразделений всегда смогут понимать, на каком этапе находится работа по тому или иному процессу. Подобный метод позволяет значительно повысить эффективность управления.
Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0. А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.
Я рекомендую на начальном этапе работы с BPMN создавать неисполняемые бизнес-процессы. Это действительно очень удобная нотация для того, чтобы иллюстрировать свои идеи и предложения, демонстрировать «узкие места» в бизнесе, даже просто для себя разбираться в структуре работы той или иной компании очень удобно с использованием нотаций. Наглядная графика и строгие правила в этом очень помогают.
Исполняемый вариант требует глубоких знаний BPMN, а также внимательного отношения к каждой детали, так как вы, по сути, создаете программу (алгоритм) для компьютера, просто используете для этого не текстовый язык, а графические нотации. Это дело – для опытных специалистов.
ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА?
Нотации BPMN можно и даже нужно использовать при работе с малым и средним бизнесом. Возможно, что вы не будете реализовать бизнес-модель на уровне программного обеспечения, так как это всегда — дополнительные затраты, и в условиях малого бизнеса нет необходимости в подобных инструментах контроля и анализа работы.
Но, тем не менее, на уровне неисполняемых бизнес-процессов я очень активно используют именно BPMN. Дело в том, что при всей сложности вхождения (т.е изучения и умения работать с нотациями), уровень понимания BPMN — низкий, т.е. для чтения нотаций не требуется вообще никаких особых знаний и навыков. Графические нотации понимаются интуитивно. И я еще не встретил ни одного человека, для которого бы прочесть нотацию было бы сложно. Эта нотация создавалась специально для того, чтобы найти общий язык между аналитиком и обычными бизнесменами (управленцами).
В результате, как я и писал выше, при помощи BPMN вы экономите свое время и время заказчика (руководителя) и добиваетесь максимально высокого уровня взаимопонимания. Нотации не позволяют “двойного прочтения”, а потому очень помогают в работе.
МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN
О том, насколько удобна BPMN, я сказал уже много. Но для выбора любого инструмента важно также понимать и возможные минусы. О них я сейчас и расскажу:
ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN
Конечно же, без примера описание моделирования бизнес-процессов было бы неполным и не до конца понятным. Я решил в качестве примера взять процесс обеспечения заказов покупателей, так как этот этап работы присутствует практически в любом направлении бизнеса, а потому реализация этого процесса на практике будет понятна без дополнительных пояснений широкому кругу читателей.
Результатом этого процесса должно быть обеспечение покупателя необходимыми ему наименованиями товара.
Данный бизнес-процесс выполняется следующим образом:
BPMN позволяет при моделировании бизнес-процессов опускать на определенном уровне те или иные реальные процессы. Так, в нашем случае мы оставляем «за скобками» получение заказа и согласование перечня товаров и их стоимости с клиентом. Это можно будет детализировать в случае необходимости отдельно. Также в этом примере мы оставили «за скобками» процессы оплаты товары, отгрузки, оформления расходных документов и т.д. А сейчас у нас другая задача – описать сам процесс обеспечения покупателя необходимыми товарами.
Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».
Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:
При необходимости этот бизнес-процесс может быть детализирован, что также помогает увидеть, что и как работает (должно работать) для получения результата.
КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?
Здесь я хочу поделиться некоторыми советами о том, с чего начать и как производить разработку моделей бизнес-процессов. Мои советы основаны на знаниях особенностей бизнес-моделирования и личном практическом опыте.
Что еще хотелось бы посоветовать:
Еще статьи по данной теме:
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.