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

Предлагаются две стратегии. Первая заключается в установлении высокого показателя своевременности (95%) при относительно большом целевом времени решения (8 часов), с последующим его постепенным сокращением. Вторая стратегия предполагает установление более жестких сроков решения (например, 2 часа) с начальным показателем своевременности в 50%, который постепенно увеличивается до целевых 80-90%. Автор рекомендует вторую стратегию как более эффективную для быстрого восстановления и снижения количества инцидентов.

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

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

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

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

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

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

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

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