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

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

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

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

Традиционный подход «вешать просрочку на последнюю группу» неэффективен по нескольким причинам: 1) Последняя группа могла получить инцидент уже близко к окончанию срока или даже после его нарушения, поэтому вменение ей полной ответственности за просрочку несправедливо; 2) Такой подход создаёт негативную мотивацию для групп, так как они стремятся как можно быстрее перенаправить инциденты в другие группы ('футбол'), чтобы избежать ответственности; 3) Игнорируется сложность многоэтапной обработки инцидентов, где задержки накапливаются на разных этапах и являются результатом совокупного влияния нескольких групп.

Существуют логичные сочетания ИТ-процессов, которые способны обеспечить 100% загрузку менеджера в крупной компании. К таким комбинациям относятся, например, управление сервис-уровневыми соглашениями (SLM) совместно с работой в рамках совета по изменениям (PRB), управление изменениями (CHG) в сочетании с управлением конфигурациями (CFG), а также управление инцидентами (INC) даже без дополнительных процессов. Эти пары процессов взаимодополняют друг друга и позволяют оптимизировать работу менеджера, обеспечивая ему комплексную ответственность за ключевые аспекты ИТ-сервисов.

После внедрения ITSM ресурсное планирование становится более сложным, так как определение потребностей уже учитывает не только выполнение новых проектов и внедрений, но и изменение объёма потребления ИТ-услуг. Это требует более точного прогнозирования потребностей и гибкого регулирования ресурсов в зависимости от спроса на услуги.

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

Основные недостатки MAC-модели: 1) Низкая гибкость — все ресурсы одного уровня допуска (например, 'секретно') доступны всем, у кого есть мандат на этот уровень, что не учитывает индивидуальные обязанности пользователей. 2) Сложность управления при увеличении количества классов секретности: если добавить новый гриф (например, 'для внутреннего пользования'), система становится громоздкой и менее наглядной. 3) Необходимость жёсткой классификации всех данных, что требует постоянного мониторинга и обновления грифов при изменении важности информации. 4) Несоответствие бизнес-логике — модель подходит для военных и государственных структур, но слабо применима в коммерческих организациях, где доступ должен учитывать функции сотрудников, а не статус секретности.

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