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

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

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

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

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

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

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

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

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

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