5.9 Проектирование сервисов

Обзор и мотивация

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

Это различие «за стойкой» суть дела. Проектирование сервисов делит мир на передний план, то есть всё, что пользователь видит и трогает, и задний план, то есть людей, системы и процессы, оказывающие сервис, но остающиеся невидимыми пользователю. Хорошие впечатления переднего плана постоянно проваливаются, потому что задний план не может их поддержать. Гладкая форма бронирования, сливающая данные в таблицу, которую сотрудник проверяет дважды в день, это быстрый передний план, прикрученный к медленному заднему, а пользователь ощущает несоответствие как трёхдневное молчание. Проектирование всего сервиса означает проектирование обеих половин вместе и швов между ними.

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

Ключевые принципы

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Сквозное владение сервисом (одна команда владеет путём)	Ясная подотчётность, связный опыт, швы проектируются	Пересекает существующую оргструктуру, трудно укомплектовать и финансировать, может стать узким местом
Владение по каналам или шагам	Вписывается в существующие команды, ясный локальный охват, легко укомплектовать	Целым никто не владеет; разрывы между каналами; локальная оптимизация
Полное составление плана сервиса заранее	Выявляет отказы заднего плана до поставки, общее понимание	Трудоёмко, может устареть, риск анализа вместо действия
Только лёгкая карта пути	Быстро, дёшево, достаточно для выявления худших разрывов	Упускает отказы заднего плана и систем, которые поймал бы план
Омниканальная согласованность (единая по каналам)	Бесшовные передачи, контекст переносится между каналами	Дорогая интеграция, требует общих данных и выровненных команд

Центральное напряжение между сервисом, который нужен пользователю и который течёт через ваши границы, и организацией, которая у вас есть и которая нарисована вдоль них. Разрешайте его пропорционально, а не догматично. Вам не нужно реорганизовывать всю компанию, чтобы хорошо спроектировать один сервис, но вам нужен хотя бы один человек или команда, подотчётные за сквозной результат, вооружённые планом, делающим задний план видимым, и мандатом исправлять швы. Тратьте самое тяжёлое составление планов на пути большого объёма, высоких ставок или высокой доли отказов, а для остальных используйте более лёгкие карты путей. Цель не совершенный артефакт; это сервис, работающий для человека в его центре.

Вопросы для обсуждения с командой

Кто владеет всем сервисом от конца до конца, от первого намерения пользователя до его реального результата, и какая у него реально власть? В большинстве больших организаций честный ответ «никто», потому что владение разделено по каналам и отделам, а каждый владелец оценивается по своему ломтику. Этот пробел то место, где сервисы проваливаются, поскольку швы между владельцами никому не принадлежат и не получают внимания. Решите, создадите ли вы явного сквозного владельца, владельца сервиса или владельца пути, и будьте ясны, может ли этот человек действительно менять системы заднего плана и границы команд или лишь отвечает за метрику, которую не может сдвинуть. Принесите вашу текущую оргсхему и план вашего главного пути и положите рядом, чтобы увидеть, кто касается пути и кто за него подотчётен. Если двое не совпадают, вы нашли источник ваших худших отказов передач. Ответ должен изменить то, как вы финансируете и комплектуете работу, а не только то, кто приходит на стендап.
Очерчены ли наши команды вокруг пути пользователя или вокруг нашего внутреннего удобства и готовы ли мы это менять? Закон Конвея (глава 1.2) означает, что ваш сервис будет отражать вашу коммуникационную структуру, хотите вы того или нет, поэтому путь, разбитый на четыре немногословные команды, будет ощущаться как четыре разрозненных шага. Удобный ход исправить экраны и оставить оргсхему в покое, но это лечит симптом, пока причина продолжает его воспроизводить. Честно взгляните, создают ли границы ваших команд те самые разрывы передач, на которые жалуются ваши пользователи, и взвесьте реальную цену перестройки команд против постоянной цены фрагментированного опыта. Принесите боли с вашей карты пути и проверьте, сколько из них лежит точно на границе команд. Если большинство, лучший UI вас не спасёт, и разговор должен идти о проектировании команд. То, что вы решите здесь, определяет, закрепятся ли улучшения сервиса или тихо размоются.
Насколько хорошо наши инструменты для персонала служат людям, которые ими пользуются, и как это проявляется для клиента? Внутренние инструменты самое надёжно пренебрегаемое программное обеспечение в любой большой организации, потому что их пользователи «пленные», а бюджеты запоздалая мысль, однако социальный работник или сотрудник, борющийся со сломанной консолью, передаёт это трение прямо клиенту как задержки и ошибки. Спросите, когда вы в последний раз проводили исследование собственных систем для персонала или предполагаете, что раз сотрудникам платят за терпение, то инструменты в порядке. Учтите, что задний план то место, где происходит большинство молчаливых отказов сервиса, в ручном повторном вводе и потерянном контексте на передачах, ничего из чего метрики переднего плана не видят. Приведите настоящего сотрудника в комнату и понаблюдайте, как он выполняет обычную задачу, затем проследите, как его борьба доходит до клиента. Если вы никогда не финансировали внутренние инструменты как продукт, это, вероятно, ваше дешёвейшее большое улучшение сквозного качества сервиса.
Какая единственная сквозная метрика сказала бы нам, работает ли весь сервис на самом деле, и почему мы не отслеживаем её сегодня? Для большой команды этот вопрос неудобен, потому что честный ответ обычно в том, что у каждого канала и отдела зелёная локальная метрика, а никто не измеряет, получил ли человек то, за чем пришёл. Доли завершения форм, время обработки звонков и числа закрытых заявок все льстят владельцу, который о них докладывает, и каждая может оставаться здоровой, пока объединённый результат проваливается в очереди заднего плана. Решите сквозную меру завершения или сквозного времени, следующую за пользователем от первого намерения до реального результата, и будьте ясны, кто будет инструментировать её через системы, никогда не строившиеся для обмена данными. Принесите текущие панели по каналам, план одного пути большого объёма и оценку молчаливого отсева между каналами, чтобы разрыв между локальным зелёным и сквозным красным был виден. В корпоративной и государственной среде договоритесь, кто подотчётен за число всего пути и у кого полномочия действовать по нему, потому что метрика, которую не может сдвинуть ни один владелец, метрика, ничего не меняющая.
Где наш сервис заставляет пользователя повторяться и во сколько обошлась бы версия «скажите нам один раз»? Дублированный сбор данных яснейший сигнал того, что сервис организован вокруг ваших внутренних границ, а не потребности пользователя, и он дорог с обеих сторон: пользователь заново вводит те же свидетельства на каждой передаче, а каждый отдел платит за повторный сбор и проверку. Конкурирующее соображение в том, что общая запись, делающая возможным «скажите нам один раз», требует интеграции между системами и командами, у которых может не быть истории доверия к данным друг друга, поэтому цена построения и работа по управлению данными реальны. Принесите карту пути, размеченную каждой точкой, где пользователь предоставляет информацию, которой вы уже располагаете, и грубый подсчёт, сколько отдельных записей хранит одно и то же поле. Для государственной услуги, охватывающей несколько ведомств, добавьте правовое основание для обмена этими данными между ними, поскольку согласие, закон о приватности и правила управления информацией решают, разрешено ли «скажите нам один раз» вообще, до того как вы спросите, доступно ли оно по цене.
Когда контекст передаётся между командой, системой или каналом, что на самом деле едет с делом и что происходит, когда передача проваливается? Передачи то место, где сервисы ломаются молча, потому что отказ невидим для всех, кроме пользователя, оставшегося ждать, а в большой организации каждая передача пересекает границу, где ни один владелец не чувствует ответственности за потерянное. Решите намеренно, какие данные, история и статус должны двигаться с делом, видит ли принимающая сторона их и каков путь восстановления, когда передача застряла или пришла неполной. Принесите ваш план сервиса для настоящего пути и проследите каждую линию, где дело переходит из рук в руки, отметив, какой контекст сохраняется, а какой заново вводится или теряется. В корпоративных и государственных сервисах, связанных соглашениями об уровне обслуживания или установленными законом сроками ответа, воспринимайте каждую передачу как явный контракт с согласованным контекстом и определённым запасным вариантом, потому что недокументированная передача нарушение, ждущее своего часа, о котором не предупредит ни одна панель.

Взгляд по секторам

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

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

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

Государственный сектор. Услуги должны быть организованы вокруг жизненного события гражданина, а не структуры ведомства, и подчиняться опубликованным стандартам услуг с прозрачностью и публичной подотчётностью. Правила закупок формируют то, что вы можете построить, поэтому отдавайте предпочтение общим записям и шаблонам «скажите нам один раз» там, где есть правовое основание для обмена данными, и документируйте это основание до проектирования потока. Исследуйте с настоящими пользователями, включая самых уязвимых, составляйте план межведомственного заднего плана и измеряйте весь путь, а не ломтик каждого ведомства, потому что общество судит об услуге по тому, получило ли оно результат, а не по тому, какой отдел преуспел.

