Глава Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)

Заметьте, что ресурсы, которые мы не отображаем на диаграмме, тоже могут быть причиной скрытых зависимостей, к примеру, когда два процесса используют энергоёмкие станки, которые не следует включать одновременно. Убедитесь, что диаграмма легко читается и содержит не более 20 объектов; если это не так, сгруппируйте несколько контекстно связанных объектов в один объект подходящего типа с вложенной диаграммой, содержащей данную группу. Практика показывает, что когда диаграмма содержит более 20 объектов ресурсов или процессов , то схема перестаёт восприниматься цельно, а начинает выглядеть, как лабиринт, в котором зрителю нужно выискивать интересующие его пути.

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

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

Это довольно полезное свойство: Другим важным аспектом детализации диаграмм является возможность развести аудитории: Разбив диаграмму на уровни, мы можем каждую новую диаграмму проектировать с учётом её аудитории, формируя сюжет, понятный и увлекательный именно для неё. Убедитесь, что объекты имеют тип, соответствующий их сути, визуально разделите информационные и физические потоки. Если диаграмма содержит несколько контекстно связанных объектов, выделите их с помощью группы.

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

Такая организация диаграммы довольно наглядна, но может иметь свои композиционные недостатки. Для процессов, не являющихся элементарными операциями, постройте вложенную диаграмму, начиная с Шага 1. На Шаге 7 мы синтетически создавали новую задачу из группы объектов и детализировали её вложенной диаграммой.

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

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

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

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

Заметьте, что внедрённая в описание процесса иерархия может не быть частью самого процесса, она больше нужна для целей эффективного восприятия аудиторией — иногда, чтобы что-то сделать проще, сначала это нужно усложнить. Ниже приложена диаграмма пошагового процесса, изложенного в статье, потратьте несколько минут на её изучение. Ой, у вас баннер убежал! DevOps - Support level 2. Roonyx Ростов-на-Дону Возможна удаленная работа.

Все вакансии Разместить вакансию. Если это всё счастье рисовалось Вашим приложением, то следует признать, что презентация её возможностей Вам явно удалась! Что же, чудесно, спасибо за комплимент! Но, такой результат не полностью заслуга приложения, диаграммы составлены так чтобы легко и чисто читаться — вот этим опытом я и хочу поделиться. НЛО прилетело и опубликовало эту надпись здесь. Отчего же, приложение и web-сервис разработаны мною, у меня в профиле есть ссылки на сайты wokflow.

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

Круто, спасибо за статью. Главное чтобы не уйти в художники после этого навыка. Споткнулся только на Шаге 5. Почему просто не добавить ресурс, который забыл указать на Шаге 2? На Шаге 2 определяются исходные ресурсы, то есть те которые должны быть в наличии перед началом исполнения работ, это довольно узкий список. А на Шаге 3 определены ресурсы, которые так или иначе становятся доступны в процессе работ, в принципе они могут включать в себя и исходные ресурсы и те ресурсы, которые были произведены по ходу дела.

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

Его использовали при построении Бурана, в этом проекте участвовало 2 миллиона человек. Вашу диаграмму можно улучшить с помощью этой концепции. Честно попробовал пользоваться сервисом, но невозможность делать папки или блоки одинакового размера превращает все в цирк. Добавьте, пожалуйста, или направляющие, или возможность указать точный размер, иначе это просто ад перфекциониста. А то что лист начинается не с целой ячейки, а с половины, вообще убивает: Сервис выглядит очень полезным, но лично для меня им пользоваться невозможно.

Спасибо, что поделились опытом пользования. Все размеры автоматически выравниваются по сетке, странно что у вас не так, а то что лист начинается не с целой ячейки, а с половины, вообще не понятно — у себя я такого не отыскал. Можно поинтересоваться какой у вас браузер и ОС? Последний Chrome, Windows Скрин стартового листа с половиной ячейки: Какие варианты я вижу у вас, чтобы все выглядело более-менее структурированно: То есть я искренне пытался заставить себя пользоваться инструментом, но получается абсолютно кривая разноразмерная каша именно у меня, инструмент прекрасный.

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

Пожалуй, соглашусь с предложенной последовательностью построения конечные цели — доступные ресурсы — промежуточные цели — процессы для схем to be. Для схем as is, думаю, нужно начинать с процессов, а уж к ним пристегивать цели и ресурсы: Естественно это так и должно быть, любая диаграмма не существует сама по себе, он всегда находится в каком-то контексте с уже сформировавшейся аудиторией.

С моей экстремальной точки зрения в развитой корпоративной культуре as is не должно существовать, но в жизни всё иначе. Если to be это работа строителя, то as is это призвание реставратора в хорошем смысле, и патологоанатома в плохом. Это совсем разные подходы, и если для построения процесса еще можно предложить какой-то метод, то с анализом на месте всё сложнее, здесь работа больше похожа на занятие детектива.

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

Вот он и спрашивает: Такое ни в одной методике не предусмотреть. В моей идеальной картине мира as is должны получаться из to be сразу после внедрения с отражением всех расхождений, которые образовались в процессе реализации. Я работаю на стороне клиента и мне, в отличии от внешних консультантов, важно иметь актуальную информацию по процессам: Но в жизни, конечно, все не так.

Правила и рекомендации построения BPMN-диаграмм. Примеры построения BPMN-диаграмм для расчета допускаемых скоростей. Information technology - Object Management Group. Основной целью BPMN является обеспечение доступной нотацией описания бизнес-процессов всех пользователей: Таким образом, BPMN нацелен на устранение расхождения между моделями бизнес-процессов и их реализацией [ 23 ].

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

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

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

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

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

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

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

Задача считается выполненной, если сообщение послано хотя бы один раз;. Задача считается выполненной, если сообщение получено хотя бы один раз;. Характерная задача, выполняемая исполнителем при содействии других людей или программного обеспечения;.

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

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

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

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

Дополнительные особенности реализации или выполнения действия могут быть указаны с помощью маркеров, отображаемых у нижнего края символа:. Действие выполняется в цикле с пред- while или пост- repeat-until условием;.

Параллельное или последовательное выполнение нескольких экземпляров однотипных действий. При последовательном выполнении действие можно рассматривать как цикл с параметром for ;. Действие выполняется взамен стандартного при невозможности его удачного завершения;. Указывается только для подпроцессов. Конкретный состав и последовательность входящих в него действий определяется исполнителем в процессе его выполнения.

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

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

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

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

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

Возможно асинхронное выполнение маршрутов связанных потоков операций и действий. Не имеет входящих потоков. С помощью дополнительных маркеров на диаграмме может быть показана специфика использования и содержания данных:. Исходные ТМЦ или информация для выполнения действий. Отображается у верхнего края символа;. Коллекция или массив однотипных данных. Отображается у нижнего края символа.

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

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

Бизнес-процесс Верхний уровень процесса — А0 контекстная диаграмма. Планировать деятельность. А1.  На рис. приведен пример бизнес-процесса в нотации IDEF3 под названием «Обработать заявку клиента». Рассматриваемый про-цесс — часть более общего процесса «Сбыт готовой продукции». Про-цесс начинается с поступления заявки клиента, которую обрабатыва-ет функция «Выполнить учет заказа в системе». Пример бизнес-процесса. В качестве примера я взял крупный магазин по торговле мебелью и его бизнес-процесс "Покупка клиентом товара". На рис. представлена диаграмма этого бизнес-процесса в нотации BPMN, с комментариями по нотации. увеличить изображение Рис. Пример бизнес-процесса. Весь бизнес-процесс разбит на действия, которые изображаются прямоугольниками со скругленными углами. Переходы между действиями показаны стрелками, а документы, которые порождаются или используются каким-либо действием, показаны прямоугольниками с загнутым правым углом. На рис. показан пример диаграммы со специфическими потоками управления (условным и по умолчанию). Рис. Пример использование специфических потоков управления. Все многообразие процессов и способов взаимодействия между их участниками в BPMN поделено на типы (sub-model).  Примерный вид. Диаграмма процессов (Process Diagram). Частный (внутренний) бизнес-процесс (Private (internal) Business Process). неисполняемый (Non-executable). Процесс, выполняемый одним участником без указания на диаграмме других участников взаимодействия. Степень детализации (абстракции) участник процесса может быть произвольным (организация, отдел, сотрудник).

Примеры описаний бизнес-процессов, разработанных компанией Питер-Консалт

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

В данной статье, будет рассмотрена основная, свойственная большинству проектов. Содержание 1 Установка границ процесса 2 Основные блоки 3 Актуальность подобных схем 3. Каждое действие, имеет начало и конец, но между этими двумя этапами, существует целая система обработки заказа, расчета стоимости или консультации. При таком подходе, легче выстроить внутренние этапы. В работе компании, в основном, конечным пунктом является заключение сделки, сдача проекта, продажа.

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

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

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

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

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

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

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

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

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

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

Мы полагаем, что от применения этих диаграмм следует отказаться, в первую очередь потому, что они недостаточно выразительны и точны для исполнения в Системе. Дело не в том, что Система - "тупая", а просто на диаграмме не все необходимое указано, а то, что указано, допускает неоднозначную трактовку.

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

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

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

В результате рождаются документы толстые книжки , которые читают в основном методологи и разработчики инструментальных средств моделирования. Но как раз благодаря этим "толстым книжкам" и достигается однозначность трактовки диаграмм. Например, как отмечают специалисты в частности, в [1] , работа по созданию модели eEPC должна регламентироваться "соглашением о моделировании", предварительно составляемым командой проекта.

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

Одно время я сам удивлялся:

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

Найдено :

Случайные запросы