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

Да, количество аспектов управления проектами может отличаться от шести, рекомендованных в PRINCE2®. Хотя методология определяет конкретный набор из шести аспектов (Сроки, Затраты, Охват, Качество, Выгоды, Риск), это не означает, что других аспектов быть не может. Если для конкретной организации важна дополнительная характеристика проекта и есть (или необходим) соответствующий механизм управления этой характеристикой, то можно выделить дополнительный аспект. Главное, чтобы каждый аспект представлял собой независимый параметр, имеющий свою методику измерения и контроля, и вносил значимый вклад в общее управление проектом.

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

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

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

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

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

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

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

Правила регистрации инцидентов должны основываться на четком определении нормальной работы услуги и согласованных уровней качества. Нужно определить, какие отклонения от нормы требуют немедленного вмешательства, а какие могут обрабатываться в плановом порядке. Критерии регистрации могут включать как технические параметры, так и субъективные факторы, например, недовольство пользователей. Важно, чтобы ответственные лица понимали, при каких условиях регистрировать инцидент, и имели четкий алгоритм принятия решений. Например, руководство ITIL 4 предлагает использовать такие критерии, как «пользователь несчастлив?», чтобы определить, стоит ли классифицировать ситуацию как инцидент.