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

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

Основные ошибки при применении COBIT 5 PAM заключаются в излишней формализации и концентрации на создании документов, а не на реальном управлении процессами. Многие стремятся просто «заполнить требуемые шаблоны», не задумываясь о смысле и практической пользе. Другая распространенная ошибка — ожидание быстрого результата без учета того, что построение стабильной управленческой надстройки требует времени и постепенных улучшений. Также часто недооценивается роль профессионального суждения оценщика, из-за чего попытки механического следования формальным требованиям приводят к искажению результатов оценки. Важно помнить, что модель предназначена для поддержки управления, а не для создания бумажной волокиты.

Розабет Кантер, профессор Гарвардской школы бизнеса, определила три ключевых класса инструментов влияния: 1) Информация — данные, технические знания, экспертиза, знание политической ситуации; 2) Ресурсы — финансовые средства, материальные активы, человеческие ресурсы, время; 3) Поддержка — подтверждение, легитимность, одобрение, защита. Эффективное использование всех трех классов инструментов позволяет сформировать коалицию поддержки изменений и построить процесс внедрения так, чтобы сотрудники воспринимали изменения как свои собственные.

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

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

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

Существует два варианта методики постановки целевого значения для предложенной метрики: а) зафиксировать его, исходя из соотношения длительности отчетного периода к среднему времени решения проблем; б) зафиксировать его на заданном уровне (например, 80-90%), выбрав отчетный период равным или немного большим среднего времени решения проблемы. Второй вариант считается более оптимальным, потому что он позволяет учесть специфику работы команды и реалистичные ожидания, при этом обеспечивая стимул для постоянного мониторинга и улучшения процесса. Выбор периода, сопоставимого со средним временем решения проблем, обеспечивает более точное отражение текущей эффективности работы с проблемами.

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

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