Command disabled: recent


Использование веток и опросов

В данной главе описан один из возможных подходов к управлению жизненным циклом модели. Изменение бизнес-архитектуры компании может осуществляться в режиме оперативных изменений или в проектах, занимающих длительное время. На Рисунке 1 показан возможный жизненный цикл актуальной модели с учетом подготовки изменений в отдельных ветках и последующей их заливкой в актуальную модель:

Рисунок 1

Оперативные изменения бизнес-архитектуры

Локальные изменения в модель бизнес-архитектуры могут регулярно вноситься несколькими бизнес-аналитиками в выделенной ветке и переноситься в актуальную модель с необходимой частотой, например, один раз в месяц. Частота выбирается исходя из разумной периодичности уведомления сотрудников об изменениях.

Важно помнить, что все начатые изменения в ветке должны быть закончены до момента применения ветки.

Ветка для оперативных изменений имеет следующий типовой жизненный цикл:

  1. Разработка изменений модели (см. Работа в ветке)
  2. Согласование изменений модели с заинтересованными лицами (см. Проведение опроса "Согласование");
  3. Применение изменений с помощью операции "Применить ветку" (см. Применение ветки);
  4. Официальное ознакомление сотрудников с изменениями (см. Перенос изменений из ветки в актуальную модель и ознакомление сотрудников).

Изменение бизнес-архитектуры в проекте

Крупные изменения в бизнес-архитектуре компании, как правило, реализуются в рамках проектов, продолжающихся длительное время. Одновременно в компании может реализовываться несколько проектов.

Жизненный цикл проекта

На Рисунке 2 представлен нормативный жизненный цикл проекта:

Рисунок 2

Этапы жизненного цикла проекта:

Этап 1. Создание проекта и ветки проекта.

Этап 2. Внесение в ветке изменений в модель бизнес-архитектуры.

Этап 3. Согласование изменений с заинтересованными лицами.

Этап 4. Реализация согласованных изменений в реальности, тестирование изменений на ограниченном числе сотрудников.

Примечание. Тестирование изменений модели, как правило, проводится наиболее квалифицированными сотрудниками. При этом следует отметить, что процесс тестирования изменений не является обязательным и может быть пропущен по усмотрению команды проекта.

Этап 5. Перенос изменений из ветки в актуальную модель. Фактически данный этап подразумевает успешное завершение активной фазы проекта.

Этап 6. Официальное ознакомление сотрудников, чья деятельность была затронута проектом, с изменениями бизнес-архитектуры.

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

Создание проекта и ветки проекта (Этап 1)

При инициировании проекта определяются его основные параметры (цели, сроки, бюджет), а также задаются участники проекта. Назначение участников и предоставление им проектных ролей осуществляется в Окне свойств проекта путем добавления пользователей в список Участники проекта.

Данное Окно свойств проекта может быть вызвано как из Навигатора (Вкладка Управление → Проекты), так и из справочника Проекты (Главное меню → Управление моделью → Проекты). Взаимосвязь ветки с проектом устанавливается в Окне свойств проекта путем добавления ветки в список Ветки. Создание ветки описано в главе Создание ветки.

Примечание. Так как класс Проекты имеет единые данные в ветках (см. Свойства веток), то связывать ветки с проектами можно, находясь в любой ветке базы данных. Следовательно, создавать проект также можно из любой ветки.

При необходимости создания альтернативных версий объектов модели в рамках одного проекта в список Ветки Окна свойств проекта можно добавить несколько веток. При этом на портал на этапе согласования модели попадут объекты всех веток, связанных с проектом.

Внесение в ветке изменений в модель бизнес-архитектуры (Этап 2)

Для того, чтобы изменения модели сразу ассоциировались с проектом, необходимо открыть ветку проекта и установить текущий проект с помощью операции Выбрать текущие проекты (Главное меню → Управление моделью → Выбрать текущие проекты).

Теперь версии объектов, созданные в ветке в рамках проекта, будут автоматически связаны с выбранным проектом. Как правило, в ветке вносятся изменения в рамках одного проекта, но поддерживается возможность вести в одной ветке сразу несколько проектов (конечно, в этом случае к моменту применения ветки должны быть закончены все проекты). Связь версии объекта с проектом также может быть добавлена или удалена в Окне свойств версии в списке Проекты (см. Версии предметных объектов).

Версиям новых объектов, а также версиям изменяемых объектов на данном этапе следует устанавливать статус "В работе".

Пример.

Аналитик для единиц деятельности А2 и А2.3, оргединицы Отдел продаж и документа Договор установил новые версии 1.0.1 со статусом «В работе», а также создал новую единицу деятельности А.2.5 с теми же номером версии и статусом. Результат работы по данному этапу приведен на Рисунке 3.

Рисунок 3

Согласование изменений (Этап 3)

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

  1. Аналитик устанавливает версиям объектов, изменённым в рамках проекта, статус "Проект".
  2. Аналитик запускает на портале опрос "Согласование". (см. Запуск опроса по требованию).
  3. Заинтересованное лицо (далее по тексту – респондент) проходит опрос, предоставляя ответ по каждому объекту опроса. (см. Прохождение опроса на портале).
  4. Аналитик контролирует прохождение опроса. (см. Контроль опросов).
Примечание. При необходимости аналитик может отправлять объекты на согласование по мере их готовности, не дожидаясь окончания работы над всеми изменениями модели. При этом существующий на портале опрос будет дополняться новыми объектами с сохранением ранее предоставленных ответов.

Пример.

Аналитик с помощью гиперссылки "Сменить версию объекта" для единиц деятельности А2, А2.3 и А2.5, оргединицы Отдел продаж и документа Договор установил версию 1.1.1 со статусом "Проект" и запустил опрос "Согласование" (см. Рисунок 4).

Рисунок 4

Респондент (Бабич Ирина Петровна) после получения уведомления открывает страницу опроса и предоставляет рецензию по каждому объекту (см. Рисунок 5).

Рисунок 5

Аналитик контролирует ход опроса и просматривает полученные ответы на вкладке Контроль опросов раздела Администрирование. На Рисунке 6 показано, что только один из двух участников согласования оставил рецензии на объекты опроса.

Рисунок 6

Реализация и тестирование изменений (Этап 4)

После согласования изменений модели наступает этап их реализации в реальном мире и тестирования. Под реализацией изменений в реальном мире понимается закупка и монтаж необходимого оборудования, разработка и развертывание информационных систем. Далее необходимо осуществить тестовую эксплуатацию и проверить, насколько пригодными оказались разработанные изменения. К тестированию изменений привлекаются сотрудники, являющиеся непосредственными участниками деятельности (например, исполнители). Такие сотрудники указываются в списке Участники проекта Окна свойств проекта с ролью Участник тестовой эксплуатации. Процесс тестирования изменений имеет следующий порядок действий:

  1. Аналитик устанавливает версиям объектов, предназначенных для тестирования, статус "Рекомендована" (см. Версии предметных объектов).
  2. Аналитик запускает опрос "Тестовая эксплуатация" на портал (см. Контроль опросов).
  3. Участник тестовой эксплуатации проходит опрос, представляя ответ по каждому объекту опроса (см. Прохождение опроса на портале).
  4. Аналитик контролирует прохождение опроса (см. Контроль опросов).

Пример. Аналитик установил версиям единиц деятельности А2, А2.3 и А2.5, оргединице Отдел продаж и документу Договор статус "Рекомендована", и запустил опрос "Тестовая эксплуатация". Номера версий объектов при этом остались без изменений (см. Рисунок 7).

Рисунок 7

Респонденты-участники тестовой эксплуатации (Сидоркин Василий Викторович и Борисов Александр Михайлович) после получения уведомлений открывают страницу опроса и по каждому объекту оставляют рецензии о пригодности к эксплуатации его в новой бизнес-архитектуре (см. Рисунок 8).

Рисунок 8

Аналитик контролирует ход опроса аналогично предыдущему этапу (см. Рисунок 9).

Рисунок 9

Перенос изменений из ветки в актуальную модель и ознакомление сотрудников (Этапы 5 и 6)

Для того, чтобы изменения модели вступили в силу, и все сотрудники, чья деятельность была затронута проектом, ознакомились с ними, аналитику необходимо выполнить следующий порядок действий:

  1. Проверить изменения модели на консистентность с помощью операции Проверить ветку (Главное меню → Управление моделью → Проверить ветку) (см. Применение ветки) и устранить конфликты (при их наличии).
  2. Установить статус версии "Опубликована" всем измененным/созданным в ветке объектам (см. Версии предметных объектов).
  3. Запустить операцию Применить ветку (Главное меню → Управление моделью → Применить ветку) (см. Применение ветки).
  4. Сформировать портал с автозапускаемым опросом "Ознакомление" (см. Запуск опроса при формировании портала).

После формирования автозапускаемого опроса сотрудники получат уведомления о необходимости официального ознакомления с изменениями модели. При этом руководители осуществляют контроль ознакомления сотрудников возглавляемого подразделения в разделе Администрирование на портале (см. Контроль опросов).

Пример.

Аналитик установил версиям единиц деятельности А2, А2.3 и А2.5, оргединице Отдел продаж и документу Договор статус "Опубликована" и применил ветку к вышестоящей. Номера версий объектов при этом остались без изменений.

Результатом применения ветки проекта к родительской ветке являются:

  • Новые версии единиц деятельности А2 и А2.3, оргединицы Отдел продаж и документа Договор, а также появление в актуальной модели новой единицы деятельности А2.5;
  • Попадание объектов с новыми версиями в опрос для официального ознакомления сотрудников с новыми регламентами работы.

Руководитель подразделения (Бабич Ирина Петровна) контролирует ознакомление подчиненных сотрудников с регламентами в разделе Администрирование (см. Рисунок 10).

Рисунок 10
« ПредыдущаяНа уровень вышеСледующая »
 
Driven by DokuWiki