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

CMDB (Configuration Management Database) необходима для хранения точной и надёжной информации о конфигурационных элементах, которые требуются для предоставления ИТ-услуг. Её основное назначение — обеспечить контроль над активами, задействованными в сервисах, и предоставлять актуальные данные о них в нужное время и в нужном месте. Это позволяет поддерживать согласованность инфраструктуры, минимизировать ошибки при проведении изменений и ускорять процессы восстановления работоспособности систем.

«Доска аварий» — это инструмент, предназначенный для быстрого и наглядного отображения текущих инфраструктурных инцидентов, которые могут влиять на предоставляемые ИТ-услуги. Она позволяет визуализировать проблемные зоны инфраструктуры, чтобы оперативно оценивать возможные причины неполадок, диагностировать ситуации и информировать пользователей. Однако её эффективность зависит от точности отражения реального влияния инцидентов на бизнес-процессы и конечных пользователей.

ITIL рекомендует определять приоритеты изменений через конкретные критерии: оценку влияния на бизнес и жёсткие временные рамки. Например, если бизнес требует реализовать изменение к определённому сроку («завтра»), это напрямую задаёт временные ограничения. Второй критерий — степень влияния изменения на ключевые процессы: если отсутствие правки приведёт к остановке бизнес-операций, это автоматически получает высший приоритет. Такой подход исключает субъективность и позволяет выстраивать очередь изменений на объективной основе, избегая злоупотребления термином «срочность».

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

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

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

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

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

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