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

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

Для оценки реальной эффективности внедрения ITIL рекомендуется использовать методы количественной и качественной оценки, такие как сравнение KPI до и после внедрения, анализ удовлетворенности пользователей, измерение времени восстановления услуг и соблюдение SLA. Важно также учитывать долгосрочные эффекты и возможные улучшения в коммуникации между ИТ и бизнесом.

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

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

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

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

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

Срочное изменение предполагает определённый временной приоритет, но допускает относительную градацию (например, «очень срочно» или «не так срочно»), что часто ведёт к злоупотреблению термином. Экстренное изменение (emergency) в ITIL — это категория, не подразумевающая градаций: оно требует немедленного выполнения без отлагательств, так как связано с критическими сбоями или угрозами безопасности. Например, если сервис полностью недоступен для клиентов, это emergency — все ресурсы переключаются на его исправление, тогда как «срочное» изменение может укладываться в запланированные сроки.

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