Описание, стандартизация и регламентация бизнес процессов. В чем разница?

Регламентация бизнес процессов и их стандартизация, это одно и то же, или нет? Чем отличается регламент от стандарта? А что такое описание бизнес процессов? Что является результатом описания: регламент, стандарт или иной документ? Ответы на эти, и другие вопросы, вы найдет в данной статье.

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

Мы редко встречаем специалистов, которые разбираются в терминологии управления бизнес процессами. В этом нет ничего удивительного – понятие управления бизнес процессами не так давно стало широко распространяться в России. Но у путаницы в терминологии есть существенное последствие – разность понимания. А разность понимания приводит к разным результатам. Разность приводит к диалогам наподобие:

• Вот регламент процесса.
• Но это просто описание, а я просил сделать регламент.
• Но это же и есть регламент. Вот смотрите, все черным по белому написано.
• То, что написано, я вижу. Но где схемы процессов? Где таблицы с данными?
• Но я считал, что так должен выглядеть регламент…

Неприятная ситуация, с неприятными результатами. Именно поэтому так важно договориться о терминологии. Что мы и сделаем. Начнем с самого простого понятия – описание бизнес процессов.

Описание бизнес процессов

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

Вроде бы все понятно, но все же стоит отметить:

1. Процесс описания, это выражение процесса в реальной жизни, в таком виде, чтобы его можно было многократно прочитать или посмотреть и понять, как выполняется процесс, без его, процесса, наблюдения.
2. Описание процесса еще можно назвать формализацией. Это означает ровно то, что написано выше – перенос знаний о процессе в информацию, которой можно пользоваться.
3. Процессы существуют вне зависимости от того, описаны они или нет. Формализованный процесс, это описанный процесс.
4. Описание процесса, это еще и документ. В котором описано все, что нужно знать о процессе, чтобы его можно было понять. А может быть, такое подробное описание, чтобы процесс можно было по нему выполнить. Своеобразная инструкция, или комплект инструкций, процесса.
5. Описание процесса может быть выполнено в виде текста, таблиц, диаграмм и их совокупности.
6. Модель процесса – тоже его описание. И да, с помощью правильного ПО и методологии, модель может быть настолько хороша, что не потребует никакого другого описания.

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

Стандартизация бизнес процессов

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

Именно поэтому, говоря о стандартизации, многие авторы говорят о том, что стандартизация, это, в том числе, процесс приведения в соответствие стандарта (описания) и реального выполнения процессов в жизни.

Но прошу вас обратить внимание – стоит все же отделять «мухи от котлет». Стандартизация – процесс создания стандарта процесса. А вот синхронизация стандарта и реальной жизни, это вопрос Управления разрывами. Почему необходимо разделять эти понятия? А вот почему:

1. Процесс разработки стандарта достаточно обширен. Он имеет явно выраженные входы и продукты, а также события начала и окончания. Продукт процесса имеет ценность сам по себе. Имеется ввиду, что стандарт, это законченный продукт. Который может использоваться далее, а может и нет. Проще говоря – процесс стандартизации имеет четкие границы, которые говорят о нем, как о законченном и самостоятельном процессе.
2. Управление разрывами, это процесс, который на входе использует продукты двух процессов: Описание бизнес процессов и Стандартизация бизнес процессов. Собственно, Управление разрывами направлено на… Устранение разрывов между тем, как есть и тем, как мы хотим, чтобы было. Т.е. Это тоже самостоятельный процесс, с четкими границами.

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

Понятное дело, что очень часто нормирование используется в качестве кнута – не вложился в норму, вот тебе орех. Точнее по ореху. Это крайне неправильно. Норма, в бизнес процессах, нужна для того, чтобы можно было выявлять отклонения, анализировать их и улучшать процесс. Если норма указана не верно, это не означает, что ее нельзя изменить. Более того, она должна меняться. В определенной степени и условиях. Поэтому – нормирование, это процесс выявления нормальных значений. Которые, тем не менее, всегда будут иметь отклонения. Нормальным, мы считаем значение, которое будет принимать параметр процесса чаще всего. И да, нормирование должно основываться и на расчетах (теории), и на практически полученных измерениях. Нормирование только на основании расчетов не учитывает реальность. Нормирование только на основании реальности, не включает в себя возможность развития.

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

Но давайте разберемся, а что, собственно, подлежит стандартизации, с точки зрения процесса? Итак, что должен включать в себя хороший стандарт:

1. Состав подпроцессов и операций процесса. Т.е. Стандартом является ответ на вопрос – что должно быть обязательно сделано? И это уже не мало.
2. Порядок выполнения подпроцессов и операций процесса. Чтобы процесс получал на выходе определенный продукт, должна быть определенная последовательность действий. Именно об этом говорят, имея ввиду описание технологии – описание состава и последовательности действий, которая описывается в стандарте. Ответ на вопрос – в каком порядке нужно выполнять действия?
3. Распределение подпроцессов и операций по исполнителям. Все просто – в стандарте указывается кто должен выполнять действия в процессе.
4. Состав ресурсов. Ресурсы – все, что необходимо, для выполнения процесса. Люди, инструменты, материалы, сырье, программное обеспечение и так далее. В стандарте должен быть описан не только состав, но и качество, свойства, ресурсов.
5. Нормативные значения использования ресурсов. Вот это уже про нормирование. В стандарте описывается сколько и каких ресурсов, необходимо для выполнения каждой операции.
6. Нормативные значения операций. Это тоже вопрос нормирования. В стандарте указывается сколько времени должны выполняться операции или процесс. Зачем? Затем, что это может иметь ключевое значение для результата процесса. Например, если не соблюсти нормативные значения времени при приготовлении блюда, то результат может выйти так себе.
7. Стандарты документов. Стандарт может содержать в себе формы документов, которые должны использоваться в процессе. Ну тут, думаю, все понятно.

Очень часто можно услышать возражение – не все процессы можно стандартизировать. Как можно стандартизировать процесс, например, разработки креативной идеи? Очень просто.

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

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

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

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

Что еще нужно знать о стандартизации процессов:

1. Стандарт должен очень тщательно разрабатываться и основываться как на практическом выполнении процесса, так и на расчетах, и понимании эффективного процесса.
2. Стандарт может представлять из себя общее описание этапов процесса и его результатов.
3. Стандарт процесса может быть очень коротким. Буквально один абзац.
4. Стандарт процесса, это инструмент управления.
5. Стандарты могут быть ошибочны и тогда их нужно менять.
6. Процесс меняется со временем и стандарты должны также меняться.

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

Регламентация бизнес процессов

Самое комплексное понятие. Регламентация бизнес процесса, это, собственно, процесс создания регламента процесса. Что такое регламент? Процитирую из нашей предыдущей статьи «Как сделать регламент процесса, который будет работать»:

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

Регламентация бизнес процессов осуществляется тогда, когда разрыв между тем, как процесс выполняется (описание) и тем, как он должен выполняться (стандарт), устранен. Ну почти так. Иногда, все же, регламент, на определенном этапе оптимизации, выполняет роль стандарта и задает вектор в устранении разрывов. Таким образом, регламент включает в себя и описание и стандарт процесса. А помимо этого, он включается в себя описание всего, что необходимо для осуществления управления бизнес процессом. В этом фундаментальное отличие регламента бизнес процесса от прочих документов. Обязательно ознакомьтесь с примером регламента бизнес процесса.

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

Вот, пожалуй, и все.

Что мы знаем об описании, стандартизации и регламентации бизнес процессов? Да, пожалуй, очень многое. Так что, если вам нужны документы, которые будут действительно работать, а не «лягут на полку» пустым грузом, обращайтесь в нашу компанию.

Бизнес-процессы, основные стандарты их описания

СПОСОБЫ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССА

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

1. Текстовый: «Отдел продаж составляет договор и согласует его с юридическим отделом».

2. Табличный.

№	Операция	Ответственный	Что (Вход)	От кого (Поставщик)	Что (Выход)	Кому (Клиент)
1	Составляет договор	Отдел продаж	—	—	Договор	Юридический отдел
2	Согласует договор	Юридический отдел	Договор	Отдел продаж

3. Графический.

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

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

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

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

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

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

ОПИСАНИЕ ОКРУЖЕНИЯ БИЗНЕС-ПРОЦЕССА

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

Пример 1

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

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

Пример 2

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

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

При описании окружения бизнес-процесса рекомендуется построить его графическую схему (рис. 1).

КЛАССИФИКАЦИЯ ВХОДОВ И ВЫХОДОВ БИЗНЕС-ПРОЦЕССОВ

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

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

Характеристики первичных и вторичных входов и выходов бизнес-процесса

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

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

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

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

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

КЛАССИЧЕСКАЯ МЕТОДОЛОГИЯ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ — DFD

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

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

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

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

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

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

Правило 1. Названия работы нужно формулировать согласно следующей формуле:

Название работы = Действие + Объект, над которым действие осуществляется.

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

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

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

Название потока = Объект, предоставляющий поток + Статус объекта.

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

ПОСТРОЕНИЕ СЕТИ БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

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

ДЕКОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССА

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

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

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

В случае необходимости работы на схеме процесса второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия «вложенный процесс» или «подпроцесс». На рис. 7 процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.

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

ПОСТРОЕНИЕ ДИАГРАММЫ ПОТОКОВ РАБОТ — WFD

При описании бизнес-процессов нижнего уровня используются несколько иные процессные схемы — WFD. На этих схемах появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки (рис. 8).

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

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

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

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

Отличительной особенностью WFD-диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ.

Итак, с помощью двух классических схем — DFD и WFD — можно описать подробно все бизнес-процессы компании.

 

С.М. Ковалев, генеральный директор компании «БИТЕК», В.М. Ковалев, ведущий консультант компании «БИТЕК»

Современные стандарты описания и исполнения бизнес-процессов

Артамонов И.В., преподаватель БГУЭП

«Процессное направление» современной индустрии информационных технологий активно развивается. С начала 2000-х годов в отрасли появилось множество терминов и аббревиатур, так или иначе связанных с бизнес-процессами: BPM (Business Process Management), BPMS (Business Process Management System), BPMN (Business Process Model and  Notation), BPEL (Business Process Executable Language), BPML (Business Process Modeling Language), BPI (Business Process Integration), BPSS (Business Process Specification Schema), BI (Business Intelligence), BMM (Business Motivation Model), BPDM (Business Process Definition Metamodel),  BPMM (Business Process Maturity Model). За некоторыми аббревиатурами скрываются комплексы информационных систем поддержки бизнес-процессов, подходы к описанию, моделированию и исполнению бизнес-процессов, общепринятые и нишевые, активно использующиеся и возможно уже устаревшие (всего за несколько лет) стандарты.

На данный момент сформировались и используются несколько стандартов описания бизнес-процессов. Отметим, что из данного обзора намеренно исключены нотации описания бизнес-процессов, разработки которых были завершены до 2000 года, такие как, например, IDEF, DFD, EPC. Как отмечают многие специалисты, например Ю.Волков в [17], George Lawton в [18], или [19] диаграммы IDEF и EPC позволяют описывать бизнес-процессы, однако обладают низким уровнем выразительности, точности и однозначности, который не позволяет создавать объективные модели процессов организации и вынуждается аналитиков и разработчиков создавать дополнительные документы, описывающие те или иные особенности бизнес-процессов. Это положение негласно, но явно подтверждают крупнейшие разработчики современных CASE-средств (вообще вопрос принадлежности современных пакетов BPEL / BPM  к классу CASE требует отдельного обсуждения) для разработки и описания бизнес-процессов: диаграммы IDEF, DFD, ERD используются лишь для поддержки ранее собранных документов и преобразования их к современным стандартам.

Анализ литературы (например [2], [3], [4], [5], [6], [7], [11],  [8], [9], [10], [16]) и официальных каталогов стандартов (например [12], [13]) позволил выделить такие стандарты описания, реализации и взаимодействия бизнес-процессов как BPMN, UML, BPEL, XPDL, WS-CDL, JPDL, XLang, BPML, WSFL, WSCL, BPSS, WSCI.

Рекомендуем

Узнайте больше про ECM из вебинаров

Анализ стандартов

Приведем таблицу, предложенную М. Романовым [11], и дополним ее.

Эти стандарты стали разрабатываться в ответ на потребности рынка информационных технологий для бизнеса в начале 2000-х. В тот момент обострились проблемы интеграции разнородных приложений на одной технологической площадке, проблемы поддержки унаследованных приложений и данных, появилась концепция веб-служб, стали активно развиваться технологии управления бизнес-процессами (BPM), а вслед за этим появилась и парадигма сервис-ориентированной архитектуры (СОА). Эти и другие вызовы рынка заставили крупнейших поставщиков, развивая свои предложения, разрабатывать внутрикорпоративные стандарты поддержки бизнес-процессов для их описания, реализации  и исполнения в рамках своих программных систем. Было опубликовано множество спецификаций, таких как JPDL, XLang, BPML,  WSFL , WSCL, BPSS, WSCI, которые поддерживались отдельными конкурирующими продуктами. Часть этих стандартов наследовалась из workflow-языков 90-х [30], [34], часть – для поддержки работы отдельных приложений, часть – была разработана специально для поддержки веб-служб.

Развитие этих стандартов схоже с историей технологий распределенного компонентно-ориентированного программирования. Основной проблемой развития этого направления, как отмечает В.Кулямин [21], стали закрытые, нишевые стандарты, которые, ввиду постоянной конкуренции таких производителей как Microsoft и SUN, также постоянно изменялись и были слабо совместимы даже между ближайшими версиями. Такая скачкообразная и необоснованная эволюция, закрытость форматов данных и «сильная связанность» компонентов (и некоторые другие причины) привели к отрицанию мировой общественностью компонентной модели как надежного средства интеграции разнородных приложений и построения гибких распределенных систем. В связи с этим стала развиваться концепция веб-служб, в корне своем отвергающая недостатки компонентно-ориентированной разработки, веб-сервисы реализовывали бизнес-процессы, и те и другие описывались с помощью стандартов JPDL, XLang, BPML, WSFL, WSCL, BPSS, WSCI. В итоге, в начале 2000-х ситуация, приведшая к депопуляризации компонентно-ориентированной разработки, начала назревать и в средствах описания и реализации бизнес-процессов и веб-служб: на рынке существовало не менее десяти группировок, определяющих BP-* стандарты [47] и протоколы взаимодействия и описания веб-служб.

Однако привлечение опыта разработки открытых стандартов интернет-консорциума W3C и открытых стандартов веб-служб консорциумом OASIS позволило таким крупнейшим поставщикам как Microsoft, Intalio, SAP, IBM, Oracle, JBoss, Adobe, BEA собрать воедино опыт разработки стандартов и предложить единые спецификации описания служб и процессов, например, для создания BPEL [22]. Этой точки зрения придерживается, например, Ю.Волков в [17]: «Прошло то время, когда спецификации описания бизнес-процессов создавались для собственных нужд: сегодня такой роскоши (или такого убожества) не могут позволить себе даже IBM и Microsoft. Спецификации разрабатываются и открыто обсуждаются годами, причём этим уже не занимаются сами корпорации: для того, чтобы международное сообщество не похоронило эти «закрытые спецификации» только из-за их закрытости. Разработка глобальных спецификаций (открытых стандартов) — удел международных некоммерческих организаций (консорциумов), в которые входят представители всех заинтересованных сторон.» Таким образом, такие стандарты как JPDL, XLang, WSFL, WSCL, BPSS, WSCI, BPML были полностью или частично заменены [8] совместно разработанным языком BPEL. Причем BPML и WSCI также разрабатывался консорциумами крупных разработчиков, но как после «жарких» дискуссий в прессе в 2002-2005-х годах (например, в [23], [24], [25]), так и ввиду того, что BPEL поддерживался такими крупными корпорациями как IBM, Microsoft и BEA,  предпочтение, как показала практика, было отдано BPEL. Впрочем, это не мешает ему «почти» конкурировать со стандартом XPDL, поддерживаемым Workflow Management Coalition, куда входят такие крупные поставщики как Adobe Systems, Fujitsu, TIBCO Corporation, BEA Systems. Последняя в этом списке компания, BEA Systems, в 2008 году была приобретена компанией Oracle, а в конце 2009 Oracle выкупила Sun, крупного поставщика программных и аппаратных решений, поддерживающего развитие java-проектов (отметим, что на протяжении уже нескольких лет компания Oracle каждый месяц покупает компании конкуренты или нишевых поставщиков, усиливая линейки своих продуктов [26]). Такая тенденция слияний и поглощений, особенно в пост-кризисный период позволяет рассчитывать на дальнейшее объединение и унификацию стандартов. Подробнее о борьбе коалиций компаний за стандарты и историю их развития можно почитать у А. Михеева, М. Орлова в [33].

