В ITSM процессное управление с метриками внедрено системно: в регламенты процессов заложены точки измерения, оценки и принятия решений, что делает управление более прозрачным и объективным. В разработке ПО часто преобладает проектный подход с фокусом на калendарные планы, отсутствием процессного мышления и измерения эффективности работы. Разработка ПО часто воспринимается как чисто творческий процесс, где измерения кажутся ненужными или слишком сложными для внедрения.

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

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

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

При применении цикла Деминга в улучшении процессов могут быть допущены следующие ошибки: 1) Недостаточная детализация плана на этапе Планируй, что приводит к непродуктивному выполнению; 2) Недостаточное время для реализации изменений на этапе Выполняй, не позволяющее получить статистически значимые результаты; 3) Неполная проверка результатов на этапе Проверяй из-за выбора неадекватных метрик или неправильной интерпретации данных; 4) Поспешные решения на этапе Корректируй без глубокого анализа причин неудачи. Например, в описанном случае с управлением инцидентами первой попыткой не было учтено влияние большого количества простых инцидентов на обработку сложных, что привело к новой проблеме.

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

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

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

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

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