design thinking

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

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