Принципы организации ИТ подразделения компании. Часть первая

Эффективность работы современного предприятия напрямую зависит от эффективности работы ИТ подразделения. Качество работы ИТ существенно влияет на работу бизнеса, т.к. при помощи ИТ поддерживаются основные бизнес процессы компании. Более того, от качества работы ИТ напрямую зависит конечная стоимость товаров и услуг предлагаемых компанией потребителю. Чем больше тратиться на ИТ, тем выше стоимость конечной продукции, с одной стороны. С другой стороны, недофинансирование ИТ ведет к замедлению и нарушению бизнес процессов, что, в свою очередь, ведет к увеличению других издержек.

Как превратить информационные технологии из «черной дыры» пожирающей бюджет в инструмент помогающий компании динамично развиваться и конкурировать на рынке? Как соблюсти баланс между стоимостью ИТ и качеством их работы? Как упорядочить работу ИТ отдела и сделать её прозрачной?

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

Выход – воспользоваться передовым мировым опытом в области информационных технологий.

Одним из возможных ответов на поставленные вопросы является использование библиотеки ITIL (IT Infrastructure Library - библиотека инфраструктуры информационных технологий). ITIL – это библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

В этой статье мы постараемся как можно более кратко и доступно объяснить что такое ITIL, какие выгоды она несет предприятию и как применить ее на практике. Библиотека ITIL состоит из нескольких больших книг и очень трудно уложиться в весьма ограниченные рамки статьи, однако, мы попробуем…

Говоря о работе ИТ подразделения невозможно не упомянуть разработанную компанией Microsoft модель оптимизации ИТ-инфраструктуры. Эта модель помогает организациям понять и впоследствии улучшить состояние ИТ-инфраструктуры, а также получить представление о том, каких затрат она требует, каков уровень ее безопасности и гибкости в эксплуатации. В соответствии с этой моделью определено 4 уровня зрелости ИТ-инфраструктуры:

·         Базовый (Basic);

·         Стандартизированный (Standardized);

·         Рационализированный (Rationalized);

·         Динамический (Dynamic).

Так вот, использование ITIL – это прекрасный способ повысить уровень зрелости ИТ-инфраструктуры организации. Модель оптимизации позволяет быстро понять стратегическую выгоду и преимущества для бизнеса от перехода с «базового» уровня зрелости ИТ-инфраструктуры (при котором она обычно считается основной статьей расходов) к более динамичному, где ее ценность для бизнеса четко понятна и ИТ-инфраструктура рассматривается как стратегический актив, способствующий эффективному ведению бизнеса.

Приведем худший пример организации ИТ подразделения с инфраструктурой находящейся на базовом уровне зрелости..

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

Обращения пользователей по тем или иным вопросам не фиксируются. Невозможно отследить и систематизировать возникающие проблемы. Часто одну и ту же проблему приходится решать дважды двум разным людям, т.к. накопленные знания каждым отдельным человеком не систематизируются и не передаются остальным. Отсутствует корпоративная база знаний.

Установка нового ПО, ликвидация проблем в сети, внедрение нового оборудования и т.д. происходят не запланировано, спонтанно. Чем больше таких изменений происходит, тем запутаннее становиться ИТ инфраструктура и там больше времени требуется ИТ персоналу на решение возникающих проблем и восстановление после сбоев.

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

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

Конечно, это пример совершенно запущенного ИТ подразделения, однако, те или иные проблемы могут присутствовать и на вашем предприятии.

ITIL и ITSM

Существует несколько версий ITIL. Первая версия была разработана еще в конце 80-х годах. В конце 90-х ей на смену пришла 2-я версия. В настоящий момент, последней версией ITIL является 3-я. Наша статья базируется на 2-й версии ITIL. Основные принципы организации в версии 3 не изменились. Версия 3 является дополнением к версии 2 и в большей мере фокусируется на бизнес стратегию компании в целом. Кроме того, существуют мнения, что версия 3 не удалась. Она более сложна для понимания и не дает целостного представления о проблематике.

Закончив с историей, перейдем непосредственно к рассмотрению того, что представляет из себя библиотека ITIL и чем она может помочь в решении проблем возникающих в работе ИТ подразделения.

ITIL основывается на процессно-сервисном подходе к деятельности ИТ подразделения.

Что такое процесс? Процесс – это совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы и выходы. У процесса есть:

