Компания IBM
Опубликован: 14.08.2008 | Доступ: свободный | Студентов: 1090 / 150 | Оценка: 4.75 / 3.75 | Длительность: 27:55:00
Лекция 4:

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

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

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

  1. Определите расписание (timetable) с именем NormalWorkTime, как показано на рис. 4.39:
    Расписание NormalWorkTime. Содержимое закладки Recurring time intervals (Периоды времени)

    увеличить изображение
    Рис. 4.39. Расписание NormalWorkTime. Содержимое закладки Recurring time intervals (Периоды времени)
    • Перейдите к дереву проектов, затем выберите пункт Timetables (Расписание) \to New (Новый) \to Timetable (Расписание). Назовите расписание NormalWorkTime и нажмите Finish (Готово) (рис. 4.39).
    • Откройте расписание и выберите пункт Time interval (Временной интервал) \to Remove (Удалить) \to 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.
Расписание LunchTime. Содержимое закладки Recurring time intervals (Периоды времени)

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

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

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

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

Рис. 4.42. Представление Attributes (Атрибуты) расписания NormalWorkTime
Совет. Наведите указатель мыши на представление Attributes (Атрибуты) и нажимайте кнопки мыши, чтобы увеличить или уменьшить увеличение. Указывайте на периоды в расписании, чтобы увидеть имя интервала и его начальный и конечный срок. Обратите внимание, что после того, как мы изменили имя временного интервала с заданного по умолчанию Time interval на Working hours, Lunch и Weekend, мы можем более ясно видеть построение расписания в этом представлении.

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

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

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

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

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

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

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

Рис. 4.44. Пример назначенных для задачи ресурсов и организаций
Совет. Поле Time required for Resources (Время, необходимое для ресурсов) используется для вычисления стоимости определенных ресурсов при эмуляции. Это значение отличается от значения Time required to finish task (Время, необходимое для завершения задачи), которое вы можете указать при выполнении эмуляции.
Таблица 4.2. Параметры назначения задачам ресурсов и организационных подразделений
Задача Роль Необходимое время Количество Определение ресурса Организация
ResponseTimeBasedOnPolicy BusinessRules Engine 1 секунда 1 Machine Claim Department
IdentifyAssesors AssessorManagement 1 секунда 1 Machine Claim Department
RequestAvailability Assessor 2 минуты 1 External Resource External Assessors
SelectAssessor Business Rules Engine 1 секунда 1 Machine Claim Department
ManualSelectAssessor Claim handler 2 минуты 1 Staff Machine Claim Department
Claim handler Desktop 2 минуты 1
RequestAssessment Assessor 1 секунда 1 External Resource External Assessors
AssessorSendReport Assessor 1 час 1 External Resource External Assessors
StoreReport Document Handler 1 секунда 1 Machine Claim Department

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

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

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

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

Палитра WebSphere Business Integration Modeler

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

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

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

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

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

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

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

  • Статический анализ осуществляется на основе информации из модели. Например, мы можем использовать параметр Qualified Resources for Roles (Связанные с ро- лями ресурсы), чтобы узнать, сколько ресурсов было выделено определенным ролям. Для этого нужно щелкнуть правой кнопкой мыши в любом месте дерева проектов и выбрать пункт меню Static Analysis (Статический анализ) \to Resource Analysis (Анализ ресурсов) \to 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, распечатывать их и экспортировать в различные файловые форматы.
Надежда Белякова
Надежда Белякова
Россия
Pavel Pelevin
Pavel Pelevin
Украина, Одесса