Автоматизировали передачу заказов между производством, кухней и складом

Решение

1. Проанализировать текущий процесс передачи заявок в производственные отделы;
2. Разработать новый процесс, включающий автоматизацию передачи списка блюд из заявок;
3. Разработать веб-сервис, с помощью которого эта автоматизация будет доступна сотрудникам производства.

Стоит отметить, описываем работу поэтапно, хотя эти этапы условные, поскольку большая часть процессов шли параллельно.

1 этап. Аналитика

Сначала мы провели интервью с директором производства и сотрудниками, ответственными за получение заявок и их распределение на склад продуктов и кухню. Это позволило нам составить схему текущего состояния процесса.

Затем мы проанализировали требования и ожидания сотрудников, создав User Story Map. В ходе анализа выяснилось, что менеджеры тратят много времени на предварительную обработку заявок и подготовку списков для следующих этапов. Повара и сотрудники склада часто путаются и совершают ошибки из-за мелкого шрифта на бумажных таблицах, в которых постоянно нужно что-то отмечать. Еще одна сложность заключается в том, что бумажные таблицы не предусматривают иерархическое деление рецепта: блюдо – заготовка – продукт. Все коммуникации между отделами происходят лично, что требует физического перемещения для уточнения и обновления информации.

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

2 этап. Составление требований для MVP

На основе согласованной с заказчиком идеи мы задокументировали требования к минимально жизнеспособному продукту (MVP), который будет доступен для первичного тестирования. В дальнейшем функциональность и структура сервиса значительно расширились. Это не создало критических ограничений благодаря подходу Time&Material, хотя увеличило сроки и стоимость разработки. Однако, давайте опишем, как выглядела изначальная идея.

Сервис предусматривал четыре роли пользователей. Для каждой роли были определены процессы и алгоритмы, описывающие действия пользователей в сервисе, и составлены сценарии использования (Use Cases).

3 этап. Прототипирование

На основе этих базовых требований мы создали lo-fi прототип, чтобы определить необходимость всех элементов и проверить, нужно ли скорректировать требования.

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

Приготовленные поваром блюда из сводной таблицы распределяются по заявкам текущего дня в соответствии с приоритетом и временем их добавления.

4 этап. Дизайн

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

Кроме того, по отзывам сотрудников, многие предпочитают использовать темную тему на мобильных устройствах. Поэтому мы решили включить темную тему в MVP, так как она более привычна для сотрудников и обеспечивает лучший контраст на экранах.

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

5 этап. Верстка и программирование

Основой проекта стал фреймворк Laravel, так как, по нашему мнению, он наиболее подходит под сложные не типовые проекты, легко масштабируется и кастомизируется.

За пользовательскую часть (фронтенд) у нас отвечал фреймворк VueJS. Он позволил реализовать удобный интерфейс, который работает без перезагрузки страниц. 

А обмен с сервером осуществлялся посредством коротких и легковесных Ajax-запросов, что делало загрузку данных быстрой и незаметной для пользователя. 

Всё это добро мы заботливо упаковали в Docker-контейнеры, что позволило нам легко и быстро разворачивать проект на любых машинах разработчиков, на тестовых стендах и на хостинге заказчика буквально одной командой. 

Работы на фронтенде и бэкенде шли практически одновременно. Пока фронтенд-разработчики занимались макетом и визуальной частью, бэкенд-разработчики разрабатывали первые версии базы данных.

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

В целом задачи были достаточно понятными, хотя и не самыми простыми, если бы не одно «но»…

Дополнительные моменты

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

Результат

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