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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

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

Всё про контроль изменений в ИТ-инфраструктуре

Управление изменениями — формальный подход не сработает

Вам скучно на собраниях совета по управлению изменениями? Нам это знакомо. Значит ли это, что не надо управлять изменениями? Нет, конечно! Значит ли это, что компаниям нужно как-то помочь в управлении изменениями! Да, безусловно. Мы проанализировали проблемы быстрорастущих организаций, которые пытаются управлять изменениями, и идентифицировали, как нам кажется, четыре основных проблемы таких компаний. 1. Планируемые изменения нужно тщательно проверять до их утверждения Утверждение предложенных изменений — обязанность старших менеджеров или самого CIO. Но люди они занятые, и тщательно проверять предлагаемые изменения им некогда. Поэтому они их утверждают, не проверяя — а потом, когда кому-то пора нести ответственность, пригвождают к позорному…

7 советов для успешного CAB

Vawns Murphy,  практикующий менеджер изменений (в прошлом) в своей статье "The 7 habits of highly effective CABs" делится мыслями о важности CAB: «Как менеджер изменений, могу сказать, что заседания Комитета по изменениям одни из самых важных заседаний, которые только могут быть в организации, предоставляющей услуги. На них получаешь представление о том, что будет происходить с услугами в ближайшее время, как обстоят дела с уже внедренными изменениями и подумать об улучшениях. Встречи CAB  – это все о людях, участвующих в них, и плохо организованная встреча не принесет никаких результатов". Vawns делится советами для эффективных встреч Комитета (CAB), которыми пользовалась сама : Шаг 1: сила в…

Святая троица Chg+Rel+Cfg

Каждый раз, когда мне приходится работать в проектах, где мы касаемся этой связки процессов, в моей голове возникает голос сомнения. Насколько правильно мы подходим к этим процессам, действительно ли порядок, который мы предлагаем во время внедрения – наилучший?   Думаю, что ни для кого из наших читателей не является тайной, что известные источники рекомендуют проектировать и внедрять эти процессы совместно, т.к. синергия и совместное влияние этих процессов друг на друга действительно очень велики. Да, это так, если мы говорим о сферических единорогах в вакууме. Реальная жизнь неизбежно вносит свои коррективы. Если мы говорим о зрелых процессах, которые реально работают значимое время в организации, то мы действительно можем говорить об ощутимой значимости этих…

7 R’s – суть управления изменениями

Для чего нужен процесс Управление изменениями? Коротко – для контролируемого проведения изменения при прохождении всех этапов, определенных для конкретного изменения. В книге ITIL Service Transition авторы предлагают 7 вопросов (7R's – так как ключевые слова на "R"), на которые нужно ответить тем, кто проводит изменения, – чтобы оценка влияния была целостной, и был выдержан баланс рисков и эффективности проводимого изменения. Собственно вопросы: Who Raised the Change?  – кто инициирует изменение What is the Reason for Change? – какова причина для данного изменения What is the Return? – что мы получим в результате изменения Who is Responsible to do the change? – кто ответственный за…

Major incident – когда становится горячо…

На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что тема управления ИТ-подразделением для них вообще новая и термин «значительный инцидент» слышится впервые, хотя в реальной жизни – это знакомая ситуация, иногда – потому что не совсем ясно, где провести границу между просто инцидентом и значительным инцидентом, и почти всегда – как с ним работать. О ключевых моментах, которые нужно учесть при работе со значительными инцидентами, пишет Neven Zitek в своей статье «Управление значительными инцидентами – когда становится горячо…»  Что такое значительный инцидент? В теории значительный  инцидент – это инцидент с самым высоким влиянием и…

Граница между изменением и проектом

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

Модели изменений в контексте DevOps

Концепция DevOps всё больше проникает в умы руководителей и сотрудников ИТ-подразделений, а также в наши заметки на портале REALITSM. Это не удивительно, ведь с трудностями при организации взаимодействия подразделений "Dev" и "Ops" так или иначе сталкиваются почти все, у кого есть программное обеспечение заказной разработки. Мы регулярно помогаем нашим заказчикам решать задачи интеграции деятельности департаментов разработки и поддержки в рамках процессов управления инцидентами/запросами и управления изменениями (о нём и пойдёт речь дальше), поэтому знаем о возникающих проблемах не понаслышке. Поэтому никак не можем остаться в стороне от концепции, призванной данные проблемы решать. На всякий случай сразу уточню – при этом…

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) опубликовал заметку о релизах ПО, и о том, как в среде ИТ-специалистов поступают при возникновении проблем с ними. Марк говорит о том, что иногда при возникновении сложностей с релизами, в силу их значительной временной дискретности, некоторые компании принимают меры к "починке релиза", нежели к "починке конвейера релизов". Далее в заметке излагаются закономерные выводы о том, что именно второй подход в среднесрочной перспективе способен предоставлять результаты более стабильного качества. Для выбора способа улучшения нам приходится оценивать множество факторов: критичность приложения для бизнеса/потребителя, риски и ущерб от возможных сбоев, репутационный риск и способность поставщика услуги принять его….

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM