Файл: Управление изменениями в проекте.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 04.07.2023

Просмотров: 296

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

ГЛАВА 1

Инновации и изменения на рабочем месте

ГЛАВА 2

Изменения в культуре и в людях

ГЛАВА 3

Управление изменениями. Microsoft

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

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

Запросы на изменение могут поступать из различных источников, включая следующие:

Процесс 5. Разработка и тестирование изменения. После утверждения изменения можно приступать к его разработке и тестированию. Эти действия совпадают с проведением этапа «Внедрение» жизненного цикла ИТ­услуги и направлены на то, чтобы предварительное планирование, основное планирование, создание, стабилизация и выпуск ИТ-услуг выполнялись в соответствии с требованиями бизнеса и предоставленными заказчиком спецификациями.

Заключение

Библиография

Расформирование совместного предприятия, созданного без надлежащего предварительного планирований этой процедуры, оказывается исключительно неприятной операцией. Нужно перераспределить владение интеллектуальной собственностью и другими активами, управлять отношениями с клиентами, управлять и выделять ресурсы на выполнение обязательств и т. п. Любая компания, планирующая войти в совместное предприятие, должна пройти серьезный и подробный процесс планирования разрешения споров и вариантов прекращения деятельности предприятия, в том числе, какие права передаются какой компании и каковы обязательства по поддержке в переходный период.

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

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

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

Каждая компания-участник выигрывает от технологических инноваций других участников сотрудничества оттого, что услуги становятся более согласованными, а их качество оказывается выше. Вместе с тем, все участники выигрывают за счет увеличения доходов, создаваемых клиентами участников.

Соглашения о стратегических альянсах могут быть сложными, поэтому требуется подробное планирование и документирование. Вопросы отношений с клиентами, разделения доходов, расходов и ответственности, конфиденциальности и прав на созданную интеллектуальную собственность могут оказаться исключительно сложными. К основным вопросам следует отнести:


  • Кто должен представлять совместно созданные технологии перед клиентами — одна из компаний или совокупно все участники?
  • Что если клиенты захотят иметь дело с одним поставщиком, требуя, чтобы остальные числились субподрядчиками?
  • Как между участниками должны распределяться доходы и ответственность за расходы?
  • Если клиент, который приобрел инновационный продукт стратегического альянса, подаст в суд на одного или обоих участников, то как должна распределяться ответственность между участниками?
  • Иногда участникам придется раскрывать свою конфиденциальную информацию. Какая конфиденциальная информация может раскрываться и при каких обстоятельствах?
  • Если инновационная технология действительно создана общими усилиями, то кому должны принадлежать лицензии, интеллектуальная собственность и права на авторские отчисления? Как эти права меняются при расформировании альянса?

Проработайте все эти вопросы и сформулируйте четкие правила в соглашении о сотрудничестве, чтобы предотвратить конфликты и неприятные сюрпризы в будущем.

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

Каждый участник должен участвовать в совместном анализе результатов исследований, чтобы решить, что нужно делать с тем или иным исследованием — отложить, выделить ассигнования на совместную разработку или выделить для дальнейшей доработке на местах.

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

У этой модели есть еще один недостаток: патентные пулы часто предусматривают сотрудничество между компаниями-конкурентами, поэтому участникам надо следить за соблюдением норм антимонопольных законов. Поэтому любая компания, планирующая участие в этой модели, должна заручиться поддержкой государственного антимонопольного органа.


Правильный инструмент. Компании, технологии, отрасли и рынки могут создавать самые причудливые сочетания. Стратегические преимущества и сложности каждой описанной здесь модели служат основой для информированной оценки потребностей и возможностей компании в области создания инновационных технологий. Естественно, что за этим должно следовать тщательное планирование и документирование, призванные реализовать эти стратегические решения на практике.

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

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

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

SMF-функция «Изменение и конфигурация» предоставляет рекомендации, основанные на передовом опыте и позволяющие ИТ-подразделению контролировать риски и управлять изменениями с помощью повторяемых, предсказуемых и поддающихся измерению процессов. Установленные организацией допустимые риски определяют уровень детализации и формализации, применяемые при внесении изменений разных типов и размеров и в разные сроки.

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


Надлежащее управление изменениями в рамках всего жизненного цикла ИТ-услуги позволяет устанавливать границы и обеспечивать высокую гибкость в их пределах. Эти границы сужаются при переходе от этапа «Планирование» на этапы «Внедрение» и «Эксплуатация», по мере роста влияния рисков на рабочую среду и ИТ-услуги.

Риск изменения зависит от классификации изменения и его места в жизненном цикле ИТ-услуги. Уровень обнаруженного риска определяет строгость требуемых мер контроля изменений.

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

Изменения могут быть объединены в следующие категории:

  • Важные. Изменения, которые могут оказывать большое влияние на группу (например, изменение уровня отдела либо уровня организации или изменение сетевых служб в масштабах сети).
  • Значительные. Значительные изменения оказывают масштабное воздействие, однако это воздействие не является значительным (например, изменение, влияющее на группу в подразделении или на отдельную группу конфигурационных элементов).
  • Незначительные. Изменения, влияющие на незначительное число людей или конфигурационных элементов (например, изменение параметров принтера, который используется в подразделении, состоящем всего из нескольких сотрудников).
  • Стандартные. Изменения, которые уже вносились и являются частью процесса эксплуатации (например, обновление профиля пользователя).

Стандартные изменения обеспечивают гибкость в пределах границ управления изменениями на этапе «Эксплуатация». Каждая организация должна разработать набор стандартных изменений, гарантирующих предсказуемое и эффективное использование ресурсов благодаря «надежному, проверенному и протестированному» стандартному процессу обработки запросов общих изменений. Это достигается путем выявления общих повторяющихся изменений и оптимизации их выполнения. В идеальном случае не менее 80% всех изменений, вносимых на этапе «Эксплуатация», должны быть стандартными — это свидетельствует о зрелости процесса управления изменениями.


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

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

  • Оценивать предлагаемые изменения
  • Определять текущее состояние рабочей среды
  • Разрешать проблемы, анализируя последние изменения в рабочей среде
  • Возвращать конфигурацию в известное предыдущее состояние, чтобы разрешать хронические проблемы или выполнять нормативные требования
  • Тестировать изменения вне рабочей среды и быть уверенными, что рабочая среда подобна тестовой среде.

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

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

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

CMS предоставляет следующие возможности:

  • Средства анализа, контроля и прогнозирования последствий изменений
  • Полное и точное представление состояния рабочей среды
  • Журнал предыдущих состояний, помогающий анализировать и разрешать проблемы

Используя систему управления конфигурациями в процессе управления изменениями, ИТ-специалисты могут выполнять следующие действия:

  • Анализировать CMS в ходе оценки нового запроса на изменение (RFC), чтобы определить влияние предлагаемых изменений
  • Вносить в CMS информацию об утвержденных запросах на изменение, чтобы использовать эти сведения при оценке других запросов на изменение
  • Вносить в CMS информацию о выполненных изменениях, чтобы использовать эти сведения при разрешении проблем после выполнения изменений
  • Использовать CMS для подтверждения известного работоспособного состояния, необходимого для отката изменений, оказывающих непредвиденное негативное влияние