Так, к 2008-му году список развивающихся и поддерживаемых стандартов сократился до BPMN, UML, BPEL с расширениями,  XPDL, WS-CDL, ebXML.

Причем пара BPMN и UML (в основном диаграммы деятельности) предназначена для графического описания процессов, XPDL и BPEL для описания оркестровки процессов, а WS-CDL и ebXML для описания хореографии. Хотя опыт практического применения показал, что некоторые распространенные стандарты волей вендоров неплохо справляются и со смежными областями [37], поддержка крупнейшими производителями практически сдвигает непопулярные стандарты в ниши или в «опциональные» свойства продукта, и поэтому этот список можно сократить до BPMN, XPDL, BPEL.

Business Process Executable Language

Представленная русскоязычная литература о BPEL носит несколько устаревший характер. Пик публикаций о BPEL пришелся на 2004-2005 года, за несколько лет до утверждения спецификации WS-BPEL 2.0. Этот стандарт описан в соответствующем разделе официального сайта консорциума OASIS [29]. Отличия BPEL 1.1 от WS-BPEL 2.0 описаны в третьей части техническом обзоре WS-BPEL 2.0 от OASIS [40]. Или в описании стандарта BPEL на сайте Oracle [41].

BPEL – это XML-подобный язык описания поведения бизнес-процессов и последовательности их вызовов. Немного более развернутое и интересное определение дает Ю. Волков [42]: «BPEL определяет модель и грамматику для описания поведения бизнес-процессов, основанных на web-сервисах, в терминах длительных, обладающих состоянием взаимодействий (состоящих из обмена сообщениями) между процессом и его партнёрами». Процессы могут не только вызывать веб-службы для реализации определенных функций, но и сами представляться в виде веб-служб. Такую возможность отобразить процессы и потоки работ на совокупность веб-служб Д. Рапоза  назвал [43] главным преимуществом BPEL. Наряду с элементами, которые BPEL вобрал в себя из моделей workflow (ветвление и объединение процессов, параллелизм и под-процессы), в нем поднимаются вопросы асинхронного взаимодействия, поведения на случай возможных ошибок. BPEL иcпользует WSDL для описания интерфейсов веб-служб, что позволяет легко интегрировать их с другими приложениями и процессами и, как обычный язык программирования, процесс может быть описан на нем и выполнен вручную, но чаще всего автоматически генерируется из workflow-диаграмм.

Введем понятия оркестровки и хореографии бизнес-процессов.

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

Хореография — это определение последовательности условий, при соблюдении которых несколько независимых участников обмениваются сообщениями с целью выполнения некоторой общей бизнес-задачи [48]. Здесь нет центрального координатора, наоборот, каждая веб-служба, вовлеченная в хореографию, знает точно, когда и с кем нужно взаимодействовать. Каждый участник хореографии должен знать о всех выполняемых бизнес-процессах, операциях, сообщениях и настройках для их обмена.

Границы между оркестровкой и хореографией достаточно размыты. Так BPEL поддерживает и оркестровку, и хореографию через понятия абстрактных и исполняемых бизнес-процессов, хотя напрямую для описания хореографии предназначен, например, WS-CDL.

В BPEL бизнес-процессы можно описать двумя способами:

1. Описав детально бизнес-процесс. Такой процесс будет исполняемым и будет отвечать принципам оркестровки. Он определяет четкие алгоритмы работы, задает набор выполняемых служб и определяет входящие / исходящие сообщения. Этот процесс выполняется в BPEL-движке.

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

В общем случае BPEL-скрипт включает:

●   Корневой тег <Process>

●   Блок импорта WSDL или другой схемы для определения типа данных и интерфейса служб.

●   Ссылки на участников процесса, которые позволяют определить роли и взаимодействующие процессы.

●   Переменные, используемые процессом, описанные в терминах WSDL или используемой XML-схемы.

●   Обработчики ошибок и событий

●   Последовательности действий (activities)

Команды BPEL называют  activities (букв. с англ. «действия»). Их можно разделить на 4 типа:

1.     Коммуникации, например:

●   Вызов операции веб-службы (<invoke>)

●   Ожидание внешнего сообщения  (<receive>)

2.     Управление, например:

●   Разветвление с использованием «case» (<switch>)

●   Цикл (<while>)

●   Показывает, что потоки должны быть выполнены параллельно (<flow>)

●   Ожидание (<wait>)

●   Определить последовательность шагов для выполнения в специфическом порядке (<sequence>)

●   Выполнить один из несколько альтернативных путей (<pick>)

3.     Ошибки, например:

●   Индикация о произошедшей ошибке или когда что-то пошло не так (<throw>)

4.     Другое, например:

●   Копирование данных (<assign>)

●   Генерация ответа для входа / выхода (<reply>)

●   Уничтожить экземпляр службы (<terminate>)

●   Ничего не делать (<empty>)

Подробнее о семантике BPEL можно узнать в официальной спецификации стандарта в [22], в дальнейшем в статье будет более подробно рассмотрена его роль через взаимосвязь с другими стандартами.

XML Process Definition Language

Текущая версия XPDL – 2.1а, представленная на сайте Workflow Management Coalition [49]. XPDL (XML Process Description Language) – XML-ориентированный формат проектирования процессов и обмена информацией о них между различными утилитами моделирования и исполнения бизнес-процессов. XPDL основан на языке WPDL (Workflow Process Definition Language, кр), который WfMC разрабатывала с начала 90-х для поддержки workflow-систем.

XPDL  определяет XML-схему, которая используется для спецификации декларативной части процесса. В отличие от BPEL, XPDL – это не исполняемый язык, XPDL – это формат, определяющий синтаксис для хранения моделей и графической информации бизнес-процессов.  Поэтому основным назначением XPDL является поддержка хранения диаграмм процессов между программными инструментами, один из которых может быть предназначен для моделирования процесса, другой для чтения и редактирования, третий для исполнения процесса и  т.д. [2]. Стоит отметить также возможность двустороннего преобразования процессов из BPMN в XPDL и обратно, в отличие от BPMN в BPEL, где это преобразованием одностороннее. Официальная спецификация XPDL, сравнивая его с BPMN, говорит о том, что и BPMN, и XPDL решают один и тот же комплекс проблем моделирования процессов, но разными путями. XPDL – это обмен моделями между инструментами, BPMN – обмен графическими представлениями о процессах между пользователями, бизнес-аналитиками и техническими специалистами. 

Наличие поддержки XPDL в BPM-связных системах существенно облегчает возможность интеграции этих систем между собой. При этом можно, например, использовать уже разработанные в одном средстве диаграммы моделей, чтобы исполнять их на новом «BPM-движке». Некоторые (сравнительно немногие, если верить официальным данным WfMC)  BPM-движки могут обрабатывать XPDL напрямую, некоторым же необходимо преобразовать поток процесса в BPEL или в более низкоуровневый язык, Java, C#,Ruby, и пр.  Таким образом, пользователи BPM-систем в зависимости от реализованного функционала: во-первых, или они «рисуют» диаграммы с помощью BPMN, сохраняют в XPDL в процессе разработки, и преобразуют в BPEL для исполнения в BPM-движках, или, во-вторых, используют цепочку трансформации BPMN=>BPEL=>[Специфический язык исполнения BPM] (особо для поддержки оркестровки бизнес-процессов, что хорошо поддерживает BPEL), или, в-третьих, пользуются цепочкой BPMN=>XPDL=>[Специфический язык исполнения BPM] (если необходима поддержка возможностей, отсутствующих в BPEL). Хотя, возможно, органичная комбинация BPEL, BPMN, XPDL в рамках одной системы или предприятия позволит избежать жесткой привязки к определенному поставщику [57].

Одним из важнейших свойств XPDL Кейт Свенсон (Keith Swenson), считает возможность его расширения [2]. Язык поддерживает возможность введения дополнительных атрибутов, которые производитель ПО может вводить для своих целей. Например, одна утилита может вводить определенные требования на диаграмме, сохраняя их через расширенные атрибуты. Другая утилита, естественно, эти расширения распознать и адекватно обработать не сможет, но может их сохранить в модели, и, в случае необходимости, вернуть обратно. С другой стороны, возможности расширения и поддержки элементов и атрибутов именно для исполнения процессов некоторые аналитики считают недостаточными, выходящими за рамки возможностей XPDL 2.1 [53].

По данным консорциума WfMC [50] список продуктов разных производителей, поддерживающих XPDL тем или иным образом достаточно широк. XPDL используется для хранения диаграмм или в качестве формата для импорта / экспорта. Так, Кейт Свенсон называет XPDL «форматом поддержки диаграмм бизнес-процессов на долгие годы, так как его поддерживают множество вендоров, а WfMC обеспечит полную совместимость следующих версий XPDL с более старыми». Однако это утверждение легко оспаривается другими аналитиками: среди этих производителей нет ведущих вендоров BPM или нет их ведущих продуктов [53]. Измаеля Халими [52]  отмечает, что в XPDL-код, который генерирует большая часть утилит, вкладывается лишь малая часть от семантики, необходимой для выполнения процесса. При портировании диаграмм с одного инструмента в другой нередко бизнес-аналитики должны исправлять или дополнять модели, таких недостатков лишен, например, BPEL, один и тот же код которого успешно выполняется на разных BPM-платформах. Поэтому, отмечают Халими и  Скотт, при выборе определенного продукта, нацеливаясь на поддержку стандартов и множества различных поставщиков, стоит убедиться, что выбранные продукты действительно поддерживают заявленный или необходимый уровень переносимости процессов через XPDL.  Себастьян Штайн (Sebastian Stein) показывает два неудобства при использовании XPDL [51]: в-первую очередь, это слишком большой объем официальной спецификации, часть которой не описывает XPDL напрямую, а во-вторых, несмотря на то, что именно форматы XPDL и BPMN чаще всего вынуждены работать «в паре», они поддерживаются разными консорциумами, которые почти не взаимодействуют друг с другом, вернее консорциум OMG, работая с BPMN, не взаимодействуюет с WfMC [61], но WfMC  приходится ориентироваться на работы при разработке XPDL: Кейт Свенсон, как всегда, аргументируя в поддержку XPDL [54], заявляет, что при подготовке спецификации XPDL 2.1 стандарт BPMN был детально проанализирован для поддержки в новом формате XPDL  и утверждает в [55], что XPDL описывает все, что может быть «нарисовано» в BPMN.  И сейчас вероятность того, что XPDL станет предпочтительным форматом хранения для BPMN 2.0, по словам Скотта Френсиса (Scott Francis), достаточно низка.

Некоторые аналитики считают XPDL и BPEL (например в [11], [4]) прямыми конкурентами, но ошибочность этого утверждения не раз доказывалась на страницах авторитетных изданий. Например, официальный сайт консорциума Workflow Management Coalition (разработчик XPDL) в [27] определяет BPEL и XPDL как «всецело и совершенно различные стандарты». Кейт Свенсон в [2] сравнивает два стандарта, выделяя важные отличия: BPEL – исполняемый язык (это, кстати, явно следует из названия). Это язык программирования с переменными и операторами. XPDL – формат проектирования процессов, отвечающий за хранение и прорисовку описания процесса. Цель BPEL – предоставить описание для оркестрации веб-служб, в основе которой лежит последовательность операций, потоки данных от точки к точке. Цель XPDL – хранение и обмен диаграммами процессов. Он позволяет в одном инструменте создать диаграмму, в другом ее прочитать, и изображения будут практически идентичными. 

Кейт Свенсон показывает отличия на диаграмме (см. рис. 1) . На верхнем уровне расположены различные инструменты проектирования. В нижней части диаграммы – различные среды исполнения. XPDL используется для переноса проекта процесса между инструментами. XPDL, BPEL или другой специфический язык может использоваться для связи выполняемого процесса и «движка» выполнения.

рис. 1 Взаимоотношения двух BPM-систем с точки зрения обмена описаниями процессов

В общем случае любой инструмент описания процесса требует перевода описания в формат, определяемом движком и исполняемый код от одной утилиты не будет работать в движке другого производителя.  XPDL поддерживает двустороннее преобразование с BPMN, BPEL же не гарантируется схожести кода в процессе преобразования BPMN — > BPEL -> BPMN. Брюс Сильвер в [38] выступил с уточнением логики Кейта Свенсона [39] и указал на ряд недоговоренностей, намеренно допущенных автором в целях рекламы стандарта XPDL. XPDL охватывает диаграммы процесса, BPEL – его семантику.  По словами Б. Сильвера К. Свенсон намеренно умолчал об отличиях между диаграммой и моделью процесса и о возможности отображения языками BPEL и XPDL именно процессной модели. Именно поэтому сравнение о переносимости формата XPDL по сравнению с BPEL данное в [2], [39] не совсем верно. BPEL более переносим между движками BPM, когда нужно сохранить семантику процесса. XPDL необходим для работы с одной и той же диаграммой в различных инструментах проектирования. XPDL хранит и описывает диаграмму процесса, а не его модель.  Сэнди Кимсли (Sandy Kemsley), независимый системный аналитик и BPM-архитектор, в [37] обсуждает сравнение двух языков от Workflow Management Coalition [27] и отмечает, что на практике очень мало производителей используют BPEL как язык исполнения процессов в чистом виде. Они используют его и как формат обмена данными, что вызывает ряд споров о конкуренции XPDL и BPEL. XPDL, в свою очередь, поддерживая графическое представление процессов также хорошо, как информацию о исполнении, способен описывать все, что разрабатывается силами BPMN.  Поэтому XPDL и BPEL несравнимы в том смысле, что один не может заменить другой, однако вполне сравнимы как форматы обмена информацией о процессах, только разными способами и в разных инструментах.

Business Process Model and  Notation

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

Основная цель BPMN – поддержка нотации, которая одинаково будет пониматься всеми участниками бизнеса, от бизнес-аналитиков, которые разрабатывают эскизы процессов, разработчиков, которые реализуются технологию для выполнения этих процессов, и до бизнесменов, менеджеров, которые будут управлять и наблюдать за процессами. Таким образом, отмечает официальная спецификация, BPMN – это «мост» между этапами разработки и реализации бизнес-процессов. В отличие от многих других спецификаций, BPMN разрабатывался исключительно для описания бизнес-процессов и поэтому, по сути, поддерживает лишь один тип диаграмм – диаграммы бизнес-процессов.  К.Е. Самуйлов в [48] подчеркивает, что BPMN, являясь графической нотацией «третьей волны» моделирования бизнес-процессов, во многих отношениях превосходит традиционные нотации. Он позволяет моделировать взаимодействие внешние и внутренние бизнес-процессы компании, поддерживает механизмы моделирования передачи сообщений и обработки исключительных ситуаций. Другой не менее важной целью является поддержка визуализации в бизнес-нотации XML-языков, ориентированных на выполнение бизнес-процессов (например, BPEL).

OMG позиционирует стандарт как вобравший в себя все лучшие идеи, концепции и опыт других нотаций моделирования процессов, таких как ML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains.

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

●   Flow Objects (объекты схемы, объекты потока управления) – основные графические элементы, которые описывают поведение бизнес-процесса. Включают три элемента:

●   Event (Событие) означает нечто, которое «происходит»  по время процесса. События изображаются окружностью с рисунком в центре для выделения отдельных подтипов.

В процессе можно выделить:

●   начальные (start) события – указывают на начало процесса

