Национальный стандарт РФ ГОСТ Р ИСО/МЭК 19770-1-2014 "Информационные технологии. Менеджмент программных активов. Часть 1. Процессы и оценка соответствия по уровням" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2014 г. N 483-ст) (документ утратил силу)

Национальный стандарт РФ ГОСТ Р ИСО/МЭК 19770-1-2014
"Информационные технологии. Менеджмент программных активов. Часть 1. Процессы и оценка соответствия по уровням"
(утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2014 г. N 483-ст)

Information technologies. Software asset management. Part 1. Processes and tiered assessment of conformance

ОКС 35.080
П85
ОКСТУ 4090

Дата введения - 1 марта 2015 г.
Введен впервые

Предисловие

1 Подготовлен Закрытым акционерным обществом "Консистент Софтвеа Дистрибушн" на основе перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 Внесен Техническим комитетом по стандартизации ТК 076 "Системы менеджмента"

3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2014 г. N 483-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 19770-1:2012 "Информационные технологии. Менеджмент программных активов. Часть 1. Процессы и оценка соответствия по уровням (ISO/IEC 19770-1:2012 "Information technology - Software asset management - Part 1: Processes and tiered assessment of conformance", IDT).

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

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с требованиями ГОСТ Р 1.5-2012 (пункт 3.5)

5 Введен впервые

6 Переиздание. Январь 2017 г.

Введение

Настоящий стандарт предназначен для организаций, желающих освоить передовой опыт в области менеджмента программных активов (Software Asset Management, SAM). Настоящий стандарт идентичен ИСО/МЭК 19770-1:2012, который разработан на базе ИСО/МЭК 19770-1:2006 "Информационные технологии. Менеджмент программного обеспечения. Часть 1. Процессы" - комплексного стандарта, разработанного для применения ко всему менеджменту услуг, как это описано в ИСО/МЭК 20000.

Опыт применения ИСО/МЭК 19770-1:2006 выявил потребность в поэтапном внедрении, причем такие этапы должны наилучшим образом соответствовать потребностям организации. Настоящий стандарт разработан с целью обеспечения внедрения SAM в соответствии с требованиями настоящего стандарта в рамках любого из этапов наращивания, именуемых далее уровнями (кумулятивными по своей сути). Это позволяет организациям проходить независимую автономную сертификацию, соответствующую естественным уровням развития и приоритетов в управлении. Последующее подтверждение дается таким организациям через возможность публично заявлять о пройденной сертификации на соответствие заявленному уровню.

Разделение на уровни разработано таким образом, чтобы стандартизированные процессы менеджмента программных активов (SAM) были доступны для большинства организаций. Организации, внедряющие SAM впервые, часто могут ускорить этот процесс, тщательно определяя программные активы и части организации, охватываемые SAM. Обычно организация не стремится к достижению всех возможных внутренних целей, целей программного обеспечения и целей организации, описанных в настоящем стандарте в разделе 1 "Цель документа". Организация может определить для себя любую цель, если она является однозначной.

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

На рисунке 1 показаны четыре уровня SAM, определенные в настоящем стандарте. Более полное описание этих уровней приведено в разделе 5 "Уровни". Их можно кратко охарактеризовать следующим образом:

Рисунок 1 - Четыре уровня SAM

Основные связанные преимущества каждого уровня:

Уровень 1: Достоверные данные. Достижение этого уровня означает получение знаний о том, что у вас есть, чтобы уметь управлять этим.

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

Примечание - Другие части ИСО/МЭК 19770 определяют дескриптор идентификации программного обеспечения (см. ИСО/МЭК 19770-2) и дескриптор права на программное обеспечение (см. ИСО/МЭК 19770-3), имеющие целью упростить задачу получения достоверных данных.

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

На практике руководство организации обычно начинает заниматься вопросами, относящимися к SAM, только после того, как будут выявлены проблемы, связанные с недостоверностью данных. Организация выясняет степень подверженности рискам, а также потенциал для усовершенствований и экономии. Этот уровень охватывает базовую среду административного управления (см. 4.2 "Контрольная среда SAM"), включая политики, роли и обязанности. На этом уровне также определяются цели и достигаются немедленные преимущества (за счет использования данных уровня 1).

Уровень 3: Операционная интеграция. Достижение этого уровня означает повышение эффективности и результативности.

Этот уровень, основываясь на результатах, полученных на двух предыдущих уровнях, интегрирует процессы SAM в операционные процессы (см. 4.6 "Процессы и интерфейсы управления операциями SAM"). В результате повышается эффективность и результативность.

Примечание - Другие части ИСО/МЭК 19770 определяют дескриптор идентификации программного обеспечения (см. ИСО/МЭК 19770-2) и дескриптор права на программное обеспечение (см. ИСО/МЭК 19770-3), имеющие целью упростить задачу интеграции.

Уровень 4: Полное соответствие настоящего стандарта SAM. Достижение этого уровня означает достижение лучшего в своем классе стратегического SAM.

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

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

Уровни формируются один над другим, причем уровень 4 определяется как полный набор групп процессов и результатов, определенных в настоящем стандарте. Следует обратить внимание, что группы процессов и результаты, определенные в настоящем стандарте, если сравнивать их с ИСО/МЭК 19770-1:2006, практически не изменились, не считая некоторых незначительных разъяснений. Также в целом сохранена структура целей групп процессов, устанавливающих множество результатов, после чего может быть установлено соответствие любому конкретному уровню. Несмотря на то, что любой из уровней можно сертифицировать по отдельности, все они рассчитаны на то, что все предыдущие уровни в любое время остаются функциональными. На практике это обычно означает, что в организации, претендующей на сертификацию более высокого уровня, аудитор при регулярной проверке любого предыдущего уровня или уровней также осуществит проверку более высокого уровня.

Более подробное описание уровней и их структуры приведено в разделе 5.

Общие преимущества SAM:

a) управление рисками: например, минимизация степени воздействия прерываний или снижения качества работы ИТ/служб; снижение юридических и регуляторных рисков;

b) контроль затрат: снижение прямых затрат на программное обеспечение и связанные активы (см. описание связанных активов в 1.2), контроль затрат, связанных с постоянной поддержкой, контроль контрактных издержек;

c) конкурентное преимущество: лучшие бизнес-решения и чувство удовлетворения от наличия постоянно доступных достоверных данных.

Обычно бизнес-требования относятся к приоритетным областям, например к конкретным производителям программного обеспечения, а иногда к конкретным группам организационных подразделений. Правильно выбрав уровни и соответствующим образом определив масштабы, организации получат преимущества от использования стандартизированных процессов SAM, описанные в настоящем стандарте в разделе 1 "Цель документа".

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

1 Общие положения

1.1 Цель документа

Настоящий стандарт определяет основу комплексного набора процессов менеджмента программных активов (Software Asset Management, SAM), разделенного на уровни, предусматривающие поэтапное внедрение, оценку и утверждение процессов SAM.

1.2 Область применения

Настоящий стандарт применяется к процессам SAM и может использоваться организациями для получения немедленных преимуществ. ИСО/МЭК 19770-2 определяет соответствующую спецификацию дескрипторов идентификации программного обеспечения. Для получения всех преимуществ данная спецификация должна быть внедрена производителями программного обеспечения (внешними и внутренними) и разработчиками инструментальных средств.

Предполагается, что настоящий стандарт станет стандартом внедрения для организаций. В последующих редакциях могут быть предусмотрены инструменты измерений, согласованные с требованиями ИСО/МЭК 15504-2:2003 или ИСО/МЭК 33003 ^*.

------------------------------

^*_{ИСО/МЭК 33003 Системное проектирование и разработка программного обеспечения. Требования к инфраструктуре измерения процессов.}

------------------------------

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

Примечание - Определение организационной области применения документируется в разделе "Процесс корпоративного управления SAM" (4.2.2).

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

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

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

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

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

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

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

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

c) носители, содержащие программное обеспечение для использования.

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

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

Таблица 1 - Применение настоящего стандарта к активам, не являющимся программным обеспечением

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

1.3 Ограничения

Настоящий стандарт не оговаривает методы или процедуры SAM, необходимые для удовлетворения требований к результатам процесса.

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

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

Сведения о процессах сертификации и оформления официального подтверждения находятся вне области действия настоящего стандарта.

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

2 Соответствие требованиям

2.1 Предусмотренное использование

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

