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

Структура IT4IT первого уровня (Level 1) представлена через призму потоков создания ценности (Value Streams), где все элементы модели выстроены вокруг сервисной модели (Service Backbone) как основы. Это создает более явную и структурированную картину того, как различный ИТ-активы взаимодействуют для создания ценности. В ITIL v3 структура основана на жизненном цикле услуги (Service Lifecycle), представленном как последовательность фаз: стратегия, дизайн, переход к эксплуатации, эксплуатация и непрерывное улучшение. В то время как ITIL v3 фокусируется на том, что происходит с услугей на разных этапах ее жизни, IT4IT Level 1 делает акцент на том, как потоки работы проходят через организацию для создания этой услуги. IT4IT Level 1 предоставляет более явные связи между бизнес-потребностями и ИТ-реализацией через Value Streams, тогда как ITIL v3 предоставляет более детализированный взгляд на управление самой услугой на разных этапах ее жизненного цикла.

Теория ограничений применяется через выявление ключевого ограничения в каждом процессе и постановку SMART-целей, направленных на его устранение. Например, для процесса управления инцидентами ограничением может быть длительное время решения проблем, поэтому цель формулируется как 'Сократить среднее время устранения инцидентов на X%'. Цели должны быть привязаны к конкретному назначению процесса ('Обеспечение качества ИТ-услуг посредством...') и измеряться через влияние на конечный результат — повышение качества услуг для клиентов.

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

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

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

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

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

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

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