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

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

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

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

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

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

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

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

В тексте упомянуты четыре основные проблемы управления рабочим временем: 1. Объем работы: задач поступает больше, чем есть времени на их выполнение. После перехода из клиентской компании в консалтинг и запуска собственного бизнеса рабочая загрузка возросла до 120-160%, что создало острую нехватку времени. 2. Противоречие интересов: существует разница между тем, что хочется делать (интересная работа) и тем, что необходимо выполнять (обязательные задачи, например, бухгалтерский и налоговый учёт). 3. Приоритизация: рутинные оперативные вопросы занимают всё рабочее время, в то время как на стратегическое развитие компании и личностный рост времени не хватает. 4. Размытость границ: в современных условиях сложно отделить рабочее время от личной жизни. Гибкий график и постоянное погружение в работу приводят к тому, что приходится успевать и профессиональные, и семейные обязанности.

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