Дорожка для плавания
 | Эта статья нуждается в дополнительных цитатах для проверки . ( февраль 2024 г. ) |
Дорожка или (например, диаграмма дорожек ) используется в блок-схемах процессов блок-схемах, которые визуально разграничивают распределение задач и ответственность за подпроцессы бизнес -процесса . Дорожки для плавания могут располагаться как горизонтально, так и вертикально.
Атрибуты
[ редактировать ]Блок-схема «дорожки» отличается от других блок-схем тем, что процессы и решения группируются визуально путем размещения их в дорожках . Параллельные линии делят диаграмму на полосы, по одной полосе для каждого человека, группы или подпроцесса. Дорожки помечены, чтобы показать, как организована диаграмма.
В прилагаемом примере вертикальное направление представляет последовательность событий в общем процессе, а горизонтальное деление показывает, какой подпроцесс выполняет этот шаг. Стрелки между полосами показывают, как информация или материал передаются между подпроцессами.
Альтернативно, поток можно повернуть так, чтобы последовательность читалась горизонтально слева направо, при этом задействованные роли отображались у левого края. Это может быть легче читать и проектировать, поскольку экраны компьютеров обычно шире, чем высота, что дает лучший обзор потока.
Использование стандартных символов позволяет показать четкую связь между связанными блок-схемами при отображении потоков со сложными отношениями.
Использование
[ редактировать ]При использовании для диаграммы бизнес-процесса, в котором участвует более одного отдела, дорожки часто служат для пояснения не только этапов и того, кто несет ответственность за каждый из них, но также того, как наиболее вероятны задержки, ошибки или мошенничество.
Многие методологии моделирования процессов используют концепцию «дорожек» как механизм для организации действий в отдельные визуальные категории, чтобы проиллюстрировать различные функциональные возможности или обязанности (организационные роли ). Дорожки для плавания используются в в нотации моделирования бизнес-процессов (BPMN) и унифицированном языке моделирования (UML) методологиях моделирования диаграмм деятельности .
Источник
[ редактировать ]Диаграммы «дорожки для плавания» впервые появились в 1940-х годах как разновидность блок-схемы процесса, называемой многоколоночной диаграммой. [1] (1990) назвали их «диаграммами плавательных дорожек» Гири Раммлер и Алан Брейч в своей книге «Улучшение производительности» . Впервые с компьютерным построением диаграмм их познакомил iGrafx. Дорожки для плавания также известны как «диаграммы Раммлера-Браша». Другое возможное происхождение термина «дорожка для плавания» - это часть графического дизайнера процессов JBoss jBPM jPDL (язык определения процесса), являющегося частью структуры JBoss jBPM для языков процессов. [2]
Презентация Swimlane была разработана в начале 1980-х годов профессором, доктором технических наук. Биннера в рамках своей докторской диссертации о требованиях концепции информационных технологий и CIM в Институте фабричного оборудования профессора Виндала в TU-Har.
Была разработана модель процесса, в которой ролевой анализ и моделирование процесса были отправной точкой для ИТ-решения на базе ИТ или, в данном случае, решения CIM, с помощью которого была возможна разработка концепции IT-CIM.
Альтернативные условия
[ редактировать ]Дорожка для плавания была впервые представлена в компьютерном моделировании процессов компанией IGrafx в 1993 году и зарегистрирована как торговая марка в 1996 году. Ее также можно называть функциональной полосой (как в Microsoft Visio 2007) и она используется таким же образом для создания дорожки для плавания. кросс-функциональная блок-схема для отображения процесса внутри функциональных подразделений бизнеса. [3] Термин «функциональная полоса» появился после использования «дорожки для плавания» и, по-видимому, становится менее приемлемым термином, поскольку BPMN получил более широкое признание в качестве стандарта моделирования.
Другой используемый термин — «функциональная блок-схема», полезный для проектов по повышению производительности и проектированию систем. После установки рабочего процесса и системных интерфейсов «как есть», рабочие этапы упрощаются для автоматизации процессов, когда это возможно, и переноса этапов в последующие рабочие процессы. Затем создается модель «как должно быть» для человеческих процессов и проектный документ по соответствующим системам, разрабатываемый для тех, которые автоматизированы. Обычно прирост производительности составляет более 30 % даже для процессов, которые остаются ручными.