Введение Эта инструкция – попытка систематизировать знания, полученные за годы работы в ресторанном бизнесе. Я хочу разложить все по полочкам и дать рабочий инструмент всем заинтересованным коллегам. Аналитика преувеличена теми консультантами, которые не хотят делиться элементарными знаниями, зарабатывая на своих клиентах. Я никогда не придерживался этих принципов: все мои клиенты получают инструмент для улучшения своих позиций, а не готовое решение. Они могут повторить всю работу сами. В этом заключается моя цель – я хочу, чтобы вы завтра начали работать по другому. Аналитика – это инструмент для решения управленческих задач и только.

• Р Кипер Как Пользоваться
• Программа Р Кипер

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

R keeper 7 инструкция. Инструкция для бухгалтера. 12 21 отдел продаж Р кипер инструкция. Скачать руководство менеджера р кипер 7 инструкция R-Keeper Содержание руководства: 1.

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

Действительно – только «показаться». Представьте, что в этот самый момент десятки ресторанов уже работают по предложенным стандартам. Если работают другие, то и вы сможете. Это может быть неожиданным заявлением, но уже на этапе подготовки к анализу вы начнете зарабатывать больше, а ваше отношение к бизнесу изменится. Главное – начать! Дорогу осилит идущий.

С уважением, Сергей Ицков Глава 1. Алгоритм подключения к системе MOZG Для того, чтобы начать работу, вам необходимо выполнить следующие шаги инструкции. Для реализации подключения рекомендуем создать рабочую группу, в которой принимают участие управляющий, бухгалтер-калькулятор (или технолог) и ИТ-специалист, обслуживающий вашу систему автоматизации. Настройка занимает 3-5 дней. Основная часть работы возлагается на бухгалтера-калькулятора или технолога, разделы для ИТ-специалиста отмечены, а руководителю необходимо проследить за качеством работы. Данная инструкция составлена максимально подробно для того, чтобы компании могли своими силами настроить работу программы.

На случай, если вы по каким либо причинам не можете организовать работу по подключению, компания MOZG может помочь вам в этом (как создать новые классификации и настроить выгрузку). Заявку на консультацию отпарвляйте на почту IT@mozgexpress.ru Алгоритм подключения: 1. Администратор поддтвердит регистрацию и Вам на почту прийдет письмо с паролем для входа в систему 3. Выполните первую авторизацию на сайте. При первом заходе вы увидете привественное сообщение с ссылкой на инструкцию по настройке системе 4. Проходите шаги по настройке справочников в системе автоматизации 5. Настраиваете экспорт данныз в MOZG 7.

Настраиваете справочники внутри Мозга Глава 2. Настройка системы автоматизации и стандарты Для начала аналитической работы необходимо привести в порядок все ваши справочники в системе автоматизации. Чаще всего – в R-keeper и Store House. Это кропотливая и объемная работа. Но она делается всего 1 раз и стоит того.

Дальнейшее поддержание в чистоте не отнимает много времени. Каждый шаг инструкции – это рекомендация компании Zuma Consulting, которая является разработчиком платформы MozgExpress.

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

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

Как правило, настройка одного ресторана занимает не более 3-5 рабочих дней. Это кропотливая и ответственная работа. Реализация некоторых пунктов может внести изменения в процессы работы официантов, менеджеров и кассирова. Компания оказывает услугу по консультированию и подключению ресторана к аналитической платформе. Именная карта У каждого официанта, менеджера и кассира должна быть строго своя именная карта в формате «Имя Фамилия».

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

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

Она определяется разницей между открытием и закрытием чека. Если у вас в ресторане существует практика «висящих столов» – показатель длительности будет неактуальным. Кроме того, такие столы, обычно, списываются, так как без карты невозможно определить чей этот стол и «кто виноват». В наших ресторанах все столы в 4 утра автоматически закрываются «под зарплату» ответственного лица, если этот сотрудник вовремя (в течении смены) не разобрался с этим счетом.