Примеры

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

Крупная организация. Телекоммуникационная компания продавала бизнес-интернет с двухминутным онлайн-заказом и двухнедельным кошмаром доставки. Продажи, развёртывание, полевая инженерия и выставление счетов каждый владел отрезком пути и каждый выполнял свои цели, тогда как клиент переживал повторные запросы той же информации, пропущенные окна визитов и первый счёт, не совпадавший с предложением. Составление плана сервиса по всем четырём отделам вскрыло швы: контекст умирал на каждой передаче, потому что не было общей записи заказа, следующей за клиентом. Компания назначила сквозного владельца от заказа до активации, построила общую запись дела, путешествовавшую с заказом, и перестроила стимулы команд вокруг объединённого результата. Локальные метрики почти не изменились; сквозное время активации и доля жалоб резко упали.

Государственный сектор. Национальное правительство переработало свою услугу «смерть члена семьи», одно из самых трудных жизненных событий, с которыми сталкивается гражданин. Раньше скорбящий должен был отдельно уведомлять налоговый орган, пенсионную службу, ведомство транспортных средств, паспортный стол и местное самоуправление, у каждого своя форма и каждый требует то же свидетельство о смерти. Организовав услугу вокруг жизненного события, а не ведомств, команда построила единый путь «скажите нам один раз», брал введённую человеком информацию и распределял её по каждому соответствующему отделу за линией видимости. Выравниваясь по стандарту услуг государственного сектора, они исследовали с недавно овдовевшими людьми, составили план межведомственного заднего плана и измеряли весь путь, а не часть каждого ведомства. Завершение выросло, дублированные обращения упали, и гражданам больше не приходилось переживать утрату заново дюжину раз.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от проектирования сервисов приходит от закрытия разрывов между каналами и командами, потому что именно там утекает ценность. Сквозные отказы дороги способами, которые панели по каналам скрывают: путь, завершающийся онлайн, но проваливающийся на заднем плане, порождает обращение в поддержку, повтор и нередко потерянного клиента, и ни одна из этих затрат не ложится на канал, выглядящий успешным. Когда вы измеряете и исправляете весь сервис, вы снижаете дублированные усилия (одни и те же данные собираются пять раз), спрос из-за отказов (обращения, вызванные исключительно тем, что сервис подвёл с первого раза) и отток от опыта, ощущавшегося сломанным, даже когда каждая часть технически работала. В корпоративной среде отдача проявляется как более короткие циклы от заказа до оплаты и меньше эскалаций; в государстве как ниже стоимость обслуживания и выше успешное завершение услуг, которые люди не могут получить нигде больше.

Совокупная стоимость владения должна взвешивать цену проектирования сервисов против гораздо большей цены фрагментации, которую вы уже несёте. Видимые затраты это исследование, составление планов, координация между командами и иногда вложения в общие системы и инструменты для персонала. Скрытые цены непроведения разбросаны по бюджетам поддержки, операций и репутационного ущерба, именно поэтому руководство их недооценивает: бюджет ни одной команды не показывает полную цену сломанной передачи. Чтобы обосновать это, выразите числом спрос из-за отказов и дублированную работу на одном пути большого объёма, составьте его план и покажите руководству, какая доля стоимости сидит в швах между их существующими командами. Затем проведите ограниченный пилот на этом пути, измерьте сквозные показатели до и после и используйте результат для обоснования более трудных структурных изменений. Формулирование проектирования сервисов как устранения затрат, которые уже платятся, просто невидимо, обычно убеждает финансовых и управляющих заинтересованных лиц сильнее любого призыва к элегантности.

Антипаттерны и ловушки