·         входы – то, что является исходным сырьем/данными;

·         выходы – результат/готовая продукция;

·         механизм – кто (люди) и что (оборудование, программы) работает внутри процесса;

·         требования – условия, по которым можно отличить правильный процесс от брака.

Любая деятельность ИТ отдела представляется как процесс.

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

Пользователи не знают и не хотят знать как и какие технологии используются в ИТ. Главное – чтобы они могли работать, а все возникающие сбои устранялись в минимальное время. Чтобы было к кому обратиться за гарантированной квалифицированной помощью. С другой стороны, пользователям необходимо понимать, что предоставление сервисов связано с определенными затратами.

Таким образом, мы получаем следующую картину: процессы – это то что происходит внутри ИТ подразделения. Они направлены на обеспечение сервисов, которые предоставляются внешним по отношению к ИТ подразделению пользователям.

Простой пример.

Пользователю необходимо выполнять печать документов на принтере. Печать должна осуществляется с 8 до 5. Время простоя не более 20 минут. Это и есть сервис, характеризующийся определенными параметрами.

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

В дальнейшем будем использовать этот простейший пример сервиса печати для демонстрации подходов ITIL.

Библиотека ITIL версии 2 состоит из 7 достаточно больших томов:

·         ITIL ICT infrastructure Management посвящена процессам планирования инфраструктуры, развертывания инфраструктуры, эксплуатации инфраструктуры и процессу технической поддержки;

·         ITIL Business Perspective призвана помочь понять бизнес-менеджерам предоставление ИТ-сервисов;

·         ITIL Application Management описывает полный жизненный цикл приложений;

·         ITIL Planning to implement Service Management рассказывает, как нужно организовывать проекты по внедрению ITIL;

·         ITIL Security Management описывает общие подходы к управлению информационной безопасностью.

·         ITIL Service Support – поддержка услуг (единственная переведенная на русский язык книга);

·         ITIL Service Delivery – предоставление услуг.

На базе двух последних книг (ITIL Service Support и ITIL Service Delivery) основывается концепция ITSM (IT service management - управление ИТ услугами). ITSM – наиболее популярная часть ITIL. Она непосредственно используется компаниями для организации работы ИТ подразделения.

И так, в первой части статьи мы рассмотрим том «ITIL Service Support» («Поддержка сервисов»), а также рассмотрим очень важный процесс из тома «ITIL Service Delivery» («Предоставление сервисов») – «Управление уровнем сервиса».

ИТ компании и ИТ-подразделения предоставляют различные сервисы своим потребителям. Часто случается так, что потребители не довольны качеством предоставляемых сервисов. Как определить на сколько качественно предоставляется тот или иной сервис? Для того чтобы сделать это, прежде всего необходимо определиться с самим понятием качества. Так что же такое качество?

Качество – это степень соответствия присущих характеристик требованиям.

Соответственно, не зная требований к сервису невозможно определить его качество. Первоочередной задачей ИТ подразделения является определение качественных характеристик сервисов. Эти характеристики должны быть согласованы с потребителями сервисов. Достигнутые договоренности как правило фиксируются в специальном документе – соглашение об уровне сервиса (SLA – Service Level agreement).

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

Вернемся к нашему примеру с принтером. Допустим, мы определили следующие параметры сервиса:

·         пользователь должен иметь возможность распечатывать документы;

·         время предоставления услуги (сервиса) – с 8 и до 17;

·         максимальное время простоя – 30 мин;

·         скорость печати – не менее 10 стр/мин.

Если в течении определенного в SLA времени предоставления услуг пользователь не может распечатать документ, при этом ИТ служба не может восстановить работоспособность более 30 минут, мы получаем снижение качества сервиса вплоть до полного его не предоставления. Т.е. ИТ служба не выполняет взятые на себя обязательства. Это повод к проведению серьезного разбирательства - почему так происходит.

С другой стороны, если пользователь пытается распечатать документ после 17 часов и у него это не получается, мы вправе указать ему на SLA. В этом случаем ИТ служба работает четко в соответствии с достигнутыми договоренностями. SLA помогает ИТ службе избежать необоснованных упреков пользователей, которые зачастую склонны требовать гораздо больше, чем входит в обязанности ИТ отдела.

Качество сервиса постоянно должно поддерживаться на определенном уровне или даже повышаться, т.к. ожидания потребителей со временем постоянно растут. Чтобы управлять качеством необходимо:

