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

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

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

Переносить данные из внешних систем в CMDB следует в случаях, когда необходим: 1) Повышение удобства доступа для пользователей - возможность просмотра информации без перехода между системами; 2) Реализация поиска и фильтрации - когда требуется выполнение операций поиска или группировки конфигурационных элементов по определенным атрибутам; 3) Формирование отчетности - если отчеты по конфигурационным элементам требуют использования атрибутов, которые изначально находятся во внешних системах.

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

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

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

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

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

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