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

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

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

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

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

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

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

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

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

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