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

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

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

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

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

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

Для оценки риска изменений (Change Risk) можно использовать несколько видов метрик. Прямые метрики (отложенные показатели): Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases, Number of defects per release. Эти метрики отражают уже произошедшие инциденты и их последствия. Опережающие показатели: Release size (размер релиза), Emergency change rate (доля аварийных изменений), которые помогают прогнозировать потенциальные риски. Также косвенно на Change Risk влияют метрики, связанные с First-Time Implementation Rate и Standardization/Automation, так как они отражают качество подготовки и внедрения изменений.

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

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

Объемный документ "описание процесса" не подходит для рядовых специалистов, потому что их работа в рамках процесса часто ограничена выполнением одной процедуры. Для выполнения своих обязанностей им не нужно знать все детали процесса, а достаточно иметь общее представление о нем и понимать свою роль. Читать документ объемом, например, в 80 страниц, когда необходимо знать лишь узкий участок работы, нецелесообразно. Таким сотрудникам больше подойдут ролевые инструкции, детализирующие их непосредственные задачи.