●   промежуточные (intermediate) события – указывают, что что-то произошло где-то между началом и окончанием процесса.

●   завершающие (end) события – указывают на завершение процесса.

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

Activity (Действие) – это работа, которая выполняется в бизнес-процессе. Это исполняемый элемент BPMN-диаграммы. Действие может быть атомарным или составным. Отображается прямоугольником с закругленными углами.  Определено 3 типа действий:

●   Задача (task) это атомарное действие в потоке процесса. Задача используется тогда, когда процессе не может быть более детализован. В общем случае задачи выполняет пользователь или приложение. Отдельно стоит выделить задачи, решаемые с привлечением людей. BPMN выделяет два типа таких задач: ручные (manual task) и пользовательские (user task). Пользовательская задача исполняется и управляется в среде бизнес-процесса, например, это некоторое действие пользователя для реализации БП с помощью ПО, а ручная задача не контролируется системами управления бизнес-процессами. Это может быть, например, установка техническим персоналом телефона для клиента. Задача изображается прямоугольником со скругленными краями.

●   Под-процесс (sub-process) – действие, которое может быть детализировано на другие действия, события, логические операторы и потоки управления. В старых версиях BPMN вместо под-процесса выделяли Транзакцию (transaction), однако сейчас она рассматривается как специализированный тип под-процесса. Задачи и подпроцессы могут быть снабжены определенными маркерами, указывающими некоторые характеристики их выполнения.

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

Вызывающее действие (call activity) позволяет включать повторно используемые глобальные задачи и процессы в диаграмму и идентифицируют точку их входа в процесс. Изображается прямоугольником со скругленными краями и толстой линией границы.

Gateways (Логические операторы) необходимы для контроля над объединением и разветвлением потоков управления процессами. Прямой перевод слова как «ворота, шлюз» предполагает наличие некоего шлюзового механизма, который разрешает или не разрешает потоку управления проходить через себя, при этом поток может быть как разделен на альтернативные ветви, так и альтернативные ветви могут объединиться. Логические операторы определяют все типы поведения потока с условиями включения, исключения, сложными условиями, объединениями и разветвлениями. Логический оператор изображается «алмазом», внутри которого изображается тип операции.

●   Исключающий логический оператор (exclusive gateway, оператор исключающего «ИЛИ») применяется для создания альтернативных потоков процесса или для их объединения. Это базовый способ разделения / объединения потока процесса. При разделении может быть выбрана только одна ветвь, при объединении оператор ожидает завершения любой их входящих ветвей. Этот оператор может помечаться знаком «Х» в центре «алмаза». В случае, если ни одно из условий оператора не находится в состоянии «истина», выполнение может быть передано по ветви, определенной разработчиком «по умолчанию».

●   Включающий логический оператор (inclusive gateway, оператор включающего «ИЛИ») применяется для создания одного или нескольких альтернативных параллельных путей в потоке процесса. В отличие от исключающего оператора, все условия входа в оператор должны быть выполнены (все входящие ветви должны быть завершены). Изображается знаком окружности «О» в центре «алмаза». Ветвь по умолчанию создается для аналогичных с исключающим оператором условий.

●   Параллельный логический оператор (оператор «И») используется для синхронизации и создания альтернативных потоков. Изображается знаком «+». Параллельные потоки создаются без какой-либо проверки условий. При объединении потоков оператор ожидает завершения всех входящих ветвей перед тем как активировать исходящую.

●   Сложный логический оператор (complex gateway) используется для моделирования сложных ситуаций синхронизации. Например, для активации исходящего потока оператор может потребовать завершения трех из пяти входящих ветвей. Использование этого оператора нежелательно, так как оно затрудняет понимание диаграммы.

●   Событийный логический оператор (event-based gateway) используется для ветвления потока процесса на основе «срабатывания» определенных событий, в отличие от вычисления условных выражений с использованием данных процесса (как в вышеописанных операторах). Например, компания может ожидать ответа заказчика. Если он скажет «Да» — нужно будет провести один комплекс действий, а в случае «Нет» — совершенно другой. Ответ заказчика и идентификация сообщения определяют путь процесса, поэтому прием сообщения может быть смоделирован при помощи промежуточного события-сообщения. Вдобавок, определенный набор действий можно инициировать здесь по таймеру, если, например, клиент не ответил вовремя. Этот оператор обязан включать  два и более исходящих потоков и не должен содержать условий перехода: исходящие потоки указывают на события, которые являются частью событийного оператора или на обработчики сообщений. Поток управления передается на то событие, что произошло раньше. Этот оператор изображается как составное промежуточное событие.  Существуют еще и исключающий и параллельный событийные логические операторы, которые используются для создания и запуска отдельных экземпляров процесса.

●   Исключающий событийный логический оператор (exclusive event-based gateway) создает экземпляр процесса, если наступает каждое из следующих за ним событий. Такой процесс или не должен иметь начального событий, а логический оператор не должен иметь входящего потока управления, или входящий поток управления приходит от обычного начального события. Изображается как составное начальное событие.

●   Параллельный событийный логический оператор (parallel event-based gateway)  создает экземпляр процесса при наступлении всех последующих событий. При этом первое событие инициирует процесс, но наступление остальных событий также необходимо для нормального завершения процесса.  Оператор изображается как параллельное составное начальное событие.

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

●   Data Objects (Объекты данных) предоставляют информацию, которая обрабатывается или производиться действиями. Объекты данных могут быть представлены как единичными экземплярами, так и коллекциями. Изображаются в виде пустого листка или листка с тремя чертами для коллекций.

●   Data inputs (Входные данные) предоставляют данные, подающиеся на вход процесса. Изображается в виде листочка с неокрашенной стрелкой.

●   Data outputs (Выходные данные) представляют собой результат выполнения процесса. Изображаются в виде листочка с окрашенной стрелкой.

●   Data Stores (Хранилища данных) предоставляют механизм получения и добавления данных, которые будут храниться вне зависимости от жизни процесса. Изображаются значком базы данных (жесткого диска). 

●   Properties (Свойства) определяют некоторые признаки элементов потока управления: процессов, действий, событий. Не видны на диаграмме.

Connecting Objects (Соединяющие объекты) определяют четыре способа взаимодействия объектов потоков друг с другом и с другими элементами:

●   Sequence Flow  (Поток управления) показывает порядок работы объектов в бизнес процессе или в процессе хореографии. Каждый поток управления имеет только один источник и только одну цель. Источником и целью могут выступать только: события, действия, действия хореографии, логические операторы. Изображается сплошной линией с закрашенной стрелкой на конце. Кроме того, для потока управления может быть определено условие, показывающее, что поток будет выполнен, если будет выполнено определенное условие. Условие обычно используется, когда источник поток – логическое оператор или какое-либо действие. Поток управления с условием, исходящий из действия, обязан начинаться со значка «алмаза», при этом действие должно содержать как минимум еще один безусловный исходящий поток управления. Поток управления с условием, исходящий из логического оператора, значка «алмаза» не содержит, а логический оператор не должен быть параллельным или событийным. Поток управления может быть определенным «по умолчанию» для включающих, исключающих, сложных логических операторов или действий. Он имеет значок «слэш» в начале стрелки.

●   Message Flow (Поток сообщений) используется для передачи сообщений между двумя участниками. Поток сообщений соединяет два различных пула. Он должен касаться границы пула или объекта потока управления в пуле. Он не может объединять два объекта одного пула. Изображается в виде пунктирной линией, которая начинается с пустого кружка и заканчивается пустой стрелкой.

●   Association (Ассоциация) используется для ассоциации информации и артефактов с объектами потока управления. Информация может быть представлена текстом или графическими объектами. Кроме того, ассоциация может указывать на то, используется ли действие для компенсации. Ассоциация отображается одиночной точечной линией .

●   Data Association (Ассоциация данных) используются для перемещения объектов данных, свойств и входящей/исходящей информации действий, процессов и глобальных заданий. Результаты ассоциаций данных не оказывают прямого влияния на поток процесса. Ассоциация данных изображается пунктирной тонкой стрелкой. Ассоциация данных всегда имеет источник, цель и возможную информацию о трансформации данных. При выполнении ассоциации данных, данные копируются из источника к цели.

Swimlanes (букв. «Плавательные дорожки», иначе говоря «Разделительные дорожки») позволяют группировать элементы модели по пулам и дорожкам, распределяя между ними обязанности.

●   Pool (пул) выступает как контейнер для потока управления между действиями или как определенный участник бизнес-процесса. Процесс полностью содержится в пуле. Поток управления может пересекать дорожки (lanes) пула, но не может пересекать границы пула. Взаимодействие между пулами осуществляется через потоки сообщений. Каждый пул может выступать как «черным», так и «белым» ящиком, детализируя или скрывая свою внутреннюю структуру. В случае «черного ящика» поток сообщений соединяет границы пула, в случае «белого ящика» — его определенные действия. Любое взаимодействие (Collaboration) имеет хотя бы два пула (т.е. участника). Каждый пул отображается прямоугольником, в левой (верхней) части которого пишется имя пула. Обычно прямоугольник проходит через всю диаграмму по вертикали или по горизонтали. Если в диаграмме выделен главный пул – он может не обрамляться границами.

●   Lane (дорожка) является составной частью пула. Служит для группировки и организации действий в пуле. Изображает горизонтальным или вертикальным поименованным прямоугольником длинной как и весь процесс. BPMN строго не определяет назначение линий. Они могут использоваться для отображения внутренних ролей (например Менеджер), систем (например, информационная система), или отдел организации и т.д.

