design

Проектирование в ITSM — это целенаправленная работа по переводу потребностей и ожиданий заказчика и других заинтересованных сторон в согласованный образ будущего решения. Обычно проектирование начинается с выявления и уточнения требований (включая требования полезности и требования гарантии), после чего формируется решение: как будет устроена услуга или ИТ-услуга, какие компоненты и взаимодействия потребуются, какие ограничения действуют и как будет обеспечиваться ценность. В практике проектирования услуг это выражается в создании и уточнении сервисной архитектуры, определении целевых характеристик доступности, производительности, безопасности, а также в описании процессов и сервисных операций, необходимых для предоставления и поддержки. Результаты проектирования используются далее в управлении изменениями, управлении релизами и управлении развёртыванием, а также задают основу для управления уровнем услуг и измерения и отчётности. При этом проектирование не равно «рисованию схем»: оно включает согласование компромиссов, оценку риска и обеспечение соответствия требованиям, стандартам и политике. Вне области термина находятся фактическая реализация решения (разработка и настройка), проведение валидации и тестирования как самостоятельной активности и эксплуатационное сопровождение в рабочей среде; проектирование описывает, что и почему должно быть создано, а не выполняет само создание.

Проектирование часто ошибочно отождествляют с разработкой ПО или развёртыванием. На практике проектирование задаёт целевую структуру и характеристики решения, а разработка и развёртывание реализуют это решение в средах и переводят его в рабочую среду через управление изменениями и релизами. Другая распространённая путаница — между проектированием и управлением архитектурой: управление архитектурой поддерживает принципы и целостность архитектуры на уровне организации, тогда как проектирование конкретизирует решение под заданные требования в рамках услуги или продукта. Также проектирование нередко воспринимают как разовую фазу «в начале проекта»; в современных подходах оно итеративно и может уточняться по мере появления обратной связи и изменения спроса, однако это не отменяет необходимости фиксировать решения и допущения, чтобы управлять риском и техническим долгом. Типичная ошибка — фокус только на полезности и игнорирование требований гарантии: решение может выполнять функции, но быть неприемлемым по доступности, надёжности или конфиденциальности. Ещё один риск — проектировать «в вакууме», без вовлечения заказчика, пользователей и команд поддержки; тогда возникают несоответствия процессам предоставления и поддержки и завышенные ожидания по уровню услуги. Наконец, проектирование не является валидацией: проверка того, что решение действительно соответствует требованиям, относится к управлению валидацией и тестированием, хотя критерии проверки должны быть заложены уже на этапе проектирования.