Диссертация (1152223), страница 56
Текст из файла (страница 56)
Под требованиями предлагается пониматьхарактеристики целевого состояния объекта управления или характеристики работы, котораяизменяет это состояние. Показано, что при невыполнении любого из функциональных требований, цель считается недостигнутой. Не функциональные требования на достижение результатане влияют. Теоретическое обоснование метода основывается на онтологической модели БунгеВанда-Вебера.Предлагаемый метод выявления цели бизнес-процесса и анализа критериев её достиженияобладает практической ценностью — позволяет устранить субъективизм при формированиитребований к проектируемой информационной системе, присущий действиям бизнес-аналитиков.
Практический опыт показывает, что методика оказалась мощным инструментом выявленияпроцесса «сверху вниз» [179]. Можно предположить, что предлагаемый метод выявления целиможет найти более широкое применение в области программной инженерии, а не только применительно к моделированию бизнес-процессов.4.3Метод проектирования архитектуры модели бизнес-процессовВ практике аналитического моделирования принято говорить о сквозных процессах, которые «пронизывают» всю организацию, пересекая границы многих структурных подразделений.Сквозные процессы первоначально кажутся нам монолитными, но на практике они оказываются фрагментированными, распадаются на сеть взаимодействующих подпроцессов.
Можноназвать несколько причин разделения сквозного процесса на подпроцессы. Во-первых, хотелосьбы выделить повторно используемые компоненты, что упростит разработку и сопровождение215всей системы. Во-вторых, модель процесса, которая не умещается на одном стандартном листе,кажется мало понятной и сложной для анализа. Поэтому аналитики группируют операции,формируя подпроцессы. Но поскольку критерии синтеза подпроцессов отсутствуют, аналитикутрудно понять, по какому принципу надо объединять операции в модули, которые выносятся наверхний уровень диаграммы.В настоящий момент не существует методики проектирования архитектуры бизнес-процесса.
Как следствие, либо аналитики изображают сквозные процессы как монолитные и не выделяют подпроцессы, либо наоборот, неоправданно дробят их на модули, которые не могутбыть использованы повторно. Плохо структурированный процесс скрывает важное и характерное, но выпячивает второстепенное, то что, скорее всего, является исключениям. Например,банковские аналитики считают каждый вид кредита отдельным типом процесса. Структуризация поможет увидеть, что процессы выдачи разных видов кредита по-разному комбинируютстандартные, повторно используемые модули. Это помогает сократить число рассматриваемыхпроцессов, улучшает управляемость ими.Цель настоящее исследования в том, чтобы выделить критерии структуризации сквозногопроцесса на подпроцессы, описать механизм связывания подпроцессов в цепочку.
Это поможетаналитику правильно проектировать архитектуру процесса, сделает его работу менее субъективной, позволит превратить её в инженерную деятельность.Известные подходы к проектированию архитектуры модели бизнес-процессовЧасто сквозные процессы делят на модули, исполняемые целиком внутри организационных единиц компании, их называют бизнес-процессами подразделения [123]. Такой способ локализации бизнес-процесса в рамках одного структурного подразделения свойственен функциональному подходу к управлению организацией и может противоречить основной цели моделирования — переходу к процессному управлению.А.Ю. Сооляттэ и В.В.
Репин рекомендуется выявлять процессы с помощью цепочек создания ценностей [259]. Для этого предлагается: (а) выявить клиентов компании; (б) определить,какие продукты компании потребляют эти клиенты, и в чем именно заключается ценность этихпродуктов компании для клиентов; (в) выявить поток преобразования продуктов (услуг), итогом которого являются результат, ценный для клиента компании. Однако, как отмечают авторы,если компания выпускает материальный продукт, выявление цепочки создания ценности является относительно простым делом, однако, если результатом является услуга, обнаружение цепочки создания услуги существенно сложнее.Что бы сделать схему процесса читаемой и понятной, Б. Сильвер предлагает создаватьиерархическую модель, где верхний уровень даёт самое общее представление о ходе исполне-216ния процесса, а все детали исполнения процесса «спрятаны» на нижних уровнях [227].
Идея абсолютно правильная, однако остаётся непонятно, как построить иерархию процесса, раскрываяего снизу-вверх. При этом не уточняется глубина декомпозиции и требуемая степень детализации модели бизнес-процесса.А. Шарп и П. Макдермотт в качестве критерия разделения сквозного процесса на цепочкувзаимодействующих процессов советуют анализировать выходы одного этапа процесса и входыследующего [62].
Если вход и выход соотносятся 1:1, то процесс можно рассматривать как монолитный. Но если это соотношение 1:М или М:1, то это свидетельствует о разделении процесса на подпроцессы. Покажем, что этот критерий следует рассматривать как необходимый,но он не является достаточным.Таким образом, можно констатировать, что на сегодняшний день не существует общепринятого критерия деления сквозного процесса на подпроцессы. В отсутствии системного подхода аналитики полагаются на интуицию, а не на методологию.
Как следствие многие модели содержат ошибки. Например, известно, что до 20% моделей, включённых в справочник референтных моделей SAP, содержат ошибки [260], часть из которых связана с неверной архитектурой бизнес-процесса.Свойство сохранения числа объектов управленияМы ранее установили, что одно инициирующее стартовое событие процесса должно создавать один отклик на его выходе.
Будем иметь в виду, каждый результат на выходе бизнеспроцесса должен быть индивидуально идентифицируем, так что бы было возможно посчитатьрезультативность процесса за определённый интервал времени [62]. Если предположить, чтоодно входное воздействие сгенерирует несколько выходных, то следует допустить, что их число может оказаться неисчислимо большим. Но это противоречит требованию исчислимости результата.
Конечно, можно представить процесс, который на одно входное воздействие будетгенерировать выходной сигнал с определённой периодичностью, однако вряд ли это задача моделирования бизнес-процесса, скорее программирования конечного автомата.Будем ограничиваться рассмотрением только таких бизнес-процессов, которые генерируют один выход на каждое входное воздействие. Если аналитик сталкивается с ситуацией, когда один вход генерирует несколько выходов, он может с уверенностью предположить, что входе исполнение происходит смена объекта управления, один процесс порождает несколькоподпроцессов потомков, которые в сумме создают необходимое число выходов.217Фрагментация процессаЧто бы выявить фрагментацию процесса, аналитик должен следить за основным информационным объектом, его смена есть необходимое условие разделения сквозного бизнеспроцесса на подпроцессы.
Рассмотрим пример, изображённый на рисунке 4.8, клиент размещает заказ, состоящий их нескольких позиций, объектом управления на этом этапе является заявка. По каждой позиции необходимо отдельно проверить наличие изделий на складе, объектуправления изменился, теперь это накладная. Если все позиции заказа доступны, то можно собрать их в единую посылку, теперь объект управления — ведомость отправки. В этом примереодна заявка порождает несколько накладных, которые будут обрабатываться параллельно, нозатем они будут снова собраны вместе и образуют один документ — ведомость.
Таким образом,одной заявке на входе процесса соответствует одна посылка заказчику на выходе. В этом процессе мы выделили три этапа: оформление, исполнение и отправка, каждый со своим объектомуправления. Сквозной процесс можно разделить на подпроцессы, по числу выделенных этапов.12А) Один объектуправления – одинпроцессОформитьзаказПодготовитьдеталь 1Подготовитьдеталь 2ОтправитьзаказЗакрыть заказПодготовитьдеталь 3Заказ12Рисунок 4.8 - Сквозной процессИсточник: составлено автором.Теперь рассмотрим другую ситуацию, показанную на рисунке 4.9. Клиент размещает заказ,состоящий из нескольких позиций, проводится проверка наличия требуемых изделий на складе.Но теперь, мы предположим, что какие-то изделия отсутствуют, их надо изготовить. Те детали,которые есть в наличии, можно оправить заказчику сразу.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
