Управление изменениями Archives – Страница 8 из 14

О, это сладкое слово — Релиз!

Завсегдатай всем известного сайта allthingsitsm.com Марк Смолли (Mark Smalley) опубликовал заметку о релизах ПО, и о том, как в среде ИТ-специалистов поступают при возникновении проблем с ними. Марк говорит о том, что иногда при возникновении сложностей с релизами, в силу их значительной временной дискретности, некоторые компании принимают меры к "починке релиза", нежели к "починке конвейера релизов". Далее в заметке излагаются закономерные выводы о том, что именно второй подход в среднесрочной перспективе способен предоставлять результаты более стабильного качества. Для выбора способа улучшения нам приходится оценивать множество факторов: критичность приложения для бизнеса/потребителя, риски и ущерб от возможных сбоев, репутационный риск и способность поставщика услуги принять его….

Новостной поток, 4 апреля 2016, последний комментарий 7 апреля 2016

Может ли Change Management быть “бумажным”?

Вопрос может показаться странным, но он возник не на пустом месте. Если на этапе разработки процесса нет ясности, каким образом будет решаться вопрос автоматизации, процесс проектируется "на бумаге". Разрабатывается только регламент процесса, для которого пока не предполагается соответствующего функционала в ITSM-системе. Функционала, обеспечивающего возможности учёта объектов управления и направляющего исполнителей ролей процесса по нужному пути. В целом, если автоматизация предполагается на следующем этапе, в виде отдельного проекта, никаких противоречий, вроде бы, нет. Ведь это, как раз, правильно – проектировать процесс от потребностей, а не выстраивать его в зависимости от возможностей конкретной ITSM-системы. Затем сформулировать требования к автоматизации и "уложить" процесс…

Артём Мукосеев, 1 марта 2016, последний комментарий 16 марта 2016

Изменения и релизы: они такие разные, но они – пара

Вопрос о разделении задач и ответственности между процессами управления изменениями и управления релизами задает себе почти каждый из впервые знакомящихся с преобразованием услуг. Просто и понятно на этот вопрос отвечает Вонс Мерфи (Vawns Murphy) в своем блоге на theitsmreview.com. Не смотря на то, что для этих процессов декларированы очень близкие цели по обеспечению реализации изменений услуг с наименьшими рисками, ключевые акценты этих процессов различны. Управление изменениями выступают в качестве защитников продуктивной среды, обеспечивая выполнение успешных авторизованных изменений. Управление релизами, обрабатывая поток изменений, занимается их пакетированием. Тем самым процесс обеспечивает экономию ресурсов и также минимизирует риски, обеспечивая надлежащий контроль над непосредственным исполнением изменений (развертыванием релиза). Для того, чтобы эти…

Моделирование изменений, как инструмент преодоления разногласий

Что делать, когда единые правила не работают? Когда разные группы участников одного процесса работают по своим правилам? Причём, не из прихоти, а в силу определённой специфики своей деятельности? В качестве примера рассмотрим знаменитую историю про трёх товарищей, которые не смогли сдвинуть с места воз с поклажей. Ведь золотые слова написал Иван Андреевич! Но можно взглянуть на проблему и чуть с другой стороны. Все трое ведь банально РАЗНЫЕ! И по-другому не могут! Значит, надо их правильно организовать. Менеджера процесса на них нет, да с регламентом! Только вот ведь незадача: смотри пункт 1 – они все разные. Ну нельзя им всем просто…

Артём Мукосеев, 29 января 2016, последний комментарий 4 марта 2016

Два слова об управлении релизами

После нескольких недавних обсуждений, как внутренних, так и по вопросам заказчиков, хочу написать буквально два слова об управлении релизами. Первое – когда пакетирование изменений в релизы имеет смысл, второе – как часто выпускать релизы. Вопрос о том, когда применять практику управления релизами – не праздный, поскольку эта практика несет с собой не только плюсы, но и минусы, замедляя среднюю скорость внедрения готовых к развертыванию изменений в продуктив. С моей точки зрения пакетирование изменений в релизы «показано» по отношению к тем системам, которые удовлетворяют следующим двум требованиям: система является критичной / значимой для заказчика – её простой или нарушения в работе…

Дмитрий Исайченко, 28 октября 2015, последний комментарий 14 ноября 2015

Почему для эффективного проведения изменений надо использовать несколько подходов

Осень в самом разгаре, тем не менее, мы хотим вас познакомить с интересной заметкой Роберта Страуда, вышедшей весной 2015 года. Роберт работает в течение многих лет в области управления ИТ-услугами (ITSM), в том числе над тем, как наилучшим образом не просто решать, но и предотвращать инциденты. Как известно, не зависимо от того, насколько вы готовы, инциденты будут случаться. Однако, для эффективного управления услугами подготовка имеет решающее значение. Роберт начинал свой путь в ITSM с организации процесса управления изменениями. Он вспоминает шквал инцидентов, который возникал после релиза программного обеспечения, проведенного в выходные. После того, как процесс управления изменениями был реализован, появилось…

Всегда ли нужен CAB в управлении изменениями?

Таким вопросом задаётся в своём блоге Стюарт Рэнс и делится своими соображениями по этому поводу. Он замечает, что в организациях люди непременно стремятся отнести каждое изменение к одному из следующих типов (обратите внимание, что определения близки к тексту ITIL, но не до конца ему соответствуют): Стандартные изменение – связанные с низким риском, понятные, полностью задокументированные, предавторизованные, которые могут проводиться без необходимости дополнительного согласования). Часто выполняются как запросы на обслуживание, но также могут включать операционные изменения. Нормальные изменения – являются предметом рассмотрения на Комитете по изменениями (CAB), который обычно собирается один раз в неделю для рассмотрения запросов на изменения, полученных в…

Новостной поток, 2 сентября 2015, последний комментарий 7 сентября 2015

Приоритеты изменений

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

Дмитрий Исайченко, 23 августа 2015, последний комментарий 9 октября 2015

Checklist: Содержание политики релизов

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

Не так просто управлять изменениями, но оно того стоит

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

Что включать в отчет о PIR?

Все чаще на курсах, когда разбираем процесс управления изменениями, слушатели интересуются Post-Implementation Review в целом и форматом отчета с итогами оценки в частности. На основании рекомендаций ITIL, открытых источников и проектного опыта видится приблизительно следующая картина: 1. Введение 1.1 Состав группы оценщиков 1.2 Охват и критерии оценки 2. Результаты оценки 2.1 Достижение целей, стоявших перед изменением (например, сократить затраты на обслуживание, сократить ресурсные или временные затраты на те или иные операции, предоставить новую функциональность, повысить производительность, сократить количество инцидентов, повысить безопасность и т.д.) Цель Что было Что хотелось Что получилось Отметка о достижении 2.2 Параметры качества (если целью изменения было воздействие…

Павел Дёмин, 15 февраля 2015, последний комментарий 27 октября 2015

Портал №1 по управлению цифровымии информационными технологиями

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

Портал №1 по управлению цифровыми
и информационными технологиями