Под непредвиденными проблемами развития инфраструктуры ИТ мы здесь и далее будем понимать проблемы, не предусмотренные в регуляр­ном планировании ИС.

Следует отметить, что для современного состояния ИС и ИТ-инфра­структуры российских предприятий непредвиденные проблемы весьма типичны. К ним могут относиться:

· недопустимые простои критически важных сервисов (например, про­грамм операционного дня в коммерческом банке);

· прекращение сопровождения критически важных приложений вслед­ствие распада внутренней команды разработчиков или небольшой фирмы - поставщика;

· масштабное поражение корпоративной сети компьютерным вирусом;

· необходимость срочной легализации применяемого ПО вследствие правовых проблем.

Однако модель бизнес-процессов ITIL/ITSM предназначена не в по­следнюю очередь для проактивного (предупреждающего) разрешения проблем такого уровня. Так, блок процессов планирования и управления сервисами в этой модели ориентирован, в частности, именно на решение вышеперечисленных задач. Означает ли это, что разрешение непред­виденных проблем развития инфраструктуры ИТ с внедрением модели ITIL/ITSM становится ненужным? Нет, не означает.

Хотя модель ITIL/ITSM позволяет ограничить внутренние риски ИТ-инфраструктуры предприятия, а также организовать планирование и управление этими рисками, сохраняются риски внешней среды, кото­рые зачастую невозможно контролировать. К ним относятся:

· технические проблемы, не предусмотренные в рамках регулярных процедур планирования и управления ИТ, например «проблема 2000 года»;

· изменение технической политики производителей оборудования и ПО, например колебания компании Hewlett-Packard в отношении своей линии UNIX-серверов;

· изменение лицензионной политики производителей ПО, например введение фирмой Microsoft практики ограниченного срока действия лицензии на операционную систему Windows XP, а также другие возможные проблемы. Эти внешние риски находятся вне контроля предприятия и его ИС, вследствие чего совершенствование управления ИС не позволяет их устранить.

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

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

Рассмотрим общие принципы таких «чрезвычайных проектов», как мы и будем их называть в дальнейшем:

· целью проекта является восстановление сервиса, а не обеспечение работоспособности оборудования и ПО. Иными словами, при необхо­димости то и другое следует заменять;

· проект должен предусматривать несколько вариантов решения, вклю­чая основной (восстановление сервиса) и один или несколько резер­вных вариантов удовлетворения бизнес-требований в случае, если сервис обеспечить не удастся (данное условие не обязательно, если причина проекта — удорожание сервиса);

· необходимо оценить полные затраты по модели ФСА для основного и запасного вариантов решения;

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

Таким образом, разработка схемы проекта решения проблемы подра­зумевает несколько обязательных этапов:

1. Диагностика проблемы — определение перечня оборудования и ПО, затронутых проблемой, затем внутренних сервисов, основанных на данном оборудовании и ПО, и, наконец, внешних сервисов.

2. Сортировка нарушенных проблемой внешних сервисов по их при­оритетам. В результате определяется круг сервисов, восстанавлива­емых в рамках чрезвычайного проекта. Прочие сервисы восстанав­ливаются при выполнении обычных инфраструктурных проектов.

3. Разработка и оценка вариантов решения проблемы. В каждом ва­рианте анализируются, во-первых, способность решить проблему, и, во-вторых, затраты по модели жизненного цикла ИТ-решения. Исходя из последнего критерия среди допустимых вариантов выби­рается оптимальный.

4. Выполнение проекта и его мониторинг. Выбранный вариант реше­ния проблемы приводится в исполнение. Параллельно руководство проекта контролирует ход работ с целью определения отклонений от плана и их существенности.

5. Планирование резервных вариантов решения проблемы. При ре­шении крупномасштабных проблем предусматриваются резервные, обычно временные варианты поддержания работоспособности сер­виса при неудаче или срыве сроков выполнения основного плана работ. Такое планирование ведется параллельно работам по основ­ному плану проекта.

