Декомпозиция бизнес процессов это: Структура модели бизнес-процессов [BS Docs 4]

Структура модели бизнес-процессов [BS Docs 4]

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

1. Продвижение продуктов

2. Выяснение потребности клиента

3. Заключение договора с потребителем

4. Прием текущих заказов

5. Производственное планирование

6. Организация выполнения заказа клиента

7. Организация удовлетворения претензий клиентов

8. Анализ удовлетворенности клиентов

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

Business Studio позволяет создавать графические модели бизнес-процессов с помощью диаграмм, выполненных в той или иной нотации моделирования. Поддерживается пять типов нотаций графического моделирования — IDEF0, Процесс и Процедура, BPMN, EPC. Для создания модели бизнес-процессов можно использовать любую из этих нотаций или их комбинации. Рекомендуется в зависимости от уровня процесса в модели для его описания использовать нотации, приведенные в Таблице 1.

Уровень модели	Используемая нотация	Комментарий
0	IDEF0 (контекстная диаграмма)	Модель, выполненная в нотации IDEF0, имеет контекстную диаграмму верхнего уровня А-0, на которой объект моделирования представлен единственным блоком с граничными стрелками. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.
1	IDEF0	1 уровень содержит процессы верхнего уровня модели.
2	IDEF0	2 уровень содержит декомпозицию процессов верхнего уровня. Например, процесс второго уровня «Продвижение продуктов» может быть декомпозирован на подпроцессы 3 уровня: 1. Группировка клиентов и анализ клиентской базы 2. Разработка программы удержания клиентов 3. Определение потребности по привлечению новых клиентов 4. Разработка комплекса продвижения продуктов на целевые рынки 5. Проведение мероприятий комплекса продвижения
3 и далее	Процесс, Процедура, BPMN, EPC	На 3 уровне происходит смена нотации моделирования. 3 уровень при корректной декомпозиции будет представлять собой работы — наименьшие возможные процессы, создающие минимальный отделимый результат, за отдельные действия внутри работы будут отвечать конкретные должностные лица.

Таблица 1. Уровни модели нотации IDEF0

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

Моделирование деятельности на низких уровнях модели тесно коррелирует с прикладными методиками и технологиями деятельности, т.е. в ряде случаев вопросы «что делать» и «как делать» сливаются воедино.

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

«Управление бизнес-процессами. Эффективная реализация стратегии»

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

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

Итак, рассмотрим логическую основу.

1     Для того, чтобы можно было добиться каких либо стратегических целей, – они должны быть сформулированы.

Внятно. Четко. Письменно. Пути их достижения необходимо тщательно  согласовать с теми, кто будет их воплощать.

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

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

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

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

К организационным стратегиям, как правило, относятся: маркетинговая, финансовая, производственная, стратегия управления персоналом, IT стратегия. (см. рис. 1)

3     Когда стали понятны основные цели, на которые следует обратить внимание, т.е. получен ответ на вопрос «Что делаем ?» имеет смысл ответить на вопрос: Каким образом ? Как, за счет чего должна быть обеспечена реализация стратегии?

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

Лев ВВ

Рисунок 1. 

 

 

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

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

Таблица 1.

Основной классический принцип:

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

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

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

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

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

3.2   Помимо проверки на соответствие оргструктуры следует обратить внимание на

бизнес-процессы.

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

Если это описание есть, то соответствует ли оно действительно происходящим в организации процессам ?

И, наверное, наиболее сложно решаемый вопрос – оптимально ли построены эти самые бизнес-процессы ? Если предположим, что оптимально, то по какому критерию они оптимизировались ? Т.е. в чьих интересах выполняются ? Здесь как раз и кроется много интересного. Вплоть до применения появившейся сравнительно недавно в России технологии Lean Thinking.

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

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

Второй не менее важный вопрос – актуальность существующих описаний. И международный, и российский опыт говорят – если на бумаге одно, а в действительности другое, то бумага бесполезна. А значит, должна быть система, следящая за соответствием документации и самих процессов. Наиболее полно этот подход реализован  при внедрении системы менеджмента качества по международному стандарту ISO 9001-2000. Но опять-таки, при условии реально работающего внедрения. А это также не совсем часто встречающийся в России опыт. Но он все-таки есть. Видел такие организации, участвовал во внедрении. Прогресс идет не гладко, но он идет.

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

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

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

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

На сегодня есть 2 актуальных подхода: это собственно система ключевых показателей эффективности (КПЭ) в общем виде и, как  ее весьма продвинутая разновидность, система сбалансированных показателей (ССП). Про последнюю (тем более, что она наиболее востребована лишь в крупных предприятиях) сейчас достаточно много пишут, поэтому позволю себе на ней не останавливаться (если у читателя появится интерес, можно посмотреть, например, книги Р. Каплана и Д. Нортона). Остановимся более подробно на первой возможности – тем более, что она, по моему мнению, является необходимой (и не такой уж «короткой», судя по западному опыту)  ступенькой для набора опыта перед внедрением ССП. Для малого и среднего бизнеса не исключено, что этой ступеньки вполне достаточно.

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

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

Здесь есть два основных пути:

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

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

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

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

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

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

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

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

Согласно ей, есть 5 типов мотивации:

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

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

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

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

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

Конечно, в каждом человеке, как правило, присутствуют все (или почти все) типы мотивации. Вопрос в их соотношении. Т.е. в том, какой именно тип мотивации будет доминантным (что вполне адекватно определяется тестированием).

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

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

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

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

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

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

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

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

Рисунок № 2

Лев ВВ

Итак, подведем итоги.

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

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

Автор: Лев В.В., к.э.н.   

Финансовая газета (еженедельник) №15, апрель 2008

Упомянутые источники:

1. Гребиньяк Лоуренс Дж. Как заставить работать вашу стратегию: Эффективная реализация стратегии и внедрение перемен./ Пер. с англ.- Днепропетровск: Баланс Бизнес Букс, 2006.-352 с.
2. Пригожин А.И. Методы развития организаций. -М.: МЦФЭР, 2003-864 с.
3. Герчиков В.И. Управление персоналом: работник – самый эффективный ресурс компании: Учебное пособие.- М.: ИНФРА-М, 2008.-282 с.

 

ГОСТ Р 53633.11-2015 Информационные технологии (ИТ). Сеть управления электросвязью. Расширенная схема деятельности организации связи (eTOM).Декомпозиция и описания процессов. Процессы уровня 2 eTOM. Управление организацией. Управление эффективностью организации, ГОСТ Р от 10 июня 2015 года №53633.11-2015

ГОСТ Р 53633.11-2015

OKC 35.020

Дата введения 2015-09-01

Предисловие

1 РАЗРАБОТАН Автономной некоммерческой организацией «Научно-технический центр информатики» (АНО «НТЦИ»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 «Связь»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 10 июня 2015 г. N 595-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта МСЭ-Т М.3050.2*. (03.2007) «Сеть управления электросвязью. Расширенная схема деятельности организации связи. Декомпозиция и описания процессов» [ITU-T M.3050.2 (03.2007) «Telecommunications management network. Enhanced Telecom Operations Map (eTOM) — Process decompositions and descriptions», NEQ]
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. — Примечание изготовителя базы данных.

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Октябрь 2018 г.


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Группа стандартов «Расширенная схема деятельности организации связи (eTOM)» разработана с учетом рекомендаций М.3050.x сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т).

Рекомендации по eTOM (Enhanced Telecom Operations Map) входят в состав серии рекомендаций М.Зххх МСЭ-Т, которая стандартизирует «Сеть управления электросвязью» TMN (Telecommunications Management Network) — модель управления оборудованием, сетями и услугами электросвязи.

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

Модель eTOM, определенная группой рекомендаций МСЭ-Т по eTOM, была разработана международной ассоциацией ТМ Forum (Форум управления телекоммуникациями) в рамках программы работ «Новое поколение систем управления и программного обеспечения» NGOSS (New Generation Operations Systems and Software).

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

