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

Улучшение клиентского опыта достигается через идентификацию и оптимизацию точек взаимодействия с потребителем, которые находятся в полосе видимости. При синхронизации потоков и путешествия заказчика необходимо определить, на каких этапах путешествия происходит взаимодействие с клиентом и какие потоки при этом запускаются. Сфокусировавшись на этих точках, можно непрерывно улучшать CX/UX, делая взаимодействие более эффективным и приятным. Например, упрощая процессы сбора требований на этапе Offer или оптимизируя решение инцидентов на этапе Co-create. Это позволяет целенаправленно управлять клиентским опытом и повышать удовлетворенность потребителей.

Цикл Деминга-Шухарта представляет собой метод непрерывного совершенствования процессов, состоящий из четырех этапов: Plan (Планирование), Do (Выполнение), Check (Проверка), Act (Действие). В управлении ИТ этот цикл применяется для постоянного улучшения процессов, позволяя организациям анализировать текущее состояние, внедрять изменения, проверять их эффективность и корректировать дальнейшие действия. На практике цикл используется для оптимизации различных ИТ-процессов, таких как управление инцидентами, управление изменениями и управление проблемами.

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

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

В контексте предоставления услуг 'utility' (полезность) и 'warranty' (гарантия) обозначают два ключевых аспекта услуги. 'Utility' связан с функциональной полезностью услуги — например, в случае горячего водоснабжения это достаточная температура воды, правильный напор и удобное расположение крана для стирки. 'Warranty' касается качества и надежности услуги — например, режим подачи горячей воды (круглосуточно или с перерывами), скорость реагирования на аварии, длительность профилактических отключений и безопасность состава воды для здоровья. Гарантии должны быть тщательно проработаны поставщиком, согласованы с клиентом, а затем подтверждены в ходе предоставления услуги.

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

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

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

Time to market формируется из двух компонент: Process Time (время фактической работы над изменением) и Queue Time (время ожидания в очереди). Service Quality обратно пропорционально связана с Change Risk - чем выше риски, тем ниже качество услуг. Чем быстрее проводятся изменения (меньше Time to market), тем выше риски для качества услуг, и наоборот - увеличение требований к качеству (Service Quality) ведет к увеличению времени вывода решений. Release rate (частота внедрений) и Release size (размер релиза) также влияют на эту связь: высокая частота малых релизов снижает риски и способствует ускорению Time to market, тогда как редкие крупные релизы увеличивают риски и замедляют процесс. Также важны Change capability (способность команды проводить изменения) и Change Control Level (уровень контроля изменений), которые определяют, как эффективно и качественно проводятся изменения в системе.