Создание электронного каталога технологических карт блюд и системы тестирования и адаптации поваров

1. Создать электронный каталог блюд в ресторане с быстрым и удобным доступом для работников кухни и обновлением меню в режиме онлайн.

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

3. Избежать заказной разработки, решения должны будут поддерживаться и развиваться аналитиком - сотрудником “Кофемании”.

2024

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

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

В дальнейшем Кофемания может сама дорабатывать приложение на low-code платформе, с минимальным привлечением команды разработчиков.

Да

1.     Gestori – ERP система управления предприятием. Хранение мастер-данных (техкарт) по техпроцессам приготовления блюд.

2.     Naumen SMP – Low-Code технология для автоматизации процессно-учетной деятельности. Учёт связи техкарт, меню ресторанов, обучающих курсов и результатов сдачи тестов (допусков к приготовлению блюд). Управление процессами обновления меню в ресторанах.

3.     Naumen Platform – Low-Code технология для построения портальных решений (front-end) поверх существующих информационных систем. Созданы приложения «Карточка блюда» и «Тестирование».

4.     Планшеты на Android – терминал для электронного меню в зоне кухни.

В проекте не используются решения из каталога Global CIO

• Проект требовалось реализовать в сжатые сроки

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

Заказная разработка не подходила из-за стоимости и сложности последующего развития и поддержки.

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

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

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

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

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

4. Интегрированная система аттестации. Готовые системы обучения не могли автоматически загружать базу данных технологических карт блюд и не предоставляли нужной функциональности для анализа результатов аттестации. Это ограничивало возможности контроля качества и допусков на кухне.

Проект выполнялся в два этапа:

Используя комбинированный подход к разработки и инструменты Naumen Platform в короткие сроки были решены следующие задачи:

1. Первый шаг – разработка макетов. Дизайнеры, используя собственную дизайн систему, настроенную в привычном инструменте (Figma) разработали макеты будущего приложения. Это заняло примерно 3-5 дней.

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

3. Создание прототипов. Далее аналитики в точности перенесли все макеты в приложение используя модуль с готовыми компонентами для построения интерфейсов в Naumen Platform. Созданный прототип будущего решения позволил продемонстрировать общие принципы работы приложения и был готов к подключению реальных данных. Этот этап занял 2-3 дня.

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

5. Разработка и интеграция. Далее прототип мы интегрировали с источником данных ITSM 365, чтобы вся информация о блюдах и тестах автоматически подгружалась в систему. Этот процесс занял от 7 до 10 дней. Важно отметить, что для этого не потребовалось писать код в Naumen Platform.

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

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

Москва, около 50 точек (ресторанов) + школа поваров.