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

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

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

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

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

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

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

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

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

Система постоянного улучшения на основе ITIL (Continual Service Improvement) строится по следующему алгоритму: во-первых, определите ключевые показатели эффективности (KPI) для каждой ИТ-услуги, ориентированные на бизнес-результаты. Затем регулярно (ежемесячно или ежеквартально) проводите анализ данных по этим KPI, сравнивая с целевыми значениями. Обеспечьте сбор обратной связи от всех заинтересованных сторон - бизнес-подразделений, пользователей и технических специалистов. Создайте циклический процесс из четырех этапов: Measure (измерение текущего состояния), Analyze (анализ данных и выявление проблем), Improve (внедрение улучшений), Review (оценка результатов изменений). Назначьте ответственных за CSI из руководителей ИТ-подразделений и бизнес-лидеров. Проводите регулярные сессии по выявлению возможностей для улучшения, используя техники мозгового штурма и анализ основных причин. Внедрите систему приоритизации улучшений на основе их влияния на бизнес и сложности реализации. Убедитесь, что результаты улучшений измеряются и доводятся до сведения всех заинтересованных сторон, что создаст мотивацию для дальнейших улучшений. Важно, чтобы процесс CSI был частью повседневной культуры организации, а не разовым проектом.