Острова каналов. Каждый канал проектируется и измеряется сам по себе, так что путь выглядит нормально везде и не работает от конца до конца нигде.
Помада на переднем плане. Отполированный UI, прикрученный к медленному или ручному заднему плану, так что опыт ломается в миг, когда пользователю нужен отклик заднего плана.
Оргсхема как сервис. Сервисы, структурированные вокруг ваших отделов, а не цели пользователя, заставляющие пользователя ориентироваться во внутренних границах.
Театр планов. Изощрённые планы, нарисованные раз, которыми любуются и которые никогда не используют для изменения того, как сервис на самом деле работает.
Картирование только счастливого пути. Пути и планы, игнорирующие отказ и восстановление, а именно там реальные сервисы причиняют боль.
Пренебрегаемые инструменты персонала. Воспринимание внутренних систем для персонала как второсортных, так что их трение утекает прямо к клиенту.
Амнезия передач. Контекст, теряемый на каждой передаче между командой, системой или каналом, так что пользователь объясняет свою ситуацию снова и снова.
Лестные метрики. Локальные цели по каналам, остающиеся зелёными, пока сквозной результат молча проваливается.

Модель зрелости

Уровень 1, Начальный: Каждый канал и команда проектируются и ведутся изолированно, реактивно. Никто не владеет сквозным сервисом, нет ни карты пути, ни плана, а отказы заднего плана остаются невидимыми, пока не проявятся как жалобы. Пользователи регулярно повторяются через каналы, потому что никто не смотрел на целое.
Уровень 2, Развитие: Некоторые пути нанесены на карту, и худшие межканальные разрывы известны, но практика пятнами и зависит от энтузиазма отдельных людей. Карты путей существуют, но редко доходят до заднего плана, владение всё ещё по каналам, инструменты для персонала запоздалая мысль, а составление планов там, где происходит, различается от команды к команде.
Уровень 3, Стандартизация: Ключевые пути составлены в планах от переднего до заднего плана с операционным персоналом по документированному методу, применяемому последовательно по организации. Названные владельцы сервиса подотчётны от конца до конца, передачи явные контракты с согласованным контекстом, инструменты персонала проектируются намеренно, а подход принуждается, а не необязателен.
Уровень 4, Управление: Сервис измеряется и контролируется данными. Сквозное завершение, сквозное время (включая невидимые ожидания заднего плана), усилия пользователя, спрос из-за отказов и отсев между каналами отслеживаются относительно базовых значений, а отказы передач и дублированный сбор данных количественно оцениваются, а не предполагаются. Планы поддерживаются актуальными, владельцы сервисов отвечают за сквозные цели, а решения «пускать или нет» по изменениям опираются на эти свидетельства, а не локальные метрики каналов.
Уровень 5, Оркестрация: Проектирование команд и проектирование сервиса выровнены, так что владение следует за путём, а организация структурирована вокруг целей пользователей и жизненных событий, а не отделов. Сквозные метрики управляют приоритизацией, организация непрерывно составляет планы, измеряет и перестраивает вместе и опыт, и операции, и адаптирует весь сервис по мере сдвигов потребностей пользователей, каналов и междукомандных границ.

Идеи для обсуждения

Когда путь пересекает несколько команд, лучше назначить одного сквозного владельца или перерисовать команды вокруг пути и что определяет выбор?
Какую долю качества сервиса можно исправить лучшим дизайном переднего плана, а какая требует изменения заднего плана или оргсхемы?
Где в вашем сервисе пользователям чаще всего приходится повторяться и во сколько обошлась бы версия «скажите нам один раз»?
Как финансировать и приоритизировать инструменты для персонала, когда их пользователи «пленные» и не могут проголосовать ногами?
Следует ли организовывать сервисы вокруг жизненных событий или целей пользователей, даже когда это прямо идёт против ваших линий финансирования и отчётности?
Какая единственная сквозная метрика лучше всего сказала бы, работает ли весь ваш сервис, и почему вы не отслеживаете её сегодня?

Главные выводы

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

Источники и дополнительное чтение

Marc Stickdorn and Jakob Schneider, This Is Service Design Thinking
Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider, This Is Service Design Doing
Andy Polaine, Lavrans Lovlie, and Ben Reason, Service Design: From Insight to Implementation
Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review
Matthew Skelton and Manuel Pais, Team Topologies
Melvin Conway, “How Do Committees Invent?“, Datamation
UK Government Digital Service, Service Manual and the Service Standard
U.S. General Services Administration, 18F Methods and the U.S. Digital Service Playbook
Nielsen Norman Group, articles on service blueprinting and customer journey mapping

5.9 Проектирование сервисов

Обзор и мотивация

Ключевые принципы

Рекомендации

Нанесите путь клиента на карту через каждый канал

Стройте план сервиса, связывающий передний план с задним

Проектируйте задний план и инструменты для персонала как первоклассные

Выравнивайте проектирование команд с проектированием сервиса

Измеряйте качество сервиса от конца до конца