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

RFC и Change proposal: кто первый?

После недавно проведённого курса ITIL RCV пришёл к выводу, что будет полезно зафиксировать некоторые комментарии относительно взаимосвязей запроса на изменение (Request for change, RFC) и предложения об изменении (Change proposal). Как оказалось, термин “предложение об изменении” не всем понятен и вызывает у коллег некоторые вопросы, в частности: в чём разница между RFC и Change proposal и как они связаны между собой, что из них первично; если первичным является Change proposal, то что является его источником. Чтобы разобраться с данными вопросами, заглянем в учебник. Вот, что написано про предложение об изменении в глоссарии*: Предложение об изменении (Change proposal) – документ, содержащий…

Определение атрибутов процесса с помощью COBIT 5

Недавно заново для себя открыл структуру описания фактора влияния из COBIT 5[1]. У каждого фактора влияния заданы универсальные атрибуты. Вот они: Источник: COBIT 5: Бизнес-модель по руководству и управлению ИТ на предприятии Причем, не важно речь о процессе, услуге или, скажем, информации, набор атрибутов не изменится. Утверждается, что единая структура позволяет: работать со всеми факторами влияния на единой, простой и структурированной основе; управлять комплексными взаимодействиями; обеспечивать успешные результаты работы факторов влияния. Вроде все слова понятные, но вот что из них следует – здесь у меня было больше вопросов, чем ответов. И лишь недавно, на мой взгляд, картинка в целом сложилась. В этой…

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

Завсегдатай всем известного сайта 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: Содержание политики релизов

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

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

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

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