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

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

Так или иначе, мы все занимаемся изменениями. В такой профессиональной области работы, как информационные технологии, отлично проявляется динамика по разным направлениям. Разработка новых продуктов, добавление мощностей к сервисным активам, установка “заплаток” на пользовательских станциях. Всё это – ежедневные задачи ИТ-подразделений. Их быстрое выполнение необходимо для обеспечения нужд бизнеса. На одном из курсов 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

В защиту Роба нашего Ингланда

Провокационный пост от Роба Ингланда (IT Skeptic), посвящённый CAB, заметка о котором недавно была опубликована на нашем портале, и не менее эмоциональный (но весьма рациональный) комментарий моего коллеги по этому поводу побудили меня высказаться немного более развёрнуто, чем предполагает формат комментариев на форуме. Действительно в обсуждении практик DevOps у апологетов, по моему мнению, в некоторых случая наблюдаются проявления, обусловленные слишком упрощённым взглядом на вещи. Вряд ли имеет смысл без оглядки применять рецепт по отказу от CAB в абсолютно любых компаниях. Собственно, примеров классических «enterprise’ов» (крупных, распределённых компаний, с «гетерогенной, территориально распределенной» инфраструктурой, как писал Андрей Труфанов, которые бы поменяли свой…

Игорь Гутник, 26 июня 2017, последний комментарий 5 июля 2017

Оценка эффективности сотрудника ИТ-службы

В редакцию портала поступил вопрос: Уважаемые коллеги! Вопрос следующего свойства: По книге "ITSM. Руководство по измерению" успешно внедряем индикаторы для процессов Inc mng и rf (Service request) mng, выбрали 2 индикатора TPI и TCR, как сбалансированные. Вопрос в следующем: Как однозначно оценить "эффективность сотрудника"? Т.к. если сотрудник 1 решил за месяц 200 обращений — у него TCR 0.78 и TPI 0.80, а второй решил 10 обращений и у него оба индикатора равны 1 (Идеальный). В описании измерений процессов не нашёл информации как сие реализовать, чтоб было честно с точки зрения сотрудника 1. Свой вариант: Ввести "нормирование" количества обращений, выполненых за период, но данный вариант не предусматривает…

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

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

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

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