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

Оценка удовлетворённости заказчика услугой проводится через регулярные опросы (формальные) и неформальные разговоры (например, 'у кулера'). Нужно прямо спрашивать заказчика, доволен ли он услугой, выявлять конкретные причины недовольства, если таковые имеются, и определять, что можно улучшить, даже если заказчик доволен. Важно получать как позитивную, так и негативную обратную связь, чтобы понимать, какие аспекты услуги ценятся, а какие требуют корректировки. Эта информация служит основой для выявления путей улучшения услуг через программу SIP.

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

В IT4IT функциональные компоненты организованы вокруг сервисной модели (Service Model), которая представляет собой Service Backbone архитектуры. Эта модель охватывает все стадии, необходимые для создания и предоставления ИТ-услуг, что напрямую соответствует концепции жизненного цикла услуги из ITIL. Конкретно, функциональные компоненты в IT4IT распределены по четырем Value Streams, каждый из которых охватывает определенную фазу жизненного цикла: Strategy to Portfolio (S2P) - управление портфелем и стратегией; Requirement to Deployment (R2D) - разработка и развертывание; Request to Fulfill (R2F) - предоставление услуг; Detect to Correct (D2C) - управление эксплуатацией и решением проблем. Таким образом, набор функциональных компонентов в IT4IT охватывает все этапы от идеи услуги до ее непрерывного улучшения, полностью зеркалируя концепцию жизненного цикла услуги, только структурированную в виде потоков создания ценности.

Семь основных факторов успеха в реализации ITSM проектов, описанных в документе Pink Elephant "The Seven Enablers & Constraints Of IT Service Management", это: 1) Лидерство - поддержка и участие руководителей, без чего сложно принимать оптимальные решения и добиваться реализации процессов 2) Ресурсы - доступ к необходимым временным, человеческим и финансовым ресурсам, которые требуются задолго до запуска процессов 3) Знания и навыки - достаточный уровень квалификации ключевых специалистов, который достигается не только обучением проектной команды, но и вовлечением менеджеров на всех этапах 4) Средства автоматизации - наличие инструментов, способных реализовать требования к автоматизации процессов, а не диктовать их форму 5) Возможность запуска нововведений - способность организации распространять новые политики и процессы, что является наиболее важным пунктом, так как без полноценного запуска вся предыдущая работа теряет смысл 6) Способность влиять на корпоративную культуру - обеспечение выполнения новых правил с использованием различных методов мотивации и вмешательства руководства 7) Поддержка ITSM изменений - обеспечение необходимых приоритетов, финансирования и внимания на протяжении всего длительного периода внедрения системы управления.

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

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

Реализация ITSM кардинально изменяет управление инцидентами, обеспечивая более обоснованные и чёткие нормативы. Меняется подход к классификации обращений пользователей, что требует переподготовки первой линии поддержки. Существенно усиливается потребность в эффективной координации устранения крупных инцидентов (major incidents) и регистрируются инфраструктурные инциденты для контроля доступности услуг.

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

В тексте описаны две основные конфликтующие цели ИТ: необходимость поддерживать развитие бизнеса и быстро проводить изменения (минимизировать Time to market), и необходимость предоставлять услуги высокого качества (стабильные, надежные, безопасные), что подразумевает обеспечение Service Quality. Эти цели конфликтуют, потому что чем быстрее проводятся изменения (меньше Time to market), тем выше риски с точки зрения качества услуг, а повышение уровня защиты продуктивной среды (увеличение Service Quality) приводит к увеличению времени на реализацию изменений (увеличению Time to market). Этот конфликт лежит в основе многих проблем в ИТ-организациях и часто приводит к так называемому Core Chronic Conflict (CCC) между разработкой и эксплуатацией.