Artifacts (Артефакты) используются для предоставления дополнительной информации о процессах. Существуют два стандартных артефакта (Group (Группа), Text Annotation (Аннотация), однако для своих нужд разработчики могут создавать любые другие. Текстовая аннотация служит для дополнительного описания элемента диаграммы. Изображается половинкой прямоугольника. Группа служит для группировки элементов диаграммы. Изображается прямоугольником с закругленными углами в пунктирную через точку линию.  Артефакты не могут выступать как элементы потока управления, не могут соединяться потоками управления или сообщения, на них не накладываются ограничения пулов и дорожек. Таким образом, например, группа может пересекать границы пула для объединения элементов диаграммы.

Отдельно следует выделить особый элемент BPMN, который не отображается отдельным графическим элементом, но присутствует или предполагается на любой диаграмме – это участник (participant). Под участником может пониматься некая сущность – бизнес-партнер (например, компания-поставщик) или роль процесса (например, покупатель), участвующая в процессах взаимодействия. Именно участника отображают пулы BPMN. С понятием участника тесно связаны диаграммы взаимодействия (совместные диаграммы) BPMN. В ранних спецификациях эти диаграммы выделяли в отдельный тип и называли глобальными (Collaboration (global)). На диаграмме взаимодействия показаны несколько пулов и потоки сообщений между ними.

В BPMN 2.0 определены два основных типа процессов процессы хореографии и процессы оркестровки. Процессы оркестровки представляют собой набор действий или взаимодействие внутри компании. С этими процессами наиболее часто работают бизнес-аналитики. В BPMN к ним относят частные (внутренние) и абстрактные (открытые) процессы.

●   Частный (public) бизнес-процесс выполняется внутри организации. Этот тип бизнес-процесса часто называют workflow или BPM-процесс. В области СОА этот процесс часто связывают с оркестровкой служб. Частный процесс подразделяется на два вида: исполняемые и неисполняемые. Исполняемый процесс создается и моделируется для выполнения, неисполняемый служит лишь для оценки поведения процесса на определенном уровне детализации бизнес-процессов компании.

●   Абстрактный (abstract, это название взято еще из BPMN 1.2) (public) бизнес-процесс необходим для демонстрации взаимодействия между частными бизнес-процессом и другим процессом или участником процесса. Абстрактным процессом можно назвать тот, в котором есть действия по коммуникации с другими участниками процесса. Все остальные внутренние действия частного процесса не показываются на схеме абстрактного. Так, с помощью открытого процесса можно показать последовательность обмена сообщениями между процессами.

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

Основным элементом диаграмм хореографии стало действие хореографии (Choreography Activity) – некий этап взаимодействия между двумя сторонами. Единое, неделимое действие, задача хореографии описывает процесс обмена сообщениями между двумя участниками. Название процесса и имена участников подписываются на графическом элементе задачи хореографии – скругленном прямоугольнике с тремя областями. Соединяются задачи потоками управления, которые могут проходить через шлюзы. Существуют несколько специфических типов потоков управления и особенностей их использования в диаграммах этого типа. Диаграммы хореографии могут быть как детализированы с помощью диаграмм взаимодействия, так и присутствовать на них. 

Процессы хореографии поддерживались в BPMN 1.2 в виде диаграмм взаимодействия, однако специалисты находили в этом подходе ряд существенных недостатков, например, Геро Декер в [63] говорит о ненужной избыточности, несоответствии потоков управления и  событий запуска процессов. Введение элементов хореографии устранила часть этих проблем, но и породило свои, например, проблемы очередности взаимодействия между множеством участников.

Подробнее об элементах BPMN можно прочесть в официальной спецификации BPMN [12].  На сегодняшний день поддержка BPMN реализована в программном обеспечении большого количества производителей [48], например, таких как Oracle, IBM и др.

Взаимосвязь BPEL, XPDL, BPMN

Вопросы о необходимости наличия стандартов описания, исполнения и взаимодействия процессов, а также вопросы их способности адекватно описывать предметную область неоднократно поднимались и обсуждались в прессе (например, в [2], [35], [1], [33], [7], [36]).  Tom Baeyens, ведущий разработчик платформы JBoss jBPM, утверждая в [1], что описывать бизнес-процессы можно с использованием множества нотаций, не ограничиваясь набором из тех, что поддерживаются производителями. Пьер Вигнерас (Pierre Vigneras) проанализировав ряд статей в [36] и сравнил процедуры и результаты преобразования между BPMN и BPEL и показал, что, несмотря на все успехи развития оболочек программирования и проектирования программистам BPEL приходиться напрямую работать с этим языком, а для бизнес-аналитиков язык очень сложен – сложен, чтобы учить и читать, сложен для реализации, и, что самое важное для обеспечения прозрачности, – сложен для скрытия реализации. Кроме того, BPEL при преобразовании из BPMN привносит много мелочей в модель процесса, о которых бизнес-аналитик может и не знать: это разнообразная техническая и программная информация. Таким образом, такое преобразование достаточно сложно совершить, а результат, если он и получится, будет сложно даже прочитать.

Кейт Свенсон, ссылаясь на Пьера Вигнераса, показывает в [35], что BPEL совсем не нужен для реализации процесса, достаточно лишь спецификации BPMN. С другой стороны, наличие стандарта все же лучше, чем его отсутствие, подчеркивает он в [46]. Исмаель Халими (Ismael Ghalimi), вступая в эту дискуссию напрямую, приводит несколько положений в [7], доказывая права существование языка BPEL и BMPN:

1. Корректность. Использование стандартов выполнения процессов, которые описаны нотациями типа BPMN, предполагает определенные, четкие пути проверки корректности выполняемых моделей.

2. Предсказуемость. Использование стандартов выполнения процессов дает возможность предсказать поведение исполняемых моделей процесса.

3. Переносимость. Использование стандартов выполнения процессов дает возможность переноса исполняемых процессов между исполняющими системами, предоставленными различными вендорами.  Тем более, как отмечает Ю. Волков в [42], нотации BPEL и BPMN приняты крупнейшими поставщиками как стандарты де-факто и совместимы между различными реализациями.

4. Тестирование производительности. Использование стандартов выполнения процессов позволяет объективно тестировать производительность систем различных вендоров на основе одной и той же модели процессов.

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

Ю. Волков в [42] добавляет к преимуществам строгость, минимализм и высокую распространенность BPMN и BPEL. Кроме того, Исмаель Халими, отвечая на слова Пьера Вигнераса и Кейта Свенсона о сложности BPEL [44], говорит, что никто и никогда не должен писать код на BPEL вручную. BPEL также сложен и точен, как и мощен, он специально разрабатывался для автоматического создания генераторами кода. А если возникла потребность писать код BPEL вручную, то стоит воспользоваться более простыми вариантами, например, SimPEL или jPDL.  Отвечая на предложения избежать кодирования BPMN в BPEL, он говорит, что исполняемых нотаций BPMN не существует. А если кто-то и выполняет диаграммы BPMN напрямую, то он, скорей всего, заново изобрел BPEL 2.0 или что-то похожее. Так, сочетание BPMN и BPEL – это все, что необходимо для того, чтобы сделать процесс исполняемым, но стоит их разъединить и вся система рухнет.  Брюс Сильвер (Bruce Silver) в [45] рассматривает доводы Вигнерса и Халими и отмечает, что BPMN обладает возможностью проводить такие действия, на которые BPEL накладывает серьезные ограничения. Это означает, что не все BPMN диаграммы транслируются в BPEL (таких проблем, например, не испытывает XPDL, при разработке которого учитывали совместимость с последним стандартом BPMN). Вендорам приходится накладывать ограничения на BPMN дизайнеры для поддержки BPEL.  С другой стороны, BPMN проигрывает BPEL в стандартизации семантики. Каждый вендор самостоятельно решает, что из стандарта он поддерживает, а что нет. С BPEL все строже, вендор может добавлять в него свою функциональность, но если его программное обеспечение не поддерживает базовую семантику  нотации – то нельзя говорить о поддержке BPEL. Рассматривая слова Халими об исполняемых нотациях BPMN,  Брюс отмечает, что SAP и Oracle уже поддерживают прямое исполнение диаграмм в своих BPM-движках, оставляя BPEL роль только в процессах интеграции и СОА.

Итак, было показано, что к началу 2010 года в отрасли автоматизации бизнес-процессов, особенно в зарубежной практике, сформировалось устойчивое понимание основных концепций языков описания и исполнения бизнес-процессов. Несмотря на предваряющие эти соглашения дискуссии и открытую конкуренцию между крупнейшими производителями программного обеспечения и поставщиками средств автоматизации в первом десятилетии 2000-х, консорциумы разработчиков, созданные еще в 90-х для проектирования и внедрения стандартов веб-технологий (например, W3C) и компонентно-ориентированной разработки ПО (например, OMG), по большей части смогли предупредить возможные проблемы параллельного развития в отрасли множества протоколов и стандартов, описывающих одну и ту же предметную область. И отрасль сосредоточилась вокруг трех дисциплин: BPMN, XPDL и BPEL. Однако это не помешало консорциумам по некоторым вопросам [61] вступить в негласную конфронтацию друг с другом, что привело, во-первых, к практически полному игнорированию в некоторых случаях одной нотации другой, а, следовательно, и, во-вторых, к очевидным сложностям интерпретации одной и той же модели бизнес-процесса в рамках различных стандартов. Конечно, предметные области каждого из трех стандартов примерно схожи, а цели и задачи каждого из них, на первый взгляд, предельно различны: BPMN – графическая интерпретация модели, XPDL – семантика ее хранения и промежуточное звено между другими стандартами, а BPEL – это уровень высокоуровнего языка описания взаимодействия процессо. Но детальное рассмотрение и анализ стандартов, и, особенно, дискуссии, развернувшиеся среди самих разработчиков нотаций, не позволяют с уверенностью это утверждать. Скорее, можно объяснить так: для каждой пары стандартов, для BPMN – XPDL, XPDL – BPEL, BPMN – BPEL существуют свои особенные проблемы. Это могут быть проблемы взаимоинтерпретации, сохранения целостности и адекватности модели, пересечения множеств решаемых в рамках стандартов задач и многое другое. В любом случае на данный момент решение этих проблем переложено на плечи поставщиков средств автоматизации, а конечный потребитель поставлен перед самостоятельным выбором оценки необходимости поддержки этих моделей в своей повседневной деятельности, и, следовательно, перед выбором конкретного поставщика. Активная работа над стандартами, совместное их обсуждение всеми заинтересованными группами позволяют предполагать, что сложившаяся в отрасли ситуация в скором времени измениться в лучшую сторону.

Список используемой литературы

1. Tom Baeyens. 3 Approaches To Transform Analysis Diagrams Into Executable Processes. 2008 / [электронный ресурс] // http://processdevelopments.blogspot.com/2008/10/3-approaches-to-transform-analysis.html
2. The BPMN-XPDL-BPEL value chain [электронный ресурс] / Keith Swenson, 2006 // http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/
3. BPM Think Tank Day 2: Panel on Business Value of Process Standards [электронный ресурс]/ Sandy Kemsley, 2006 // http://www.ebizq.net/blogs/column2/2006/05/bpm_think_tank_7.php
4. Стандарты BPM [электронный ресурс]  // http://bpms.ru/library/standards/index.html
5. Михеев А., Орлов М. Война стандартов в мире workflow. 2007 / [электронный ресурс]  // http://www.ecm-journal.ru/docs/Vojjna-standartov-v-mire-workflow.aspx
6. Standards and Web services. / [электронный ресурс] // http://www.ibm.com/developerworks/webservices/standards/
7. Why Standards Matter [электронный ресурс]/ Ismael Ghalimi, 2008  // http://www.bpmlab.org/2008/11/02/why-standards-matter/
8. Matjaz B. J. Business Process Exexution Language for WebServices, Second Edition. / Matjaz B. Juric. – Birmingham, UK: Packt Publishing Ltd., 2006. – 353 стр.
9. Harish Gaur. BPEL Cookbook. Best Practices for SOA-based integration and composite applications development / под ред. Harish Gaur, под ред.  Markus Zirn. – Birmingham, UK: Packt Publishing Ltd., 2006. – 185 стр.
10. Eben H. Java SOA Cookbook / Eben Hewitt. – Sebastopol, USA: O’Reilly Media, Inc., 2009 – 742 стр.
11. Некоторые, наиболее известные стандарты описания бизнес-процессов / [электронный ресурс]/ Романов М., 2009  //  http://www.ecm-journal.ru/blog/post/Nekotorye-naibolee-izvestnye-standarty-opisanija-biznes-processov.aspx
12. Business Process Management Initiative. / [электронный ресурс]  //   http://www.bpmn.org/
13. Catalog of OMG Business Strategy, Business Rules and  Business Process Management Specifications / [электронный ресурс]  //  http://www.omg.org/technology/documents/br_pm_spec_catalog.htm
14. Catalog of OMG Modeling and Metadata Specifications / [электронный ресурс]  // http://www.omg.org/technology/documents/modeling_spec_catalog.htm
15. Unified Modeling Language, версия 2.0 / [электронный ресурс] / Брэн Селик, 2005  // http://www.ibm.com/developerworks/ru/rational/library/321_uml/index.html
16. Ньюкомер Э. Веб-Сервисы. Для профессионалов / Эрин Ньюкомер. – СПб.: Питер, 2003. – 256 с.: ил.
17. Диаграммы для описания бизнес-процессов. [электронный ресурс]/ Волков Ю.О., 2006  // http://yurivolkov.com/articles/Diagrams_for_business_processes_ru.html
18. George Lawton. Co-evolution of BPMN and BPEL drives BPM in SOA settings. 2009 / [электронный ресурс]  // http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1353870,00.html
19. BPMN vs IDEF3: 11:5 в пользу BPMN. 2009 / [электронный ресурс]  // http://chevalry.livejournal.com/115586.html
20. jBPM Process Definition Language (JPDL) / [электронный ресурс]  // http://docs.jboss.org/jbpm/v3/userguide/jpdl.html
21. Кулямин В.В. Технологии программирования. Компонентный подход – М.: БИНОМ, 2006. – 464с.
22. Web Services Business Process Execution Language Version 2.0. 2007 / [электронный ресурс]  // http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
23. Оркестровка и хореография Web-сервисов/ [электронный ресурс]  // http://www.osp.ru/os/2004/11/184785/
24. Will BPEL and WSCI Come Together? [электронный ресурс]/ Thor Olavsrud, 2003  // http://www.internetnews.com/infra/article.php/2211121
25. Robert Shapiro. A Comparison of XPDL, BPML and BPEL4WS/ Shapiro R.,   17 стр. // Cape Visions, 2002 
26. Oracle Magazine — Русское Издание [электронный ресурс]  // http://www.oracle.com/global/ru/oramag/index.html
27. XPDL Support and Resources [электронный ресурс]  // http://www.wfmc.org/xpdl.html
28. OASIS ebXML Business Process TC [электронный ресурс]  // http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp
29. OASIS Web Services Business Process Execution Language (WSBPEL) TC  [электронный ресурс]  // http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
30. WS-BPEL Extension for People (BPEL4People) [электронный ресурс]  / Ashish Agrawal, Mike Amend, Manoj Das [и др.] // http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/BPEL4People_v1.pdf
31. BPML specification [электронный ресурс]  // http://www.ebpml.org/bpml.htm
32. Web Services Choreography Description Language Version 1.0 [электронный ресурс] / Nickolas Kavantzas, David Burdett [и др.] // http://www.w3.org/TR/ws-cdl-10/
33. Война стандартов в мире workflow [электронный ресурс]/ Михеев А., Орлов М.   // http://wf.runa.ru/images/c/ce/Stat_ya2.pdf
34. Business processes and workflow in the Web services world [электронный ресурс]  / Margie Virdell // http://www.ibm.com/developerworks/webservices/library/ws-work.html
35. Directly Executing BPMN [электронный ресурс] / Keith Swenson, 2009   // http://kswenson.wordpress.com/2008/10/29/directly-executing-bpmn/
36. Why BPEL is not the holy grail for BPM [электронный ресурс] / Pierre Vigneras, 2008   // http://www.infoq.com/articles/bpelbpm
37. XPDL and BPEL [электронный ресурс] / Sandy Kemsley, 2007  // http://www.ebizq.net/blogs/column2/2007/03/xpdl_and_bpel.php
38. The Real Issues with XPDL, BPEL, and BPMN [электронный ресурс] / Bruce Silver, 2007  // http://www.bpmenterprise.com/blog/archive/the_real_issues_with_xpdl_bpel_and_bpmn.html
39. Are Apples more useful than Oranges? [электронный ресурс]/ Keith Swenson, 2007     // http://kswenson.wordpress.com/2007/03/20/are-apples-more-useful-than-oranges/
40. Technical Overview of WS-BPEL 2.0 [электронный ресурс]/ Dieter Koenig, 2007  // http://bpel.xml.org/presentation-tech-overview
41. Business Process Management and WS-BPEL 2.0. What’s next for SOA Orchestration? —  An Oracle White Paper, 2006 / Manoj Das [электронный ресурс]  // http://www.oracle.com/technology/tech/standards/pdf/bpel.pdf
42. Волков Ю.О. Что дают предприятию новые стандарты описания бизнес-процессов [электронный ресурс]/ Волков Ю.О.   // http://www.yurivolkov.com/articles/NewBpmStandardsForTheEnterprise_ru.html
43. Куда движется BPM. [электронный ресурс]/ Джим Рапоза, 2007  // http://www.pcweek.ru/themes/detail.php?ID=82525&phrase_id=309871
44. Why BPEL Matters. [электронный ресурс] /  Ismael Ghalimi, 2008  // http://itredux.com/2008/09/28/why-bpel/
45. BPMN-BPEL in Perspective [электронный ресурс]/ Bruce Silver, 2008  // http://www.brsilver.com/wordpress/2008/10/25/bpmn-bpel-in-perspective/
46. BPEL-Grail. [электронный ресурс]/ Keith Swenson, 2008  // http://kswenson.wordpress.com/2008/10/24/bpel-grail/
47. Is XPDL the Silent Workhorse of BPM? [электронный ресурс]  // http://www.ebizq.net/topics/bpm/features/7852.html
48. Самуйлов К.Е. Бизнес-процессы и информационные технологии в управлении телекоммуникационными компаниями / К.Е. Самуйлов, А.В. Чукарин, Н.В. Яркина. – М.: Альпина Паблишерз, 2009. – 442 стр.
49. Workflow Management Coalition Workflow Standard.  Process Definition Interface — XML Process Definition Language [электронный ресурс]/ Workflow Management Coalition, 2008 // http://www.wfmc.org/index.php?option=com_docman&task=doc_download&Itemid=72&gid=132
50. XPDL Implementations  [электронный ресурс]  // http://www.wfmc.org/xpdl-implementations.html
51. BPMN and XPDL [электронный ресурс]/ Dr. Sebastian Stein, 2008  // http://www.ariscommunity.com/users/sstein/2008-05-21-bpmn-and-xpdl
52. Why XPDL is Essentially Useless [электронный ресурс] / Ismael Ghalimi, 2008  // http://itredux.com/2008/11/21/why-xpdl-is-essentially-useless/
53. Is XPDL Going to Become a Dominant Process Standard? [электронный ресурс] / Scott Francis, 2009  // http://www.bp-3.com/blogs/2009/04/is-xpdl-going-to-become-a-dominant-process-standard/
54. Searching for BPMN / XPDL Incompatibility [электронный ресурс]/ Keith Swenson, 2009    // http://kswenson.wordpress.com/2009/04/20/searching-for-bpmn-xpdl-incompatibility/
55. The Diagram IS the Meaning  [электронный ресурс] / Keith Swenson, 2007 // http://kswenson.wordpress.com/2007/03/25/the-diagram-is-the-meaning/
56. BPEL, XPDL and BPMN [электронный ресурс]  // http://social.msdn.microsoft.com/Forums/en-US/architecturegeneral/thread/b8692bd8-5c32-47e8-96f8-46c33210ee99/
57. On BPMN, BPEL and XPDL – Part II [электронный ресурс]  // http://www.primatek.ca/blog/2008/11/24/on-bpmn-bpel-and-xpdl-–-part-ii/
58. Майкл Хаммер. Реинжиниринг корпорации. Манифест революции в бизнесе. / Майкл Хаммер, Джеймс Чампи. ­­– М. : Манн, Иванов и Фербер, 2007 г. – 288 стр.
59. Белайчук А. Зачет по BPM / А. Белайчук // Открытые системы. 2006. Вып. 1. с. 19-20
60. The Role of Business Process Management in SOA [электронный ресурс] / Sandy Carter, 2007  // http://www.information-management.com/issues/20070501/1082553-1.html
61. Model Portability in BPMN 2.0 [электронный ресурс]/ Bruce Silver, 2009    // http://www.brsilver.com/wordpress/2009/03/04/model-portability-in-bpmn-20-2/
62. Business Process Model and Notation (BPMN). FTF Beta 1 for Version 2.0 [электронный ресурс]  // http://www.omg.org/cgi-bin/doc?dtc/09-08-14
63. BPMN 2.0 takes dancing lessons – do we need choreographies? [электронный ресурс] / Gero Decker, 2008 // http://www.bpmn.info/2008/10/15/bpmn-20-takes-dancing-lessons-do-we-need-choreographies/

Методология описания бизнес-процессов | Глоссарий ПитерСофт

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

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

К ключевым стандартам описания бизнес-процессов относят DFD (Построение диаграмм потоков данных) и WFD (Построение диаграммы потоков работ).

На диаграмме потоков данных (методология DFD) отображаются выполняемые в ходе процесса работы (функции), и для каждой из них определяются входы и выходы. В качестве входных и выходных данных бизнес-процесса выступают его информационные и материальные ресурсы. В программном продукте «ПитерСофт: Управление процессами» для обозначения входов и выходов конкретной задачи бизнес-процесса используются реквизиты процесса.

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

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

Таким образом, описание бизнес-процесса может быть представлено упорядоченным набором DFD и WFD-диаграмм. Указанные методологии, кроме того, могут применяться для описания как дерева, так и сети бизнес-процессов компании.

Бизнес процессы и стандарты управления

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

Стандарты автоматизации бизнес-процессов

Стандарты управления бизнес-процессами

Важная цель автоматизации – повысить качество исполнения процессов. Современные автоматизированные процессы отличаются более стабильной работой, чем те, которые выполняются в ручном режиме.

Цели автоматизации выделенных бизнес процессов на предприятии:

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

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

Стандарты управления бизнес-процессами

Business Process Management System (BPMS)

BPMS, Business Process Management System — современная система, предназначенная для удобного управления бизнес-процессами. Идея в том, чтобы взять описание бизнес-процесса, отследить его выполнение с применением специализированной программы. Описания создаются сотрудниками компании или приглашенными специалистами по реинжинирингу.

Автоматизация бизнес-процессов малого предприятия или большой компании выполняется при помощи разработки или приобретения прикладного ПО. Однако при внедрении такой системы следует учитывать определенные нюансы. BPM-программа автоматизирует лишь часть шагов процесса. Также необходимость внести изменения в ПО для Business Process Management System означает перепрограммирование, связанное со значительными затратами времени.

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

Для BPMS (Business Process Management System) любое описание бизнес-процесса создается на языке, который исполняется программой BPM.

Виды систем автоматизации

Тип системы	Описание
Неизменяемая	Последовательность действий определяется конкретными факторами (конфигурация оборудования, условия процесса). Не изменяется в ходе работы.
Программируемая	Последовательность действий можно изменять, исходя из конфигурации процесса, заданной программы. Существует набор инструкций, который интерпретируется системой, по выбору последовательности действий.
Гибкая (самонастраиваемая)	Программа может выбирать требуемые действия во время работы системы. Конфигурация процесса выполняется на основе полученных данных о ходе текущего процесса.

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

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

Определение

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

1. Это совокупность взаимосвязанных мероприятий или работ, нацеленных на создание конкретного товара или услуги для потребителей. Проще говоря, это любая логическая последовательность действий, которая стабильно зациклена и приводит к определенной конечной цели, поставленной перед компанией. Важно уточнить, что коммерческая составляющая не является обязательным элементом в этом вопросе. К примеру, процессы контакта между сотрудниками внутри предприятия (отпуск, перевод, увольнение и т.д.) также могут относиться к бизнес-процессам.
2. Это логическая последовательность человеческих действий (или группы лиц) в рабочем коллективе. Целью его описания является анализ и регламентация определенных событий в штате работников.

Именно последнему определению стоит уделить внимание. В этом описании бизнес-процессов компании делается акцент на сотрудниках и коллективе. Это обосновывается следующим.

• Человек принимает участие в любом бизнес-процессе. Если работа выполняется в полностью автоматизированном режиме (при помощи различных ПО или систем оптимизации), то это не более, чем технологический прогресс. В таком случае используются другие стандарты, способы и нюансы реализации.
• Обязательное задействование нескольких людей в открытой или скрытой форме. Даже при наличии одного работника (к примеру, художник), у него в любом случае есть клиенты (картинные галереи) и потребители (покупатели). Помимо этого, продавец не осуществляет трудовую деятельность в «вакууме» — у него есть множество лиц, которые принимают определенное участие в развитии его труда.

Описание

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

№	Шаг	Начало	Ответственный	Действие №1	Действие №2	Результат
1	Звонок клиента	Входящий звонок	Оператор контакт-центра	Поиск клиента по номеру телефона или Ф.И.О.	Регистрация новой карточки (если нет записи)	Идентификация клиента или регистрация новой карты
2	Проверка товарного наличия	Клиентский заказ	Оператор контакт-центра Сотрудник складского помещения	Проверка наличия по базе данных, уточнение у работника склада	Озвучивание наличия, текущей цены, способов и сроков доставки	Переход к презентации товара или к ожиданию его поступления
3	Презентация товара	Заказ клиента + товар в наличии	Оператор контакт-центра Технический специалист	Проведение презентации, озвучка главных характеристик, ответы на вопросы клиента	Перевод в продажу, перевод в возвращение, отказ от продажи	Переход на этап оформления или завершения бизнес-процесса
4	Оформление заказа	Подтверждение заказа от клиента	Оператор контакт-центра Сотрудник склада	Резерв товара на складе, оформление заявки на доставку, подготовка документации	Оповещение клиента о примерном или точном времени доставки	Окончание оформления и передача в службу доставки

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

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

Готовые решения для всех направлений

Мобильность, точность и скорость пересчёта товара в торговом зале и на складе, позволят вам не потерять дни продаж во время проведения инвентаризации и при приёмке товара.

Узнать больше

Ускорь работу сотрудников склада при помощи мобильной автоматизации. Навсегда устраните ошибки при приёмке, отгрузке, инвентаризации и перемещении товара.

Узнать больше

Обязательная маркировка товаров — это возможность для каждой организации на 100% исключить приёмку на свой склад контрафактного товара и отследить цепочку поставок от производителя.

Узнать больше

Скорость, точность приёмки и отгрузки товаров на складе — краеугольный камень в E-commerce бизнесе. Начни использовать современные, более эффективные мобильные инструменты.

Узнать больше

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

Узнать больше

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

Узнать больше

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

Узнать больше

Первое в России готовое решение для учёта товара по RFID-меткам на каждом из этапов цепочки поставок.

Узнать больше

Получение сертифицированного статуса партнёра «Клеверенс» позволит вашей компании выйти на новый уровень решения задач на предприятиях ваших клиентов..

Узнать больше

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

Узнать больше

Используй современные мобильные инструменты в учете товара и основных средств на вашем предприятии. Полностью откажитесь от учета «на бумаге».

Узнать больше Показать все решения по автоматизации

Из чего состоят и какие бывают бизнес-процессы

Сегодня существует 2 основные классификации: расширенная и упрощенная. Каждая из них имеет свои особенности и отличительные черты. К первой относятся такие процессы:

1. Основные — направлены на предоставление товаров или услуг, которые являются предпочтительными объектами компании и ответственны за получение прибыли.
2. Сопутствующие — нужны для создания товаров или услуг, которые служат следствием основной предпринимательской деятельности и обеспечивают заработок.
3. Вспомогательные — применяются для реализации главных процессов и поддержания их специфических черт.
4. Обеспечивающие — необходимы для нормального функционирования прочих процессов и нацелены на поддержание их универсальных характеристик.
5. Управление — одновременно охватывают несколько управляющих функций на всех уровнях. Это дальновидное, быстрое и нынешнее планирование, формирование и реализация воздействиия управления.
6. Развитие — улучшение создаваемого товара или услуги, оснащения, улучшение оборудования.

Упрощенные составляющие бизнес-процесса делят на: управляющие, основные и вспомогательные.

Подробная классификация процессов	Простая классификация
Основные  Сопутствующие	Основные
Вспомогательные  Обеспечивающие	Вспомогательные
Управляющие  Процессы развития	Управляющие

История появления термина

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

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

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

Выделяют 3 главные характеристики: цена, продолжительность, удовлетворенность потребителя товаром или услугой. Более подробная информация будет представлена в таблице, расположенной ниже.

Длительность	Стоимость	Удовлетворенность
Чем выше скорость выполнения процесса, тем лучше продуктивность предприятия. Но важно помнить, что качество результата должно соответствовать высокому показателю с меньшими временными затратами. Для их снижения времени выполнения процесса применяются разные технические и IT-методы, ускоряющие бизнес.	Стоимость выполнения бизнес-процесса должна стремиться к минимуму. Этот подход относится как к производственному процессу, так и к предоставлению услуг. Фирма, оптимизирующая и снижающая цену, имеет значительно больший заработок.	Результатом бизнес-процесса является продукт. От качества финального результата зависит успех предприятия и лояльность клиентской базы. Нужно собирать обратную связь для уличения контроля качества.

Главные задачи

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

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

Отличие бизнес-процесса от технологического

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

Для лучшего понимания приведем наглядный пример технологического процесса:

1. Взять заготовку А.
2. Соединить ее с Б.
3. Обработать под параметром Г.
4. Получить готовый продукт.

Все действия достаточно однозначны и отсутствуют так называемые «вилки».

Пример внутреннего бизнес-процесса в компании выглядит следующим образом:

1. Получение вводных данных А. После этого возможны 2 исхода: переход на следующий этап — при соответствии данных условию Б — выполнение действия Г (при несоответствии условию В).
2. Передача результата на выход.

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

Зачем моделировать бизнес-процессы

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

1. Изучение предпринимательской деятельности. Графические изображения (схемы) дают возможность быстро ознакомиться с рабочими нюансами предприятия и найти ее наиболее уязвимые места.
2. Наглядность. Не зря говорят, что «1 картинка стоит 1000 слов». Схематическая визуализация значительно сокращает время понимания сути проблемы, а также дает возможность дать оценку предложенным путям их решения. Бизнес-консультант должен максимально детально объяснить клиенту все возможные варианты, однако не меньшей важность служит обратная связь. Вторая сторона должна увидеть и понять слабые стороны еще на стадии обсуждения, за счет чего удастся избежать неприятных сложностей и внесения коррективов «на ходу».

Как описывать

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

1. Оптимальный цикл действий состоит из следующих этапов:
2. Сбор участников (рабочий штат), входящих сведений, применяемых для старта.
3. Применяемые системы.
4. Определение желаемого результата.
5. Выбор последовательности, выполняемой работником.
6. Вычленение условий.
7. Описание информации в графическом виде.

Готовые решения для всех направлений

Мобильность, точность и скорость пересчёта товара в торговом зале и на складе, позволят вам не потерять дни продаж во время проведения инвентаризации и при приёмке товара.

Узнать больше

Ускорь работу сотрудников склада при помощи мобильной автоматизации. Навсегда устраните ошибки при приёмке, отгрузке, инвентаризации и перемещении товара.

Узнать больше

Обязательная маркировка товаров — это возможность для каждой организации на 100% исключить приёмку на свой склад контрафактного товара и отследить цепочку поставок от производителя.

Узнать больше

Скорость, точность приёмки и отгрузки товаров на складе — краеугольный камень в E-commerce бизнесе. Начни использовать современные, более эффективные мобильные инструменты.

Узнать больше

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

Узнать больше

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

Узнать больше

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

Узнать больше

Первое в России готовое решение для учёта товара по RFID-меткам на каждом из этапов цепочки поставок.

Узнать больше

Получение сертифицированного статуса партнёра «Клеверенс» позволит вашей компании выйти на новый уровень решения задач на предприятиях ваших клиентов..

Узнать больше

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

Узнать больше

Используй современные мобильные инструменты в учете товара и основных средств на вашем предприятии. Полностью откажитесь от учета «на бумаге».

Узнать больше Показать все решения по автоматизации

Правила описания бизнес-процесса: что это такое

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

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

Схема бизнес-процесса

Распространенные мифы и ошибочные мнения

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

1. Самодеятельность — это успех. Подобное решение потребует создания своих обозначений и стандартов, что сильно замедляет работу и снижает шансы на достижение нужной цели.
2. Описание бизнес-процесса предприятия и IT-системы не имеет отличий. В реальности у них есть ряд особенностей, которые крайне важно учитывать.
3. Обязательно должна появиться прибыль. Не все бизнесы ведут прямые продажи, которые и влияют на видимый показатель дохода. Некоторые виды деятельности невозможно оценить по этому критерию. Более того, процессоориентированный подход, прежде всего, внедряется для получения высокой производительности при предыдущих инвестициях.
4. Можно создать идеал. Не стоит надеяться на разработку безукоризненного плана, гарантирующего отсутствие даже малейших ошибок или сложностей, которые достаточно часто возникают по мере продвижения к конечной цели. Даже гениальному специалисту с многолетним опытом не получится охватить весь материал сразу, поэтому он в любом случае будет содержать небольшие недочеты, которые будут своевременно и эффективно решаться при совместной заинтересованности обеих сторон.

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

Упростить и оптимизировать различные бизнес-процессы помогут продукты от компании «Клеверенс».

Количество показов: 48996

Стандарты и методологии моделирования бизнес-процессов. Управление основной деятельности риэлторской фирмы

Выполнил: студент группы 03-431 Степанов М.Д.

Московский авиационный институт (Государственный технический университет)

Москва, 2009 .

Введение

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

Целью моделирования является систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации.

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

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования), семейство стандартов IDEF (Icam DEFinition, где Icam — это Integrated Computer-Aided Manufacturing) и алгоритмические языки. Основные типы методологий моделирования и анализа бизнес-процессов:

Моделирование бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-процессов – стандарт IDEF0. Модели в нотации IDEF0 предназначены для высокоуровневого описания бизнеса компании в функциональном аспекте.

Описание потоков работ (Work Flow Modeling). Стандарт IDEF3 предназначен для описания рабочих процессов и близок к алгоритмическим методам построения блок-схем.

Описание потоков данных (Data Flow Modeling). Нотация DFD (Data Flow Diagramming), позволяет отразить последовательность работ, выполняемых по ходу процесса, и потоки информации, циркулирующие между этими работами.

Прочие методологии.

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

Сущность и значение моделирования бизнес-процессов

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

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

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

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

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

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

моделирование бизнес-процессов — это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности;

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

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

Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы, создаёт ценность и выдаёт результат. В международном стандарте ISO 9000:2000 принят термин «процесс», однако в настоящее время эти термины можно считать синонимами. Среди основных причин, побуждающих организацию оптимизировать бизнес-процессы, можно выделить необходимость снижения затрат или длительности производственного цикла, требования, предъявляемые потребителями и государством, внедрение программ управления качеством, слияние компаний, внутриорганизационные противоречия и др. .

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 — Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

изменение организационной структуры;

оптимизацию функций подразделений и сотрудников;

перераспределение прав и обязанностей руководителей;

изменение внутренних нормативных документов и технологии проведения операций;

новые требования к автоматизации выполняемых процессов и т. д.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

существующая организационная структура;

документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;

структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

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

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

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

Детальная модель бизнес-процесса должна включать:

набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

диаграммы взаимодействия, отражающие схемы документооборота.

Модели должны быть согласованы с ведущими специалистами организации, обладающими необходимыми знаниями.

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

1.2 История развития методологий моделирования бизнес-процессов

Основу многих современных методологий моделирования бизнес-процессов составили методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения.

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

 Рисунок 2 — История развития методологий моделирования бизнес-процессов

1.3 Современные методологии описания бизнес-процессов

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

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

На самом деле, несмотря на свое различие, в основном связанное с названием диаграмм и видов используемых объектов современные методологии описания бизнес-процессов практически идентичны и представляют из себя незначительные видоизменения двух классических схем — DFD и WFD – Work Flow Diagram, которые были рассмотрены.

Давайте рассмотрим другие современные языки описания бизнес-процессов:

IDEF0;

DFD в нотациях Гейна-Сарсона и Йордана-Де Марко;

IDEF3;

Oracle;

BAAN;

ARIS.

Swimmer lanes;

1.4 Методология IDEF0

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

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

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

Четыре типа объектов, применяемых для описания входов и выходов в стандарте IDEF0, в английском варианте образуют сокращение ICOM и на схеме IDEF0 размещаются в строго отведенных местах относительно работ, которые называются функциональными блоками (Таблица 1).

Таблица 1. Название и размещение входов и выходов в стандарте IDEF0 относительно функционального блока.

Давайте рассмотрим пример бизнес-процесса «Выточить деталь», который выполняет токарь. Входом процесса является заготовка из которой вытачивается деталь – она физически преобразуется в процессе. Для того, что бы токарь начал точить деталь ему нужно дать задание или план. Также ему понадобится чертеж с размерами детали. Так вот, чертеж, задание или план нужны для реализации бизнес-процесса и процесс без них не начнется, но по ходу выполнения процесса они не преобразуются. Согласно стандарту IDEF0 их относят к управлению. Для того, что бы выточить деталь нужен токарь, нужен станок – их относят к механизмам. Выходами или результатами бизнес-процесса является деталь (рис. 3).

Рис.3. Стандарт описания бизнес-процесса IDEF0.

Стандарт IDEF0 получил большое распространение в США и активно используется в России. Ввиду того, что в стандарте IDEF0 появилась дополнительная аналитика по сравнению с классическим стандартом DFD, схемы бизнес-процессов получаемые при описании в стандарте IDEF0 выглядят более сложными с точки зрения менеджеров компании, в виду ограниченного наличия у них свободного времени. Данная сложность часто приводит к тому, что менеджеры, особенно высшего уровня, которые должны принимать активное участие в проекте по описанию и оптимизации деятельности компании, «отказываются» от работы с IDEF0. В данном случае IDEF0 — является излишне информационно насыщенным и сложным стандартом.