Общая структура бизнес-процессов eTOM, стандартизированная в ГОСТ Р 53633.0, определяет структуры уровней для уровней 0 и 1 eTOM, а также их элементы. Структуры и элементы процессов для уровней 2 и 3 иерархической структуры eTOM определяются другими стандартами группы eTOM.

Структура и элементы процессов уровня 2 образованы в результате декомпозиции групп процессов уровня 1 eTOM. Каждой группе процессов уровня 1 соответствует своя совокупность элементов процессов уровня 2, которая устанавливается отдельным стандартом.

Настоящий стандарт определяет структуру и элементы процессов уровня 2 для группы процессов уровня 1 «Управление эффективностью организации» в главной области процессов «Управление организацией».

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

1 Область применения

Настоящий стандарт устанавливает структуру и элементы процессов уровня 2 для группы процессов «Управление эффективностью организации» (Enterprise effectiveness management), являющейся элементом структуры уровня 1 в главной области «Управление организацией» модели eTOM (Enhanced Telecom Operations Map). Эта группа процессов определена в базовом стандарте ГОСТ Р 53633.0.

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

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

Стандарт предназначен для применения организациями связи, системными интеграторами и производителями систем автоматизации производственных процессов.

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

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

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

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

2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

ГОСТ Р 53633.0 Информационные технологии. Сеть управления электросвязью. Расширенная схема деятельности организации связи (eTOM). Общая структура бизнес-процессов

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

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 бизнес-процесс (business process): Производственный процесс организации связи.

3.2 иерархическая декомпозиция процесса (hierarchical process decomposition): Метод последовательной детализации процессов более высокого уровня на процессы более низкого уровня с целью обеспечения возможности моделирования протекания процессов высокого уровня с помощью процессов нижележащего уровня.

3.3 клиент (customer): Физическое или юридическое лицо, покупающее у организации связи или получающее бесплатно продукты и услуги.

3.4 оператор связи (service provider): Юридическое лицо или индивидуальный предприниматель, оказывающие услуги связи на основании соответствующей лицензии; поставщик инфокоммуникационных услуг клиентам.

3.5 оператор сети (network operator): Организация связи, производственная деятельность которой направлена на предоставление трактов передачи информации и соединений через сети электросвязи.

3.6 организация (enterprise): Юридическое лицо, осуществляющее деятельность в области связи в качестве основного вида деятельности.

3.7 основная деятельность (operations; OPS): Главная область бизнес-процессов eTOM, относящихся к повседневной деятельности персонала организации.

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

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

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

3.10 продукт (product): Материальная и/или нематериальная сущность, предлагаемая или предоставляемая организацией связи клиенту.

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

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

3.12 расширенная схема деятельности организации связи (Enhanced Telecom Operations Map; eTOM): Эталонная общая структура производственной деятельности организации связи, определяющая стандартные элементы процессов, из которых должны строиться модели всех производственных процессов.

3.13 ресурсы (resource): Физические и логические компоненты, используемые для формирования услуг.

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

3.14 сеть управления электросвязью (Telecommunications Management Network; TMN): Модель управления оборудованием, сетями и услугами электросвязи, определенная в серии рекомендаций М.3000 МСЭ-Т.

3.15 система поддержки бизнеса (Business Support System; BSS): Система, поддерживающая процессы eTOM из главной области «Стратегия, инфраструктура и продукт».

3.16 система поддержки основной деятельности (Operations Support System; OSS): Система, поддерживающая процессы eTOM из главной области «Основная деятельность».

3.17 сквозной процесс (end-to-end process flow): Совокупность всех подпроцессов, действий и порядок их следования, которые необходимы для достижения целей выполнения процесса.

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

3.18 стратегия, инфраструктура и продукт (Strategy, infrastructure and product; SIP): Главная область бизнес-процессов eTOM, осуществляющих планирование и управление жизненным циклом сетевой инфраструктуры и продуктов.

3.19 сущность (entity): Конкретизация или абстракция, различаемые в пределах системы.

Примечание — Примерами сущностей являются система, подсистема, компонент, класс, объект, интерфейс, клиент, процесс, приложение, спецификация.

3.20 управление организацией (Enterprise Management; EM): Главная область бизнес-процессов eTOM, осуществляющих управление организацией и поддержку ее бизнеса.

3.21 услуга связи (service): Деятельность по приему, обработке, хранению, передаче, доставке сообщений электросвязи или почтовых отправлений. Является составной частью продукта, предназначенной для продажи клиенту в составе продукта.

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

3.22 цепочка поставок (supply chain): Сущности и процессы, в том числе внешние процессы организации, которые задействованы при поставке товаров и услуг, необходимых для предоставления продуктов и услуг клиентам.

3.23 элементы процессов (process elements): Стандартные блоки или компоненты, используемые для сборки сквозных бизнес-процессов.

4 Общие положения

4.1 Расширенная схема деятельности организации связи (eTOM) является инструментальным средством для моделирования, анализа, оптимизации и реорганизации производственных процессов и структуры организаций связи.

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

4.3 Настоящий стандарт устанавливает структуру и элементы процессов уровня 2 для группы процессов уровня 1 «Управление эффективностью организации» из главной области «Управление организацией».

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

5 Идентификация процессов

5.1 Для индикации позиционирования элементов процессов уровня 2 на графическом представлении структуры уровня 1 eTOM применяют пиктограммы матричной структуры eTOM. Матричная структура образуется путем наложения вертикальных групп процессов на горизонтальные группы процессов eTOM.

Место элемента процессов или группы процессов в структуре уровня 1 eTOM показывают путем выделения темным фоном соответствующих элементов матрицы на пиктограмме.

На рисунке 1 приведено стандартное графическое представление структуры уровня 1 eTOM в соответствии с ГОСТ Р 53633.0. Пиктограмма группы «Управление эффективностью организации» представлена на рисунке 2. На обоих рисунках рассматриваемая группа процессов выделена темным фоном.

Рисунок 1 — Структура уровня 1 общей структуры бизнес-процессов eTOM

Рисунок 2 — Пиктограмма группы процессов уровня 1 «Управление эффективностью организации»

5.2 В eTOM принята схема нумерации главных областей, групп и элементов процессов с помощью идентификаторов процессов ID (identifier). Идентификатор процессов имеет следующий формат:

aaaaaa.b.x.c.d.e,

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

b — цифра, указывающая разработчика процесса. Значение 1 относится к ТМ Forum, значение 2 — ко всем другим разработчикам;

х — цифра, представляющая номер главной области процессов. Принята следующая нумерация: 1 — «Основная деятельность» OPS, 2 — «Стратегия, инфраструктура и продукт» SIP, 3 — «Управление организацией» ЕМ;

с — цифра, представляющая номер группы процессов уровня 1 в пределах главной области. В главных областях OPS и SIP принята нумерация горизонтальных групп процессов сверху вниз в пределах области в соответствии с рисунком 1;

d — цифра, представляющая номер элемента процессов уровня 2 в структуре группы процессов уровня 1;

е — цифра, представляющая номер элемента процессов уровня 3 в структуре элемента процессов уровня 2.

5.3 Идентификаторы процессов связаны с функциональными описаниями групп и элементов процессов eTOM и используются в качестве ссылок на определения стандартных процессов.

6 Cтруктура и назначение процессов группы «Управление эффективностью организации»

6.1 Структура группы процессов «Управление эффективностью организации» и соответствующие элементы процессов уровня 2 приведены на рисунке 3.

Идентификатор группы: 1.3.3.

Рисунок 3 — Декомпозиция группы процессов «Управление эффективностью организации» на элементы процессов уровня 2

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

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

6.4 Процессы «Управление и поддержка процессов» предназначены для обеспечения, с течением времени, эволюции основных процессов поддержки бизнеса организации.

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

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

6.7 Процессы «Оценка рабочих характеристик организации» предназначены для создания и применения базовой архитектуры управления измерениями рабочих характеристик организации.

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

