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

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

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

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

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

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

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

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

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

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