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

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

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

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

Актуально о ITSM сегодня

Мы уже знакомили вас с мнениями экспертов о последних тенденциях развития ITSM (раз, два), но чем больше мнений, тем полнее картина. Джон Мелло (John P. Mello Jr.) излагает свою точку зрения на состояние и векторы движения ITSM в своей статье. Основными тенденциями и факторами развития названы рост DevOps, расширение предложений по самообслуживанию и интеграция цифровых технологий. DevOps меняет все По словам Чарльза Бетца (Charles Betz), аналитика Forrester Research, организации, внедряющие DevOps, переживают прорыв в отношении укоренившихся подходов к управлению изменениями. Повышается степень его автоматизации, и больше полномочий в проведении изменений переходит к командам разработчиков. Усовершенствованный процесс управления изменениями предоставляет инструменты…

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

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

Когда начинается ITSM Change Management

Стюарт Рэнс, один из авторов текущей версии библиотеки ITIL, в своей заметке When Should ITSM Change Management Start рассуждает о процессе управления изменениями: «У большинства организаций есть процесс управления изменениями. Обычно он включает такие шаги, которые гарантируют, что изменение не вызовет негативных последствий. Для инициирования процесса управления изменениями регистрируется RFC, и тогда это изменение рассматривается на предмет того что: необходимое тестирование проведено, вопросы безопасности и риски рассмотрены, все регламенты и стандарты взяты в расчет, etc. Процесс управления изменениями также составляет график изменений, чтобы предотвратить конфликты – например, когда для двух разных изменений требуются одни и те же ресурсы. Одно большое…

Игровая маршрутизация

В деловой игре GRAB@PIZZA, как и в любой бизнес-симуляции, предусмотрены некоторые упрощения и допущения. Оно и понятно, мы же только моделируем реальную рабочую ситуацию, а не пытаемся её детально воссоздать и проанализировать. Попытка полностью воссоздать процесс может привести к существенному усложнению игры. Однако есть один важный нюанс, который, как мне кажется, хорошо было бы ввести в игру. В игре чётко разграничены точки входа “заявок” (назовём их так в целях обобщения) – через процесс управления инцидентами и через процесс управления взаимоотношениями с бизнесом. Всё красиво, каждый должен заниматься своим делом. Первая линия – маршрутизировать или решать/выполнять инциденты и запросы на обслуживание….

Какие запросы на изменение нужно выносить на CAB?

Если ваш ИТ-департамент отправляет каждый запрос на изменение (RFC) в Совет по изменениям (CAB) для утверждения, то вы неправильно управляете изменениями. По моему опыту, есть четыре причины того, что все или большинство RFC отправляются в CAB: Плохо построенный процесс управления изменениями. Не прозрачные бизнес-требования для внесения изменений («что мы должны получить в результате?»). Объем RFC не понятен. В ИТ есть те, кто больше озабочен выполнением предписанных действий, чем хорошей работой. Хорошо продуманный процесс управления изменениями должен облегчить, но не перегружать контролем осуществление изменений. Эффективные процессы управления изменениями устраняют столько разногласий, сколько возможно, гарантируя ясность того, каким образом осуществляются изменения. В…

Управление преобразованиями и изменениями – советы бывалого

Уже давно стало понятным, что IT департамент организации является источником изменений – внедрение новых систем и/или процессов, замена старых информационных систем на новые, etc. Тема изменений не нова, горячо обсуждаема и актуальна. Всегда. И всегда есть чему поучиться у самих же себя после проведения каждого изменения, ибо каждое – уникально. Scott Harberd (Interim senior project and programme manager) делится в блоге на портале Axelos своим опытом (lessons learned – термин, принятый в методологиях по управлению проектной деятельностью) внедрения информационной системы по управлению портфелем проектов в крупной британской компании. Несмотря на то, что компания входит в FTSE 100 (Financial Times Stock…

Планирование отката релиза

Так или иначе, мы все занимаемся изменениями. В такой профессиональной области работы, как информационные технологии, отлично проявляется динамика по разным направлениям. Разработка новых продуктов, добавление мощностей к сервисным активам, установка “заплаток” на пользовательских станциях. Всё это – ежедневные задачи ИТ-подразделений. Их быстрое выполнение необходимо для обеспечения нужд бизнеса. На одном из курсов ITIL RCV(Release, Control and Validation), был затронут интересный и жизненный вопрос. Почему в момент развёртывания релиза при появлении каких-либо проблем никто не знает, что нужно делать, а сама деятельность превращается в беготню?  Вроде бы при проектировании услуги вместе с остальной документацией должен был быть разработан план отката, и…

Цифровая трансформация: основные мотивации и трудности

Международная ассоциация ISACA®, которой многие благодарны за развитие свода знаний COBIT, провела исследование среди профессионалов в области бизнес-технологий. В нем участвовали компании из разных стран мира. В основе исследования – новые технологии, внедрение которых влечет наибольшие организационные трудности из-за возможных рисков и сопротивления изменениям. Ниже представлены некоторые направления исследования. Как видно из диаграммы, первые три пункта про финансы. Вполне ожидаемо, ведь любой бизнес в первую очередь акцентирует внимание на них. В первую пятёрку также входят технологии, провоцирующие большинство организационных трудностей и высокую степень сопротивления изменениям, по данным ISACA®. Генеральный директор ISACA® Мэтт Лойб, предоставил комментарий касательно текущей ситуации. “Результаты нашего исследования показали,…

Плановый простой в контексте SLA

Интересно наблюдать, как под воздействием накопленного опыта развиваются интересы и трансформируются приоритеты коллег, с кем выпадает удовольствие работать и не меньшее удовольствие обмениваться опытом в рамках курсов обучения, периодически проходящих у нас в Cleverics. Недавно вышло так, что близкие по содержанию вопросы поднимались слушателями курса “Управление изменениями и релизами ИТ-услуг” (ITIL RCV) и коллегами по проекту. Вопросы касались планирования простоев услуг, необходимых для внедрения изменений. Один из вопросов был следующий: нужно ли, согласно хорошим практиками, учитывать внеплановые простои, во время которых внедрялись изменения, трактуемые бизнесом как “безотлагательные”, в отчётности? Отвечу в соответствии со своим пониманием. Если коротко – в отчётность нужно…

Довожу до сведения

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

Вам срочно или экстренно?

Срочно, безотлагательно, экстренно… Все эти синонимы с точки зрения англо-русских словарей могут быть использованы для перевода слова “emergency”, которое в ITIL используется для именования особой группы изменений. Изменения этой группы должны внедряться “как можно скорее”. Формулировка, на первый взгляд, несколько размытая и не дающая чётких указаний, в каких конкретно случаях изменение следует обрабатывать в соответствии с некой специальной процедурой. Но в ITIL эта формулировка сопровождается чётким ограничением охвата и соответствующими примерами. В частности, там сказано, что “процедура обработки emergency-изменений должна применяться только для изменений, направленных на устранение ошибок в ИТ-сервисах, которые серьёзно влияют на бизнес”. А в разделе, посвящённом типам…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM