Workspace Digital Awards 2025 — престижнейшая премия в диджитал. Прием заявок до 17 февраля, успейте принять участие!
Kolibri
Оптимизация процессов с помощью разработки веб-сервиса для пищевого производства
Kolibri
WDA
2025
#Сайт под ключ

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

560 
24 янв 2025 в 14:01
Kolibri
Kolibri Россия, Екатеринбург
Поделиться:
Оптимизация процессов с помощью разработки веб-сервиса для пищевого производства
Клиент

Торговый дом готовой продукции

Бюджет

5 000 000

Сфера

Промышленность

Регион

Россия, Екатеринбург

Тип сайта

Порталы и сервисы

Сдано

Май 2024

Задача

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

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

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

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

Решение

ЗАДАЧИ

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

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

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

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

1Аналитика

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

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

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

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

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

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

Роли и краткое описание:

1. Администратор — это пользователь с расширенными правами управления системой. Его возможности включают:

   - Полный функционал менеджера, о котором мы расскажем позже.

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

   - Добавление новых пользователей с назначением ролей и редактирование списка существующих пользователей.

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

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

Поскольку заявки от клиентов поступают в разных форматах, менеджер сначала вручную вводит их в 1С для учета и унификации. Чтобы ускорить процесс переноса заявок в веб-сервис, предусмотрена возможность загрузки заявок через Excel-файл, выгруженный из 1С.

3. Повар — это пользователь, который готовит блюда по заявкам. Он может:

   - Просматривать заявки с перечнем необходимых блюд.

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

   - Изменять статус заявки (с "новая" на "в работе" и "завершено").

   - Оформлять дополнительные заявки на склад, если в процессе готовки не хватает каких-либо продуктов.

4. Склад — это пользователь, работающий на складе и собирающий необходимые продукты для передачи на кухню. Его возможности включают:

   - Просмотр списка заявок с продуктами, которые нужно собрать для кухни.

   - Просмотр дополнительных заявок, поступивших с кухни.

   - Изменение статуса заявки (с "новая" на "в работе" и "завершено").

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

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

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

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

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

4Дизайн

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

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

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

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

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

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

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

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

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

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

Так постепенно у нас появились:

1. Раздел аналитики. Он должен был учитывать планируемое и фактическое количество блюд, заготовок и продуктов, а также количество выполненных и невыполненных заявок.

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

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

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

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

3. Введена дополнительная роль — Заготовщик. Появилась необходимость учитывать изменение веса продукта после его очистки. Например, 100 г картофеля после очистки могут стать 90 г, что приведет к нехватке продуктов для готовки. В таком случае потребуется дополнительная заявка на склад, что увеличит время работы всех отделов.

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

5. Расчет коэффициента нормы закладки. Помимо нормы очистки, возникла необходимость учитывать “норму закладки” — процент, на который уменьшается вес продукта при варке, жарке и других процессах.

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

6. В ответ на беспокойство клиента: "А если у нас закончатся кабачки?", мы решили предусмотреть редкие экстренные ситуации, когда на складе в какой-то день отсутствуют необходимые продукты для приготовления блюда. В таком случае сотрудник склада добавляет недостающие продукты в стоп-лист.

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

Результат

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


Стек технологий

  • JavaScript JavaScript Язык программирования
  • PHP PHP Язык программирования
  • Sass Sass Язык программирования
  • Laravel Laravel Фреймворк/библиотека
  • Vue.js Vue.js Фреймворк/библиотека
  • MariaDB MariaDB База данных
  • Docker Docker Среда разработки
  • PhpStorm PhpStorm Среда разработки
  • Figma Figma Графический редактор

Выскажите мнение
Авторизуйтесь, чтобы добавить свой комментарий.
оставить заявку

Хотите заказать похожий проект?

Kolibri с удовольствием обсудит вашу задачу

Оставить заявку