Шаг 2. Определение процессов, подлежащих оптимизации средствами CMS (системы управления конфигурациями)

· На данном шаге перечисляются процессы, которые планируется оптимизироват ь за счет применения CMS, и цели, которых надо достичь по каждому процессу (таблица 3).

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

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

Шаг 3. Определение требований к CMDB.

· На данном шаге определяется «охват» CMDB: классы объектов, которые будут учитываться в рамках автоматизируемых процессов, и зона учета (площадки, ЦОД, подразделения и т.д., по которым будет производиться учет) (рис. 4).

· Охват CMDB может изменяться с течением времени, поэтому рекомендуется определить этапы расширения охвата.

· На первом этапе целесообразно включать в CMDB только те КЕ, информация по которым необходима для повышения качества (скорости обработки заявок, снижения количества сбоев после изменений) по наиболее критичным услуга м, перечисленным в таблице 2.

· Результаты работы сводятся в «Классификатор конфигурационных единиц» (таблица 4) при дополнении каждого класса КЕ описанием принципа присвоения ему уникального имени. Это имя впоследствии будет использоваться для идентификации КЕ в CMDB и для маркировки физического объекта, связанного с КЕ (например, идентификатор ПК, проставляемый на его корпусе). Сведения о зоне охвата и этапе реализации заносятся в графу «Примечания» таблицы 4.

· Сформируем теперь требуемый набор связей между КЕ в виде логической модели данных CMDB, пример которой приведен на рис. 5.

· Модель должна содержать все классы CMDB, перечисленные в классификаторе (таблица 1), и

· все связи между КЕ.

· При формировании связей необходимо руководствоваться принципом «Замкнутая цепочка влияния»: двигаясь по цепочке связей, всегда нужно иметь возможность получить полный перечень КЕ, на которые повлияет изменение (остановка) текущего КЕ. В результате работы над логической моделью данных может быть изменен состав классов КЕ в таблице 4. Связи между КЕ могут иметь различные типы (например: «Содержит в составе», «Материально ответственный» и т.д.). Связи могут отражать влияние одной КЕ на работу другой КЕ, в этом случае их можно будет учитывать при анализе последствий изменений.

· Перечень полученных связей сводится в классификатор.

· Сформируем перечень атрибутов для каждого класса конфигурационных единиц в форме, приведенной в таблице 5.

· Для каждого атрибута определим источник (источники) актуальных данных (например, LANDesk Inventory manager – для ПК и серверов, Cisco Works – для сетевого оборудования, MS Active Directory + Кадры – для пользователей и т.д.). Не следует дублировать всю информацию внешнего источника в CMDB. Набор атрибутов должен быть минимально необходимым для обеспечения оперативной обработки инцидентов и анализа изменений. Кроме того, обязательно должны быть атрибуты, однозначно идентифицирующие каждый КЕ во всех внешних источниках информации по нему и атрибуты-связи в соответствии с рис. 5.

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

· Следует учитывать, что чем больше атрибутов, поддерживаемых вручную, тем выше трудоемкость (и стоимость) эксплуатации системы, тем ниже актуальность данных в CMDB и тем меньше эффект от реализации CMS.

· В случае если нельзя определиться с источником данных по какому-либо атрибуту (или по целому классу КЕ ), его следует исключить из CMDB, так как неактуальная информация дискредитирует систему в глазах пользователей на стадии эксплуатации.

Шаг 4. Составление перечня требований к системе.

· На этом шаге формулируются требования к системе, посредством которой планируется автоматизировать процессы управления ИТ в форме таблицы.

· Требования целесообразно группировать по автоматизируемым процессам.

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

Шаг 5. Формулировка критериев выбора системы.

· На предыдущих шагах мы получили подробный перечень требований к СMS и описание CMDB.

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

· В качестве дополнительных критериев отбора могут быть использованы:

o гибкость (возможность изменения глубины и охвата CMDB на стадии эксплуатации, гибкость настройки пользовательских интерфейсов и т.д.),

o цена (включая лицензии, внедрение, поддержку, обновление версий, обучение),

o надежность регионального поставщика и разработчика системы.

