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

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

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

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

Записки с полей:Типовые заявки

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

Вопрос из зала: процедура актуализации типовых изменений

Евгений спрашивает: Добрый день! Помогите, пожалуйста, в вопросе написания процедуры. Новичок в ISO, но по ряду рабочих обязательств, возложенных на меня, мне нужно разработать процедуру актуализации списка типовых изменений. Помогите, в каком направлении излагать мысли? Может, есть какие-то наработки, статьи, темы, размышления и т.д. Есть ли у кого-нибудь советы и рекомендации по составлению такой процедуры? Какой информации не хватает для полноценного ответа на поставленный практический вопрос?

Догонять и причинять добро: как убедить людей работать в новых процессах

У гостей и участников 10-го Russian IT Management Forum (ITMF-2013), который пройдет в Москве 6 июня 2013 года, есть редкая возможность принять участие в интерактивном тренинге, основанном на реальном кейсе. Тренинг пройдет в формате деловой игры, демонстрирующей трудности принятия в компании процесса управления ИТ-изменениями. Наш проектный и тренинговый опыт за последние девять лет показывает, что описанный в кейсе сценарий весьма распространен и актуален для многих организаций. Это касается и непосредственно процесса управления изменениями, и в целом проектов по организации процессов ITSM. Так, согласно статистике компании Pink Elephant, 82% ITSM-проектов, впервые инициирующих в организации процессы управления ИТ-услугами,  терпит неудачу. И основная…

Наконец-то: новые экзамены ITIL 2011 на русском языке

Долгожданные новости поступают из компании APMG, официального (на текущий момент) распорядителя экзаменационной линейки ITIL.  В конце апреля все экзаменационные институты получили извещение о готовности перевода ряда экзаменов на различные мировые языки. В частности, говорится в нем о русифицированных ITIL Intermediate RCV и OSA. 28 мая 2013 года будут опубликованы пробные, а еще чуть позже экзаменационным институтам предложено продавать настоящие экзамены на нашем родном языке. Сроки локализации остальных экзаменов ITIL пока не разглашаются. Мы будем держать вас в курсе развития событий и с удовольствием поможем подготовиться к экзаменам на литературном русском языке.

Больше Bok’ов, хороших и разных

APMG и Change Management Instutute (а есть и такой) объявили о начале работ по созданию универсального свода знаний по управлению изменениями – CMI Change Management Body of knowledge, CMBok.  Опросы, проведенные среди членов CMI показали, что большинство из них считают необходимой разработку универсального свода знаний по управлянию изменениями, поддержанного системой профессиональной сертификации, что, конечно, поспособствует развитию профессии менеджеров изменений и принесет много пользы, особенно на быстро развивающихся рынках вроде Китая.  Новая сертификация будет называться AACM (Accredited Associate Change Manager) и дополнит уже существующую ACM (то же, но без Associate). Требования к кандидатам и экзамены будет разрабатывать APMG, "чей богатый опыт…

Групповая безответственность

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

Они такие похожие… и всё-таки они врозь?

Тема объединения/разделения процессов управления изменениями и релизами продолжает оставаться предметом споров и публикаций. Запущенный несколько недель назад на itsmportal.com опрос получил уже более ста ответов, и можно подвести промежуточные итоги. Вопрос задаётся очень простой: Управление изменениями и управление релизами – разные процессы? Голоса распределились так: Да, так учит ITIL – 58% Нет, управление релизами – вид управления изменениями, за который отвечает управление изменениями – 24% Нет, управление релизами – это функция, а управление изменениями – процесс – 16% А? Что такое управление релизами? – 2% Любопытно, какая часть респондентов из первых 58% трактовала первый вариант как "Да, потому что так…

Измерение процессов. Доля срочных изменений

Всем известно, что срочные изменения – это зло, с которым необходимо бороться, но невозможно победить до конца. В связи с этим возникает интересный вопрос: если до конца не победить, то сколько процентов срочных изменений является приемлемым уровнем? Для начала разберемся, что такое срочные изменения. В ITIL v2 срочным считалось любое изменение, которое необходимо выполнить так быстро, что часть стандартных активностей процесса управления изменениями для них приходится либо пропускать, либо выполнять в сокращенном варианте, либо выполнять «задним числом». Например, пропускаем тестирование в тестовой среде (тестируем на продуктиве), согласуем по сокращенному варианту, оформляем в системе автоматизации задним числом. При этом на причину…

Антирейтинг высказываний на Change Advisory Board

Новозеландский специалист по управлению ИТ-услугами Райан Огилви опубликовал свой личный  рейтинг самых вредных фраз для процесса управления изменениями.  Примерно раз в неделю, группа уполномоченных сотрудников собирается, чтобы рассмотреть, оценить и приоритизировать грядущие изменения в инфраструктуре. Во многих организациях такая группа называется Change Advisory Board (CAB) – совет по изменениям. Вот слова, которые я часто слышу на подобных встречах в моей компании. «Это изменение на 30 секунд». Даже за полминуты можно успеть сломать приложение. «На пользователей не повлияет». Даже если изменение проводится в «нерабочее время», не забудьте про план коммуникаций. «Это минимальное изменение в интерфейсе приложения». Обычно за этими словами кроется…

Почему случаются инциденты

Один из авторов ITSMPortal, Robert S. Falkowitz, провел интернет-опрос о причинах инцидентов. Как объясняет Роберт, таким образом он хотел проверить увиденное в одной из публикаций утверждение, что "80% инцидентов являются следствием проводимых изменений".  В обзоре результатов опроса Роберт отмечает, что собранные им данные так же недостоверны, как любые другие результаты подобных опросов: Выборка участников нерепрезентативна и невелика Как ни старался автор сделать вопросы максимально простыми, нашлись те, кто их не понял или понял неверно Знания, на которых участники основывают свои ответы, могут быть неверны; при этом сами участники склонны переоценивать свою практику и качество доступной им информации Тем не менее, опрос проведен…

Одинокий процесс управления изменениями

В своей первой в новом году колонке на itsmportal.com, голландский эксперт Ян ван Бон рассказал о недавней дискуссии на тему связи процессов управления релизами и изменениями. Он резюмировал свою позицию так: Многие справедливо считают, что релиз и изменение различаются. Это правда: релиз – это набор изменений. Поэтому планирование релизов более сложное и требует повышенного внимания. В остальном, релизы и изменения очень похожи: утверждение, планирование, построение, тестирование, проверка готовности, внедрение, оценка и т.д. Некоторые еще полагают, что планирование релизов должно быть отделено от планирования изменений. Мне кажется, что здесь могут возникнуть сложности: размывается главная цель управления изменениями: предотвращение негативного влияния одного…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM