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

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

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

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

В методологии COBIT 5 for Risk влияние риска оценивается по трем составляющим: получение ценности от ИТ (IT Benefit/Value Enablement), исполнение ИТ программ и проектов (IT Programme and Project Delivery) и эксплуатация и предоставление ИТ-услуг (IT Operations and Service Delivery). Для каждого конкретного сценария риска приводится детальное описание того, как негативное событие может повлиять на эти три ключевые области. Такая структурированная оценка позволяет организациям лучше понимать последствия рисков и разрабатывать целевые стратегии их снижения.

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

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

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

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

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