Управление преобразованиями и изменениями — советы бывалого

Уже давно стало понятным, что IT департамент организации является источником изменений – внедрение новых систем и/или процессов, замена старых информационных систем на новые, etc. Тема изменений не нова, горячо обсуждаема и актуальна. Всегда. И всегда есть чему поучиться у самих же себя после проведения каждого изменения, ибо каждое – уникально.

Scott Harberd (Interim senior project and programme manager) делится в блоге на портале Axelos своим опытом (lessons learned – термин, принятый в методологиях по управлению проектной деятельностью) внедрения информационной системы по управлению портфелем проектов в крупной британской компании.

Несмотря на то, что компания входит в FTSE 100 (Financial Times Stock Exchange Index- ведущий индекс Британской фондовой биржи) и является внешне успешной, внутри очевидна незрелость с точки зрения систем и процессов.

Большое количество рабочих групп, работающих в настолько же большом количестве систем, нет понимания какая из них главная (вспоминается термин «градообразующее предприятие»). Поэтому при решении оперативных вопросов за неимением актуальной информации, пришлось опираться даже не на факты, а в большей степени на ощущения. «Далеко от идеальной картинки компании-члена FTSE 100», — сетует автор.

Целью было – внедрить «единственную версию правды»: централизованную систему для сбора и анализа информации, необходимой для принятия выверенных управленческих решений, эффективного планирования и управления ресурсами. Так чему же удалось научиться в результате нелегкого, но успешного внедрения?

Извлеченные уроки:

  • очень важно в самом начале поработать со стейкхолдерами на предмет выявления уровня зрелости организации. Очень хочется буквально с первых дней проекта начать делать грандиозные дела, большими шагами. Но в реальности попытка перевести людей на новую информационную систему в сжатые сроки может просто провалиться. Маленькими шагами, стимулируя продвижение к цели, управляя рисками – гораздо результативнее.
  • при определении модели лицензирования продукта, закладывайтесь на долгосрочную перспективу использования информационной системы, а не на задачи только вашего проекта (который когда-то закончится).
  • используйте инструменты управления изменениями и организационными изменениями. Внедрение даже самой простой-удобной-эффективной информационной системы не гарантирует получения результатов, если эту систему не примут люди.
  • работайте с людьми: определите функциональные группы, профессиональные и «не» сообщества со стороны заказчика и информируйте, вовлекайте, поддерживайте каждую.
  • убедитесь в том, что обучение пользователей будет проводиться на данных, максимально приближенных к продуктивным. Это даст свои плоды на этапах опытно-промышленной и продуктивной эксплуатации.
  • оцените влияние внедрения системы на бизнес-процессы. Этим тоже лучше управлять своевременно
  • большинство изменений – это результат действий как ИТ, так и бизнеса, — привлекайте и тех и других. Назначьте агентов изменений, которые будут обеспечивать своевременное информирование, вовлечение, обучение всех групп, которых затрагивает изменение. Это даст свои результаты в виде доверия и принятия, а в будущем – результатов.

 

 

 

 

 

 

 

 

 

 

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

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

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

  1. Nargiza Suleymanova

    Мне кажется, или все эти пункты (а так же другие не менее важные) замечательно описаны в книге ITIL Practitioner Guidance? 😉 Я не к тому, что оспариваю авторство, а к тому, что мысли-то и боли у всех похожи.

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

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

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

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

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20