Второй недостаток стандарта IDEF0 связан с тем, что он дает больше поводов и возможностей сторонникам сопротивлений изменениям притормозить проект по описанию и оптимизации бизнес-процессов и дискредитировать его идею. Это также связано с усложненной аналитикой стандарта IDEF0, которая часто дает повод задуматься и задавать следующие вопросы: «А правильно ли, что этот объект отнесен ко входу? Может его отнести к управлению?»

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

Практика показала, что стандарт IDEF0 целесообразно использовать в проектах по описанию и оптимизации локальных бизнес-процессов, в небольших проектах в которых больше участвуют и принимают решения специалисты предметных областей, а руководители высшего уровня привлекаются для принятия решений по минимуму. На рис. 4 приведена диаграмма IDEF0 верхнего уровня бизнес-процесса «Увольнение сотрудника».

Рис. 4. Диаграмма IDEF0 верхнего уровня бизнес-процесса «Увольнение сотрудника».

1.5 Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Марко

Следующий стандарт описания бизнес-процессов, который получил распространение, был разработан на основе развития классической методологии DFD. Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна Сарсона, вторая нотацией Йордона-Де Марко.

Гейн Сарсон, предложил классическую DFD-схему немного усложнить. Он предложил ввести дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых хранится информация, либо материальные ресурсы. Примерами таким мест являются архив, в котором хранятся документы, база данных, в которой хранится информация, либо склад, на котором хранятся материальные ресурсы. Данный объект получил название — хранилище данных. На DFD-схемах в нотациях Гейна-Сарсона и Йордона-Де Марко также используются объекты, с помощью которых показывают внешних субъектов, с которыми бизнес-процесс взаимодействует. Данные объекты называют внешними сущностями. На рис. 5 приведен пример DFD-схемы бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении», разработанной в нотации Гейна-Сарсона.

Рис. 5. DFD-схема бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении» в нотации Гейна-Сарсона.

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

Вторая нотация Йордона-Де Марко методологии DFD была названа в честь разработавшего ее специалиста Йордона-Де Марко. В первом приближении эта нотация аналогична нотации Гейна Саросна, за исключение форм объектов: для описаний операций бизнес-процесса вместо закругленных прямоугольников стали использоваться круги, немного видоизменились и другие объекты – хранилище данных и внешние сущности (рис. 6).

Рис. 6. DFD-схема бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении» в нотации Йордона-Де Марко.

В таблице 2 приведены названия, обозначения и смыл элементов, используемых при построении DFD-схемы бизнес-процесса в нотациях Гейна-Сарсано и Йордона-Де Марко.

Таблица 2. Элементы методологии DFD в нотацияхГейна-Сарсано и Йордона-Де Марко.

1.6 Методология IDEF3

Стандарт IDEF0, который был рассмотрен ранее является развитием классического DFD – подхода и предназначен для описания бизнес-процессов верхнего уровня. Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.

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

Рис. 7. Схема бизнес-процесса в стандарте IDEF3.

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

Таблица 3. Типы связей между работами в стандарте IDEF3.

Помимо наличия нескольких типов связей между работами в стандарте IDEF3 логические операторы, которые в данном случае называются перекрестками также делятся на несколько типов: «Исключающий ИЛИ», «И» и «ИЛИ».

Перекресток «Исключающий ИЛИ» обозначает, что после завершения работы «A» (рис. 8), начинает выполняться только одна из трех расположенных параллельно работ B, С или D в зависимости от условий 1, 2 и 3. Перекресток «И» обозначает, что после завершения работы «A», начинают выполняться одновременно три параллельно расположенные работы B, С и D. Перекресток «ИЛИ» обозначает, что после завершения работы «A», может запуститься любая комбинация трех параллельно расположенных работ B, С и D. Например может запуститься только одна из них, могут запуститься три работы, а также могут запуститься двойные комбинации В и С, либо C и D, либо B и D. Перекресток «Исключающий ИЛИ» является самым неопределенным, так как предполагает несколько возможных сценариев реализации бизнес-процесса и применяется для описания слабо формализованных ситуаций.

Рис. 8. Применение перекрестков «Исключающий ИЛИ», «И» и «ИЛИ» — схемы расхождения.

Перекрестки «И» и «ИЛИ» подразделяются еще на два подтипа – синхронные и асинхронные. Перекрестки синхронного типа обозначают, что работы В, С и D запускаются одновременно после завершения работы A. Перекрестки асинхронного типа требований к одновременности не предъявляют.

Приведенные на рис. 5 схемы взаимосвязи работ и перекрестков называются схемами расхождения, так как от перекрестков расходятся несколько работ. Существует и другие схемы взаимосвязи перекрестков и работ – это так называемые схемы схождения, когда к перекрестку подходит несколько работ (рис. 9).

Рис. 9. Применение перекрестков «Исключающий ИЛИ», «И» и «ИЛИ» — схемы схождения.

В таблице 4 приведены обозначения, названия и смысл всех типов перекрестков как в схемах схождения, так и в схемах расхождения.

Таблица 4. Обозначения, названия и смысл типов перекрестков в схемах схождения и расхождения.

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

1.7 Методология ORACLE

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

Три наиболее крупных разработчика информационных систем: SAP/R3, BAAN и ORACLE для повышения эффективности внедрения своих информационных систем разработали свои стандарты и программные продукты, с помощью которых описывается бизнес-деятельность компании. Каждый из этих стандартов содержит несколько бизнес-моделей, с помощью которых описываются бизнес-процессы, организационная структура, а также строятся прочие бизнес-модели.

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

Таблица 5. Модели методологии ORACLE.

При описании бизнес-процессов с использованием методологии ORACLE наиболее часто применяется вторая согласно перечню таблицы 5 модель бизнес-процессов. Построение этой модели основано на подходе «Swimmer lanes», который представляет из себя смесь классических DFD и WFD стандартов и имеет одну отличительную особенность. Диаграмма, на котором рисуется схема бизнес-процесса разделена по горизонтали на дорожки. Каждая дорожка принадлежит определенному структурному подразделению или должности, участвующей в бизнес-процессе. Те операции бизнес-процесса, которые выполняются этим структурным подразделением, размещаются в зоне соответствующей дорожки. Такой подход позволяет наглядно показать распределение ответственности в бизнес-процессе и продемонстрировать степень его организационной фрагментарности (рис. 10).

Рис. 10. Пример описания бизнес-процесса «Торговля чаем» для функциональной организационной структуры компании «Эврика».

Одним из недостатков формата «Swimmer lanes» является то, что в данном случае более трудно отследить временную последовательность работ, а так же критический путь бизнес-процесса, что актуально при проведении временной оптимизации.

1.8 IDEF1X

IDEF1X — методология описания данных. Применяется для построения баз данных.

IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу «AS IS», тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

1.7.1 Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Ниже, на рисунке, приведен ряд примеров связи между сущностями:

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. На рисунке 2 приведен пример IDEF1X диаграммы.

1.7.2 Преимущества IDEF1X

Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком ER.

1.9 IDEF4

IDEF4 — объектно-ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектно-ориентированных языках (например С++). Пока, на мой взгляд, широкого распространения не нашла. Более широко сейчас используется UML.

1.10 SADT

SADT — методология структурного анализа и проектирования (Structured Analysis and Design Technique). Основана на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители. Возникла в конце 60-х годов.

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

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

1.11 ARIS

Методология ARIS

Одной из современных методологий бизнес-моделирования, получившей широкое распространение в России является методология ARIS, которая расшифровывается как Architecture of Integrated Information Systems — проектирование интегрированных информационных систем. Ее использует программное средство ARIS Toolset

Методология ARIS на данный момент времени является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации. Часть моделей методологии ARIS используются в настроечном модуле интегрированной информационной системы SAP/R3, который применяется при внедрении системе и ее настройке на деятельности компании. В виду большого количества бизнес-моделей методология ARIS делит их на четыре группы (рис. 11):

Группа «Оргструктура».

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

Группа «Функции».

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

Группа. «Информация».

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

Группа «Процессы».

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

Рис. 11. Группы моделей методологии ARIS.

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

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

Например, материальные и информационные потоки на процессных схемах обозначаются разными по форме и цвету объектами, что позволяет быстро определить тип потока.

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

В общем случае практика показала, что в проектах наиболее часто используются модели, приведенные в таблице 6.

Таблица 6. Наиболее часто используемые на практике модели методологии ARIS.

Модель «Диаграмма целей» — OD применяется для описания стратегических целей компании, их иерархической упорядоченности, а также связей целей с продуктами и услугами, производимыми компанией и бизнес-процессами, поддерживающими их производство (рис. 12)

Рис. 12. Модель «Диаграмма целей» — OD/ARIS.

Модель «Дерево продуктов и услуг» — PST применяется для описания продуктов и услуг, производимых в компании, а также и связи со стратегическими целями компании, бизнес-процессами, поддерживающими их производство (рис. 13).

Рис. 13. Модель «Дерево продуктов и услуг — PST/ARIS».

Модель «Дерево функций» — FT описывает функции, выполняемые в компании и их иерархию. Данная модель часто применяется для для построения дерева бизнес-процессов компании (рис. 14).

Рис. 14. Модель «Дерево функций» — PST/ARIS.

Модель «Диаграмма окружения процесса» — FAT позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов (рис. 15).

Рис. 15. Модель «Диаграмма окружения процесса» — PST/ARIS.

Модель «Диаграмм цепочки добавленной стоимости» — VACD является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Дополнительным отличием данной и других процессных моделей является то, что информационные и материальные потоки на схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. На модели VACD методологии ARIS в отличие от классического подхода также используется логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характерно для классического подхода WFD. (рис. 16).

Рис. 16. Модель «Расширенная цепочка процессов, управляемая событиями» — eEPC/ARIS.

Модель «Матрица выбора процесса» — PSM является прототипом классического DFD-стандарта и используется как альтернатива для модели VACD. Матрица выбора процессов по отношению к диаграмме цепочки добавленной стоимости является с одной стороны более упрощенным вариантом описания процесса, с другой стороны данная модель содержит дополнительные объекты, позволяющие показать другие аспекты бизнес-процесса. Простота матрицы выбора бизнес-процессов связана с тем, что на данной модели не показываются информационные и материальные потоки. Что касается других аспектов, то данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения бизнес-процесса, который описывается. Соответственно матрицу выбора процессов целесообразно применять вместо диаграммы цепочки добавленной стоимости в случаях, когда описываемый бизнес-процесс имеет несколько вариантов исполнения, каждый из которых ложится базовую схему. Пример применения матрицы выбора процессов для описания деятельности компании «Эврика», имеющий функциональную организационную структуру показан на рис. 17.

Рис. 17. Модель «Матрица выбора процессов» — PSM/ARIS.

Модель «Extended event driven Process Chain» — eEPC является прототипом классического WFD-стандарта и используется для описания бизнес-процессов нижнего уровня. Дополнительным отличием eEPC-модели от классической WFD-схемы является наличие на модели объекта, который называется событием. С помощью событий изображается факт, время или событие инициирующие начало выполнения работ процесса, а также факт или время их завершения (рис. 18).

Рис. 18. Модель «Расширенная цепочка процессов, управляемая событиями» — VACD/ARIS.

Модель «Организационная структура» — ORG используется для описания организационной структуры компании. На данной модели изображаются структурные подразделения, группы, должности, роли и прочие элементы организационной структуры и связи между ними (рис. 19).

Рис. 19. Модель «Организационная структура» — ORG/ARIS.

Модель «Диаграмма типов информационных систем» — ASTD используется для описания структуры информационных систем, используемых в компании. На данной модели показываются типы и модули информационных систем, программные продукты, взаимосвязь между ними и бизнес-процессами организации, которые они автоматизируют (рис. 20).

Рис. 20. Модель «Диаграмма типов информационных систем» — VACD/ASTD.

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

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

1.12 Методология, применяемая консалтинговыми компаниями

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

Модель верхнего уровня и принципы ее построения представлена на рис. 21.

Рис. 21. Модель описания бизнес-процессов верхнего уровня, применяемая консалтинговыми компаниями.

Модель бизнес-процессов нижнего уровня, использующая подход «Swimmer lanes» представлена на рис. 22.

Рис. 22. Модель описания бизнес-процессов нижнего уровня, применяемая консалтинговыми компаниями.

1.13 Методология Betec (©)

На основе применения различных современных методологий описания бизнес-процессов в российских компаниях, консалтинговая компания «Бизнес — инжиниринговые технологии» разработала методологию описания деятельности, компании, воплотившую в себя наилучшие элементы рассмотренных выше методологий. Данная методология, называемая Betec (©), состоит из моделей, с помощью которых описывают бизнес-деятельность компании и которые условно сгруппированы в следующие разделы:

Стратегия;

Бизнес-процессы;

Оргструктура;

Финансы;

Персонал;

Маркетинг.

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

процессы» и «Оргструктура».

Таблица 7. Модели методологии Betec (©) соответствующие разделам «Бизнес-процесс» и «Оргструктура».

Модель «Дерево бизнес-направлений» применяется для описания бизнес-направлений, реализуемых в компании и их взаимосвязь с другими элементами организации (рис. 23).

Рис. 23. Модель «Дерево бизнес-направлений» — Betec (©).

Модель «Дерево бизнес-процессов» описывает бизнес-процессы, выполняемые в компании и их иерархию (рис. 24). На верхнем уровне дерева бизнес-процессы делятся на три группы: основные, обеспечивающие и управленческие.

Рис. 24. Модель «Дерево бизнес-процессов» — Betec (©).

Модель «Диаграмм окружения процесса» позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов (рис. 25).

Рис.25. Модель «Диаграмма окружения процесса» — Betec (©).

Модель «Дерево информационных потоков» позволяет описать и классифицировать информационные потоки компании, которые представляют из себя информацию, размещенную на бумажных носителях, устную информацию либо информацию в электронном виде. Во многих проектах по описанию бизнес-процессов, также приходится описать внутреннюю структуру информационных потоков. Для решения этой задачи, удобным с практической точки зрения, является подход, когда структура информации описывается в виде документа MS Word, после чего на схеме дерева информационных потоков показывается соответствие между элементами дерева и разработанными документами (рис. 26).

Рис. 26. Модель «Дерево информационных потоков» — Betec (©).

Модель «Дерево материальных потоков» позволяет описать и классифицировать материальные потоки компании, которые представляют из себя сырье, полуфабрикаты, готовую продукцию и т.д. (рис. 27).

Рис. 27. Модель «Дерево материальных потоков» — Betec (©).

Модель «Дерево организационной структуры» используется для описания организационной структуры компании. На данной модели изображаются структурные подразделения, должности, а также связи линейного и функционального подчинения (рис. 28).

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

Рис. 28. Модель «Дерево организационной структуры» — Betec (©).

Модель «Дерево информационной систем» используется для описания структуры информационных систем, используемых в компании. На данной модели показываются типы информационных систем применяемых в компании, описывается их модульная структура, а также перечисляется программное обеспечение, используемое в компании при выполнении бизнес-процессов. (рис. 29).

Рис. 29. Модель «Дерево информационной системы» – — Betec (©).

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

В случае если в проекте была описана внутренняя структура информационных потоков, то на схеме процесса показывается соответствие между элементами информационных потоков и документами в формате MS Word, описывающих внутреннюю структуру информации (рис. 30).

Рис. 30 Модель «Диаграмма процесса — DFD» – — Betec (©).

Модель «Диаграмма процесса — WFD» является прототипом классического WFD–стандарта и используется для описания бизнес-процессов нижнего уровня. При построении диаграммы процесса – WFD описываются работы, из которых состоит бизнес-процесс, а также используются элементы организационной структуры, информационных систем, материальных и информационных потоков, которые были описаны при построении бизнес-моделей, рассмотренных выше.

В случае если в проекте была описана внутренняя структура информационных потоков, то на схеме процесса показывается соответствие между элементами информационных потоков и документами в формате MS Word, описывающих внутреннюю структуру информации (рис. 31).