·         Планировать меры по улучшению (Plan);

·         Выполнять эти меры (Do);

·         Проверять выполнение (Check);

·         Устранение несоответствия (Act).

Это – так называемый цикл качества Деминга (PDCA цикл). Предоставляемый сервис должен регулярно контролироваться на предмет соответствия заявленным параметрам. В случае отклонения должны незамедлительно приниматься соответствующие меры.

Управление уровнем сервиса

Рассмотрим каким образом должна быть организована работа ИТ подразделения для управления уровнем сервиса.

На стыке между процессами проходящими внутри ИТ подразделения и сервисами предоставляемыми пользователям находится служба «Service Desk». Service Desk – это единая точка контакта пользователей с ИТ отделом. Основные задачи этой службы – это принятие и обработка запросов пользователей, координация выполнения запросов пользователей. Отныне пользователи не должны непосредственно обращаться к сотрудникам ИТ отдела. Все контакты осуществляются только через службу Service Desk. Более того, все обращения в обязательном порядке фиксируются и контролируются.

Что это дает:

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

2.       за каждое обращение будет назначен конкретный ответственный с которого можно требовать результаты обработки обращений;

3.       пользователи всегда знают к кому обратиться;

4.       прекращается неупорядоченная работа ИТ персонала по неадекватным запросам пользователей;

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

Вопрос о том, с помощью каких средств организовать службу Service Desk не относиться к компетенции ITIL. Тем не менее, можно сказать, что выбор этих средств сугубо индивидуален и зависит от масштабов компании и интенсивности использования информационных технологий.

Приведем простой пример:

В одной компании работал системный администратор. Пользователи постоянно донимали его различными вопросами, в том числе и теми, которые не относятся к его компетенции. «Я не могу вставить в Word картинку», «А куда пропал мой файл» и т.п. В один прекрасный день ему это надоело. Что он сделал? Он просто завел специальную тетрадку и сказал пользователям «Все ваши проблемы пишите в эту тетрадь. Все что там напишите – буду делать. Все остальное – нет.» С тех пор жизнь системного администратора стала налаживаться. Когда пользователи сталкиваются с необходимостью четко формулировать свои вопросы, они предварительно обдумывают ситуацию и, часто уже на этом этапе находят пути её решения или осознают что это не относиться к компетенции ИТ отдела. С другой стороны, запросы пользователей теперь не остаются без внимания, т.к. они документально зафиксированы.

Перед вами пример простейшего «Service Desk». Все крайне просто, но, в то же время, функционально.

Для более крупных компаний существует специальные программные продукты для автоматизации деятельности ИТ отдела в соответствии с ITSM. Можно также достаточно просто реализовать Service Desk на базе универсальных систем коллективной работы. Например, на базе Microsoft SharePoint.

Теперь перейдем непосредственно к рассмотрению тех процессов которые происходят внутри ИТ подразделения, и которые направлены непосредственно на предоставление и поддержание сервисов.

В соответствии с ITIL версии 2, таких процессов 10 штук:

·         процесс управления инцидентами;

·         процесс управления проблемами;

·         процесс управления конфигурациями;

·         процесс управления изменениями;

·         процесс управления релизами;

·         процесс управления уровнем сервиса;

·         процесс управления мощностями (емкостью);

·         процесс управления доступностью;

·         процесс управления непрерывностью;

·         процесс управления финансами.

Часть этих процессов мы рассмотрим во второй части статьи.

Управление инцидентами

Начнем с понятия инцидент. Предоставление ИТ сервисов всегда сопряжено со сбоями или, по крайней мере, с затруднениями.

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

Основная цель процесса управления инцидентами – это как можно скорее восстановить нормальное (соответствующее SLA) предоставление сервиса. Причем устранение необходимо произвести как можно в более сжатые сроки и, возможно, без выявления корневой причины инцидента. Волне допустимым является так называемое обходное решение (Work-around).

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

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

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

·         Сбой. Что-то не работает или работает не так, как должно. Например, не осуществляется печать на принтере, не включается компьютер, нет доступа к сетевой папке.

