Workflow diagram что это
Урок по диаграммам потока работ
Каковы ваши потребности в диаграммах?
содержание
Здесь представлена вся основная информация о диаграммах потока работ — от истоков возникновения и примеров использования до символов нотации и наглядных уроков. Мы даже поделимся с вами секретами создания диаграмм потока работ на нашей платформе, где вы найдете все необходимые фигуры, иконки и функции, чтобы немедленно взяться за дело.
Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.
Что такое диаграмма потока работ?
Диаграмма потока работ дает наглядное представление о ходе выполнения работы. С помощью стандартных символов и фигур она показывает, как шаг за шагом разворачивается ваш рабочий процесс от начала до конца. На диаграмме также видно, кто отвечает за работу на каждом этапе процесса. Для создания диаграммы первым делом вам потребуется досконально проанализировать свой рабочий процесс и найти в нем возможные слабые места. Этот анализ также поможет вам выявить, определить и стандартизировать ключевые области своего рабочего процесса.
Благодаря схемам рабочих процессов, ваши сотрудники смогут лучше разобраться в своих обязанностях и составить представление о том, в каком порядке выполняется работа. Эти схемы также помогут вам повысить взаимопонимание между разными отделами. Схематизация рабочих процессов берет начало в области промышленного производства, однако сегодня этот подход применяется во многих сферах — от государственного управления до финансов и коммерции, — а создавать такие схемы стало как никогда просто.
Виды диаграмм DFD
Схематично представить рабочий процесс можно разными способами. Вот наиболее распространенные виды диаграмм потока работ:
Компоненты диаграммы потока работ
Каждый элемент схемы рабочего процесса иллюстрирует переход от одного шага к другому. Каждый шаг, в свою очередь, характеризуется одним из трех параметров:
Создание диаграмм быстро и легко с Lucidchart. Начните бесплатную пробную версию сегодня, чтобы начать создавать и сотрудничать.
Распространенные символы и фигуры диаграмм потока работ
Для изображения шагов и действий в схемах рабочих процессов применяются специальные фигуры и символы. Вот некоторые распространенные примеры:
 | Овал | Начальная или конечная точка процесса. |
 | Прямоугольник | Инструкции или действия. |
 | Ромб | Точка принятия решения, после которой схема разветвляется на два отдельных направления («да» и «нет»). |
| Круг | Соединитель, указывающий на переход от одной секции к другой (разделяются стрелками). | |
 | Стрелка | Указывает на следующий шаг. |
