Торговый дом готовой продукции
5 000 000
Промышленность
Россия, Екатеринбург
Порталы и сервисы
Май 2024
Наш заказчик – компания, которая занимается производством и поставкой разнообразных блюд для сервисов доставки и сетевых магазинов, предлагающих готовую еду.
Целью было упростить рабочие будни менеджеров и сотрудников кухни, которые до сих пор использовали бумажные листочки для списка блюд. Технологи на производстве применяют решение от IIKO для учета продуктов, но оно слишком сложное для передачи информации на склад продуктов и кухню. Поэтому требовался упрощенный вариант.
Основная задача заключалась в минимизации ошибок, упрощении взаимодействия между подразделениями и обеспечении более контролируемых процессов. Также важным запросом было создание максимально понятной системы для сотрудников, не имеющих опыта работы с компьютерами.
Кроме того, компания стремилась к быстрому и гибкому масштабированию, поэтому был выбран веб-формат.
ЗАДАЧИ
1. Проанализировать текущий процесс передачи заявок в производственные отделы;
2. Разработать новый процесс, включающий автоматизацию передачи списка блюд из заявок;
3. Разработать веб-сервис, с помощью которого эта автоматизация будет доступна сотрудникам производства.
Стоит отметить, описываем работу поэтапно, хотя эти этапы условные, поскольку большая часть процессов шли параллельно.
Сначала мы провели интервью с директором производства и сотрудниками, ответственными за получение заявок и их распределение на склад продуктов и кухню. Это позволило нам составить схему текущего состояния процесса.
Затем мы проанализировали требования и ожидания сотрудников, создав User Story Map. В ходе анализа выяснилось, что менеджеры тратят много времени на предварительную обработку заявок и подготовку списков для следующих этапов. Повара и сотрудники склада часто путаются и совершают ошибки из-за мелкого шрифта на бумажных таблицах, в которых постоянно нужно что-то отмечать. Еще одна сложность заключается в том, что бумажные таблицы не предусматривают иерархическое деление рецепта: блюдо – заготовка – продукт. Все коммуникации между отделами происходят лично, что требует физического перемещения для уточнения и обновления информации.
На основе полученных данных мы разработали схему будущего бизнес-процесса, который избавляет сотрудников от лишней бумажной работы, упрощает коммуникацию между отделами и снижает вероятность ошибок в рабочих процессах.
На основе согласованной с заказчиком идеи мы задокументировали требования к минимально жизнеспособному продукту (MVP), который будет доступен для первичного тестирования. В дальнейшем функциональность и структура сервиса значительно расширились. Это не создало критических ограничений благодаря подходу Time&Material, хотя увеличило сроки и стоимость разработки. Однако, давайте опишем, как выглядела изначальная идея.
Сервис предусматривал четыре роли пользователей. Для каждой роли были определены процессы и алгоритмы, описывающие действия пользователей в сервисе, и составлены сценарии использования (Use Cases).
Роли и краткое описание:
1. Администратор — это пользователь с расширенными правами управления системой. Его возможности включают:
- Полный функционал менеджера, о котором мы расскажем позже.
- Возможность добавлять рецепты в базу данных. Рецепты учитывают этапы приготовления: блюда (конечный продукт) могут состоять из заготовок и/или ингредиентов, заготовки состоят из ингредиентов, а ингредиенты являются неделимыми единицами.
- Добавление новых пользователей с назначением ролей и редактирование списка существующих пользователей.
- Управление таблицей дефростации, которая содержит недельную информацию для склада о необходимости разморозки замороженных продуктов. Количество продуктов для разморозки рассчитывается автоматически на основе данных за предыдущие недели, и устанавливается медианное значение, которое администратор может корректировать.
2. Менеджер — это пользователь, который обрабатывает заявки от клиентов. Он может добавлять новые заявки и редактировать уже существующие. При работе с заявками менеджер указывает клиента, от которого поступила заявка, выбирает необходимое количество блюд из базы, устанавливает дату выполнения заявки и отслеживает ее статус в зависимости от работы кухни.
Поскольку заявки от клиентов поступают в разных форматах, менеджер сначала вручную вводит их в 1С для учета и унификации. Чтобы ускорить процесс переноса заявок в веб-сервис, предусмотрена возможность загрузки заявок через Excel-файл, выгруженный из 1С.
3. Повар — это пользователь, который готовит блюда по заявкам. Он может:
- Просматривать заявки с перечнем необходимых блюд.
- Изучать рецепты приготовления блюд, при необходимости переходя к рецептам заготовок и списку ингредиентов.
- Изменять статус заявки (с "новая" на "в работе" и "завершено").
- Оформлять дополнительные заявки на склад, если в процессе готовки не хватает каких-либо продуктов.
4. Склад — это пользователь, работающий на складе и собирающий необходимые продукты для передачи на кухню. Его возможности включают:
- Просмотр списка заявок с продуктами, которые нужно собрать для кухни.
- Просмотр дополнительных заявок, поступивших с кухни.
- Изменение статуса заявки (с "новая" на "в работе" и "завершено").
- Просмотр таблицы дефростации для подготовки продуктов к разморозке на следующий день.
На основе этих базовых требований мы создали lo-fi прототип, чтобы определить необходимость всех элементов и проверить, нужно ли скорректировать требования.
В результате создания прототипа мы поняли, что необходимо изменить способ представления информации для роли "Склад". Сотрудникам склада удобнее работать с общей таблицей продуктов, которые нужно собрать, вместо ориентирования на первоначальные заявки от клиентов. Поэтому в дальнейшем дизайне мы предусмотрели сводные таблицы по продуктам для склада и сводные таблицы по блюдам для поваров в том числе.
Приготовленные поваром блюда из сводной таблицы распределяются по заявкам текущего дня в соответствии с приоритетом и временем их добавления.
При разработке дизайна мы учитывали, что большинство сотрудников предприятия будут пользоваться сервисом либо с телефонов (склад), либо со специальных экранов с тачпадами (кухня). Поэтому структура была спроектирована в первую очередь для планшетов и мобильных устройств.
Кроме того, по отзывам сотрудников, многие предпочитают использовать темную тему на мобильных устройствах. Поэтому мы решили включить темную тему в MVP, так как она более привычна для сотрудников и обеспечивает лучший контраст на экранах.
В целом, дизайн сосредоточен на удобстве работы с системой и не содержит креативных элементов. Все декоративные детали, такие как иконки и фотографии, имеют функциональное значение.
Разработка велась на системе Laravel, так как требовалось создать кастомную систему администрирования для конкретного предприятия, и готовые решения не подходили.
Работы на фронтенде и бэкенде шли практически одновременно. Пока фронтенд-разработчики занимались макетом и визуальной частью, бэкенд-разработчики разрабатывали первые версии базы данных.
Затем началась совместная работа над функциональностью как на фронтенде (например, работа фильтров, поиск, изменение приоритета заявки и др.), так и на бэкенде (например, установка связей между блюдами, заготовками и продуктами, хранение и получение заявок, настройка связей между ролями и др.). На заключительном этапе необходимо было интегрировать фронтенд и бэкенд, чтобы данные корректно передавались между ними.
В целом задачи были достаточно понятными, хотя и не самыми простыми, если бы не одно "но"...
Во время работы над веб-сервисом и при презентации каждой доработки мы получали разнообразную обратную связь от команды клиента. В основном она касалась необходимости расширения объема запускаемого MVP, чтобы не только упростить работу сотрудников, но и обеспечить контроль над их деятельностью.
Так постепенно у нас появились:
1. Раздел аналитики. Он должен был учитывать планируемое и фактическое количество блюд, заготовок и продуктов, а также количество выполненных и невыполненных заявок.
Статистика должна была обновляться в зависимости от выбора клиента, рецепта, цеха и даты. Кроме того, каждое отклонение от плана должно было пересчитываться в процентах и отображаться в отдельном отчете. Все отчеты должны были быть доступны для выгрузки в Excel.
Однако было решено временно отложить разработку этого раздела, так как первичная функциональность еще не была достаточно протестирована на практике.
2. Изменения в работе кухни и склада стали включать деление по цехам. Теперь повара могут просматривать не только общий список заявок, но и видеть список конкретных блюд в зависимости от цеха, в котором они работают. Также повар на кухне может устанавливать приоритет заявки в зависимости от процесса приготовления.
На складе также введено разделение по цехам: каждый сотрудник видит, какие и в каком количестве продукты нужно подготовить для конкретного цеха. Продукты распределяются по цехам в соответствии с количеством блюд, относящихся к каждому из них.
3. Введена дополнительная роль — Заготовщик. Появилась необходимость учитывать изменение веса продукта после его очистки. Например, 100 г картофеля после очистки могут стать 90 г, что приведет к нехватке продуктов для готовки. В таком случае потребуется дополнительная заявка на склад, что увеличит время работы всех отделов.
Заготовщик получает список продуктов с учетом нормы очистки (стандартный коэффициент, заданный при создании рецепта). В результате повар сразу получает корректное количество продуктов. Если при чистке произошла ошибка (например, испорчены продукты), можно сделать дополнительную заявку на склад продуктов для восполнения потерь.
5. Расчет коэффициента нормы закладки. Помимо нормы очистки, возникла необходимость учитывать “норму закладки” — процент, на который уменьшается вес продукта при варке, жарке и других процессах.
В работе с этими расчетами есть много нюансов, но основная сложность заключается в правильном распределении этого коэффициента по блюдам. Норма закладки для заготовки и продукта может различаться в зависимости от блюда, а также веса брутто и нетто продукта. Чтобы упростить расчеты, использовали средний коэффициент нормы закладки для продукта и заготовки, чтобы получить вес блюда, максимально приближенный к реальному.
6. В ответ на беспокойство клиента: "А если у нас закончатся кабачки?", мы решили предусмотреть редкие экстренные ситуации, когда на складе в какой-то день отсутствуют необходимые продукты для приготовления блюда. В таком случае сотрудник склада добавляет недостающие продукты в стоп-лист.
Если продукт попадает в стоп-лист, он и все связанные с ним заготовки и блюда исчезают из списков у всех ролей. У поваров и менеджеров в списке заявок появляется специальное обозначение, указывающее, что заявка не будет выполнена полностью из-за отсутствия продуктов.
В настоящее время сервис запущен в тестовом режиме для проверки готовых функций заказчиком. Для полного внедрения необходимо закупить оборудование, такое как экраны и корпоративные телефоны, для производства. В дальнейшем планируется разработка раздела "Аналитика", интеграция с 1С и IIKO, а также доработка сервиса для следующего этапа работы производства — распределения заказов для логистики.
Kolibri с удовольствием обсудит вашу задачу