6.9 Данные соответствия идентификаторов элементов процессов уровня 2 наименованиям этих процессов в составе группы процессов «Управление эффективностью организации» представлены в таблице А.1 приложения А.

7 Элементы процессов уровня 2 для группы «Управление эффективностью организации»

7.1 Функциональные описания элементов процессов уровня 2 устанавливают классификационные признаки, по которым реальные процессы могут быть отнесены к категории процессов, соответствующей конкретному элементу процессов.

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

7.3 Функциональные описания элементов процессов уровня 2 для группы «Управление эффективностью организации» должны соответствовать данным таблицы 1.


Таблица 1 — Функциональные описания элементов процессов уровня 2 для группы «Управление эффективностью организации»

Идентификатор	Наименование элемента процессов	Функциональная характеристика
1.3.3.1	Управление и поддержка процессов (Process management and support)	Процессы создания и применения средств управления процессами в организации. Процессы создания и применения общей методологии проектирования, управления изменениями или реинжинирингом для всех процессов в организации. Создание методологии включает, при необходимости, определение, приобретение и внедрение наборов инструментальных средств разработчика бизнес-процессов. Процессы создания учебных курсов по применению методологии и подготовки руководств по управлению процессами. Процессы координации распределенных процессов проектирования, управления изменениями или реинжинирингом, обеспечивающие устранение дублирования и увеличение повторного использования процессов. Процессы мониторинга процессов для оценки положительного эффекта, получаемого от использования средств управления процессами в организации. Процессы выпуска отчетов о рабочих характеристиках для организации в целом и для отдельных уровней управления организацией
1.3.3.2	Управление качеством в организации (Enterprise quality management)	Процессы формирования политик управления качеством и создания модели организации для целей управления качеством. Процессы поддержки всех операционных процессов и процессов жизненного цикла, которые участвуют в построении модели и в управлении ею. Процессы создания руководств и шаблонов управления качеством для различных областей деятельности организации
1.3.3.3	Управление планами развития и проектами (Programme and project management)	Процессы создания и применения методологий управления планами развития и проектами, управления профессиональными навыками персонала и инструментальными средствами. Процессы создания руководств, шаблонов документации и выбора необходимых средств для управления проектами в различных областях деятельности организации.
		Примечание — Заказ и приобретение инструментальных средств осуществляют процессы «Разработка и управление цепочками поставок» из области SIP. Процессы создания и ведения репозитория информации по управлению планами развития и проектами. Процессы определения, сбора и анализа метрик процессов управления планами развития и проектами
1.3.3.4	Оценка рабочих характеристик организации (Enterprise performance assessment)	Процессы проверки правильности следования целям организации. Процессы определения и запуска необходимых измерений рабочих характеристик, сбора и анализа соответствующих данных, выпуска итоговых отчетов (обычно ежемесячных) для высшего руководства организации. Итоговые отчеты должны содержать сведения о статусе всех контролируемых рабочих характеристик. Процессы оценки уровня управления и формирования сбалансированной карты взаимосвязанных показателей деятельности организации. Процессы администрирования взаимоотношений с внешними организациями, которые по заказу проводят внешние измерения или помогают в проведении внутренних измерений. Примечание — Примерами внешних измерений являются опросы удовлетворенности клиентов в различных сегментах рынка, сравнительное (с другими организациями) тестирование отдельных аспектов работы организации. Процессы создания руководств и шаблонов по оценке рабочих характеристик для различных областей деятельности организации
1.3.3.5	Управление и поддержка оборудования (Facilities management and support)	Процессы обеспечения необходимых климатических условий на рабочих местах персонала. Процессы технического обслуживания оборудования рабочих мест, позволяющие поддерживать оптимальную производительность труда персонала

Приложение А (обязательное). Наименования и идентификаторы элементов процессов уровня 2 для группы процессов «Управление эффективностью организации»

Приложение А
(обязательное)

А.1 Наименования и идентификаторы элементов процессов уровня 2 для группы процессов «Управление эффективностью организации» (Enterprise effectiveness management) должны соответствовать данным таблицы А.1.


Таблица А.1 — Группа процессов «Управление эффективностью организации»

Идентификатор	Наименование элемента процессов	Английский эквивалент наименования
1.3.3.1	Управление и поддержка процессов	Process management and support
1.3.3.2	Управление качеством в организации	Enterprise quality management
1.3.3.3	Управление планами развития и проектами	Programme and project management
1.3.3.4	Оценка рабочих характеристик организации	Enterprise performance assessment
1.3.3.5	Управление и поддержка оборудования	Facilities management and support

УДК 621.391:006.354	OKC 35.020
Ключевые слова: eTOM, общая структура бизнес-процессов, группы процессов, элементы процессов, декомпозиция процессов

Электронный текст документа
подготовлен АО «Кодекс» и сверен по:
официальное издание
М.: Стандартинформ, 2018

Некоторые аспекты внедрения процессного подхода к управлению на промышленном предприятии

Библиографическое описание:

Константинова, И. В. Некоторые аспекты внедрения процессного подхода к управлению на промышленном предприятии / И. В. Константинова, Г. М. Чукалина. — Текст : непосредственный // Экономическая наука и практика : материалы IV Междунар. науч. конф. (г. Чита, апрель 2016 г.). — Чита : Издательство Молодой ученый, 2016. — С. 60-62. — URL: https://moluch.ru/conf/econ/archive/173/10223/ (дата обращения: 04.03.2021).



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

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

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

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

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

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

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

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

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

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

Для внедрения методики процессного подхода в управлении за основу возьмем следующие этапы и проведем их критический анализ2:

 создание сети бизнес-процессов;

 определение владельцев бизнес-процессов;

 моделирование (описания) бизнес-процессов;

 регламентации бизнес-процессов;

 управление бизнес-процессами на основе цикла PDCA;

 аудита бизнес-процессов.

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

Наиболее распространенная классификация бизнес-процессов на внешние и внутренние бизнес-процессы может быть использована как критерий для горизонтальной декомпозиции 1:

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

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

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

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

 верхнего уровня;

 детальные;

 элементарные (операции, не требующие более детального описания).

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

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

Рис. 1.Схема внедрения процессного подхода на предприятии

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

1. 1 этап. Формирование архитектуры бизнес-процессов предприятия:

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

 определение владельцев и моделирование бизнес-процессов.

2. 2 этап. Управление бизнес-процессами на основе цикла PDCA:

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

 внедрение системы постоянного совершенствования системы бизнес-процессов на базе цикла PDCA.

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

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

Литература:

1. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.: Манн, Иванов и Фербер, 2013. — 544 с.
2. Зенченко И. В. Процессный подход к управлению заказами на предприятиях машиностроения: диссертация кандидата экономических наук: 08.00.05 / Зенченко Ирина Владимировна; [Место защиты: Оренбург. гос. ун-т]. — Оренбург, 2011. — 180 с.

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

Похожие статьи

Декомпозиция технологического процесса производства…

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

Опыт

внедрения комплексного подхода к организации…

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

Система бизнес—процессов управления холдингом.

Основные

принципы декомпозиции показателей и построения…

Ключевые слова: декомпозиция, дерево целей, ключевые показатели эффективности, многоуровневый подход, стратегия развития предприятия. Управление любой организацией, в том числе и промышленными предприятиями…

Оптимизация

бизнес—процессов систем бухгалтерского учета

2) декомпозиция бизнес—процессов (разложение на элементы). Моделирование процессов управления запасами и ресурсами на промышленном предприятии, определение и роль этих процессов. Характеристики и взаимосвязь бизнес—процессов на предприятии.

Проблемы и практика

реализации процессного подхода…

Рис. 2. Декомпозиция бизнес—процессов социально-кадрового блока ОАО «РЖД». Основные вопросы по управлению персоналом отображены на рисунке 3. Они называются процессами первого уровня, и включают в себя: организацию труда; обучение персонала…

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

бизнес—процесса «метрологический…

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

Моделирование

бизнес—процессов в условиях антикризисного…

