Оптимизация процессов с помощью разработки веб-сервиса для пищевого производства

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

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

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

Кроме того, компания стремилась к быстрому и гибкому масштабированию, поэтому был выбран веб-формат.

1. Проанализировать текущий процесс передачи заявок в производственные отделы;

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

3. Разработать веб-сервис, с помощью которого эта автоматизация будет доступна сотрудникам производства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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