Декомпозиция бизнес процессов и характеристики
Если всю деятельность компании можно разделить на бизнес процессы, то и процессы можно разделить на более мелкие составляющие. В методологии построения бизнес процессов это называется “декомпозиция бизнес процессов”. Цель декомпозиции очень проста – если большим процессом сложно управлять, его необходимо разделить на части. Проектирование бизнес процессов позволяет нам «разбирать» и «собирать» процессы, изменяя их размер. Об этом, а также характеристиках процессов мы и поговорим.
Итак, процесс можно разбить на более мелкие части:
Подпроцесс. Если нам необходимо разделить процесс на части для более легкого управления мы будем делить его на подпроцессы. Подпроцесс можно рассматривать отдельно. Он имеет такие же составляющие и свойства. У подпроцесса так же есть начало, окончание, механизм реализации, показатели и т.д. Иными словами, подпроцесс – это процесс более низкого уровня. В принципе, количество уровней, подпроцессов, на которые мы делим процесс, может быть безграничным. Когда мы собираемся приготовить обед, то мысленно делим процесс на подпроцессы – подготовка продуктов, подготовка посуды, обработка продуктов, приготовление.
Операция. Это самое простое действие в процессе. “Простое” означает, что его не надо детализировать. Если процесс не имеет вложенных подпроцессов, то его механизм реализации как раз и представляет собой цепочку операций. Когда мы готовим посуду для приготовления обеда, то выполняем простые операции: достать кастрюлю, налить в нее воду, поставить на плиту и так далее. Нет смысла подробно объяснять, что значит «налить воду в кастрюлю», а значит, это операция.
Насколько необходимо детализировать процессы?
Ровно настолько, насколько вам это необходимо;) Да, это правда. Все зависит от цели описания бизнес процесса. Если нужно подробное описание для новичка, то и детализировать необходимо максимально. Таким образом, кстати, можно готовить инструкции для некоторых подпроцессов. Если же вы делаете общую модель, то достаточно общих, объемных операций. К примеру, подготовка квартального отчета, тоже может быть операцией. А может и подпроцессом с большим количеством уровней. Мы еще вернемся к этому вопросу в теме про подготовку описания процессов.
Группировка операций и подпроцессов.
Иногда необходимо объединить некоторые операции или подпроцессы – чтобы ими было легче оперировать. К примеру, можно выделить:
- Работы – это процессы и/или операции, которые выполняет один человек или одно подразделение. Например, для дворника такой работой является уборка мусора.
- Функции – совокупность работ, похожих друг на друга или имеющих что-то общее. Продажи – это функция. А обработка заявок по продажам – работа.
По сути, можно спокойно обойтись без такой группировки. В своей работе я стараюсь избегать подобных усложнений.
Но есть один очень полезный тип группировки – Процедура. Процедура – это цепочка операций. При этом такая цепочка может иметь только один вариант порядка действий, а операции выполняются одна за одной, без перерыва. Процедуры удобны для подготовки инструкций.
Характеристики бизнес процесса.
Любой бизнес процесс необходимо как-то оценивать. Оценка позволяет быстро понять, какие процессы требуют пристального внимания и должны меняться в первую очередь. Это позволяет найти слабое звено во всей системе бизнес процессов. Любой процесс можно охарактеризовать по следующим критериям:
- Результативность – достигает процесс необходимых результатов или нет. Если в результате процесса «Приготовление пирога» получился яблочный пирог, то процесс результативен.
- Эффективность – сколько ресурсов затрачивает процесс на получение результата. Если вы знаете, что на приготовление пирога должно уйти 0,5 кг яблок, а было потрачено 2 кг, то процесс неэффективен.
- Определенность – если процесс описан в каком-то документе, и то, как он выполняет в действительности, соответствует тому, что написано, значит, процесс определен. Если пирог был приготовлен полностью по рецепту, все ок.
- Повторяемость – важнейшая характеристика! Она показывает, может ли процесс получать одинаковые результаты из раза в раз. Если повар постоянно выдает разные яблочные пироги, что-то не так с процессом. Или с поваром.:)
- Адаптируемость – характеристика гибкости бизнес процесса, т. е. способности меняться в зависимости от условий. Можно ли быстро заменить яблоки на груши? Можно. Значит, процесс адаптируем.
- Длительность – время, которое необходимо для выполнения процесса. Иными словами, промежуток времени между началом процесса и его завершением.
- Стоимость – это совокупность всех затрат выполнения процесса 1 раз. Для этого необходимо подсчитать, сколько продуктов мы затратили на приготовление пирога, сколько стоит время повара, который его готовил, а также сколько стоит использование инструментов и посуды.
Данные характеристики являются основой бизнес процессов. Но никто не запрещает вам добавлять их, сократить или расширить.
Итак. Методология бизнес процессов помогает нам разбивать крупные процессы на подпроцессы и операции. Операция – самая простая составляющая процесса. При создании бизнес процессов необходимо учитывать их характеристики. Более того, построение системы бизнес процессов невозможно без построения системы характеристик. Построение системы бизнес процессов начинается с карты процессов, но об этом уже в другой раз.
Вернуться на Главную?
rzbpm.ru
«Деловой журнал» Как сделать декомпозицию бизнес-процесса
Недавно потенциальный заказчик услуги описания бизнес-процессов задал мне интересный вопрос: по каким принципам делается
Ответ на этот вопрос очень простой. Каждый бизнес-процесс декомпозируется на бизнес-процессы управления объектами, которыми нужно управлять на этом уровне. Например, самый общий бизнес-процесс предприятия («контекстный» в терминологии IDEF0) декомпозируется на бизнес-процессы управления клиентами, поставщиками товаров и услуг, производством товаров или услуг, персоналом, инфраструктурой, финансами и т. д.
Однако, мой собеседник продолжал настаивать: «Как именно для декомпозиции бизнес-процессов
Уже потом, после переговоров, я понял, почему декомпозиция бизнес-процессов не составляет затруднения у меня, но вызывает вопрос у заказчика. У каждого специалиста в области описания бизнес-процессов есть проверенная годами структура декомпозиции, которая для конкретного предприятия лишь настраивается. Такая структура позволяет без затруднений правильно составить иерархию объектов управления для декомпозиции бизнес-процессов на каждом уровне.
«Правильная» структура бизнес-процессов доступна и неспециалистам. Достаточно воспользоваться, например,
Есть способ, который позволяет если не сделать декомпозицию бизнес-процессов, то по крайней мере проверить её необходимость и достаточность. В статье «Использование системы показателей для улучшения бизнес-процессов» я писал о том, что декомпозиция бизнес-процессов должна соответствовать иерархии системы показателей.
Как
Теперь давайте вернёмся к декомпозиции бизнес-процессов. Если в декомпозиции бизнес-процесса, соответствующего цели верхнего уровня, присутствуют бизнес-процессы, необходимые и достаточные для достижения этой цели, значит декомпозиция выполнена правильно.
Приведу пример. Предположим, мы декомпозируем «контекстный» бизнес-процесс. Определили одну из его целей – увеличение масштаба бизнеса. Определяем инициативы для достижение этой цели – расширение клиентской базы, увеличение ассортимента. Значит в декомпозиции «контекстного» бизнес-процесса обязаны быть бизнес-процессы управления отношениями с клиентами и поставщиками. Для выполнения этих бизнес-процессов необходимо управлять персоналом, финансами и инфраструктурой предприятия. Таким образом декомпозиция «контекстного» бизнес-процесса в отношении цели «увеличение масштаба бизнеса» определилась.
blog.dp.ru
Проектирование модели бизнес-процессов | Открытые системы. СУБД
Сегодня нет еще методик проектирования архитектуры бизнес-процесса, как следствие, аналитики либо изображают сквозные процессы как монолитные и не выделяют подпроцессов, либо наоборот — неоправданно дробят их на модули, которые не могут быть использованы повторно. Однако плохо структурированный процесс часто скрывает важное, выпячивая второстепенное, например, банковские аналитики считают каждый вид кредита отдельным типом процесса, но структуризация помогает увидеть, что процессы выдачи разных видов кредита отличаются лишь разными комбинациями стандартных, повторно используемых модулей. Это может упростить продуктовую линейку. Правильно спроектированная архитектура помогает сократить число рассматриваемых процессов и улучшает управляемость ими. В случае создания исполняемой модели бизнес-процесса ошибка при проектировании его архитектуры сделает работу невозможной.
Какие могут быть критерии декомпозиции сквозного процесса на подпроцессы и как описать механизм связывания подпроцессов в цепочку? Ответы на эти вопросы помогут аналитику правильно проектировать архитектуру процесса, сделав его работу менее субъективной, превратив ее в инженерную деятельность.
Текущее состояние
Часто сквозные процессы делят на модули, исполняемые целиком внутри организационных единиц компании, — их называют бизнес-процессами подразделения [1]. Такой способ локализации бизнес-процесса в рамках одного структурного подразделения свойственен функциональному подходу к управлению организацией и может противоречить основной цели моделирования — переходу к процессному управлению. Рекомендуется выявлять процессы с помощью цепочек создания ценностей [2]. Для этого предлагается: выявить клиентов компании; определить, какие продукты потребляют эти клиенты; определить поток преобразования продуктов или услуг, итогом которого является результат, ценный для клиента компании. Если компания выпускает материальный продукт, то определение цепочки создания ценности является относительно простой задачей, однако если компания предоставляет услугу, то обнаружение цепочки ее создания существенно сложнее.
Чтобы сделать схему процесса читаемой и понятной, предлагается создавать иерархическую модель, где верхний уровень дает самое общее представление о ходе исполнения процесса, а все детали исполнения «спрятаны» на нижних уровнях [3]. Идея правильная, однако непонятно, как построить иерархию процесса, раскрывая его снизу вверх.
В качестве критерия разделения сквозного процесса на цепочку взаимодействующих подпроцессов ряд авторов советуют анализировать выходы одного этапа процесса и входы следующего [4]. Действительно, если вход и выход соотносятся как 1:1, то процесс можно рассматривать как монолитный, но если соотношение имеет вид 1:М или М:1, то это свидетельствует о разделении процесса на подпроцессы.
Таким образом, на сегодняшний день нет общепринятого критерия деления сквозного процесса на подпроцессы, и при отсутствии системного подхода аналитики полагаются на интуицию, а не на методологию. Как следствие, многие модели содержат ошибки, например до 20% моделей, включенных в справочник референтных моделей SAP, ошибочны [5].
Объект управления
Бизнес-процесс оперирует одним или несколькими информационными объектами. Один из них будем называть основным, если он: является ключевым для данного бизнес-процесса; связывает вход и выход процесса; может содержать (ссылаться на) другие информационные сущности. Если объект является ключевым для процесса, то это означает, что он фиксирует результат исполнения очередной операции, отдельного этапа или всего процесса целиком и передает его на вход следующей операции, этапа или процесса. Тем самым он связывает выходы и входы. Вспомогательными будем называть остальные информационные объекты, которые фиксируют изменения данных, но не результат выполнения операций.
Объект управления играет роль переменной состояния, определяющей статус всей системы в данный момент времени, — его движение будем трактовать как поток управления, где прибытие определяет начало исполнения соответствующей операции. Будем выделять совокупность смежных работ, ссылающихся на один и тот же документ или информационную сущность, которую можно трактовать как объект управления. Таким образом, мы разобьем сквозной процесс на фрагменты, каждый со своим объектом управления.
Одно инициирующее стартовое событие процесса должно создавать один отклик на его выходе. Будем иметь в виду, что каждый результат на выходе бизнес-процесса должен быть индивидуально идентифицируем, чтобы можно было посчитать количество продуктов, полученных за определенный интервал времени [5]. Если предположить, что одно входное воздействие может сгенерировать несколько выходных, то следует допустить, что их число может оказаться неисчислимо большим и результат не сможет быть подсчитан. Конечно, можно представить процесс, который на одно входное воздействие будет генерировать выходной сигнал с определенной периодичностью, однако вряд ли это входит в задачу моделирования бизнес-процесса — скорее, программирования конечного автомата.
Здесь ограничимся рассмотрением только бизнес-процессов, генерирующих один выход на каждое входное воздействие. Если аналитик столкнется с ситуацией, когда один вход генерирует несколько выходов, то он может с уверенностью считать, что в ходе исполнения происходит смена объекта управления, один процесс порождает несколько подпроцессов-потомков, которые в сумме создают необходимое число выходов.
Декомпозиция процесса
Для выявления фрагментации процесса аналитик должен следить за основным информационным объектом — его смена свидетельствует о разделении сквозного бизнес-процесса на подпроцессы. Например, клиент размещает заказ, состоящий из нескольких позиций, — основным объектом на этом этапе является заявка. По каждой позиции необходимо отдельно проверить наличие изделий на складе — основной документ изменился, и теперь это накладная. Если все позиции доступны, то можно собрать их в единую посылку, и теперь основной документ — ведомость отправки. Таким образом, одна заявка порождает несколько накладных, которые будут обрабатываться параллельно, но затем они будут снова собраны вместе и образуют один документ — накладную. Иначе говоря, одной заявке на входе процесса соответствует одна посылка заказчику на выходе. В этом процессе выделено три этапа: оформление, исполнение и отправка — каждый со своим объектом управления. Сквозной процесс можно разделить на три подпроцесса, по числу выделенных этапов.
Теперь рассмотрим другую ситуацию. Клиент размещает заказ, состоящий из нескольких позиций, и проводится проверка наличия требуемых изделий на складе. Предположим, что какие-то изделия отсутствуют и их надо изготовить. Детали, которые есть в наличии, можно отправить заказчику сразу, и при этом на этапе оформления доставки к ним будут добавлены изделия, которые были заказаны ранее по другому заказу. Имеет место перегруппировка отдельных потоков разных заявок. Однако, чтобы окончательно закрыть исходный заказ, надо убедиться, что все изделия, сгруппированные в разные посылки, доставлены заказчику. В этом примере происходит многократная перегруппировка потоков управления, что приводит к дроблению основного процесса. В этом процессе также можно выделить три подпроцесса, но соотношение входов и выходов сложнее — одному заказу соответствуют несколько посылок заказчику. Сквозной процесс обязательно разделится на подпроцессы.
Чтобы обнаружить фрагментацию процесса, аналитик должен внимательно следить за основным информационным объектом, через который передаются результаты между этапами, — смена основного информационного объекта является сигналом о возможной фрагментации. Затем аналитик должен проанализировать отдельные потоки управления. Перегруппировка потоков обязательно приводит к фрагментации, процесс разделяется на цепочку взаимодействующих подпроцессов. Таким образом, смена объекта управления есть необходимое условие разделения процессов, а перегруппировка — достаточное.
Примеры деления на подпроцессы
Рассмотрим типичный пример процесса заключения договора в нотации BPMN [6]. В примере имеются две точки старта, причем одна из них ведет в середину процесса, и несколько завершающих событий, некоторые из которых находятся в середине процесса (рис. 1). Сквозной процесс имеет два объекта управления: коммерческое предложение и договор — внимательный аналитик увидит смену объекта управления и предположит, что сквозной процесс распадется на два подпроцесса: «Согласовать коммерческое предложение» и «Заключить договор».
| Рис. 1. Сквозной процесс от заявки до договора |
В качестве второго примера, иллюстрирующего предлагаемый подход, рассмотрим бизнес-процесс присуждения Нобелевской премии, взятый из альбома типовых моделей в нотации BPMN [7]. В этом процессе можно выделить следующие объекты управления:
- объявление о начале кампании по сбору заявок на номинацию;
- заявка на номинацию, каждая заявка может содержать имена нескольких кандидатов;
- список отобранных кандидатов на присуждение премии, один на всех номинантов;
- запросы экспертам, по каждому кандидату из списка в отдельности;
- отчет по списку кандидатов, содержит заключение по каждому номинанту;
- результат голосования по списку, определяет одного лауреата премии.
Анализ бизнес-процесса показывает, что по ходу исполнения происходит многократная смена и перегруппировка объектов управления: в ответ на одно объявление происходит сбор заявок, причем их число меняется из года в год. Каждая заявка может включать несколько кандидатов, количество которых заранее не известно. После отбора часть кандидатов попадет в список номинантов, размер которого зависит от обстоятельств. Это означает, что соотношение между объявлением о выдвижении кандидатов, числом заявок на выдвижение и количеством запросов на экспертизу заранее неизвестно. Следовательно, в модели должны быть выделены соответствующие подпроцессы: «объявить о сборе заявок», «собрать заявки», «провести экспертизу кандидатов». Вместе с тем заранее известно, что одному объявлению о выдвижении кандидатов всегда соответствует один список номинантов. В этом случае разделение на подпроцессы необязательно. Этот пример показывает, что выделение объектов управления и анализ связей между ними помогают разделить процесс на подпроцессы и правильно организовать их взаимодействие.
Этапы исполнения процесса
Мы разделили сквозной процесс на подпроцессы, ориентируясь на смену объекта управления, однако получившиеся в результате подпроцессы могут оказаться достаточно большими и может возникнуть потребность их повторной декомпозиции на более мелкие фрагменты. Без потери общности будем считать, что у процесса есть только один объект управления. Рассмотрим алгоритм разбиения, выделив основные этапы жизненного цикла объекта управления.
Декомпозиция процесса по этапам жизненного цикла объекта управления позволяет расположить этапы исполнения в естественном порядке следования. Они связаны безусловными переходами и образуют основной сценарий исполнения процесса [8], который не предполагает показывать альтернативные маршруты и варианты ветвления. Поэтому следующим шагом нужно уточнить модель: расширить — добавить в основной сценарий пропущенные варианты исполнения и углубить — детализовать каждый из подпроцессов. Можно оформить каждый этап как подпроцесс в нотации BPMN, тогда основной сценарий будет изображаться цепочкой подпроцессов, связанных безусловными переходами (рис. 2). Например, объект управления «Заказ» имеет следующие этапы жизненного цикла: оформление, проверка реализуемости, согласование условий, исполнение, передача заказчику и завершение финансовых расчетов. Затем основной сценарий следует уточнить: (а) расширить — добавить пропущенные варианты исполнения, (б) углубить — детализовать каждый из подпроцессов.
| Рис. 2. Основной сценарий исполнения процесса |
Моделирование организационных обязанностей
Часто работы, образующие этап, выполняются в рамках структурного подразделения, и при этом одна операционная функция, например «Согласовать заказ», может быть представлена как подпроцесс, который описывает взаимодействие сотрудников, выполняющих эту операцию. Он включает выбор исполнителя, возложение поручения, координацию работы и т. д.
До сих пор на схеме процесса фигурировали только операционные функции, направленные непосредственно на производство товаров и услуг, а теперь настала пора изобразить организационное взаимодействие сотрудников внутри подразделения. Это нужно для координации и управления операционной подсистемой и заключается в воздействии на других людей с целью организации их совместной деятельности. На схеме процесса очень важно детально отобразить организационные функции участников — от четкости их исполнения зависит качество результата и показатели его достижения. Этот тип взаимодействия подвержен частым изменениям — например, вновь пришедший начальник по-своему организует работу подчиненных. Набор организационных функций фиксирован, при реорганизации они не исчезают, но могут перераспределяться между участниками. Например, вначале руководитель вручную распределял задания между сотрудниками, а после внедрения информационной системы диспетчеризация осуществляется автоматически. Таким образом, автоматизация не изменяет набора функций, но может передавать их исполнение информационной системе.
Если изображать организационное взаимодействие на схемах верхнего уровня, то любая реорганизация приведет к глобальному изменению моделей, поэтому будем моделировать организационное взаимодействие на схемах нижнего уровня, и тогда изменения окажутся локальными. Чтобы избежать использования на схеме процесса названия должностей или имен сотрудников, что привяжет модель к конкретной организации, будем использовать абстрактные организационные псевдороли участников (см. таблицу).
| Псевдороль | Функция | |
|---|---|---|
| 1. | Распределяющий | Оценка задания, установка приоритетов и сроков |
| 2. | Диспетчеризация, отбор и назначение исполнителя в соответствии с критериями | |
| 3. | Возложение поручения на выбранного исполнителя | |
| 4. | Исполнитель | Выполнение функционального поручения |
| 5. | Информируемый | Координация работы |
| 6. | Проверяющий | Проверка качества выполненных работ |
| 7. | Визирующий | Утверждение результата своей подписью |
| 8. | Передача задания на следующий этап обработки |
Следующий пример (рис. 3) показывает схему взаимодействия сотрудников одного подразделения. Обычно руководитель подразделения играет сразу несколько ролей: «Распределяющий», «Информируемый», «Проверяющий», «Визирующий». Если руководитель хочет иметь возможность самостоятельно исполнять задание, он должен быть приписан к роли «Исполнитель».
 |