При написании настоящего стандарта была сохранена преемственность ИСО/МЭК 19770-1:2006 с добавлением того, что оценка может осуществляться с применением того же подхода, который используется в других стандартах, принятых в качестве основных стандартов систем управления, как это определено в Руководстве ИСО 72. В частности, это означает, что аудитору теперь предоставлена возможность выбирать между оценкой на основе анализа главной цели каждой из групп процессов (по-новому) и оценкой на основе анализа всех результатов каждой из групп процессов, как это предусмотрено ИСО/МЭК 19770-1:2006 (по-старому). Сделанный выбор должен последовательно применяться в качестве метода оценки во всех группах процессов.

2.2 Методы демонстрации полного соответствия

Описание требований, предъявляемых настоящим стандартом, содержится в целях и результатах, перечисленных в разделе 4. Любое заявление о соответствии должно быть заявлением о полном соответствии условиям данного стандарта (в том числе это касается любых процессов, переданных на субподряд).

Полное соответствие любому уровню настоящего стандарта достигается одним из двух способов:

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

- посредством демонстрации достижения всех целей соответствующего уровня настоящего стандарта.

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

Если в процессе демонстрации достижений всех целей соответствующего уровня, определенного в настоящем стандарте, было подтверждено полное соответствие, выдвигаются два дальнейших требования:

- если группа процессов имеет результаты на различных уровнях, то цель такой группы процессов должна соответственно интерпретироваться при проведении аудита каждого уровня;

- помимо анализа подтверждений, демонстрирующих достижение всех целей, аудитор должен учитывать оговоренные результаты на соответствующем уровне.

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

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

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 базовые показатели: Состояние услуги или отдельных элементов конфигурации (3.2) в конкретный момент времени [ИСО/МЭК 20000-1:2005].

3.2 элемент конфигурации (ЭК): Компонент инфраструктуры или объект, который находится или будет находиться под контролем.

Примечания

1 В контексте настоящего стандарта термин "под контролем" означает под контролем процессов инвентаризации. Процессы инвентаризации SAM (4.4) являются основой не только SAM, но и всего управления конфигурациями.

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

3.3 правление или эквивалентный орган: Лицо или группа лиц, несущих юридическую ответственность за руководство или управление организацией на высшем уровне.

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

Пример - Источник, используемый для создания экземпляров для распространения.

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

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

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

Примечания

1 Действующая лицензия состоит из одной или более составляющих лицензий (3.16).

Пример - В некоторых типах лицензирования составляющая полная лицензия для версии 1 программного продукта плюс составляющая лицензия на обновление программного продукта до версии 2 объединяются и составляют одну действующую полную лицензию для версии 2 программного продукта. В данном примере права на обновление лицензии могут быть получены в соответствии с условиями контракта на предоставление услуг поддержки или по подписке.

2 Термин "полное использование программного обеспечения" определяется в условиях использования лицензии(ий).

3.7 локальный владелец процессов SAM: Физическое лицо на любом уровне организации, располагающееся ниже уровня владельца процессов SAM (3.13), определяемое как лицо, ответственное за процессы SAM в определенной части организации.

3.8 персонал: Любое физическое лицо, выполняющее обязанности по поручению организации, в том числе должностные лица, работники и подрядчики.

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

Примечание - Платформа - не одно и то же, что отдельно взятые экземпляры этой платформы, которые именуются "устройства" или "экземпляры".

3.10 процедура: Определенный способ выполнения действия или процесса.

Примечание - Если процедура определена как результат, то в итоговом документе должно быть указано, кто, что и в какой последовательности ее выполняет. Процедура имеет более детальный уровень описания, чем процесс (3.11).

3.11 процесс: Набор взаимосвязанных операций, с помощью которых исходные данные преобразуются в выходные данные.

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

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

[ИСО/МЭК 20000-1:2005]

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

3.13 владелец процессов SAM: Физическое лицо на высшем уровне руководства организации, определенное как лицо, ответственное за процессы SAM.

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

Примечания

1 Имеется множество определений используемого программного обеспечения. В контексте настоящего стандарта в программное обеспечение важно включать как исполняемое, так и неисполняемое программное обеспечение, например шрифты, графику, аудио- и видеозаписи, шаблоны, словари и документы. (См. также 1.2 "Область применения").

2 Пользователь настоящего стандарта должен определить собственную область действия для своего приложения, и может ограничить типы программного обеспечения, учитываемые в области действия. (См. также раздел 1 "Цель документа").

[ИСО/МЭК 2382-1:1993, 01.01.08]

3.15 менеджмент программных активов (SAM): Эффективное управление, контроль и защита программных активов в масштабах организации и эффективное управление, контроль и защита информации о связанных активах, необходимых для управления программными активами.

Примечание - Соответствующее определение в Библиотеке инфраструктуры информационных технологий (InformationTechnologylnfrastructureLibrary, ITIL) - "вся инфраструктура и процессы, необходимые для эффективного управления, контроля и защиты программных активов в пределах организации на протяжении всех стадий ее жизненного цикла".

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

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

4 Процессы SAM

4.1 Общие положения

4.1.1 Определение и отношение к менеджменту услуг

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

Процессы SAM, в соответствии с их определением в настоящем стандарте, согласованы и предназначены для поддержки менеджмента ИТ-услуг, в соответствии с определением стандарта ИСО/МЭК 20000-1.

4.1.2 Обзор процессов SAM

Концептуальная основа процессов SAM имеет комплексный характер и сама по себе не отражает уровни, описанные во введении или в разделе 5 "Уровни".

Концепция процессов SAM структурирована по трем основным категориям:

a) процессы организационного управления SAM;

b) базовые процессы SAM;

c) первичные интерфейсы процессов SAM.

Структура процессов SAM с разбивкой по трем основным категориям приведена на рисунке 2.

Рисунок 2 - Структура процессов SAM

Более подробное описание процессов приведено в 4.2-4.7.

4.1.3 Результаты, операции и интерфейсы

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

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

Целостность данных обеспечивается в настоящем стандарте с помощью процессов проверки правильности и соблюдения соответствия SAM.

Некоторые наиболее важные операции представляют собой действия по обеспечению взаимодействия с другими процессами. Например, после приобретения (или "закупки") программного актива цель к достижению формулируется так: "Цель процесса закупки программного обеспечения и связанных активов состоит в обеспечении получения программного обеспечения контролируемым способом и в регистрации этого программного обеспечения". Этот процесс, как и многие другие, требует применения процесса "Управление инвентаризацией программных активов" для регистрации данных, их проверки на наличие обязательных полей и т.п. Другим примером может служить создание базовых показателей в процессе "Контроль программных активов". Этот процесс вызывается процессом "Разработка программного обеспечения" и процессом "Управление релизами программного обеспечения". В настоящем стандарте не ставится цель подробного описания таких деталей, однако для достижения поставленных целей косвенно подразумеваются к наличию таких операций или интерфейсов.

4.2 Контрольная среда SAM

4.2.1 Общие положения

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

Контрольная среда SAM состоит из следующих групп процессов:

a) процесс корпоративного управления SAM;

b) роли и обязанности SAM;

c) политики, процессы и процедуры SAM;

d) компетенции в SAM.

4.2.2 Процесс корпоративного управления SAM

4.2.2.1 Цель

Цель процесса корпоративного управления SAM состоит в обеспечении того, чтобы обязанности по управлению программными активами подтверждались на уровне правления или эквивалентного органа и чтобы для обеспечения надлежащего исполнения этих обязанностей использовались соответствующие механизмы.	Применимо к уровням 2 и 4
Примечание - Этот процесс может рассматриваться как часть общего корпоративного управления ИТ. (См. ИСО/МЭК 38500).

