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

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

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

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

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

Организации, внедряющие co-creation как модный тренд, часто совершают ошибки: объявляют о co-creation в маркетинговых материалах, но не меняют внутренние процессы; создают видимость участия потребителей без реального влияния на продукт; не обучают сотрудников работе в режиме совместного создания; не определяют чётких правил и границ взаимодействия с клиентами; игнорируют необходимость изменения организационной культуры на более открытую и партнёрскую. Это приводит к разочарованию клиентов, которые ожидают реального участия, но получают лишь поверхностное копирование тренда без его实质ной реализации.

Управление доступностью (AVA) часто не является частью централизованной корпоративной функции, а интегрировано в повседневные ИТ-процессы, поскольку оно связано с рутинным обеспечением качества услуг и оптимизацией систем. Управление непрерывностью (CONT), напротив, часто функционирует как часть корпоративной функции, поскольку его задачи требуют централизованного подхода и координации на уровне всей организации. Это связано с тем, что CONT включает планирование ответа на кризисные ситуации, которые могут затрогивать множество подразделений и требуют разработки единой стратегии восстановления.

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

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

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