Как создать диаграмму потока работ
Построение эффективной диаграммы потока работ осуществляется в несколько шагов.
1. Прежде всего, выберите, с чьей точки зрения разворачивается схема, — организации или ее клиентов. Кроме того, как вы собираетесь изображать рабочий процесс — таким, как он есть в настоящий момент, или таким, как вы хотите видеть в будущем, то есть после внесения запланированных изменений?
2. Далее необходимо набросать приблизительную схему текущего рабочего процесса. Для этого достаточно в общих чертах изобразить сам процесс и вовлеченные в него шаги, то есть рабочие задачи и дела, которые регулярно имеют место в вашей организации.
3. Когда общая схема будет готова, можно браться за подробности. Теперь вам предстоит опросить людей, задействованных в выполнении каждого отдельного шага, и собрать набор требований.
На этом этапе рекомендуем задать своим сотрудникам следующие вопросы:
4. Собрав всю необходимую информацию, проведите анализ рабочего процесса, обращая особое внимание на три шага ниже, так как именно они помогут вам избавиться от участков низкой эффективности:
5. Пора приступать к построению схемы! Чтобы упростить себе задачу, зарегистрируйте бесплатную учетную запись в Lucidchart и воспользуйтесь одним из наших шаблонов. Затем добавьте необходимые фигуры и текстовые метки согласно вашему рабочему процессу.
Шаблоны и примеры диаграмм потока работ
Диаграмма потока работ по маркетингу
Этот шаблон поможет вам наглядно представить процесс создания маркетинговых материалов и выполнения связанных с ними рабочих задач от разработки стратегии до непосредственно исполнения.
Шаблон процесса введения сотрудника в должность
Эта схема поможет вашим новым сотрудникам быстрее вникнуть в устройство компании. Рабочий процесс, представленный таким образом, обеспечит взаимопонимание между отделом кадров, IT-командой и менеджерами при введении новичков в курс дела.
Более 5 миллионов пользователей из всевозможных сфер деятельности, включая технологии, консалтинг, образование, производство и здравоохранение, полагаются на Lucidchart для создания единой картины своего бизнеса. Если вы тоже стремитесь повысить эффективность своей компании, наша удобная платформа к вашим услугам!
Хотите создать собственную диаграмму? Попробуйте Lucidchart. Это быстро, легко и совершенно бесплатно.
Что такое DFD (диаграммы потоков данных)
В комментариях к одной из моих прошлых статей, посвященной IDEF0, один из пользователей высказал просьбу рассказать подробнее о том, что такое DFD. Понятие это несколько запутанное, многие мои клиенты также задают вопросы о потоках данных и стандартах построения диаграмм. А потому я решил эту статью посвятить DFD.
DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Википедия
По моему мнению, определение из русскоязычной Википедии, несколько перегружено информацией и, в результате, излишне сложно для понимания. Кроме того, лично я считаю, что DFD и UML — это разные инструменты, а потому некорректно утверждать, что DFD — это просто предшественник UML.
Для себя я вывел следующую формулировку:
DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.
Зачем нужна нотация DFD?
Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:
Сам я пользуюсь только одним из вариантов, по Гейну и Сарсону. Но когда я изучал материал перед написанием этой статьи, я увидел эту таблицу сравнения. Считаю, что она важна не столько для выбора варианта синтаксиса, он будет зависеть, скорее от выбора программного обеспечения для создания нотаций и ваших личных предпочтений, сколько как наглядная иллюстрация того факта, что в DFD нет жесткого синтаксиса, как, например, в BPMN. Здесь можно использовать разные варианты, главное, чтобы они были понятны вам и вашим клиентам. Нотации DFD — удобный инструмент для создания нерегламентированных диаграмм, которые можно сделать быстро и с максимумом свободы.
Применяется этот вид нотации в случае, когда требуется описание системы как хранилища данных. Т.е. нотация должна наглядно ответить на вопросы:
Как создавать нотации DFD
Давайте для примера рассмотрим нотацию автоматизации продаж. Допустим, у нас есть клиент, который делает заявку через сайт или по телефону. Есть менеджер, который регистрирует эту заявку. Таким образом, в системе появляются данные – клиент и его заказ. Работник склада должен это увидеть и произвести отгрузку товара с оформлением всех необходимых документов и передать документы клиенту.
Последовательность получается такая:
С точки зрения DFD у нас имеются:
И декомпозиция основного элемента нашей диаграммы:
Где используются DFD нотации
DFD-диаграммы активно применяются при разработке программного обеспечения. При этом:
Например, для выявления проблем документооборота, дублирования документов или, наоборот, недостающей документации или электронных данных в системе, очень удобно создать отдельно – описание бизнес-процесса, а потом к нему – DFD-нотацию. Либо наоборот, предварительно для понимания основ работы бизнеса и особенностей реализации документооборота создается DFD-нотация. Она помогает выявить, например, отсутствие в системе автоматизации важных документов, которые на самом деле создаются (на бумаге), но в системе никак не отображаются. А потом уже строится оптимизированный бизнес-процесс с учетом выявленных нюансов документооборота.
DFD нотации – это просто!
Я считаю, что DFD нотации – это действительно много проще, чем это кажется на первый взгляд. Главное, четко понимать ограничения построения этого типа диаграмм (отсутствие условий, времени и т.д.) и применять их там, где именно такой подход окажется удобнее. Возможно, вы найдете собственные варианты применения DFD, которые я выше не описал. В моем перечне присутствуют только те варианты, которые я использую на практике.
Что в DFD-нотациях особенно удобно, здесь не обязательно придерживаться строгих правил и синтаксиса, как, например, в BPMN. Эти нотации не будут исполнимыми, они нужны для понимания особенностей документооборота, структуры и последующей работы с данными. А потому, если ваша диаграмма понятна и вам, и заказчику, какие-то отступления от стандартов DFD вполне допустимы.
Рисовать диаграммы DFD можно, в принципе, где и как вам удобнее. Но если вы хотите работать с декомпозицией, выстраивать систему на разных уровнях детализации, то «рисовалки» (Visio, Paint и тому подобные) придется забыть. Вам потребуются специализированные программы для моделирования.
Лично я пользуюсь программой ERwin и всем ее рекомендую. Одна из причин моего выбора – это особенности декомпозиции. В ERwin, как и в некоторых других подобных системах, существует возможность декомпозирования DFD-процессов в формате IDEF3, т.е. основная диаграмма будет в формате DFD, и на самом общем уровне вы будете видеть основные потоки данных и «узлы» их обработки. А при декомпозиции вы сможете использовать уже процессный подход, что также бывает очень удобно для разработки крупных систем или работе с разными подразделениями бизнеса.
Вопросы и ответы
В чем разница между DFD и UML?
Существует язык создания нотаций UML, который также позиционирует себя как нотации, основанные на работе с данными. Но при этом UML — это уже язык программирования, здесь есть жесткий синтаксис, требования, но и возможностей для описания различных функций также много больше. DFD — это нотации, которые применяются более свободно, подходят, скорее, для планирования, изучения возможных вариантов решения, обсуждения с заказчиком и т.д.
Если вы — разработчик, и знаете UML, волне возможно, что даже какие-то предварительные решения вам будет удобнее создавать в этой нотации. А для бизнес-консультанта DFD всегда будет удобнее в качестве инструмента, так как бизнес-консультанту не требуется подробное описание функций с точки зрения автоматизации, это — задача технических специалистов. Зато время и силы DFD значительно экономит.
При этом не стоит рассматривать DFD как упрощенный вариант UML. Не смотря на схожесть в подходе, это — разные инструменты, предназначенные для разных целей.
Какое количество элементов может использоваться в DFD?
В отличие от систем с жестким синтаксисом и регламентом, в DFD нет ограничения по количеству элементов, которые могут находиться на одной диаграмме. Для сравнения: в IDEF0 количество таких элементов, дальше — только детализация (декомпозиция) или разные нотации.
С одной стороны, это большой плюс, так как отсутствие ограничений дает максимум свободы и комфорта при составлении нотации. С другой стороны, этой свободой злоупотреблять не рекомендуется. Помните, чем больше элементов у вас на диаграмме, тем сложнее ее читать.
Можно ли использовать нотации DFD для работы с клиентами?
В принципе, запретить это делать никто не может. Более того, в ограниченных количествах как иллюстрацию к каким-то вашим пояснениям такие нотации прекрасно подойдут и при обсуждении особенностей проекта с клиентом. Но все же, клиенты обычно слабо разбираются в вопросах автоматизации, структуре хранения данных, возможностях обработки и т.д. Это все находится в компетенции разработчиков. А нотации DFD строятся с учетом особенностей работы с данными, потому я все же рекомендую применять их преимущественно при обсуждении проекта специалистами, при создании технического описания и задания разработчикам, для повышения понимания именно разработчиками сути и особенностей проекта. Неподготовленному заказчику даже объяснить особенности DFD-нотаций может быть сложно.
Хорошие BPM — инструменты, которых нет и нет. Моделирование процессов
Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего …
Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном АРИС-ARIS и MS visio).
Задача
1. Подходы к визуализации диаграммы
1.1 Слои модели
Нарисовал нам наш архитектор (специалист по моделированию процессов) схему:
Рис. 1 Процесс оформления заявления
Смотрят пользователи (Работник, Начальник, бизнес и системные аналитики) на схему и понять не могут, что нарисовано то и как этот процесс работает. Соглашение о моделировании прочитали, обучающие ролики посмотрели, но все равно не понятно.
Далее отключаем слой «Документооборот» (docflow) и остается только последовательность действий (workflow, Process Flow), который говорит, что нужно провести всего две операции.
По мере появления ясности подключаем слои (кто исполнитель и какие документы на входе и выходе каждой функции \ операции). Когда схема большая (перегруженная) отключение слоев может творить «чудеса» в плане облегчения восприятия процесса. Иногда достаточно увидеть несколько представлений «одного и того же» (т.е. «те же самые, только в профиль») чтобы понять и нотацию и саму логику схемы, а если для этого достаточно нажать несколько кнопок (фильтров категорий), то путь к пониманию резко сокращается.
Пользоваться послойным построением схемы также удобно: вначале нарисовали основной слой workflow, потом наращиваем информативность процесса другими слоями.
Пример такой реализации возможен в MS Visio:
Рис. 2 Управление слоями в MS Visio
1.2 Плавательные дорожки
Применительно к Рис. 1 «Процесс оформления заявления»: отключили слой «документы», а оставшуюся часть (функции и ресурсы) представили в виде одной или двух Swimlane (опять же «по кнопке»).
Рис. 3 Swimlane по ролям в горизонтальной плоскости
Применительно к рассматриваемому случаю возможны следующие комбинации Swimlane:
две одинарные (горизонт, вертикаль) по ролям;
две одинарные (горизонт, вертикаль) по инструментам (часто в разрезе баз данных показывают);
«Дорожки» помимо того, что позволяют создать другое (альтернативное) представление процесса (смена представления иногда играет решающую роль в понимании процесса), обеспечивают сортировку по указанным категориям, что позволяет быстро и просто найти: где применяется такой-то инструмент и где «нужно поработать» такому то исполнителю (роли).
1.3 Объекты модели и их атрибуты, свойства
Как минимум необходимы атрибуты: название объекта, тип (функция, документ, роль и т.п.), связь с другими объектами. В принципе любой векторный графический редактор оперирует с объектами, но редкий имеет удобные инструменты работы с их атрибутами.
При просмотре схемы процесса должна быть возможность выделения объекта и просмотр атрибутов схемы и ее объектов (с наложением фильтров, т.к. иначе будет избыток).
1.4 Задание своей нотации (на примере новой ЕРС ver. 2)
Посмотрим на примере нотации ЕРС. Что же в ней улучшить? Все улучшения запишем в гипотетическую ЕРС2 нотацию.
Возможность задания своей нотации в инструменте моделирования означает подсказку (блокировку) при некорректном построении модели, как в момент отрисовки, так и через проверочный отчет построенной диаграммы. Например, в ЕРС2 предусматриваются следующие типы коннекторов: для входящих сущностей (входящие документы, материалы-заготовки), для выходящих (исходящие документы, продукты операции), соединитель потока (функции, события), соединитель ресурса. В объекте «функция» предусматриваются три «Connection Point» (visio):
слева в овале «функция» два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);
справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.
Вопрос: кроме как в visio, где можно задавать новые нотации и делать проверки на соответствие (валидность), аналогичные показанным выше?
Можно предусмотреть в таблице отдельное поле «полное описание функции» с подробным (большим, т.е. не влезающим в надпись) описанием операции, отображаемое на диаграмме в виде, например, всплывающей подсказки (или в отдельном окне) при активации конкретной функции (при наведении мышью).
Концептуально изложенный подход близок к выделенной в АРИС нотации «табличная ЕРС» (см. «Нотация ЕРС в виде таблицы»), но здесь реализация в виде обычной текстовой таблицы, т.е. ближе к ARIS Smart Designer. Причем логику процесса также можно указать в составе таблицы, например, как ссылка на предшествующий объект (этого нет Smart Designer, но не сложно добавить «что-то» для ЕРС2). Таблицу можно вставлять в текстовые регламенты word и макросом (VBA) генерить схему процесса («не отходя от кассы») с дублированием конечно в общем каталоге моделей.
Собирать схему из таблицы намного сложнее, чем наоборот, т.к. требуется сложный механизм пространственного разнесения объектов схемы (минимизация пересечений, задание направления потока и т.п.).
Применительно к graphviz: в случае, когда репозитарий объектов хранится в Excel, можно автоматически генерировать схемы, используя инструменты типа: Excel to Graphviz (sourceforge.net).
Пример простого VAD из dot:
Посмотреть схему можно, вставив код в окно «Online Graphviz Generator»:
Кстати, редкий Online Graphviz понимает несокращенный набор параметров спецификации.
В теме автоматического создания диаграмм из «текстового описания языком» нельзя не упомянуть про Object Process Diagram (OPD) \ Object Process Language (OPL). Тезисы у Object Process Methodology (OPM) вроде как BPM-ориентированные, но поверхностное знакомство с ним породило уверенность, что эта методология намного дальше от «workflow \ business process» (народа), чем те же plant uml \ dot (graphviz). OPCloud доступен тут: https://sandbox.opm.technion.ac.il/
2. Другое
2.1 Навигация по связанным моделям (каталог моделей)
При построении вложенных диаграмм (причем, возможно выполненных в разных нотациях, например, верхнеуровневые в VAD, IDEF0) необходимо иметь возможность перехода от одной к другой.
Обычно связанный набор моделей (и их объектов) называют репозитарий (репозитОрий). Часто в интерфейсе программы предусмотрено два окна: иерархическое дерево моделей (слева вверху) и окно диаграммы (основное). В идеале навигация по моделям должна быть трех видов:
по дереву моделей (treeview );
комбинированная, когда при переходе через кликабельные объекты схемы меняется фокус на общем дереве процессов.
2.2 Разные фишки и отчеты по атрибутике
Поиск по названиям моделей, атрибутам. Задание правил отбора, например, по диапазону значений последнего редактирования модели. Выгрузка данных фильтрации \ сортировки во внешний файл (отчет), причем разного формата (например, excel для анализа, pdf для презентабельности) и т.п.
2.3 Специфические отчеты
Отчеты могут быть разнообразны (зависит от воображения), но в первую очередь, нас будут интересовать выгрузки в распространенные формы. Универсальный генератор отчетов «на все случаи жизни» видимо проблема, но инструменты создания отчетов должны быть изначально в среде моделирования.
Для примера рассмотрим матрицу ответственности\ участия RACI. Требуется автоматическая генерация усеченной RACI-матрицы (здесь показано только для участников процесса, но часто плюс владельцы процесса) по имеющейся, например, VAD-диаграмме (value added chain diagram). Набор ключевых «мега процессов» компании показан в виде VAD и нужно по ним построить (синхронизировать) матрицу участников (RACI по одной только роли «участник процесса»).
Рис. 4 Построение RACI матрицы
Алгоритм построения таблицы на VBA Visio\Excel может быть следующий:
Создаем в таблице Excel новую строку и в поле «Ключевые процессы» подставляем значение с активного листа visio из объекта типа «название мега процесса».
Далее циклом пробегаем по всем VAD-элементам схемы (листа) и через связь (объект «соединитель» для связки с объектами «исполнитель») находим связанные объекты типа «исполнитель» (участник подпроцесса).
Находим соответствующее название подразделения в шапке таблицы и на пересечении с процессом ставим символ участия (признак).
Переход к следующему листу visio.
Когда в организации десятки подразделений и около сотни «мега процессов» (их выделение достаточно субъективно), то задача синхронизации схем мега-процессов и матрицы участия подразделений в таких ключевых процессах становится достаточно трудоемкой.
2.4 Упаковка необъятной схемы процесса в печатный лист
Когда рисуют гигантскую «портянку» из «тучи элементов» на одной схеме, а потом нужно ее распечатать (А4, А3) или представить в ином интерфейсе (без скролинга такой «портянки»), то возникает ступор. Должна быть поддержка многостраничной схемы и элементов перехода между страницами (в том числе, кликабельными).
2.5 Разное
Публикация процессов, совместная работа, интеграция с корпоративной базой нормативных документов и т.п.
Авто-размещение объектов на схеме: набросал невпопад объекты на лист (главное правильно связи указать и никого не забыть) и нажал кнопку: «расположить как надо» и система сама оптимально и красиво разместила объекты на схеме (в visio функции выравнивания и распределения фигур).
Открытые стандарты хранения и экспорта \ импорта (внешний графический импорт \ экспорт как минимум в visio), как самих графических объектов модели, так и их атрибутов. К сожалению, тот же MS visio так и не научился нормально экспортировать схемы в pdf и svg (например, всплывающие подсказки).
Изменение дизайна графического примитива для любого объекта нотации, расширение нотации, передача новых шаблонов в другую аналогичную систему, добавление новых атрибутов объектов (новых полей) и многое другое.
Заключение
В 2000-ном году мной использовались ровно такие же подходы и ровно те же инструменты моделирования (основные: ARIS toolset, MS visio), что и сейчас, но тогда была настолько интенсивная «движуха в мире ВРМ», что казалось «вот-вот и прогресс всё поменяет», но это оказалось иллюзией. «Старику ARIS» (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово «cloud»), но похоже перемены придут еще совсем не скоро и светлое будущее «обычного» BPM откладывается …