«Готовность» (из ГОСТ по надежности) характеризует вероятность безотказной работы компонента в момент включения и не учитывает внешние факторы, такие как обслуживание или инциденты. «Доступность» в ITIL и ISO/IEC 20000 включает не только техническую работоспособность, но и время простоя из-за плановых работ, внешних воздействий и процессов управления. Таким образом, «доступность» охватывает более широкий спектр факторов, связанных с предоставлением услуги конечному пользователю, а «готовность» фокусируется на внутренних характеристиках системы.

Ошибка «делать правильно, но не то, что нужно» заключается в том, что ИТ-специалисты технически корректно выполняют задачи, но эти задачи не связаны с реальными бизнес-потребностями и не приносят ценности. Например, разработчики могут внедрить «крутой» API с высокой производительностью, но если он не интегрирован с CRM, бизнес не увидит роста продаж. Или сервис-деск может похвастаться 1000 закрытыми заявками, игнорируя 40% повторных обращений. В таких случаях работа выполняется технически грамотно, но не решает реальные проблемы бизнеса и клиентов, приводя к потраченным впустую ресурсам и неэффективности.

В формуле First Time Resolution (FTR) при расчёте в разрезе рабочих групп используются два основных операнда: Nj и Sj. Sj представляет собой количество объектов, возвращённых на доработку в j-тую группу. Nj — это количество обращений, полностью обработанных j-той группой, включая как закрытые без рекламаций обращения (Cj), так и возвраты на доработку (Sj). Таким образом, Nj = Cj + Sj, где Cj — количество обращений, закрытых без рекламаций. Расчёт выполняется за период, когда завершена проверка решения, а не само решение задачи.

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

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

Электронная переписка имеет несколько важных преимуществ: во-первых, в ней остаются «следы» взаимодействия, которые могут помочь при будущем анализе ситуации или «разборе полетов»; во-вторых, email позволяет структурированно и продуманно изложить свои мысли, что снижает риск недопонимания; в-третьих, возможность отправки вложений с необходимой информацией (отчеты, графики, протоколы); в-четвертых, возможность точного определения и контроля сроков выполнения задачи; в-пятых, возможность создания архива переписки по конкретным проектам и темам, что упрощает поиск информации в будущем.

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

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

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

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