Рис. 31 Модель «Диаграмма процесса — WFD» – — Betec (©).

1.14 Методология BAAN

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

Таблица 8. Модели методологии BAAN.

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

Модель метаструктуры предприятия – ESM применяется для описания географически распределенной организационной структуры предприятия, описывает географические подразделения компании (офисы, филиалы, пр.), а также материальные и информационные потоки между ними. Данная бизнес-модель по своей сути напоминает классический DFD- стандарт, в котором на разрабатываемой схеме вместо работ, показываются структурные подразделения и взаимодействия между ними (рис. 32)

Рис. 32. Модель метаструктуры предприятия – ESM / BAAN.

Структурные подразделения компании, изображенные на модели метаструктуры предприятия – ESM декомпозируется на модель управления – BCM, на которой показываются бизнес-процессы данного структурного подразделения, а также материальные и информационные потоки протекающие между ними. Модель управления – BCМ полностью соответствуют классической DFD-схеме и она применяется для описания бизнес-процессов верхнего уровня (рис. 33).

Рис. 33. Модель управления – BCM / BAAN.

Процессы с модели управления – BCM декомпозируются на модель управления – BCM более низкого уровня в случае, если они глобальны и могут быть представлены в виде временной последовательности работ. В противном случае они декомпозируются на модели бизнес-процессов – BPM, которые применяются для описания бизнес-процессов нижнего уровня и практически соответствуют классической WFD-схеме, за исключением двух особенностей. Первая – блоки принятия решений на модели бизнес-процессов BPM называются управляющими работами и вторая особенность связана с наличием на модели элементов, называемых состоянием, с помощью которых описываются состояния, характеризующие начало и окончания каждой работы. Данный подход, связанный с описанием состояний заимствован из подхода к описанию бизнес-процессов, который называется «Сети Петри» (рис. 34).

Рис. 34. Модель бизнес-процессов – BPM / BAAN.

При описании деятельности компании методология BAAN также использует модель функций – BFM, при помощи которых строится дерево функций компании (рис. 35).

Рис. 35. Модель функций – BFM / BAAN.

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

Рис. 36. Модель организационной структуры – BOM / BAAN.

Последняя информационная модель — ERM методологии BAAN имеет тип «Сущность-Связь» и предназначена для описания структуры информации, используемой при реализации бизнес-процессов. С помощью данной модели проектируется базы данных (рис. 37).

Рис. 37. Информационная модель – ERM / BAAN.

Аналитический раздел

Объект управления: Риэлторская компания (Корпорация «Инком-Недвижимость»). Основные направления деятельности компании – создание пригородных жилых комплексов малой и средней этажности, а также осуществление сделок с жилой и коммерческой недвижимостью в Московском регионе, Кирове и Красноярске. Одним из главных условий успешного бизнеса риэлторской компании, является хороший подбор персонала. Так как именно высококлассные специалисты обеспечивают высокую прибыль компании. Набор персонала, увольнение, смена должности, обучение персонала – эти процессы, являются такими же важными, как и процессы связанные с не посредственной деятельностью компании.

Риэлторские компании имеют максимально простую организационную структуру в форме головного офиса и дополнительных региональных офисов, что не несет организационные факторы риска и несущественно влияет на деятельность компаний. Для риэлторских компаний более значимым являются отраслевые факторы риска и операционные риски. В состав Инком-недвижимости входят 31 офис в Москве и региональные представительства в Красноярске, Алма-Ате, Кирове. Управление и структура агентства недвижимости(рис 38).

Рис. 38 Структура агентства недвижимости

Обеспечение служб, риэлторской компании:

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

Программное: Использование системы Microsoft Dynamics CRM 3.0 в качестве связующей среды для работы сотрудников, взаимодействующих с клиентами корпорации «ИНКОМ-Недвижимость»( единой базы данных поставщиков, клиентов корпорации), использование лицензионного ПО (т.к. антивирусы, брандмауэры, браузеры)

Обеспечение Кадрами: Набор и обучение высококлассных специалистов, так как от профессионализма сотрудников напрямую зависит прибыль компании.

3. Проектный раздел.

3.1 Постановка задачи.

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

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

3.2 Экономическая сущность задачи.

Цель – выдать увольняющемуся сотруднику трудовую книжку; вход – обходной лист, выход – заполненный обходной лист, трудовая книжка ; задача не периодична и выполняется по мере необходимости.

3.3 Описание метода решения задачи.

Задача решается по методологии DFD-схемы бизнес-процесса в нотации Гейна-Сарсона показанному ниже на рисунке 39.

3.4 Описание бизнес-процесса.

Рис. 39 DFD-схема бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении».

Дополнительные информация и схемы по данной функциональности, расположены в разделе ПРИЛОЖЕНИЯ, ДОПОЛНИТЕЛЬНЫЕ ЗАДАНИЯ.

Заключение

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

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

Основу многих современных методологий моделирования бизнес-процессов составила методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и алгоритмические языки, применяемые для разработки программного обеспечения. С помощью методологии семейства IDEF можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему.

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

Список литературы

Войнов И. В., Пудовкина С. Г., Телегин А. И. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей: Монография. – Челябинск: Изд. ЮУрГУ, 2002. – 392 с.

Волков О. Стандарты и методологии моделирования бизнес-процессов. Режим доступа: http://www.connect.ru/article.asp?id=5710. — Загл. с экрана.

Григорьев Д. Моделирование бизнес-процессов предприятия. Режим доступа: http://www.valex.net/articles/process.html. — — Загл. с экрана.

Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов // М.: Финансы и статистика, 2006.

Менеджмент процессов / Под ред. Й. Беккера, Л. Вилкова, В. Таратухина, М. Кугелера, М. Роземанна; [пер. с нем.]. — М.: Эксмо, 2007. — 384 с. — (Качественный менеджмент).

Пинаев Д., Веретенников Д. Моделирование бизнес-процессов: доступно о сложном / Д. Пинаев // 2003.

http://www.betec.ru/ — Бизнес-инжиниринговые технологии.

Сергей Ковалев, Валерий Ковалев, Журнал «Консультант директора», № 12, Июнь, 2004 г.

http://www.sql.ru/forum/actualthread.aspx?tid=441853 – методология описания бизнес-процессов.

Андрей Дворников, Журнал «Авант Партнер», № 22(79), Август 2005 г.

http://www.aris-portal.ru/ — все о методологии ARIS.

Приложения

Дополнительные задания.

Классификация документов в рамках IDEF0

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

Рис. Доп. 1. Классификация документов агентства недвижимости в рамках IDEF0 модели.

Концептуальная модель

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

Рис. Доп. 2. Концептуальная модель совершения платежной транзакции.

Диаграмма классов

Диаграмма классов оплаты и заказа.

На диаграмме классов, приведенной ниже, статическая структура описана вокруг главной сущности — Customer (покупатель), который связан с набором других классов, например Address (адрес), Order (заказ), и интерфейсом Payment (платеж). У покупателя может быть несколько Addresses (адресов) смоделированных агрегированием. Также у покупателя может быть отношение ассоциации с интерфейсом Payment (платеж) и классом Order (заказ). Интерфейс Payment (платеж) может быть либо CreditCard (кредитной картой) либо DebitCard (дебетовой картой), которые являются двумя реализационными моделями интерфейса Payment (платеж). У каждого заказа может быть много присоединенных OrderItems (предметов заказа). Так как OrderItem (предмет заказа) не может существовать без Order (заказ), то отношение смоделировано как композиция. PrivilegedCustomer (привилегированный покупатель) это особый Customer (покупатель), у которого есть скидки на сделанные покупки, и который является продолжением Customer (покупатель) на основе отношения обобщения. Навигация указывает направление перемещения по ассоциации. Кратность описывает возможные сущности. .

Рис. Доп. 3. Диаграмма классов заказов и оплаты различными категориями покупателяй.

Функция управления созданием объявления

Рис. Доп. 4. Схема составления объявления.

Взаимосвязь Организационной структуры агентства недвижимости

Рис. Доп. 5. Взаимосвязь подразделений

Примечания и заметки

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://referat.ru

Дата добавления: 02.09.2009

Стандартизация бизнес-процессов | Руководство от А до Я по стандартизации процессов

Что такое стандартизация бизнес-процессов?

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

Стандартизация бизнес-процессов направлена ​​на:

• Определите многочисленные разрозненные способы решения конкретной проблемы в организации
• Разработайте единое решение этой проблемы
• Внедрите это уникальное решение во всей организации

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

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

Как работает стандартизация бизнес-процессов?

Компартментализация — это ключевая концепция, которая заставляет работать стандартизацию бизнес-процессов.

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

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

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

Почему важна стандартизация бизнес-процессов?

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

Стандартизация.

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

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

Как стандартизировать бизнес-процессы

Стандартизация бизнес-процессов — это двухэтапный процесс, который обычно включает:

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

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

Обнаружение бизнес-процессов

На этапе обнаружения процесса группа управления процессами идентифицирует:

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

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

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

С другой стороны, вместо этого вы можете использовать такой инструмент, как Kissflow.

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

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

Kissflow Process упрощает рабочие процессы и процессы, поэтому ваша команда может тратить меньше времени на устранение хаоса процессов и больше времени на то, чтобы работать с ними наилучшим образом.

Внедрение процесса

Реализация процесса включает:

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

Преимущества стандартизации бизнес-процессов

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

Вот 4 основных преимущества стандартизации бизнес-процессов.

Повышение уровня удовлетворенности клиентов

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

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

Соответствие

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

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

Ресурсоэффективность

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

Это приводит к сценарию, в котором экономия ресурсов в одном филиале организации легко и быстро дублируется, многократно увеличивая экономию затрат.

Надежное управление знаниями

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

Заключение

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

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

Определение стандартов управления бизнес-процессами (BPM)

Название компании Страна UNITED STATESUNITED KINGDOMCANADAAUSTRALIAINDIA —— AfghanistanÅland IslandsAlbaniaAlgeriaAmerican SamoaAndorraAngolaAnguillaAntarcticaAntigua и BarbudaArgentinaArmeniaArubaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBonaire, Синт-Эстатиус и SabaBosnia и HerzegovinaBotswanaBouvet IslandBrazilBritish Индийский океан TerritoryBrunei DarussalamBulgariaBurkina FasoBurundiCambodiaCameroonCape VerdeCayman IslandsCentral африканских RepublicChadChileChinaChristmas IslandCocos (Килинг) IslandsColombiaComorosCongoCongo, Демократическая Республика theCook IslandsCosta RicaCôte D’IvoireCroatiaCubaCuraçaoCuraçaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEcuadorEgyptEl SalvadorEquatorial ГвинеяЭритреяЭстонияЭфиопияФолклендские острова (Мальвинские острова) Фарерские островаФиджиФинляндияФранцияФранцузская ГвианаФранцузская ПолинезияФранцузские Южные территорииГабонГамбияГрузияГерманияГанаГибралтарствоГрецияГренландияГренадаГваделупа-ГуамГватемалаГерна Бисау, Гайана, Гаити, Херд, острова Макдональд.HondurasHong KongHungaryIcelandIndonesiaIran, Исламская Республика ofIraqIrelandIsle из ManIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKorea, Корейская Народно-Демократическая Республика ofKorea, Республика ofKuwaitKyrgyzstanLao Народная Демократическая RepublicLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacaoMacedonia, бывшая югославская Республика ofMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritaniaMauritiusMayotteMexicoMicronesia, Федеративные Штаты ofMoldova, Республика ofMonacoMongoliaMontenegroMontserratMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigerNigeriaNiueNorfolk IslandNorthern Mariana IslandsNorwayOmanPakistanPalauPalestine, Государственный ofPanamaPapua Новый GuineaParaguayPeruPhilippinesPitcairnPolandPortugalPuerto RicoQatarRéunionRomaniaRussian FederationRwandaSaint BarthélemySaint Елены, Вознесения и Тристан-да-Кунья, Сент-Китс и Невис, Сент-Люсия, Сент-Мартен (Французская часть), Сен-Пьер и MiquelonSaint Винсент и GrenadinesSamoaSan MarinoSao Томе и PrincipeSaudi ArabiaSenegalSerbiaSerbia и MontenegroSeychellesSierra LeoneSingaporeSint Маартен (Голландская часть) SlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSouth Джорджия и Южные Сандвичевы IslandsSouth SudanSpainSri LankaSudanSurinameSvalbard и Ян MayenSwazilandSwedenSwitzerlandSyrian Arab RepublicTaiwanTajikistanTanzania, Объединенная Республика ofThailandTimor-LesteTogoTokelauTongaTrinidad и TobagoTunisiaTurkeyTurkmenistanTurks и Кайкос IslandsTuvaluUgandaUkraineUnited Арабские EmiratesUnited Штаты Экваторияльная Острова УругвайУзбекистан ВануатуВатикан Венесуэла, Боливарианская Республика Вьетнам Виргинские острова, Британские Виргинские острова, U.С.Уоллис и Футуна, Западная Сахара, Йемен, Замбия, Зимбабве.

Управление бизнес-процессами — каковы ваши стандарты?

После выступления на конференции «Шесть сигм» меня спросили, каково мое определение BPM и что отличает его от «Шести сигм». Тема моей презентации заключалась в том, как определить важные программы изменений. Я не уверен, какую точную формулировку я использовал, но я, должно быть, сначала заявил, что я не эксперт Шести Сигм, а только клиент Шести Сигм, но Шесть Сигм, похоже, не используют стандарты.Определение BPM должно включать измерение процесса, моделирование и планирование изменений. Позже, в своем гостиничном номере, я понял, что никогда не излагал на бумаге то, что мое определение BPM.

Для меня BPM началось 5 лет назад с просьбы присоединиться к группе людей, путешествующих в Миннеаполис, которые собирались пройти обучение SCOR. Опыт обучения был как положительным, так и отрицательным. Положительным моментом были и остаются стандартные определения процессов и показателей. Как бывший менеджер по отчетности я провел много встреч, объясняя, почему мы приняли определенный набор показателей, а затем приводил аргументы в пользу того, каким должно быть определение в соответствии с тем-то и таким-то.Сегодня, когда кто-то задает вопрос, как измерить какой-либо аспект цепочки поставок, ответ прост: вот список показателей SCOR; давайте рассмотрим, какие аспекты вы хотите измерить. «Отговорка» о том, что они являются отраслевым стандартом, быстро убивает этих двух зайцев одним выстрелом; Какая метрика и как она определяется.

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

В то время в учебных материалах Совета по цепочке поставок говорилось, что проект SCOR займет от 12 до 18 месяцев. Для нас это был большой поворот. Мы уже знали, как делать многолетние проекты (просто продолжать работу в обычном режиме). Нашему руководству также будет сложно продать: «Если мы будем тренировать всех сейчас, мы увидим результаты через 12-18 месяцев». Это, плюс знание того, что период внимания руководства «стратегическими» проектами составляет около 3-6 месяцев, на самом деле не похоже на то, во что мы будем инвестировать.

Перемотать вперед на 5 лет после обучения; Я начал использовать SCOR в проектах, над которыми работал, затем обучил пару человек использованию SCOR, позже сформировал группу менеджеров проектов SCOR и вскоре понял, что мы отлаживаем то, как мы выполняем проекты. Были изменены методы и шаблоны, и были созданы структуры для других областей бизнеса, таких как дизайн продукта и операции по продажам. Где-то по пути название BPM было привязано к тому, что мы делали. Именно тогда я впервые начал изучать определение BPM.Gartner разделила BPA и BPM; BPA, Анализ бизнес-процессов, представляет собой больше из того, что мы сделали. BPM (Business Process Management) означает автоматизацию рабочего процесса. Многие ИТ-специалисты, похоже, соглашались с Gartner в понимании BPM.

Достаточно об истории, вернемся к исходному вопросу.

Что такое BPM? BPM — это способность идентифицировать основные процессы и проверять их эффективность, полноту, сходство, избыточность и возможность повторного использования. М для управления подразумевает непрерывность, способность постоянно адаптировать процесс к любым меняющимся потребностям рынка и целям компании.

