Моделирование бизнес-процессов c Rational Software Architect. Часть 3

Источник: developerworks
Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт Галина Карабанова, ведущий проектировщик, ЗАО "Лимб"

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

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

Что такое "модель" с точки зрения IBM Rational Software Architect? Это набор необходимых диаграмм, позволяющих отобразить различные представления, например, моделируемого процесса и используемых на этих диаграммах элементов. Rational Software Architect предоставляет набор шаблонов моделей, представляющих собой базовую структуру для возможно необходимых моделей, таких как Use Case Model, Service Design Model, Blank Model и др. Более того, он предоставляет возможность создать в случае необходимости собственный шаблон модели для повторного использования в других проектах. В рамках данной статьи мы не будем углубляться в нюансы создания и сохранения шаблонов моделей, а рассмотрим лишь один из возможных вариантов использования стандартного шаблона Blank Model для целей построения моделей бизнес-процессов "Как есть" и "Как будет" с использованием Activity diagram.

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

  1. "Business Process Model "As-Is"".
  2. "Business Process Model "As-To-Be"".

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

Рисунок 2. Структура моделей анализируемых бизнес-процессов "Как есть" и "Как будет"
Рисунок 2. Структура моделей анализируемых бизнес-процессов

Следующим шагом в IBM Rational Software Architect будет изображение первого представления процесса "Заключение договора аренды" - "Как есть" (рисунок 3). В качестве критерия для классификации выполняемых в ходе анализируемого процесса действий выберем "Использование инструментальных средств". При этом заметим, что данный выбор был обусловлен тем фактом, что достаточно часто "проблемы" встречаются в тех действиях и/или процессах, которые не "покрыты" теми или иными информационными системами. Кроме того, это тот фактор, который очень легко выявить на начальных стадиях анализа, он буквально бросается в глаза.

Рисунок 3. Представление 1 процесса "Заключить договор аренды" - "Как есть"
Рисунок 3. Представление 1 процесса

Допустим, что того факта, что некоторые действия не автоматизированы либо некоторые действия анализируемого процесса выполняются посредством использования различных инструментальных средств, недостаточно для выявления всех "проблем". В качестве второго критерия выберем степень эффективности выполняемых действий и изобразим второе представление для анализируемого процесса "Заключить договор аренды". Логично предположить, что действия по вводу информации, идентифицирующей договор аренды, вряд ли являются эффективными. Кроме того, многократный ввод сведений об одном и том же объекте увеличивает вероятность возникновения ошибки и т.д. Эффективность анализируемых действий может быть оценена специальными способами, рассмотрение которых выходит за рамки данной статьи о IBM Rational Software Architect. Большинство из этих способов предоставляют возможность измерить эффективность, например, в денежном выражении. В нашем случае мы ограничимся лишь оценкой уровня эффективности и разделим действия в соответствии с тем, является ли их эффективность "низкой" либо "удовлетворительной" (рисунок 4).

Рисунок 4. Представление 2 процесса "Заключить договор аренды" - "Как есть"
Рисунок 4. Представление 2 процесса  
Читать часть 4


Страница сайта http://185.71.96.61
Оригинал находится по адресу http://185.71.96.61/home.asp?artId=23176