·         Запрос на обслуживание. Сбоя и неполадок нет, но обращение зафиксировано. Запрос на обслуживание не содержит информации о неработоспособности предоставляемого сервиса - это вид работ, запрашиваемый у вас, без возникновения ошибки в работе систем. Это обращение может быть связано с оказанием технической поддержки пользователю («Какую кнопку нажать, чтобы осуществить печать на принтере»). Также обращение может быть связано выполнением регламентных работ. Например: заведение учетной записи нового пользователя, добавление в список доступа и т.п. Данный вид запроса, как и сбой, требует безусловного выполнения.

·         Запрос на изменение. Сбоя снова нет, однако пользователи требуют определенных изменений в инфраструктуре. Поступивший запрос требует согласования и вполне может быть отклонен. Например: требуется заменить CRT монитор на LCD монитор, требуется установить принтер формата А3 с производительностью более 30 страниц в минуту. Выполнение этих запросов связано с существенным изменением в инфраструктуре. Выполнение их может быть проведено только после дополнительного исследования и согласования со всеми заинтересованными сторонами.

Все запросы в обязательном порядке классифицируется службой «ServiceDesk». Уже на этом этапе некоторые запросы пользователей могут быть отклонены, как несоответствующие задачам ИТ подразделения. Это позволяет экономить рабочее время ИТ персонала. На должности специалистов ServiceDesk как правило ставятся менее квалифицированные кадры, с меньшим уровнем заработной платы. Фильтрация обращений позволяет снять нагрузку с более квалифицированных сотрудников, которые потенциально могут быть задействованы для разрешения проблем.

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

Линии тех. поддержки могут выглядеть следующим образом:

Нужно стремиться к тому, чтобы решить проблему как можно на более низком уровне. Для этого, в частности, существует корпоративная база знаний, в которой накапливаются возможные решения типовых вопросов.

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

·         выявление и регистрация;

·         классификация и начальная поддержка;

·         поиск решения;

·         применение решения (выполнение определенных действий ИТ специалистами);

·         закрытие;

·         контроль, информирование и отчетность.

Закрытием называется формальное (официальное) прекращение работ над инцидентом. Как правило, закрытие состоит в проверке того, что пользователь согласен с тем, что инцидент устранен.

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

У процесса «Управление инцидентами» как и у любого другого процесса есть свои параметры (метрики), по которым контролируется качество этого процесса. Метриками в частности являются: среднее время устранения, процент инцидентов устраненных вовремя, процент инцидентов устраненных Service Desk без обращения к более высоким уровням поддержки и т.п.

На основе этих показателей делаются соответствующие выводы о совершенствовании методов работы.

Выгоды от управления инцидентами:

·         снижение потерь для бизнеса;

·         повышение продуктивности сотрудников;

·         точная картина происходящего;

·         эффективность руководства.

Управление проблемами

Целью данного процесса является снижение количества инцидентов. Для её достижения этот процесс ищет причины возникновения инцидентов и инициирует действия по улучшению ситуации.

Что же такое проблема? Проблема – это неизвестная корневая причина одного или более инцидентов.

Например:

·         Постоянно возникают ошибки печати на принтер;

·         Большое количество запросов на консультацию по продукту MS Office 2007.

После того как решение проблемы найдено, она становиться известной ошибкой (known error). Известная ошибка – это проблема, причина которой выявлена.

Например:

·         Проблема: Постоянно возникают ошибки печати на принтер;

·         Известная ошибка: неисправен коммуникационный кабель. Заменить.

·         Проблема: Большое кол-во запросов на консультацию по продукту MS Office 2007;

·         Известная ошибка: Недостаточная квалификация пользователей. Провести обучение.

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

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

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

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

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

Известные ошибки, требующие изменения инфраструктуры порождают запрос на изменение. Таким образом, мы плавно переходим к одному из следующих процессов – «Управление изменениями». Однако, прежде чем что-то менять, нужно точно знать где что находится и как взаимосвязаны компоненты инфраструктуры. В этом нам поможет процесс «Управление конфигурациями».

Выгоды от процесса управления проблемами:

·         снижение потерь для бизнеса за счет уменьшения количества инцидентов;

·         улучшение качества сервисов, и, как следствие, рост доверия со стороны заказчика.

Управление конфигурациями

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

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

Процесс состоит из 5 операций:

·         планирование;

·         идентификация;

·         контроль;

·         отчетность;

·         аудит.

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

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

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

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

Эти простые правила гарантируют актуальное состояние CMDB. Никто не в праве самостоятельно изменять компоненты инфраструктуры и связи между ними, а также неподконтрольно менять логическую модель.

