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

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

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

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

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

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

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

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

К стандартам управления инцидентами информационной безопасности относятся ГОСТ Р ИСО/МЭК 18044-2007 (Информационная технология - Методы и средства обеспечения безопасности - Менеджмент инцидентов информационной безопасности) и E.409 (Организация по реагированию на инциденты и обработка инцидентов безопасности: Руководство для организаций электросвязи). Эти документы содержат рекомендации по организации реагирования на инциденты и управлению процессами безопасности.

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