Уровень влияния инцидента напрямую определяет его вес в системе расчета приоритета проблемы. Инциденты с высоким уровнем влияния (например, "Критичный") вносят больший вклад в суммарный вес проблемы, что повышает её приоритет. Точное определение уровня влияния является ключевым фактором для корректной расстановки приоритетов.

Система Управления Конфигурациями (Configuration Management System, CMS) определяется как набор инструментов, данных и информации, которые используются для поддержки процесса управления сервисными активами и конфигурациями. CMS является частью общей системы управления знаниями по услугам и включает в себя инструменты для сбора, хранения, управления, обновления, анализа и представления информации обо всех конфигурационных единицах и их взаимоотношениях. CMS может также содержать информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Кроме того, CMS поддерживается процессом управления сервисными активами и конфигурациями и используется всеми процессами управления ИТ-услугами.

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

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

Чтобы избежать превращения разработчиков в роботов, необходимо сделать их соучастниками происходящего. Это включает вовлечение в процесс co-creation (совместного создания ценности) с другими участниками команды и конечными пользователями продукта. Необходимо обеспечивать прозрачность общего результата работы команды, а не ограничиваться предоставлением отдельных задач по разработке фич. Важно демонстрировать живое влияние их работы на пользователей и бизнес-показатели, а не ограничиваться цифрами типа увеличения конверсии на незначительные проценты. Также полезным может быть временная стажировка разработчиков в поддержке продукта или непосредственно у пользователей, чтобы они могли пережить опыт "в поле" и понять реальный контекст использования создаваемых ими решений. Создание безопасной среды, где можно свободно выражать мнения без поиска виновных и с презумпцией добросовестности, также критически важно для поддержания вовлеченности разработчиков.

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

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

Бэклог команды в иерархии Atlassian состоит из понятных команде конечных элементов, которые могут быть обработаны за один или несколько условных "тактов" (не более некоторого N). Такими элементами являются пользовательские истории и задачи/подзадачи. Эпики, инициативы и темы не входят в бэклог команды, так как они либо слишком велики для непосредственной обработки (эпики), либо служат управленческими группировками (темы), либо относятся к инвестиционному планированию (инициативы).

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

Влияние человеческого фактора снижается через: 1) обучение сотрудников стандартам оформления данных, 2) внедрение валидации полей на этапе ввода, 3) регулярный аудит случайных записей с обратной связью, 4) разделение ролей (например, один сотрудник вносит данные, другой проверяет). Для критически важных метрик можно использовать двухэтапное согласование. В случае классификации инцидентов проверка может выполняться ответственным менеджером перед закрытием обращения.