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

В управлении конфигурациями существуют альтернативы сервисно-ресурсной модели, такие как классические CMDB-подходы (Configuration Management Database), базирующиеся на иерархическом представлении конфигурационных элементов. Также можно использовать упрощенные подходы, фокусирующиеся только на критически важных элементах инфраструктуры. Некоторые организации применяют гибридные модели, сочетающие элементы различных подходов, чтобы соответствовать своим специфическим потребностям без избыточного усложнения.

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

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

В условиях строгих ограничений на численность штата ИТ-руководители активно используют аутсорсинг и аутстаффинг для выполнения задач. Также широко практикуется передача функций в регионы с более низким уровнем заработных плат – например, создание центров разработки и поддержки в городах России, отличных от Москвы и Санкт-Петербурга, таких как Волгоград, Нижний Новгород и Новосибирск. Это позволяет частично сократить затраты на персонал, сохранив необходимый объем работы.

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

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

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

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

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