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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

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

Большие преобразования и маленькие процессы

Для снятия наличных я часто использую банкомат, находящийся в одном торговом центре. Всё бы хорошо, но пару месяцев назад у него появилась неприятная особенность — выдача чека после операции стала сопровождаться ожиданием в две-три минуты. При этом отказаться от печати чека нельзя, а оставлять его торчащим из банкомата мне не очень хочется. Неприятно, конечно же, но расположение этого места выдачи денег очень удачное, поэтому приходилось ждать. Как-то раз банкомат вместо традиционных трёх минут "завис" почти на десять. "Это уж слишком!", — подумал я и набрал номер поддержки банка, который был написан тут же на стикере. Оператор, принявший звонок, сообщил мне, что если...

Манифест скептиков от ИТ

Наш друг Роб Ингланд, широко известный как IT-Skeptic, в середине новозеландской зимы, задался целью составить манифест таких же как он. Вот, что у него пока получается.   Правила нельзя изменить революционным путём. Напротив: они эволюционируют со временем. Каждый раз когда мы пытаемся выкинуть старые правила в форточку, всё заканчивается плохо. Те, кто предлагает нам изменить всё — вендоры, аналитики, консультанты и лихорадочные СМИ — исчезают задолго до того, как наброшенное на вентилятор начинает планомерно разбрызгиваться. Мы можем прогрессировать только если будем совершенствовать то, что имеем, но не начинать каждый раз сначала... Здравый смысл не так то просто отыскать. Если он присутствует — берегите и сохраняйте...

Разбираемся с управлением релизами

И опять из навеянного недавними встречами и обсуждениями с Заказчиками. Вообще назначение процесса управления релизами и его организация вызывают массу вопросов: Нужен ли процесс управления релизами как отдельный процесс? Для обработки каких изменений будет привлекаться процесс управления релизами? В каких отношениях находятся процессы управления релизами и изменениями (кто кому выдаёт задания, кто перед кем отчитывается, кто принимает решения, а кто их исполняет)? Часть из этих вопросов уже поднималась в предыдущих обсуждениях на этом сайте. Стремясь привести свои давние мысли на этот счёт в порядок, я решил освежить свои знания первоисточников, коих использовал три: ITIL, BMC Service Management Process Model (SMPM),...

No country for CSI

ИТ Скептик, в свойственной ему юмористической манере, прошелся по одной из логических неувязок библиотеки ITIL – управление изменениями и постоянное совершенствование. Смысл управления изменениями – сделать так, чтобы продуктивная среда была максимально стабильна. Цель постоянного улучшения – непрерывно изменять продуктивную среду (услуги и процессы), отвечая на изменяющиеся условия. Постоянное совершенствование [как его описывает ITIL] похоже на ученых в белых халатах, которые аккуратно поворачивают ручки и снимают показания приборов, занося их в журнал наблюдений, чтобы по чуть-чуть оптимизировать производительность... ИТ-службы, которые я знаю и люблю – это кричащие люди в рабочих комбинезонах, которые носятся вокруг с огнетушителями... ...Руководство компании объявляет, что сделан выбор...

PIR в управлении изменениями

"Попаразитирую" немного, фактически используя блог в качестве форума. Коллеги, поделитесь, пожалуйста, практикой — как у вас (или у ваших заказчиков) организован PIR в управлении изменениями. Как это устроено организационно? Как PIR поддерживает система автоматизации процессов управления услугами? Что в этой практике вам кажется полезной или наоборот — вредно-бесполезным? Головы здесь порой собираются приличные. У таких и совета не грех попросить 🙂

Попытка измерить пользу от управления изменениями

Передовой опыт, или "лучшие практики", — рассуждает в своей колонке на ITSMPortal Aale Ross, — обычно основаны на экспериментальных исследованиях. Обычно, но не всегда. В ITSM то, что называется передовым опытом, часто представляет собой результат предположений и теоретических рассуждений, а иногда — опыта, но скорее частного, чем систематически и научно подтвержденного.  Существует много свидетельств практической пользы от организации службы поддержки. Удивительно, как часто на разного рода конференциях докладчики рапортуют об успехах в деле "внедрения ITIL", приводя в подтверждение именно преимущества, полученные от внедрения help desk.  Стремясь получить подтверждение пользы от внедрения в компаниях процесса управления изменениями, Aale Ross провел опрос финских ИТ-менеджеров. Представители...

Что такое CAB и зачем это надо?

В своей заметке на ITSM Watch Elizabeth Harrin приводит мнения нескольких экспертов о том, что такое CAB (Change Advisory Board), каковы основные требования к его участникам, и о том, кто такие эти его участники.   Интересно наблюдение о необходимости обеспечить прозрачность принципов принятия решений об одобрении или отклонении изменений для сотрудников организации (а не только для участников CAB). Важно обеспечить уверенность всех заинтересованных сторон в том, что решения принимаются в интересах организации, взвешено и с учетом мнения экспертов.  Полный текст заметки — на ITSM Watch

Выделенный Change manager

На семинаре itSMF 19.01.2011 обсуждали тему координаторов изменений. Идея заключается в том, чтобы отделить функцию общего контроля исполнения и организации работ по проведению изменений от функции организации обработки отдельных запросов на изменения. Первое — ответственность менеджера изменений (менеджера процесса управления изменениями), второе — небольшого количества людей, обычно называемых координаторами изменений. "Обычно" потому, что роль координатора изменений, не будучи упомянутой в ITIL, используется в большинстве распространенных вендорских процессных моделей, в частности в модели BMC, HP и IBM (только в IBM Tivoli Unified Process эта роль называется "Владелец изменений", это не очень здорово очередным неоднозначным использованием слова "Owner", но в данном случае это к...

Конфигурационные единицы, которых нет

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

Семинар по управлению изменениями и релизами

На этой неделе поучаствовал в совместном семинаре itSMF Russia и ГУУ на тему "Управление изменениями и релизами. Изюминки и трюки". Что могу сказать — по-моему, интересное мероприятие получилось. Около 70 участников. К сожалению, маловато заказчиков (по моим оценкам около трети участников), в основном — коллеги-консультанты-интеграторы. Тем не менее, были интересные вопросы, получилась довольно живая дискуссия. Все снимали на видео, может быть оно будет доступным (кому и когда пока не знаю). Бросается в глаза неоднородность аудитории. Об этом можно судить, например, по вопросам из зала. Диапазон широк. На "верхнем" крае — взаимодействие управления изменениями и проектами, управление сложными изменениями с вовлечением нескольких координаторов изменений...

Где граница между изменениями и «просто работой»?

Скептик отвечает на вопрос читателя о границе между Изменениями (проводимыми под контролем соответствующего процесса) и рутинной работой по администрированию. Вкратце ответ Скептика звучит так: "Записи об изменениях содержат информацию о том, что что-то было изменено. Если вам важно знать, когда что-то изменяется — регистрируйте такие действия. Любая задача по администрированию, по которой должна быть обеспечена возможность последующего аудита проведенных модификаций, должна управляться как изменение." Аргументы и подробности — в блоге Скептика

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM