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

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

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

Заинтересованные стороны играют ключевую роль в домене EDM COBIT 5. Процесс EDM05 напрямую связан с их потребностями, так как обеспечивает прозрачность и информирование заинтересованных сторон. Кроме того, все процессы домена EDM ориентированы на удовлетворение ожиданий и требований заинтересованных лиц. Например, процессы EDM02, EDM03 и EDM04 направлены на оптимизацию ценности, рисков и ресурсов именно с точки зрения интересов заинтересованных сторон. Таким образом, заинтересованные стороны выступают как основные получатели результатов деятельности системы руководства ИТ.

Для интеграции данных необходимо создать единую платформу (например, CDP — Customer Data Platform), которая собирает информацию из всех каналов: CRM, веб-аналитики, соцсетей, оффлайн-продаж. Важно устранить «информационные барьеры» между отделами, внедрив процессы обмена данными по стандартам и с использованием API. Также нужно использовать инструменты для обогащения данных (например, геолокация или данные о поведении) и применять машинное обучение для выявления паттернов. Ключевой принцип — данные должны быть доступны в реальном времени, чтобы персонализировать взаимодействие мгновенно.

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

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

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

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

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