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

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

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

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

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

Новостной поток, 5 марта 2018, последний комментарий 8 марта 2018

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

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

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

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

Новостной поток, 6 декабря 2017, последний комментарий 11 декабря 2017

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

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

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

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

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

Андрей Труфанов, 30 октября 2017, последний комментарий 9 ноября 2017

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

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

Артём Мукосеев, 1 сентября 2017, последний комментарий 6 сентября 2017

Ресурсно-сервисные модели (РСМ). Упражнение.

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

Андрей Труфанов, 31 августа 2017, последний комментарий 9 января 2019

Как мотивировать сотрудников фиксировать свои изменения

В редакцию портала поступил вопрос: Как мотивировать сотрудников фиксировать свои изменения в рамках процесса Change Management? Периодически выявляются случаи проведения изменений в ИТ-инфраструктуре, проведенных за рамками соотвествующего процесса. При этом сотрудники в свое оправдание дают пояснение вида: не оформил RFC потому, что – это тестовая среда/ это по SR от заказчика/ работы в рамках стандартного функционала услуги/ конфигурация самой системы не затрагивается и т.д. Традиционные доводы (почему необходмо фиксировать изменение) в стиле "повышается прослеживаемость цепочки событий при решении инцидентов/ поиска причин проблем", или "повышается качество планирования работ, формирование ожиданий потребителей ИТ-услуг", "проводить изменения с минимальным негативным воздейстием на ИТ-услуги" — работают скорее для ИТ-руководителей или процессных менеджеров, нежели для…

Вопрос из зала, 8 августа 2017, последний комментарий 5 октября 2017

Адаптивные модели изменений

"Жизнь многообразна, бумага не бесконечна!" )) "Ну хорошо, а сколько их нужно сделать?" Этот весьма насущный вопрос возникает, когда начинаешь проектировать модели изменений. Мы уже делились на нашем портале разными мыслями по поводу моделей изменений. Например, здесь и здесь. А здесь даже лежит вебинар по данной теме. Но если мы говорим, что модели позволяют учесть различную специфику проведения изменений в зависимости от того, как это изменение классифицировано, то каков должен быть масштаб проработки этой специфики? Какова должна быть детализация того самого классификатора? И какие конкретно параметры изменений должна настраивать модель? Как обычно, следует искать рациональный баланс. Чётко прописать всю специфику вплоть до…

Артём Мукосеев, 9 июля 2017, последний комментарий 13 июля 2017

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос: Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть…

Вопрос из зала, 4 июля 2017, последний комментарий 8 июля 2019

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

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

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