Компании, придерживающиеся стратегии выживания, выделяют на 'развитие и управление ИТ' 4-8% от общего размера ИТ-бюджета. Это значительно выше, чем в других стратегических группах.

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

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

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

При изменении ИТ-ландшафта (например, замене системы) связь между системными и бизнес-ролями определяется через: 1) Анализ архитектуры старой и новой систем — выявление функциональных аналогов (например, роль 'Менеджер проектов' в старой Jira может соответствовать роли 'Лид проекта' в новой системе). 2) Построение таблицы соответствия, где каждой старой системной роли ставится в соответствие новая. 3) Корректировку бизнес-ролей: если старая системная роль 'Кассир' входила в бизнес-роль 'Финансовый сотрудник', после замены её заменяют на новую роль 'Оператор кассы', но бизнес-роль сохраняет логику использования. Критически важно сохранить соответствие функций сотрудников, даже если названия системных ролей меняются.

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

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

Отчётность ради отчётности не соответствует критерию «R» (relevant), так как данные собираются и предоставляются без использования их для принятия решений или изменений в управлении. Наличие измеримых показателей («M») не компенсирует отсутствие релевантности. Это приводит к трате ресурсов на создание отчётов без реальной пользы для организации.

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

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