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

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

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

Координатору релизов от менеджера процесса могут быть делегированы следующие обязанности в рамках конкретного направления: управление ресурсами, непосредственно участвующими в процессе релиза; координация деятельности практиков (пакетирования, построения, развёртывания и первичной поддержки) внутри направления; контроль соблюдения сроков и качества выполнения этапов релиза; обеспечение взаимодействия между командами, задействованными в релизе; сопровождение релиза на всех этапах — от планирования до закрытия. Такая делегация полномочий позволяет менеджеру процесса сосредоточиться на стратегических аспектах и взаимодействии с другими процессами, а координатору релизов — на оперативном управлении конкретными релизами в рамках своего направления.

Согласно тексту, эксперты DevOps рекомендуют визуализировать следующие ключевые элементы: поток создания ценности (Value Stream), определение завершения (Definition of Done), ограничение числа задач в работе (WIP Limit), а также ясную картину загрузки ресурсов и ограничений. Эти элементы помогают создать эффективную систему управления работой, обеспечивая прозрачность и понимание процессов всеми участниками.

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

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

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

KPI группы поддержки рассчитывается по формуле: Кгруппы = (1/N) * Σ[(1 - (ti/Ti) * vi)], где N – общее число инцидентов, в которых участвовала группа, vi принимает значение 0 (инцидент решен в срок) или 1 (инцидент просрочен), ti – время обработки i-го инцидента силами данной группы (включая время реакции), Ti – общее время обработка i-го инцидента от регистрации до решения. Значение метрики находится в пределах [0; 1] и отражает степень своевременности обработки инцидентов, учитывая долю участия группы в общем процессе.

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