Метка: Change management

Управление портфелем ИТ проектов

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

Вебинар: ИТ-архитектура и управление изменениями

Друзья! Осень еще не скоро, но серия осенних вебинаров уже начинается. Приглашаю вас 15 августа в 20:00 MSK на бесплатный вебинар: «ИТ-архитектура и управление изменениями. Обновление процесса CHG». За предыдущие годы в ИТ-процессах изменилось очень многое. В разработке появились не только гибкие методологии, но и обрели реальное воплощение инструменты непрерывной интеграции и поставки (CI/CD). В инфраструктуре и операциях (I&O) вряд ли кто-то еще не слышал про devops. Проектные подходы уступают свое место продуктовым и вносят в мир ИТ Design Thinking, Lean Startup и прочие неведомые ранее термины. Lean IT и Kanban – тоже с нами. И кажется только в процессе управления изменениями ничего не меняется. Запросы на изменения (Request for change), Change Advisory Board (CAB), CMDB и прочая архаика сохраняет свои позиции (у тех, кто отстроил эти процессы, разумеется). На самом деле это не совсем так и change тоже меняется. Приведу несколько ссылок на эту тему:

Книга Роба Ингланда Plus! The Standard+Case Approach: See service response in a new light 2013 года, подборка материалов The Standard+Case approach to response management  и последующая серия публикаций в блоге, например одна из последних: Change goes away.Статья Joanne Molesky в блоге Axelos Is it time to change Change Management? и многие другие подобные обсуждения.

Ну а главный вопрос предстоящего вебинара: можно ли поменять что-либо в корпоративных ИТ, не поменяв CHG. Можно полностью поменять методологию разработки, автоматизировать сборку, тестирование, развертывание и даже обработку событий мониторинга, заменить написание требований рисованием customer journey map. Но будет ли от этого хоть какой-то толк, если рамка процесса управления изменениями останется прежней?

Своей точкой зрения я поделюсь на предстоящем вебинаре. Регистрация: https://mxsmirnov.timepad.ru/event/543835/

 

PS: И не забывайте регистрироваться на вебинар 9 августа BIAN (Banking Industry Architecture Network) – Обзор методов и принципов проектирования который проведет Роман Дынник

Стратегия развития корпоративных информационных систем (2)

strategyТема Стратегия развития корпоративных информационных систем вызвала довольно много откликов на FB, поэтому еще несколько соображений относительно pace layer model. Первое относится к тому, могут ли приложения переезжать из одного слоя в другой.  На этот вопрос дается четкий ответ в работе How to Differentiate Governance and Change Management in Your Pace-Layered Application Strategy (19 September 2012 ID:G00237513). Организации должны регулярно пересматривать свой портфель приложений и при необходимости корректировать классификацию той или иной системы. Читать далее Стратегия развития корпоративных информационных систем (2)

Стратегия развития корпоративных информационных систем

paraЗабавные вещи пишут ребята из Gartner относительно стратегии развития приложений. Называется это pace layer model. Если говорить в двух словах, то смысл модели следующий. Организации необходимо иметь три типа бизнес-приложений: system of records, system of differentiation, system of innovation. На мой взгляд, названия не очень удачные. Но дело, разумеется, не в словах, а в подходе, который стоит за этими названиями. Читать далее Стратегия развития корпоративных информационных систем

Управление изменениями. Standard+Case approach

SplusCНа прошлой неделе увидела свет новая книжка ИТ-скептика Роба Ингланда(Rob England) Plus! The Standard+Case Approach Конечно же я не смог удержаться от приобретения kindle версии данной книги. В своей книге Роб сделал довольно простую и в то же время очень важную вещь, объединил два подхода управления бизнес-процессом заказа и предоставления услуг. Стандартный подход, описанный в многочисленных книжках по ITIL и ITSM и навевающий скуку на большинство пользователей ИТ-услуг и адаптивный кейс-менеджмент, используемый в проектах и другой человеко-ориентированной деятельности. Читать далее Управление изменениями. Standard+Case approach

Gartner: Projects Today, “Change Operations” Tomorrow

За пару дней до Нового года Андрей Коптелов поделился ссылкой на июльскую статью Владимира Иванова Доклад Gartner: Будьте готовы к будущему управления портфелями и программами проектов Я решил разобраться более подробно в том, что предрекает Gartner проектному менеджменту и кроме презентации Be Prepared For the Future of Program and Portfolio Management посмотрел их более ранние работы:

Не стану пересказывать статью Владимира Иванова. Позволю себе лишь несколько акцентов. Итак, аналитики предсказывают, что организации на треть сократят сроки и стоимость реализуемых проектов (Думаю, в наших условиях речь может идти о 50% и больше). Это приведет к серьезному давлению, как на проектные офисы, так и на средства их автоматизации. Системы управления проектами и портфелями проектов мне никогда не нравились, так что туда им и дорога. Впрочем, проектные офисы, в отличии от «боевых» проектных менеджеров, тоже приносили проблем больше чем результатов. Одним словом, предсказания аналитиков вполне созвучны и моим рассуждениям:

Резонный вопрос: как организовать Getting Things Done в условиях такого давления. Как справедливо замечают аналитики Gartner, проекты бывают разными. Значительная часть активностей, осуществляемых организациями, заключается в улучшениях уже существующих продуктов. Вести их в формате традиционных проектов, как-то совсем неразумно. Кстати, в ИТ уже давно существуют процессы управления проблемами и управления изменениями. Вопрос в том, насколько широко трактовать эти процессы. Например, замена устаревшей ИТ системы на новую, казалось бы, типичный пример ИТ проекта. В действительности, эта активность намного ближе к управлению проблемой (недостаточная масштабируемость или функциональность системы). Возможно, качественное решение проблем освободит нас от необходимости инициировать новый проект и внедрять новую ИТ систему. Это как раз то, о чем я собираюсь рассказывать в теме Интеграция новых приложений в корпоративный ИТ-ландшафт

Релизы и версии

Как и во многих крупных компаниях, наш корпоративный ИТ ландшафт состоит из информационных систем, таких как система управления отношениями с клиентами (CRM), система самообслуживания, биллинговая система и т.д. Всего их в CMDB насчитывается несколько сотен. Каждая система включает в себя несколько программных компонент. Это и базы данных и JEE приложения, толстые клиенты и web-интерфейсы. До пришествия виртуализации каждая система развертывались на своем наборе оборудования. Впрочем, и сейчас основные системы развернуты на закупленных специально для них серверах.

Не удивительно, что ИТ система является основным элементом управления. К ИТ системам привязываются запросы на изменения (Request for Change, RFC). Системы являются основной единицей процесса управления релизами. Т.е. для каждой системы развивается своя ветка релизов. Все планирование, разработка, тестирование и развертывание ведется в границах систем. Версии приложений попросту совпадают с релизами. Мы не уникальны. Многие компании развивают свою ИТ-инфраструктуру примерно так же. Но в какой-то момент это становится проблемой. Сначала проблемой ИТ архитектуры, а вскоре и проблемой всего ИТ.

На днях листая перед сном ITIL я пытался найти ответ на вопрос почему релиз может включать в себя только одну ИТ систему. Честно говоря, в явном виде такой рекомендации я не нашел. В чем недостатки привязки релиза к одной конкретной ИТ системе? Все очень просто. Традиционный цикл выпуска программного обеспечения ограничивается фазами анализ->проектирование->разработка->тестирование->развертывание. Однако в большинстве современных компаний изменения в ИТ носят комплексный характер, затрагивают сразу несколько систем (см. примечание). Такие работы, как согласование интерфейсов, интеграционное тестирование, конфигурирование приложения (это когда вместо абстрактных интерфейсов, администраторы прописывают реальные ip-адреса web-сервисов и connection strings баз данных), пользовательское тестирование (UAT), разработка архитектуры, в конечном счете =) и управления конфигурациями – остаются за бортом процесса.

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

Примечание: Опрос Как интегрируют приложения в России, приведенный в блоге Андрея Коптелова, показывает что всего треть отечественных компаний никак не интегрируют свои приложения. Остальные – тем или иным способом решают задачу интеграции приложений

Еще несколько слов про CHG

Перечитал своё вчерашнее сообщение. Наверное, не очень понятно, почему я пишу о JIRA в контексте управления изменениями (change management). Всё очень просто: у кого чего болит… У меня сейчас болит это самое управление изменениями.

Читать далее Еще несколько слов про CHG