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

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

Помимо скорости решения инцидентов на удовлетворённость пользователей влияет несколько важных факторов. Во-первых, количество коммуникационных итераций: чем меньше пользователю приходится взаимодействовать с службой поддержки в рамках одного инцидента, тем выше удовлетворённость. Это измеряется показателем FCR (First Contact Resolution) — долей инцидентов, решённых с первого обращения. Во-вторых, качество решения: важно, чтобы инцидент был устранён правильно с первой попытки, что контролируется через долю инцидентов, возвращённых на доработку. В-третьих, качество коммуникаций: это включает культуру общения, уровень прозрачности, своевременность оповещений и проактивное информирование пользователей о ходе решения инцидента. Все эти компоненты в совокупности формируют общий уровень удовлетворённости пользователей сервисом.

Основной базовый набор ключевых метрик DevOps включает: время нахождения идеи в бэклоге (пока не взяли на реализацию), время прохождения задачи от начала работы до выпуска в продуктивную среду, долю выполненных задач, которые принесли ожидаемую пользу, и предсказуемость выполнения взятых на себя задач за определенные временные периоды. К этому базовому набору можно добавить дополнительные метрики, такие как velocity, MTTR (среднее время восстановления), MTBF (среднее время наработки на отказ) и расход ресурсов на устранение дефектов и инцидентов. Однако важно не количество метрик, а то, что они дают объективную картину ситуации и помогают в принятии решений для уменьшения времени выпуска продукта (lead time).

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

Участие в деловой игре Grab@Pizza развивает множество навыков: способность быстро принимать решения в условиях неопределённости, навыки коммуникации и взаимодействия между различными департаментами (особенно бизнеса и ИТ), понимание процессов ITSM и ITIL, умение приоритезировать задачи и обосновывать бизнес-ценность ИТ-инициатив, навыки управления кризисными ситуациями, лидерские качества и способность работать в команде. Также игра развивает умение анализировать ситуации, находить ошибки в текущих процессах и предлагать решения по их улучшению.

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

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

ISO 31010 представляет собой полное собрание методов идентификации, анализа и оценки рисков. Стандарт охватывает широкий спектр подходов – от организации работы экспертных групп до количественной оценки вероятности негативных событий. Среди описанных методов присутствуют FTA (анализ дерева отказов), ETA (анализ дерева событий), BIA (анализ бизнес-воздействия), метод Дельфи, SWIFT (Структурированный Что-Если Анализ Технологии) и диаграмма Ишикавы. Все эти методы собраны в едином документе, что делает стандарт ценным практическим руководством.

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