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

Для решения проблем требуются координаторы, отвечающие за конкретную проблему и взаимодействие со смежными группами (разработчики, архитекторы, администраторы). Координатор назначается при регистрации проблемы и отслеживает этапы диагностики, согласование решений и внедрение изменений. Эта роль отсутствует в стандартном управлении инцидентами, где ответственность обычно лежит на L2/L3 поддержке. Также в процессе прописывается контроль за деятельностью координаторов через регулярные отчёты и проверки.

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

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

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

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

В качестве альтернативы подходу ITIL предлагаются три подпроцесса: Business Capacity Management (управление бизнес-мощностями), System Capacity Management (управление системной мощностью) и Resource Capacity Management (управление ресурсной мощностью). Это деление более точно отражает уровни, на которых происходит управление мощностями, в зависимости от того, как определены ИТ-услуги (через бизнес-процессы, ИТ-системы или ресурсы).

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

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

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