Возможность декомпозиции объекта.

3. Репин В.В. Бизнес—процессы. Моделирование, внедрение, управление.М.:РИА «Стандарты и качество», 2007.

4. Репин В.В. Бизнес—процессы. Регламентация и управление.

Методы и средства проектирования информационных систем

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

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

Декомпозиция линейной модели квадрокоптера

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

Значение находится из уравнения вертикальной динамики квадрокоптера с допущением, что при данной величине управляющего сигнала БПЛА висит в воздухе…

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

4. Camunda https://camunda.com/products/modeler/ 
Это BPM-движок для автоматизации бизнес-процессов.
— Открытые исходники позволяют однозначно понимать как работает софт, а отличная документация позволяет очень быстро разобраться, как интегрировать движок в свою инфраструктуру.
— Camunda поддерживает последнюю версию Java, или вообще любой JVM-язык.
— Отличная архитектура внутри — движок делает то, что от него ожидается самым очевидным и ожидаемым способом. Нет никаких лишних абстракций, которые необходимо изучать.
— Удобство разработки, тестирования и встраивания в CI\CD за счёт того, что Camunda можно использовать просто как библиотеку в Java-приложении. Camunda не ограничивает разработчика какими-то своими условиями. Используйте любые удобные инструменты — статистические анализаторы, тестовые фрейморвки, средства сборки, средства контроля версий.
Camunda — это также набор приложений Modeler, Task List, BPMN Engine, DMN Engine, Cockpit, Admin,Optimize.
Modeler — это приложение для создания моделей BPMN процессов. Эти модели нужны для других частей системы.
Task list — это веб-приложение, в котором исполнители выполняют задачи, поставленные на них бизнес-процессом.
BPMN Engine — это непосредственно движок, которые отвечает за интерпритацию BPMN в объекты JAVA, сохранение объектов в базе и реализацию других вещей (типа листенеров активностей), которые крутятся вокруг процессов.
DMN Engine — аналогично BPMN Engine, только для DMN (Decision Model and Notation)
Cockpit — это веб-приложение для просмотра состояния процессов. В бесплатной версии он сильно обрезан по функционалу.
Admin — это веб-приложение для управления правами пользователей и пользователями.
Optimize — это веб-приложение для анализа бизнес-процессов. Оно платное.

5. AllFusion Process Modeler http://www.ca.com/ru/default.aspx 
Позволяет проводить описание, анализ и моделирование модели данных, построитель мета-моделей данных. Занимает одно из лидирующих мест в своём сегменте рынка.
Включает три стандартные методологии: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ).

Что такое исполнимые бизнес-процессы. Введение в предметную область / Хабр

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

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

Термин «процессное управление» применяется к двум разным сферам деятельности:

1. В случае, когда не производится автоматизация исполнения бизнес-процессов. Задача — составить описание бизнеса в виде графических диаграмм, которые легко воспринимаются людьми. Такие диаграммы фактически представляют собой специальный язык общения менеджеров, бизнес-аналитиков и руководителей предприятий и используются для выработки и объяснения базовых решений по организации бизнеса предприятия.
2. В случае, когда бизнес-процессы непосредственно исполняются в компьютерной среде предприятия. Будем называть процессы этого вида — исполнимые бизнес-процессы. Для исполнения таких бизнес-процессов на предприятии устанавливается специальная компьютерная система — BPMS (Business Process Managrment System) в английском варианте наименования, или СУБП (Система Управления Бизнес-Процессами) в русском варианте. Этим бизнес-процессам и посвящена данная статья.

Эволюция развития BPMS и «естественный отбор» за примерно 15 — 20 лет привели к тому, что в существующих на рынке BPMS используется одна и та же базовая концепция. В ней к бизнес-процессам относятся два понятия: определение бизнес-процесса и экземпляр бизнес-процесса. Иногда определение бизнес-процесса также называют шаблоном бизнес-процесса. Определение бизнес-процесса содержит схему бизнес-процесса, роли бизнес-процесса, правила назначения исполнителей на роли. Также определение бизнес-процесса содержит описание структур хранения данных.

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

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

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

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

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

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

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

Процессный подход в случае исполнимых бизнес-процессов

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

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

1. На предприятии бизнес-процессы выделены, построены в исполнимом виде и внедрены в эксплуатацию путем загрузки в BPMS. Процессное управление в этом случае является результатом:
   • Действий бизнес-аналитиков, разработавших исполнимые бизнес-процессы, в частности — схемы бизнес-процессов
   • Принятия управленческих решений менеджерами в узлах схем экземпляров бизнес-процессов, имеющих различные возможные варианты дальнейшего движения точек управления
   • Принятия управленческих решений исполнителями заданий при вводе в экземпляры бизнес-процессов данных (от которых существенно зависит их дальнейшее поведение).
2. К процессному управлению относится оперативное изменение схем и других элементов определений бизнес-процессов в ответ на изменение условий бизнеса предприятия.
3. Также к процессному управлению относится косвенное административное влияние на выполнение конкретных экземпляров бизнес-процессов. Например, влияние по «человеческим ресурсам» — менеджмент предприятия может увеличивать или уменьшать количество работников, выполняющих определенные операции, или изменять требования к квалификации работников, выполняющих некоторые действия, а также принимать конкретные кадровые решения, назначая сотрудников на те, или иные роли. Также менеджеры могут анализировать состояния исполняющиеся экземпляров бизнес-процессов, проводить разбор возникающих коллизий и принимать различные административные решения, влияющие на эффективность исполнения экземпляров бизнес-процессов, не изменяя при этом схемы бизнес-процессов.

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

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

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

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

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

Более подробное описание исполнимых бизнес-процессов

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

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

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

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

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

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

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

Рисунок 1. Обозначения узлов: а – начало; б – завершение потока; в – окончание; г – действие

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

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

Узел «действие» генерирует задание исполнителю, обозначается прямоугольником со скругленными углами, в центре которого пишется имя узла (Рис. 1 г)

Узел «исключающий шлюз» может иметь несколько входящих и несколько исходящих ребер. Для каждой пришедшей в него точки управления выбирается, по какому из исходящих ребер она будет перемещена далее. Обозначается ромбом, в котором изображен «крестик» (Рис. 2 а).

Рисунок 2. Обозначения узлов: а – исключающий шлюз; б – параллельный шлюз

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

Рисунок 3. Пример (упрощенный) схемы бизнес-процесса “Оплата счета поставщика”

Переменные бизнес-процесса

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

Роли бизнес-процесса

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

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

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

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

Для выполнения этих функций в BPMS служат следующие графические интерфейсы:

• интерфейсы для работы с заданиями исполнителей
• интерфейсы для работы с загруженными в BPMS определениями бизнес-процессов
• интерфейсы для работы с выполняющимися в BPMS экземплярами процессов
• интерфейсы для администрирования пользователей и групп пользователей
• интерфейсы для настройки замещений исполнителей заданий

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

Типичная BPMS состоит из следующих основных компонентов:

• Среда исполнения бизнес-процессов
• Среда разработки бизнес-процессов и связанных с ними объектов
• Клиент-оповещатель о поступивших заданиях
• Компонент-коннектор к другим информационным системам

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

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

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

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

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

При помощи интерфейсов для работы с заданиями исполнителей пользователь может:

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

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

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

При помощи интерфейсов для администрирования системы администратор может:

• Создавать-удалять пользователей и группы пользователей
• Включать (исключать) пользователей в группы
• Раздавать права на объекты системы пользователям и группам пользователей
• Принудительно останавливать экземпляры бизнес-процессов
• Добавлять, изменять правила замещения пользователей

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

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

Рисунок 7. Пример интерфейса, в котором можно разрабатывать бизнес-процессы

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

Описание работы пользователей и компонентов BPMS

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

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

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

В среде исполнения выполняются экземпляры бизнес-процессов.

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

Web-интерфейсы и клиенты-оповещатели периодически обращаются к среде исполнения и отображают задачи пользователей.

