В DevOps важно учитывать не только плановую, но и неплановую работу при распределении ресурсов, потому что операционная часть (тот самый 'Ops') требует постоянного внимания к текущим системам и их поддержке. Неплановые задачи, такие как инциденты, исправление дефектов и срочные запросы, являются неотъемлемой частью операционной деятельности и могут возникать в любой момент. Если выделить все ресурсы только на плановую работу, команда не сможет оперативно реагировать на проблемы в эксплуатации, что приведет к снижению надежности системы и удовлетворенности пользователей. Разделение ресурсов позволяет поддерживать баланс между внедрением новых функций и поддержанием стабильности текущих систем.

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

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

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

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

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

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

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

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

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