Стандарт INCITS 494-2012 делит ограничения на статические и динамические. Динамические ограничения включают: Роль-роль (запрет на одновременное использование ролей в одной сессии), Пользователь-роль (запрет пользователям исполнять данную пару ролей параллельно) и Атрибут (запрет на использование роли или прав доступа в зависимости от значения атрибута, такого как время суток, местоположение, цель использования и другие). Статические ограничения включают: Роль-роль (запрет на назначение роли конкретному пользователю), Пользователь-роль (запрет определённым пользователям быть назначенными на пару ролей), Права доступа-права доступа (запрет на комбинации прав доступа в роли) и Права доступа-роль (запрет на использование конкретных прав доступа в определенной роли).

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

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

В рамках процесса управления сервисными активами и конфигурациями должны быть четко определены следующие роли и ответственности: ответственные за идентификацию и учет конфигурационных единиц, специалисты, отвечающие за поддержание актуальности данных CMDB, члены Совета по изменениям (CAB), ответственные за авторизацию базовых состояний, изменений и релизов, владельцы конфигурационных единиц, ответственные за проверку корректности и полноты информации. Также важно определить взаимодействие с другими процессами, например, с управлением изменениями, управлением релизами и службой Service Desk, чтобы обеспечить четкую передачу ответственности за обновление данных конфигурации на всех этапах жизненного цикла сервисов.

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

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

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

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

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

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