Пользуясь web-интерфейсом BPMS пользователи:

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

Пользуясь web-нтерфейсом BPMS администраторы:

• Загружают или изменяют определения бизнес-процессов
• Создают или изменяют параметры пользователей и групп пользователей
• Раздают права на объекты системы
• Изменяют параметры ботов и бот-станций

При помощи среды разработки аналитики:

• разрабатывают и модифицируют бизнес-процессы

Для разработки бизнес-процесса аналитику надо:

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

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

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

Клиенты-оповещатели сигнализируют пользователям о появлении новых заданий.

Реинжиниринг и эволюционное управление бизнес-процессами

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

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

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

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

Для образного понимания того, как бизнес-процессы используются в качестве инструмента управления бизнесом в случае эволюционного управления с использованием КПЭ А. Белайчук (председатель Ассоциации профессионалов по управлению бизнес-процессами) предложил следующую аналогию: Управление предприятием можно образно сравнить с управлением автомобилем. В этом случае КПЭ являются аналогом того, что видит водитель — вид через лобовое стекло автомобиля и значения показателей датчиков (скорость, давление масла, количество оборотов двигателя, количество бензина и т.п.), а бизнес-процессы выполняют роль руля, педалей (газ, тормоз, сцепление) и рычага переключения передач автомобиля. То есть, служат для непосредственного управления траекторией в пространстве и времени.

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

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

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

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

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

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

Математические основы исполнимых бизнес-процессов

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

Большинство существующих языков описания исполнимых бизнес-процессов в той или иной степени относят к одной из двух математических теорий:

• теория сетей Петри
• концепция Пи-исчисления

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

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

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

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

Концепция Пи-исчисления (Pi calculus) была разработана в конце 80-х годов ХХ века Робином Милнером и основана на алгебре параллельных процессов. В отличие от сетей Петри, математическими объектами Пи-исчисления являются не графы, а выражения над элементами специальных множеств и преобразования над этими выражениями. В настоящее время Пи-исчисление является перспективной, но еще молодой и развивающейся теорией, в ней много открытых вопросов и нерешенных проблем. Математически было доказано, что функциональные возможности Пи-исчисления выше, чем сетей Петри.

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

Бизнес-процессы в новостных СМИ: опыт графической презентации

Business Processes in News Media: the Experience of Graphic Presentation

 

Вырковский Андрей Владимирович
кандидат филологических наук, доцент кафедры теории и экономики СМИ факультета журналистики МГУ имени М.В.Ломоносова, [email protected]

Andrei V. Vyrkovsky
PhD, Associate Professor at the Chair of Media Theory and Economics, Faculty of Journalism, Lomonosov Moscow State University, [email protected]

 

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

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

Abstract
The author considers the process of news production from the viewpoint of operations management. In the article, the capabilities of graphic analysis for researching the business process of text creation are explored and the respective processes are decomposed. Prospective research questions the answers to which are essential in creating the model for the business process of news production are raised in the article.

Key words: operations management, graphic analysis, decomposition of processes, research questions, model for the business process.

 

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

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

С нашей точки зрения, такое положение дел требует, прежде всего, максимально точного понимания того, какие процессы/операции вынужден ежедневно выполнять сотрудник новостной редакции при подготовке информационного продукта. Знание этих процессов, в свою очередь, позволит оптимизировать работу корреспондента.
В данном случае речь идет о так называемом операционном/процессном управлении – вычленении основных типичных рабочих процессов и управлении каждым из них по отдельности. Одним из ключевых принципов операционного управления является так называемая декомпозиция – разукрупнение крупных процессов до все более мелких². Это дает понимание, во-первых, из чего состоит работа сотрудника (в данном случае, корреспондента),   и, во-вторых, какие элементы в ней нужно изменить для получения лучшего результата.
Графическая форма представления модели процессов (бизнес-процессов), протекающих в компании (в данном случае ? в редакции), с нашей точки зрения, является оптимальной благодаря ее наглядности. Попробуем «разобрать» работу современной новостной редакции в таком виде.
В целом работа новостного (да и вообще любого) СМИ может быть представлена в таком виде (Рис. 1).

Рисунок № 1. Принципиальная схема работы редакции СМИ

Мы сознательно оставляем в стороне специфику коммерческой деятельности редакции: это предмет специальных разработок.
Рисунок № 1 иллюстрирует принципиальную схему работы редакции СМИ. Однако она тоже неоднородна: ее условно можно разбить на три блока: «корреспондентский», «редакторский», «выпускающий». Схема бизнес-процессов, протекающих в этих трех блоках в их взаимодействии, достаточно сложна, однако неплохо описана (пусть и с использованием иной терминологии) в отечественных трудах³.

Рисунок № 2. Блоки бизнес-процессов редакции

Безусловно, каждый из блоков включает в себя массу бизнес-процессов, различным образом связанных как внутри каждого из блоков (например, «редактирование текста редактором» ? «просмотр текста главным редактором либо заменяющим его лицом» ? «редактирование текста литературным редактором»; «выгрузка текста на сайт» ? «верстка текста для печатной версии»), так и между различными блоками («сдача текста редактору» ? «постановка дополнительного вопроса редактором» ? «ответ на дополнительный вопрос редактора» ? «постановка дополнительного вопроса редактором» ? «работа над текстом» ? «сдача текста редактору»).
Мы склонны полагать, что именно «корреспондентский» блок бизнес-процессов претерпевает самые масштабные и специфические трансформации в связи с описанными в начале статьи процессами. «Редакторский блок» процессов, по большому счету, испытал «косметические» изменения, связанные, прежде всего, с особенностями работы в редакционно-издательских системах, основа же работы редактора осталась прежней. Процессы «выпускающего блока», безусловно, серьезно трансформировались, но, опять-таки, изменения касаются прежде всего технических аспектов работы редакции:  процедур верстки, выгрузки текстов на сайт, цифровой обработки изображений и т.п.
Поэтому мы сосредоточились на «корреспондентском» блоке процессов, которые выполняются непосредственно журналистами – в конечном итоге именно на их работе «держится» вся редакция.
Очень грубое и приближенное графическое представление «корреспондентского» и – частично – «редакторского» блока процессов дано на рисунке № 3.

Рисунок № 3. Бизнес-процессы в работе корреспондента.

Это крайне грубая схема работы корреспондента, причем  как новостного, так и работающего в аналитических печатных либо онлайновых средствах массовой информации. Процессами, которые не относятся к работе корреспондента, здесь являются «обработка заявки редактором», «обработка текста редактором» (их мы включили в схему для понимания алгоритма работы). Синими стрелками мы обозначили «выходы» «вторичных» бизнес-процессов – тех, которые не имеют альтернативных «выходов». Такие процессы не могут закончиться ничем, т.е. иметь «отрицательный» выход ? поиск темы обязательно должен завершаться подготовкой заявки, сбор информации обязательно должен привести к написанию текста.
Желтые стрелки, наоборот,  «выходы» «первичных» бизнес-процессов ? те, которые могут иметь альтернативу. Так, процесс «обработки заявки редактором» может привести как в процессу «сбор информации» (в случае «положительного» завершения процесса), так и к процессу «поиск темы» ? если заявка отвергнута редактором. Процесс «обработка текста редактором» может трансформироваться, как минимум,  в четыре процесса: «сбор информации» (если для переработки текста необходима дополнительная фактура), «написание текста» (если переработка текста нужна, но возможна без дополнительного сбора информации), «постановка дополнительного вопроса редактором» (и, соответственно, далее ? в «ответ на дополнительный вопрос редактора»), а также «работа корректора» (если текст редактора устраивает, и он, внеся некоторые поправки, готов отдать его в дальнейшую работу по выпуску). Мы не настаиваем на том, что этот список полон, в некоторых случаях он может быть расширен: например, если в редакции выгрузка текста на сайт предваряет  работу корректора. Также в редакции (особенно журнальной) может работать и литературный редактор, возможна также и верстка до начала работы корректора. Тем не менее, это частности, которые фактически не влияют на общий алгоритм.
Как видно из рисунка № 3, большая часть процессов «корреспондентского» блока является «вторичной», то есть должна иметь «положительный выход». В то же время «редакторские» процессы, наоборот, являются первичными, то есть предполагают альтернативные «выходы».
Таким образом, описанная выше схема, как мы уже отмечали, является  грубой и, кроме этого, может относиться к любому печатному или онлайновому СМИ.
Для того чтобы понять специфику работы новостной редакции и особенности ее трансформации, необходимо провести декомпозицию основных процессов «корреспондентского» блока: «поиск темы», «сбор информации» и «написание текста».
Принципиальным для работы по декомпозиции этих процессов является выявление и графическое отображение количества, типа/вида и порядка/иерархии выделяемых более мелких бизнес-процессов.
Попробуем схематично изобразить декомпозицию процесса «поиск темы». Сразу оговорим: мы не пытаемся дать его исчерпывающее  описание. Для этого необходимо серьезное, масштабное исследование, провести которое мы планируем в ближайшем будущем. Пока же это – попытка концептуализации того, как работают новостные масс-медиа (см. рис. №4).

