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

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

Процесс Управления инцидентами должен быть спроектирован так, чтобы предоставление информации о статусе инцидента соответствовало договорённостям с бизнесом. Это включает определение момента времени, когда информация должна быть предоставлена пользователю, выбор формата информации и каналов её передачи. Процесс должен предусматривать как проактивные коммуникационные действия (автоматические оповещения при изменении статуса), так и реактивные (предоставление информации по запросу). Интеграция с порталом самообслуживания, настройка автоматических уведомлений по email или SMS, организация работы Service Desk — всё это элементы проектирования процесса, обеспечивающие необходимый уровень прозрачности и удовлетворяющие требованиям пользователей без излишней нагрузки на персонал.

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

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

Терминология ITIL меняется от версии к версии, потому что подходы к управлению ИТ-услугами эволюционируют в соответствии с изменениями в бизнес-среде и технологиях. ITIL4 делает акцент на гибкости, ко-создании ценности и интеграции с современными методологиями (такими как Agile и DevOps), что требует более гибкой терминологии. Жесткое разделение, существовавшее в ITIL V3, заменяется концепцией видимости ресурсов в зависимости от контекста, что лучше отражает сложность современных сервисных экосистем.

ITIL рекомендует четко обозначать и устанавливать реалистичные сроки выполнения для инцидентов и запросов на обслуживание, отражая разную срочность и сложность этих категорий. Сроки для инцидентов должны быть определены исходя из уровня их влияния и важности для бизнеса, с акцентом на максимальное сокращение времени простоя. Для запросов на обслуживание сроки могут быть более предсказуемыми и стандартными, так как они представляют собой регулярные операции, которые можно запланировать. Важно, чтобы эти сроки были согласованы с заказчиком и отражены в SLA, обеспечивая прозрачность ожиданий для всех заинтересованных сторон и позволяя объективно измерять соблюдение этих сроков.

Подход к управлению непрерывностью ИТ-услуг в ITIL v3 и IT4IT имеет как сходства, так и различия. В ITIL v3 управление непрерывностью представлено как отдельный процесс, который входит в состав этапа Service Design (дизайн услуг) и фокусируется на обеспечении непрерывности бизнеса через ИТ-услуги. В IT4IT управление непрерывностью интегрировано в Value Stream Detect to Correct (D2C), который охватывает весь спектр деятельности по обнаружению и устранению инцидентов и проблем. В рамках этого потока управление непрерывностью рассматривается как часть более широкого процесса обеспечения стабильности и качества услуг. При этом IT4IT делает акцент на том, как система в целом обеспечивает непрерывность через взаимодействие различных функциональных компонентов, тогда как ITIL v3 предоставляет более детализированное описание конкретных процессов и процедур управления непрерывностью. Оба подхода признают важность непрерывности услуг, но структурируют эту деятельность по-разному - в ITIL v3 как отдельный процесс, а в IT4IT - как интегральную часть потока обнаружения и исправления проблем.

Раздел «Хорошие практики» в описании фактора влияния COBIT 5 включает набор задач и факторов успеха, необходимых для реализации назначения процесса. Эти практики можно взять из общедоступных референтных моделей, таких как COBIT, ITIL или ISO20000, или разработать собственные. Например, для процесса BAI06 Manage Changes COBIT 5 определяет такие практики, как оценка и приоритизация запросов на изменения, управление экстренными изменениями, отслеживание статуса изменений и их документирование. Соответствие этим практикам является метрикой соответствия внешним или внутренним требованиям и помогает оценить, насколько процесс соответствует лучшим практикам отрасли, что важно как для внутреннего совершенствования, так и для аудита и сертификации.

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