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

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

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

В управлении доступностью (AVA) основными показателями выступают: - MTRS (среднее время восстановления услуги) - MTBF (среднее время между сбоями) - MTBSI (среднее время между инцидентами) Эти показатели связаны со статистикой и тенденциями сбоев в работе ИТ-систем. В управлении непрерывностью (CONT) используются: - RTO (recovery time objective) — целевое время восстановления - RPO (recovery point objective) — целевая точка восстановления RTO показывает, за какое время после сбоя должно быть возобновлено предоставление услуги, а RPO указывает, какой период данных может быть потерян без критического ущерба для бизнеса.

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

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

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

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

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

Существует два основных подхода к определению соотношения этих процессов. 1) Модель №1: CSI рассматривается как общий подход к совершенствованию, который встраивается во все области деятельности, в том числе в процесс управления проблемами. В этом случае CSI является мета-практикой или инструментом, который используется на всех этапах жизненного цикла услуги и опоясывает стратегию, проектирование, преобразование и эксплуатацию. Процесс управления проблемами, в свою очередь, использует подходы CSI для решения конкретных проблем. 2) Модель №2: Граница между CSI и PRB проходит не между различными видами деятельности, а между различными уровнями организации. В этом случае CSI представляет собой общекорпоративную практику, которая охватывает всю организацию (например, весь ИТ-департамент), в то время как процесс управления проблемами фокусируется на решении конкретных технических ошибок. При этом в большинстве организаций эти практики появляются не одновременно и имеют разный охват, что делает вопрос границы между ними актуальным только после установления жизнеспособности обеих практик. Если рассматривать CSI как мета-практику, обеспечивающую единые подходы к управлению качеством (аналогично практике риск-анализа), то эти процессы находятся в разных плоскостях, но взаимодействуют друг с другом.