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

Разрушители легенд: управление конфигурациями невозможно без процесса управления изменениями

Недавний разговор об управлении конфигурациями и изменениями опять напомнил мне извечный вопрос о курице и яйце. А разговор, в сущности, был на тему, правда ли необходимо внедрение управления изменениями для обеспечения актуальности CMDB? Распространённое мнение гласит: «Да, управление изменениями необходимо, иначе мы не сможем отслеживать изменения и, следовательно, CMDB утратит актуальность». Я не согласен. Даже если апеллировать к каноническим текстам (книжкам ITIL), назначение процесса управления конфигурациями – «is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed». В то время,...

Дмитрий Исайченко, 6 октября 2012, последний комментарий 15 октября 2012

Мировая статистика процессов INC, PRB и CHG

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

Новостной поток, 24 июля 2012, последний комментарий 26 июля 2012

Между разработкой и эксплуатацией

Работая с разными компаниями, в последние годы мы несколько раз сталкивались с задачей определения требований к взаимодействию в триаде «проектный офис, разработчики, эксплуатирующие подразделения». Практика в этой области весьма разнообразна. Столкнувшись с этой задачей в очередной раз, решил кратко суммировать накопленный опыт (спасибо нашим заказчикам!). Итак, вот основной набор регламентирующих документов в этой области: Документ, определяющий основные стадии создания новой АС (новой версии АС) или выполнения доработок. Обычно называется «Положение о разработке прикладного ПО» или аналогично. Основное содержание – по каждой стадии определяется состав работ, ответственных, входные и выходные документы. Важный момент – вовлечение эксплуатирующих подразделений в определение требований и...

Дмитрий Исайченко, 16 июля 2012, последний комментарий 23 июля 2012

Управление черными ящиками

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

Роман Журавлёв, 13 июня 2012, последний комментарий 16 июня 2012

Вопрос из зала: разница между изменением и проектом

Постоянный участник дискуссий на нашем портале Александр Пешков спрашивает: Предлагаю обсудить животрепещущий вопрос — разграничение проектов и изменений. Действительно ли это вопрос бюджета, или это вопрос изменения параметров спецификации? Если первое, все понятно — можно установить пороги и разделять. Если второе — тогда проектами становятся только те разработки, которые изменяют пользовательские функции или параметры качества. Здесь нюансы — какие именно параметры и функции? Можно ли считать пользовательскими функции консоли администратора приложения, к примеру? Какая у вас практика, и какие есть плюсы/минусы у этих подходов? Каков процент проектов в общем объеме изменений, в первом и втором случаях?

Вопрос из зала, 20 мая 2012, последний комментарий 23 мая 2012

Управление изменениями и релизами: один или два процесса

Мы-таки провели этот вебинар (давно уже собирались). Вопрос поднимался неоднократно, системного ответа не было. Теперь, как мне кажется, есть: https://cleverics.ru/subject-field/webinars/46-core/webinars-and-video/380. Если есть вопросы – велкам, обсудим. Специально для этого и создал этот пост.

Дмитрий Исайченко, 27 апреля 2012, последний комментарий 28 апреля 2012

Готовые метрики Управления Изменениями от Pink Elephant

Компания Pink Elephant ведёт занимательный проект — сбор статистических данных о реальных значениях процессных метрик. Принять участие в опросе может любая компания, а результаты периодически публикуются в блоге компании. Сегодня появились обновлённые данные по процессу управления изменениями.

Новостной поток, 25 января 2012, последний комментарий 9 февраля 2021

Аналитик Forrester хочет отменить CAB

Глен О'Доннел из Forrester Research пишет в своём блоге: Главный виновник негибкости изменений — это Консультативный комитет по изменениям (CAB). CAB — это анахронизм. На пути к гибким облачным решениям CAB играет роль лежачего полицейского. В CAB часто участвуют жадные до власти эгоцентристы, которые просто хотят контролировать процесс, но не поддерживать интересы заказчика. Вне зависимости состава, участники CAB не имеют понятия и реальных условиях. Мир стал слишком сложен для этого комитета, поэтому суждения участников трудно принять на веру. Даже самые подкованные технари не поспевают за усложнением. А в состав CAB редко включаются именно такие люди, что еще больше удаляет CAB от реальности...

Новостной поток, 13 декабря 2011, последний комментарий 14 декабря 2011

Про новый процесс в ITIL 2011

Старший консультант канадской компании Thought Rock Грехем Фернис опубликовал своё мнение по поводу нового процесса в ITIL 2011 — Координация проектирования (Design coordination). Этот процесс определён в ITIL на фазе проектирования услуг (Service Design) как "отвечающий за координацию всех действий, процессов и ресурсов, необходимых для проектирования услуг. Координация проектирования обеспечивает целостное и эффективное проектирование новых или изменяемых ИТ-услуг, систем управления услугами, архитектур, технологий, процессов и метрик". Путём приоритезации и составления расписаний, процесс координирует ресурсы с целью сбалансировать спрос на них со стороны множества проектов и изменений. На более высоком уровне, Координация Проектирования создаёт политики, регламенты, бюджеты и модели, которые будут использоваться...

Новостной поток, 17 ноября 2011, последний комментарий 18 ноября 2011

Четыре мысли про управление изменениями

Вдогонку прошедшему вебинару хотелось бы поделиться (и обсудить) несколькими мыслями, из опыта внедрения процессов управления изменениями и конфигурациями. Часть из них я озвучивал на вебинаре, но не все успели высказаться. Мысль первая — процесс управления изменениями на начальном этапе может внедряться даже как простой способ обновления CMDB и не более. Т.е. ту часть цели, которая касается снижения негативного влияния изменений можно оставить в стороне на некоторое время. И только после того как удастся добиться стабильной работы процесса в части единообразного проведения изменений, можно будет сосредоточиться и на снижении влияния. К слову сказать, даже просто единообразие отчасти повлияет улучшение ситуации со снижением...

Евгений Шилов, 24 октября 2011, последний комментарий 30 октября 2011

ИТ-скептик про Devops и Agile

Наш друг Роб Ингланд (IT Skeptic) решил опубликовать заметки к своим выступлениям на конференциях в этом году. Первый в очереди — мгновенно ставший популярным в социальных сетях критический очерк о концепции Devops. DevOps (Developers+Operations) — современный свод различных методик, направленных на продуктивную совместную работу разработчиков программного обеспечения и эксплуатационщиков (администраторов) информационных систем. Идея Devops — прямой наследник Agile. Подход предлагает использовать комплекс мер по "разрушению стены между разработчиками и системными администраторами": единые инструменты повсеместной автоматизации, революция культуры взаимодействия, отказ от бюрократических процедур, мелкие и частые изменения продуктивной среды. Скептик выразил крайне консервативное отношение к этой новой идее. Противопоставив ее традиционной системе управления ИТ...

Новостной поток, 31 августа 2011, последний комментарий 25 августа 2015

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

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

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