Сначала все было просто. Молодость, задор. Проект пилили несколько программистов. Все кодили, по мере готовности копировали код на общую виртуалку, изредка попинывали админа на предмет доставить какой-нибудь пакет или поправить конфиг. Как только понимали, что все, шли делать релиз. Сначала backup, потом старшой собирал всю свою крутизну в кулак, копировал проект на production сервер и, при содействии админа, добивался, чтобы оно там заработало. Команда выжидала два дня, убеждалась, что очереди из благодарных пользователей с топориками не образовалось, и, с чувством гордости за выполненную работу, шла пить пиво.

Потом все чуть-чуть повзрослели. Появились и начали как-то использоваться redmine/jira/etc, git/svn, jenkins, spinx-docs/rubydoc/doxygen/etc, wiki, unit тесты. Появились подпроекты, стенд подрос. Production сервачков стало несколько. Админ поднял salt/puppet/etc, мониторинг, сидит в своем логове как паук, правит конфиги на salt-master и дергает оттуда state.highstate.

Жизнь

А это таки подходящее время, чтобы сесть и немного подумать про жизнь (проекта).

Стадий жизненного цикла всего семь.

1. Conceptual design. На этом этапе надо понять, что вообще надо делать.
2. Architectural design. На этом этапе надо понять как это нужно делать.
3. Implementation. Это непостредсвтенно кодинг и unit тестирование.
4. Verification. Проверка того, что все задуманные функции программа выполняет.
5. Validation. Проверка того, что программой таки можно пользоваться. Из предыдущего пункта это внезапно не следует.
6. Ввод в эксплуатацию. В нее обычно входят выкатка релиза, миграция данных, обучение пользователей.
7. Собственно сама эксплуатация.
8. Вывод из эксплуатации

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

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

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

Что может сломаться?

Версии библиотек. Собрались, набросали диаграмку классов, договорились использовать libcrutch. Одна команда давно и долго сидела на libcrutch-1.0, вторая о ней только узнала и скачала из Интернета libcrutch-2.0. А выясниться это только на интеграционном тестировании. Словить bug можно даже на отличиях libcrutch-1.2.14 и libcrutch-1.2.15. А всякие LD_PRELOAD или docker только подливают масла в огонь. Даже если проект весь из себя на микросервисах, в интерфейсы может быть венесен обмен данными, полученными из libcrutch и имеющими в разных версиях разный формат.

Несоответствие версий компонент. Одни пилят libbase, другие libManagementFacade. В процессе выяснилось, что в libbase-1.14.3 есть мелкий но коварный bug. Поговорили, поправили, забыли. Тестировались на libbase-1.14.4, а в релиз ушло libbase-1.14.3.

Изменение конфигурации окружения. Один POST запрос внезапно начал работать долго. Посмотрели, он не такой уж и важный, пусть себе поработает.Увеличили в nginx таймаут ожидания ответа backend"а. Админ на стенде поправил и забыл. Выкатились и опять старые баги ловить, но теперь уже в боевых условиях.

Изменение проектных решений. Начинали делать под Windows, потом прониклись идеями RMS"а, решили перейти на Ubuntu, но до всех решение не довели. Начали собирать, все принесли deb пакеты, а кто-то, кто был в танке, exe"шник.

Потеря значимого для пользователя функционала. Принесли новую версию, долго рассказывали про смену дизайна, про новые фреймворки, про передовые алгоритмы. Пользователи послушали, головой покивали, и сказали: «Это все хорошо, но вы для нас по нашей просьбе формочку делали. Раньше она была пятым подпунктом в третьем пункте меню, где она теперь?» Потеряли на каком-то merge request"е.

Что делать

Программистам очень повезло, что есть git. Основной удар он берет на себя и от них самих требуется совсем чуть-чуть.

1. Определить все компоненты, которые нужны для функционирования проекта, убедиться, что они корректно версионируются. Конфигурация в первом приближении это список компонент и их версий.
2. Понять как обеспечивается перенос конфигурации со стенда в production.
3. Начать управление требованиями. Вообще говоря, управление требованиями это отдельный процесс. В рамках управления конфигурацией нужно убедиться, что для каждого компонента, попавшего в релизный набор, прилагается документация, в которой точно описаны требования, предъявленные к этому компоненту, и их cтатуcы: выполнено, не выполнено, выполнено частично, с оговорками.
4. Да и вообще у каждого компонента должна быть документация, которая описывает что как и зачем он делает.