Бывают моменты, когда вина сотрудника (например, официанта) отсутствует: к примеру, гость отказался, потому что кухня действительно отдавала салат 30 минут. Для таких случаев у нас есть специальные процедуры, описанные в следующем правиле. Стандарт нумерации столов для любой ситуации Каждый стол в зале должен иметь свой номер, а так же должен быть специ-альный регламент для служебных операций. Пронумерованными должны быть не только фактические столы в зале, но так же столы для конфликтных ситуаций, столы для неплательщиков, бартеры, доставка, вынос, кейтеринг, скидки и питание персонала, ошибки персонала, продажа депозитов и прочее. Вот, к примеру, как выглядит стандарт столов в одном из наших ресторанов. Стандарт нумерации столов для зала ресторана. Стол № Наименование Столы в ресторане 1-650 Зал ресторана 701-759 Зал караоке 900-920 Летняя террасса 801-850 Патио (теплая веранда) 501-545 Вынос 601-649 Доставка 8008 Кейтеринг (выездное обслуживание) Такая группировка столов в залы доступна в любой системе автоматизации.

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

Многие рестораны ведут статистику продаж доставки и выноса через специальную карту официанта под названием «доставка» и «вынос». Но таким образом, будет невозможно установить лицо, принимающие заказ и закрывающее стол. Это совсем непрозрачно.

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

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

Рекомендую не изобретать велосипед, а взять за основу следующую нумерацию служебных столов. Стандарт нумерации служебных столов Стол № Наименование Служебные столы 100 Неплательщик 1 (ФИО) 101 Неплательщик 2 (ФИО) 107 Неплательщик 3 (ФИО) 222 Стол для сотрудников, которые заказывают по меню 334 Напитки сотрудника СБ 400 Представительские расходы 600 Комплименты для гостей 700 Бракераж 666 Обман гостем 2000 Продажа депозитов 2100 Бартер (оплата от юр. Лиц) 2200 Ошибки персонала 7000 Реклама 8001 Сертификат 1500 8002 Сертификат 3000 8003 Сертификат 5000 8004 Безнал (оплата от юр. Лиц по безналу) Обратите внимание, что для каждой операции существует отдельный стол. Такая методика существенно облегчает контроль за персоналом, а так же упрощает учет как для технолога, так и для бухгалтерии.

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

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

Когда учет ведется правильно – установить причину ошибки проще в разы. Если блюдо вышло из меню (неактуально) никогда не удаляйте его из системы автоматизации, делайте его «неактивным» и оставляйте его в той же товарной группе! Кроме того, нельзя удалять карту комплекта (R-keeper) этого блюда - иначе себестоимость в MOZG будет равно 0.

Столы ресторана необходимо объединить в залы Это делается очень просто в самой системе автоматизации. То есть именно в системе вы отмечаете столы и группируете их по залам. Такая классификация необходима, чтобы оценивать эффективность загрузки каждого зала ре-сторана, не теряя времени на выбор нескольких столов. Кроме того, в MOZG залы группируются в подразделения, поэтому группировка столов по залам – необходимая процедура. К примеру, в таблице 1 проиллюстрирована группировка залов таким обра-зом, как она настроена в системе автоматизации нашего ресторана. И для формирования нужного отчета я могу выбрать сразу весь зал, а не перебирать столы от 500 до 540, когда хочу посмотреть статистику продаж по выносам.

Это существенно ускоряет процесс получения данных, экономит время и деньги. Указать количество гостей за каждым столиком После того, как вы сгруппировали столы в залы, необходимо назначить каждому столику его вместимость. Это так же делается в настройках системы автоматизации. Указывайте адекватное количество гостей, а не «максимальное». То есть если столик предназначен на 4 гостей, но бывает такое, что вы подставляете стул и в итоге за него усаживается 5 или даже 6 человек, все равно это стол на 4 гостей! Так же обратите внимание на барную стойку.

Если она контактная и вы в часы пик размещаете там гостей, я рекомендую назначить номер стола для каждого места и объединить все столы в зал «Бар ресторана». Соответственно, вместимость каждого «столика» будет равна 1. За кассу в течении смены отвечает только 1 сотрудник Это правило не связано с аналитикой, но зато помогает быстро находить и устранять причину недостач в ресторане. Когда ответственность несет 1 сотрудник, содержимое кассового ящика в большей сохранности. В ресторанах работает безотказно, а вот в барах с контактной стойкой в пятничный вечер или ночь необходимо прорабатывать другие возможности, чтобы работать быстро. Если вы не можете нанять кассира, подумайте, как можно решить эту задачу другим путем. Но, как показывает практика, кассир обходится дешевле злоупотреблений.

Если вам необходима инструкция кассовой дисциплины, сделайте запрос на почту и мы бесплатно вышлем вам наш стандарт работы, выверенный годами с одной целью – настроить максимальную прозрачность и свести злоупотребления на нет. На каждый случай свой метод оплат Очень часто в ресторане всего 3 метода оплат – «наличные», «безнал» и «служебные». С точки зрения логики вроде и достаточно. Вот только как правильно списать блюда, которые ушли на неплательщиков, комплементы, бракераж, дегустации, ошибки персонала и прочее? А ведь с точки зрения производственного учета – это очень важная часть как для технолога, так и для бухгалтера. Выгрузить все продукты, использованные на приготовления служебных позиций можно только исходя из методов оплат, так как Store House не может делать выгрузку по столам или залам (впрочем, как и большинство других систем автоматизации). В том числе, это делается для того, чтобы при формировании нужных аналитических отчетов, вы могли выбрать только те чеки, которые были закрыты на “реальные деньги”.

Это важно, так как в служебных чеках нет реальных гостей: такая ситуация может существенно испортить полученную статистику о гостевом потоке (если залы не настроены), среднем чеке и других показателях, важных для оценки деятельности ресторана. В нашей аналитической системе я делаю дополнительную группировку су-ществующих методов оплат, разделяя их на: реальные деньги, служебные и бонусы (оплата баллами пр картам). Соответственно, дальнейший анализ провожу только по фильтру «реальные деньги», так как именно там находятся наши гости, а, значит, показатели эффективности. Настройка категорий меню для аналитики Пришло время приводить в порядок справочники, связанные с меню ресторана. Здесь у 99% рестораторов полный бардак.

Для начала хотелось бы утвердить несколько базовых понятий в анализе продаж меню, которые являются стандартом Zuma Consulting. Речь идет о категориях меню и товарных группах меню. Категория меню – это группировка товаров по принципу где позиция была произведена: кухня, бар, кальянная и прочее. Товарная группа – это группировка товара согласно его гастрономическому признаку: роллы, горячие блюда, салаты, десерты, супы и так далее. Очень часто в обсуждении коллеги путают эти понятия, или пользуются одним обозначением для всего. Это может привести к путанице.

К примеру, мне необходимо сделать отчет только по блюдам кухни. Для этого теперь достаточно выбрать соответственный фильтр «Кухня меню», а не набирать разные товарные группы. Для того, чтобы вам было удобнее выгружать нужные отчеты (фильтруая категории), а так же для удачной интеграции с аналитической системой www.MozgExpress.ru в вашей системе автоматизации необходимо создать классификатор «Категории для аналитики». Это дополнительный классификатор, который вы можете создать сами (иснтуркция с картинками находится ниже), или обратиться к ИТ-специалистам, обслуживающим вашу систему автоматизации. Стандарт Zuma Consulting для названия Категорий для Мозга: 1. Кухня меню 2. Кухня прочее 3.

Бар прочее 5. Кальяны (сюда относится все, что связано с кальянами) 6. Услуги и прочее Теперь, когда у вас есть категории для аналитики, необходимо каждое блюдо в справочнике системы автоматизации (далее СА), активное и неактивное, абсолютно все, что есть в базе данных за весь период работы, отнести к соответственной категории.

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

