Автор работы: Пользователь скрыл имя, 06 Декабря 2013 в 15:46, лекция
Любое предприятие постоянно решает двуединую задачу – движется к достижению своих стратегических целей, и адаптируется к изменению окружающей среды. При этом долгосрочные цели развития остаются неизменны, а способы их достижения могут меняться в зависимости от изменения обстановки на рынке, в экономике, в законодательстве, и т.д.
Любое предприятие постоянно решает двуединую задачу – движется к достижению своих стратегических целей, и адаптируется к изменению окружающей среды. При этом долгосрочные цели развития остаются неизменны, а способы их достижения могут меняться в зависимости от изменения обстановки на рынке, в экономике, в законодательстве, и т.д.
Но именно эта способность у большинства компаний зачастую отсутствует, ибо не рассматривается как объект управления. Если же компания хочет быть гибкой в достижении своих целей, постоянно соответствуя требованиям окружающей среды, ей необходимо уметь управлять изменениями.
Цель построения всякой системы управления — достижение состояния, при котором все имеющиеся объекты управления будут находиться под контролем и готовы адекватно реагировать на управляющие воздействия. Методология ITSM (IT Service Management) рассматривает пути достижения такого состояния. Неотъемлемой частью процесса управления является наличие возможности контролировать текущее состояние всех систем и их компонентов. Когда речь идет об ИТ-инфраструктуре (оборудование и программное обеспечение, документация и вспомогательные службы, окружающая среда и подготовленный персонал), обычно возникают следующие задачи:
На начальном этапе следует определить, что входит в ИТ-инфраструктуру и насколько подробно предполагается отслеживать ее отдельные элементы. Излишне высокая степень детализации позволяет при необходимости учесть даже минимальные возможности и отклонения, однако требует существенных ресурсов на ведение базы данных. Здесь, как и в других областях, должно работать простое правило: издержки, связанные с внедрением и эксплуатацией системы не должны превышать положительного эффекта от ее внедрения. Существенное внимание следует уделить разработке системы классификации. Простейший вариант — все перенумеровать по порядку, является самым дешевым, но очень слабо будет помогать в дальнейшей деятельности. Желательно, чтобы по учетному номеру можно было определить, к какому типу относится конфигурационная единица, какой она версии и.т.д. Отсюда следует полезность структурированной системы кодирования, которая однозначно намного удобнее последовательных номеров. Все имеющиеся конфигурационные единицы должны быть помечены соответствующими им учетными номерами. Наличие четкой и понятной наклейки позволит при необходимости легко определить номер каждой конфигурационной единицы, тем самым сократив время на ее идентификацию. После того, как элементы инфраструктуры промаркированы, встает вопрос об организации базы данных, содержащей информацию о них. Она именуется «База данных конфигурационных единиц» (Configuration Management Data Base — CMDB).
Изменения на рынке и в технологиях постоянно приводят к необходимости внесения изменений в информационную систему, с целью предоставления бизнес - подразделениям именно тех услуг, которые им требуются в данной ситуации. Анализ указывает на то, что причиной большинства проблем, возникающих при эксплуатации ИС являются неавторизованные или непроверенные изменения, произведенные в системе. Содержание процесса управления изменениями составляют учет изменений и координацию деятельности персонала, который проводит эти изменения. Процесс инициализируется в результате выполнения различных задач управления, обуславливающих внесение изменений в конфигурационную базу данных в соответствии с правами, предоставленными тому или иному «владельцу». Одним из основных результатов процесса является комплексное изменение информации в базе данных конфигураций (Configuration Management Database, CMDB) в рамках процесса управления конфигурацией. В рамках этого же процесса в автоматическом режиме могут фиксироваться сведения обо всех инцидентах, текущих метрик услуг, инвентаризационные данные и т.п. Важная особенность этого процесса — обеспечение способности возврата к исходному состоянию базы данных CMDB в случае неуспешного завершения всех взаимосвязанных процессов или принятия решения об отказе от выполнения конкретного изменения. Процесс управления изменениями частично реализован в Remedy Help Desk и в виде запросов на изменения (Request for Change, RFC) может использоваться для небольших компаний, однако в полном объеме он представлен отдельным приложением Remedy Change Management, которое реализует процедуры утверждения/согласования, стоимостные оценки, оценки рисков и пр. Если при использовании Remedy Help Desk процесс управления изменениями только обозначен, то применение Change Management за счет средств настройки позволяет покрыть все возможные требования к данному процессу.
Иногда изменения могут не привести к ожидаемому результату, или, что еще хуже, оказать неблагоприятное воздействие на работу различных систем и приложений. В этом случае следует вернуть все системы к состоянию, которое предшествовало внесению изменения.
Сегодняшняя ситуация на мировом рынке заставляет многие компании меняться, чтобы сохранить имеющиеся и приобрести новые конкурентные преимущества. Согласно определению словаря Webster’s Ninth New Collegiate Dictionary, «изменить» значит «придать чему-либо другое положение, задать другое направление или курс, совершить сдвиг от одной позиции к другой, модифицировать, трансформировать, заменить, перевести в другое качество». Термин «управлять» означает «умело контролировать или направлять, осуществлять организаторские, административные и контролирующие функции». Применительно к организациям под термином «изменения» будем понимать внедрение новых бизнес-процессов и технологий для преобразования деятельности организации в соответствии с требованиями рынка и извлечения выгоды с помощью создавшихся в бизнесе возможностей. Иными словами, управление изменениями — это процесс, задача которого согласовать и внедрить изменения в соответствии с экономическими и техническими возможностями компании.
Непосредственно применительно к специфики информационной инфраструктуры под изменением подразумевается любое изменение, происходящее в ИТ. инфраструктуре, например, замена, ремонт или перемещение оборудования, установка нового ПО, закупка техники и т.д. Для специалистов в области информационных технологий частые изменения в этой сфере — большая «головная боль», поскольку донастраивать системы под изменяющиеся бизнес-процессы приходится достаточно часто и в срочном порядке. Если запланированные изменения осуществляются медленно, то это мешает бизнесу и вызывает снижение его конкурентоспособности, что в конечном итоге приводит к недовольству бизнес-подразделений информационными технологиями.
Одним из источников информации о том, каким образом нужно внедрять в IT-компании процесс управления изменениями, является ITIL (Information Technology Infrastructure Library — «библиотека IT-инфраструктуры»), где все описание приведено на детальном уровне. Компании, поставившей перед собой цель внедрить этот процесс или усовершенствовать уже существующий, следует ознакомиться в ITIL с основными принципами процесса и выбрать из них те, которые подходят к ее собственным задачам. Для многих крупных компаний процесс управления изменениями, изложенный в ITIL, может показаться слишком простым, тогда как маленьким фирмам попросту не хватит ресурсов для внедрения точной копии системы управления изменениями, данной в ITIL. В таком случае следует внедрить основные принципы и выбрать один сценарий процесса, а затем постоянно работать над его улучшением.
В соответствии, с определением изложенном в ITIL под процессом «управления изменениями» принято понимать процесс контроля и управления внесением изменений в инфраструктуру и различные аспекты сервисов, ответственный за минимизацию разрушений и неудобств для предоставляемых сервисов при внесении изменений.
Цель процесса управления изменениями — обеспечение внесения Изменений в IT-инфраструктуру в соответствии со стандартизованными процедурами, для эффективного проведения изменений и минимизации воздействия изменений на функционирование инфраструктуры.
Основные цели:
Общая схема проведения изменений начинается с регистрации запроса на изменения — Request for Change (RFC), причем здесь запрос попадает в сферу управления процессом управления изменениями, то есть фактически становится его экземпляром. На данном этапе изменению присваивается идентификационный номер, и в дальнейшем осуществляется классификация запроса, то есть фактически определяется сценарий, по которому данный запрос будет обрабатываться.
Многие компании считают необходимым следовать одному сценарию процесса для всех изменений. На самом деле библиотека ITIL позволяет использовать различные сценарии процесса управления изменениями. Точнее, может быть один сценарий для незначительных изменений с малой степенью риска неучтенных ошибок, а также более совершенные сценарии в случае существенных и масштабных изменений. Например, одна и та же компания может поддерживать сценарии для изменений и с малой, и со средней, и с повышенной степенью риска. Такой подход обеспечит гибкость и своевременность процесса, а также приведет к снижению себестоимости работ по его реализации.