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

Баланс между высоким уровнем контроля изменений (Change Control Level) и необходимостью ускорения процессов достигается через оптимизацию размера и частоты релизов. Высокий Change Control Level обычно приводит к увеличению времени обработки изменений (Process Time), поскольку требует тщательного планирования, оценки и тестирования. Однако, переход к частым малым релизам (высокий Release rate и низкий Release size) позволяет поддерживать высокий уровень контроля без значительного увеличения рисков и времени вывода решений. Частые малые внедрения уменьшают сложность каждого отдельного изменения, что делает процесс контроля более эффективным. Также повышение Change capability за счет накопленного опыта и автоматизации стандартных процессов (Standardization/automation) позволяет поддерживать высокий Change Control Level при снижении Process Time. В итоге, вместо жесткого выбора между контролем и скоростью, организация может достичь состояния, где высокий уровень контроля сочетается с высокой скоростью внедрения благодаря оптимизации процессов и непрерывному обучению.

В ITSM процессное управление с метриками внедрено системно: в регламенты процессов заложены точки измерения, оценки и принятия решений, что делает управление более прозрачным и объективным. В разработке ПО часто преобладает проектный подход с фокусом на калendарные планы, отсутствием процессного мышления и измерения эффективности работы. Разработка ПО часто воспринимается как чисто творческий процесс, где измерения кажутся ненужными или слишком сложными для внедрения.

Процесс EDM05 «Обеспечение прозрачности для заинтересованных сторон» отвечает за формирование отчетности и обеспечение прозрачности системы руководства ИТ. Объектом этого процесса также выступают процессы руководства (EDM02–EDM04), а его задача — обеспечить доступность информации о руководстве ИТ для заинтересованных сторон. Практики процесса EDM05 включают оценку требований к отчетности со стороны заинтересованных лиц, определение направления действий в сфере информирования и мониторинг эффективности предоставления отчетности.

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

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

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

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

Бюрократия влияет на работу ИТ-организации отрицательным образом по мере усугубления проблем через замыкание вредоносного цикла. При высоких рисках и низком качестве услуг (Service Quality) люди и организация становятся менее терпимы к изменениям, стремясь минимизировать риски путем введения множества дополнительных согласований и авторизаций. Рост бюрократии (Bureaucracy) увеличивает Process Time (время работы над изменением), что приводит к росту общего Time to market. Увеличение времени вывода решений создает дополнительное давление со стороны бизнеса, что стимулирует проведение срочных изменений с нарушением процессов (Emergency changes), ведущих к новым ошибкам и проблемам. Также бюрократия препятствует свободному обмену знаниями и уроками, поскольку люди занимают оборонительную позицию и боятся ошибок, что приводит к тому, что уроки не извлекаются и из них не делаются выводы, создавая замкнутый цикл постоянного ухудшения ситуации в ИТ-организации.

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