Каждая позиция при вводе в меню, должна быть отнесена к одной из этих категорий. Логика распределения проста – в категорию “Кухня Меню” и “Бар Меню” относятся только полноценные блюда и напитки, а к “прочим” категориями бара или кухни относятся специи, хлеб (только если это не закуска к пиву), гарниры, соус, дольки лимонов или мята, добавки и прочие сопутствующие позиции. Например, суп “Том-ям” или салат “Цезарь” – это полноценные блюда, которое необходимо определить в категорию “Кухня Меню”, а дополнительный соус к стейку – это “Кухня прочее”. Так же и по бару: кофе “Американо” – это полноценный напиток, поэтому относится к категории “Бар Меню”, а вот мед к чаю, лимон или мята – это “бар прочее”. Часто в СА заводятся позиции, которые вообще не относятся к бару или кухне, например продажа билетов на детский праздник, или карта на парковку – все это мы относим к категории “Услуги и прочее”.

Позиции обеденное меню (бизне-ланча) распределяются по такому же при-знаку (блюда – к кухне, напитки – в бар). Я рекомендую относить бизнес-ланч к «кухня прочее» и «бар прочее» в тех случаях, когда продажи ланча занимаются менее 20% от общих продаж в течение обеда (с 12:00 до 16:00) по будним дням. Создадим классификации для Мозга в R-keeper: 1.

Заходим в «Меню» и выбираем «Классификации блюд» 2. Нажав правой кнопкой мыши на корневой вершине «Все» выберем «Новая классификация». Строго вводим имя «Категории для Мозга». В созданной классификации «Категории для Мозга» создадим нужные нам категории «Кухня меню», «Бар меню» и так далее, как указано в стадарте: Затем у любого блюда в меню станет возможным назначить категории: Далее открываете каждое блюдо и назначете ему нужную категорию по стандарту Zuma Consulting. Товарные группы для аналитики Обычно «древо товаров» настроено таким образом, чтобы было удобнее ра-ботать персоналу в зале.

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

Сделать это очень просто по аналогии с Шагом 9 - в системе автоматизации классификацию «Товарные группы для Мозга» и внутри нее создаете новые товарные группы. Принцип создания товарных групп для аналитики очень прост: в каждой группе меню должны находится равноценные блюда. Фактически, это те же самые группы, что есть сейчас в вашей системе автоматизации, но из них нужно убрать лишние блюда, или обобщить. Например, группа «горячее» очень часто содержит еще и гарниры и блюда на компанию из горячих блюд, или мешает профилирующие группы блюд (например стейки или вок) с остальными горячими позициями. Официанту удобно, а вот чтобы сделать анализ товарной группы, вам придется вручную удалять лишние позиции, оставляя только «равноценные» позиции для срав-нения. Поэтому данную группу необходимо очистить – все, что относится к гарнирами перенести в групп «гарниры», а блюда для компанию – в товарную группу «блюда для компаний». Другой пример: для аналитики можно объединить группы «горячее из мяса» и «горячее из рыбы», так как с точки зрения повода (основное второе блюдо) – эти позиции одинаковы.

Тоже самое можно сделать и с винами в категории «бар». Красные и белые – смело объединяйте, игристые и шампанские – одну группу «игристы и шам-панские вина». Так же в баре очень часто существует несколько товарных групп для коктейлей – «классика», «твисты», «модные» и так далее. Это все можно обобщать.

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

Однако, при детальном анализе, выяснилось, что блюда «хинкали» были включены в эту группу и обладают минимальными продажами, что очень странно для такого формата. Было принято решение провести корректирующие действия с целью увеличения продаж, а группу «хинкали» вынести отдельную товарную группу, чтобы оперативное определять ее динамику, так как эта группа все равно что «роллы» в япон-ском ресторане. Все блюда обеденного меню необходимо свести в одну товарную группу «Обеденное меню», или «Бизнес ланчи». Туда необходимо включить абсо-лютно все блюда, которые относятся к ланчам: супы, салаты, горячее и про-чее. Так же в напитках должна быть группа обеденного меню. Все дело в том, что аудитория ланчей рассматривает предложение в комплексе (сетом), поэтому нет необходимости анализовать отдельно товарные группы (салаты, горячее или супы ланчей). К сезонным предложениям действует такое же правило, как для обеденного меню.

