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

Зачем нам склады и собственная система управления?

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

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

Кроме того, ОС не всегда “переваривает” нагрузку входящих и исходящих потоков складов, поэтому может сильно зависать, долго грузить, не сохранять данные, а иногда и просто падать. 

Как мы решили делать собственную систему управления...

Дело было не просто в ОС, а в показателях пропускной способности складов и выручки, которые хотелось увеличивать. Пропускная способность — это показатель, который отражает способность склада быстро обрабатывать поток товаров при меньших затратах. Чем быстрее склад обрабатывает потоки товаров, тем меньше расходов требует и больше прибыли приносит.

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

Но просто так взять и разработать собственную систему нельзя — сначала надо понять как устроены процессы и какие есть проблемы в использовании текущей системы, чтобы не допустить этих ошибок при разработке новой. 

Чтобы все это понять у продуктовой команды возникла потребность в исследованиях, поэтому они обратились ко мне.

Почему этнография?

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

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

Внутри любого процесса живые люди

Этнография помогла увидеть особенности, о которых раньше продуктовая команда не знала. Различия обнаружились даже между сменами на одном складе. Все подходят к стандартным процессам по-разному. Например, в одной смене сотрудники тратят много времени и сил, перемещая тяжёлый товар из 2-го блока в 5-й через весь склад. В то время, как другая смена старается заранее расположить такие грузы ближе, чтобы упростить и облегчить логистику.

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

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

Как обрабатывали результаты?

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

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

Когда стали проводить UX-тесты?

После того, как мы изучили устройство процессов со всеми особенностями и проблемами, продуктовая команда начала внедрять исследования в проектировании макетов новой системы. Как только макеты сформировались в полноценные процессы или операции, нужно было тестировать их вместе с конечными пользователями – сотрудниками на складах. 

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

Таким образом, мы поняли, что для таких складских сотрудников нам нужно менять привычный подход к UX-тестированию. С пользователями, которые работают в офисе склада за компьютером, мы тестировали новую систему онлайн, а с пользователями, которые работают с товарами на складе, мы решили тестировать офлайн на территории склада. Но есть нюанс. На самом складе проводить тесты неудобно (т.к. вокруг много людей, которые будут отвлекаться от своей работы, а нас отвлекать от исследования) поэтому мы проводили тесты в офисной части склада. 

А как же физические процессы?

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

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

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

А как тестировали саму систему?

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

Лёгким движением руки исследования превращаются в продукт

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

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