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

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

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

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

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

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

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

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

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

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