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

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

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

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

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

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

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

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

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

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