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

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

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

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

Lean и Six Sigma сосредоточены на оптимизации внутренних процессов компании, минимизации потерь и повышении качества. Их связь с CXM проявляется в том, что многие бизнес-процессы, которые улучшаются по методологиям Lean/Six Sigma, напрямую влияют на клиентский опыт. Например, сокращение времени обработки заявки улучшает удовлетворенность клиента. Современные практики объединяют эти подходы: команды CXM инициируют изменения, ориентированные на клиента, а команды Lean/Six Sigma внедряют их с точки зрения операционной эффективности. Это создает синергию, где клиентская ценность становится центральным критерием оптимизации процессов.

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

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

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

Для определения, какие метрики следует измерять с учетом их важности, помогает метод анализа через Causal Loop Diagram (CLD), который отображает причинно-следственные связи между элементами системы управления. Анализируя CLD, можно определить относительную важность разных показателей по силе их влияния на конечный результат. Это позволяет принимать обоснованное решение о том, на какие метрики стоит тратить ресурсы для измерения, а какие могут быть опущены из-за низкого влияния на общий результат или чрезмерной сложности измерения.

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