Рисунок № 4. Декомпозиция бизнес-процесса «поиск темы»

Приведенная выше схема декомпозиции бизнес-процесса «поиск темы» представлена в упрощенном виде: мы не отмечали многочисленные варианты «закольцовывания» процессов, а также не выделяли взаимосвязи между ними. Помимо этого, приведенный нами список процессов не является исчерпывающим (именно поэтому мы оставляли незаполненными последние элементы схемы).
Тем не менее, даже в таком виде схема требует некоторой расшифровки.
Прежде всего, в схеме не только приведены бизнес-процессы как таковые, но и дана приблизительная классификация этих процессов («активные способы поиска» ? «пассивные способы поиска»; «интернет-поиск» ? «“телефонный” поиск» ? «“личный” поиск» ? «поиск “по интернет-почте”»; «агрегация входящей информации» ? «агрегация заданий»).
Кроме того, несмотря на то что в схеме мы отмечали приблизительный порядок выполнения бизнес-процессов («1…», «2…», «3…» и т.п.), это вовсе не означает, что реальная работа над материалом простроена именно таким образом. Во-первых, некоторые операции могут проводиться параллельно, во-вторых, многие процессы взаимосвязаны (так, положительное завершение одного процесса может означать остановку всех остальных). И, наконец, самое главное: каждый материал корреспондента уникален, поэтому идеальной схемы бизнес-процессов как таковой вообще не существует, можно описать только наиболее распространенные варианты таких схем. А это требует дальнейшего эмпирического исследования.
Следует отметить интересный факт: декомпозиция любого из базовых процессов в работе журналиста («поиск темы», «сбор информации», «написание текста») дает множество мелких бизнес-процессов «первичного» вида – они имеют альтернативные «выходы». Так, любой из процессов, направленных на поиск темы, может быть закончен подготовкой заявки, но в то же время он может быть закончен и ничем: после его завершения корреспондент перейдет снова к процессу поиска темы, правда, другого вида. Но базовый процесс «поиск темы» вторичен: он не имеет альтернативного «выхода», тема в любом случае должна быть найдена.
Из-за того, что на данном этапе нашего исследования невозможно создание принципиальной схемы (схем) базовых бизнес-процессов работы над новостью, мы не стали проводить соответствующую схематизацию процессов «сбор информации» и «написание текста». Однако мы считаем, что в данной статье доказали возможность графического анализа и обозначили его перспективы при исследовании процессов, направленных на подготовку новостного материала.
Конечно, построение принципиальной схемы работы корреспондента новостного масс-медиа требует дальнейшего исследования.
Учитывая, что принципиальным в этом случае является знание количества, типа/вида и порядка/иерархии бизнес-процессов,  необходимо в ближайшее время выполнить следующие задачи (в отношении как печатной, так и онлайн-версии СМИ):

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

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

 

---

1. См.: Вырковский А.В. Операционный менеджмент в СМИ: актуальные вопросы / Ежегодник 2012. Экономика и менеджмент СМИ / Отв. ред. и сост. Е.Л.Вартанова. М., 2013.
2. Стерлигова А.Н., Фель А.В. Операционный (производственный) менеджмент: Учеб. пособие. М., 2009. С. 112.
3. См.: Гуревич С.М. Газета: вчера, сегодня, завтра. М., 2004.

(PDF) Разложение моделей бизнес-процессов на многоразовые поддиаграммы

модели процессов [3]. Это осуществляется путем идентификации структур

SESE (Single Entry, Single Exit) в дереве процесса

. Milani et al. [4] обсуждают критерии и эвристику для декомпозиции модели

. Они также предоставляют оценку

относительно влияния этих критериев на понятность

выбранных моделей. Процедура декомпозиции

может поддерживаться путем обнаружения имен не-

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

более быстрое создание согласованных сложных моделей [5].

Другое решение обсуждаемой проблемы было представлено

в [6], где бизнес-процессы были представлены как

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

динамического создания моделей совместного бизнеса

процессов.

Эта статья также имеет отношение к структурированным и формальным представлениям процесса

, которые облегчают моделирование процесса

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

является представление

на основе электронных таблиц [7], где набор действий перечислен в таблице

с указанными ветвями и условиями маршрутизации.

Модели процессов, пригодные для перекомпоновки, также могут быть описаны в декларативной спецификации [8],

фокусируется на ограничениях и зависимостях между

действиями вместо определения явной последовательности

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

вместе с их входными и выходными

условиями, которые затем используются для композиции процесса

на основе ограничений [9]. Другой подход — семантическая модель

для BPMN, заданная в алгебре процессов CSP

[10]. Это особенно полезно для определения временных ограничений

между действиями процесса.

Репозитории моделей процессов — важный инструмент

в области редизайна бизнес-процессов.Они могут быть разработаны в виде базы данных

, хранящей соответствующие фрагменты процесса

со ссылкой на метаданные процесса

[11]. Такой подход приводит к автоматизированному созданию сложных моделей

. В случае такой композиции

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

. Следовательно, необходимо упомянуть

об идентификации и оценке проблем

, касающихся согласованности потока [12], а также макет

сгенерированной модели бизнес-процесса [13].Автоматическое моделирование процессов

должно также включать проверку

, содержит ли созданная модель какие-либо типичные аномалии

, такие как взаимоблокировки, живые блокировки или отсутствие синхронизации

[14] [15] или аномалии событий

[16]. Анализ формальных аспектов модели BPMN

также может быть проведен с использованием языка Alvis Modeling

Language [17].

3 Модели бизнес-процессов

Высокоразвитые программные системы присутствуют во многих областях

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

систем человеко-машинного интерфейса до управления производством

и веб-сервисов, охватывающих

больших область реализаций.Для обеспечения надежности и эффективности таких систем

и упрощения этапов проектирования и разработки

используются усовершенствованные инженерные подходы к процессу

.

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

, которое представляет собой набор методов

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

, изображающих бизнес-процесс с его

зависимостями. Таким образом, модель бизнес-процесса

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

.

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

моделей является спецификация Manufacturing Execution

Systems (MES) [18]. Построение полной среды моделирования

для интеграции технической модели системы и функциональной модели

, а также модели производственного процесса

обеспечивает понятность спецификации для всех

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

3.1 Модель бизнес-процесса и нотация

Модели бизнес-процессов в нотации BPMN — это

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

[19].Визуализация потоков операций

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

. Это прозрачный визуальный инструмент

, предназначенный для моделирования сложных процессов.

Элементы модели

BPMN можно разделить на четыре основные группы

: объекты потока, соединяющиеся объекты,

дорожек и артефакты. Объекты потока представляют собой

основных элементов диаграммы процесса. В этом наборе можно выделить три основных типа объектов

[1]:

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

, которая должна быть выполнена в процессе,

— события (кружки), которые представляют происходящие инциденты. на

время выполнения процесса,

