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

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

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

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

Отложенное влияние возникает, когда сбой в инфраструктуре не приводит к немедленным проблемам для пользователей, но может вызвать сбои позже. Например, падение резервного сервера не повлияет на услуги сразу, но оставит систему уязвимой при следующем сбое основного сервера. Или при сбое в системе резервного копирования данные потеряются только при попытке восстановления после аварии.

Предложения должны быть связаны с конкретными проблемами, выявленными в анализе, и содержать описание механизма решения. Например, вместо «нам не хватает людей» можно указать: «снижение времени на рутинные операции на 20% за счет внедрения скрипта обработки данных высвободит ресурсы для текущих задач». Важно оценивать ожидаемый результат и подкреплять идею расчетами или примерами.

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

Матрично-иерархическая структура в классификаторе изменений применяется следующим образом: Сначала устанавливается иерархия категорий изменений: - На верхнем уровне разделяются стандартные и нестандартные изменения - Далее по критериям риска, типа объекта (ИТ-инфраструктура, информационные системы, сети) - Иерархия продолжается до уровня конкретных типов или групп систем Затем формируется матрица параметров для каждой категории: - Для каждой группы систем или направлений определяются свои наборы параметров - Параметры включают: ответственных за координацию, уполномоченных на согласование, обязательные результаты этапов - Набор опциональных этапов для конкретной группы систем Особенность применения такой структуры: - Для ИТ-инфраструктуры может быть определен общий типовой порядок с опциональными этапами для работ в боевой среде - Для информационных систем — мастер-порядок с обязательным приёмочным тестированием - Для разных групп информационных систем (например, критически важных) — дополнительные этапы оценки влияния Как пример конкретной реализации: - Категория «Стандартные изменения для серверной инфраструктуры»: * Общие этапы: запрос, техническое согласование, выполнение, подтверждение * Параметры: ответственный координатор — администратор соответствующего направления, срок выполнения — не более 2 часов * Специфика: не требуется приёмочное тестирование, так как работы выполняются в режиме реального времени - Категория «Изменения для критически важных информационных систем»: * Общие этапы: запрос, анализ влияния, утверждение комитета, планирование, тестирование, выполнение, подтверждение * Параметры: ответственный координатор — старший сотрудник, срок планирования — минимум 5 рабочих дней * Специфика: обязательное приёмочное тестирование в выделенной среде Этот подход позволяет значительно сократить количество уникальных моделей, оставаясь при этом достаточно гибким для учета специфики различных систем и направлений.

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

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