Аналогично настройке «Категории для Мозга», описанные в шаге 9, созда-ются «Товарные группы для Мозга». Обратите внимание на частую ошибку с выгрузкой себестоимости из R-Keeper в систему Мозг! В случае, если у Вас в АВС анализе отображается нулевая себестоимость у реализованных блюд, а в StoreHouse себестоимость отображается корректно, проверьте коды группы, в которой находится это блюдо. Например, «Рис» находится в группе гарниры, необходимо проверить, что код группы в R-keeper равный 21 (рис. А) соответствует коду в StoreHouse (рис. Если нашли расхождение исправить необходимо в StoreHouse, указав код как в R-Keeper.

После этого необходимо очистить базу данных Рисунок А Рисунок Б Рисунок В Шаг 11. Порционный коэффициент Один из важнейших показателей в работе ресторана – это среднее количе-ство блюд и напитков на 1 гостя. Задача ресторатора – стремиться к идеальной модели посещения: когда гость заказывает первое блюдо, второе, десерт и повторяет напиток. Но как оценить ваше положение на данный момент, если в системе автоматизации большой набор на компанию – это одно блюдо, а бутылка вина – это 1 напиток?

Для системы автоматизации все блюда равны – и долька лимона и стейк, из напитков – и мед и бутылка виски. Для объективного анализа продаж такое тождество не подходит. Поэтому мы вводим в стандарт предприятия порционный коэффициент (ПК). Для внесения порционного ПК в системе автоматизации Р-Кипер необходимо создать целочисленное расширенное свойство для позиции меню. Это обычная функция, которую выполняет ИТ-специалист или компания, которая занимается поддержкой вашей системы автоматизации.

Коллеги из отрасли говорят, что такая возможность есть в ТТК системы автоматизации, но я не знаком с этой технологией. Полноценное блюдо, например, салат «Цезарь обладает ПК = 100 (%).

В системе автоматизации необходимо ставить целые числа без%, без точек и запятых, то есть цифру 100, 200 и так далее. Например, если блюдо большое и подается на двоих, его порционный коэффициент равен 200 (2 умножить на 100), на троих - 300.

А небольшому блюду, равному половине порции, нужно поставить коэффициент 50 (0.5 умножить на 100). Чайник чая обычно заказывается двумя гостями, поэтому ПК=200, а вот рюмка крепого алкоголя в наших ресторанах равна ½ порции, то есть имеет ПК=50. По такому же принципу разделяются напитки на баре.

Позиции, которые не являются блюдами, к примеру мята, или мед имеют ПК=0. Стандарт Zuma Consulting для расстановки порционного ПК в системе автоматизации приведен в таблице: Группы блюд ПК Дополнения Кухня Салаты, холодные закуски 1 Роллы (4шт) 0,5 Суши 0,2 Сашими 0,5 Горячие блюда 1 Супы 1 Десерты 1 Гарниры 0,5 Хлеб 0,5 Выпечка (пироги, пирожки) 0,5 Соусы, добавки 0 Большие блюда на компанию Для горячих - вес свыше 600 г. Делим вес на 300 Добавки, специи, соуса 0 Бар Чай пакет 1 Чай чайник 2 Кофе 1 Коктейль алкогольный, безалкогольный 1 Коктейль большой объем (двойной от стандартного) 2 Порция крепкого алкоголя 50 мл. 0,5 Бутылка крепкого алкоголя Объем бутылки делим на 100 Порция вина 120-150 мл.

1 Бутылка вина 750 мл. 5 Вода и напитки бут.

Р Кипер Как Пользоваться

250 мл 1 Если бутылка, объем делим на 250 Сок 250 мл. 1 Пиво 0,33 мл. 1 Пиво 0,5 1 Пиво 1000 мл.

Программа Р Кипер

2 Морс 1000 мл. 4 Объем делим на 250 Сигареты, кальяны 0 Добавки, специи 0 Прочее Модификаторы 0 Если без списания комплектом Опен фуд (открытое блюдо) 1 Блюда банкет 1 Добавки, специи 0 Бизнес ланч Горячее с гарниром 1 Горячее без гарнира 0,5 Гарнир 0,5 Супы 1 Салат 1 Десерт 0,5 Напиток Согласно основным блюдам В вашем ресторане может быть уникальная ситуация с некоторыми блюдами и напитками.

Расставляйте ПК согласно логике – блюдо или напиток на самом деле на какое количество порций? Ведь главная задача – получить объективный показатель среднего количества блюд и напитков на гостя. Инструкция по созданию порционного коэффициента для системы ав-томатизации R-Keeper: 1.Зайти в «Настройки»= «Расширенные свойства» 2.

Создать «Новый тип расширенных свойств» 3. У созданного типа указать параметры как указано на рисунке. Красными точками точками отмечены поля, которые нужно настроить по образцу.

Выбрать слева в меню навигации поле «Меню, модификаторы», в основ-ном окне «Элемент меню» и нажать кнопку «Ок» 5. Затем в «Меню» у свойств любого блюда появится группа свойств «Ex-tended» и параметр «Порционный коэфф» После того, как вы создали классификации «Категории для Мозга», «Товарные группы для Мозга» и «Порционный коэффициент», необходимо поставить задачу технологу, или бухгалтерку-калькулятору каждое блюдо вашего ресторана разнести по этим классификаторам и назначить ему порционный К по стандартам, указанным выше. К примеру, блюдо «Калифорния» необходимо отнести к категории «Кухня Меню», к товарной группе «Роллы» и назначить порционный К = 100. И так для каждой позиции в меню ресторана. Данную настройку нужно провести для каждого блюда в вашей базе данных, даже которые на сегодняшний день неактивны, или удалены. Сделать это необходимо по простой причине – сравнивая периоды, вы будете захватывать более ранние месяцы, в которые проходила реализация удаленных позиций.

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

Верное количество гостей Средний чек на гостя и средний чек на заказ – один их базовых показателей в ресторанном бизнесе по всему миру. Однако, очень часто я встречаю картину, когда рестораторы вообще не задумываются о том, насколько верно сотрудники зала вносят количество гостей в чек перед его закрытием. Более того, относятся к этому очень «халатно». А ведь неверное количество гостей существенно искажает данные и не дает возможности ставить цели по показателям. В итоге искажен не только средний чек на гостя, но так же показатель среднего количества блюд и напитков на одного гостя, оборачиваемости места, оценки эффективности загрузки ресторана и другие KPI ресторана. На самом деле вносить верное количество гостей в чек – это сложно.

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

Для остальных существует два способа, с помощью которых можно вести контроль. Первый – простой, когда менеджер, делая «восьмерку», заглядывает в станцию pos-терминала и сверяет фактическое количество гостей за столиком с той информацией, что есть в чеке. Второй способ более сложный: сотрудник службы безопасности или другое ответственное лицо проверяет по камерам те чеки, в которых гостей мало, например 2, а блюд и напитков заказано на дюжину. Без автоматизации такой способ весьма трудоемок, в нашей компании этот процесс автоматизирован: программа показывает чек и время его открытия по заданным параметрам (более 4 блюд на гостя). Согласитесь, что это очень нетипично. Настройка автоматического импорта Данный ШАГ предназначен исключительно для IT-специалистов вашей компании, или компании, которая обслуживает систему автоматизации.

Данные из СА в Мозг отправляются по http-протоколу в виде архива с файлами csv. Для импорта эти файлы следует поместить в архив arch.tar.gz и отправить через форму по адресу указав id организации и базы данных, которые можно посмотреть в настройках в разделе Импорт данных. На данный момент автоматизирован импорт данных для систем R-Keeper 7 (для импорта себестоимостей необходим StoreHouse 4) и Iiko 4.3 (для импорта себестоимости необходима лицензия сервера API).

ПО для автоматического импорта данных можно загрузить по адресу Ссылка также доступна в настройках Мозга в разделе 'Импорт данных'. Папку mozgimport в архиве нужно распаковать, например, в корень диска C.

ПО представляет собой скрипты командной строки и powershell, а также программы для архивирования (7z) и http-соединения (curl). Для работы импорта на сервере должны быть установлены powershell, sqlcmd и Microsoft Visual C 2010 (x64). Для импорта себестоимостей из StoreHouse4 на сервере должна быть зарегистрирована библиотека sh4ole.dll.