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

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

При изменении бизнес-процессов: 1) Анализировать поддерживаемые системы на предмет появления новых объектов или операций, требующих добавления/изменения системных ролей. 2) Связывать новые роли с исполнителями (должностями или подразделениями), так как сами исполнители могут измениться. Например, если внедряется новый этап в цепочке согласования документов, необходимо создать роль 'Согласующий по новому направлению' и закрепить её за соответствующими сотрудниками. Акцент делается не на соответствие старых и новых ролей, а на актуализацию распределения прав в рамках изменённых процессов.

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

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

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

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

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

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

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