4.2.2.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса корпоративного управления SAM позволит организации продемонстрировать следующее:
а) на корпоративном уровне организации имеется ясное изложение организационной области применения в контексте данного стандарта в отношении: 1) юридического лица или частей юридического лица, включенных в область применения. Примечание - Одним из факторов, которые следует учитывать при определении организационной области применения, может быть наличие контрактов на поставку программного обеспечения, базирующихся на определенных организационных областях; 2) отдельного органа или физического лица, которые несут ответственность за решение всех вопросов корпоративного управления для такого лица или части такого юридического лица. Примечание - Такой отдельный орган или физическое лицо далее именуются "правление" или "эквивалентный орган"
b) ответственность за корпоративное управление программным обеспечением и связанными активами формально подтверждена правлением или эквивалентным органом организации
с) организацией были определены, документированы и не реже одного раза в год пересматриваются корпоративные регулирующие документы или нормативы, относящиеся к использованию программного обеспечения и связанных активов во всех странах, в которых работает организация
d) организацией были определены, задокументированы и утверждены правлением или эквивалентным органом и не реже одного раза в год обновляются результаты оценки рисков, имеющих отношение к программному обеспечению и связанным активам, и определяемые руководством методы их снижения. К таким рискам, как минимум, относятся следующие: 1) риск несоответствия регуляторным документам. Примечание - Эти риски могут возникать, например, вследствие защиты частных данных для контроля использования персоналом программного обеспечения, защиты данных SAM, ведущихся о физических лицах, и выдвижения специализированных требований в отдельных промышленных отраслях, например фармацевтической; 2) риск нарушения требований к безопасности. Примечание - Нарушение требований безопасности может приводить, например, к прерыванию работы, неправомерному использованию конфиденциальной информации конкурентами и репутационному ущербу вследствие недостаточной защиты личных данных клиентов; 3) риск несоблюдения лицензионных требований; 4) риск прерывания деятельности из-за проблем с инфраструктурой ИТ, которые могли быть вызваны неадекватностью SAM; 5) риск чрезмерных расходов на лицензирование и других затрат на поддержку ИТ вследствие неадекватности SAM; 6) риски, связанные с применением разных подходов к управлению программным обеспечением и связанным активам - децентрализованного и централизованного. Примечание - По культурным и экономическим соображениям крайне желательно децентрализовать операционное управление SAM. Однако при таких подходах снижение издержек станет более трудной задачей, связанной с высокими рисками, например риском несоблюдения условий лицензирования (при централизованном подходе к управлению эти риски меньше). Например, любое несоблюдение условий лицензирования в любой децентрализованной работе создает риск угрозы репутации и повышает юридические риски всей организации. Вероятно, было бы разумно даже в децентрализованной среде операционного управления продолжать применять к выборочной информации и аналитическим данным для руководства принципы централизованного управления, что позволит распределенному руководству применять методы SAM без увеличения рисков. Управление централизованной информацией само по себе обычно предполагает некоторый централизованный контроль руководства над SAM; 7) риски, связанные с ведением деятельности в разных странах, учитываются местные культуры соответствия требованиям и подходы к обеспечению исполнения
е) цели управления SAM утверждаются правлением или эквивалентным органом и пересматриваются не реже одного раза в год

4.2.3 Роли и обязанности SAM

4.2.3.1 Цель

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

Применимо к уровню 2

4.2.3.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Роли и обязанности SAM" позволит организации продемонстрировать следующее:
а) в организации четко определена и утверждена правлением или эквивалентным органом роль владельца процессов SAM, ответственного за корпоративное управление программным обеспечением и связанными активами. Возложенные на владельца процессов SAM в масштабе всей организации обязанности включают следующее: 1) предложение целей управления SAM; 2) надзор за разработкой плана SAM; 3) получение ресурсов для реализации утвержденного плана SAM; 4) получение результатов в соответствии с утвержденным планом SAM; 5) обеспечение надлежащего исполнения всеми локальными владельцами процессов SAM своих обязанностей, охват всех частей организации владельцем процессов SAM или локальными владельцами процессов SAM без конфликтующих наложений
b) в организации документированы и назначены конкретным лицам локальные роли и обязанности по корпоративному управлению программного обеспечения и связанными активами. Возложенные обязанности для той части организации, за которую несет ответственность каждое лицо, включают следующее: 1) получение ресурсов для реализации утвержденного плана SAM; 2) получение результатов в соответствии с утвержденным планом SAM; 3) принятие и внедрение необходимых политик, процессов и процедур; 4) ведение точного учета программного обеспечения и связанных активов; 5) обеспечение управления и технических согласований, требуемых для закупки, развертывания и контроля программных активов; 6) управление контрактами, отношениями с поставщиками и внутренними клиентами; 7) определение потребностей в усовершенствованиях и их реализация Примечания 1 Настоящий стандарт проводит различие между владельцем процессов SAM на уровне организации и локальными ролями и обязанностями, поскольку некоторые организации с распределенным местоположением проводят такое различие в своих управленческих ролях. Если организация размещается только в одном месте, или если удаленные места можно считать несущественными, и управление ими осуществляется непосредственно из центрального местоположения, эти два набора функций объединяются друг с другом. 2 Обязанности могут назначаться определенным должностям или классам должностей, при условии, что характер этих обязанностей и ответственность за их выполнение не вызывает сомнений. На практике это означает, что назначать различные обязанности различным физическим лицам, особенно в небольших организациях, где такое разделение обязанностей не практикуется, нет необходимости
с) эти обязанности доводятся до сведения всех связанных с SAM частей организации тем же образом, что и другие политики (уровня организации и локальные)

4.2.4 Политики, процессы и процедуры SAM

4.2.4.1 Цель

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

Применимо к уровню 2

4.2.4.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Политики, процессы и процедуры SAM" позволит организации продемонстрировать следующее:
а) в организации применяется структурированный подход к созданию, анализу, утверждению, выпуску и контролю политик, процессов, процедур и связанной документации, относящихся к SAM, позволяющий в любое время определять полный доступный набор, текущую рабочую версию любого документа и документы, которые должны применяться к различным типам ПО и связанных активов. Примечание - Эта установка относится не только к SAM, обычно она является частью общего подхода, применяемого организацией ко всем своим политикам, процессам и процедурам
b) документация по политикам, процессам и процедурам, описываемая настоящим стандартом, классифицируется в организации по процессам, определенным в настоящем стандарте, или по ссылкам на такие классификации
с) в организации разрабатываются, утверждаются и выпускаются политики, охватывающие, как минимум: 1) индивидуальные и корпоративные обязанности по корпоративному управлению ПО и связанными активами; 2) любые ограничения на персональное использование корпоративного ПО и связанных активов; 3) вопросы соблюдения законодательных и регуляторных требований, в том числе с целью защиты авторских прав и данных; 4) любые требования к закупкам (например, использование корпоративных соглашений или закупки только у авторитетных/утвержденных поставщиков); 5) оформление любых требований на получение утверждений на установку или использование программного обеспечения, как приобретенного, так и полученного иным способом. 6) дисциплинарные последствия нарушения этих политик. Примечание - Перечисленные выше политики должны удовлетворять общим требованиям, в том числе требованиям конечных пользователей. Политики и процедуры, относящиеся к определенным группам процессов, определяются в соответствующих группах процессов
d) политики и процедуры доводятся до сведения всего персонала в организации способом, который позволяет: 1) оповещать всех новых работников после их выхода на работу, и не реже одного раза в год оповещать постоянно работающих работников; 2) получать подтверждение об оповещении от всех новых работников после их выхода на работу, и впоследствии не реже одного раза в год; 3) работникам в любое время получать доступ к политикам и процедурам. Примечание - Документация может вестись в любой форме и на любом носителе. Документация может выпускаться совместно с другими документами, например, могут выпускаться консолидированные заявления о политике, также устанавливающие требования к персоналу относительно конфиденциальности

4.2.5 Компетенции в SAM

4.2.5.1 Цель

Цель процесса "Компетенции в SAM" состоит в обеспечении доступности и применении соответствующей компетенции и опыта в SAM

Применимо к уровням 2 и 4

4.2.5.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Компетенции в SAM" позволит организации продемонстрировать следующее:
а) в организации не реже одного раза в год документируется процесс проверки изменений требований. Проверяется доступность и прохождение обучения и сертификации персонала в сфере обязанностей SAM в отношении: 1) SAM в целом; 2) лицензирования продукции производителей используемого программного обеспечения. Примечание - Это требование относится только к программному обеспечению, определенному как относящееся к области применения (см. 4.2.2.2.а1 и 4.3.2.2.b1)
b) в организации не реже одного раза в год проводится проверка требований к составляющим "Подтверждения лицензии" для производителя программного обеспечения
с) персонал организации, ответственный за управление SAM, ежегодно проходит обучение (включая начальное и дополнительное) в области SAM и соответствующее лицензирование. Примечание - Также, если имеется такая возможность, персоналу рекомендуется повышать квалификацию индивидуально
d) в организации не реже одного раза в год осуществляется проверка наличия дополнительных инструкций производителей программного обеспечения (если таковые имеются) с целью обеспечения соответствия их лицензиям