— шлюзы (ромбики), которые контролируют поток токенов в

процессе.

Есть два вида деятельности: задачи и подпроцессы

. Задача — это элементарное действие, которое может быть выполнено человеком

или выполнено как автоматическое действие

. С другой стороны, подпроцесс — это составная деятельность

, представляющая сложную работу, делимую на

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

.

Набор событий охватывает три типа элементов: начало

событий, которые указывают начало процесса с

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

конец пути в процессе или подпроцессе, а также

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

внутри процесса.

Шлюзы управляют потоком процесса, разделяя его на

ветвей и присоединяя их впоследствии. Наиболее типичные шлюзы

BPMN основаны на данных, что означает, что они

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

не могут принять решение относительно потока процесса [20]. Шлюзы

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

на основе заданных данных процесса, включая

(OR), которые предшествуют потенциально параллельным ветвям, а также

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

оформлено без каких-либо условий.

Набор наиболее часто используемых объектов потока BPMN

представлен на рисунке 2.

ITM Web of Conferences 15, 01002 (2017) DOI: 10.1051 / itmconf / 20171501002

CMES’17

2

A целостный подход к декомпозиции бизнес-процессов | Карло Марколи

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

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

Эта статья была первоначально опубликована по адресу ibm.com/developerworks в мае 2013 года.

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

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

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

IBM разработала набор карт возможностей для каждой отрасли, который называется Component Business Models (CBM). Карты организованы в ряды, классифицирующие уровни подотчетности, от стратегии до контроля и исполнения, и столбцы, предназначенные для различных областей производственно-сбытовой цепочки предприятия. Поскольку элементы модели возможностей внутренне очень связаны и слабо связаны друг с другом, их границы обеспечивают надежное руководство для ограничения объема усилий по моделированию процесса, которые не будут иметь слишком много внешних зависимостей.Вы также не должны недооценивать ценность возможности сообщать на одной странице объем ваших усилий в контексте всей организации, просто выделяя рассматриваемые компоненты, как показано на Рисунке 1.

Рисунок 1. Компонентная бизнес-модель для розничной торговли банковское дело

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

3.1 Процесс и структурный анализ

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

Рисунок 2. Поведенческая декомпозиция арендованного автомобиля

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

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

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

Рисунок 3. Структурная декомпозиция операций по аренде автомобилей.

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

3.2 Анализ информации

Часто данные рассматриваются как второстепенное при определении решения BPM. Действия и их потоки — это основные абстракции, используемые бизнес-сообществом и дизайнерским сообществом. Только на более позднем этапе вы понимаете, что ключевые термины, такие как «учетная запись», «клиент» или «продукт», имеют разное значение в разных частях бизнеса. Это приводит к неуправляемым изменениям в реализации процесса.Бизнес-глоссарий, иногда называемый словарем данных, является основополагающим артефактом, который должен содержать точные семантические определения, согласованные во всей организации, терминов, связанных с инициативой. Модель данных также важна для определения отношений между информационными объектами, а также их ключевых атрибутов.

Анализ информации также играет важную роль в декомпозиции процессов, помогая распутать описание бизнес-операций. Идея состоит в том, чтобы сместить акцент в бизнес-моделировании с «предпринятых действий» на «сущности», в отношении которых действуют.Эти объекты, такие как Заказ, Запрос, План или Счет-фактура, представляют собой информацию, используемую предприятиями для отслеживания своих деловых операций; они являются основными концептуальными объектами, которые создаются, развиваются и (обычно) архивируются в процессе. Например, когда клиенты банка снимают деньги со своих счетов, они заполняют бланк снятия средств и передают его кассиру. Кассир использует квитанцию ​​для проверки данных счета клиента и, в зависимости от суммы, запрашивает одобрение менеджера.Менеджер утверждает, подписывая квитанцию ​​и возвращая ее кассиру, который передает запрошенные деньги клиенту, а затем подает квитанцию ​​для банковских записей. Хотя в примере упоминаются такие имена, как счет и клиент, «квитанция о снятии средств» является ключевой бизнес-единицей, которая фиксирует все важные данные, относящиеся к процессу снятия средств: описание его жизненного цикла является эффективным способом описания того, как работает этот процесс.

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

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

Рис. 4. Операции поставщика ИТ-услуг, описанные как поток действий

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

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

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

Рисунок 5. Основные сущности для операций поставщика ИТ-услуг

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

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

Например, рассмотрим декомпозицию процессов продаж и управления персоналом банка. В отделе продаж при подключении нового клиента банк выполняет процесс идентификации и подтверждения клиента, чтобы убедиться, что клиент является тем, кем он себя называет (ID&V означает идентификация и проверка).С другой стороны, в области управления персоналом банк выполняет идентификацию и подтверждение сотрудника каждый раз, когда к организации присоединяется новый человек. Это два разных процесса или один и тот же (см. Рисунок 6)?

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

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

Рисунок 7. Измерения определения бизнес-процесса

4.1 Владение

Владение процессом определяет, кто несет конечную ответственность за то, что делает процесс, и как им управлять.Отсутствие четкого владения сделает любой процесс неуправляемым, как только он будет запущен. Это особенно очевидно в инициативах BPM, направленных на упрощение и унификацию процессов. Рассмотрим организацию, в которой разные отделы запускают независимые варианты одного и того же процесса. Что произойдет, если новое общее решение автоматизации процессов будет развернуто в разных отделах, если структура владения процессами также не изменится? Множественные владельцы, мотивированные разными драйверами бизнеса, скоро найдут способы обойти ИТ, и процессы будут расходиться.

Вернемся к примеру процесса ID&V в банковском деле: для общего процесса ID&V клиента и сотрудника потребуется один владелец. Где бы он или она сидели? В HR или в продажах? В любом случае это, кажется, вводит ненужные зависимости между отделами, которые по своей природе имеют тенденцию быть совершенно независимыми друг от друга. Это соображение указывает на возможность моделировать и управлять двумя процессами как независимыми активами. Фактически, анализ ценностного предложения идентификации и проверки (описанного в следующем разделе) показывает, что отдел по борьбе с мошенничеством банка является естественным владельцем всей деятельности ID&V.

4.2 Ценностное предложение

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

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

Рисунок 8. Продажи и HR используют один процесс ID&V, принадлежащий Anti-Fraud

4.3 Ключевые действия и ресурсы

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

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

Рис. 9. Пример процесса ID&V

Область, выделенная фиолетовым цветом, описывает действия, направленные на обработку документации. Для этого требуются человеческие и технические ресурсы с возможностями обработки документов, которые не имеют прямого отношения к ID&V.Поэтому мы можем рассматривать эти действия как отдельный процесс, получение документа, способный работать с любым документом (даже не связанным с ID&V), хранить его, связывать его со ссылкой и транслировать информацию любому процессу, который может быть в нем заинтересован. В самом деле, банки обычно имеют функции управления документами с этими обязанностями, как показано на рисунке 10.

Рисунок 10. Действия по обработке документов можно вынести за рамки ID&V и сделать их повторно используемыми в более широком контексте

4.3 Клиенты и поставщики

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

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

Рисунок 11. Клиенты и поставщики процесса ID&V

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

4.4 Информационная модель

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

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

Например, способ, которым ID&V выполняется в контексте продаж, может сильно зависеть от типа продукта, на который претендует человек. Если вы подаете заявку на ссуду, банк может захотеть провести более строгую проверку, чем та, которая требуется для сберегательного счета.Если «Продукт» является входом процесса, ID&V необходимо будет знать обо всех предложениях банка и правилах, которые будут назначать разные уровни проверки для разных продуктов. Альтернативный подход может заключаться в том, чтобы сохранить какие-либо знания о продукте вне процесса и попросить инициатора запроса процесса указать в качестве входных данных только требуемый уровень проверки. Это единственное изменение в определении ввода значительно упрощает процесс и делает его более пригодным для повторного использования при адаптации сотрудников. На самом деле концепция продукта не имеет никакого значения в HR, хотя имеет смысл запрашивать разные уровни проверки в зависимости от должности, на которую человек присоединяется к организации.