| Рис. 3. Организационное взаимодействие участников |
***
Предложенные критерии и метод последовательной декомпозиции процесса, предполагающий выделение объектов управления, рассмотрение этапов жизненного цикла каждого из объектов и выделение функций организационного взаимодействия участников, позволяют создать иерархическую модель, на верхнем уровне которой имеется самое общее представление о ходе процесса, а все детали спрятаны на нижних. Предлагаемые критерии объективны и измеряемы, что исключает субъективность при их применении. Полученная модель оказывается удобной для анализа разными категориями пользователей: бизнес видит суть процесса, изучая диаграммы верхнего уровня; эксперты предметной области смогут разобраться в подробностях, используя детализацию; разработчики найдут важные подробности на диаграммах нижнего уровня. Такая архитектура процесса максимально защищает модель от возможных модификаций, поскольку локализует изменения рамками соответствующего подпроцесса. Она помогает увидеть сходство разных процессов и свести их к единому сценарию, что улучшает управление. Подпроцессы нижнего уровня оказываются повторно используемыми, а модульная архитектура процесса оказывается удобной при автоматизации бизнеса.
Литература
- Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.: Манн, Иванов и Фербер, 2012.
- Сооляттэ А.Ю., Репин В. В. Цепочка создания ценности — основа для построения сети бизнес-процессов компании // Финэксперт.
- Silver B., BPMN Method and Syle, 2009.
- Sharp А., McDermott P., Workflow Modeling. Artech House Publishers, 2001.
- Mendling J., Neumann G., Van der Aalst W., Understanding the Occurrence of Errors in Process Models Based on Metrics // In: Proceedings of the OTM Conference on Cooperative information Systems (CoopIS 2007). Berlin: Springer-Verlag, 2007.
- Белайчук А. Процессный паттерн: Cнова здравствуйте! [Электронный ресурс]. URL: mainthing.ru/ru/item/537/#more-537. 2012. (Из BPM-блога «Главное не результат, главное процесс»).
- OMG. BPMN 2.0 by Example. OMG Document Number: dtc/2010-06-02. www.omg.org/spec/BPMN/2.0/examples/PDF
- Федоров И.Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. — 2012. No. 5 (41), — C.5–13.
Игорь Федоров ([email protected]) — профессор, Московский государственный университет экономики, статистики и информатики (Москва).
Поделитесь материалом с коллегами и друзьями
www.osp.ru
Структура модели бизнес-процессов [BS Docs 4]
Модель бизнес-процессов, согласно методологии SADT, создается на основе принципа декомпозиции: «…декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта». На верхнем уровне модели рассматриваемая система представляется в виде одного процесса, например, «Деятельность по производству и продаже оборудования», далее он декомпозируется на совокупность бизнес-процессов верхнего уровня (см. Основные элементы системы управления). Каждый из бизнес-процессов верхнего уровня декомпозируется на ряд подпроцессов. В качестве критерия выделения подпроцессов второго уровня можно использовать промежуточные состояния объекта управления. Например, процесс «Продвижение и продажи» может быть декомпозирован на подпроцессы:
Продвижение продуктов
Выяснение потребности клиента
Заключение договора с потребителем
Прием текущих заказов
Производственное планирование
Организация выполнения заказа клиента
Организация удовлетворения претензий клиентов
Анализ удовлетворенности клиентов
Количество уровней декомпозиции выбирается исходя из стоящих задач и необходимой степени подробности описания. На практике используют 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.
Моделирование деятельности на низких уровнях модели тесно коррелирует с прикладными методиками и технологиями деятельности, т.е. в ряде случаев вопросы «что делать» и «как делать» сливаются воедино.
Диаграмма является основным рабочим элементом при создании модели. Диаграммы имеют собственные синтаксические правила, которые будут рассмотрены в следующих разделах.
www.businessstudio.ru
3.Построение сети бизнес-процессов(теория)
4
Описание бизнес-процессов
Способы описания бизнес процессов
Текстовое описание БП
Текстовое описание БП представляет собой ответы компетентных лиц на следующие вопросы:
Что поступает в организацию (подразделение) на «входе»?
Какие функции и в какой последовательности выполняются в рамках должности (подразделения)?
Кто является ответственным за выполнение каждой из функций?
Чем руководствуется исполнитель при выполнении каждой из функций?
Что является результатом работы организации (подразделения) на выходе?
Рекомендуется каждой работе присвоить номер или идентификатор, а также использовать два правила при формулировке названия работ.
Исполнитель + «:» + Названия работы + Основание (правило) выполнения
Правило 1. Названия работы нужно формулировать согласно следующее формуле:
Название работы = Действие + Объект, над которым действие осуществляется
Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать «Продажа продукции», а еще лучше конкретизировать что это за продукция. В данном случае «Закупка» это действие, а «продукция» — объект над которым действие по продаже производится.
Правило 2. При формулировании названия работы нужно стараться использовать краткую и лаконичную формулировку, что повысит эффективность дальнейшей работы по оптимизации бизнес-процесса. Идеальный вариант – формулирование названия работы при помощи 2-3 слов, в крайнем случае – использование в названии не более 50 символов. В сложных случаях рекомендуется для каждого краткого названия работы сделать ее подробное описание, которое поместить в глоссарий.
Графическое описание БП
Графическое описание БП обычно состоит из следующих этапов:
1. Разработка схемы бизнес-процессов в виде дерева.
2. Построение сетевой схемы (сети) бизнес-процессов на основе дерева.
Дерево БП
Пример БП управления:
планирование бюджета;
составление штатного расписания;
планирование закупок;
планирование продаж и т.д.
Для крупных предприятий БП можно объединять в категории и группы. Например, для БП управления верхнего уровня это могут быть следующие категории БП:
управление закупками и запасами;
управление производством;
управление продажами;
управление финансами и т.д.
Рис. Построение дерева бизнес процессов
Сеть БП
На практике сеть процессов часто называют схемой взаимодействия бизнес-процессов. Отличие сети процессов от классической древовидной схемы состоит в том, что на сети показывают внешние субъекты, с которым взаимодействуют бизнес-процессы компании – клиенты, поставщики, банки и др.
В результате сетевая схема дает более наглядное представление бизнес-процессов компании, поскольку описывает их взаимодействие друг с другом и внешней средой.
Вход и выход каждого бизнес-процесса являются соответственно выходом и входом для другого бизнес-процесса или внешнего субъекта, с которыми взаимодействует организация (рис.).
Рис. Построение сети бизнес-процессов
В отличие от дерева бизнес-процессов сеть процесса дает более полное системное представление о деятельности организации, так как позволяет показать не только элементы организации, но и взаимодействия между ними.
Иерархические связи и классификация бизнес-процессов на сети процессов не показывается для того, чтобы не загромождать модель.
При формулировании названий материальных и информационных потоков также нужно использовать подобные правила. В данном случае второе правило используется без изменений, а первое правил формулируется следующей формулой:
Название потока = Объект, представляющий поток + Статус объекта
Например, если речь идет о продукции, которую отгрузили клиенту, то данный поток нужно сформулировать следующим образом – «Продукция отгруженная» или «Продукция, отгруженная клиенту». В данном случае «Продукция» — это объект, представляющий поток, а «отгруженная клиенту» — статус объекта.
При построении сетевой схемы бизнес-процесса нужно помнить, что такая схема показывает потоки материальных и информационных потоков и не говорит о временной последовательности работ. Иногда временная последовательность выполнения процессов совпадает с направлением движения потоков объектов.
Рис. Фрагмент схемы получения отчета
В данном примере второй БП по времени может начаться раньше первого, но Документ 1 движется от первого БП ко второму.
Именно поэтому стандарт IDEF0 удобен для описания бизнес-процессов верхнего уровня или макропроцессов, при описании которых в общем случае невозможно указать временную последовательность работ, так как все работы выполняются одновременное или существует несколько вариантов различных последовательностей, которые к тому же могут зависеть и от различных точек зрения.
Рассмотрим пример бизнес-процесса, приведенного на рис.
Рис. 3. Фрагмент схемы БП верхнего уровня
На вопрос что происходит раньше закупка продукции или ее продажа могут быть даны два различных ответа в зависимости от двух различных ситуаций. Если конкретный продукт имеется на складе, то его закупка по времени происходит раньше, чем продажа. Если, при обращении клиента продукции на складе нет и клиент готов подождать пока будет произведена закупка, то процесс продажи начинается по времени раньше, чем закупка, а заканчивается позже.
В случае, если необходимо описать последовательность выполнения операций, используют другие стандарты, например IDEF3 или языки описания алгоритмов.
Помимо этого сеть процессов обеспечивает проверку разработанной модели деятельности организации на целостность, правильность выделения бизнес-процессов и описания их окружения.
Если выход одного из бизнес-процессов, например, документ, нигде далее не используется, то есть не является входом для другого бизнес-процесса или внешнего субъекта, то это означает следующее. Первое – описанный выход бизнес-процесса является либо ошибочным, либо лишним. В противном случае нужно найти бизнес-процесс для которого данный выход является входом и доработать схему окружения этого бизнес-процесса.
На рис. приведено пример сети бизнес-процессов для производственной компании.
Рис. Пример сети бизнес-процессов (основные БП выделены красным)
Декомпозиция бизнес-процесса
При декомпозиции каждый процесс описывают в виде отдельной схемы следующего уровня. При этом каждый процесс должен включать от трех до шести «вложенных» процессов (или подпроцессов), что связано с особенностями восприятия.
В случае необходимости работы на схеме процесса второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания.
Использование слишком глубокой детализации и большого количества работ приведет к сильному усложнению схемы и снижению возможности проведения качественного анализа бизнес-процесса. Использование небольшой детализации и меньшего количества работ на схеме бизнес-процесса приведет к тому, что работы будут достаточно укрупненными, что также уменьшит возможность проведения их качественного анализа и оптимизации.
На рис. процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.
Рис. Декомпозиция бизнес-процесса
При классическом подходе описания бизнес-процессов для разработанной схемы второго уровня можно использовать стандарт функционального моделирования IDEF0, диаграммы потоков данных DFD или диаграммы потоков работы WFD в зависимости от уровня и глобальности работы. Если работа глобальна и ее невозможно представить в виде временной последовательности более мелких работ, то используют IDEF0 или DFD-стандарты описания. В противном случае работу целесообразно описать посредством диаграммы потоков работ WFD.
При этом для описания бизнес-процессов верхнего уровня чаще используют IDEF0-стандарт, который является универсальным при описании любых систем, как социо-организационных, так и информационных.
Диаграммы потоков данных DFD чаще используют при моделировании информационных систем, на них показывают работы, которые входят в состав описанных на IDEF0 диаграмме бизнес-процессов, с указанием внешних «сущностей» (поставщиков и потребителей процессов) и хранилищ объектов (материальных и информационных).
В итоге описание деятельности объекта представляет собой иерархически упорядоченный набор IDEF0, DFD и WFD схем, в котором схемы верхнего уровня ссылаются на схемы нижнего уровня.
studfile.net
цели, процессы, структура и виды 🚩 Управление бизнесом
В основе метода декомпозиции лежит логика и анализ имеющихся данных. Такой подход к решению поставленных задач позволяет успевать за современным темпом жизни, ведения бизнеса, и даже решения обычных жизненных проблем – семейных, бюджетных, психологических. Причем методикой пользуются даже те, кто не знаком с ее основами и вообще не подозревает о ее существовании, то есть на подсознательном уровне. Выстраивая тактику поведения с коллегами или близкими, помогая ребенку выполнить сложное домашнее задание, обдумывая расписание дня и свое будущее в целом, мы применяем именно метод декомпозиции в том или ином его проявлении.
Говоря простым языком, декомпозиция – это расщепление единой задачи на более мелкие, и их последовательное решение для получения ответа на поставленный вопрос или для достижения поставленной, итоговой цели. Методика максимально проста и понятна, не требует наличия определенных навыков в определенной области, и ее можно использовать для достижения цели даже там, где знания и опыт минимальны.
О способе декомпозиции написано много научных трудов, определены его основные этапы, принципы и области применения. В некоторых областях методика проста, выполняется в 2-3 этапа, а в некоторых может занимать длительное время и проходить пошагово, причем в процессе участвуют целые группы специалистов, сотрудников.
Процесс декомпозиции позволяет упростить что-либо, не нарушая его целостности. Разделение деятельности или задачи не влияет на важность полученных составляющих, но значительно облегчает, а иногда и сокращает время на осуществление задуманного. Количество систем достижения цели (уровней) зависит от направления деятельности, области применения метода, уровня знаний того, кто решает задачу.
Несмотря на то, что этот метод использовался издревле, детально описан, структурирован и представлен в виде научного труда он только в 1960 году, американцами Данцингом и Вульфом. Именно они разработали алгоритмы способа, основные принципы и генерационные столбцы методики.
Для достижения максимального эффекта от применения методики декомпозиции процесс необходимо проводить в соответствие с определенными принципами (правилами):
- в основе структурирования задачи или цели должна лежать простота их разбора на этапы,
- подцели должны определяться так, чтобы они были максимально понятны для тех, кто будет их решать,
- после того, как была сформирована первая подструктурная линейка вторичных задач, реализатор задачи (решающий ее) определяет необходимость дальнейшего разбора цели – нужен еще один этап или нет.
В ходе разбора поставленной цели на поэтапные шаги поиска оптимального решения могут возникать противоречия по поводу логичности и единства выстроенной системы. Их также можно разбивать на несколько шагов, чтобы исключить ошибку в решении задачи. Подобный подход помогает не только в поиске верного ответа, но и в определении пути развития бизнеса, поиска исследовательских путей и кардинальных решений для оптимизирования экономических, социальных и психологических проблем.
Структура метода декомпозиции складывается из принципа его работы. Самый последний (нижний) уровень является исходным, и именно с него начинается поиск решения. Шаги выполняются последовательно, строго по построенной схеме, и, как правило, процесс достижения цели не занимает много времени. Кроме этого, декомпозиция наиболее эффективна в командной работе, когда каждый из участников занимается определенной задачей.
Чаще всего метод декомпозиции в современном мире применяется в бизнесе, а точнее – в менеджменте, науке управления, администрирования, руководства, оптимизации всех производственных и торговых процессов. Этот способ системного анализа данных бывает
- функциональным,
- структурным,
- объектным.
При функциональной декомпозиции на первом этапе разрабатывается определенный алгоритм действий, под который потом подгоняется схема данных. Подобный способ оптимален для ситуаций, когда данные не структурированы, не разделены на виды и подвиды.
При структурной декомпозиции поставленная задача разбивается на простейшие, из которых формируется план поиска решения. Подзадачи выстраиваются в иерархическую таблицу, где первое место занимают самые простые из них в плане решения. К некоторым могут быть предложены альтернативы – поиск и добавление информации, ввод новых данных для оптимизации процесса.
В ходе объектной декомпозиции процесс разделяется на предметные области, которые представляют из себя функциональные элементы, обменивающиеся определенными данными (информацией). Каждый из выделенных объектов обладает определенными характеристиками, отвечает за передачу или сбор однотипной информации. Состояние объектов при таком виде декомпозиции называют поведением, на основе которого и принимается то или иное решение по дальнейшим действиям, определяется путь следования к поставленной цели.
В основе каждого из перечисленных видов методики декомпозиции лежит структурирование. При создании плана поиска верного решения для той или иной задачи рекомендуется следовать принципам:
- строгое соблюдение уровневой системы – когда более низкий уровень подчиняется только тому, что стоит над ним, и имеет мало логических связей с теми, что стоят выше,
- расчленение одной задачи на несколько подзадач выполняется по однотипным характеристикам, и если одна из низших структур имеет иные характеристики, ее также нужно делить на несколько,
- все созданные подсистемы преследуют единую цель – являются составляющим основной задачи на 100%, и подразделы в процентном соотношении должны являться их суммой,
- глубина (количество уровней структуры) определяется на начальном этапе, составляется иерархическая структура, численность уровней, так, чтобы их количество позволяло одновременно визуально охватить всю составленную систему.
Для метода декомпозиции иногда используются не характерные для логики и анализа термины, к примеру – древо целей и проблем, аналогичное по своему строению древу семьи. Такой способ структурирования позволяет компактно оформить задачи и подзадачи, сохранить все уровни в единой плоскости, облегчить их визуализацию. На начальном этапе создается древо проблем, а уже после его анализа формируется древо целей. В итоге структура сохраняется, а каждая подзадача находит свое решение.
Не всегда изначально выбранная стратегия метода декомпозиции бывает верной, и искомого приходится добиваться, пробуя разные способы решения задачи. Первый опыт создания диаграммы с несколькими уровнями и подуровнями часто приводит к созданию лишних мелких задач, которые не нужны для достижения цели. Именно поэтому специалисты рекомендуют вначале пробовать простейшие пути и не составлять сложных схем.
Создавая декомпозиционную структуру, стоит вспомнить выражение: «Проблемы должны решаться по мере их поступления». В основе обучения такому принципу решения задач лежит использование метода отсечения:
- определяется основная цель,
- задача делится на несколько разноплановых,
- подзадачи, при необходимости, разделяются на более мелкие в плане значения,
- выполняется анализ каждой из выведенных линеек (структур),
- отсекаются ненужные и незначимые,
- созданное древо проблем и целей переносится на новую плоскость,
- начинается решение.
Каждый шаг должен выполняться в спокойной обстановке, этапы проговариваются и визуализируются, что позволяет быстрее выявить ненужные и сформировать максимально точную программу действий для поиска кратчайшего пути решения.
Важен и психологический момент. Работа в команде приносит гораздо лучшие результаты, чем индивидуальный декомпозиционный анализ. Секрет прост – наличие слушателей и критиков стимулирует, да и принцип «одна голова хорошо, а две – лучше» не отменен и активно используется.
Метод декомпозиции может быть использован в любой области жизни, бизнеса и науки. Более простого пути поиска решения самых сложных задач еще не найдено. Важно лишь в полной мере освоить хитрости деления большой задачи или проблемы на более мелкие, которые проще решить, и затем сложить полученные данные в единое целое.
www.kakprosto.ru
Декомпозиция — это… Что такое декомпозиция: суть и виды
Добавлено в закладки: 0
Что такое декомпозиция? Описание и определение термина
Декомпозиция – это научный метод исследования, вследствии которого определяется структура задачи, и одна большая задача заменяется несколькими небольшими задачами, которые взаимосвязаны друг с другом.
В конечном итоге эти задачи решаются гораздо проще.
С помощью декомпозиции любая подвергающаяся исследованию система, может быть условно разделена на несколько более мелких, но взаимосвязанных систем, которые, при необходимости, и далее могут подвергаться разделению.
Системой могут служить не только материальные предметы, но и явления и процессы. Разделение системы должно при этом проводится только по одному определенному признаку, одинаковому для всех уровней системы -это важно.
Рассмотрим более детально, что значит термин декомпозиция.
Суть декомпозиции
Декомпозиция является основой любого аналитического процесса или просто анализа.
Это процесс упрощения чего-либо без потери целостности.
Декомпозиция – это действие, посредством которого расчленяется что либо цельное, при выполнении поставленных задач в различных областях деятельности. Декомпозиция, как процесс расчленения, делает возможным рассматривать любую исследуемую систему как сложную, которая состоит из отдельных взаимосвязанных подсистем, а они, в свою очередь, также могут быть расчленены на части. Как вариант систем могут выступать не только материальные объекты, но также и процессы, явления и понятия.
Декомпозиция позволяет рассматривать предстоящую деятельность по частям, при этом каждая деталь процесса важна и учитывается.
Начальная система располагается на нулевом уровне. После её расчленения получаются подсистемы первого уровня. Разделение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и так происходит дальше. Но при этом есть необходимое условие – вычленяемые подсистемы не должны взаимно исключать друг друга. Например, если при перечислении частей автомобиля опустить, допустим, мотор, то функциональное взаимодействие остальных подсистем не обеспечит нормальное функционирование всей системы (автомобиля) в целом. Степень подробности описания и количество уровней определяются требованиями обозримости и удобства восприятия получаемой иерархической структуры и её соответствия уровню знания работающему с ней специалисту. Число уровней иерархии всегда влияет на обозримость структуры: много уровней — задача трудно обозримая, мало уровней — возрастает число находящихся на одном уровне подсистем и тогда бывает сложно установить между ними связи.
Виды декомпозиции
Декомпозиция бывает разных видов: объектная, функциональная, структурная, по физическому процессу.
Одним из важных и обязательных условий декомпозиции – иерархическое подчинение нижних уровней верхним уровням. Также следует помнить, что декомпозиция не меняет сути декомпозируемого объекта или явления, а лишь уточняет его, упрощает, помогает снять неопределенность или локализовать ее.
Основным методом декомпозиции целей является переход от общего к частному. Например, дедукция является той основой, которая формирует всю сущность декомпозиции.
Но также можно выделить и обратную (индуктивную) форму, где частные моменты образуют общности. Это процесс, обратный декомпозиции можно назвать агрегированием целей или композицией. Только такой метод характерен в проектировании инженерных систем, программировании и/или в создании программного обеспечения, а никак при выстраивании целевой структуры организации.
Мы коротко рассмотрели термин декомпозиция, постарались раскрыть его главные особенности и виды.
Оставляйте свои комментарии или дополнения к материалу.
biznes-prost.ru