4.3 Процессы планирования и внедрения SAM

4.3.1 Общие положения

Процессы планирования и внедрения SAM обеспечивают эффективное достижение целей управления SAM.

Процессы в этой области в целом соответствуют процессам "Планируй - выполняй - проверяй - действуй", определенным в ИСО/МЭК 9001.

Процессы планирования и внедрения SAM состоят из следующих групп процессов:

a) планирование SAM;

b) внедрение SAM;

c) мониторинг и проверка SAM;

d) непрерывное совершенствование SAM.

4.3.2 Планирование SAM

4.3.2.1 Цель

Цель процесса "Планирование SAM" состоит в обеспечении адекватной подготовки и планировании для эффективного достижения целей SAM

Применимо к уровням 2 и 4

4.3.2.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Планирование в SAM" позволит организации продемонстрировать следующее:
а) управленческие цели SAM в организации разрабатываются и предлагаются для утверждения правлением или эквивалентным органом и обновляются не реже одного раза в год
b) план реализации и представления SAM (далее - план SAM) разрабатывается, документируется и обновляется не реже одного раза в год. Этот план включает в себя: 1) четкое изложение области применения (однозначно определенной "области применения программного актива"), описывающее, какие типы ПО в нее включены; охват программного обеспечения и связанных активов, например должна быть указана доля складской заполненности в соответствии с последним обновлением плана SAM с указанием фактических и плановых показателей; любой охват активов сверх минимума, требуемого настоящим стандартом; любые методы взаимодействия с другими организациями или системами и/или требования к ним. См. также организационную область применения по 4.2.2.2.а1; 2) четкое определение политик, процессов и процедур, требуемых для использования активов в области применения; 3) четкое разъяснение подхода к управлению, аудиту и усовершенствованию SAM (в том числе с применением методов автоматизации), используемого для поддержания процессов; 4) разъяснение подхода, используемого для идентификации, оценки и управления проблемами и рисками, связанными с достижением установленных целей управления; 5) графики выполнения периодических операций и распределение ответственностей по их выполнению, в том числе подготовка отчетов для руководства и контроль соответствия; 6) определение ресурсов (включая бюджетные ресурсы), необходимых для реализации плана SAM; 7) отслеживание показателей выполнения плана SAM, включая целевые измерения точности записей об управлении активами. Примечание - В плане SAM должен быть предусмотрен адекватный уровень автоматизации, при котором процессы не будут неэффективными или подвержены ошибкам или вообще не смогут выполняться
с) план утвержден правлением или эквивалентным органом организации

4.3.3 Внедрение SAM

4.3.3.1 Цель

Цель процесса "Внедрение SAM" состоит в достижении общих целей SAM и выполнении плана SAM

Применимо к уровню 4

4.3.3.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Внедрение SAM" позволит организации продемонстрировать следующее:
а) в организации имеются механизмы сбора информации, в том числе информации локальных владельцев процессов SAM, об изменениях, проблемах и рисках, воздействующих на план SAM на протяжении года
b) владельцами процессов SAM готовятся регулярные отчеты о состоянии дел (не реже одного раза в квартал), подробно описывающие общий ход выполнения плана SAM, для выдачи отчета правлению или эквивалентному органу организации
с) в организации проводится оперативное отслеживание и документирование любых выявленных расхождений

4.3.4 Мониторинг и проверка SAM

4.3.4.1 Цель

Цель процесса "Мониторинг и проверка SAM" состоит в обеспечении достижения общих целей управления SAM

Применимо к уровням 2 и 4

4.3.4.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Мониторинг и проверка SAM" позволит организации продемонстрировать следующее:
а) в организации не реже одного раза в год проводится формальная проверка с целью: 1) оценки достижений целей управления SAM и выполнения плана SAM; 2) подведения итогов работы по всем производственным показателям, установленным в плане SAM и в соглашениях об уровне обслуживания, относящихся к SAM. Примечание - Соглашения об уровне обслуживания, устанавливающие требования SAM, могут относиться не только к SAM; 3) выдачи сводного изложения результатов процесса "Проверка соответствия SAM"; 4) выдачи на основании вышеизложенного заключения о том, действительно ли: i) утвержденные руководством политики SAM были эффективно распространены по всей организационной области применения, определенной в контексте настоящего стандарта; ii) утвержденные руководством процессы и процедуры SAM были эффективно реализованы во всей организационной области применения, определенной в контексте настоящего стандарта; 5) краткого изложения любых выявленных исключительных ситуаций и действий, которые может понадобиться выполнить в результате вышеизложенного; б) определения возможностей улучшения обслуживания, относящегося к программному обеспечению и связанным активам; 7) определения потребности в пересмотре политик, процессов и процедур в плане обеспечения их постоянной адекватности, полноты и правильности
b) владелец процессов SAM формально утверждает итоговые отчет, документы, решения и меры, и направляет их копии в правление или эквивалентный орган организации
с) в организации проводится периодическая (не реже одного раза в год) проверка того, развернуты ли программное обеспечение и связанные активы наиболее рентабельным способом; и выдаются рекомендации по возможным усовершенствованиям. Примечания 1 Этот процесс, по сути, можно считать процессом оптимизации лицензий. Он должен обеспечить максимальную экономическую эффективность лицензирования. В качестве базового уровня, от которого ведется оптимизация, могут использоваться базовые показатели стоимости активов. Базовый показатель стоимости - это выбранная организацией основа учета стоимости программного обеспечения. Таким показателем может быть, например, базис себестоимости, с помощью которого организация может оценивать изменения со временем и постоянно отслеживать качество оптимизации, например стоимость лицензий. 2 Этот результат, в основном, используется на уровне 4. На уровне 2 результат имеет ограниченное применение, например используется для определения непосредственных возможностей усовершенствования

4.3.5 Непрерывное совершенствование SAM

4.3.5.1 Цель

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

Применимо к уровню 4

4.3.5.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Непрерывное совершенствование SAM" позволит организации продемонстрировать следующее:
а) в организации имеется механизм сбора и учета предложений по усовершенствованию SAM, поступающих из всех источников в течение года
b) в организации регулярно выполняются оценки, классификации и утверждения для включения предложений по усовершенствованию в планы реализации и совершенствования SAM

4.4 Процессы инвентаризации SAM

4.4.1 Общие положения

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

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

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

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

Процессы инвентаризации SAM состоят из следующих групп процессов:

a) идентификация программных активов;

b) управление инвентаризацией программных активов;

c) контроль программных активов.

4.4.2 Идентификация программных активов

4.4.2.1 Цель

Цель процесса "Идентификация программных активов" состоит в отборе, группировании и классификации по соответствующим характеристикам необходимых классов активов, обеспечивающих эффективное управление программным обеспечением и связанными активами

Применимо к уровням 1 и 4

4.4.2.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Идентификация программных активов" позволит организации продемонстрировать следующее:
а) в организации формально определены типы контролируемых активов и связанная с ними информация, характеризуемые следующими особенностями: 1) управляемые позиции выбраны в соответствии с установленными критериями отбора, сгруппированы, классифицированы и идентифицированы, что обеспечит их управляемость и отслеживаемость на протяжении всего жизненного цикла. Примечание - Важные с точки зрения бизнеса и безопасности активы, а также активы высокого риска должны классифицироваться и контролироваться на более детальном уровне; 2) к управляемым позициям относятся: i) все экземпляры устройств или платформ, на которых может устанавливаться или запускаться программное обеспечение; ii) финальные основные версии и экземпляры для распространения программного обеспечения; iii) сборки и релизы программного обеспечения (финальные основные версии и экземпляры для распространения); iv) все установленное программное обеспечение; v) версии программного обеспечения; vi) методология, в соответствии с которой программное обеспечение идентифицируется в области применения. Примечание - Необходимая информация может быть получена из соответствующим образом определенных и отслеживаемых дескрипторов идентификации программного обеспечения, как это определено в других частях настоящего стандарта; vii) патчи и обновления; viii) лицензии, в том числе составляющие лицензии и действующие полные лицензии; ix) документы, доказывающие наличие лицензии ("Подтверждение лицензии"); x) контракты (включая количественные характеристики и условия), имеющие отношение к программным активам, в том числе их бумажные и электронные копии; xi) физические и электронные хранилища и описи вышеуказанного (в зависимости от обстоятельств); xii) модели лицензирования; 3) управление программным обеспечением осуществляется в организации, как по файлам, так и по пакетам, в соответствии с особенностями конкретных продуктов, выпущенных производителями программного обеспечения или разработчиками; 4) Базовая информация для всех активов: i) уникальный идентификатор; ii) имя/описание; iii) расположение; iv) ответственный (или владелец); v) статус (например, тестовый/производственный; разработка/сборка и т.п.); vi) тип (например, программное обеспечение, аппаратное обеспечение, устройство); vii) версия (если имеется). Примечания 1 В рамках данного процесса также могут определяться требования к проверке правильности данных. 2 Эта информация может быть извлечена из соответствующим образом определенного и отслеживаемого дескриптора идентификации программного обеспечения (см. ИСО/МЭК 19770-2);
b) в организации имеется реестр хранилищ и запасов, содержащий сведения о хранимых запасах и типах информации. Дублирование информации такого реестра допускается только в том случае, если дублируемую информацию можно отследить до определенной исходной записи. Примечание - Обычно в этом реестре содержатся следующие типы информации о каждом физическом наборе (хранилище) хранимых активов или списке (инвентарной описи) активов: 1) определенный тип актива SAM; 2) имя лица, отвечающего за управление этой информацией; 3) место, в котором можно получить доступ к такому хранилищу или инвентарной описи

