Ссылка на файл: >>>>>> http://file-portal.ru/Схема описания процесса/
Соглашения о правилах размещения фигур на схеме
Основные объекты блок-схемы описания бизнес- процесса. Преимущества использования блок-схем для описания бизнес-процессов
Описание бизнес-процессов: стремление к простоте
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Всякая вещь есть форма проявления беспредельного разнообразия. Козьма Прутков Введение в нотацию eEPC В настоящее время существует множество различных принципов графического представления бизнес-процессов, именуемых нотациями. Этот вопрос уже десятки лет задает себе каждый, кто сталкивается с необходимостью описать бизнес-процессы. Давайте разберемся с причинами. Их три на мой взгляд: Не все нотации одинаково удобны для решения различных задач. Например, нотация может быть удобна для бизнес-процесса верхнего уровня и совсем не удобной для описания рабочего процесса. Разные разработчики таких нотаций. В разное время разные разработчики пытались придумать новые принципы описания схем. Делали они это из благих побуждений, когда на практике сталкивались с ситуацией, когда используемая ими нотация не может отразить необходимых тонкостей либо не наглядно. Иногда в процессе эволюции такие нотации стали как бы параллельными, то есть выглядят по разному, а задачи решают одинаковые. Это когда по непонятным причинам вдруг появляется новая нотация, не имеющая в себе ничего выдающегося, но, почему-то продвигающаяся ее создателем как совершеннейшее ноу-хау. Такое происходит до сих пор. Целью данной статьи является не рассмотрение всевозможных нотаций я сознательно не называю их названий , а остановиться на подробном описании той нотации, которую выбрал я для своих проектов в процессе длительного поиска наиболее оптимального варианта. Пора начать наше повествование об очень интересной, простой и практичной нотации eEPC в переводе: В ее дословном переводе раскрывается и основное предназначение: Какие преимущества имеет нотация eEPC: Во-первых, это не совсем нотация в чистом виде. Кроме этого Вы может добавить свой элемент, включить правила его использования в собственный корпоративный стандарт чтобы исключить самодеятельность, которая может запутать схему и усложнить ее читаемость и все! Это очень важный момент. Кроме этого, в своем корпоративном стандарте можно задать и любые другие ограничения и правила eEPC содержит элементы логики. На обучение правилам потребуется около 2-х часов при наличии желания обучаемого. Конечно, как и все в этом мире, она имеет и недостатки. Но рациональное использование сводит их к минимуму. Главный недостаток, на мой взгляд, это тот факт, что если использовать простые инструменты то есть программы для рисования схем, а не для моделирования бизнес-процессов , то мы не имеем единой базы данных объектов. Кроме этого, сложно проконтролировать, входы-выходы надо их именно контролировать, то есть придумать способ такого контроля, если требуется. Но, с другой стороны, использование инструментов моделирования сложных бизнес-процессов стоит весьма внушительных сумм, а проект с их использованием измеряется в миллионах. А так мы имеем очень экономичный и понятный инструмент. Если говорить точнее, этот недостаток относится именно к рассматриваемому мной способу описания, то есть с использованием MS Visio или аналогичного ПО. Если Вы будее использовать специализированные системы описания бизнес-процессов, поддерживающие базы данных объектов, то этого недостатка можно избежать. Это очень важный момент, на котором и строится весь принцип построения схемы. Итак, есть два ключевых понятие: Когда кто-то первый раз попытаетесь нарисовать свой процесс в виде диаграммы eEPC, то часто возникает вопрос, а чем отличается событие от функции? Это надо четко себе уяснить, иначе получится непредсказуемый результат. Причем событие всегда вызывает необходимость исполнения функции, и исполнение функции всегда заканчивается событием Поясню на примере. Менеджер взял трубку для телефонного разговора. Телефонный разговор — это функция. Разговор завершен повесил трубку —снова событие. Таким образом, наблюдается событийная цепочка: Звонок — разговор — завершение звонка. А завершении звонка наверняка потребует выполнение новой функции: Давайте попробуем это нарисовать. Вот такие два простых элемента составляют основу правил описания бизнес процессов в нотации eEPC. Думаю, надо сказать пару слов об используемых цветах. Если Вы сталкивались с описание процессов в других нотациях, как правило они были черно-белые. И это правильно, явной зависимости содержания от цвета быть не должно, так как схема может быть нарисована карандашом на бумаге, распечатана на черно-белом принтере и пр. В данном случае в нтации eEPC так исторически сложилось, что элементы имеют определенные цвета. Не сказать, чтобы это было обязательно, но привычка вырабатывается, да и восприятие в электронном виде лучше — сразу видно что есть что. Эти цвета можно рассматривать как рекомендацию. В общем, рекомендую использовать цвета. Главное, чтобы сама форма элементов не была одинаковой то есть отличаться лишь цветом , так как в черно-белом варианте это может вызвать путаницу. Итак, есть событие, есть функция. Мы видим, что событие1 привело к необходимости выполнять некую функцию, которая завершилась событием2. Если применительно к примеру с телефонным звонком, то будет так: Связку событие — функция — событие принято отображать сверху вниз в одну линию либо слева направо. Направление цепочки указывается связывающими линиями со стрелками. Для того, чтобы схема была более наглядной, нотация предусматривает еще несколько стандартных элементов: Тот, кто выполняет данную функцию Информация. Любая информация, используемая для выполнения функции, кроме документальной. Например, телефонный звонок, инструкция по выполнению операции т. Программное обеспечение, используемое для выполнения функции. Все остальные элементы являются вспомогательными, и практически не регламентированы требованиями самой eEPC. Однако, нет никаких препятствий для того, чтобы добавить свои собственные элементы. Главное, зафиксировать это во внутреннем стандарте, чтобы было единое понимание, как они выглядят и зачем применяются. Такое расширение не нарушает требований, если не нарушается связка событие-функция-событие, и предназначено лишь для улучшения восприятия информации или адаптации правил описания в какой-либо отраслевой специфике. Я добавил свой набор элементов, о которых расскажу ниже. Еще требуется выяснить, как рассмотренные элементы должны располагаться. Все эти элементы так или иначе должны быть связаны с функцией. Что касается стрелок и их направлений: Если информация входит поступает на вход , то направление стрелки от объекта к функции, если выходит, то наоборот. Еще пару слов о месте нахождения этих элементов на схеме и можно перерисовать нашу схему, уточнив выполнение функции обработки звонка. Жестких требований по расположению элементов нет, но принято их отображать на всех схемах одинаково для однообразия и стройности схемы. Для унификации вешнего вида графических схем бизнес-процессов такие правила надо закрепить во внутреннем стандарте и следовать им. Чуть позже и приведу некоторые рекомендации по этому поводу. Теперь перерисуем нашу схему: Ни входящих, ни исходящих документов при этом не используется. Как я уже упоминал, одной из сильных сторон нотации являются элементы логики. Одновременно это и один из самых сложных для понимания моментов. Поэтому, сначала я приведу пример, а потом мы отдельно будем разбираться с элементами логики. Пусть в нашем примере будет так: Если заинтересованности нет, то обработка звонка завершена. В реальной жизни хорошо бы использовать и правила завершения звонка, но это я так, к слову, пока это упростим. Элементы логики в схемах нотации eEPC Элементы логики просты, но есть свои особенности и правила, чтобы схема была логичной и однозначно истолкована. Потому, что в этом случае это противоречит самому понятию события — оно простое и мгновенное, без времени выполнения. Например, если зазвонил телефон, и человек сидит думает, брать ему трубку или не брать, теоретически это уже будет функцией, где он принимает решение. А практически, в том числе из здравого смысла, он нарушает правила обработки звонков, так как ему зарплату платят за то, чтобы он эти звонки обрабатывал, и нечего тут рассуждать в целом как нарисовано на схеме. Всего различается 3 элемента логики: Когда произойдут два или более события одновременно; ИЛИ. Либо одно, либо другое. Вот как одни выглядят: Как видите, существует два варианта графического представления элементов логики. Они ничем не отличаются, совершенно альтернативные. Я привел их оба, так как на практике в различных источниках можно увидеть оба варианта. Какой из них использовать, решать Вам. Мне больше нравится первый. Теперь необходимо разобраться с применением элементов логики. Сначала рассмотрим встречающиеся варианты, затем перейдем к примеру. Разберем каждый элемент в отдельности. Когда для выполнения функции требуется одновременное выполнение нескольких событий: Если закрыт отчетный период событие 1 и наступил срок подачи отчета руководителю событие 2 , сотрудник готовит ежемесячный отчет. Соединение элементов, если при выполнении функции, возникает несколько событий: Завершена некоторая работа с заказчиком. Одновременно зафиксировано два события: На практике такое применение встречается не часто. Как правило, если в одной функции объединено много действий. Соединение элементов, если при выполнении нескольких функций, возникает событие: Кладовщик собрал заказ функция 1 , оператор выписал документы функция 2 , товар готов к отгрузке событие. Соединение элементов, если возникновение одного события приводит к выполнению нескольких функций: Поступила партия товара событие. Одновременно начинается отгрузка ранее заказанного клиентами товара и размещение оставшегося на складе. Соединение элементов, если одно из событий может вызвать выполнение функции: Поступила заявка по телефону событие 1 или поступление заявки по электронной почте событие 2 приведет к необходимости ее обрабатывать. Соединение элементов, если одна функция может вызвать как минимум одно событие: Подготовлен и отправлен товар счет для отправки клиенту. Счет мог быть отправлен по почте событие 1 , по факсу событие 2. Соединение элементов, когда выполнение нескольких функций вызовет событие: Оказана услуга функция 1 или продан товар функция 2 , возникла задолженность у клиента событие 1. Соединение элементов, когда для выполнения функции необходимо одно и только одно из событий: Клиент приехал в магазин лично событие 1 или совершил заказ через интернет событие 2. Необходимо выполнить отгрузку товара функция 1. Соединение элементов, если в результате выполнения функции происходит максимум одно из событий: Решение либо принято либо нет. Соединение элементов, если с обытие произойдет после того, как будет выполнена одна и только одна из функций. Доставка товара осуществлена событие 1 либо собственным транспортом Функция 1 , либо транспортной компанией функция 2 Корректное применение элементов логики требует определенной практики. Но это не сложно. Надо отметить, что не все рассмотренные комбинации широко применяются на практике а вообще это определяется образом мышления аналитика. Попробуйте применить элементы логики на практике. Если будут трудности, напишите мне, постараюсь помочь. Расширение нотации собственными элементами Как я уже говорил, eEPC является не совсем нотацией, а именно правилами описания. И эти правила не запрещают добавлять собственные элементы на схему. Главное, чтобы эти элементы были понятными, и существовал документ, где такие расширения элеметов зафиксированы. Например, я использую следующие дополнительные элементы, которые возникали постепенно в процессе описания реальных процессов для различных задач, от простого описания для постановки задач для автоматизации. Используется, если в результате выполнения операции создается файл данных, или файл используется для выполнения операции. Используется при описании информационных потоков между автоматизированными системами. Используется для отображения бумажной картотеки или архива. Используется для обозначения входящих и исходящих материальных потоков, а также ресурсов, потребляемых при выполнении процесса. Материальный поток отображается слева от сопровождающих его документов. Используется для обозначения структурированной информации представление сущности. На диаграмме может применяться для обозначения документов, сформированных программным образом при использовании пользовательских приложений. Соглашения о правилах размещения фигур на схеме Сама по себе нотация eEPC не предъявляет жестких требованиях в расположении элементов друг относительно друга, хотя принято рисовать схему сверху вниз или слева направо. Что бы этого избежать, рекомендуется выработать и утвердить свои правила расположения элементов. Я придерживаюсь и рекомендую следующих правил: Идентификация элементов на диаграмме Как известно, грамотный подход к описанию бизнес-процессов предусматривает их идентификацию, то есть когда каждый процесс имеет свое кодовое название. Соответственно, отдельные функции внутри процесса также имеют свои названия и идентификаторы. Документ идентифицируется посредством указания в левом верхнем углу кода отчета или документа в соответствии с реестром. Документы, полученные от поставщиков товаров и услуг входящие , идентифицируются только по наименованию. Функция идентифицируется указанием порядкового номера функции для данной группы процессов. Вопросы выявления групп процессов выходят за рамки данной статьи, мы рассмотрим их отдельно. Причем, научиться выявлять процессы следует до того, как Вы начнете их описывать, иначе может возникнуть стремление описать всю деятельность компании на одной диаграмме, как иногда пытаются сделать. Поэтому, сейчас я лишь покажу на примере, как это может быть представлено на схеме. Вернемся к примеру с обработкой звонка. Тогда схема примет следующий вид идентификация выделена красным для наглядности. Код документа при этом указывает на порядковые номер документа в общем реестре документов мы это тоже будем рассматривать отдельно, когда доберемся до обследования системы документооборота. Отображение обратной связи При построении моделей часто возникает необходимость цикличного выполнения процесса по некоторому условию или необходимость отобразить деятельность лиц, принимающих решения. В этом случае речь идет об обратной связи. Текстовое описание процессов Как бы мы не старались отобразить бизнес-процесс на схеме, добиться полной детализации не получится, иначе можно погрязнуть в бесконечных цепочках элементов и условий. Чтобы этого избежать, а также добавить к описанию процесса информацию, которую нельзя отобразить графически, описание дополняют текстовым сопровождением. Для этого разрабатывают различные текстовые шаблоны, которые заполняют в процессе описания. Формы таких шаблонно могут быть разными, включать в себя отдельные разделы с описанием входов и выходов, потребляемых ресурсов, используемом программном обеспечении и пр. В простейшем случае шаблон описания бизнес-процесса может выглядеть так: Обработка входящего контакта Наименование Описание Номер на схеме Обработка входящего звонка При поступлении входящего звонка оператор обрабатывает звонок в соответствии с правилам обработки входящих звонков. Выявляет интерес клиента, предоставляет информацию об услугах Менеджер по продажам готовит коммерческое предложение и отправляет клиенту по электронной почте Данные вопросы мы обязательно будем изучать в дальнейших выпусках. Управление проектами авторов , 2,2k публикаций. Развитие стартапа автора , публикация. Патентование 48 авторов , публикаций. Управление персоналом авторов , публикации. Управление разработкой автора , публикации. Законодательство и IT-бизнес авторов , 1,1k публикаций. Управление e-commerce 99 авторов , публикаций. Бизнес-модели автора , публикаций. Agile авторов , публикации. Управление продуктом авторов , публикаций. Необходимость регулирования интернета вещей 4,3k Добавить в закладки Чавалах Александр chavalah карма. В предложенной нотации отсутствует такой важный элемент, как подпроцессы. Без группировки элементов любая схема быстро становится нечитаемой. Которую можно рассматривать как единое целое, а можно разложить на более мелкие составляющие на отдельном или на том же листе. Я для себя выбрал BPMN 2. Метки лучше разделять запятой. Сейчас Вчера Неделя K-sort: Сортировка пузырьком в коде Qualcomm 19,7k Вы ни черта не понимаете в цветах 28,8k Интересные публикации Хабрахабр Geektimes. Что читать о нейросетях. Жизнь разработчика на Кипре. Не совсем умный, но очень безопасный дом от Xiaomi GT. Частичное восстановление информации после Petya ExPetr GT. Отчет с Science Slam Digital 7 июля. MVC на чистом JavaScript. Британские спутниковые снимки 2: Разбираемся в физике частиц: Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары. При поступлении входящего звонка оператор обрабатывает звонок в соответствии с правилам обработки входящих звонков. Выявляет интерес клиента, предоставляет информацию об услугах. При наличии интереса клиента, оператор передает контакт менеджеру по продажам. Менеджер по продажам готовит коммерческое предложение и отправляет клиенту по электронной почте.
Женщине делают операцию
Во сколько раз сила притяжения земли
Пастернак стихи о театре
Бизнес-процессы: примеры и описание
Экономические новости в израиле
Свойства судебной власти рф
Маці божая ружанцовая
Схема бизнес процесса для нетерпеливых
Как считаются отпускные учителям
Ошибка 0x000000f4что делать
Как описать процесс.
Кандид b6 инструкция по применению
Асус зенфон 2 лазер ze550 характеристики
Расписание электричек бронницы новая на завтра
Описание процессов при помощи Work Flow
Когда делать тест при эко