Функционально-процессный дизайн
Стенограмма анонса Игоря Нечаева
зимняя конференция Русской школы сервисного дизайна
Mail.ru headquarters, 19.01.2016
Игорь Нечаев
Анонс мастер-класса по функциональному и процессному проектированию, презентация
Маленькая новогодняя история, которая обнажила некоторые моменты. Имеем серьёзные вложения людей в продукт, а на выходе историю «Новогодние предложения или как не превратить карету в тыкву».
Серьёзные вложения дизайнеров: визуальных, графических просто обрушились банальной неорганизованностью, раскоординированностью, отсутствием пользовательского тестирования…
Мой личный опыт. Я увидел предложение моего банка о том, что стартует новогодняя распродажа. И пусть я не очень люблю участвовать в подобных акциях, я взялся, выбрал товар, положил в корзину, попытался ввести промо-код, получил сообщение, что промо-код не релевантен, потрудился и написал в саппорт; банк не отвечал, я смекнул и попытался обратиться в поддержку ритейлера, выяснилось, что у них поменялся номер телефона, а на сайте был указан другой; я знал, где искать, я дозвонился из-за азарта, и выяснилось, что нет никакой совместной акции с банком; уже банк мне отвечает, что коды надо вводить не вручную, а копировать - смешно, да? - но это сработало; а акция вообще-то только на конкретные товары распространялась. Почувствовал себя дураком.
Вывод.
Две большие компании: оба и банк, и ритейлер из топ-5. У них есть собственные замечательно отстроенные бизнес процессы, но вот в таком партнёрстве всё сыграло в обратную сторону. Если сервис каждого оценить меньше, чем в единицу, то при перемножении значений меньше единицы суммарный эффект получится многократно меньшим.
Причём здесь сервис-дизайн?
Для меня было удивительно, что в МГТС (доклад Дмитрия Кулаковского, директора по маркетингу) делают ставку не только на проработку пользовательских флоу, но и на простройку бизнес-процессов.
И Альфа Банк, и МГТС - очень хорошо, что они ставят на это.
При разработке в больших компания разработка сервиса - это не столько разработка самого сервиса, сколько интеграция продукта в портфель и настройка сервисов. Чтобы обеспечить общее вовлечение и участие, добиться бизнес kpi существует необходимость вовлечения каждого подразделения так, чтобы при этом оно обеспечило требуемый уровень сервиса. А ведь есть менеджеры продуктов, которые видят в продукте «дойную корову», есть продавцы, которые видят «то, что не нужно продавать», т.к. само продастся, как горячие пирожки, есть UX и их NPS, плюс поддержка, которая не хочет напрягаться, чтобы окучивать их, а хочет заниматься своим делом, и юристы, и фрод контроллёры, которые не пропускают и заинтересованы в том, чтобы продукт был не для фродстеров, а для клиентов, и IT технические специалисты, делающие так, тобы продукты соответствовали целевой архитектуре, чтобы серверные были замечательными… - это всё важные звенья взаимодействия.
Товарное предложение, цена - необходимо, чтобы все подразделения знали «что», «для кого», «как» и поддерживали общее, чтобы не возникали такие казусы.
Вот вам пример - шестерёнка. Почему, как вы думаете, она называется именно так? Потому что, взаимодействие с другими элементами происходит не менее, чем шестью зубцами, так, чтобы по 3 зубца передавали усилия по каждому очагу соприкосновения. Если зубцов будет меньше, это может привезти к надрыву и выведет весь механизм из строя, большее число будет избыточно.
Очевидно, с front-end-ом у обеих компаний было всё в порядке, с тестированием функционала ничего не случилось, но шестерня осталась вне системы, банальная проверка не была выполнена. Поддержка задействовала максимум 1 зубец, а вдобавок клиенты, обращавшиеся по штатным вопросам, не могли дозвониться до саппорта.