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

Flow Efficiency может ошибочно показывать завышенные значения (90% и более) из-за методологических ошибок в расчете. Например, если учитывать только рабочее время, но неправильно определить время активной работы (Touch Time), то числитель может оказаться неадекватно большим. Также часто возникает проблема, когда при совместной работе нескольких сотрудников время работы учитывается не корректно (например, суммируются часы всех участников, тогда как фактически задача выполнялась параллельно). Кроме того, некоторые автоматизированные инструменты могут неправильно интерпретировать изменения статусов задач, принимая за активную работу периоды ожидания. Все эти факторы приводят к искажению результата и созданию иллюзии сверхвысокой эффективности, не соответствующей реальности.

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

Используемая ITSM-система существенно влияет на решение о разделении процессов. Многие современные ITSM-продукты, такие как HP SM или BMC Remedy ITSM Suite, реализуют строгое разделение инцидентов и сервисных запросов как разные объекты с разными возможностями обработки, что стимулирует организации следовать этой практике. Если система не поддерживает гибкой переклассификации обращений, это может усилить проблемы, связанные с нечеткими границами между типами запросов. Некоторые системы, как HP OpenView Service Desk, предлагают альтернативные подходы к разделению (например, по источнику запроса), что может оказаться более практичным. Поэтому решение о разделении процессов должно учитывать как практические потребности организации, так и возможности используемого инструментария.

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

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

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

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

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

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