6. Оценка готовности решения. Производятся тестирование готово­го решения и анализ его готовности к эксплуатации. В зависимости от результатов анализа вводится в эксплуатацию основное решение либо приводится в исполнение резервный план. Также планируются мероприятия по обеспечению бесперебойного ввода решения в экс­плуатацию: подготовка персонала, создание и обучение специали­зированных бригад по решению проблем и т.д.

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

8. Запуск в эксплуатацию основного варианта решения проблемы, включающий мероприятия по обеспечению бесперебойного функ­ционирования решения в переходный период.

Вышеприведенная схема основана на опыте решения «проблемы 2000 года», являющейся на сегодняшний день крупнейшим проектом та­кого рода. В более простых проектах, таких как замена бухгалтерской системы, ряд шагов может быть опущен. Тем не менее базовая схема остается неизменной: оценка масштаба проблемы — выбор основного варианта решения — выполнение работ — планирование резервных ва­риантов — оценка готовности к эксплуатации.

Экономическая оценка проекта решения проблемы проводится в сле­дующем порядке. Исходный пункт — оценка потерь, связанных с непред­виденными обстоятельствами. Эти потери складываются из трех состав­ляющих:

1. Потери от возможного отказа сервисов, затронутых проектом. Дан­ные для такой оценки собираются в рамках модели ФСА в ИС пред­приятия (см. подтему 9.3). При необходимости, данные о потерях уточняются бизнес-подразделениями.

2. Потери от сокращения жизненного цикла ИТ-решения. Данные для этой оценки собираются в рамках модели жизненного цикла ИТ-ре­шения (см. подтеме 9.2.1).

3. Далее оценивается удорожание сервисов в связи с непредвиденны­ми обстоятельствами. Эти данные оцениваются также на основании модели жизненного цикла ИТ-решения (см. подтему 9.2.1).

Следует отметить, что в рамках одной проблемы необязательно при­сутствуют все составляющие потерь. Проблемы, связанные с политикой производителей, как правило, не создают рисков отказа сервиса^[39]. Анало­гичным образом непредвиденные технические проблемы создают риски отказа сервиса, но не ведут к удорожанию существующих ИТ-решений.

Затраты на проект оцениваются на этапе 3 и корректируются на по­следующих этапах с учетом необходимых изменений в плане и бюджете проекта.

Решение о целесообразности проекта принимается на основа­нии сопоставления затрат на проект с оценкой потерь от непредвиден­ных обстоятельств. Риск отказа сервиса обычно служит достаточным основанием для чрезвычайного проекта. Напротив, удорожание серви­сов в результате изменения политики производителя необязательно тре­бует чрезвычайного проекта, а возникшие проблемы в определенных случаях могут быть устранены в рамках регулярных процедур развития ИТ-инфраструктуры. При оценке затрат необходимо учитывать возмож­ность изменений в других проектах развития ИТ, проводимых предпри­ятием, поскольку непредвиденные проблемы влекут за собой изменение уже существующих решений и стандартов инфраструктуры ИТ. Если тот или иной проект развития ИТ опирается на изменяемые решения, необ­ходимы изменения в таком проекте.

Рис. 9.12 Принятие решений по проекту решения проблем.

Если проект был начат, затраты списываются на проект как времен­ный объект затрат. При успешном завершении проекта затраты списы­ваются на сервисы ИТ, затронутые непредвиденными обстоятельствами.

Схема принятия решения по проекту решения проблем приведена на рис. 9.12. Оценка возможных потерь от непредвиденных обстоятельств проводится совместно бизнес-подразделениями (уточнение потерь от от­каза сервиса) и ИС (оценка прочих видов потерь). На основании сово­купной оценки потерь оцениваются варианты решения с учетом влияния на другие проекты. На основании основного и резервного вариантов ре­шения формируются основная и альтернативная оценка затрат. Решение о целесообразности проекта принимается Комитетом по изменениям. При значительном объеме проекта решение принимает Правление пред­приятия. Это имело место, например, в случае «проблемы 2000 года». Ее решение требовало от крупнейших российских предприятий затрат в десятки миллионов долларов. Эти суммы находились в исключительной компетенции Правления соответствующих предприятий.