Сервисный подход — это метод управления, который необходим прежде всего для решения задач взаимодействия ИТ-службы и заказчиков услуг. Его применение актуально не для всех ИТ-служб, а только в тех случаях, когда между ИТ-службой и заказчиками установлены отношения поставщика и потребителя услуг. Ключевой аспект сервисного подхода — взаимное понимание и приемка со стороны обеих сторон: заказчика и поставщика услуг. Одностороннее применение этого подхода без участия заказчика обычно не приносит ожидаемых результатов и может оказаться бесполезным.

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

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

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

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

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

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

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

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

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