Но так было не всегда. Вплоть до октября 2015г. обстановка с чейнджами больше походила на хаос. Потом появился ITSM, который навёл порядок со всеми неавторизованными чейнджами. Появилась структура, позволившая измерить неизмеримое.
Основная цель управления изменениями (Change Management) — свести к минимуму проблемы, возникающие при неудачных изменениях и приводящие к сбоям в предоставлении услуг. Мы следим за планированием ИТ изменений, их согласованием и подтверждением, доскональным тестированием всех шагов до того, как изменения окажут влияние на пользователей.
Менеджер по контролю за изменениями (Change Manager) следит за реализацией процесса управления жизненным циклом всех ИТ изменений. В Mars IS — четыре таких специалиста. За месяц они обрабатывают более тысячи изменений. Менеджер контролирует весь процесс внедрения, и в случае негативного воздействия изменение откатывается по заранее подготовленному его инициатором плану.
В Mars IS используются три типа изменений:
— стандартные с низком риском и рутинными операциями;
— экстренные для недопущения или разрешения критических инцидентов;
— нормальные, которые планируются заранее.
Каждую неделю мы проводим Общий совет по изменениям (Global CAB), где обсуждаются важные и имеющие повышенный риск изменения, требующие отключения систем и согласования с бизнесом.
Совет утверждает новые темплейты стандартных изменений, рассматривает изменения, вызвавшие обычные и критические инциденты, неудачные изменения, результаты разбора изменений в рабочих группах (Post Change Review), а также делает обзор на следующие две недели, чтобы идентифицировать потенциальные конфликты и наметить план действий по их разрешению.
В компании используется определенный набор индикаторов (KPIs), позволяющий измерить успешность процесса управления изменениями как по каждому региону и команде, так и в целом в Mars IS. Мы измеряем успешность внедрения изменений (Successful Change Rate), количество «брошенных» изменений, за которыми никто не следит (Abandoned Change Backlog), качество заполнения формы на изменение (Change Initial Ticket Quality) и количество процедур, вызвавших инциденты, и критические инциденты (Changes Causing Incidents/Major Incidents).
Как это работает
Change Manager проверяет изменения с точки зрения доступности и ясности всей представленной по ним информации: причина, ответственные за планирование, тестирование и выполнение, риски и конечный результат, план проведения, задействованные ресурсы и т.д.
Если необходимая информация отсутствует, менеджер, обосновывая, отклоняет изменение, которое затем поступает вновь с соответствующими дополнениями. Чем больше таких отклонений, тем ниже метрика по качеству изменений.
Наша задача – поддерживать качество на высоком уровне, поэтому мы регулярно проводим тренинги по управлению изменениями. В этом году было проведено 12 тренингов, в которых приняли участие 200 человек. Также у нас есть библиотека электронного обучения. В этом году мы подготовили 25 видео-уроков по процедурам управления изменениями в форме диалога контролирующего менеджера с владельцем изменений. Ежемесячно проводится аудит изменений и тренинг для топ-10 их владельцев изменений с ненадлежащим качеством.
Все изменения должны быть зарегистрированы в системе ServiceNow и вовремя одобрены. Иначе они становятся неавторизованными и могут привести к инцидентам. Неавторизованные изменения запрещены, поэтому они отслеживаются, документируются и подробно разбираются на рабочих группах (Post Change Review).
Мы проводим Post Change Review и с неудачными изменениями, к которым может привести нечеткое планирование, отсутствие необходимых договоренностей, недостаток тестирования или человеческий фактор. Поводом для разбора на рабочей группе может стать и успешно внедренное изменение, если оно стало причиной инцидента. Особое внимание мы уделяем срочным незапланированным изменениям. Например, если нужно срочно устранить сбой, вызванный критическим инцидентом.
Немного статистики
Мы постоянно улучшаем и совершенствуем наши процессы управления изменениями. Несмотря на то, что Change Management работает на платформе ServiceNow всего чуть больше двух лет, нам есть чем гордиться. Например, в конце прошлого года, в период новогоднего ограничения на изменения (Change Stability Period), когда были разрешены только срочные изменения, мы провели их больше 1500, и ни одно из них не вызвало инцидентов.
В 2017 году прошло около 12 тысяч изменений, проведено 200 Post Change Reviews. С октября 2017 года мы поддерживаем изменения в Royal Canin, а это дополнительно около 300 изменений в месяц.
Итоги и планы
Одним из явных плюсов процесса Change management является сокращение потерь, увеличение стабильности работы организации и самое главное уменьшение количества аутеджей (outage). В наших планах работа по улучшению базы данных управления конфигурации (Configuration Management Data Base), более тесное сотрудничество с Incident Management и Problem Management, а так же новые проекты по оптимизации управлением изменениями.
Комментарии (9)
achekalin
18.09.2018 14:54Так с места в карьер написано, будто бы все читатели знают, что такое Mars. Или работают в Mars.
fetisnik
21.09.2018 11:28Чуть больше о нас можно узнать в одной из наших первых публикаций: habr.com/company/marsis/blog/338886
mSnus
19.09.2018 04:51Простите, а чем, всё-таки, вы сейчас хвалились? 12.000 изменений — это что, например?
baxxter
19.09.2018 09:09Большое спасибо за статью, вы здесь поделились своим опытом, но во что не понятно — как этот опыт может быть полезен другим компаниям? Большинство подобных статей можно подвести под общий заголовок «как мы в большой компании Х внедрили процесс Y». Т.е. я говорю о том что в компаниях, которые созрели для процесса Y, он скорее всего уже внедряется по своему уникальному сценарию, а в компаниях которые не созрели для этого — он не нужен и может даже мешать бизнесу.
Hardened
19.09.2018 09:59Пересказ ITSM скучен для тех, кто с ним знаком, и непонятен для остальных. А вот ошибки случаются чтобы на них учится. Расскажите про несколько epic fails года, как процесс помог сделать их менее epic, чем было бы без него, и какие процесные или организационные изменения внесли с учётом полученного опыта.
Tell the Story. Pure theory and stats are boring.
whiplash
19.09.2018 16:49Цифры это ерунда.
Как вы решили проблему «мистера Брента» (см. книгу «Проект Феникс»)?
alexsibtone
Вот тяжело, реально. Супер технологии, масштабное описание. А вот берешь трубку и боишься (я про поддержку) — что на том конце будет бразильянка на своем английском с тобой говорить. Знание языка тут не поможет — выручает конечно текстовый чат.