Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 3

03.05.21

Архитектура

Итак, сейчас рассмотрим уже самые разнообразные графические нотации и начнем с очень неожиданной – ДРАКОНа.

Инструкция: «Запрещено разбирать устройство. В нем нет деталей, которые мог бы отремонтировать пользователь». Производитель меня заинтриговал. Практически провоцирует. (С) из Интернета

Вступление

В первой статье этого цикла мы рассмотрели, какие методологии моделирования и описания бизнес-процессов сейчас существуют (//infostart.ru/public/1426878/).

Потом была вторая часть (//infostart.ru/public/1430187/) в которой мы рассмотрели уже непосредственно нотации (сами графические инструменты), а именно все нотации семейства IDEF.

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

И начнем мы с очень интересной нотации – отечественной разработки – языка ДРАКОН.

Краткое описание нотаций

ДРАКОН

ДРАКОН – это визуальный алгоритмический язык программирования и моделирования, разработанный в СССР и сейчас доступный. Расшифровывается как: Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность.

Основа языка – блок-схемы по ГОСТ 19.701-90 и ISO 5807-85.

Немного истории, как появился данный язык программирования. Он был частью космической программы «Буран». Начало разработки приходится на 1986 Министерством общего машиностроения СССР (Научно-производственный центр автоматики и приборостроения им. акад. Н.А. Пилюгина, Москва) и Академия наук СССР (Институт прикладной математики им. М.В. Келдыша). Основные работы по разработке языка были закончены в 1996 году (спустя 3 года после закрытия программы «Буран»). В этот момент была создана автоматизированная система проектирования программных систем (CASE-технология) ГРАФИТ-ФЛОКС.

Так на основе трех языков ПРОЛ2 (для разработки бортовых комплексных программ Бурана), ДИПОЛЬ (для создания наземных программ Бурана) и ЛАКС (для моделирования) В. Паронджановым был разработан единый универсальный язык программирования и моделирования.

На начальном этапе развития информация о ДРАКОНе была недоступна для пользователей, так как работы по ракетно-космическим программам и, в частности, по космической программе Буран были строго засекречены как составляющие государственную тайну.

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

Фундаментальной основой языка являются собственно блок-схема, диаграмма Насси-Шнейдермана (Nassi-Shneiderman diagram), псевдокод (язык описания алгоритмов) и др.

А основой алгоритмического языка моделирования являются диаграммы поведения языка UML: диаграмма деятельности (Activity diagram), диаграмма состояний (UML State machine) и некоторые диаграммы взаимодействия, например, диаграмма синхронизации (Timing diagram).

Графическое изображение языка ДРАКОН. Основой графического синтаксиса языка ДРАКОН является графический алфавит. Икона – графический элемент (графическая фигура). Язык ДРАКОН содержит 27 икон. Для каждой иконы задана ориентация, однозначно показано направление соединительных линий, входов и выходов. Благодаря жестко заданной ориентации икон и соединительных линий в большинстве случаев отпадает необходимость использовать стрелки. Сама блок-схема, отображающая порядок действий с точно определенными свойствами, называется дракон-схема.

Для чего используется:

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

Преимущества:

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

Недостатки:

  • Нет фирмы, которая поддерживает и развивает язык программирования и моделирования ДРАКОН, а также его инструменты. Сейчас этот язык существует как идея, и не существует как товарный продукт. Все держится на работе и труде энтузиастов.
  • Инструментальные средства языка ДРАКОН имеют экспериментальный характер и нуждаются в совершенствовании. Доступны для использования следующие инструментальные средства:
    • ИС Дракон (коммерческая программа) разработчик Геннадий Тышов (Россия, Северодвинск);
    • DrakonHub разработчик Stepan Mitkin (Норвегия).
  • Отсутствует стандарт языка ДРАКОН. В качестве стандарта используются книги:
    • Паронджанов В. Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. – М.: Препринт, 2019. – 374 с.
    • Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012, 2014, 2016. – 520 с.
  • Очень маленькая доля рынка использования данного языка

Пример диаграммы:

Блок-схемы

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

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

Для разработки блок-схем могут быть использованы стандартные офисные программные продукты, например MS Word или MS Visio.

Ключевые особенности:

  • Множество вариантов использования.
  • Может использоваться как основа для других нотаций.
  • В основе заложен набор легко понимаемых и узнаваемых символов.
  • Является предшественником многих нотаций.

Для чего используется:

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

Преимущества:

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

Недостатки:

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

Пример диаграммы:

UML

UML (Unified Modeling Language) – унифицированный язык моделирования, язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

Основные характеристики:

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

Для чего используется:

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

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Преимущества:

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

Недостатки:

  • Создан изначально для моделирования программного обеспечения, моделирование бизнес-процессов – второстепенная задача.
  • Разные средства моделирования могут реализовывать нотацию по-разному.
  • Необходимость знания различных диаграмм и их нотаций.

Пример диаграммы:

CPN

Раскрашенная сеть Петри (также цветная, окрашенная; Coloured Petri Net, CP-net) – это графоориентированный язык для проектирования, описания, имитации и контроля распределенных и параллельных систем. Один из видов сетей Петри, позволяющий различать виды меток, используемые в сети. Для этого каждой метке приписывается некоторое значение, обычно называемое цветом (цвета принято применять для удобства визуализации, и чтобы подчеркнуть, что над значениями меток в рамках формализма невозможны никакие операции, кроме проверки равенства). В процессе имитационного моделирования метке невозможно присвоить новое значение; в то же время, вместо цвета меткам могут быть приписаны значения, обладающие сложной внутренней структурой, то есть относящиеся к сложным типам данных и эти значения могут быть использованы в условиях срабатывания переходов.

Теория раскрашенных сетей Петри разрабатывается более 20 лет рабочей группой (CPN Group) университета г. Орхуса (University of Aarhus, Denmark) под руководством профессора Курта Йенсена (Kurt Jensen).

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

В качестве программного представления цветных сетей Петри используется специальная версия языка MLCPN ML, являющуюся расширенной версией SML/NJ.

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

Основные характеристики:

  • Формальная модель сетей Петри отличается хорошо разработанным математическим аппаратом.

Для чего используется:

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

Преимущества:

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

Недостатки:

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

Пример диаграммы:

Рассмотрим пример известного нам уже Саввы Игнатьевича, который будет кушать пирог. Есть две фишки: Савва Игнатьевич, пирог. Голодный Савва Игнатьевич становится сытым после того, как съедает пирог.

Определены два множества цветов: множество s с элементом Савва Игнатьевич и множество p с элементом Пирог. Позиции Голодный Савва Игнатьевич и Сытый Савва Игнатьевич имеют множество цветов s с фишкой Савва Игнатьевич. Позиция Еда имеет множество цветов p с фишкой Пирог. Чтобы запустить переход Кушать, необходимо наличие двух фишек: Савва Игнатьевич и Пирог. Переменные x и y используются, чтобы извлечь фишки из входных позиций и поместить новую фишку в выходную позицию. Пример иллюстрирует способ, с помощью которого могут быть обработаны различные типы фишек.

EPC

Событийная цепочка процессов (EPC-диаграмма, Event-driven Process Chain) — тип блок-схемы, используемой для бизнес-моделирования, а также нотация для моделирования процессов, входящая в методологию ARIS. EPC может быть использована для настройки системы планирования ресурсов предприятия (ERP), и для улучшений бизнес-процессов.

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

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

Основные характеристики:

  • Нотация EPC была разработана в начале 1990-х годов профессором Августом-Вильгельмом Шеером (August-Wilhelm Scheer) как часть методологии ARIS.
  • Может использоваться в сочетании с вертикальными или горизонтальными дорожками.
  • В основе лежит набор легко узнаваемых символов, может расширяться большим количеством дополнительных или специальных символов.

Для чего используется:

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

Преимущества:

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

Недостатки:

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

Пример диаграммы:

ARIS

Методология ARIS (Architecture of Integrated Information Systems, проектирование интегрированных информационных систем) – это одна из современных методологий бизнес-моделирования, получившая широкое распространение.

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

Модели методологии ARIS:

  • OD – Objective diagram – Диаграмма целей
    Модель описывает стратегические цели компании и х взаимосвязь с другими элементами организации.
  • PST – Product/Service tree – Дерево продуктов и услуг
    Модель описывает продукты и услуги, производимые компанией, и их взаимосвязь с другими элементами организации.
  • FT – Function tree – Дерево функций
    Модель описывает функции, выполняемые в компании и их иерархию.
  • FAD – Function allocation diagram – Диаграмма окружения процессов
    Процессная модель описывает окружение бизнес-процессов.
  • VACD – Value added chain diagram – Диаграмма цепочки добавленной стоимости
    Процессная модель – аналог классического стандарта DFD. Применяется для описания бизнес-процессов верхнего уровня.
  • PSM – Process selection matrix – Матрица выбора процесса
    Процессная модель– аналог классического стандарта DFD. Является альтернативой модели VACD и применяется для описания бизнес-процессов верхнего уровня.
  • eEPC – Extended Event driven Process Chain
    Расширенная цепочка процессов, управляемая событиями – Процессная модель аналог классического стандарта WFD. Применяется для описания бизнес-процессов нижнего уровня.
  • ORG – Organizational chart – Модель организационной структуры
    Модель описывает организационную структуру компании.
  • ASTD – Application system type diagram – Диаграмма типов информационных систем
    Модель описывает структуру информационных система, используемых в компании.

Основные характеристики:

  • Любая организация в методологии ARIS рассматривается с пяти точек зрения: организационной, функциональной, обрабатываемых данных, структуры бизнес-процессов, продуктов и услуг.
  • Каждая из этих точек зрения разделяется на три подуровня: описание требований, описание спецификации, описание внедрения.
  • Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту.
  • ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей.

Преимущества:

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

Недостатки:

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

Пример диаграммы:

Нотация Йордана – Де Марко (Yourdon / DeMarko)

Нотация Йордана – Де Марко – одна из нотаций, разработанная на основе развития классической методологии DFD. Названа по именам разработавших ее специалистов.

Данная нотация очень схожа со второй нотацией Гейна – Сарсона, однако принципиальное различие в графическом отображении форм объектов:

  •  
  • Функциональный блок изображается в виде окружности, внутри которой указывается название функции (операции) и (при необходимости) ее порядковый номер на диаграмме;
  • Потоки данных также изображаются в виде линий со стрел кой/стрелкам и на конце;
  • Внешняя сущность представляется в виде простого прямоугольника; нумерация сущностей не производится, в прямоугольнике указывается только ее название;
  • Хранилища данных изображаются так же, как и в нотации Гейна – Сарсона.

Для чего используется:

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

Преимущества:

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

Недостатки:

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

Пример диаграммы:

Подведем итог

Мы рассмотрели особенности применения еще 7 нотаций: отечественная нотация ДРАКОН, простые блок-схемы, диаграммы UML, разновидность сетей Петри, EPC, различные модели ARIS и одну из нотаций методологии DFD – нотацию Йордана - Де Марко.

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

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1494    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

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

11.12.2023    1701    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3973    0    ivanov660    10    

30

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1935    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2928    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9755    0    1c-izhtc    37    

22

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

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

22.05.2023    1433    0    Ingraf    0    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ccapt 05.05.21 09:41 Сейчас в теме
В этой статье нет ни одной нотации, предназначенной для описания именно бизнес-процессов. Такое настойчивое (как минимум, в трёх статьях) игнорирование, например, BPMN, похоже скорее на избегание. Даже интересно, почему.
depresnjak; +1 Ответить
3. Olenevod 33 16.05.21 20:20 Сейчас в теме
(1) А мне показалось, что это настолько популярная нотация, что даже было бы не интересно читать о ней короткий обзор. BPMN скорее нуждается в более подробных примерах и "расшифровках", кои можно найти и в других статьях инета (либо посвятить отдельную здесь, но зачем?). Очень интересно было ознакомиться с другими, за что автору большое спасибо.
Конечно бы хотелось чуть больше подробностей и примеров (см. коммент № (2) ), чтоб можно было понять где это можно попробовать и освоить и применять потом :)
4. ccapt 17.05.21 08:53 Сейчас в теме
(3), то есть о популярной и распространенной нотации в статье о нотациях упоминать не надо? при этом описывать те, которые нотациями описания бизнес-процессов даже не являются? и насколько адекватное представление о теме получит не знакомый с ней читатель?
2. VIA_1C 73 11.05.21 11:41 Сейчас в теме
Цикл статей очень познавательный. В последующих статьях хотелось бы увидеть пример реального построения в какой либо из нотаций небольшого бизнес-процесса на обследуемом предприятии и детальное описание шагов при построении диаграммы модели (на основе чего принято то или иное решение на каждом шаге, почему выбран тот или иной элемент модели и т.п.).
Hoper1981; Olenevod; ashtey; +3 Ответить
5. Dimka74 04.06.21 08:28 Сейчас в теме
Расскажите пожалуйста о программных средствах которыми пользуетесь при составлении таких схем.
6. ashtey 284 04.06.21 10:21 Сейчас в теме
(5) Добрый день!) Спасибо за комментарий. По инструментам (программным средствам) будет, я думаю, прямо отдельная публикация.
9. julia_green 18.09.21 15:52 Сейчас в теме
(6)Добрый день, подскажите пожалуйста, есть ли нотация к "Модель C4 для визуализации архитектуры программного обеспечения"?
10. ashtey 284 18.09.21 18:04 Сейчас в теме
(9)
, есть ли нотация

Добрый день, насколько я помню, С4 использует нотации языка UML.
11. julia_green 18.09.21 21:49 Сейчас в теме
(10) Благодарю, Анастасия
12. julia_green 22.09.21 12:55 Сейчас в теме
(10) Анастасия, добрый день, можете посоветовать источники по с4 на русском языке?
13. ashtey 284 22.09.21 23:17 Сейчас в теме
(12) Добрый вечер! У меня не было практики работы с с4, поэтому не могу дать вам никакой рекомендации.
14. DELOVOYDOM 24.02.24 16:55 Сейчас в теме
(10) Нужно было начинать с уровней функционирования предприятия. От хардверного, железа, грузовиков и тд, и далее до через структуры софта, бизнес-процессы до ценностей. Иначе получается все вперемешку и кто читает вообще не понимает что где как почему и зачем. Почти везде попытка внедрить процессный подход скатывается от управления абстракциями действий, событий и бизнес-условий до написание бизнес-моделей в коде. Зачем тогда нотации? давайте ТЗ писать программистам и они будут в процедурах писать цепочку работу с клиентом от заявки до отгрузки, как и делают большинство в 1С, 5 тыс заплатил кнопку добавили)
7. Steelvan 302 15.09.21 13:09 Сейчас в теме
Бесплатная рисовалка Набра с поддержкой bpmn и epc диаграмм.
Описание и сама программа: https://infostart.ru/public/1515487/
Пример рисования epc диаграммы: https://youtu.be/tDbCiPunktY
8. julia_green 18.09.21 15:51 Сейчас в теме
Добрый день, подскажите пожалуйста, есть ли нотация к "Модель C4 для визуализации архитектуры программного обеспечения"?
Оставьте свое сообщение