На этапе завершения conceptual design"а , когда специалисты предметники говорят: «Такая система нам нужна!», - технари в один голос заявляют «Сделаем!», - менеджеры дают отмашку: «Ресурсы выделим - делайте!», - нужно убедиться, что согласованное описание системы из головы экспертов вынуто, на требования порезано и в документацию положено. В процессе разработки это описание будет меняться. Надо убедиться, что описание версионируется. Неплохой вариант, если это текст, забрать его в git

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

На этапе разработки нужно убедиться, что код документируется. Неплохо на модули заводить отдельные документы (в git), которые описывают требования к ним и их особенности поведения. Оставлять много информации в redmine/jira не стоит. После допила большой фичи, перед merge"ом в master, нужно убедиться, что ее описание из task tracker"а корректно перенесено в документацию. Просто потому, что через некоторое время в рамках другой задачи поведение может поменяться и собирать документацию по нескольким задачам будет сложно. Task tracker целостную картину не обеспечивает.

Пользовательскую документацию хорошо делать на этапе разработки. Держать (если можно) в git и править параллельно с кодом. Если на это нет специальных технических писателей, контекст уйдет, все забудут, документации точно не будет.

При верификации проверяется соответствие программы выдвинутым требованиям. В конце нужно убедиться, что всем требованиям присвоен статус выполнен/не выполнен.

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

На этапе ввода в эксплуатацию проверяется корректность подготовки и накатывания релиза. Надо убедиться, что в него подшиты все компоненты правильных версий. Основной удар здесь держит salt/puppet. Можно и без них, просто выпустив инструкцию по установке, но с ними проще. Готовить их надо правильно и загодя.

Про этап эксплуатации все понятно. Надо просто следовать инструкциям производителя.

На этапе вывода из эксплуатации надо убедиться, что все нужные данные вынуты.

