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

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

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

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

Стандартное восприятие SLM (Service Level Management) как процесса, который ограничивается подготовкой и актуализацией каталога услуг, SLA и OLA, имеет довольно ограниченное применение. Фактически, создание и поддержка этих документов составляет не более половины содержания SLM как процесса. При этом практика ведения каталога технических услуг и OLA применима лишь к очень небольшой доле компаний, где реализован сервисный подход, а каталог бизнес-услуг с различными уровнями обслуживания востребован преимущественно в сценариях массового обслуживания. Это восприятие важно осознавать, особенно когда процесс управления уровнем услуг сводится только к документированию.

Для управления сложными изменениями с несколькими координаторами рекомендуется создать централизованную группу управления изменениями (Change Advisory Board), которая будет координировать работу всех участников процесса. Необходимо четко определить роли и ответственность каждого координатора, наладить коммуникацию между командами и использовать инструменты автоматизации для отслеживания статуса изменений. Также важно разработать протоколы согласования изменений и внедрить этапы тестирования и обратной связи перед реализацией.

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

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

Business Relationship Management (BRM) и Service Level Management (SLM) служат основой для ИТ-бюджетирования, поскольку через них определяются потребности бизнеса и ожидаемые объемы потребления услуг. BRM обеспечивает понимание стратегических бизнес-планов и целей, а SLM переводит эти цели в конкретные соглашения об уровне услуг с заказчиками. Эти данные являются отправной точкой для всего процесса бюджетирования, обеспечивая, что ИТ-бюджет будет согласован с бизнес-потребностями и направлен на достижение конкретных результатов.

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