4.4.3 Управление инвентаризацией программных активов

4.4.3.1 Цель

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

Применимо к уровням 1 и 4

4.4.3.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Управление инвентаризацией программных активов" позволит организации продемонстрировать следующее:
а) организацией разработаны, утверждены и выпущены политики и процедуры, относящиеся к управлению и обслуживанию физических/электронных хранилищ, в том числе имеются средства контроля доступа: 1) защищающие их от несанкционированного доступа, изменений или повреждений; 2) обеспечивающие аварийное восстановление после отказа
b) в организации имеются инвентарные описи: 1) всех экземпляров устройств или платформ, на которых могут устанавливаться или запускаться программные активы; 2) всего разрешенного установленного программного обеспечения с указанием пакетов и версий (которые могут быть лицензированы или разрешены к развертыванию по отдельности, статуса обновлений/патчей программного обеспечения по всем платформам, на которых они установлены. Примечание - Инвентарная опись программного обеспечения, разрешенного для установки (или использования), является важным документом, однозначно устанавливающим тот факт, что программное обеспечение разрешено к установке, и определяющим, может ли какой-либо конкретный экземпляр платформы/устройства использовать программное обеспечение или разрешать его установку. Разрешение может выдаваться на любом уровне, например на уровне устройства, класса пользователя или всей организации; 3) имеющихся составляющих лицензий и действующих полных лицензий. Примечание - Ведение отдельных инвентарных описей для составляющих и действующих полных лицензий не требуется, однако должна быть предусмотрена возможность различения этих двух типов
с) в организации имеются инвентарные описи и соответствующие физические/электронные хранилища:
1) программного обеспечения (финальных основных версий и экземпляров для распространения);
2) сборок и релизов программного обеспечения (финальных основных версий и экземпляров для распространения);
3) контрактов, имеющих отношение к программным активам, как бумажных, так и электронных;
4) документов, доказывающих наличие лицензии ("Подтверждение лицензии")
d) в организации имеются инвентарные описи или другие четко определенные механизмы анализа или отслеживания количественных показателей, позволяющие определить любое лицензированное использование на базе других критериев, помимо количества установленного программного обеспечения. Примечание - Эти требования будут зависеть от моделей лицензирования используемого программного обеспечения. Например, они могут включать следующие количественные показатели: численность работников в указанных частях организации; количество ПК, удовлетворяющих указанным критериям; количество пользователей или оконечных станций, имеющих доступ к ресурсам сервера; количество процессоров и их производительные характеристики
е) организацией приняты меры, направленные на обеспечение постоянной доступности источников упомянутых выше инвентарных описей и хранилищ
f) все представленные инвентарные отчеты составлены в соответствии с четкой описательной схемой, в том числе содержат наименование, предназначение и подробные сведения об источнике данных

4.4.4 Контроль программных активов

4.4.4.1 Цель

Цель процесса "Контроль программных активов" состоит в обеспечении механизма контроля программных активов и изменений программного обеспечения и связанных активов в процессе учета изменений статуса и утверждений

Применимо к уровню 4

4.4.4.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Контроль программных активов" позволит организации продемонстрировать следующее:
а) организацией ведется журнал учета изменений, внесенных в программное обеспечение и связанные активы, в том числе изменений статуса, расположения, ответственности и версий
b) организацией разработаны, утверждены и выпущены политики и процедуры для разработки, обслуживания и управления версиями программного обеспечения, образами/сборками и релизами
с) организацией разработаны, утверждены и выпущены политики и процедуры, устанавливающие требования учета базовых показателей соответствующих активов перед выпуском программного обеспечения в производственную среду, причем таким образом, чтобы эти показатели могли использоваться при последующей сверке с фактическим развертыванием

4.5 Процессы проверки правильности и соблюдения соответствия SAM

4.5.1 Общие положения

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

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

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

a) проверка правильности записей о программных активах;

b) соответствие лицензии на ПО;

c) проверка соответствия требованиям безопасности программных активов;

d) проверка соответствия SAM.

4.5.2 Проверка правильности записей о программных активах

4.5.2.1 Цель

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

Применимо к уровням 1, 2 и 4

4.5.2.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Проверка правильности записей о программных активах" позволит организации продемонстрировать следующее:
а) организацией разработаны, утверждены и выпущены процедуры для процесса "Проверка правильности записей о программных активах", характеризуемые следующими особенностями:
1) при любом определении или изменении области применения проверяется допустимость этой области применения посредством анализа контракта и истории закупок, с целью обеспечения соответствия организационных целей и областей применения программного обеспечения бизнес-требованиям. Примечание - Например, такой анализ необходим в тех случаях, когда в область применения включается другой производитель программного обеспечения, или при слиянии или разделении организации в соответствии со стандартом, или при перераспределении прав собственности между производителями программного обеспечения;
2) не реже одного раза в квартал проводится сверка того, что установлено на каждом экземпляре устройства или платформы, с тем, что было разрешено для установки, включая выпуск отчетов об исключительных ситуациях, выявленных по результатам текущей сверки, и об изменениях, внесенных со времени предыдущей сверки. Примечание - Некоторые изменения могут обуславливаться обновлениями методики, посредством которой идентифицируется программное обеспечение (например, обновленные файлы подписи, в результате чего продукт, ранее учитываемый как отдельное приложение, теперь корректно идентифицируется как часть пакета);
3) не реже одного раза в 6 мес проверяется инвентарная опись аппаратного обеспечения (а также его размещения), в том числе выпускаются отчеты о выявленных исключительных ситуациях;
4) не реже одного раза в 6 мес проверяется инвентарная опись программ (финальных основных версий и экземпляров для распространения), в том числе выпускаются отчеты о выявленных исключительных ситуациях;
5) не реже одного раза в 6 мес. проверяется инвентарная опись программных сборок (оригиналы и экземпляры для распространения), в том числе выпускаются отчеты о выявленных исключительных ситуациях;
6) не реже одного раза в год проверяется физическое хранилище документов, доказывающих наличие лицензии ("Подтверждение лицензии") (включая проверку документации на аутентичность), в том числе выпускаются отчеты о выявленных исключительных ситуациях;
7) не реже одного раза в год пересматриваются основания и расчеты по действующим лицензиям из составляющих лицензий, с целью подтверждения наличия необходимых составляющих лицензий и исключения дублирования учета;
8) не реже одного раза в год осуществляется проверка целостности физического хранилища контрактной документации, имеющей отношение к программному обеспечению, в том числе выпускаются отчеты о выявленных исключительных ситуациях;
9) не реже одного раза в год проверяется инвентарная опись контрактов, в том числе выпускаются отчеты о выявленных исключительных ситуациях;
10) проводится периодическая проверка прошлых счетов-фактур с целью выявления неверно оформленных счетов и переплат. Примечание - Это действие, в принципе, можно отнести к процессу проверки соответствия, однако оно имеет более расширительный и формальный смысл, чем это оговорено в процессе проверки соответствия;
11) при выявлении любых расхождений или возникновении описанных выше проблем выполняются и документируются последующие корректирующие действия. Примечание - По мере того как на последующих уровнях вводятся новые проверки, для такого уровня должны демонстрироваться новые последующие мероприятия

