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

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

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

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

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

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

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

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

Концепция ценности услуг в ITIL основывается на двух факторах: функциональности (utility) и гарантии (warranty). Предложенный подход к анализу процессов в ИТ-менеджменте полностью соответствует этой концепции. Результативность процессов является аналогом функциональности — она показывает, насколько процессы полезны и удовлетворяют требованиям бизнеса. Зрелость процессов выступает аналогом гарантии — она отражает уверенность в том, что процессы будут стабильно обеспечивать эту полезность в любых условиях. Таким образом, объединение результативности и зрелости на радарной диаграмме позволяет анализировать ценность процессов так же, как ITIL анализирует ценность услуг.

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