В данной главе описан один из возможных подходов к управлению жизненным циклом модели. Изменение бизнес-архитектуры компании может осуществляться в режиме оперативных изменений или в проектах, занимающих длительное время. На Рисунке 1 показан возможный жизненный цикл актуальной модели с учетом подготовки изменений в отдельных ветках и последующей их заливкой в актуальную модель:
Локальные изменения в модель бизнес-архитектуры могут регулярно вноситься несколькими бизнес-аналитиками в выделенной ветке и переноситься в актуальную модель с необходимой частотой, например, один раз в месяц. Частота выбирается исходя из разумной периодичности уведомления сотрудников об изменениях.
Важно помнить, что все начатые изменения в ветке должны быть закончены до момента применения ветки.
Ветка для оперативных изменений имеет следующий типовой жизненный цикл:
Крупные изменения в бизнес-архитектуре компании, как правило, реализуются в рамках проектов, продолжающихся длительное время. Одновременно в компании может реализовываться несколько проектов.
На Рисунке 2 представлен нормативный жизненный цикл проекта:
Этапы жизненного цикла проекта:
Этап 1. Создание проекта и ветки проекта.
Этап 2. Внесение в ветке изменений в модель бизнес-архитектуры.
Этап 3. Согласование изменений с заинтересованными лицами.
Этап 4. Реализация согласованных изменений в реальности, тестирование изменений на ограниченном числе сотрудников.
Этап 5. Перенос изменений из ветки в актуальную модель. Фактически данный этап подразумевает успешное завершение активной фазы проекта.
Этап 6. Официальное ознакомление сотрудников, чья деятельность была затронута проектом, с изменениями бизнес-архитектуры.
Важно иметь ввиду, что при реализации проекта может происходить возврат на предыдущие этапы, а также то, что изменения могут двигаться по жизненному циклу проекта отдельными частями.
При инициировании проекта определяются его основные параметры (цели, сроки, бюджет), а также задаются участники проекта. Назначение участников и предоставление им проектных ролей осуществляется в Окне свойств проекта путем добавления пользователей в список Участники проекта.
Данное Окно свойств проекта может быть вызвано как из Навигатора (Вкладка Управление → Проекты), так и из справочника Проекты (Главное меню → Управление моделью → Проекты). Взаимосвязь ветки с проектом устанавливается в Окне свойств проекта путем добавления ветки в список Ветки. Создание ветки описано в главе Создание ветки.
При необходимости создания альтернативных версий объектов модели в рамках одного проекта в список Ветки Окна свойств проекта можно добавить несколько веток. При этом на портал на этапе согласования модели попадут объекты всех веток, связанных с проектом.
Для того, чтобы изменения модели сразу ассоциировались с проектом, необходимо открыть ветку проекта и установить текущий проект с помощью операции Выбрать текущие проекты (Главное меню → Управление моделью → Выбрать текущие проекты).
Теперь версии объектов, созданные в ветке в рамках проекта, будут автоматически связаны с выбранным проектом. Как правило, в ветке вносятся изменения в рамках одного проекта, но поддерживается возможность вести в одной ветке сразу несколько проектов (конечно, в этом случае к моменту применения ветки должны быть закончены все проекты). Связь версии объекта с проектом также может быть добавлена или удалена в Окне свойств версии в списке Проекты (см. Версии предметных объектов).
Версиям новых объектов, а также версиям изменяемых объектов на данном этапе следует устанавливать статус "В работе".
Пример.
Аналитик для единиц деятельности А2 и А2.3, оргединицы Отдел продаж и документа Договор установил новые версии 1.0.1 со статусом «В работе», а также создал новую единицу деятельности А.2.5 с теми же номером версии и статусом. Результат работы по данному этапу приведен на Рисунке 3.
Изменения бизнес-архитектуры должны быть согласованы с заинтересованными лицами (с экспертами проекта, руководителями). Данная задача решается с помощью проведения опроса "Согласование" и имеет следующий порядок действий:
Пример.
Аналитик с помощью гиперссылки "Сменить версию объекта" для единиц деятельности А2, А2.3 и А2.5, оргединицы Отдел продаж и документа Договор установил версию 1.1.1 со статусом "Проект" и запустил опрос "Согласование" (см. Рисунок 4).
Респондент (Бабич Ирина Петровна) после получения уведомления открывает страницу опроса и предоставляет рецензию по каждому объекту (см. Рисунок 5).
Аналитик контролирует ход опроса и просматривает полученные ответы на вкладке Контроль опросов раздела Администрирование. На Рисунке 6 показано, что только один из двух участников согласования оставил рецензии на объекты опроса.
После согласования изменений модели наступает этап их реализации в реальном мире и тестирования. Под реализацией изменений в реальном мире понимается закупка и монтаж необходимого оборудования, разработка и развертывание информационных систем. Далее необходимо осуществить тестовую эксплуатацию и проверить, насколько пригодными оказались разработанные изменения. К тестированию изменений привлекаются сотрудники, являющиеся непосредственными участниками деятельности (например, исполнители). Такие сотрудники указываются в списке Участники проекта Окна свойств проекта с ролью Участник тестовой эксплуатации. Процесс тестирования изменений имеет следующий порядок действий:
Пример. Аналитик установил версиям единиц деятельности А2, А2.3 и А2.5, оргединице Отдел продаж и документу Договор статус "Рекомендована", и запустил опрос "Тестовая эксплуатация". Номера версий объектов при этом остались без изменений (см. Рисунок 7).
Респонденты-участники тестовой эксплуатации (Сидоркин Василий Викторович и Борисов Александр Михайлович) после получения уведомлений открывают страницу опроса и по каждому объекту оставляют рецензии о пригодности к эксплуатации его в новой бизнес-архитектуре (см. Рисунок 8).
Аналитик контролирует ход опроса аналогично предыдущему этапу (см. Рисунок 9).
Для того, чтобы изменения модели вступили в силу, и все сотрудники, чья деятельность была затронута проектом, ознакомились с ними, аналитику необходимо выполнить следующий порядок действий:
После формирования автозапускаемого опроса сотрудники получат уведомления о необходимости официального ознакомления с изменениями модели. При этом руководители осуществляют контроль ознакомления сотрудников возглавляемого подразделения в разделе Администрирование на портале (см. Контроль опросов).
Пример.
Аналитик установил версиям единиц деятельности А2, А2.3 и А2.5, оргединице Отдел продаж и документу Договор статус "Опубликована" и применил ветку к вышестоящей. Номера версий объектов при этом остались без изменений.
Результатом применения ветки проекта к родительской ветке являются:
Руководитель подразделения (Бабич Ирина Петровна) контролирует ознакомление подчиненных сотрудников с регламентами в разделе Администрирование (см. Рисунок 10).