4.5.3 Проверка соответствия лицензирования программного обеспечения

4.5.3.1 Цель

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

Применимо к уровню 1

4.5.3.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Проверка соответствия лицензирования программного обеспечения" позволит организации продемонстрировать следующее:
а) организацией разработаны, утверждены и выпущены процедуры для процесса "Проверка соответствия лицензирования программного обеспечения", характеризуемые следующими особенностями: 1) не реже одного раза в квартал проводится сверка действующих приобретенных лицензий и лицензий, требуемых для используемого программного обеспечения, с учетом определения лицензионных требований в соответствии с условиями лицензии. Примечания 1 В частности, сюда относятся лицензионные требования, не связанные с количеством установленных копий, например права на доступ к серверу. 2 Ежеквартальный цикл сверки, по сути, представляет собой процесс анализа и расчета, использующий количественные характеристики требуемых лицензий, количественные параметры инвентарных описей и количество документированных установок для расчета того или иного количества лицензий. Предполагается, что условия пересматриваются не реже одного раза в год (с последующими проверками в течение трех месяцев, если выяснится необходимость принятия новых мер или применения новых моделей лицензирования, или если будет изменена область применения, или если производитель особо оговорит изменения условий лицензирования); 2) расхождения, выявленные в ходе этой сверки, немедленно регистрируются, анализируются, и определяется их первопричина; 3) устанавливается очередность исполнения, и принимаются корректирующие меры

4.5.4 Проверка соответствия требованиям безопасности программных активов

4.5.4.1 Цель

Цель процесса "Проверка соответствия требованиям безопасности программных активов" состоит в обеспечении требований к безопасности, имеющих отношение к использованию программного обеспечения и связанных активов

Применимо к уровню 3

4.5.4.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Проверка соответствия требованиям безопасности программных активов" позволит организации продемонстрировать следующее:
а) в организации не реже одного раза в год проводится анализ фактической практики с целью выявления исключительных ситуаций в политике безопасности. В ходе этой проверки должен проводиться анализ средств контроля доступа к финальным основным версиям и экземплярам для распространения программного обеспечения, а также прав на установку и/или использование, указанных пользователем или группой пользователей
b) в организации принимаются документированные меры по любым выявленным при таком анализе расхождениям

4.5.5 Проверка соответствия SAM

4.5.5.1 Цель

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

На всех уровнях для требований этого уровня

4.5.5.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Проверка соответствия SAM" позволит организации продемонстрировать следующее:
а) организацией разработаны, утверждены и выпущены политики и процедуры для проверки соответствия данному уровню (уровням) настоящего стандарта, обеспечивающие такую проверку не реже одного раза в год на основе выборки всех требований, оговоренных для соответствующего уровня(ей) настоящего стандарта. В частности выполняется проверка того, что процедуры, реализованные организацией для других процессов SAM, удовлетворяют всем требованиям, описанным в настоящем стандарте для таких процедур
b) в организации имеются письменные подтверждения выполнения указанных выше процедур проверки и выполнения последующих корректирующих мер вплоть до успешного устранения причин всех выявленных исключительных ситуаций

4.6 Процессы и интерфейсы управления операциями SAM

4.6.1 Общие положения

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

Процессы и интерфейсы управления операциями SAM состоят из следующих групп процессов:

a) управление отношениями и контрактами SAM;

b) управление финансами SAM;

c) управление уровнями обслуживания SAM;

d) управление безопасностью SAM.

4.6.2 Управление отношениями и контрактами SAM

4.6.2.1 Цель

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

Применимо к уровням 2, 3 и 4

4.6.2.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Управление отношениями и контрактами SAM" позволит организации продемонстрировать следующее:
а) организацией разработаны, утверждены и выпущены политики и процедуры для управления отношениями с поставщиками, поставляющими программное обеспечение и связанные с ним активы и услуги, характеризуемые следующими особенностями: 1) определены обязанности конкретных назначенных лиц по управлению поставщиками, с целью получения полной картины ответственности по управлению каждым поставщиком; 2) разрабатываются приглашения на участие в тендерах на поставку программного обеспечения или связанных услуг, с целью обеспечения учета процессом требований к SAM, в том числе требований к управлению уровнями обслуживания, средствам контроля безопасности, управлению версиями и изменениями; 3) выпускаются официальные отчеты (не реже одного раза в 6 мес) о работе поставщиков, их достижениях и проблемах с документально зафиксированными выводами и решениями о принятии любых необходимых мер
b) организацией разработаны, утверждены и выпущены политики и процедуры для управления отношениями на стороне клиентов, в частности включающие: 1) определение обязанностей по управлению деловыми отношениями на стороне клиентов в отношении программного обеспечения и связанных с ним активов и услуг; 2) формальный анализ (проводимый не реже одного раза в год) текущих и будущих программных требований клиентов и организации в целом; 3) формальный анализ (проводимый не реже одного раза в год) показателей эффективности работы поставщиков, степени удовлетворенности клиентов, достижений и проблем с документально зафиксированными выводами и решениями о принятии любых необходимых мер
с) организацией разработаны, утверждены и выпущены политики и процедуры для управления контрактами, в частности предусматривающие:
1) непрерывную регистрацию в системе управления контрактами сведений о контрактах по мере их подписания. Примечание - Система управления контрактами представляет собой фирменное руководство или электронную систему, позволяющую управлять контрактами и контролировать их выполнение;
2) надежное хранение экземпляров всей подписанной контрактной документации, а также всех их копий в системе управления документами. Примечание - В системе управления документами также могут храниться условия, принятые в электронной форме (если установлено стороннее программное обеспечение);
3) документированный анализ (не реже одного раза в 6 мес, а также перед истечением срока действия) всех контрактов на поставку и обслуживание программного обеспечения и связанных активов и услуг с документально зафиксированными выводами и решениями о принятии любых необходимых мер. Примечание - Этот результат, в основном, применяется на уровне 3. На уровне 2 этот результат используется реже и позволяет определять непосредственные возможности усовершенствования (например, при обслуживании неиспользуемого программного обеспечения), а также возможности достижения более качественных договоренностей о закупках

4.6.3 Финансовое управление SAM

4.6.3.1 Цель

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

Применимо к уровням 2 и 3

4.6.3.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Финансовое управление SAM" позволит организации продемонстрировать следующее:
а) организация согласовала с соответствующими сторонами и документировала по типам активов определения финансовой информации, относящейся к управлению программным обеспечением и связанными активами. Примечания 1 Финансовая классификация затрат, имеющих отношение к программному обеспечению и связанным активам, является важной частью процесса "Финансовое управление SAM". Типы активов, используемые в финансовом управлении, должны быть согласованы с типами активов в SAM или быть сопоставлены с ними (при наличии различий). 2 Требования к данным для типов активов формально определены для уровня 4. Эти требования будут распространены на уровни 1-3. (См. пункт 4.4.2 "Идентификация программных активов")
b) организацией разработаны официальные бюджеты на приобретение программных активов (внешних или внутренних) и определены связанные затраты на поддержку и обслуживание инфраструктуры
с) организацией учтены в бюджете фактические расходы на программные активы и затраты на поддержку и обслуживание инфраструктуры
d) в организации имеются средства оперативного доступа к четко документированной финансовой информации о стоимости программных активов (в том числе к данным о первоначальной и амортизированной стоимости)
е) в организации проводится формально документированная сверка (не реже одного раза в квартал) фактических расходов с бюджетными показателями с документально зафиксированными выводами и решениями о принятии любых необходимых мер
f) в организации проводится оптимизационный анализ лицензий, заключающийся в анализе рентабельности затрат на лицензирование, по результатам которого выдаются рекомендации по улучшению. Примечания 1 Например, малоценное бизнес-приложение (к примеру, утилита для работы со справочником персонала, требующая приобретения дорогих лицензий для каждого пользователя) можно заменить на альтернативное менее дорогое приложение, обеспечивающее достижение той же коммерческой цели. 2 Этот результат, в основном, применяется на уровне 3. На уровне 2 результат применяется реже и служит для определения и документирования непосредственных возможностей улучшения. Оценки уровней исходят из этой основы

4.6.4 Управление уровнями обслуживания SAM

4.6.4.1 Цель

Цель процесса "Управление уровнями обслуживания SAM" состоит в определении, регистрировании и управлении уровнями обслуживания, имеющими отношение к SAM

Применимо к уровню 3

