Emergency-изменения в ITIL — это особая группа изменений, которые требуют внедрения «как можно скорее» из-за критического влияния инцидентов на бизнес. Они применяются строго для устранения серьёзных ошибок в ИТ-сервисах, таких как массовые сбои или уязвимости безопасности. Процедура обработки emergency-изменений активируется только в ситуациях, когда бизнес-процессы существенно нарушены, и требуется незамедлительное вмешательство для их восстановления. Например, если произошёл массовый инцидент, блокирующий работу клиентов, или обнаружена критическая дыра в безопасности, требующая немедленного патча.

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

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

В процессе управления проблемами координатором проблемы должен стать ведущий специалист из той области, где изначально проявляется проблема. Например, если тормозит приложение, координатором будет специалист app-саппорта. Однако, если диагностика выявляет проблему в смежной области (например, на СХД), в условиях слабой матрицы рекомендуется создать новую связанную проблему и назначить для неё отдельного координатора, сохранив исходную проблему под ответственностью первого координатора. Это позволяет вести параллельное решение обеих проблем и избежать потери мотивации у «страдающей стороны».

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

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

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

Структура сценария риска в COBIT 5 for Risk включает пять основных компонентов: источник угрозы (Actor), который определяется как внутренний или внешний; тип угрозы (Threat Type), такой как злоумышленные действия, ошибки или природные катаклизмы; событие (Event), включающее раскрытие информации, модификацию, кражу или уничтожение; связанные активы (Asset/Resource), относящиеся к людям, организационным структурам, процессам и ИТ-инфраструктуре; и временной аспект (Time), учитывающий прогнозируемую длительность негативного влияния и критичность события в зависимости от времени суток или календарного периода.

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

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