Моделирование. Бизнес-процесс

Определение расписаний (timetables)

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

1. Определите расписание (timetable) с именем NormalWorkTime, как показано на рис. 4.39:
   

   
   увеличить изображение
   Рис. 4.39. Расписание NormalWorkTime. Содержимое закладки Recurring time intervals (Периоды времени)
   • Перейдите к дереву проектов, затем выберите пункт Timetables (Расписание) New (Новый) Timetable (Расписание). Назовите расписание NormalWorkTime и нажмите Finish (Готово) (рис. 4.39).
   • Откройте расписание и выберите пункт Time interval (Временной интервал) Remove (Удалить) Add (Добавить). Введите значение Working hours и нажмите OK. Укажите значение 9:00 AM в поле Start time (Начало работы) и 8 hours в поле duration (Продолжительность). Оставьте заданную по умолчанию дату.
2. Еще два расписания с именами LunchTime ( рис. 4.40) и Weekend ( рис. 4.41) определите сходным образом.
3. Сохраните все расписания и вернитесь к NormalWorkTime. Перейдите на закладку Exemption periods (Нерабочее время) и добавьте в качестве нерабочего времени расписания Lunchtime и Weekend.

увеличить изображение
Рис. 4.40. Расписание LunchTime. Содержимое закладки Recurring time intervals (Периоды времени)

увеличить изображение
Рис. 4.41. Расписание Weekend. Содержимое закладки Recurring time intervals (Периоды времени)

Таким образом, нормальным рабочим временем будет время с понедельника по пятницу с 9 утра до 5 вечера с получасовым обеденным перерывом. Окончательный вид расписания NormalWorkTime показан на рис. 4.42, где рабочие часы обозначены синим цветом, а нерабочие - красным.

Рис. 4.42. Представление Attributes (Атрибуты) расписания NormalWorkTime

Мы присваиваем расписание NormalWorkTime ролям Claim handler и Assessor. Для отдельных специалистов по обработке претензий или оценщиков расписание отображаться не будет.

Назначение ресурсов задачам

После того как роли определены, мы назначаем их задачам в процессе Request-ExternalReports.

1. Выберите задачу ResponseTimeBasedOnPolicy в редакторе процессов, щелкнув по ней мышью в представлении Attributes (Атрибуты), перейдите на закладку Resources (Ресурсы), раскройте пункт Role requirements (Необходимые роли) (если он еще не раскрыт), нажмите кнопку Add (Добавить), укажите данные в соответствии с табл. 4.2. Пример показан на рис. 4.43.
   

   
   Рис. 4.43. Указание ролей для задачи ResponseTimeBasedonPolicy
2. Измените значение в поле Name (Имя) на что-нибудь более описательное. Это имя будет использоваться, если архитектор решения применяет схемы деятельности в Rational Software Architect. Задачи группируются по столбцам с использованием этого имени. Для начала можно использовать здесь то же имя, которое имеет роль.

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

Рис. 4.44. Пример назначенных для задачи ресурсов и организаций

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

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

Просмотр всего процесса в Swimlane

Нажав на кнопку Launch Swimlane Viewer (Запустить средство просмотра Swimlane) на палитре, как показано на рис. 4.45, вы получаете возможность просмотреть схему процесса в формате swimlane, с сортировкой по ролям, ресурсам, организационным подразделениям или местоположению.

Рис. 4.45. Палитра WebSphere Business Integration Modeler

На рис. 4.46 показан вид процесса в Swinlane с сортировкой по ролям.

Рис. 4.46. Вид процесса в Swinlane с сортировкой по ролям

4.3.6 Возможности, интересные для бизнес-аналитика

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

Существует два типа анализа - статический анализ и создание отчетов.

• Статический анализ осуществляется на основе информации из модели. Например, мы можем использовать параметр Qualified Resources for Roles (Связанные с ро- лями ресурсы), чтобы узнать, сколько ресурсов было выделено определенным ролям. Для этого нужно щелкнуть правой кнопкой мыши в любом месте дерева проектов и выбрать пункт меню Static Analysis (Статический анализ) Resource Analysis (Анализ ресурсов) Qualified Resources for Role (Ресурсы, выделенные роли). В открывшемся окне выберите пункт Select all (Выбрать все), если вы хотите увидеть все ресурсы, а затем нажмите Finish (Готово). Результат показан на рис. 4.47.
  

  
  Рис. 4.47. Часть результатов анализа ресурсов, выделенных ролям
• Динамический анализ выполняется на основе результатов эмуляции процесса, чтобы получить больше сведений. Существует четыре типа таких анализов:
  • Совокупный анализ ( Aggregated Analysis ). Дает сведения об операциях и ресурсах, используемых во всех экземплярах процесса, сгенерированных при эмуляции.
  • Анализ процесса ( Process Analysis ). Выполняется суммарный анализ по экземплярам процесса с выводом данных:
    • прецедентах процесса (process cases);
    • экземплярах процесса (process instances) сгенерированных в ходе эмуляции, а также показывается вероятность возникновения каждого прецедента процесса.
  • Сравнительный анализ процессов (Process comparison analysis). Сравнивается средневзвешенная величина результатов анализа для двух эмулированных процессов, использующих одинаковые входные параметры.
  • Запросы (Queries). Запросы возвращают данные об элементах модели, относящихся к одному указанному типу.

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

    В категории Queries (Запросы) дерева проектов есть 25 готовых запросов. Вы также можете создавать новые запросы.
  • Отчеты (Reports) - это структурированное представление информации, относящейся к модели или к результатам анализа эмуляции процесса:
    • WebSphere Business Integration Modeler предлагает всего 95 типов шаблонов отчетов в категориях, относящихся к базовому профилю (Basic), промежуточному профилю (Intermediate) и усложненному профилю (Advanced), а также к вспомогательным отчетам (Collateral Reports);
    • вы можете генерировать отчеты по запросам, статическому или динамическому анализу;
    • вы можете просматривать отчеты в интерактивном режиме в WebSphere Business Integration Modeler, распечатывать их и экспортировать в различные файловые форматы.