Главная» Новости» Новости додо пицца. Ищете информацию о базе знаний Додо? Мы предлагаем вам различные полезные советы и рекомендации, которые помогут вам максимально эффективно использовать эту базу знаний. Улучшите свой опыт работы с Додо и получите максимум пользы и результативности!
Что нужно, чтобы стать зерокодером
- Что нужно, чтобы стать зерокодером
- Додо ис база знаний
- Пожалуй, лучшая база знаний для лучшей сети пиццерий!
- ВТИ-Сервис - эксперт автоматизации
Вкусная пицца для сотрудников
Так с 2012 года в пиццериях установлены камеры, которые позволяют клиентам наблюдать за процессом приготовления пиццы [13] [9] [25]. Компания использует системы на основе нейронных сетей для определения настроения посетителей [26] , отслеживания распределения гостей по времени и даже контроля качества пиццы по малозаметным особенностям теста [27]. Структура[ править править код ] Головной офис «Додо Пиццы» расположен в Сыктывкаре. С 2015 года он занимает здание бывшего советского завода паровых котлов. Новые франчайзи в обязательном порядке проходят 22-дневное обучение в головном офисе в Сыктывкаре, а разрешение на открытие пиццерии в выбранном месте получают только попробовав силы в небольшом городе. Компания разрабатывает для франчайзи дизайн-проекты помещений, регламентирует закупку продуктов и помогает в обучении сотрудников. Контролем работы франчайзи занимается отдельная структура «Додо Контроллинг» [6].
Для заказа нам нужно реализовать простой flow: Клиент заходит на статический сайт с ценами, выбирает продукты и звонит по номеру, который указан на сайте. Клиент называет продукты, которые хочет добавить в заказ. Называет свой адрес и имя. Оператор принимает заказ. Заказ отображается в интерфейсе принятых заказов. Все начинается с отображения меню. Залогиненный пользователь-оператор в один момент времени принимает лишь один заказ. Поэтому draft-корзина может храниться в его сессии сеанс пользователя хранится в памяти.
Там объект Cart, в котором продукты и информация о клиенте. По продукту вытаскивается информация из базы и добавляется информация о продукте в корзину. Да, здесь можно не вытаскивать продукт из базы, а передавать с фронтенда. Но для наглядности я показал именно путь из базы. Далее вводим адрес и имя клиента. При нажатии «Создать заказ»: Запрос отправляем в OrderController. Получаем Cart из сессии, там лежат продукты в нужном нам количестве. Дополняем Cart информацией о клиенте и передаем в метод AddOrder класса ReceivingOrderService, где он сохраняется в базу.
В базе есть таблицы с заказом, составом заказа, клиентом и они все связаны. Интерфейс отображения заказа идет и вытаскивает последние заказы и отражает их. Новые модули Прием заказа был важен и необходим. Нельзя сделать бизнес по продаже пиццы, если нет приема заказа для продажи. Поэтому система начала обрастать функционалом — примерно с 2012 по 2015 года. За это время появилось много различных блоков системы, которые я буду называть модулями, в противовес понятию сервиса или продукта. Модуль — это набор функций, которые объединены какой-то общей бизнес-целью. При этом физически они находятся в одном приложении.
Модули можно назвать блоками системы. Например, это модуль отчетов, интерфейсы админки, трекер продуктов на кухне , авторизация. Это всё разные интерфейсы для пользователя, некоторые имеют даже различные визуальные стили. При этом все в рамках одного приложения, одного работающего процесса. Технически модули оформлялись как Area вот такая идея даже осталась в asp. Там были отдельные файлы для фронтенда, моделей, а также свои классы контроллеров. В итоге система преобразовалась из такой... Это: Site — первая версия сайта dodopizza.
Export: выгрузка отчетов из Dodo IS для 1C. Personal — личный кабинет сотрудника. Отдельно разрабатывался и имеет свою точку входа и отдельный дизайн. Позже мы ушли от него, переведя всю статику на CDN Akamai. Остальные же блоки находились в приложении BackOffice. Пояснение по названиям: Cashier — Касса ресторана. ShiftManager — интерфейсы для роли «Менеджер смены»: оперативная статистика по продажам пиццерии, возможность поставить в стоп-лист продукты, изменить заказ. OfficeManager — интерфейсы для роли «Управляющий пиццерии» и «Франчайзи».
Здесь собраны функции по настройке пиццерии, её бонусных акций, прием и работа с сотрудниками, отчеты. PublicScreens — интерфейсы для телевизоров и планшетов, висящих в пиццериях. На телевизорах отображается меню, рекламная информация, статус заказа при выдаче. Они использовали общий слой сервисов, общий блок доменных классов Dodo. Core, а также общую базу. Иногда еще могли вести по переходам друг к другу. В том числе к общим сервисам ходили и отдельные сайты, вроде dodopizza. При появлении новых модулей старались по максимуму переиспользовать уже созданный код сервисов, хранимых процедур и таблиц в базе.
Для лучшего понимания масштаба модулей, сделанных в системе, вот схема из 2012 года с планами развития: К 2015 году всё на схеме и даже больше было в продакшн. Прием заказа перерос в отдельный блок Контакт Центра, где заказ принимается оператором. Появились общедоступные экраны с меню и информацией, висящие в пиццериях.
Регистрация аккаунта сотрудника происходит при приеме на работу. Данные для входа человек получает от руководства. Новый сотрудник должен заполнить анкету с указанием таких данных: телефонного номера для получения SMS-сообщения с кодом подтверждения; фамилии, имени и отчества; даты рождения. Вход в личный кабинет Авторизоваться в системе можно с помощью сайта либо приложения.
Большинство пользователей отдают предпочтение мобильному приложению. Ввести логин и пароль, которые были предоставлены сотруднику в процессе принятия на работу. Нажать «Войти». Теперь можно пользоваться полным функционалом личного кабинета. При возникновении проблем с доступом к персональному аккаунту следует обратиться за помощью к оператору горячей линии в телефонном режиме. Также можно отправить сообщение на сайте компании. Мобильное приложение Вне зависимости от места работы потенциального пользователя, предоставляется возможность использования персонального профиля с помощью официального сайта либо мобильного приложения.
Разработчики уже не занимались всеми задачами, а были разделены на команды. Проблемы В том числе из-за архитектуры но не только. Хаос в базе Одна база — это удобно. В ней можно добиться консистентности, причем за счет средств, встроенных в реляционные базы. Работать с ней привычно и удобно, особенно, если там мало таблиц и немного данных. Но за 4 года разработки в базе оказалось около 600 таблиц, 1500 хранимых процедур, во многих из которых была еще и логика. Увы, хранимые процедуры не приносят особого преимущества при работе с MySQL. Они не кэшируются базой, а хранение в них логики усложняет разработку и отладку. Переиспользование кода тоже затруднено. На многих таблицах не было подходящих индексов, где-то, наоборот, было очень много индексов, что затрудняло вставку.
Надо было модифицировать около 20 таблиц — транзакция на создание заказа могла выполняться около 3-5 секунд. Данные в таблицах не всегда были в наиболее подходящей форме. Где-то нужно было сделать денормализацию. Часть регулярно получаемых данных была в колонке в виде XML-структуры, это увеличивало время выполнения, удлиняло запросоы и усложняло разработку. К одним и тем же таблицам производились очень разнородные запросы. Особенно страдали популярные таблицы, вроде упоминавшейся таблицы orders или таблицы pizzeria. Они использовались для вывода оперативных интерфейсов на кухне, аналитики. Еще к ним обращался сайт dodopizza. Данные не были агрегированными и много расчетов происходило на лету средствами базы. Это создавало лишние вычисления и дополнительную нагрузку.
Часто код ходил в базу тогда, когда мог этого не делать. Где-то не хватало bulk-операций, где-то надо было бы разнести один запрос на несколько через код, чтобы ускорить и повысить надежность. Связность и запутанность в коде Модули, которые должны были отвечать за свой участок бизнеса, не делали этого честно. Некоторые из них имели дублирование по функциям для ролей. Например, локальному маркетологу, который отвечает за маркетинговую активность сети в своем городе, приходилось пользоваться как интерфейсом «Админа» для заведения акций , так и интерфейсом «Менеджера Офиса» для просмотра влияния акций на бизнес. Конечно, внутри оба модуля использовали один сервис, который работал с с бонусными акциями. Сервисы классы в рамках одного монолитного большого проекта могли вызывать друг друга для обогащения своих данных. С самими классами-моделей, которые хранят данные, работа в коде велась различно. Где-то были конструкторы, через которые можно было указать обязательные поля. Где-то это делалось через публичные свойства.
Конечно, получение и преобразование данных из базы было разнообразным. Логика была либо в контроллерах, либо в классах сервисов. Это вроде незначительные проблемы, но они сильно замедляли разработку и снижали качество, что приводило к нестабильности и ошибкам. Сложность большой разработки Трудности возникли и в самой разработке. Нужно было делать разные блоки системы, причем параллельно. Вместить нужды каждого компонента в единый код становилось все труднее. Было не просто договориться и угодить всем компонентам одновременно. К этому добавлялись ограничения в технологиях, особенно касаемо базы и фронтэнда. Нужно было отказываться от JQuery в сторону высокоуровневых фреймворков, особенно в части клиентских сервисов сайт. В каких-то частях системы могли бы использоваться базы, более подходящие для этого.
Например, позднее у нас был прецедент перехода с Redis на CosmosDB для хранения корзины заказа. Команды и разработчики, занимающиеся своей областью явно хотели большей самостоятельности для своих сервисов, как в части разработки, так и в части выкатки. Конфликты при мерже, проблемы при релизах. Если для 5 разработчиков эта проблема несущественна, то при 10, а уж тем более при планируемом росте, все стало бы серьёзнее. А а впереди должна была быть разработка мобильного приложения она стартанула в 2017, а в 2018 было большое падение. Разные части системы требовали разных показателей стабильности, но в силу сильной связности системы, мы не могли этого обеспечить. Ошибка при разработке новой функции в админке, вполне могла выстрелить в приеме заказа на сайте, ведь код общий и переиспользуемый, база и данные тоже едины. Вероятно, можно было бы и в рамках такой монолитно-модульной архитектуры не допускать этих ошибок и проблем: сделать разделение ответственности, проводить рефакторинг как кода, так и базы данных, чётко отделять слои друг от друга, следить за качеством каждый день. Но выбранные архитектурные решения и фокус на быстром расширении функционала системы привели к проблемам в вопросах стабильности. Как блог Сила ума положил кассы в ресторанах Если рост сети пиццерий и нагрузки продолжался бы в том же темпе, то через некоторое время падения были бы уже такими, что система и не поднимется.
Хорошо иллюстрирует проблемы, с которыми мы начали сталкиваться к 2015 году вот такая история.
Как зерокодинг помогает «Додо Пицце» быстро тестировать гипотезы: новая база знаний для сотрудников
Таким образом информационная система реально влияет на увеличение эффективности и прибыльности «Додо Пиццы», так как стоимость труда являются одной из главнейших статей расхода для нашего бизнеса. Мы называем это «dodo-эффект». Лента новостей. Кассы также подключены к «облаку», поэтому с помощью Додо ИС офис может отслеживать все финансовые показатели любой пиццерии в онлайн режиме. Мы выкладываем туда свежие новости компании, обсуждаем актуальные тренды, храним все стандарты, обучающие статьи и курсы. «Додо ИС» была призвана сделать работу в пиццерии легче. Информационная система Додо.
Use saved searches to filter your results more quickly
- Use saved searches to filter your results more quickly
- Додо ис база знаний - 84 фото
- Франшиза «Додо Пиццы»: официальный сайт, цены, условия участия, роялти
- *Как видеоаналитика и машинное зрение помогают оценивать качество пиццы
- Выживают только… техно-параноики
Статистика пиццерий Додо Пицца
Основатель "Додо пиццы" выпустил бесплатное мобильное приложение для рестораторов. Dodo IS — информационная система как ядро франчайзинга. Додо ис – это база знаний компании Dodo Pizza, которая содержит информацию о всех процессах, продуктах, технологиях и т.д., используемых в работе сети. Владелец сайта предпочёл скрыть описание страницы. Сейчас у нас уже есть база знаний, в которой доступны статьи, рассказывающие о возможных проблемах, способах их решения и нестандартных сценариях работы. Какая техническая база стоит за системой Додо IS?
Выручка пиццерий
- Условия покупки франшизы «Додо пиццы»
- Navigation Menu
- Додо ис база знаний - 84 фото
- База знаний Додо 🔥. А вы знали, что у нас есть сайт, который называется База знаний?
- Как насчет бесплатной пиццы?
- «Додо Пицца» застраховалась от киберпреступников
Как создать личный кабинет на сайте Додо ИС
Информационная система Dodo IS состоит из 44 различных сервисов, таких как Трекер, Кассы ресторана или Базы знаний и многих других. Инспекторы пиццерии — это наша агентская сеть, которая помогает находить нарушения в пиццериях Додо Пиццы. Стандарты Додо пицца. База знаний додо. Личный кабинет сотрудника. База знаний ИИ Презентация. История о том, как мы автоматизировали контакт-центр «Додо Пиццы». «Додо ИС» — это «Скайнет» среди систем управления предприятием.
База знаний додо
Автор популярного блога «Сила ума», в котором он честно и открыто рассказывает о своем бизнесе, и герой книги «И ботаники делают бизнес». По итогам 2016 года компания «Додо Пицца» стала крупнейшей сетью в России по количеству пиццерий. Сегодня сеть насчитывает более 180 пиццерии в 9 странах, включая США и Китай.
Между Dodo IS и специализированными программами будет налажен обмен данными. В Dodo IS будет осуществляться прием и управление заказами, товарный и складской учет, управление запасами, управление персоналом, клиентская база. С информационной системой будет интегрирован сайт для клиентов и мобильные приложения. Информационная система является одним из главных конкурентных преимуществ нашей бизнес-концепции.
Она задумывалась изначально как ядро нашего бизнеса. Почему мы решили создавать собственную информационную систему? Специализированное решение лучше универсального Любое универсальное программное решение всегда проигрывает приложениям, созданным под конкретный бизнес и его специфические бизнес-процессы. К тому же на данный момент на рынке просто не существует хороших решений для бизнеса, ориентированного на доставку. Все существующие приложения слишком универсальные. Либо они требуют значительно доработки, либо нам придется подстраивать бизнес под готовую программную систему.
Однако наша цель — создать эффективный бизнес формат, который можно будет масштабировать на федеральный и даже транснациональный уровень. Мы можем это сделать только с собственной системой, которая будет учитывать всю специфику и детали нашего бизнеса. Выгода в долгосрочной перспективе Разработка собственной информационной системы является дорогим решением в среднесрочной перспективе. Однако в долгосрочной перспективе с учетом масштабирования бизнеса разработка своего ПО является более выгодным проектом, так как все авторские права на систему принадлежат нашей компании и нам не придется производить лицензионные отчисления после каждого запуска нового розничного объекта. Франчайзинг Собственная информационная система будет увеличивать эффективность розничных операций. В будущем наши франчайзи будут получать от не только торговую марку, меню и стандарты, но и информационную систему, созданную под наши уникальные бизнес-процессы.
Это придаст нашей франчайзинговой модели дополнительную ценность. Фактически мы будем лицензировать нашу информационную систему вместе с бизнес-системой. Единая информационная система позволит также контролировать работу франчайзи, в частности — качество проводимых операций, что позволит поддерживать единые стандарты по всей сети. Почему мы разрабатываем информационную систему в виде веб-приложения? Наша система изначально задумывалась как SaaS-решение software as a service. Информационная система в данной модели представляет из себя веб-приложение.
Пользователи системы работают с программой через Интернет, используя обычный веб-браузер. Простота использования и поддержки SaaS — технология будущего. Доступность и высокая скорость Интернета позволит работать с программным обеспечением, не устанавливая его на локальный компьютер. Сегодня для использования информационной системы Dodo IS нужно всего лишь зайти через стандартный веб-бразуер на наш сайт и ввести логин и пароль. Необходимость администрирования, настройки и технической поддержки локального сети и программного обеспечения отпадает. Эффективное решение для большой розничной сети SaaS-модель идеально подходит для розничной сети.
Преимущества: быстрое развертывание системы, единая техническая поддержка, единое место хранения данных, более высокая безопасность, единая база клиентов, адресов, телефонов.
В том числе к общим сервисам ходили и отдельные сайты, вроде dodopizza. При появлении новых модулей старались по максимуму переиспользовать уже созданный код сервисов, хранимых процедур и таблиц в базе. Для лучшего понимания масштаба модулей, сделанных в системе, вот схема из 2012 года с планами развития: К 2015 году всё на схеме и даже больше было в продакшн. Прием заказа перерос в отдельный блок Контакт Центра, где заказ принимается оператором. Появились общедоступные экраны с меню и информацией, висящие в пиццериях. На кухне есть модуль, который автоматически воспроизводит голосовое сообщение «Новая пицца» при поступлении нового заказа, а также печатает накладную для курьера. Это сильно упрощает процессы на кухне, позволяет не отвлекаться на большое количество простых операций сотрудникам. Блок доставки стал отдельной Кассой Доставки, где заказ выдавался курьеру, который предварительно встал на смену. Учитывалось его рабочее время для начисления зарплаты.
Параллельно с 2012 по 2015 появилось более 10 разработчиков, открылось 35 пиццерий, развернули систему на Румынию и подготовили к открытию точек в США. Разработчики уже не занимались всеми задачами, а были разделены на команды. Проблемы В том числе из-за архитектуры но не только. Хаос в базе Одна база — это удобно. В ней можно добиться консистентности, причем за счет средств, встроенных в реляционные базы. Работать с ней привычно и удобно, особенно, если там мало таблиц и немного данных. Но за 4 года разработки в базе оказалось около 600 таблиц, 1500 хранимых процедур, во многих из которых была еще и логика. Увы, хранимые процедуры не приносят особого преимущества при работе с MySQL. Они не кэшируются базой, а хранение в них логики усложняет разработку и отладку. Переиспользование кода тоже затруднено.
На многих таблицах не было подходящих индексов, где-то, наоборот, было очень много индексов, что затрудняло вставку. Надо было модифицировать около 20 таблиц — транзакция на создание заказа могла выполняться около 3-5 секунд. Данные в таблицах не всегда были в наиболее подходящей форме. Где-то нужно было сделать денормализацию. Часть регулярно получаемых данных была в колонке в виде XML-структуры, это увеличивало время выполнения, удлиняло запросоы и усложняло разработку. К одним и тем же таблицам производились очень разнородные запросы. Особенно страдали популярные таблицы, вроде упоминавшейся таблицы orders или таблицы pizzeria. Они использовались для вывода оперативных интерфейсов на кухне, аналитики. Еще к ним обращался сайт dodopizza. Данные не были агрегированными и много расчетов происходило на лету средствами базы.
Это создавало лишние вычисления и дополнительную нагрузку. Часто код ходил в базу тогда, когда мог этого не делать. Где-то не хватало bulk-операций, где-то надо было бы разнести один запрос на несколько через код, чтобы ускорить и повысить надежность. Связность и запутанность в коде Модули, которые должны были отвечать за свой участок бизнеса, не делали этого честно. Некоторые из них имели дублирование по функциям для ролей. Например, локальному маркетологу, который отвечает за маркетинговую активность сети в своем городе, приходилось пользоваться как интерфейсом «Админа» для заведения акций , так и интерфейсом «Менеджера Офиса» для просмотра влияния акций на бизнес. Конечно, внутри оба модуля использовали один сервис, который работал с с бонусными акциями. Сервисы классы в рамках одного монолитного большого проекта могли вызывать друг друга для обогащения своих данных. С самими классами-моделей, которые хранят данные, работа в коде велась различно. Где-то были конструкторы, через которые можно было указать обязательные поля.
Где-то это делалось через публичные свойства. Конечно, получение и преобразование данных из базы было разнообразным. Логика была либо в контроллерах, либо в классах сервисов. Это вроде незначительные проблемы, но они сильно замедляли разработку и снижали качество, что приводило к нестабильности и ошибкам. Сложность большой разработки Трудности возникли и в самой разработке. Нужно было делать разные блоки системы, причем параллельно. Вместить нужды каждого компонента в единый код становилось все труднее. Было не просто договориться и угодить всем компонентам одновременно. К этому добавлялись ограничения в технологиях, особенно касаемо базы и фронтэнда. Нужно было отказываться от JQuery в сторону высокоуровневых фреймворков, особенно в части клиентских сервисов сайт.
В каких-то частях системы могли бы использоваться базы, более подходящие для этого. Например, позднее у нас был прецедент перехода с Redis на CosmosDB для хранения корзины заказа.
Клиенты ведут бухгалтерию в «1С:Фреш», поэтому мы развернули для франчайзи отдельное облако на технологии Фреш, в котором сделали необходимые доработки. Сейчас так работают уже с 10 облачными базами Додо франчайзи. Автоматизировали учет оплаты самозанятым и контроль доставок В ходе доработок сделали загрузку и учет зарплаты самозанятых, это актуально для многих франчайзи. Курьеры часто работают как самозанятые поставщики услуг по доставке. Теперь поступления услуг на оплату создаются автоматически и на основании приходов формируются платежные поручения в банк. Решили еще одну задачу по работе с курьерами — настроили сверку со Сбербанком для контроля доставок. Были случаи, когда недобросовестные курьеры оставляли деньги за доставку себе. Например, клиент заказывал пиццу с оплатой по карте, а потом расплачивался наличными.
Курьер не отражал это в программе — там по-прежнему была указана оплата по карте. А наличные курьер забирал себе. Если в течение дня происходит несколько сотен доставок, отследить такие случаи вручную сложно. Теперь можно сверить отчеты по эквайрингу сколько перевели за смену, по конкретному терминалу с информацией, которую указывают курьеры.