4.6.4.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Управление уровнями обслуживания SAM" позволит организации продемонстрировать следующее:
а) для услуг, предоставляемых в рамках SAM, организацией разработаны и утверждены соглашения об уровне обслуживания и вспомогательные соглашения. В таких соглашениях об уровне обслуживания оговариваются: 1) определенные и согласованные с соответствующими сторонами услуги, относящиеся к приобретению, установке, перемещению и изменению программных и связанных активов (вместе с целевыми показателями уровня обслуживания и характеристиками рабочей нагрузки); 2) обязательства и обязанности потребителей и пользователей в отношении SAM, или на них дается ссылка. Примечание - Соглашения об уровне обслуживания, устанавливающие требования SAM, могут относиться не только к SAM
b) регулярно (не реже одного раза в квартал) в организации оцениваются фактические рабочие нагрузки и уровни обслуживания в сравнении с целевыми показателями и документируются причины несоответствия целевым показателям SAM
с) соответствующими сторонами проводится регулярный (не реже одного раза в квартал) анализ показателей и их сравнение с уровнями обслуживания SAM с документально зафиксированными выводами и решениями о принятии любых необходимых мер

4.6.5 Управление безопасностью SAM

4.6.5.1 Цель

Цель процесса "Управление безопасностью SAM" состоит в эффективном управлении безопасностью информации в рамках всех операций SAM и обеспечение требований к согласованиям, касающихся SAM. Примечание - ИСО/МЭК 27001 содержит руководство по управлению информационной безопасностью. Организации, сертифицированные в соответствии с ИСО/МЭК 27001-1:2005, обычно удовлетворяют требованиям к безопасности, установленным в настоящем стандарте

Применимо к уровню 4

4.6.5.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса "Управление безопасностью SAM" позволит организации продемонстрировать следующее:
а) организацией разработана и утверждена формальная политика безопасности/ограничения доступа ко всем ресурсам SAM, в том числе к физическим и/или электронным хранилищам программного обеспечения, сборок и релизов программного обеспечения. Примечание - Переход на полное соответствие требует более активного управления правами доступа ко всем ресурсам SAM, в том числе к документам и инвентарным описям (требования уровня 3 удовлетворяются посредством регулярных проверок средств контроля доступа. Результаты см. в пункте 4.5.4, перечисления а) и b) "Проверка соответствия требованиям безопасности программных активов"
b) организацией определены физические и логические средства контроля доступа с целью обеспечения требований политик SAM
с) организация имеет документальные подтверждения практического внедрения этих средств контроля доступа.

4.7 Интерфейсы процессов жизненного цикла SAM

4.7.1 Общие положения

Интерфейсы процессов жизненного цикла SAM в целом соответствуют основным процессам жизненного цикла стандарта ИСО/МЭК 12207 в применении к SAM, а также стандарта ИСО/МЭК 20000. В настоящем стандарте определяются требования SAM к таким процессам жизненного цикла.

Интерфейсы процессов жизненного цикла SAM состоят из требований к следующим группам процессов жизненного цикла:

a) процесс управления изменениями;

b) процесс закупок;

c) процесс разработки программного обеспечения;

d) процесс управления релизами программного обеспечения;

e) процесс развертывания программного обеспечения;

f) процесс управления инцидентами;

g) процесс управления проблемами;

h) процесс списания.

4.7.2 Процесс управления изменениями

4.7.2.1 Цель

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

Применимо к уровню 4

4.7.2.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса управления изменениями позволит организации продемонстрировать следующее:
а) в организации имеется формальный процесс управления изменениями, характеризуемый следующими особенностями: 1) идентифицируются и регистрируются все запросы на внесение изменений, оказывающих влияние на программное обеспечение или связанные активы, услуги или процессы SAM; 2) запросы на внесение изменений, оказывающих влияние на программное обеспечение или связанные активы, услуги или процессы SAM, оцениваются на предмет их возможного воздействия, классифицируются и утверждаются ответственным руководством; 3) процесс реализации утвержденного запроса на внесение изменений выполняется только при условии получения утверждения; 4) регистрируются все изменения, оказывающие влияние на программное обеспечение или связанные активы, услуги или процессы SAM; 5) регистрируются и периодически анализируются успешные или неуспешные попытки таких изменений

4.7.3 Процесс закупок

4.7.3.1 Цель

Цель процесса закупок состоит в обеспечении контролируемого приобретения программного обеспечения и связанных активов и их надлежащем учете

Применимо к уровню 3

4.7.3.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса закупок позволит организации продемонстрировать следующее:
а) организацией определены стандартные архитектуры предоставления программных услуг, а также критерии отклонения от таких стандартов
b) организацией определены стандартные конфигурации программного обеспечения, а также критерии отклонения от таких стандартов
с) организацией разработаны, надлежащим образом утверждены и выпущены политики и процедуры для подачи заявок и заказа программных и связанных активов, в том числе: 1) способ указания требований; 2) необходимые утверждения руководства и технические согласования; 3) использование и/или повторное развертывание существующих лицензий (при их наличии). Примечание - Организация может выбрать для себя удобный метод определения наличия свободных лицензий для развертывания. В зависимости от того, как именно организация реализует управление программными активами, этот метод может меняться. Например, программное обеспечение может быть утверждено для установки, но пока не установлено. Чтобы избежать риска повторного использования одних и тех же лицензий, перед повторным развертыванием лицензий может потребоваться проверка полномочий и анализ операций по текущему развертыванию; 4) учет требований к будущим закупкам в тех случаях, когда программное обеспечение может быть развернуто до оформления отчетности и совершения оплаты
d) организацией разработаны, надлежащим образом утверждены и выпущены политики и процедуры обработки доходов, имеющих отношение к программному обеспечению и связанным активам, в том числе: 1) политики и процедуры обработки счетов, включая сверку с заказами, и сохранения копий для управления лицензиями; 2) политики и процедуры обеспечения получения и надежного хранения подтверждений лицензии по всем приобретенным лицензиям. Примечание - При этом может потребоваться проверка подлинности документов, доказывающих наличие лицензии (не контрафактная ли лицензия), особенно если подтверждения лицензии получены не непосредственно от производителя программного обеспечения; 3) обработка поступающих носителей, в том числе проверка, учет и надлежащее хранение содержимого (физических носителей и электронных копий)

4.7.4 Процесс разработки программного обеспечения

4.7.4.1 Цель

Цель процесса разработки программного обеспечения состоит в обеспечении разработки программного обеспечения с учетом требований SAM. Примечания 1 Настоящий стандарт обычно не применяется к разработке программного обеспечения в целях разработки и ведения исходного кода или иных разрабатываемых компонентов. Настоящий стандарт предназначен для применения ко всему программному обеспечению, используемому для работы в этих средах разработки, для перехода к производственной среде, а также для выполнения таких начальных работ, как настройка программного обеспечения и создание и контроль производственных сборок и релизов. Граница между тем, что считается исходным программным обеспечением для чистой разработки (таким образом исключаемым из рассмотрения), и программным обеспечением для использования (таким образом включаемым в рассмотрение) может определяться как часть формального определения области применения. 2 Программное обеспечение, используемое для разработки другого программного обеспечения, считается программным обеспечением для использования, другими словами, программное обеспечение, используемое разработчиками программного обеспечения, само должно быть под контролем.

Применимо к уровню 4

4.7.4.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса разработки программного обеспечения позволит организации продемонстрировать следующее:
а) в организации имеется формальный процесс разработки программного обеспечения, обеспечивающий учет: 1) стандартных архитектур и стандартных конфигураций; 2) лицензионных ограничений и зависимостей
b) в организации имеется формальный процесс разработки программного обеспечения, в соответствии с которым программные продукты проходят программный контроль до того, как будут внедрены в производственную среду

4.7.5 Процесс управления релизами программного обеспечения

4.7.5.1 Цель

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

Применимо к уровню 4

4.7.5.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса управления релизами программного обеспечения позволит организации продемонстрировать следующее:
а) в организации имеется формальный процесс управления релизами программного обеспечения, характеризуемый следующими особенностями: 1) использование контролируемой среды приемки для создания и тестирования всех предлагаемых релизов, включая патчи, до релиза. Примечание - Настоящий стандарт не определяет подробные требования к созданию или тестированию. В частности, он не требует повторного создания и независимого тестирования всех сборок, требующих установки патчей производителя. Между тем, организация может потребовать этого независимо от требований настоящего стандарта. Тем не менее, обычно предполагается, что любое изменение или исправление будет протестировано перед развертыванием; 2) периодичность и тип релизов, в том числе периодичность выпусков патчей безопасности, планируются и согласовываются с бизнесом и клиентами; 3) плановые даты релизов и получаемые результаты регистрируются со ссылкой на связанные запросы на внесение изменений и проблемы и передаются в процесс управления инцидентами; 4) релизы программного обеспечения и связанных активов утверждаются ответственным руководством; 5) успешные или неуспешные релизы регистрируются и периодически анализируются