Операция «Отчетность» позволяет в любой момент времени получить срез текущего состояния CMDB. Если все организовано правильно, этот срез будет соответствовать реальному положению дел в ИТ инфраструктуре.

Не смотря на то, что вся работа на наш взгляд организованно правильно, необходимо регулярно проводить аудит CMDB. Аудит – это сверка данных хранящихся в CMDB с фактической ситуацией.

Выгоды от процесса управления конфигурациями:

·         всегда актуальная информация о состоянии ИТ инфраструктуры;

·         сокращение затрат на ИТ;

·         основа для улучшения качества сервисов;

·         основа для финансовой оценки сервисов.

Управление изменениями

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

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

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

·         покупка нового принтера сопряжена с чрезмерными финансовыми затратами;

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

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

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

Чтобы обеспечить это, процесс состоит из следующих операций:

·         регистрация и фильтрация;

·         оценка;

·         координация внедрения;

·         обзор после внедрения.

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

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

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

В ряде случаев на этапе внедрения выясняется, что изменение не может быть проведено. Для этого должен быть разработан план отмены изменения (Back-out).

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

Выгоды от управления изменениями:

·         уменьшение негативного воздействия от изменений;

·         более точная оценка затрат на изменения;

·         полная информация об изменении как до начала, так и после окончания его внедрения;

·         повышение производительности персонала при проведении изменений;

·         устойчивость ИТ инфраструктуры к изменениям.

Управление релизами

Когда накапливается значительное количество изменений, можно говорить о том что ИТ инфраструктура претерпит существенное преобразование и прейдет в некоторое новое глобальное состояние.

Это может случиться при миграции на новую программную платформу (переход с Windows 2003/XP на Windows 2008/Vista или замена почтового клиента на всех ПК), при миграции на новую аппаратную платформу (обновление серверной части инфраструктуры).

В ITIL такое событие называется релизом. Релиз – совокупность одобренных изменений. Релизы делятся по масштабу (мелкий/обычный/крупный) и по срочности (экстренный/срочный/не срочный).

В рамках релиза определяется единица релиза – часть инфраструктуры которая изменяется целиком.

Релиз может быть как полным так и частичным, в зависимости от того все ли компоненты релиза заменяются. Каждому релизу присваивается идентификатор (v.1.0, v.1.0.1, v.2.0 и т.д.).

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

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

Данный процесс состоит из 8 последовательных операций, для которых определены 3 сферы выполнения – среда разработки, среда тестирования и рабочая среда. Только по завершению всех операций в средах разработки и тестирования релиз попадает в рабочую среду.

Управления релизами проходит под контролем процесса управления изменениями.

Перечень операций процесса управления релизами:

·         разработка политики процесса;

·         планирование релиза;

·         разработка, построение и конфигурирование релиза;

·         тестирование релиза;

·         приемка релиза;

·         планирование развертывания релиза;

·         коммуникации, подготовка и тренинги;

·         дистрибуция и установка.

Выгоды от процесса управления релизами:

·         снижение риска возникновения ошибок в используемых системах;

·         снижение количества прерываний сервисов из-за новых релизов;

·         стандартизация ПО и аппаратного обеспечения;

·         централизация проектирования, закупок ПО и аппаратного обеспечения.

Заключение

И так, в первой части статьи мы познакомились со всеми процессами из тома ITIL «Поддержка услуг», а также с процессом «Управление уровнем сервиса» из тома «Предоставление услуг». Рассмотренные процессы были направлены на поддержание функционирующих сервисов. Мы увидели как должна организовываться работа ИТ подразделения компании для качественной поддержки пользователей.

Основываясь на процессно-сервисном подходе ITIL, ИТ подразделение начинает работать четко и слаженно. Все происходящие процессы прозрачны и контролируемы. Как следствие, поведение ИТ инфраструктуры становится более прогнозируемым.

Все это ведет к повышению качества работы пользователей. А это, в свою очередь, обеспечивает бесперебойное функционирование и совершенствование бизнес процессов. Компания может быть уверена в том, что ИТ – надежный фундамент её работы, который обеспечивает ей конкурентоспособность и динамичное развитие.

В следующей части статьи мы рассмотрим процессы из тома «Предоставление услуг», которые помогут нам организовать предоставление сервисов.

Комментарии

Написать комментарий