В стандартах BPM необходимо учитывать два аспекта: таксономию и реализацию. Таксономия — это аспект использования общего языка, классификации или использования одних и тех же слов для описания одних и тех же вещей. Большинство людей, с которыми я говорю о SCOR, привлекаются аспектом таксономии стандартных структур процессов, как показано на рисунке 1. Аспект реализации, однако, более ценен. Реализация — это способ выполнения процесса на уровне детализации. Это включает в себя последовательность действий и может существенно отличаться.Аспекты, определяющие реализацию: Организация (кто несет ответственность), Люди (кто выполняет работу), Технология (какие инструменты поддерживают процесс), Местоположение (где это делается), Бизнес-правила (что можно, что нельзя и как процесс измеряется).

Рисунок 1.

Рассмотрим процесс «Отъезда» из командировки. Предлагаемая мной таксономия будет включать следующие этапы процесса: бронирование поездки, поездка в аэропорт, регистрация и посадка в самолет. Как частый путешественник, у меня есть разные реализации этого процесса с разными авиакомпаниями и / или направлениями.Сравним внутренние рейсы с континентальными и юго-западными рейсами. Continental базируется в Хьюстоне и является нашим предпочтительным перевозчиком; они обеспечивают прямые рейсы в большинство мест, что экономит время в пути. Когда я бронирую рейс, мне заранее выделяется место. Юго-запад — перевозчик, которым я путешествую, если цена является основным соображением. Southwest не назначает места заранее; они работают по модели FIFS (First-In / First-Seed). Их бизнес-правило назначения рабочих мест меняет мое поведение и, следовательно, то, как я реализовал процесс.На рисунке 2 показаны реализации Departing with Continental и Southwest.

Рисунок 2.

Вход в «Отъезд» определяет результат шага «Забронировать поездку». Если стоимость является основной, а время в пути — второстепенным, то, скорее всего, это будет билет на юго-запад. Если исходные данные заключаются в сокращении времени в пути, то выходом этого шага, скорее всего, станет чуть более дорогой континентальный билет.

Следующий шаг зависит от авиакомпании. Поскольку Southwest не распределяет места, я хотел бы зарегистрироваться как можно раньше (мое неподтвержденное убеждение: чем раньше вы зарегистрируетесь, тем лучше будет ваша группа посадки).Если вы путешествуете по сети Continental, я еду в аэропорт до регистрации. Пример подчеркивает разницу в последовательности. Также есть разница в регистрации. На рис. 2 это не особо подчеркивается. Я могу либо выделить это в описании элемента процесса «Регистрация», либо, если это добавит ценности моему проекту, я могу смоделировать следующий уровень ниже для «Регистрация».

На приведенных выше рисунках показана разница между использованием структуры процесса только в качестве таксономии или ее расширением до реализации. Реализации (в частности, последовательность и взаимосвязь этапов процесса) также подчеркивают еще один аспект: производительность.Для Continental имеет смысл попытаться сократить время от регистрации до полной посадки. Клиенты из континентальной Европы воспринимают это время в основном как время ожидания. Для Southwest проект по сокращению этого времени, скорее всего, потерпит неудачу, если проектной группе не будет разрешено изменить бизнес-правила по распределению рабочих мест. Соответствующим показателем времени ожидания для Southwest будет время завершения поездки до аэропорта и завершения посадки. Обратите внимание, что для обеспечения безопасности после службы 911 может потребоваться собственный элемент процесса; в моем первоначальном примере это простой шаг как часть процесса посадки.

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

Каспар Х. Хунше — управляющий директор и соучредитель Process Core Group (PCOR.com). Он является первым автором эталонных моделей Customer-Chain и Design-Chain. Он практик и сторонник управления процессами на основе стандартов.

SCOR = Справочник по операциям цепочки поставок, поддерживаемый Советом по цепочке поставок, www.supply-chain.org

Учебный курс Каспара Хунше.

(PDF) Стандарты управления бизнес-процессами

Запущенный процесс создается из модели процесса путем создания экземпляра графа модели процесса

, который в основном создает (потенциально пустой) контекст процесса,

определяет действия без соединителей входящего контроля ( начало деятельности —

активность А1 на рис.3) и составляет их график. Планирование деятельности означает оценку

его запроса или локатора персонала и создание либо рабочего запроса (рабочего элемента) для квалифицированных людей

(в случае деятельности людей), либо прямого вызова одной из соответствующих программ

, соответствующих требованиям. под локатором (в случае программной активности)

соответственно. Коннекторы данных, нацеленные на действие, отслеживаются в обратном направлении

, а данные из выходных контейнеров источников коннекторов данных извлекаются

для вычисления входных данных действия.Затем этот ввод передается в рабочий элемент или программу

соответственно. После завершения рабочего элемента или программы

ее выходные данные будут скопированы в контекст процесса; Таким образом, контекст процесса

очень динамичен и особенно зависит от экземпляра. Затем механизм процесса

определит все исходящие управляющие соединители этого действия, оценит

их переходные условия в фактическом контексте процесса экземпляра процесса,

и определит действия, являющиеся конечными точками тех управляющих соединителей

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

. Из-за зависимости экземпляра от контекста процесса подмножество фактических

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

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

параллельной работы, выполняемой в экземпляре модели процесса, а именно

, если более чем одно из соответствующих условий перехода оценивается как истинное в

фактический контекст процесса.Такое действие называется активностью форка (A

1

на рис. 3). В повороте

действие с более чем одним соединителем входящего управления называется действием соединения

(A

5

на рис. 3). Когда механизм процесса достигает активности соединения через конкретный соединительный элемент управления

, он ожидает, пока все остальные входящие соединители управления не пройдут

и их условия перехода не будут оценены, прежде чем рассматривать schedul-

в активности соединения: таким образом, фактически, Активность соединения — это средство синхронизации

параллельной работы в модели процесса.«Рассмотрение» для планирования действия соединения составляет

на основе условия соединения, связанного с каждым действием соединения: условие соединения — это логическое условие

в истинностных значениях входящих условий перехода; условие соединения

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

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

, которые должны быть успешно пройдены для правильного выполнения действия соединения

.Предполагается, что фактическое значение истинности условия перехода управляющего соединителя

, нацеленного на активность соединения, указывает на успешность всего пути

, заканчивающегося соответствующим управляющим соединителем. Таким образом, если условие соединения истинно,

по крайней мере из этих комбинаций параллельных путей было успешно выполнено.

В случае, если один из входящих управляющих соединителей операции соединения не пройден

вообще, подсистема процессов ждет, навсегда блокируя выполнение операции соединения — ситуации

, которой следует избегать.Например, p

0

на рис.3 оценивается как ложное, A

4

никогда не будет запланировано и, следовательно, никогда не будет завершено, что, в свою очередь, означает, что соединитель управления

(A

4

, A

5

) никогда не будет пройден, а A

5

будет заблокирован. Способ

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

Стандартам управления бизнес-процессами 519

Все, что вам нужно знать.

Стандартизация бизнес-процессов направлена ​​на унификацию процедур в организациях, которые используют разные практики для выполнения одного и того же процесса.
Таким образом можно достичь так называемой компонентности , которая представляет собой не что иное, как повторное использование процесса, уже установленного в качестве компонента (или подпроцесса) другого процесса, иногда в другой области или отделе компании.

Стандартизация бизнес-процессов, согласно команде разработчиков прессы Productivity Press (2002) , определяется как процесс, который включает:

• Устанавливая стандарты
• Отчетность по стандарту
• Подтверждение соответствия стандарту
• Поощрение постоянного улучшения стандарта

основных результатов стандартизации бизнес-процессов:

• Уменьшение убытков
• Корпоративная культура обучения
• Повышенная прозрачность
• Снижение изменчивости

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

См. Также: Шаги по улучшению бизнес-процессов.

Руководства по процедурам и стандартизация бизнес-процессов Руководства по процедурам

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

• Графическое представление процесса
• Условия запуска
• Интерфейс с другими процессами
• Деятельность
• Пути выполнения процессов

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

Руководства по процедурам

— важный документ для компаний, стремящихся к стандартизации бизнес-процессов .

Проверьте: Что такое автоматизация процессов — узнайте о 14 преимуществах прямо здесь.

Производственная система Toyota (TPS) и стандартизация бизнес-процессов

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

Среди основных характеристик ТПС можно выделить:

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

Как оказалось, стандартизация бизнес-процессов TPS приводит к значительному увеличению численности персонала.

Подробнее: Непрерывное совершенствование — Узнайте о японском и американском методах: посмотрите разницу здесь.

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

Стандартная библиотека процессов

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

Для этого команды должны быть организованы и стараться следовать некоторым основным принципам:

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

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

См. Также:

Профессия BPM — ABPMP International

Вероятно, есть много людей, вовлеченных в управление бизнес-процессами, которые считают себя «ИТ-специалистами», а есть другие, которые считают себя «деловыми людьми», в то время как есть люди, подобные мне, которые пересекают обе дисциплины. ABPMP International рассматривает управление бизнес-процессами (BPM) как дисциплину управления и как набор технологий, поддерживающих управление по процессам. К сожалению, это, по-видимому, единственный отраслевой консенсус в отношении определения BPM, поскольку, безусловно, нет недостатка во мнениях относительно « ЧТО » BPM и « КАК » для выполнения BPM.

Согласно руководству ABPMP International по общему объему знаний по управлению бизнес-процессами (BPM CBOK) ® , «Управление бизнес-процессами (BPM) — это дисциплинированный подход к выявлению, разработке, выполнению, документированию, измерению, мониторингу и контролю. как автоматизированные, так и неавтоматизированные бизнес-процессы для достижения согласованных и целевых результатов, согласованных со стратегическими целями организации. BPM включает в себя целенаправленное, совместное и все более технологичное определение, улучшение, инновации и управление сквозными бизнес-процессами, которые стимулируют бизнес-результаты, создание ценности и позволяет организации более гибко достигать своих бизнес-целей.BPM позволяет предприятию согласовать свои бизнес-процессы со своей бизнес-стратегией, что приводит к повышению общей производительности компании за счет улучшения конкретных рабочих операций в рамках конкретного отдела, в масштабе предприятия или между организациями ».

В рамках ABPMP International наше членство демонстрирует разнообразие названий, которые отражают эти разные подходы к управлению процессами. В нашей базе данных представлено более 150 различных наименований, хотя есть кластеры вокруг некоторых наименований, таких как Менеджер, Директор, Вице-президент, Аналитик, Консультант, Архитектор, обычно до или после которых идут Процесс, BPM, Улучшение процессов, Инновации в процессах и т. Д.

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

Модель компетенций ABPMP BPM — это путь развития, который описывает навыки, компетенции и уровни опыта для людей, желающих сделать карьеру в области управления бизнес-процессами.

Конечно, нет недостатка в поставщиках, прошедших обучение по BPM, но ни один из них полностью не определил весь спектр знаний об управлении бизнес-процессами. Для профессионалов BPM, чтобы быть силой на рынке, критически важно создать необходимые области знаний для профессионалов BPM, как это сделал Институт управления проектами 15 лет назад для специалистов по управлению проектами и APICS (ныне Ассоциация управления операциями). для специалистов по эксплуатации.Стало ясно, что существует аналогичная потребность в разработке некоторых базовых стандартов, минимальной квалификации и разумного пути для того, чтобы стать профессионалом в области BPM.

Вот почему ABPMP International решила сделать ставку и разработала Guide to The Business Process Management Common Body of Knowledge (BPM CBOK ® ) , Certified Business Process Associate (CBPA®) , the Certified Business Process Professional (CBPP ® ) , и скоро будет разработан Certified Business Process Leader (CBPL ™) .

BPM CBOK® — это базовый набор стандартов ABPMP International для « WHAT » BPM, а не « HOW » для BPM.

«ЧТО» и «КАК» BPM будут продолжать развиваться, как и его содержание (ЧТО) и обучение (КАК) для него. CBPP® ABPMP International — это сертификат, который был разработан практиками BPM и для них. Это первая программа независимых профессиональных экзаменов и сертификации в области BPM. CBPP® был разработан в соответствии с международными стандартами сертификации с целью стать международно признанным стандартом для профессионалов BPM.

Присоединяйтесь к нам в развитии дисциплины и развитии профессии BPM.

Присоединяйтесь к ABPMP International сегодня!

Тони Бенедикт

Президент, ABPMP International

Преимущества стандартов бизнес-процессов — Рабочие знания HBS

Не удовлетворены услугами аутсорсеров вашей компании? Возможно, вашему бизнесу не хватает стандартов процессов. Согласно Thomas H. Davenport , три вещи должны произойти, чтобы ваш бизнес и его возможности аутсорсинга функционировали должным образом.Выдержка из Harvard Business Review .

Томаса Х. Давенпорта

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

Однако, несмотря на тенденцию [сегодняшнего дня] к аутсорсингу, большинство компаний по-прежнему используют режим «сделай сам» для большинства процессов. (Крупные транснациональные корпорации с большей вероятностью воспользуются преимуществами аутсорсинга, но даже в этом случае только для очень транзакционной и административной деятельности.) Из-за нехватки стандартов процессов поступать иначе было бы рискованно. За исключением разработки ИТ-систем, как правило, нет четкой основы, с помощью которой компании могли бы сравнивать возможности, предоставляемые внешними организациями, с возможностями, предлагаемыми собственными, или сравнивать услуги нескольких внешних поставщиков.В результате фирмы, решившие передать свои возможности на аутсорсинг, должны руководствоваться двумя критериями: вера в то, что внешний поставщик будет выполнять свою работу хорошо, и затраты. Учитывая отсутствие сопоставимости, почти удивительно, что стоимость, безусловно, является основным критерием, который компании применяют при оценке аутсорсеров, и что снижение затрат является их основной целью. Отсутствие стандартов может также объяснить, почему в нескольких широких исследованиях удовлетворенности аутсорсингом многие компании — до половины в некоторых исследованиях — недовольны своими отношениями с аутсорсингом.

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

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

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

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

Эти стандарты деятельности и потока операций начинают появляться в самых разных предприятиях и отраслях.Некоторые из них являются результатом усилий групп процессов, таких как Совет по цепочке поставок, членами которого являются более 800 предприятий. Он разработал эталонную модель операций цепочки поставок (SCOR), в которой процесс цепочки поставок верхнего уровня состоит из пяти основных этапов: планирование, источник, изготовление, доставка, возврат. Модель также определяет типичные действия для подпроцессов второго, третьего и четвертого уровней с повышенным уровнем детализации. […]

Второй набор необходимых подходов к оценке процессов — это стандарты производительности процессов .Как только компании в определенной отрасли достигают консенсуса в отношении того, какие виды деятельности и потоки составляют данный процесс, они могут начать измерять свои собственные процессы и сравнивать свои результаты с результатами внешних поставщиков. Если есть соглашение, например, о том, что значит «обрабатывать нового сотрудника», менеджеры могут проанализировать, сколько в среднем стоит внутренняя служба управления персоналом, чтобы предоставить эту услугу, и сколько времени это займет. Они также могут провести информированное обсуждение с внешними поставщиками услуг показателей эффективности их процессов.[…]

Наконец, организациям нужен набор стандартов управления процессами , которые показывают, насколько хорошо их процессы управляются и измеряются, и находятся ли они на пути к постоянному совершенствованию. Поскольку этот третий тип стандарта процессов не требует консенсуса в отношении действий и потоков процессов, его проще всего создать и он наиболее широко доступен на сегодняшний день. Стандарты управления процессами основаны на предположении, что хорошее управление процессами в конечном итоге приведет к хорошим потокам и производительности процессов.В некоторых областях, таких как информационные технологии и производство, эти стандарты уже широко используются (через модель зрелости возможностей Института программной инженерии и серию ISO 9000, соответственно). Они начинают приводить к коммерциализации возможностей, что в конечном итоге трансформирует организации. […]

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

[Купить статью полностью]

Используется с разрешения «The Coming Commoditization of Processes», Harvard Business Review , Vol.

No related posts.