Ответственность за принимаемые в работе решения всегда лежит на самой команде, независимо от того, идет ли речь о чистом RnD или проверке гипотез. Заказчика не интересует путь, которым была достигнута цель, он оценивает только конечный результат. Даже в условиях экспериментальной работы и исследований, когда не все гипотезы подтверждаются, команда должна уметь обосновать выбор подхода и показать, как неудачные попытки способствовали пониманию проблемы и приближению к решению. Эта ответственность является основой честной сделки между командой и заказчиком.

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

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

SLM (Service Level Management) - это процесс управления уровнем обслуживания, а SLA (Service Level Agreement) - это конкретное соглашение, которое фиксирует уровень предоставления услуг. При проектировании процесса SLM важно определить, как формируются и утверждаются SLA. В данном случае предложен метод, когда на этапе старта процесса SLM формируется базовое SLA 'AS IS', которое затем может корректироваться бизнесом через дополнительные соглашения, обеспечивая баланс между необходимостью запуска процесса и учетом потребностей заказчиков.

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

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

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

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

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

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