8.1. AI 5. Поставки ИТ-ресурсов

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

Рис. 8.1. Процесс "Поставки ИТ-ресурсов"

Поставки ИТ-ресурсов

удовлетворяет следующим бизнес требованиям к ИТ

повышение эффективности вложений в ИТ и вклада ИТ в прибыльность бизнеса.

сосредоточено на

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

достигается с помощью

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

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

• Число обсуждений, связанных с договорами на поставки.
• Объемы скидок от цены покупки.
• Доля заинтересованных сторон, удовлетворенных поставщиками.

В таблице 8.1 представлена информация, необходимая для процесса и ее источники.

В таблице 8.2 приведены результаты процесса и то, куда они должны поступить.

Таблица 8.3 содержит таблицу ОУКИ для процесса, а таблица 8.4 – цели и показатели.

Цели контроля

• AI 5.1. Контроль за поставками

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

• AI 5.2. Управление контрактами с поставщиками

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

• AI 5.3. Выбор поставщиков

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

• AI 5.4. Приобретение ИТ-ресурсов

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

Чтобы грамотно управлять закупками, нам необходимо ответить на 4 вопроса:

• что мы покупаем,
• где мы покупаем,
• у кого и на каких условиях,
• как мы будем покупать в будущем.

В современном менеджменте часто встречаются понятия Запрос на цену и Запрос на коммерческое предложение.

Запрос на цену (англ. Request for quotation RFQ) является стандартным бизнес-процессом, цель которого состоит в том, чтобы пригласить поставщиков на торги стимулировать предлагать цену на определенные продукты или службы. RFQ вообще означает то же самое что и Приглашение на торги (англ. Invitation For Bid IFB).

RFQ обычно включает больше чем просто цену на товар. Во время торгов, возможно, потребуется получить информацию об условиях платежа, уровень качества товара или объём контракта.

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

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

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

Заявка на коммерческое предложение (англ. Request for Proposal RFP) — заявка на сервис (услугу, продукт). Создаётся заказчиком для потенциальных подрядчиков (поставщиков) в тендерных или аукционных процессах.

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

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

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

Практическое задание

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

Решение:

1. Запрос на покупку. Прежде чем начинать формировать запрос на покупку, необходимо обратиться к Стратегии поставок (если такая имеется в организации). Такие Стратегии описывают подходы к закупкам на высоком уровне, например:
   • для товаров (услуг) с низкой стоимостью и рисками постарайтесь объединиться с другими организациями для приобретения большого количества по меньшей цене;
   • для товаров (услуг) повышенного риска постарайтесь работать с поставщиками на основе долговременных отношений вместо того, чтобы рассматривать множество предложений от малоизвестных поставщиков;
   • и т.п.
2. В организации должны быть сформулированы процедуры закупки. Например, в процедурах закупок может быть оговорено следующее:
   • на закупки более 500 000 рублей должен быть объявлен тендер;
   • при закупке от 200 000 рублей до 500 000 необходимо рассматривать предложения минимум трех поставщиков;
   • кто может инициировать процедуру закупки (естественно, не каждый сотрудник организации);
   • кто будет рассматривать запросы на покупку;
   • кто будет утверждать запросы на покупку;
   • кто будет готовить Запрос на цену (Request for Quotation, RFQ) и Заявку на коммерческое предложение (Request for Proposal, RFP) в наиболее сложных случаях;
   • кто будет выбирать поставщиков;
   • все поставщики должны входить в список утвержденных поставщиков;
   с каждым поставщиком необходимо заключить договор.
3. Группа сотрудников, ответственная за выбор поставщиков, рассматривает запрос на покупку, ищет потенциальных поставщиков, оценивает их предложения и т.п. Все эти вопросы должны быть определены в рамках требований по управлению отношениями с третьими сторонами и процедур закупок. При этом оценивается цена, насколько хорошо предложение удовлетворяет установленным требованиям, надежность поставщика (исходя из предыдущего опыта и опыта других организаций), временные границы и т.п. 4. После оценки и выбора группа передает свой вариант руководству на утверждение.
4. Руководство утверждает запрос на покупку и выбор поставщика.
5. Когда поставщик выбран, необходимо заключить контракт. Обычно у крупных организаций есть шаблоны подобных договоров на поставку. Допустим, Вы заказываете цикл разработки программного обеспечения. Тогда в договоре необходимо отобразить:
   • область действия: функциональные и нефункциональные требования, в том числе документация, обучение (опционально);
   • временные границы: когда будет поставлено программное обеспечение, основные этапы поставки;
   • стоимость (финансовая): сколько и когда Вы заплатите поставщику? Возможно, оплата будет разбита на этапы;
   • качество: как поставщик гарантирует качество и как его можно проверить?
   • права на интеллектуальную собственность: какие права будет иметь Ваша организация? Патенты? Авторское право? Компенсации?
   • безопасность: необходимо предусмотреть статью о неразглашении на случай, если поставщик получит доступ к конфиденциальной информации или данным, которые будут получены в результате работы программного обеспечения.
   • производительность: что будет свидетельствовать о плохой производительности? Какое реагирование на плохую производительность? Прекращение действия договора? Штраф?

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

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

Задачи для самостоятельного решения:

1. Сформулируйте три процедуры закупки, отличные от приведенных в решении задачи.
2. Представьте, что компания покупает услугу хостинга. Подумайте над тем, какие показатели качества стоит оговорить в договоре.

8.2. AI 6. Управление внесением изменений

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

• оптимизация рисков;
• минимизация негативного влияния на бизнес со стороны ошибок и сбоев;
• успешная реализация изменений с первой попытки.

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

Стандартные действия при реализации отдельных изменений:

• создание Запроса на изменение (RFC);
• пересмотр и проверка RFC, фильтрация изменений;
• оценка и определение изменения:
• установить уровень управления изменением;
• определить участников процесса;
• оценить мотивацию бизнеса, издержки, риски и выгоды, связанные с изменением;
• запросить независимую оценку изменения.
• утверждение изменения (в том числе определение механизмов авторизации к нему);
• формирование планов обновлений;
• координация реализации изменения.
• обзор и завершение изменения[5].

Рис. 8.2. Процесс "Управление внесением изменений"

Управление внесением изменений.

удовлетворяет следующим бизнес требованиям к ИТ

соответствие бизнес требованиям в русле корпоративной стратегии, при сокращении дефектов и переделок в решениях и услугах.

сосредоточено на

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

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

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

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

В таблице 8.5 представлена информация, необходимая для процесса и ее источники.

В таблице 8.6 приведены результаты процесса и то, куда они должны поступить.

Таблица 8.7 содержит таблицу ОУКИ для процесса, а таблица 8.8 – цели и показатели.

Цели контроля

• AI 6.1. Стандарты и процедуры изменений

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

• AI 6.2. Оценка последствий, расстановка приоритетов и авторизация

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

• AI 6.3. Аварийные изменения

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

• AI 6.4. Мониторинг и отчетность по статусу изменений

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

• AI 6.5. Завершение изменений и документирование

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

Управление изменениями представляет ценность для бизнеса тем, что:

1. категорирует цели изменений бизнеса и заказчиков и помогает их осуществить;
2. реализует изменения, которые соответствуют потребностям заказчиков, одновременно с оптимизацией затрат;
3. старается выполнять требования закона, контрактов, руководства и регуляторов;
4. уменьшает количество неудавшихся изменений и, соответственно, количество сбоев, остановок и простоев услуг;
5. осуществляет изменения в установленном бизнесом временном интервале;
6. следит за изменениями на всем жизненном цикле услуг;
7. старается обеспечить лучшие показатели в аспектах качества, времени и затрат;
8. оценивает риски, сопутствующие внедрению;
9. помогает увеличить продуктивность работы персонала тем, что минимизирует нарушения и сбои, а, следовательно, улучшает доступность услуг.

Рассмотрим пример. Однажды внедренная ИТ-услуга (платформа для публикации произведений) требует изменений – необходимых, желаемых, нежелательных и т.п. Например:

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

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

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

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

8.3. AI 7. Внедрение и приемка решений и изменений

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

Рис. 8.3. Процесс "Внедрение и приемка решений и изменений"

Внедрение и приемка решений и изменений

удовлетворяет следующим бизнес требованиям к ИТ

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

сосредоточено на

проверке соответствия приложений и инфраструктурных решений поставленным задачам и на отсутствие ошибок, а также на планировании выпуска версий

достигается с помощью

• Внедрения методологии тестирования
• Планирования выпуска версий
• Оценки и утверждения результатов тестирования бизнес-менеджерами
• Проведении анализа результатов внедрения

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

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

В таблице 8.9 представлена информация, необходимая для процесса и ее источники.

В таблице 8.10 приведены результаты процесса и то, куда они должны поступить.

Таблица 8.11 содержит таблицу ОУКИ для процесса, а таблица 8.12 – цели и показатели.

Цели контроля

• AI 7.1. Обучение

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

• AI 7.2. План тестирования

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

• AI 7.3. План внедрения

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

• AI 7.4. Среда тестирования

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

• AI 7.5. Перенос системы и данных

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

• AI 7.6. Тестирование изменений

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

• AI 7.7. Тестирование перед окончательной приемкой

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

• AI 7.8. Ввод в эксплуатацию

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

• AI 7.9. Анализ результатов внедрения

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

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

Практическое задание

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

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

Что необходимо сделать для того, чтобы избежать указанных проблем?

Решение:

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

1. Создание тестовой среды. Тестовая среда должна быть максимально приближена к среде промышленной эксплуатации (использовать то же оборудование, операционные системы и другие приложения).
2. Планирование тестирования. После создания тестовой среды, необходимо выбрать тех, кто будет тестировать и составить детальный план тестирования, который максимально затронет функционал системы. Еще лучше разбить тестирование на отдельные составляющие и прикрепить к ним пользователей. Например:
   • Тест 1: Регистрация пользователя – тестировщик Николай Иванов;
   • Тест 2: Публикация работы на сайте – тестировшик Юлия Аминова и т.п.
3. Проведение тестирования
4. Составление отчета. В конце необходимо сделать единый отчет о тестировании и предоставить его руководству. Даже если не все тесты будут иметь положительный результат, может быть принято решение о продолжении внедрения.
5. Составление плана развертывания. После проведения тестирования, Вы уже более осведомлены об особенностях системы и можете приступить к созданию Плана развертывания. Если это требует изменения инфраструктуры, обратитесь к процессу "Управление внесением изменений". Для задач внедрения, которые могут затронуть другие приложения, выберите плановое время технического обслуживания или выходные дни. Чтобы сократить время, можно определить в плане специфические действия (например, записать команды Linux или каждый шаг для Windows GUI). Эти шаги предварительно должны быть протестированы в тестовой среде, чтобы убедиться в их корректности и надежности.

Задача для самостоятельного решения:

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