Управление изменением – это процесс управления предложенными изменениями границ проекта, как определено в фазе требований. Этот процесс гарантирует последовательную обработку и распространение всех заявок на изменения. Главная цель управления изменением – обеспечить определенный процесс, который бы управлял изменениями к требованиям и установил главные принципы для одобрения и расширения предлагаемых изменений. Этот процесс предоставит корпоративным руководителям и участникам проекта своевременную информацию об изменениях к требованиям. Очевидная выгода успешного выполнения управлением изменений будет положительно влиять на окружение и отношения со спонсорскими организациями, служащими и другими заинтересованными сторонами проекта, минимизируя область ползанья и давящих требований.
Установление программы управления изменениями, которая гарантирует последовательную обработку и распространение предлагаемых изменений, очень важно. Вы должны получить поддержку спонсора для процесса управления изменениями. Спонсор должен быть уверен, что его или её проект следует четкому процессу и не выход из границ процесса для включения новых областей (и стоимости). Все требования должны быть утверждены прежде, чем процесс управления изменениями будет внедрен.
Управление изменением определяется как интеграция коммуникаций, обучения, планирования рабочей силы; оценка приблизительной стоимости помощников менеджера, наблюдателей и служащих для эффективного выполнения работы. Эти ключевые элементы раскрываются в следующих параграфах.
Коммуникации. Эффективная, команда должна быть в состоянии оценить эффективность текущей практики деловых отношений, передать особенности выбранного решения о программном обеспечении, нанять группы для автоматизации и изменения практики деловых отношений (заинтересованные стороны) в обмене точной информаций, предоставить полную информацию о проекте, времени разработки и полдвижения, способствовать принятию новых методов работы. Эти способности увеличат вовлечение заинтересованных сторон через хорошие двухсторонние коммуникации. Поскольку усилия по коммуникации очень важны, в дополнение к плану управления изменением должен быть разработан план коммуникаций, которые детально описывает усилия, которые будут предприняты для вовлечения заинтересованных сторон.
Обучение. Успех любой реализации зависит от наличия хорошо тренированных конечных пользователей, которым комфортно с их знаниями и навыками в использовании SEP и управлении разработанным. Хорошее обучение способствует принятию новых методов работы, эффективности обработки и сбора данных. Обучение включает, но не ограничивается обучением в классной комнате, обучение по месту работы, создание и использование руководств пользователя и обновление руководства компании.
Планирование Рабочей силы. Изменения в практике деловых отношений, введении новых компьютерных систем и программного обеспечения, которое может потребовать новых навыков работы, могут затронуть естественную работу над новым проектом. Команда управления изменением (CMT) обычно состоит из группы трёх или четырёх человек, в обязанности которых входит определять изменения в рабочей нагрузке и рабочей силе, планируя результат. Работая с управлением, CMT облегчит обзор влияния, которое может сказаться на навыках служащего и назначить обязанности для создания плана возможных изменений рабочей силы.
Оценка. Чтобы оценить успех, CMT должен использовать несколько методов оценки. На постоянной основе усилия CMT должны оцениваться для измерения успеха, основанного на установленных параметрах качества работы и важных факторах успеха. Эти критерии качества работы и важные факторы успеха коррелируются с другими частями проекта. Главный фактор успеха включает принятие работниками лучших методов использования системы. Обычные методы для оценки и измерения будут вообще включать стратегически запланированные обзоры, анкетные опросы, интервью с персоналом, и другие действия для обратной связи от людей, которые были затронуты изменениями системы.
Для любого процесса управления изменением самым большим риском является отказ учесть главные аспекты управления изменением. Плохое использование коммуникаций, обучения, и планирования рабочей силы приводят к неудовлетворительному принятию деловых изменений и плохой работы на уровне конечного пользователя. В некоторых случаях, отказ предусмотреть адекватное управление изменением, повлекло в результате потерю миллионов долларов и неудавшемся или отсроченном выполнении. Убедитесь, что команда руководства проектом понимает потребность в существенном усилении управления, и выделила на это необходимые финансовые и человеческие ресурсы.
1.11 Комитет по наблюдения за бизнес требованиями.
BROC сделан для взаимодействия, рассмотрения, одобрения и координации главных проектов, которые затрагивают все части бизнеса корпорации и создание проектных списков, с помощью которых будет осуществляться координация с другими текущими проектами предприятия. SPMO служит помощником для этого взаимодействия. Взаимодействие формируется деловыми лидерами, которые представляют различные сегменты организации. У BROC осуществляет заключительный обзор, одобрение или отказ для всех предложенных проектов. Любые предложенные проекты вообще должны соответствовать следующим критериям:
1. Проект должен быть взаимосвязан с потребностями бизнеса, которые требуют интеграции этого предложения или усилий по его внедрению для выполнения функции проекта.
2. Проект должен положительно влиять на корпоративные системы и пользователей. Продукты или инструменты, используемые для внешних клиентов или для генерирования дохода, обычно выходят за границы применения BROC.
3. Проект должен превысить заданный долларовый предел, которые изменяется в зависимости от размера предприятия. Для средних и больших компаний этот предел составляет 50 000 американских денег. Проект должен обеспечивать определенные бизнес-процессы или функции.
4. Используемые внутренние корпоративные системы, которые находятся на одном уровне, должны быть предложены для процесса рассмотрения приоритетов BROC, если затраты превышают заданные пределы и относятся к:
· Обновление версий приложения (новые релизы/обновления).
· Новые приложения для замены существующих.
· Главные функциональные возможности в существующей системе (системах).
· Настройка стандарта кода приложения.
BROC оставляет за собой право рассматривать и другие изменения системы, но обычно не рассматривает приоритетные исправления ошибок, заплатки или небольшие изменения конфигурации для систем, которые находятся в производстве. Вообще, обычные внутренние процессы поддержки сопровождаются для этих изменений. Главная функция BROC – собрать и рассмотреть новые предложения по проекту.
Все новые заявления по предложениям, которые относятся к вышеупомянутым критериям, должны быть представлены BROC для обзора и одобрения. Проектное представленное предложение должно следовать за основными руководящими принципами методологии SEP и, как минимум, должно включать следующее:
· Бизнес требования высокого уровня
· Предложенные границы проекта
· Предложенный список
· Бюджет сегмента бизнеса для проекта
· Кредитоспособность
BROC рассматривает проект, располагает по приоритетам и одобряет проект. Проекты, представленные для одобрения, рассматриваются для интеграции их функций и функций деловых единиц, определение архитектуры приложения для систем предприятия.
Одобрение проекта состоит в том, что дается приоритет для выполнения. BROC отвечает за определение зависимостей проекта и риска. Это также требует рассматривать и одобрять новые внутренний IT проекты, как сказано в пункте 4 упомянутых выше критериев.
Спонсор BROC – это обычно глава делового подразделения или организации. Он обязан назначить представителя, который уполномочен говорить от имени спонсора на встречах BROC. Этот представитель уполномочен подписывать документы, одобрять предложения, планы и другие, связанные с проектом, документы. Это необходимо для того, чтобы предотвратить постоянные встречи, где посетители обязаны бегать туда-сюда к менеджерам для поиска разрешения сделать следующий шаг. Это препятствует практике, когда используется тактика задержки в пределах предприятия для нечестной борьбы за приоритетность проекта. Другими словами, это гарантирует, что за столом будут представлены одинаково все и уполномочены действовать в интересах бизнеса.
Спонсоры BROC ответственны за:
· Назначения представителя BROC для его сегмента бизнеса
· Обеспечение BROC поддержкой сегмента бизнеса
· Одобрение финансирования проекта без обязательной подписи всех членов BROC
· Решение конфликтов по установлению приоритетов, которые не могут решить члены BROC
Участники BROC ответственны за следующие задачи:
· Представление нового предложения по проекту к BROC для их сегмента бизнеса
· Расположение по приоритетам проектов, которые седеет их сегмент бизнеса
· Готовить и представлять предложения по проекту для рассмотрения в BROC, установление приоритетов и одобрение.
· Объективно рассматривать все предложения по проекту и основывать установление приоритетов на основе равнозначности всех сегментов бизнеса.
У всех участников BROC должен быть уровень директора для власти одобрения. Каждый участник должен быть уполномочен представлять его функциональную область. Это включает в себя такие деловые требования, как понимание потребностей бизнеса, приоритетов, принятие необходимых решений на встречах.
Прежде, чем рассмотреть специфические особенности каждой фазы, важно понять, что где-то в начале 1990х годов, люди начали подвергать сомнениям значение Цикла жизни разработки ПО (SDLC) и породило много обсуждений в частных компаниях и в правительственных секторах о преимуществе подходов SDLC для уменьшения стоимости и риска. Эта революция в мысли привела к появлению Закона о реформе управления информационными технологиями (ITMRA), который известен как Биль Коэна «Cohen Bill» [7].
Формально он называется «Закон о реформе управления информационными технологиями от 1996 года». Этот закон концентрирует своё внимание на процессах управления жизненным циклом в IT и на процессах поддерживающих эту технологию, а не просто на процессах и процедурах, которые обычно получали IT-технологии. Хотя этот закон и применяется главным образом в федеральном развитии и к законтрактованным правительством усилиям, но акт подчеркивает управление IT, как капиталовложением и устанавливает требования по управлению IT-ресурсами, которые включают:
ITMRA также подчеркивает требования, которые были установлены в «Законе о сокращении работы с документами от 1995 года» (PRA) и осуществелнный отделом управления и бюджета США (OMB) в пересмотре к OMB A-130. Эти требования включают:
Этот закон является важным для частного сектора и много достижений мигрирует в частный сектор уже достаточно давно. Эти процессы очень развиты в пределах правительства, поэтому они часто становились основой для идей, публикаций и для людей, которые переходят из государственного сектора в частный. Исторически сложилось так, что большое развитие индустрии ПО следовало в областях, которые стимулировало и финансировало правительство. Хороший пример замечен в части работы, которая вышла из института разработки ПО (SEI) в университет Carnegie-Mellon. Через бюджетное финансирование, был осуществлен переход свежих и новаторских идей в частный сектор.
Пока мы раскрыли только фундаментальные основы операции SPMO на очень высоком уровне. Дальше мы пройдем через каждую из 8ми фаз процесса SEP и рассмотрим детальнее задачи основной команды на стадии разработки. В этом пункте пойдем к следующей главе, где мы обсудим дорожную карту фазы 1 SEP и рассмотрим обязанности основной команды во время первой встречи.