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

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

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

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

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

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

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

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

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

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