4.4 События

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

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

В нашем примере внешние события, обрабатываемые процессом, включают получение нового запроса ID&V (начало процесса) и уведомление о прибытии документа. Исключительные события могут быть связаны с отменой запроса ID&V или длительной задержкой доставки документа.

4.5 Метрики и KPI

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

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

4.6 Бизнес-политики

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

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

4.7 Изменчивость процесса

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

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

Рис. 12. Анализ процесса, ориентированный на вариативность

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

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

Я хотел бы поблагодарить Хью Бойда, Яна Рамзи и Ким Кларк за их вклад и обзоры этой статьи.

Функциональная декомпозиция

Что такое функциональная декомпозиция?

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

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

Ключевые выводы

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

Общие сведения о функциональной декомпозиции

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

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

Диаграммы функциональной декомпозиции

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

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

Приложения функциональной декомпозиции

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

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

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

Этапы функциональной декомпозиции

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

1. Найдите основную функцию : Какую основную задачу должно выполнять устройство или процесс?
2. Перечислите основные подфункции : Эти подфункции или подзадачи способствуют успешному выполнению основной функции.
3. Перечислить подфункции следующего уровня : Эти подфункции обслуживают подфункции верхнего уровня.
4. Проверьте диаграмму : Если есть функции, которые были пропущены, добавьте их в диаграмму.

Разбиение сложного на простое — Процесс декомпозиции

В моей последней статье мы обсуждали важность:

• Общие сведения о вашей организации
• Определение четкой терминологии
• Обучение организации таким условиям
• Определение общего метода или подхода

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

Вот как я подхожу к этому:

• Во-первых, разберитесь с организацией в целом. Мы обсуждали важность этого в моей последней статье.
• Во-вторых, сосредоточьтесь на аспекте организации (это может быть один отдел, направление бизнеса и т. Д.). Не пытайтесь понять все за один раз, так как это станет невыносимым.
• Целостное понимание того, как сочетаются части, но по возможности сосредотачивайтесь на определенной части организации.Это также будет зависеть от того, насколько велика или мала организация.
• В-третьих, задайте вопрос: «Какие основные функции выполняются в зоне фокусировки?»
• В-четвертых, для каждой функции разбейте, какие процессы выполняются на очень высоком уровне.
• Задокументируйте имя и цель процесса.
• Задокументируйте начальную и конечную точки процесса.
• Задокументируйте основные действия, выполненные в процессе.
• В-пятых, проанализируйте данные, чтобы определить, является ли процесс «действительно» процессом или потенциально этапом действия, противоположным процессу.

Давайте рассмотрим пример, чтобы прояснить это.

Пример: ABC Organization (многопрофильный универмаг)

Шаг 1 : Понять организацию (различные области в универмаге)

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

Шаг 3 : Каковы основные компоненты подразделения Appliance Division в рамках домашней организации?

• Продажа бытовой техники
• Финансовые инструменты
• Управление запасами
• Пополнение запасов техники
• Финансирование

Шаг 4 : Какие процессы выполняются для управления запасами?

• Получить одобрение на инвентаризацию заказа
• Опись заказа
• Проверить правильность полученной инвентаризации
• Инвентаризация бытовой техники
• Обработка жалоб клиентов

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

Пример процесса: Обработка жалоб клиентов

• Определение процесса: в этом процессе описывается, как жалобы клиентов обрабатываются в подразделении бытовой техники ABC Organization. Это позволяет организации гарантировать, что жалобы клиентов принимаются и обрабатываются как можно быстрее.
• Запускается: когда клиент звонит или отправляет письменную жалобу в компанию.
• Окончание: Когда жалоба будет разрешена.
• Мероприятия выполнены (на высоком уровне)
• Получение жалобы клиента
• Жалоба клиента на исследование
• Определение результата жалобы клиента
• Сообщить клиенту о результате жалобы

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

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

Бизнес-процессы и логическое моделирование процессов — Обзор — TDAN.com

Опубликовано в TDAN.com апрель 2000 г.

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

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

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

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

Бизнес-процессы состоят из множества компонентов, в том числе:

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

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

Моделирование логических процессов

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

• Сбор данных, в отношении которых необходимо действовать
• Управление доступом к данным во время выполнения процесса
• Определение того, какая рабочая задача в процессе должна быть выполнена следующей
• Доставка соответствующего подмножества данных в соответствующую рабочую задачу
• Обеспечение наличия всех необходимых данных и выполнения всех необходимых действий для каждой задачи
• Обеспечение механизма, указывающего на принятие результатов процесса, например, электронные «подписи»

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

Движение данных и принятые решения, определяющие пути данных во время процесса, составляют модель процесса.Он содержит только бизнес-деятельность, использует бизнес-терминологию
(не программные сокращения, технический жаргон и т. Д.), Полностью описывает деятельность моделируемой бизнес-области и не зависит от какого-либо лица или должности, работающих в организации
. Как и его аналог, Logical Data Modeling, Logical Process Modeling не включает в себя избыточные действия, действия, зависящие от технологии, физические ограничения или требования, или
текущие системные ограничения или требования.Модель процесса — это представление бизнес-точки зрения на набор анализируемых действий.

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

Проблемы с немоделированной системой включают следующее:

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

Учебник по моделированию логических процессов

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

Моделирование логических процессов

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

• Письменное описание процесса
• Блок-схемы
• Диаграммы потоков данных
• Иерархии функций
• Модели или конечные автоматы в реальном времени
• Диаграммы функциональных зависимостей

Функция — это высокоуровневый вид деятельности организации; процесс — это деятельность в сфере бизнеса; последовательный процесс — это деятельность самого низкого уровня. Следовательно:

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

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

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

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

Моделирование физических процессов

Методы физического моделирования определяют топологию (связность), данные, роли и правила бизнес-процесса. Эта модель описывает такие предметы, как:

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

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

Подход к определению процесса, основанный на данных

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

Основные моменты, представляющие интерес при построении модели логического процесса:

• Цель процесса. Написание цели и ссылки на нее часто позволяют аналитику распознать шаг в процессе, который не имеет смысла в контексте процесса.
• Кто будет участвовать в процессе. Участниками могут быть люди, группы людей или электронные приложения.
• Порядок выполнения шагов процесса.
• Данные, которые вы ожидаете включить в процесс. Существует начальный набор ожидаемых данных, плюс вы должны знать, какие данные вы ожидаете изменить или добавить в процессе. Частью этого шага
  является решение, какое подмножество данных подходит для каждой задачи в процессе.
• Решения, которые будут приняты во время выполнения процесса. К ним относятся решения о том, какой путь должен идти процесс, и присутствуют ли все требуемые данные в любой заданной точке
  процесса.
• Правила, которые вы будете использовать для определения различных частей процесса. Также обратите внимание на любые соглашения об именах, которые важны для бизнеса.
• Расположение данных в конце процесса. То есть данные будут сохранены или удалены? Если вы планируете хранить данные, где и в какой форме они будут храниться? Нужен ли в будущих отчетах
  , связанных с процессами, доступ к данным?

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

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

Построение диаграмм модели процесса

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

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

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

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

Наконец, укажите конечную точку (точки) процесса. Это указывает на то, что процесс завершен и что все данные, сгенерированные процессом, могут быть идентифицированы.

Обзор модели

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

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

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

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

Резюме

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

Иерархия бизнес-процессов | Структура бизнес-иерархии

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

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

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

Иерархия бизнес-процессов

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

Ниже приведены уровни иерархии бизнес-процессов:

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

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

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

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

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

Знать об иерархии маркетингового бизнеса: нажмите здесь

Разложенные процессы и подпроцессы

Разложенные процессы и подпроцессы

Глава 5 Построение модели бизнес-процесса анализа

---

Декомпозированные процессы и подпроцессы

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

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

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

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

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

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

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

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

Составной вид

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

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

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