4.7.6 Процесс развертывания программного обеспечения

4.7.6.1 Цель

Цель процесса развертывания программного обеспечения применительно к SAM и связанным активам состоит в обеспечении развертывания и повторного развертывания программного обеспечения с учетом требований SAM

Применимо к уровню 3

4.7.6.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса развертывания программного обеспечения позволит организации продемонстрировать следующее:
а) организацией разработаны, утверждены и выпущены политики и процедуры для развертывания программного обеспечения, характеризуемые следующими особенностями: 1) любой новый экземпляр для распространения программного обеспечения и связанных активов утверждается ответственным руководством; 2) для любого развертывания существует процедура отката или метод исправления, если развертывание окажется неуспешным; 3) соблюдены требования к безопасности, в том числе в отношении доступа к программному обеспечению в процессе развертывания и после его установки; 4) все изменения статуса соответствующего программного обеспечения и связанных активов тщательно и своевременно регистрируются (в том числе любые изменения статуса хранения активов), и ведется журнал учета таких изменений. Примечание - Регистрировать каждое отдельно вносимое изменение не требуется. Важно определить все допустимые статусы, используемые для записи всех шагов развертывания, а затем убедиться в том, что любые изменения статусов будут фиксироваться. Обычно изменения статуса могут быть связаны с осуществлением полномочий на закупки (общих полномочий, полномочий для поименованных групп или отдельных лиц), полномочий на выпуск (в рамках сборки), полномочий на развертывание/удаление (общих, а также для поименованных групп или отдельных лиц), а также полномочий на фактическое развертывание/установку/удаление; 5) для проверки того, что развертывание было выполнено в точном соответствии с тем, что было разрешено, осуществляется документированный контроль. При выявленном несоответствии (или если не удалось проверить, что актив был развернут в рамках разрешенных ограничений) устанавливается признак исключительной ситуации с перечислением всех несоответствий. Примечания 1 Полномочия со временем могут меняться. Поэтому всякий раз при изменении полномочий, как явных, так и неявных (например, при изменениях в организационном масштабе), рекомендуется сопоставлять результаты развертывания с полномочиями. 2 Для учета программного обеспечения, разрешенного к установке, рекомендуется направлять владельцу копию отчета об исключительных ситуациях; 6) регистрируется и периодически анализируется успех или неуспех развертываний.

4.7.7 Процесс управления инцидентами

4.7.7.1 Цель

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

Применимо к уровню 4

4.7.7.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса управления инцидентами позволит организации продемонстрировать следующее:
а) организация имеет формальный процесс управления инцидентами, обеспечивающий: 1) регистрацию и ранжирование по приоритету разрешения всех инцидентов, влияющих на программное обеспечение, связанные активы или процессы управления программными активами; 2) разрешение всех таких инцидентов в соответствии с их приоритетами и документирование такого разрешения

4.7.8 Процесс управления проблемами

4.7.8.1 Цель

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

Применимо к уровню 4

4.7.8.2 Результаты

Результат	Уровень
	1	2	3	4
Реализация процесса управления проблемами позволит организации продемонстрировать следующее:
а) организация имеет формальный процесс управления проблемами, характеризуемый следующими особенностями: 1) все инциденты, оказывающие воздействие на программное обеспечение, услуги или процессы SAM, регистрируются и классифицируются по степени воздействия; 2) высокоприоритетные и повторяющиеся инциденты анализируются для выяснения первопричин и располагаются в порядке приоритета разрешения; 3) первопричины документируются и передаются в процесс управления инцидентами; 4) проблемы разрешаются в соответствии с их приоритетом, а результат разрешения документируется и передается в процесс управления инцидентами

4.7.9 Процесс списания

4.7.9.1 Цель

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

Применимо к уровню 3

4.7.9.2 Результаты

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

5 Уровни

5.1 Обзор

Обзор уровней приведен во введении к настоящему стандарту. На рисунке 1 проиллюстрирована концептуальная взаимосвязь между уровнями.

В основе группирования и упорядочивания уровней лежат следующие принципы:

a) Число уровней

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

b) Приоритет соблюдения лицензионного соответствия

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

c) Естественные группирования отражают естественную последовательность

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

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

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

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

4) лучшие в своем классе методы SAM замыкают список. Обычно к ним относятся методы, оказывающие стратегическое воздействие и дающие долгосрочные преимущества.

d) Минимальные требования к признанию

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

e) Ограничения в технологии и ее использовании

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

Также следует обратить внимание на концепцию "трудности".

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

b) Множество результатов или групп процессов обычно вообще не достигаются менее зрелыми организациями, и они, как правило, помещаются на уровень 4. С одной стороны, они могут рассматриваться как "трудные" результаты и группы процессов. Однако они скорее отражают этап становления организации, чем присущую им внутреннюю сложность. Поэтому такие результаты и группы процессов было бы точнее считать частью лучшего в своем классе SAM.

5.2 Уровень 1. Достоверные данные

На рисунке 3 показаны группы процессов, включенные в уровень 1.

Рисунок 3 - Уровень 1 SAM. Достоверные данные

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

a) базовые записи SAM;

b) лицензионное соответствие.

5.3 Уровень 2. Практическое управление

На рисунке 4 показаны группы процессов, включенные в уровень 2.

Рисунок 4 - Уровень 2 SAM. Практическое управление

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

a) немедленные преимущества;

b) обязательная контрольная среда.

5.4 Уровень 3. Операционная интеграция

На рисунке 5 показаны группы процессов, включенные в уровень 3.

Рисунок 5 - Уровень 3 SAM. Операционная интеграция

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

a) процессы базового жизненного цикла (закупка/развертывание/списание);

b) базовые процессы управления операциями.

5.5 Уровень 4. Полное соответствие настоящего стандарта SAM

На рисунке 6 показаны группы процессов, включенные в уровень 4.

Рисунок 6 - Уровень 4. Полное соответствие настоящего стандарта SAM

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

a) стратегический SAM (SAM представляет собой инструмент реализации и является частью стратегии и планирования);

b) расширенные процессы жизненного цикла менеджмента услуг;

c) лучшие в своем классе процессы SAM (не включены в более низкие уровни).

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

[1]	Руководство по ИСО 72	Руководящие указания для подтверждения и разработки стандартов системы управления (ISO Guide 72 Guidelines for the justification and development of management systems and ards)
[2]	ИСО/МЭК 2382-1:1993	Информационные технологии. Словарь. Часть 1. Основные термины (ISO/IEC 2382-1:1993 Information technology - Vocabulary - Part 1: Fundamental terms)
[3]	ИСО 9001	Системы управления качеством. Требования (ISO 9001 Quality management systems - Requirements)
[4]	ИСО/МЭК 12207	Системная и программная инженерия. Процессы жизненного цикла программного обеспечения (ISO/IEC 12207 Systems and software engineering - Software life cycle processes)
[5]	ИСО/МЭК 15504-2	Информационные технологии. Оценка процессов. Часть 2. Оценка процессов (ISO/IEC 15504-2 Information technology - Process assessment - Part 2: Performing an assessment)
[6]	ИСО/МЭК 20000-1:2005	Информационные технологии. Менеджмент услуг. Часть 1. Спецификации (ISO/IEC 20000-1:2005 Information technology - Service management - Part 1: Specification) *

------------------------------

^*_{ИСО/МЭК 20000-1:2005 был отменен и заменен на ИСО/МЭК 20000-1:2011 Информационные технологии. Менеджмент услуг. Часть 1. Системные требования к управлению услугами (ИСО/МЭК 20000-1:2011 Information technology - Service management - Part 1: Service management system requirements).}

------------------------------

[7]	ИСО/МЭК 27001	Информационная технология. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования (ISO/IEC 27001 Information technology - Security techniques - Information security management systems - Requirements)
[8]	ИСО/МЭК 38500	Корпоративное управление информационными технологиями (ISO/IEC 38500 Corporate governance of information technology)