Про сборку и salt/puppet. Это вторая линия обороны (сразу после git"а) Рабочая схема применения примерно такая:

1. Убедиться, что ситуация с каждым сторонним пакетом ясна: откуда взято, какая версия, какие патчи накладывались. Если какая-то редиска (нехороший человек) приклеивает одинаковые версии на физически разные файлики, его надо убедить, что он не прав, или на всю его продукцию наклеивать дополнительную версию.
2. Если все rpm"ки скидываются в один репозиторий, нужно убедиться, что понятно, какая именно версия будет накатана. Неплохой вариант - иметь скрипт пересборки всего репозитория и наклеивать версию на весь репозиторий целиком. Другой - версию указывать явно в манифесте/sls-файле. Кстати, у puppet"а есть bug, ресурс package не умеет версию понижать. Почему им не стыдно, я не знаю.
3. Все манифесты/sls файлы храняться в git. В pillar для salt или параметры классов для puppet выносится только то, что отличает стенд от продакшена. Такими вещами, например, являются ulr"ы web сервисов, параметры наподобии shared_buffers для postgres, флаги, включающие debug режим. Все остальное безжаластно hard"кодится. Параметры задаются один раз при развертывании стенда и в дальнейшем меняются редко. sls файлы воспринимаются как код, он накатывается на стенд, тестируется и в неизменном виде переносится в production.

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

Многие компании внедряют Управление активами до внедрения Управления конфигурациями. Процессы в этом разделе применимы как к Управлению активами, так и к Управлению конфигурациями.

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

7.5.1 Начальное планирование.

Действия по начальному планированию проекта по Управлению конфигурациями включают:.

■ согласование цели, задач, масштаба, приоритетов и подхода к внедрению процесса Управления конфигурациями;.

■ назначение ответственного за процессы и системы Управления конфигурациями;.

■ анализ существующих систем Управления конфигурациями, данных и процессов;.

■ разработка обобщенного Плана управления конфигурациями (который может быть включен в планы Управления изменениями и Управления конфигурациями в организации) и проекта создания системы Управления конфигурациями;.

■ планирование и получение финансирования для средств Управления конфигурациями и обязательства по предоставлению дополнительных ресурсов;.

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

Для всех систем, кроме самых малых, средства поддержки Управления изменениями и Управления конфигурациями особенно необходимы из-за непрактичности систем бумажного документооборота. Для размещения средств Управления конфигурациями, в особенности CMDB, требуется аппаратное обеспечение и ресурсы для хранения данных. Средства поддержки должны, как минимум, позволять осуществлять передачу данных из отдельных систем «проектного Управления конфигурациями» без необходимости повторного ввода. В идеале средства Управления конфигурациями для системы, находящейся в эксплуатации, и для проектов, находящихся в разработке, должны работать интегрированно.

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

7.5.2 Согласование цели, задач, масштаба, приоритетов и подхода к внедрению в соответствии с требованиями бизнеса.

Цель, задачи, масштаб и приоритеты Управления конфигурациями должны быть согласованы с Менеджером услуг и другими менеджерами и соответствовать требованиям бизнеса. Должно быть выработано соглашение, будет ли этот процесс централизован совместно с Управлением изменениями и Управлением релизами.

Цель и масштаб могут быть следующими:.

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

Задача может быть следующей:.

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

Подробные задачи для Управления конфигурациями должны включать:.

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

■ определение и документирование процедур и порядка работы, которому необходимо следовать;.

■ идентификация, маркировка и запись наименований и версий УЭ, которые составляют услуги ИТ, инфраструктуру и их взаимосвязи;.

■ отчетность о текущем статусе и истории всех элементов ИТинфраструктуры;.

■ обеспечение записи всех Изменений в УЭ как можно быстрее;.

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

■ обучение и проведение тренингов по процессам контроля в организации;.

■ отчетность по метрикам, связанным с УЭ, Изменениями и Релизами;.

В аудит и отчетность о нарушениях стандартов инфраструктуры и процедур Управления конфигурациями.

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

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

В серверы поддержки инфраструктуры;.

В мейнфрейм-системы;.

В базы данных Заказчиков и поставщиков;.

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

В услуги, критичные для целей бизнеса;.

В сборки рабочих станций и лицензии на ПО;.

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

Необходимо спланировать затраты на средства поддержки, учитывая требования к аппаратному обеспечению. Несмотря на то, что средства, способные интегрировать работу Управления инцидентами, Управления изменениями, Управления конфигурациями, Управления релизами, Управления проблемами и Службы Service Desk, могут стоить значительно дороже, чем «простые» средства Управления конфигурациями, дополнительная стоимость часто будет оправдана за счет более высокой степени интеграции. Для более крупных организаций эти процессы управления практически невозможны без адекватных средств поддержки.

7.5.3 Назначение Менеджера конфигураций и планирование группы Управления конфигурациями.

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

Процесс Управления конфигурациями требует от задействованного персонала усердной работы и внимания к деталям. Для центра поддержки требуется персонал (кроме случаев небольших организаций). При планировании количества персонала для Управления конфигурациями должны быть рассмотрены следующие факторы:.

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

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

■ будет ли эта группа частью объединенной группы по Управлению изменениями, конфигурациями и релизами;.

■ размер ИТ-инфраструктуры, уровень, на котором должен поддерживаться контроль, и, следовательно, количество УЭ, которое необходимо контролировать;.

■ количество персонала, который будет осуществлять действия по контролю в других группах и проектах;.

■ доступность средств поддержки;.

■ размеры, частота и сложность Изменений и Релизов.

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

7.5.4 Анализ существующих систем.

Даже в организациях, не использующих процессы в своей работе, существуют процессы и процедуры Управления конфигурациями. Они могут быть встроены в другие процедуры или связаны с какой-либо отдельной группой. Если одна из поставленных целей - внедрение общей системы Управления конфигурациями вместе с соответствующими процессами, то важно определить и проанализировать:.

■ владельцев УЭ высокого уровня;.

■ текущие рамки процесса и ресурсы (человеческие ресурсы и средства автоматизации);.

■ текущий порядок, процессы и процедуры Управления изменениями и Управления конфигурациями;.

■ обобщенные конфигурационные данные для текущих списков оборудования, печатных материалов, локальных таблиц или баз данных;.

■ роли, ответственности и возможности персонала, вовлеченного в Управление конфигурациями.

7.5.5 Разработка планов Управления конфигурациями и проектирование систем.

Для некоторых технологий и платформ Управление конфигурациями может быть распространено по всей организации, например для мейнфрейм-систем, сетей и рабочих станций. Ряд организаций передает контроль группам поддержки, являющимся экспертами в какой-либо технологии или платформе, поскольку обучение центрального персонала в специализированных областях невыгодно. В этих случаях менеджер группы поддержки несет ответственность за контроль Учетных элементов, которыми владеет и которые поддерживает эта группа. Процедуры для Управления изменениями, Управления конфигурациями, Управления релизами и централизованную CMDB следует использовать везде, где это возможно. Эти процедуры могут быть определены в плане Управления изменениями и конфигурациями для организации (см. Приложение 7 А) и поддерживаться документацией по эксплуатации и проектной документацией для системы Управления конфигурациями. Связи между этими планами должны быть документированы, чтобы помочь персоналу видеть контекст Управления конфигурациями применительно к их группе. Менеджер каждой группы должен подписаться под этим планом. Пример связей показан на Рисунке 7.2.

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

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

Рисунок 7.2 - Примеры планов Управления конфигурациями в организации.

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

7.5.6 Подробное планирование внедрения.

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

Основные действия следующие:.

■ более подробно проанализировать сложившийся порядок Управления конфигурациями, а также его взаимодействие с другими процессами Управления услугами, закупками и разработками;.

■ проанализировать возможности существующих подразделений и сотрудников, вовлеченных в Управление конфигурациями, изменениями и релизами;.

■ провести обзор конфигурационных данных, содержащихся в печатном виде, в локальных электронных таблицах или базах данных, и разработать стратегию переноса/загрузки этих данных;.

■ собрать, пересмотреть и достичь соглашения по требованиям и функциональным спецификациям;.

■ разработать критерии выбора поставщиков средств автоматизации Управления конфигурациями;.

■ оценить и выбрать средства автоматизации CMDB и Управления конфигурациями;.

■ купить и инсталлировать средства автоматизации CMDB и Управления конфигурациями;.

■ составить подробный проект системы Управления конфигурациями, включая интерфейсы с Управлением изменениями, Управлением релизами, другими процессами Управления услугами, закупками и разработкой;.

■ определить типы УЭ, их атрибуты, типы взаимосвязей, обобщенные УЭ;.

■ разработать бизнес-процессы Управления конфигурациями и процедуры, интегрированные со средствами Управления конфигурациями;.

■ проверить CMDB и другие средства поддержки, выделив достаточно времени для исправления проблем, включая незначительные и не влияющие на успешную работу; их также обязательно надо устранить до внедрения Управления конфигурациями;.

■ спланировать и обеспечить безопасные хранилища УЭ (то есть, шкафы, контролируемые библиотеки и каталоги) совместно с Управлением релизами;.

■ разработать и достичь соглашения о ролях, обязанностях и планах по обучению;.

■ объяснить персоналу важность Управления изменениями и Управления конфигурациями и обучить его использованию этих процессов.

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

Планирование поэтапного внедрения Управления конфигурациями поможет получить преимущества раньше и обосновать необходимость в финансировании и ресурсах на последующих этапах. Для каждого этапа необходимо спланировать следующие действия:.

■ составить график ознакомительного обучения для ключевого персонала, вовлеченного в Управление конфигурациями;.

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

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

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

■ разработать и спланировать процедуры регистрации для новых УЭ, и начать выполнять их как можно раньше (предпочтительно перед тем, как собраны данные о существующих УЭ);.

■ загрузить начальную конфигурацию и связанные учетные записи в систему Управления конфигурациями;.

■ обучить персонал незадолго до начала использования новых процедур и программных средств;.

■ начать промышленную эксплуатацию и поддерживать внедрение;.

■ продолжать наполнение CMDB и Библиотеки Эталонного ПО; самая длительная часть внедрения - сбор информации об УЭ и наполнение CMDB и Библиотеки Эталонного ПО (Definitive Software Libaray, DSL);.

■ наблюдать за ходом работ, чтобы обеспечить эффективное и продуктивное использование новых процедур и программных средств.

Если Управление конфигурациями используется для поддержки выполнения других процессов, таких как Управление инцидентами, то, чтобы разворачивать эти системы параллельно, потребуется дополнительное планирование. Локальные планы Управления конфигурациями могут определить процессы идентификации и контроля УЭ для определенных технологических групп. Руководитель группы может назначить Менеджера конфигураций для владения локальным планом Управления конфигурациями и общения с персоналом центрального подразделения Управления конфигурациями, а также в качестве представителя в Консультативном комитете (или комитетах) по изменениям (Change Advisory Board, CAB).

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

В идеале во время наполнения CMDB состояние УЭ должно быть «заморожено» или «в ожидании», но такое решение может оказаться непрактичным. Тем не менее, после сбора данных Управления конфигурациями об определенных УЭ эти УЭ должны быть сразу же переданы под контроль Управления конфигурациями. В этом случае возможно наполнять CMDB поэтапно (то есть начать с аппаратного обеспечения, потом постепенно перейти к программному обеспечению, сетям) см. параграф 7.5.7.

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

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

7.5.7 Наполнение CMDB и DSL.

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

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

Если такой подход невозможен, то важно записывать все Изменения, которые возникают между сбором данных об УЭ, последующим вводом этих данных в CMDB и передачей УЭ под контроль Управления конфигурациями. Для этого следует минимизировать интервал между этими этапами для каждого УЭ. Вначале должны быть собраны Запросы на Изменение (RFC) и записи о Релизах, соответствующие еще не внедренным Изменениям. Все RFC после этого должны быть включены в CMDB. При таком подходе CMDB может быть использована для записи всех последующих действий по внесению Изменений, включая авторизацию и внедрение. Сбор любых требуемых исторических записи может быть отложен для выполнения в удобное время.

Процесс Управления релизами должен наполнять Библиотеку эталонного ПО (DSL) параллельно с внедрением CMDB. Требуются процедуры для обеспечения того, что:.

■ чтобы это находящееся в DSL программное обеспечение было защищено;.

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

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

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

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

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

7.5.8 Переключение на новые процессы.

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

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

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

7.5.9 Другие вопросы, связанные с внедрением.

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

Для эффективной работы Управления конфигурациями требуется долгосрочная приверженность руководства и персонала. Успешное внедрение зависит от достаточного количества обученных сотрудников. Если существует нехватка персонала в подразделении, отвечающем за Управление конфигурациями, или сотрудники недостаточно обучены, то это может стать «узким местом» при внедрении процесса, привести к критическим ошибкам, затраты на исправление которых могут быть больше, чем расходы на оплату квалифицированных струдников. На короткий период при внедрении проекта может потребоваться дополнительный персонал (например, для помощи при проведении инвентаризации и/или наполнении CMDB).

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

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

■ аудита действий по Управлению конфигурациями на предмет их соответствия Планам управления конфигурациями;.

■ достаточного (хотя и не слишком подробного) набора УЭ, находящихся под Управлением конфигурациями, с целью обеспечения контроля и.

поддержки эффективного Управления проблемами, Управления изменениями и Управления релизами;.

■ доступности ресурсов и достаточной квалификации персонала для эффективного выполнения действий по Управлению конфигурациями;.

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

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

7.5.10 Затраты.

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

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

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

■ затраты на персонал для разработки и выполнения процедур;.

■ идентификацию конфигураций АО и ПО и уровня контроля над ними;.

■ аппаратное и программное обеспечение для CMDB и DSL, включая затраты на лицензии и сопровождение;.

■ специализированное ПО управления конфигурациями для каждой платформы, включая соответствующее АО;.

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

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

■ необходимость интеграции средств Управления конфигурациями и средств Управления услугами;.

■ разнородность и качество существующей информации, которая должна быть загружена в CMDB.

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

Другие затраты по внедрению Управления конфигурациями связаны также:.

■ с обучением персонала и образованием;.

■ с затратами на персонал для разработки и выполнения процедур;.

■ с количеством Пользователей, которым необходимо иметь доступ к системе Управления конфигурациями;.

■ с разнородностью и качеством существующей информации, которая будет загружена в CMDB и DSL, и с усилиями, требуемыми для ее обработки и загрузки;.

■ со временем и ресурсами, требуемыми для приведения в порядок низкокачественных данных;.

План управления конфигурацией в стандартах

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

Факторы, влияющие на структуру плана управления конфигурацией и его детализацию

	Возможные значения	Воздействие, описание
Тип проекта	Разработка модели (прототипа) Проект сопровождения ПС Коммерческий (с сопровождением) Коммерческий без сопровождения Субподрядный
Наличие нескольких офисов (регионально распределенная разработка)	Один офис Более одного	Наличие нескольких офисов усложняет план, дополняя его регламентами взаимодействия между офисами. Также дополнительные офисы влияют на общую архитектуру проекта. На такие ключевые факторы как количество ответвлений на проектном дереве (как правило, добавление нового региона, приводит к добавлению минимум одной ветви для каждого региона). Увеличение числа регионов воздействует на уровень формализма плана. Уровень - высокий.
Относительный размер проекта		Воздействует на количество регламентов и их проработанность и детальность. Фазы, взаимодействие между группами, прохождение запросов на изменения описываются более детально. Чем больше проект, тем более формализованным должен быть план.
Количество конфигурационных элементов	Число конфигурационных элементов влияет только на более глубокую проработку идентификации элементов. В некоторых случаях полезно определить в плане все типы конфигурационных элементов на основании шаблонов (например, по расширениям файлов)
Количество компонентов и подсистем	Число компонентов и подсистем могут влиять на выборку элементов из репозитория (способ выборки и обращения). Также влияет на глубину изложения раздела, описывающего структуру проектного каталога
Фаза жизненного цикла	План УК обычно описывает все фазы жизненного цикла ПС. Иногда при работе с субподрядчиками бывает необходимо более четко выделить фазу, на которой подключается субподрядная организация. Также к плану УК может выпускаться дополнение, отражающее фазу жизненного цикла ПС.
Модель разработки	В зависимости от того какая модель разработки принята за основу (каскад, итерации, спираль), необходимо откорректировать план УК в части состава фаз ЖЦ ПС, глубины их описания, способа идентификации базовых версий, выпуска релизов.
Доступность (наличие) средств УК и иных смежных средств	Основные системы УК (как правило, только отслеживание версий) Генераторы отчетов (обычно встроенные) Средства управления библиотеками Продвинутые, интегрированные Тоже что и выше. Плюс средства управления изменениями Встроенные средства сборки и аудита Разрозненные	Проект может строиться вообще без средств автоматизации (например, управление конфигурацией сборки макета печатной платы). На ход проекта и на план оказывают существенное воздействие такие факторы как используемые средства разработки, платформа разработки (возможно разработка на нескольких платформах и для нескольких платформ одновременно). Также большое значение имеют тип и количество средств реализации (автоматизации УК), их принадлежность одному или нескольким вендорам. Например, в проекте можно использовать средство управления версиями от одного производителя, а средство управления изменениями от другого. Можно иметь интеграцию средства управления со средствами управления проектами а можно и не иметь. Тип интеграции между средствами, архитектура интеграции должны быть детально рассмотрены в плане.
Уровень формализации (как процессов организации, так и тип контроля плана)		Уровень формализации можно варьировать в зависимости от многих факторов, в том числе отраженных в данной таблице. Выбирая уровень формальности и глубины изложения необходимо руководствоваться исходящими задачами и целями. Такие факторы, как сложность проекта, региональная разбросанность, тип проекта, наличие субподрядчиков должны автоматически подвигнуть к написанию высоко формализованного плана УК. Средний и низкий уровень может применяться в относительно краткосрочных проектах, проектах, в которых задействовано небольшое количество разработчиков. С ростом команды, разделением ролей план УК должен быть пересмотрен, уровень формализации поднят.

На сам план при его разработке влияют множество факторов. Структура плана УК, и его содержание, зависит от таких факторов, как тип проекта и его длительность, уровень формализации процессов, размер команды (наличие регионально распределенных групп), количество субподрядчиков, и многих других. Это означает, что структура плана, состав приложений могут в достаточно больших пределах варьироваться, сохраняя при этом единый «дух».

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

История развития дисциплины управления конфигурацией

Первым заметным шагом в развитии управления конфигурациями (сокращенно – УК) было изобретение микрометра в 1636 году (William Gascoigne). Это устройство сыграло важную роль в индустриальной революции и переходе к массовому производству. Этот инструмент позволил использовать взаимозаменяемые части в различных устройствах, что являлось существенной причиной для того, чтобы использовать процедуры управления конфигурацией.

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

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

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

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

Мониторинг проекта

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

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

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

Для осуществления мониторинга необходимо сформировать команду в соответствии со следующими правилами.

• 1. Это должна быть небольшая команда, состоящая из экспертов, имеющих опыт осуществления проектов и знания особенностей данного проекта.
• 2. Команда изучает проект на месте его проведения.
• 3. Команда составляет краткие отчеты и передает их менеджменту проекта.
• 4. Предложения и рекомендации, сделанные командой, должны учитываться, а их реализация – проверяться при осуществлении дальнейших мониторингов.

Процедура мониторинга представлена на рис. 11.2.

Рис. 11.2.

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

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

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

Характеристики контекста организационных изменений показаны в табл. 11.1.

Таблица 11.1

Основные характеристики контекста организационных изменений

Характеристика	Основные аспекты
Власть и влияние	Кому принадлежит власть в организации? Чьей поддержкой внутри и вовне организации необходимо заручиться? Какими возможностями по проведению изменений обладают руководители отдельных подразделений?
	Сколько времени есть у организации, чтобы достичь желаемого состояния? Она находится в кризисе и нужно быстро принимать решения, или есть время для спокойных эволюционных преобразований? Каковы ожидания ее владельцев? Они хотят получить быстрые результаты или готовы ждать фундаментальных преобразований?
Масштаб изменений	Требуется слегка изменить систему выпуска продукции или нужна полная трансформация? Изменения должны в основном затронуть какое-то конкретное подразделение или всю организацию в целом?
Степень сохранения активов	Идентификация осязаемых и неосязаемых активов. Что целесообразно сохранить и что можно ликвидировать?
Степень разнообразия персонала	Насколько разнообразны работники по своим ценностям, предпочтениям, нормам и правилам поведения? Много ли субкультур и национальных культур существует в группах?
Способность к изменениям, потенциал	Есть ли у организации способность, опыт и потенциал для преобразований? Как широко этот потенциал распространен внутри организации? Насколько глубоко организация и ее персонал изменялись в прошлом? Есть ли в организации люди, которые представляют, что такое изменения, и практикуют их в индивидуальном порядке?
Платежеспособность	Какие финансовые и кадровые ресурсы может выделить организация на проведение изменений?
Готовность к изменениям	Персонал сознательно идет на перемены или людей надо убеждать? Какова степень сопротивления изменениям? Какова степень поддержки изменений?
Путь изменений	Эволюция – природа изменений основана на постепенном, приростном принципе, а в конечном результате они направлены на полную трансформацию организации. Адаптация – принцип остается тем же, но в результате изменений должна быть преобразована только какая-то часть организации. Реконструкция – быстрые преобразования в части организации. Трансформация – полное изменение организации быстро, в сжатые сроки
Стиль изменений	Зависит от стиля управления, предпочитаемого или выбираемого менеджером, отвечающим за изменения. Существует множество подходов к классификации стилей (директивный, основанный на участии, эксплуататорский, стиль сотрудничества и т.д.)
Цель изменений	На чем будут сосредоточены изменения главным образом? Это могут быть изменения ценностей персонала, поведенческие изменения, изменения качества продукции и т.п.
Роли в изменениях	Изменения тогда будут происходить так, как мы хотим, когда есть, кому играть роль лидера. Тогда есть смысл говорить об управлении стратегическими изменениями. Агенту изменений необходима поддержка других людей. Необходимо создавать социальную базу для изменений. Можно приглашать внешних фасилитаторов для продвижения в процессе изменений. Создание команды единомышленников – весьма важный вопрос
Механизмы и рычаги для проведения изменений	При поиске механизмов и рычагов необходимо учитывать тесную взаимосвязь между подсистемами организации, а также между организационной структурой, системой контроля, организационной культурой, системой распределения власти. Различные сочетания этих сложных элементов дают представление о том, как создавать и задействовать специфические механизмы, позволяющие реализовывать организационные изменения

Процесс управления изменениями состоит из двух стадий. Это показано на рис. 11.3.

Рис. 11.3.

В самом общем виде логика внедрения изменений может быть представлена на рис. 11.4.

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

Рис. 11.4.

Все многообразие подходов к внедрению изменений, наработанное в мировой практике, можно, в некотором приближении, свести к четырем составляющим. Э го стратегия принуждения , предусматривающая силовое решение вопроса, стратегия рационального убеждения, стратегия формирования новых ценностей и стратегия компромиссов. В применении каждой существуют свои нюансы. Силовое давление требует тщательного непрерывного контроля, приказ выполняется по минимуму, но выполняется, если контроль надежен. Решение по убеждению реализуется максимально, но одновременно проверяется на разумность – появление у исполнителя сомнений немедленно тормозит процесс. Формирование новых ценностей требует больших затрат времени, хотя теоретически результативно (практически, рынок меняется слишком быстро, чтобы получить результат до устаревания идей, кроме случаев "вечных" ценностей). Бартер есть сочетание убеждения и принуждения, усиливающее действенность обоих, но – за дополнительную плату (деньгами, статусом, полномочиями).

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

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

• – анализ текущего состояния дел;
• – определение конечной цели и составление плана проведения реформ;
• – подключение к работе необходимого количества сотрудников;
• – отслеживание и закрепление полученных результатов.

Эти стадии отражены на рис. 11.5.

Рис. 11.5.

В ходе реализации проекта может возникнуть необходимость осуществить следующие изменения:

• 1) содержания продукта (состав и спецификация элементов продукта);
• 2) содержания проекта (состав и содержание работ проекта) – например, внесение незначительных, но, как правило, многочисленных и зачастую неконтролируемых улучшений по просьбе заказчика. Последнее особенно характерно для инновационных проектов, где заказчики занимают активные позиции в ходе их реализации;
• 3) сроков и стоимости проекта;
• 4) процедур управления проектом;
• 5) вследствие реакции на наступление рисковых событий.

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

