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

Для внутреннего ИТ-провайдера ответы на вопросы портфеля услуг выглядят иначе, чем для внешнего. Клиенты должны покупать услуги, потому что без них бизнес-процессы работать не смогут. Выбора у клиента нет, так как ИТ-отдел - единственный поставщик. Цену услуг не придумывают, а только рассчитывают себестоимость по согласованной методике, монетизация происходит через утверждение бюджета. Сильная сторона - безальтернативность, слабая - восприятие как центра затрат, приоритет - усиление безальтернативности, риск - возможная замена на внешнего провайдера для части услуг. Распоряжение ресурсами происходит по традиционной схеме: получение задачи, ТЗ, проект, закупка ресурсов, эксплуатация.

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

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

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

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

Желания (Запад) в модели Compass Model представляют собой менее конкретные, не всегда осознаваемые потребителем, цели и пожелания. Эти пункты не являются критически необходимыми, но существенно повышают удовлетворённость, когда реализуются. Чтобы выявить желания, следует задавать вопросы: "Что клиент хотел бы дополнительно?", "Какие необязательные элементы улучшили бы его опыт?" Например, для такси в командировке желаниями могут быть: прибытие вовремя, вежливый водитель, комфортная езда, приятная музыка и отсутствие навязчивых разговоров. Желания часто определяют дифференциацию сервиса и возможность превосходства над конкурентами.

Процесс Управления инцидентами обеспечивает прозрачность в работе за счёт своевременной и эффективной передачи информации об инцидентах и их статусах. Для этого процесс должен быть построен так, чтобы пользователь получал нужную информацию в согласованные с заказчиком моменты времени и в согласованном формате через согласованные каналы. Это могут быть электронные письма, SMS, информация на портале самообслуживания (в личном кабинете), телефонные звонки или даже личные визиты в случае работы с VIP-пользователями. Процесс INC должен минимизировать количество повторных обращений пользователей по тем же инцидентам за счёт качественного информирования, что отражается в KPI: «Среднее число звонков на Service Desk и прочих контактов со стороны бизнес-пользователей по поводу уже зарегистрированных инцидентов».

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

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