Как мотивировать сотрудников фиксировать свои изменения

В редакцию портала поступил вопрос:

Как мотивировать сотрудников фиксировать свои изменения в рамках процесса Change Management?

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

Традиционные доводы (почему необходмо фиксировать изменение)  в стиле "повышается прослеживаемость цепочки событий при решении инцидентов/ поиска причин проблем", или "повышается качество планирования работ, формирование ожиданий потребителей ИТ-услуг", "проводить изменения с минимальным негативным воздейстием на ИТ-услуги" — работают скорее для ИТ-руководителей или процессных менеджеров, нежели для простых ИТ-специалистов, которые выполняют работы "в поле".

Как сформулировать наиболее доходчиво именно простому админу, зачем ему необходимо заниматься лишней бюрократией (оформлять RFC, дорабатывать план, согласовывать с CAB, etc...) ?

Просьба  к колегам поделиться опытом, вариант кнута не предлагать) а если пряника, то просьба поподробнее))

Спасибо!

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Артем Мукосеев

    Добрый день! 

    Попробую поделиться своим мнением.

    История довольно распространённая. Более того — оправданная самой жизнью. Но лишь частично. Если кратко – надо задуматься над охватом процесса управления изменениями и спецификой проведения изменений по разным направлениям внутри ИТ.

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

    По большому счёту, довольно много задач, которые выполняют администраторы, можно отнести к изменениям. Однако выполняются эти задачи в отношении разных компонентов ИТ-инфраструктуры, не все из которых реально влияют на функционирование бизнес-процессов. Чтобы не заставлять людей заниматься бесполезной работой, важно правильно определить охват процесса управления изменениями. То есть чётко зафиксировать, в каких случаях и по каким компонентам ИТ-инфраструктуры надо регистрировать изменения. И не мыслить при этом категориями компонентов, а выделить компоненты ключевые, несогласованные изменения в которых могут повлечь за собой прерывание работы информационных систем и/или нарушение функционирования бизнес-процессов. В идеале информация о таких компонентах должна присутствовать в CMDB, а исполнитель должен перед началом работ сверяться с карточкой конфигурационной единицы на предмет необходимости регистрации изменения. Согласитесь, это уже несколько комфортнее для исполнителя, чем пытаться следовать непонятному для него правилу "регистрируй всё подряд".

    Теперь давайте обратимся к приведённым Вами оправданиям ваших администраторов.

    "...это тестовая среда"

    Если состояние каких-то конкретных тестовых сред является для вас критичным фактором — напишите об этом в CMDB. Далеко не факт, что у вас необходимость учитывать изменения всех тестовых сред.

    "это по SR от заказчика"

    "работы в рамках стандартного функционала услуги"

    Необходимо постараться максимально чётко разграничить запросы на обслуживание и запросы на изменение. Перечень запросов на обслуживание должен быть максимально конкретизирован. При этом важно от исполнителей (руководителей рабочих групп) получить вводную информацию для формирования этого перечня. То есть привлечь их к выделению стандартных изменений, что им же упростит работу.

    "конфигурация самой системы не затрагивается"

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

    "...заниматься лишней бюрократией"

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

    Про модели изменений можно почитать на нашем сайте.

  2. Андрей Вишняков

    Артем, большое спасибо за развернутый ответ.

     

    видится, что предложение записать в CI необходимость оранизовывать изменение с ним по процессу (или нет) на практике не будет хорошо работать. Сисадмин, как правило, изначально мыслит не в терминах объектов CMDB, а в виде настоящих компонент ИТ-инфраструктуры, ИТ-систем. Зачастую под эти компоненты из реальной жизни не всегла есть четкое соответствие Configuration Item. Ну и как Вы предлагаете, для того, чтобы осознать — подлежит ли работа с данным компонентом оформлению как Change, сотруднику необходимо уже зайти в систему SKMS и начать по сути оформлять изменение. Проблема как раз в том, что люди не мотивируются перед проведением работ заходить в систему.

     

    Если состояние каких-то конкретных тестовых сред является для вас критичным фактором — напишите об этом в CMDB. 

    проблема в том, что до захода в CMDB и прочтения этой информации может дело и не дойти и как результат у нас нет зафиксированного изменения.

    Вы предлагаете мероприятия по упрощению использования процесса, т.е:

    1) зафиксировать (в CMDB) что подпадает под изменение, а что нет 

    есть такое (в регламенте проведения изменений) и описание охватывает далеко не все случаи жизни

    2) проработать модели (шаблоны) изменений для типовых действий

    шаблоны есть, люди ими пользуются 

    3) делегировать авторизацию измененений в зависимости от риска на соответствующий Change Authority

    да, согласование изменений проводится по-разному, CAB, ECAB, только менеджер изменений, сам специалист (для стандартных изменений)

    вобщем все что предагаете, есть 🙂 но проблематика актуальна

    Вот например The IT Skeptic предлагает воздейвтовать на мотивацию простых специалистов при помощи манипулятивных техник 🙂

    http://www.itskeptic.org/itil-change-management-where-line-between-change-a

     

    If any of it DOES apply, then making people look in two places to see all change is clearly laziness, selfishness and arrogance that puts service at risk.

    не заводишь изменение? значит ты лентяй, эгоист и самонадеянный болван )))

    А мне хотелось бы услышать варианты предложений какой пряник то для людей . мотивировать заводить изменения по процессу?  

    увязать с KPI? использовать средства геймификации?

    спасибо за ответ

     

     

    1. Артем Мукосеев

      Андрей, увязать с KPI тоже можно. Только для этого нужно выявлять и фиксировать незарегистрированные изменения.

      Я так понял, ваши админы в принципе отказываются работать с ITSM-системой? То есть речь об одном конкретном подразделении? А что думает на этот счёт руководитель этого подразделения?

      1. Андрей Вишняков

        руководитель этого подразделения предложил менеджеру изменений подготовить предложение/список мер о том, как мотивировать сотрудников использовать Change management

        1. Артем Мукосеев

          Вообще есть ощущение, в том числе у некоторых моих коллег, с которыми мы данную проблему обсудили, что начинать в вашем случае надо с мотивации руководителя инфраструктурного подразделения, а не его подчинённых. От того, как выстроена работа внутри подразделения, зависит поведение его сотрудников. В данном случае складывается впечатление, что руководитель либо поддерживает их «подход к изменениям», либо не является для них авторитетом. В обоих случаях это именно его задача, а не ваша, выстроить работу внутри подразделения. Не думаю, что ситуацию можно кардинально изменить вводом KPI для исполнителей. Тем более, что для тех из них, которые могут здесь пригодиться, не очень просто обеспечить базу для расчёта.

          А вот подход, предложенный выше Сергеем, может очень даже заработать, если руководитель подразделения будет ощущать свою ответственность за работу вверенного ему коллектива. Он должен сам, в первую очередь, показать коллективу, что принимает и поддерживает правила. И будет карать за их невыполнение.

          Итого, основная мысль — мотивируйте руководителя работать над повышением чувства ответственности и командного (в глобальном смысле) духа у исполнителей. Со своей стороны вы можете помочь ему, разбирая с исполнителями ситуации, приведшие к негативным последствиям, объясняя, как они могли эти ситуации предотвратить.

          Также важно обеспечить поддержу от высшего ИТ-руководства, которое должно донести до руководителя подразделения свои ожидания в части организации рабочих процессов.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28