На российском рынке представлены как комплексные системы (Service Desk + CMDB) наподобие Axious Systems assyst, BMC Remedy, LANDesk Service Desk, Naumen Service Desk, OmniNet Omnitracker, так и специализированные решения: HP Universal CMDB (CMS c гибкими интеграционными возможностями) и LANDesk Asset Lifecycle Manager (CMDB и средства реализации методологии IBPL).

1. 1. Понятие Изменения. Область ответственности процесса управления Изменениями.

Целью Процесса Управления Изменениями является руководство проведением изменений и ограничение числа инцидентов, вызванных изменениями. Девиз Процесса Управления Изменениями:

Не всякое, изменение является улучшением, но всякое ухудшение является изменением.

На рис. 7.1 показан цикл изменений:

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

Основные термины

Две точки принятия решения об изменениях

Существуют две точки принятия решения о проведении изменений:

■ Руководитель Процесса Управления Изменениями — лицо, ответственное за предварительный просмотр (фильтрацию) и классификацию Запросов на Изменения (Request For Change - RFC).

■ Консультативным комитет по изменениям (Change Advisory Board - CAB) — консультативный орган, регулярно собирающийся для оценки и планирования изменений. Чаще всего одно или несколько значительных изменений выносятся на обсуждение Комитета. Отдельно создается комитет по срочным изменениям (ЕС), который назначается руководством для принятия чрезвычайных решений. Состав Консультативного комитета является гибким и включает представителей всех основных ИТ- подразделений:

- Руководителя по Управлению Изменениями (председатель);

- Руководитель по Управлению (Уровнями) Услуг;

- Представителей Службы Service Desk и Процесса Управления Проблемами;

- Руководителей линейных подразделений компании;

- Бизнес-руководителей (или их представители) со стороны заказчика;

- Представителей пользователей;

- Представителей разработчиков приложений; Администраторов программного обеспечения и системных администраторов;

- Представителей поставщиков.

Охват (сфера действия или границы) процесса

Сфера действия Процесса Управления Изменениями определяется вместе со сферой действия Процесса Управления Конфигурациями.

Если в базе данных CMDB ведется учет компьютерных мышей и клавиатур, то замена клавиатуры рассматривается как изменение.

Можно допустить, что ряд повседневных заданий, точно определенных и подчиняющихся установленным процедурам (т. е. стандартных заданий), не требуют контроля ее стороны Процесса Управления Изменениями. Примерами таких заданий могут быть установка кассет для резервного копирования, создание идентификаторов (ID) пользователей и т. д. Эти действия не обрабатываются как изменения, а самое большее классифицируются как Запросы на Обслуживание в рамках Процесса Управления Инцидентами. Внимательное изучение стандартных действий может быть полезно для предотвращения излишней бюрократизации Процесса Управления Изменениями.

Одним из способов выполнения таких действий является определение так называемых «предварительно авторизованных»» изменений (или «категории 0»»), которые записываются в базу данных изменений, но не требуют использования процедур по Управлению Изменениями. Например, если при приеме на работу нового сотрудника обычно выполняются четырнадцать действий (создание новой учетной записи, настройка рабочей станции электронной почты и т. д.), то эти действия не требуют столь внимательного изучения, как значительные изменения инфраструктуры. Такой вид стандартных изменений обрабатывается по типовому шаблону как предварительно авторизованный «Запрос на Обслуживание».

i. Цель процесса

Целью Процесса Управления Изменениями является гарантия использования стандартных методов и процедур для быстрой обработки изменений с минимальным возможным отрицательным воздействием изменения на качество услуг. Все изменения должны быть отслеживаемыми, чтобы можно было ответить на вопрос: «Что изменилось?»»

ii. Процесс

Процесс Управления Изменениями принимает или отклоняет каждый Запрос на Изменение (RFC).

Входы Процесса Управления Изменениями включают в себя:

■ Запросы на Изменения (RFC);

■ информация из базы данных CMDB (в частности, анализ степени воздействия изменений);

■ информация из других процессов (из Базы данных мощностей, информация о бюджете и

т. д.);

■ предварительно согласованный план изменений Forward Schedule of Change - FSC).

Выходы процесса включают:

■ обновленный план изменений (Согласованный план изменений FSC);

■ повестка дня Консультативного комитета CAB, протоколы и принятые решения;

■ отчеты по Процессу Управления Изменениями.