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

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

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

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

В комбинированной модели количество необходимых ролей рассчитывается как 2 в степени количества статических атрибутов, а количество атрибутных правил - как 2 в степени количества динамических атрибутов. Например, в системе с 7 статическими и 3 динамическими атрибутами потребуется 2^7 = 128 ролей и 2^3 = 8 атрибутных правил, что значительно меньше 1024 ролей, необходимых в классической ролевой модели с 10 атрибутами. Это объясняется тем, что комбинированная модель разделяет ответственность: статические атрибуты управляются через роли, а динамические - через атрибутные правила.

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

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

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

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

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