Бизнес-процессы, описание бизнес-процессов, разработка бизнес-процессов

Сложно структурировать и анализировать — процесс может иметь множество путей развития. Это значит, что в зависимости от результатов, событий и условий, мы выполняем разные действия в процессе. А теперь представьте, каково это описывать текстом.

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

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

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

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

Нет целостности восприятия — большое количество данных не способствует этому. Хотя если необходимо просмотреть данные одной операции подпроцесса в строке или данные одного типа в столбце — то лучше таблицы не придумать. Сложно отобразить ветвления — та же проблема, что и с текстом. Большое количество ветвлений, и , что важно, развитие процесса исходя из условий ветвления, довольно сложно отобразить наглядно. Требует подготовки — нужно потратить время на подготовку хорошего шаблона. Описание в виде схемы, модели бизнес процесса Не буду тянуть кота за март.

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

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

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

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

Оказалось, что графика хороша тем, что графическая информация, расположенная в поле зрения человека, воспринимается его мозгом одновременно.

Второе преимущество в том, что менеджер, как и любой человек, имеет правополушарное мышление и мыслит в виде образов. Любую текстовую информацию он переводит в образы.

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

Ею пользуются также некоторые крупные корпорации в США. Функции 1DEF могут детализироваться в отдельных схемах, это называется декомпозиция. На самом верхнем уровне это может быть все предприятие, отраженное как один блок, а далее - в отдельной схеме - будут раскрыты различные процессы.

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

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

Диаграмма развертывания - показывает организацию обрабатывающих узлов системы и размещение в них компонентов. Для описания бизнес-процессов применяются Диаграммы деятельности. Событийно-функциональные диаграммы сокращенно еЕРС - extended event-process chain ,.

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

Описание бизнес процессов - типы описания

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

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

Характеристики первичных и вторичных входов и выходов бизнес-процесс. Первичный вход - это вход, который инициирует начало бизнес-процесса. В примере с бизнес-процессов "Комиссионирование" заявка на набор заказа является первичным входом.

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

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

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

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

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

Кажущаяся на первый взгляд сложность описания бизнес-процессов является раздутой. Классическая технология описания бизнес-процессов, которая была разработана на заре рождения процессных технологий управления, достаточно проста и состоит всего лишь из двух стандартов описания бизнес-процессов - DFD и WFD.

Большинство других современных стандартов, не смотря на другие названия представляют небольшие разновидности и дополнения двух классических подходов DFD и WFD. Согласно классическому подходу стандарт DFD, который расшифровывается как Data Flow Diagram представляет из себя диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня.

У диаграммы потоков работ имеются и другое название - диаграмма алгоритмов. Давайте рассмотрим два этих стандарта, составляющих классическую методологию описания бизнес-процессов. Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня. На диаграмме потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ.

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

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

В большинстве случаев временная последовательность работ совпадает с направлением движения потоков в бизнес-процессе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IDEF Integration Definition for Function Modeling - методология функционального моделирования - семейство совместно используемых методов для процесса моделирования.

Первоначально разработаны в военных ведомствах США. На сегодня эта техника описания бизнес-процессов получила наибольшее распространение в мире и принята как стандарт во многих странах. В России па момент написания Методики это зафиксировано в Р Методология функционального моделирования", а также в проекте стандарта: Представление данных об изделии и обмен данными.

Протокол применения - Проектирование изделия управляемой конфигурации". UML Unified Modeling Language - унифицированный язык моделирования -наиболее систематизированный подход к описанию любых систем, в т. UML принят как стандарт для проектирования информационных систем более чем ю ведущими разработчиками программного обеспечения, в т. ARIS ARchitecture of Integrated Information Systems - проектирование интегрированных информационных систем - германская технология описания предприятий.

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

IDEF технология используется, начиная с конца х годов. Ею пользуются также некоторые крупные корпорации в США. Функции 1DEF могут детализироваться в отдельных схемах, это называется декомпозиция. На самом верхнем уровне это может быть все предприятие, отраженное как один блок, а далее - в отдельной схеме - будут раскрыты различные процессы. UML - объектно-ориентированный язык моделирования для описания сложных систем. Также весьма распространен, существуют многочисленные инструменты для проектирования систем на данном языке, например: Диаграмма вариантов использования - показывает статический вид системы с точки зрения конечного пользователя.

Основные понятия, используемые при графическом описании процедур Критерием разделения бизнес-процесса на части служит возможность  ‎Общие положения · ‎Действие · ‎Входной/выходной поток · ‎Поток управления. 18 дек. г. - Только после создания графической нотации можно говорить о том, Чаще всего над созданием описания бизнес процесса работает. 9 апр. г. - Описание бизнес процессов можно делать разными способами. Можно выделить 3 типа описания - текстовый, табличный и графический. Все, что происходит в бизнес процессе описывается словами, т.е. в.

Найдено :

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