Схема сервиса (англ. Service Blueprint) — способ визуализации отношения между различными компонентами услуги — сотрудниками, ресурсами и процессами — которые напрямую связаны с картой пути клиента.
Метод схемы сервиса был разработан Линн Шостак (Lynn Shostack) в 1984 году и впервые описан в её статье “Designing Services That Deliver” в Harvard Business Review. Шостак, имевшая опыт работы в банковской сфере, предложила этот метод как способ систематического проектирования услуг с учетом всех компонентов и взаимодействий, необходимых для их предоставления.
В отличие от многих других методов, которые возникли в промышленном дизайне и были позже адаптированы для цифровых продуктов, схема сервиса изначально создавалась для сферы услуг. Этот метод стал одним из фундаментальных инструментов в развивающейся дисциплине сервис-дизайна.
В 1990-х годах Мэри Джо Биттнер (Mary Jo Bitner) и её коллеги существенно развили методологию, внедрив концепцию “сервисных ландшафтов” и расширив понимание того, как физическая среда влияет на опыт клиентов и сотрудников.
В сферу UX-исследований и дизайна цифровых продуктов схема сервиса пришла в середине 2000-х годов, когда стало очевидно, что цифровые продукты являются частью более широкой сервисной экосистемы. Такие практики как Адам Лоуренс (Adam Lawrence) и Марк Стикдорн (Marc Stickdorn) адаптировали метод для использования в контексте проектирования цифровых услуг, уделяя особое внимание интеграции онлайн и офлайн каналов взаимодействия.
Описание метода
Схема сервиса представляет собой детальную визуальную модель, отображающую весь процесс предоставления услуги, включая видимые для клиента элементы и скрытые внутренние процессы. В отличие от Customer Journey Map, которая фокусируется преимущественно на опыте пользователя, схема сервиса также включает организационные аспекты, необходимые для создания этого опыта.
Традиционно схема сервиса разделяется на несколько горизонтальных слоев или “дорожек”, отделенных линиями:
- Действия пользователя — шаги, которые предпринимает клиент
- Линия взаимодействия — разделяет действия клиента и сотрудников
- Фронт-сцена — видимые действия сотрудников и системы, с которыми взаимодействует клиент
- Линия видимости — разделяет то, что видно клиенту, и внутренние процессы
- Бэк-сцена — невидимые для клиента действия сотрудников
- Линия внутреннего взаимодействия — разделяет процессы обслуживания и поддерживающие процессы
- Поддерживающие процессы — внутренние системы и процессы, обеспечивающие сервис
Типология метода
- Тип данных: качественный
- Модерация: модерируемый (групповые сессии с представителями разных отделов)
- Продолжительность: от нескольких дней до нескольких недель (зависит от сложности сервиса)
- Формат проведения: очные или удалённые воркшопы с участием проектной и операционной команд
Цели и задачи метода
Схема сервиса направлена на решение следующих задач:
- Визуализация целостного процесса предоставления услуги во всех его аспектах
- Выявление взаимосвязей между клиентским опытом и внутренними процессами
- Определение критических точек в обеспечении качества сервиса
- Идентификация возможностей для оптимизации ресурсов и процессов
- Улучшение координации между различными отделами и участниками предоставления услуги
- Планирование инфраструктуры и ресурсов, необходимых для поддержки клиентского опыта
- Выявление потенциальных точек отказа и разработка планов по их устранению
- Обеспечение согласованности опыта во всех каналах взаимодействия
Применение в процессе Human-Centered Design
Стадия 1. Понимание и определение контекста использования
Вспомогательное применение
- Позволяет визуализировать и проанализировать существующие внутренние процессы, обеспечивающие пользовательский опыт
- Выявляет взаимосвязи между пользовательскими взаимодействиями и бэкенд-процессами
- Демонстрирует точки интеграции между различными системами и департаментами
- Помогает определить организационные и технические ограничения, влияющие на пользовательский опыт
- Создает общее понимание сложности текущих процессов среди всех заинтересованных сторон
Стадия 2. Определение требований пользователей
Основное применение
- Трансформирует понимание внутренних процессов в конкретные требования к системе
- Позволяет выявить ключевые точки взаимодействия, требующие оптимизации
- Помогает определить требования не только к фронтенд-части, но и к бэкенд-процессам
- Обеспечивает согласование пользовательских потребностей с организационными возможностями
- Способствует выявлению скрытых технических требований, критичных для успешного опыта
Стадия 3. Создание проектных решений
Основное применение
- Обеспечивает проектирование целостного сервиса, а не только пользовательского интерфейса
- Позволяет синхронизировать разработку пользовательской части с внутренними процессами
- Помогает визуализировать будущее состояние процессов и взаимодействий
- Способствует созданию более устойчивых и масштабируемых решений
- Обеспечивает баланс между пользовательскими потребностями и техническими возможностями
- Служит инструментом координации работы кросс-функциональных команд
Стадия 4. Оценка проектных решений
Вспомогательное применение
- Предоставляет структуру для оценки не только фронтенд-интерфейсов, но и всей системы в целом
- Помогает выявить скрытые проблемы во внутренних процессах, влияющие на пользовательский опыт
- Позволяет оценить эффективность технических и организационных изменений
- Способствует комплексному анализу производительности всего сервиса
- Обеспечивает основу для итеративных улучшений всей экосистемы
Схема сервиса особенно ценна тем, что выходит за рамки пользовательского интерфейса и позволяет проектировать комплексные сервисы, учитывая как видимые, так и невидимые для пользователя процессы. Этот метод эффективно связывает пользовательский опыт с организационными процессами и технической инфраструктурой. Для получения максимальной пользы от Service Blueprint рекомендуется вовлекать в его создание представителей различных отделов организации – от дизайнеров и разработчиков до операционных специалистов и представителей клиентской поддержки. Важно начинать с текущего состояния (as-is blueprint), чтобы четко понимать существующие ограничения и возможности, а затем переходить к проектированию желаемого состояния (to-be blueprint). Схему сервиса рекомендуется регулярно обновлять, отражая изменения в процессах и технологиях, и использовать как динамический инструмент координации работы различных команд в процессе разработки и внедрения новых решений.
Преимущества и ограничения
Бизнес-выгоды
- Выявление скрытых проблем в операционных процессах, влияющих на пользовательский опыт
- Оптимизация ресурсов и координации между отделами для улучшения сервиса
- Снижение операционных рисков через понимание зависимостей в процессах
Уникальные особенности
- Связывание фронт-офисных взаимодействий с бэк-офисными процессами
- Визуализация многоуровневой структуры сервиса от клиентского опыта до технической инфраструктуры
- Выявление точек отказа и их влияния на общий пользовательский опыт
Оптимальные условия применения
- Сложные сервисы с множественными точками контакта и участниками
- Реорганизация бизнес-процессов с фокусом на клиентский опыт
- Планирование цифровой трансформации сервисных компаний
- Координация улучшений между различными отделами организации
Ограничения
- Высокая сложность создания и поддержания актуальности схемы
- Требует глубокого понимания внутренних процессов организации
- Может быть слишком детальной для принятия быстрых решений
- Статичность модели не отражает динамические изменения в процессах
Структура проведения
1. Подготовка и планирование
- Определение целей создания схемы сервиса
- Определение границ и объема исследуемого сервиса
- Идентификация ключевых стейкхолдеров и участников процесса
- Планирование сбора данных и ресурсов
2. Сбор данных
- Изучение существующей документации о процессах
- Интервью с сотрудниками фронт-офиса и бэк-офиса
- Наблюдение за процессами предоставления сервиса
- Сбор данных о клиентском опыте (возможно, на основе существующей Customer Journey Map)
3. Создание схемы
- Определение ключевых этапов взаимодействия клиента с сервисом
- Отображение действий клиента на каждом этапе
- Документирование видимых (фронт-сцена) элементов сервиса
- Отображение невидимых (бэк-сцена) процессов и взаимодействий
- Идентификация поддерживающих процессов и систем
- Выявление связей между различными уровнями
4. Анализ и оптимизация
- Идентификация точек отказа и узких мест в процессах
- Выявление избыточных или дублирующих действий
- Определение возможностей для автоматизации и оптимизации
- Проектирование улучшенных процессов
- Создание плана внедрения изменений
Вариации метода
Традиционная схема сервиса (Classic Service Blueprint)
Фокусируется на основных компонентах сервиса и взаимодействиях между клиентами и сотрудниками. Включает стандартные уровни: действия клиента, точки контакта, действия сотрудников, внутренние процессы и системы поддержки.
Расширенная схема сервиса (Extended Service Blueprint)
Дополняет традиционную схему дополнительными слоями, такими как эмоциональное состояние клиента, KPI, временные метрики, стоимость процессов и ответственные стороны. Обеспечивает более глубокий анализ эффективности сервиса.
Мультиканальная схема сервиса (Multichannel Service Blueprint)
Специально разработана для визуализации сервисов, предоставляемых через различные каналы (онлайн, мобильные, физические локации). Отображает различия и связи между каналами и обеспечивает согласованность опыта.
Lean Service Blueprint
Упрощенная версия, фокусирующаяся на выявлении и устранении потерь (muda) в сервисных процессах. Часто используется в контексте методологии бережливого производства (Lean) для оптимизации сервисных операций.
Связь с другими методами
Предшествующие методы
- Контекстное интервью — выявляет рабочие процессы сотрудников
- Глубинное интервью — фиксирует опыт клиентов
- Кабинетное исследование — предоставляет общие данные о процессах
- Customer Journey Map (CJM) — задаёт клиентскую перспективу
- Персона — определяет ключевые группы пользователей
Дополняющие методы
- Дизайн-спринты — используют схему для фокуса команды
- User Flow — уточняет отдельные сценарии взаимодействий
- Моделирование бизнес-процессов (BPMN) — детализация внутренней организационной логики
Последующие методы
- Прототипирование — реализует сценарии по выстроенной схеме
- Модерируемое юзабилити-тестирование — проверяет реализованные потоки
- A/B-тестирование (Сплит-тестирование) — проверяет эффективность изменений в процессах
- Операционные метрики — мониторинг бизнес-результатов после изменений (пока как концептуальная ссылка без отдельной статьи)
Заключение
Схема сервиса является мощным инструментом для понимания и оптимизации сложных сервисных систем, связывая видимый клиентский опыт с невидимыми внутренними процессами. В мире, где качество клиентского опыта становится ключевым конкурентным преимуществом, схема сервиса помогает организациям видеть целостную картину всех компонентов, необходимых для создания превосходного сервиса.
Особая ценность метода заключается в его способности преодолевать организационные силосы, создавая общее понимание того, как различные части организации взаимодействуют для создания единого опыта для клиента. Это делает схему сервиса не просто инструментом дизайна, но и мощным средством организационных изменений.
В эпоху цифровой трансформации схема сервиса продолжает эволюционировать, включая новые компоненты, такие как AI и автоматизация, и адаптируясь к всё более сложным сервисным экосистемам. Будущее метода связано с разработкой более динамичных и интерактивных версий схем, которые могут отражать постоянно меняющуюся природу современных услуг и помогать организациям быстрее адаптироваться к меняющимся потребностям клиентов.
Подписывайтесь на наш Телеграмм-канал — анонсы мероприятий, кейсы и статьи, расписание нашей Школы, и многое другое.