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

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

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

Смешение понятий назначения (purpose), целей (goals) и задач (objectives) в управлении процессами приводит к: - Путанице в формулировках: цели нечётко связаны с бизнес-требованиями, назначение дублирует оперативные задачи. - Сложностям управления: если цели фиксируются в регламенте, а не в текущих планах, документ становится устаревшим после каждого пересмотра целей. - Проблемам с ответственностью, так как дизайнер процесса вместо определения базового назначения начинает формулировать краткосрочные цели. - Несоответствию процесса бизнес-целям: без чёткой связи между стратегическим назначением и оперативными задачами сложно измерить вклад процесса в бизнес-результаты. - Отсутствию иерархии: руководители пытаются управлять стратегическими и оперативными аспектами одновременно, тратя ресурсы на нерелевантные задачи.

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

Работая на стороне заказчика в клиентской компании, автор имел рабочую загрузку в пределах 70-80%. В этом режиме времени обычно хватало не только на выполнение всех поставленных задач, но и на изучение новых технологий, управленческих методик и других интересных направлений. Хотя иногда случались авралы и завалы, в среднем за период рабочего времени баланс был приемлемым. В консалтинге же уровень загрузки значительно вырос — до 120-130%, а в пиковые периоды достигал 160%. Это привело к острой нехватке времени и поставило вопрос 'как это всё вообще можно успеть', требуя поиска специальных подходов к управлению временем и повышению личной эффективности.

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

Геометрическая фигура треугольника/пирамиды используется для наглядного представления взаимосвязи основных параметров проекта: сроков, затрат и результата. Жесткость этой фигуры символизирует, что изменение одного из параметров неизбежно влияет на другие. Например, при сокращении сроков проекта, как правило, потребуются дополнительные затраты или снижение объема работ, а иногда и качества конечного результата. Эта модель помогает визуализировать баланс между ключевыми ограничениями проекта.

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

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