IT-Суши

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

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

​Вообще заказы разноцветные, это цвет статуса "Новый" ​

Компания по доставке еды с локальной кухней, курьерами и поварами. В основе меню роллы, лапша, и несколько доп.категорий.

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

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

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

Если что, сайт по адресу sushirolla.ru

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

Сегодня, например, в результате существенных переделок системы контроля смен - упал скрипт уведомлений о новых заказах. Не то, что бы перестал работать вообще - не определял, что заказ уже загружен, и подавал об этом звуковой сигнал. Каждые 5 секунд, пока заказ не получал статус "Принят" - после чего звук пропадал.

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

Но, как выяснилось, сама скорость приёма заказов при этом выросла почти на треть.

Не сказать, что подобные психологические эксперименты всегда применимы на практике, но практический опыт, богато чреватый ошибками, порой приносит неожиданный интересные выводы.

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

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

​Выводить все статьи расходов в итоговый отчет смысла нет - их слишком много. А вот сделать так, чтобы по клику открывали более детальные данные? Это же намного удобное и нагляднее. Вся ситуация на ладони - без таблиц, отчетов, графиков и тд.

Для чего это надо мне?

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

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

В общем, если софт не нашел, значит надо сделать свой. Вот и вся логика.

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

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

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

0
20 комментариев
Написать комментарий...
Alex AlexS

Статья хорошая и идея верная, в том смысле, что  писать программу стали с  0 и на html - это прям хорошо.

 
Но кроме продаж,  приема заказов, (сайт, приложение, КЦ), статусы у администратора, УПП - это не решит ключевой задачи по управлению бизнесом удаленно. Остается очень много вопросов связанные с операционнкой - а это, от к компании  к компании, в среднем от 15% до 27% затрат. 

Тот факт, что ввели табеля поваров в CRM, тоже верное решение, а данные то используете?  Есть управленческий учет? OKR\ KPI сотрудников? 

Если не секрет, какой уровень EBITDA? 

Ответить
Развернуть ветку
Serious Mann
Автор

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

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

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

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

Ответить
Развернуть ветку
Alex AlexS

Если могу конечно, я бы посоветовал, уже сейчас начать считать EBITD'у, и\или сделать P&L ( хотя уверен, что уже есть). Картина становится яснее. 

Повара - в любом случае работают на ставке, Вы им добавляете $ за нагрузку \ выработку? 

С курьерами, как реализовали начисление ЗП по км? Какая средняя ставка за заказ? 

На счет закупок и вообще СБС - как раз хорошо анализировать через P&L если верно составить. 

Ответить
Развернуть ветку
Serious Mann
Автор

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

Курьеры также - имеют и почасовую ставку, и плану за каждый конкретный заказ. Оплата зависит от зоны, в которую входит адрес. Попадание заказа в зону контролируется через API яндекс-карт. Надо бы в формулу добавить коэффициент скорости доставки. А тут пока неясности больше в теории, как это коэф вывести чтобы он был корректен.

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

Ответить
Развернуть ветку
Alex AlexS

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

Курьеры - тут очень просто, все зависит ( как я Вас уже спрашивал) от средней стоимости за заказ и уровня желаемого ФОТа. У меня был проект, где сократил, курьерский ФОТ сократил почти на 15%. 

P&L - недельный, вообще огонь. Планирование лучше, месячное. 
Сюда же, нужно делать и БДР тоже месячный. 

Доставка прекрасный бизнес! С верным подходом конечно :) 

Ответить
Развернуть ветку
Serious Mann
Автор

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

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

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

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

Ответить
Развернуть ветку
Serious Mann
Автор

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

Ответить
Развернуть ветку
Vl Al

Компания по созданию мусора.

Ответить
Развернуть ветку
Serious Mann
Автор

Сегодня любая компания - компания по созданию мусора. А вы - человек по созданию мусора. Как и любой другой человек.

Ответить
Развернуть ветку
Vl Al

"Валерий Никнейм" - Смысл термина "junkfood" включает в себя не только оценку качества еды, но и оценку объема создаваемого мусора. 

Ответить
Развернуть ветку
Борис Агафонцев

Додо-ИС значит на коленке пилите? Похвально. 

Ответить
Развернуть ветку
Serious Mann
Автор

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

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

Ответить
Развернуть ветку
Иван Ратников

А на чем пишите?

Ответить
Развернуть ветку
Serious Mann
Автор

Да как и любой веб-проект думаю, php, js, ,mysql ну и сейчас боты пойдут - пайтон добавится. Пара фреймворков и библиотек. 

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

Ответить
Развернуть ветку
Андрей Погорелый

Если я правильно понял, это индивидуальная разработка для одного клиента (ЦР в Тюмени), которая в перспективе может стать неким продуктом (SaaS / или коробка) для подобных компаний.

Разрешите полюбопытствовать :)

1. Много разработчиков задействовано? Ну или часов в месяц в среднем уходит на поддержку/развитие.

2. Как ЦР решились на этот шаг - создавать свой велосипед - ведь это явно недешево? Неужели так сильно не подходила iiko и прочие?

Ответить
Развернуть ветку
Serious Mann
Автор

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

Да и другой софт не лучше. 

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

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

Еще не решили.

Ответить
Развернуть ветку
Alex AlexS

Андрей, поддержу автора, большинство существующего на рынке ПО, не очень хорошо заточены под бизнес доставки. От слова "совсем" не очень. IIko - хороший продукт для ресторанов, для учета ТМЦ и тд. 
 А вот все что касается доставки и CRM и работой с базой - ну просто ад. Чего стоит их продукт под названием платиус .. ух вообще гениальная штука. 

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

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

Я вот в самое ближайшее время, как раз запущу разработку CRM для сети федеральной доставки. ( по этой причине тема близка) 

Ответить
Развернуть ветку
Sasha Lapina

Зачем вы оставили на скриншоте данные пользователей?

Ответить
Развернуть ветку
Serious Mann
Автор

Александра, будьте добры уточните, какие данные вы имеете ввиду? Вроде все личные данные затёрты!

Ответить
Развернуть ветку
Sasha Lapina

Привет.
Простите, не уточнила. Имела в виду, конечно, персональные данные.

Ответить
Развернуть ветку
17 комментариев
Раскрывать всегда