• – на ценность и эффективность проекта;
• – продолжительность и сроки завершения проекта;
• – стоимость и бюджет проекта;
• – качество выполнения работ и спецификации требований к результатам.

Внесение изменений в проект предполагает:

• – возникновение дополнительных затрат;
• – нарушение плановых сроков осуществления проекта;
• – невозможность достижения требуемого качества или результата проекта.

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

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

• 1. Отчет о проблеме (Problem report ) – описание проблемы, возникающей в ходе реализации проекта. Формируется на начальной стадии.
• 2. Запрос на осуществление изменения (Change request) – формируется на начальной стадии.
• 3. Описание предполагаемого изменения (Change proposal form) – информация об изменении, его текущем статусе, инициаторах и ответственных за выполнение и контроль. Формируется на начальной и корректируется на последующих стадиях.
• 4. Заявка на изменение (Change order ) – оформляется в виде письменного приказа и подписывается должностным лицом подрядчика; разрешает и указывает, какие производить изменения по проекту. Формируется на стадии принятия решения.

Управление конфигурацией

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

Управление конфигурацией охватывает процессы:

• – подачи предложенных изменений;
• – отслеживания системы рассмотрения и утверждения предложенных изменений;
• – определения уровней утверждения для авторизации изменений;
• – обеспечения методов реализации одобренных изменений.

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

Этапы организации управления конфигурацией проекта представлены на рис. 11.6.

Образцы документов, регистрирующих изменения, приведены в приложении 7.