В редакцию портала поступил вопрос:
Как мотивировать сотрудников фиксировать свои изменения в рамках процесса Change Management?
Периодически выявляются случаи проведения изменений в ИТ-инфраструктуре, проведенных за рамками соотвествующего процесса. При этом сотрудники в свое оправдание дают пояснение вида: не оформил RFC потому, что – это тестовая среда/ это по SR от заказчика/ работы в рамках стандартного функционала услуги/ конфигурация самой системы не затрагивается и т.д.
Традиционные доводы (почему необходмо фиксировать изменение) в стиле "повышается прослеживаемость цепочки событий при решении инцидентов/ поиска причин проблем", или "повышается качество планирования работ, формирование ожиданий потребителей ИТ-услуг", "проводить изменения с минимальным негативным воздейстием на ИТ-услуги" — работают скорее для ИТ-руководителей или процессных менеджеров, нежели для простых ИТ-специалистов, которые выполняют работы "в поле".
Как сформулировать наиболее доходчиво именно простому админу, зачем ему необходимо заниматься лишней бюрократией (оформлять RFC, дорабатывать план, согласовывать с CAB, etc…) ?
Просьба к колегам поделиться опытом, вариант кнута не предлагать) а если пряника, то просьба поподробнее))
Спасибо!
Добрый день!
Попробую поделиться своим мнением.
История довольно распространённая. Более того – оправданная самой жизнью. Но лишь частично. Если кратко – надо задуматься над охватом процесса управления изменениями и спецификой проведения изменений по разным направлениям внутри ИТ.
Проблема заключается в том, что пытаясь всех загнать в рамки единых правил проведения изменений, Вы часть людей обрекаете на выполнение действий, которые им не просто непонятны, а видятся совершенно излишними и мешающими повседневной работе. А при наличии относительно сложной ИТ-инфраструктуры у администраторов различных её компонентов повседневной работы хватает. При этом работа их имеет ряд специфических особенностей по сравнению с разработчиками прикладных систем. В том числе в части проведения изменений.
По большому счёту, довольно много задач, которые выполняют администраторы, можно отнести к изменениям. Однако выполняются эти задачи в отношении разных компонентов ИТ-инфраструктуры, не все из которых реально влияют на функционирование бизнес-процессов. Чтобы не заставлять людей заниматься бесполезной работой, важно правильно определить охват процесса управления изменениями. То есть чётко зафиксировать, в каких случаях и по каким компонентам ИТ-инфраструктуры надо регистрировать изменения. И не мыслить при этом категориями компонентов, а выделить компоненты ключевые, несогласованные изменения в которых могут повлечь за собой прерывание работы информационных систем и/или нарушение функционирования бизнес-процессов. В идеале информация о таких компонентах должна присутствовать в CMDB, а исполнитель должен перед началом работ сверяться с карточкой конфигурационной единицы на предмет необходимости регистрации изменения. Согласитесь, это уже несколько комфортнее для исполнителя, чем пытаться следовать непонятному для него правилу "регистрируй всё подряд".
Теперь давайте обратимся к приведённым Вами оправданиям ваших администраторов.
Если состояние каких-то конкретных тестовых сред является для вас критичным фактором – напишите об этом в CMDB. Далеко не факт, что у вас необходимость учитывать изменения всех тестовых сред.
Необходимо постараться максимально чётко разграничить запросы на обслуживание и запросы на изменение. Перечень запросов на обслуживание должен быть максимально конкретизирован. При этом важно от исполнителей (руководителей рабочих групп) получить вводную информацию для формирования этого перечня. То есть привлечь их к выделению стандартных изменений, что им же упростит работу.
Опять же, если для компонента в CMDB установлена необходимость в регистрации изменений, надо регистрировать. И оповещать ответственных за системы, которые зависят от данного компонента. Затрагивается или не затрагивается конфигурация – будут разбираться, как раз, эти ответственные. Важно их оповестить. Пожалуй, это самое важное, что нужно от подразделения ИТ-инфраструктуры – информация! Информация о том, что они собираются сделать какое-то изменение. И здесь важно не пытаться требовать "всё", а постараться конкретизировать критерии, по которым администраторы будут определять необходимость в регистрации изменения. Как я уже писал выше, дать им в руки инструмент – CMDB, в которой есть нужная информация.
Теперь про "лишнюю бюрократию". Из Вашего описания у меня сложилось ощущение, что она действительно лишняя в некоторых случаях. В частности, относительно CAB. Нужно чётко прописать, в каких случаях он нужен, в каких – нет. По своему опыту скажу, что CAB по изменениям в ИТ-инфраструктуре зачастую не требуется, если речь не идёт о каких-то комплексных изменениях, затрагивающих информационные системы. И в таком случае он будет проводиться в рамках комплексного изменения. А инфраструктурные изменения будут частью цепочки. Это только один из примеров. Вообще хорошей практикой является выделение моделей (шаблонов) изменений, в том числе по ИТ-инфраструктуре. Модели изменений позволяют выстроить гибкий процесс, учитывающий специфику направлений, в частности, направления ИТ-инфраструктуры. Если привлечь сотрудников данного направления к разработке моделей, синхронизироваться с направлениями по информационным системам в части выделения критичных компонентов, зафиксировать эти компоненты в CMDB – люди будут лучше понимать, зачем и когда регистрировать изменения. Ведь они сами выберут и договорятся, что регистрируем, а что – нет. А также о том, как проводить те или иные изменения, через какие этапы они проходят и так далее. В данном случае пряник заключается в том, что людям не пытаются что-то навязать. Они сами определяют важные аспекты своей работы. Ну, или почти сами. Здесь важно всем заинтересованным сторонам договориться между собой.
Про модели изменений можно почитать на нашем сайте.