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

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

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

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

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

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

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

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

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

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