Александр Андронов — CEO Dodo EngineeringDodo Engineering — часть Dodo Brands, развивает собственную цифровую платформу Додо ИС для управления ресторанным. «Додо ИС» была призвана сделать работу в пиццерии легче. Dodo Pizza часто называет себя ИТ-компанией. Дмитрий Павлов, директор по продукту Dodo IS, рассказывает подробности об устройстве системы и делится несколькими кейсами, когда все пошло не так.
Франшиза «Додо Пиццы»: сильный продукт, передовые технологии и честные условия
последние новости на сегодня - РБК Инвестиции. Основатель «Додо Пицца» Федор Овчинников рассказал в Facebook об антикризисной стратегии, которую компания вынуждения принять в сложившихся условиях. Как Додо Пицца прошла путь от Scrum до LeSS Huge и осознанно отступала от правил этих фреймворков и Agile-методологии. Основа франшизы «Додо Пиццы» — облачная ERP-система «Додо ИС» (Dodo IS), которая организует рабочие процессы пиццерии, включая обработку заказов, работу кухни, доставку, управление штатом и маркетинг[24]. База знаний Додо создавалась 6 лет назад как блог на WordPress, — вполне объяснимый выбор для быстрого старта. «Додо ИС» — это «Скайнет» среди систем управления предприятием.
Автоматизируем бизнес по-крупному: создаём свой «цифровой мозг»
Разные части системы требовали разных показателей стабильности, но в силу сильной связности системы, мы не могли этого обеспечить. Ошибка при разработке новой функции в админке, вполне могла выстрелить в приеме заказа на сайте, ведь код общий и переиспользуемый, база и данные тоже едины. Вероятно, можно было бы и в рамках такой монолитно-модульной архитектуры не допускать этих ошибок и проблем: сделать разделение ответственности, проводить рефакторинг как кода, так и базы данных, чётко отделять слои друг от друга, следить за качеством каждый день. Но выбранные архитектурные решения и фокус на быстром расширении функционала системы привели к проблемам в вопросах стабильности. Как блог Сила ума положил кассы в ресторанах Если рост сети пиццерий и нагрузки продолжался бы в том же темпе, то через некоторое время падения были бы уже такими, что система и не поднимется. Хорошо иллюстрирует проблемы, с которыми мы начали сталкиваться к 2015 году вот такая история.
В блоге « Сила ума » был виджет, который показывал данные по выручке за год всей сети. Виджет обращался к публичному API Dodo, которое предоставляет эти данные. Виджет показывался на каждой странице и делал запросы по таймеру каждые 20 секунд. Запрос уходил в api. Запрос на статистику по выручке шел сразу в базу и начинал запрашивать данные по заказам, агрегировать данные прямо на лету и выдавать сумму.
В эту же таблицу заказов ходили Кассы в ресторанах, выгружали список принятых за сегодня заказов, в неё же добавлялись новые заказы. Кассы делали свои запросы каждые 5 секунд или по обновлению страницы. Схема выглядела так: Однажды осенью, Федор Овчинников написал в свой блог длинную и популярную статью. На блог пришло очень много людей и стали внимательно всё читать. Пока каждый из пришедших человек читал статью, виджет с выручкой исправно работал и запрашивал API каждые 20 секунд.
API вызывало хранимую процедуру на расчет суммы всех заказов с начала года по всем пиццериям сети. Агрегация шла по таблице orders, которая очень популярна. В неё же ходят все кассы всех открытых ресторанов на тот момент. Кассы перестали отвечать, заказы не принимались. Ещё они не принимались с сайта, не появлялись на трекере, менеджер смены не мог увидеть их в своем интерфейсе.
Это не единственная история. К осени 2015 года каждую пятницу нагрузка на систему была критическая. Несколько раз мы выключали публичное API, а однажды, нам пришлось даже отключить сайт, потому что уже ничего не помогало. Был даже список сервисов с порядком отключения при серьезных нагрузках. С этого времени начинается наша борьба с нагрузками и за стабилизацию системы с осени 2015 до осени 2018.
Именно тогда случилось « Великое падение ». Дальше тоже иногда происходили сбои, некоторые были весьма чувствительными, но общий период нестабильности сейчас можно считать пройденным. Бурный рост бизнеса Почему нельзя было «сделать сразу хорошо»? Достаточно посмотреть на следующие графики. Также в 2014-2015 было открытие в Румынии и готовилось открытие в США.
Сеть росла очень быстро, открывались новые страны, появлялись новые форматы пиццерий, например, открылась пиццерия на фудкорте. Всё это требовало значительного внимания именно к расширению функций Dodo IS. Без всех этих функций, без трекинга на кухне, учета продуктов и потерь в системе, отображения выдачи заказа в зале фудкорта, вряд ли бы мы сейчас рассуждали о «правильной» архитектуре и «верном» подходе к разработке. Еще препятствиями для своевременного пересмотра архитектуры и вообще внимания к техническим проблемам, был кризис 2014 года. Такие вещи больно бьют по возможностям для роста команд, особенно для молодого бизнеса, каким была Додо Пицца.
Быстрые решения, которые помогли Проблемы требовали решения. Условно, решения можно разделить на 2 группы: Быстрые, которые тушат пожар и дают небольшой запас прочности и выигрывают нам время на изменения. Системные и, поэтому, долгие. Реинжиниринг ряда модулей, разделение монолитной архитектуры на отдельные сервисы большинство из них вполне не микро, а скорее макросервисы и про это есть доклад Андрея Моревского. Сухой список быстрых изменений таков: Scale up мастер базы Конечно, первое, что делается для борьбы с нагрузками — увеличивается мощность сервера.
Это делали для мастер базы и для веб серверов. Увы, это возможно лишь до некоторого предела, дальше становится слишком дорого. С 2014 года мы перешли в Azure, на эту тему мы тоже писали еще в то время в статье « Как Додо Пицца доставляет пиццу с помощью облака Microsoft Azure ». Но после череды увеличений сервера под базу уперлись по стоимости. Реплики базы на чтение Реплик для базы сделали две: ReadReplica для запросов на справочники.
Применяется для чтения справочников, типа, города, улицы, пиццерии, продуктов slowly changed domain , и в тех интерфейсах, где допустима небольшая задержка. Этих реплик было 2, мы обеспечивали их доступность также, как и мастера. ReadReplica для запросов на отчеты. У этой базы доступность была ниже, но в неё ходили все отчеты. Пусть у них тяжелые запросы на огромные пересчеты данных, но зато они не влияют на основную базу и операционные интерфейсы.
Сейчас у нас 456 пиццерий и мы работаем в 12 странах. У нас сеть пиццерий, но это всего лишь прикрытие. Мы разрабатываем информационную систему — Dodo IS. Когда вы заходите в нашу пиццерию, вы видите «ТВ-борды», меню, кассу ресторана, и всё это — составные части нашей информационной системы. Нам нужны пиццерии, чтобы куда-то нашу систему выкладывать.
У нас есть модуль трекинга, через который проходят все заказы. У нас есть « Оленька » — «искусственный Додо-разум», умная система, которая помогает следить за новыми заказами и поддерживать нужный темп работы. Также есть интерфейс менеджера смены, управляющего пиццерии, огромный блок с отчётами — в общем, это очень большая система. У нас также есть Digital часть, каналы, где можно оформить заказ — это сайт, это приложение, колл-центр. Наш бизнес в основном оффлайновый, но мы его «диджитализируем» с помощью Dodo IS.
Мы очень быстро растём. Сейчас у нас уже 70 разработчиков и 9 команд. Несколько месяцев назад у нас было 50 разработчиков, и мы поставили себе цель вырасти до 250 до конца 2020 года. Синим цветом — наш предполагаемый график роста, красным — то, как мы реально растём В начале 2018 года у нас было 6 команд и мы использовали Scrum. За первую половину 2018 года нас 2 раза очень мощно накрыло проблемами.
Эти события подтолкнули нас к первой революции. Мы поняли, что надо перестраивать процессы и запустили LeSS на 6 команд. Потом мы начали экспериментировать со Sprint Reviews, с OKR, ввели дизайн-воркшопы и stop-the-line практику. И мы сейчас продолжаем эволюционировать, про это дальше и расскажем. Это наш личный опыт, используйте его на свой страх и риск или не используйте вовсе.
У вас свой контекст, своя команда и своя специфика продукта. В Додо есть несколько принципов. У нас открытые кухни, там есть камеры, и мы свою финансовую отчётность публикуем открыто. Следующий принцип — «no-bullshit», и этот принцип позволяет нам оспаривать любые решения. Любой человек, если видит «буллшит», то есть фигню, в чём угодно, в процессах, в поведении, он может об этом открыто сказать.
Ещё один принцип — «мудаков у нас нет», то есть мы предполагаем, что люди у нас правильные, открытые, честные. А если это не так, то мы таких не нанимаем, или они уходят.
По состоянию на сентябрь 2022 года, к сети относятся 833 заведения в 16 странах. Большая часть точек при этом принадлежит франчайзи [10] [11]. В октябре 2021 года основатель сети Федор Овчинников выступил с заявлением, в котором предупредил, что часть франчайзинговых точек «Додо Пицца» может быть закрыта из-за «несоответствия стандартам качества», а в одном из российских городов может быть закрыта вся сеть [11]. Германия[ править править код ] В Германии «Додо Пицца» планировала начать работать в партнёрстве с местной сетью Uno Pizza [12].
В марте 2018 года они подписали предварительное соглашение. Планировалось в течение 2019 года перевести под бренд «Додо Пиццы» 14 заведений в Саксонии и Саксонии-Анхальте , а затем открыть до 50 новых пиццерий [9] [13]. Первое заведение открылось в Оксфорде, Миссисипи , небольшом городе, где также располагалась редакция PMQ Magazine [17] [18]. Вторая пиццерия открылась в Саутхэйвене, после которого «Додо Пицца» планировала открыть заведения в Мемфисе и Джермантауне.
В своей работе компания делает ставку на инновационные технологии. Над развитием платформы трудятся свыше 250 разработчиков подразделения Dodo Engineering. А всего в компании работает более 30 000 сотрудников. В сотрудниках Додо Пицца ценит открытость, трудолюбие и готовность развиваться. Компания стремится проявлять заботу о команде во всех аспектах, включая обязательное обучение. Основная задача — сделать процесс получения знаний максимально простым и комфортным для каждого человека. Не хватало возможностей для улучшения курсов и геймификации Задача службы поддержки клиентов Додо Пиццы — помочь решить все вопросы, чтобы преодолеть преграды на пути к заказу. В месяц приходит 50 000 клиентских запросов, каждый из которых нужно обработать. В команде есть специалисты из России и Казахстана, все начали работать удалённо ещё до пандемийного 2020 года. Важно обучать всех сотрудников сразу, очень быстро и по единым стандартам. Поэтому у компании наработана большая база по онлайн-обучению. Изначально мы пользовались двумя платформами для обучения, которые поддерживали курсы в формате SCORM. Это было не очень удобно, так как редактировать материал можно было только в специальной программе, после приобретения платной лицензии. У нас их было две, то есть из двадцати администраторов доступ к редактированию курсов был только у двоих. Если кто-то из этих сотрудников заболевал или нужно было быстро обновить информацию, приходилось всё бросать и срочно заниматься платформой. Другая проблема — образовательный контент находился в едином рабочем пространстве с пиццериями. Поэтому нужно было согласовывать любые крупные изменения на платформе. На доработку и улучшение платформы уходило много времени. Сами платформы обладали ограниченными техническими возможностями. Например, не было встроенных редакторов тестов, не было возможности добавить магазин подарков для мотивации сотрудников. Мы не могли добавить баллы, которые можно получать не только за прохождение курсов, но и за дополнительные действия. Поэтому было принято решение выбирать новую платформу для онлайн-обучения.
История «додо пиццы». Dodo IS — информационная система как ядро франчайзинга
Как оформить заказ Укажите в форме данные вашей компании, сумму и количество сертификатов. Например: на 10 000 рублей вы можете оформить десять сертификатов по 1 000 рублей и раздать каждому сотруднику или оформить один сертификат для большого мероприятия. В течение часа персональный менеджер обработает заявку и выставит счет. Для удобства оформления можно использовать электронный документооборот ЭДО.
И мы решили сделать систему, настолько умную, чтобы она вместо человека управляла бы бизнесом ну, насколько это возможно и помогала бы заработать больше денег. Мы долго вынашивали идею системы, не знающей усталости, под управлением которого билось бы цифровое сердце Додо. Мозга, который управлял бы всеми процессами пиццерии с выгодой для партнёров.
Раз уж автоматизировать, то автоматизировать по-крупному В 2021 году мы начали разрабатывать систему «Небесный логист», которая позволит партнёрам легко настраивать стратегию для себя простым движением руки. Как в играх: хочешь доставлять быстрее — смещаешь ползунок левее; хочешь дешевле — ползунок правее. По задумке так будут настраиваться все стратегии: от параметров закупки по каким ценам и с какими сроками доставки Небесный логист будет заказывать продукты до количества курьеров на смене. От управления зоной доставки до управления стопами на кухне и балансировкой заказов между пиццериями. А если партнёр ещё не решил, что ему важнее, то система подумает за него и выдаст рекомендации, как побольше заработать или сэкономить. Что будет уметь Небесный логист: собирать заказы в поездку и назначать поездки на курьеров автоназначение ; управлять количеством курьеров на смене так, чтобы они не сидели без дела, но и чтобы не было недостатка курьеров; управлять кухней так, чтобы заказ был готов чётко к прибытию курьера.
Ещё на старте мы понимали, что замахнулись на что-то сложное и масштабное, поэтому решили есть слона по частям. Начали с автоматизации доставки, чтобы система сама назначала заказы курьерам, учитывая дальность заказов, тип транспорта курьера и количество заказов в поездке. Разрабатывать в вакууме — путь в никуда Мы — зрелая продуктовая команда, которая давно не смотрит на мир через розовые очки. Поэтому хорошо осознаём, что на старте разрабатываем идеализированный продукт в вакууме и постепенно будем вносить в него правки, отражающие реальное положение дел. Походы в пиццерию, проведение интервью с менеджерами, наблюдения из аналитики дадут нам представление о работе курьеров в пиццериях, но невозможно узнать всё заранее. В нашей идеализированной модели курьеры чётко выполняют свои обязанности, на смене всё идёт по плану.
В реальности в пиццерии всё может быть совсем не так. И чтобы понять, как и с чем мы столкнёмся при внедрении продукта на всю сеть, нужно обязательно тестировать в полях. Мы наметили итерации, каждая из которых — жизнеспособный продукт с некоторыми ограничениями. Как только получаем такой — выбираем жертву пиццерию, собираемся своей дружной командой и идём тестировать. Автоназначение: первый шторм В марте 22-го завершилась разработка в рамках первой итерации. На этом этапе мы хотели проверить жизнеспособность идеи автоматического назначения заказов на практике.
Ведь мало кто смотрит на экран, не отрываясь. Зайдя на сайт dodopizza. Читайте также:.
Также отсутствие собственных таблиц и индексов на них не позволяло написать более специфичные запросы, заточенные под своё использование. Для примера, трекеру может быть эффективно иметь индекс на пиццерию на таблице заказов. Мы всегда выгребаем из базы трекера заказы по пиццерии. При этом для приёма заказа не так важно, в какую пиццерию он падает, важнее, какой клиент сделал этот заказ. А значит там нужен индекс по клиенту. Ещё для трекера в таблице заказа не обязательно хранить id напечатанного чека или связанные с заказом бонусные акции. Эта информация наш сервис трекера не интересует. В общей монолитной базе таблицы могли быть только компромиссным вариантом между всеми пользователями.
Это было одной из изначальных проблем. Изначально архитектура была такая: Даже после выделения в отдельные процессы большая часть кодовой базы оставалась общей для разных сервисов. Всё, что ниже контроллеров, было единым и жило в одном репозитории. Использовались общие методы сервисов, репозиториев, общая база, в которой лежали общие таблицы. Разгружаем Трекер Главная проблема с трекером в том, что данные должны синхронизироваться между различными базами. Это же и главное его отличие от разделения Auth-сервиса, заказ и его статус могут изменяться и должны отображаться в различных сервисах. Мы принимаем заказ на Кассе Ресторана это сервис , он сохраняется в базе в статусе «Принят». После этого он должен попасть на трекер, где ещё несколько раз изменит свой статус: от «Кухня» до «Упакован».
При этом с заказом могут происходить какие-то внешние воздействия от Кассы или интерфейса Менеджера смены. Приведу в таблице статусы заказа с их описанием: Схема изменения статусов заказа выглядит так: Статусы меняются между разными системами. И здесь трекер не является конечной системой, в которой замыкаются данные. Мы видели несколько возможных подходов для разделения в таком случае: Концентрируем все действия заказа в одном сервисе. В нашем случае этот вариант требует слишком большого сервиса по работе с заказом. Если бы мы остановились на нём, то получился бы второй монолит. Проблемы бы мы не решили. Одна система делает вызов в другую.
Второй вариант уже интереснее. Но при нём возможны цепочки вызовов каскадные сбои , связность компонентов выше, управлять этим сложнее. Организуем события, и каждый сервис обменивается с другим через эти события. В итоге был выбран именно третий вариант, по которому все сервисы начинают обмениваться событиями друг с другом. То, что мы выбрали третий вариант значило, что для трекера будет своя база, а на каждое изменение заказа он будет посылать событие об этом, на которое подписываются другие сервисы и которое в том числе попадает в мастер-базу. Для этого нам нужен был некоторый сервис, который обеспечит доставку сообщений между сервисами. К тому времени у нас в стеке уже был RabbitMQ, отсюда и итоговое решение использовать его как брокер сообщений. На схеме показан переход заказа от Кассы Ресторана через Трекер, где он меняет свои статусы и отображение его на интерфейсе Заказы менеджера.
Здесь это Касса Ресторана: На Кассе полностью готов заказ, и его пора отправить на трекер. Бросается событие, на которое подписан трекер. Трекер, принимая себе заказ, сохраняет его в свою собственную базу, делая при этом событие «ЗаказПринятТрекером» и посылая его в RMQ. В шине событий на заказ уже подписаны несколько обработчиков.
Додо ис персонал
Разработан интерфейс Базы Знаний. «Додо ИС» была призвана сделать работу в пиццерии легче. Специалисты Додо Пиццы написали статью про базу знаний и запустили курс по созданию интерактивных элементов. Основатель "Додо пиццы" выпустил бесплатное мобильное приложение для рестораторов.
Вкусная пицца для сотрудников
Работаем с базами клиентов в отдельном облаке, которое позволяет держать свою доработанную конфигурацию. Рассказываем, с какой задачей к нам обратились клиенты. Это сервис для автоматизации работы франчайзи, в него поступает вся информация с рабочих мест пиццерий: что заказали, сколько нужно продуктов, куда поехал курьер. Функционала для ведения бухгалтерского учета в этой программе нет, данные нужно переносить в «1С». Своему первому клиенту среди франчайзи Додо мы помогаем с 2014 года. Пока у клиента работала одна пиццерия, достаточно было сопровождения «1С:Бухгалтерии» — бухгалтеры копировали данные из Додо ИС вручную. Но у компании появилась сеть пиццерий.
Ручной перенос данных занимал бы слишком много времени, нужно было с нуля настроить синхронизацию. Клиенты ведут бухгалтерию в «1С:Фреш», поэтому мы развернули для франчайзи отдельное облако на технологии Фреш, в котором сделали необходимые доработки. Сейчас так работают уже с 10 облачными базами Додо франчайзи. Автоматизировали учет оплаты самозанятым и контроль доставок В ходе доработок сделали загрузку и учет зарплаты самозанятых, это актуально для многих франчайзи. Курьеры часто работают как самозанятые поставщики услуг по доставке.
Мобильное приложение устанавливается на современные смартфоны, работающие на базе Android и iOS. При регистрации клиент указывает свои данные: номер мобильного телефона, на который поступит код подтверждения; реквизиты банковской карты для оплаты по безналичной системе; адрес доставки. После прохождения регистрации пользователю станет доступен ЛК на сайте «Додо Пицца». Рабочий аккаунт. Для сотрудников «Додо» существуют специально разработанные рабочие кабинеты, вход в которые осуществляется через сайт или бэк-офис компании. Регистрация может быть клиентской или рабочей. Как осуществить вход в «Додо ИС» Чтобы осуществить вход в систему Dodo IS, сотрудник ресторана должен ввести номер мобильного телефона, являющийся логином, и пароль, сгенерированный технической службой сайта на странице personal. После подтверждения учетной записи работник может изменить пароль. Для пользователей существует отдельный независимый вход на сайте auth. Чтобы войти в «Додо ИС», необходимо ввести логин и пароль, полученные при прохождении аутентификации.
Рейтинг пиццерий онлайн. Сайт, мобильные приложения и контакт-центр Сайт , мобильные приложения для iOS и Android , единый круглосуточный контакт центр 8-800-333-00-60 — неоднократно признавались лучшими в отрасли общественного питания. Естественно, ни одна локальная пиццерия не может себе позволить сервис такого уровня. Обучение сотрудников На все позиции в пиццерии выработана единая схема обучения: стажировка в пиццерии, онлайн-курсы и очное обучение в Сыктывкаре. В курсе прописано всё: какие материалы должен изучить сотрудник, какие тесты сдать, как должна проходить аттестация. Самые открытые и классные франчайзи Внутри базы знаний для всех доступны контакты любого франчайзи «Додо Пиццы». За прошедшие месяцы мы успели пообщаться с несколькими франчайзи Санкт-Петербурга и области: и все они оказались чрезвычайно открытыми и приятными людьми. Все с удовольствие делятся опытом.
Почему отделение длилось так долго? По пути было множество проблем, которые замедляли: Нам хотелось перевести данные о пользователях, устройствах и аутентификации из баз по стране в одну. Для этого пришлось переводить все таблицы и использование с идентификатора int на глобальный идентификатор UUId недавно перерабатывали этот код Роман Букин «Uuid — большая история маленькой структуры» и open-source проект Primitives. Хранение данных по пользователям так как это персональная информация имеет свои ограничения и для некоторых стран надо хранить их отдельно. Но глобальный идентификатор пользователя должен быть. Много таблиц в базе имеет аудит информацию о том пользователе, который совершил операцию. Это потребовало дополнительного механизма, чтобы была консистентность. После создания api-сервисов был долгий и постепенный период перевода на другую систему. Переключения должны были происходить бесшовно для пользователей и требовали ручной работы. Схема регистрации устройства в пиццерии: Общая архитектура после выделения Auth и Devices-сервиса: Чем занимается Трекер Теперь про второй из нагруженных сервисов. Трекер выполняет двойственную роль: С одной стороны, его задача — показывать сотрудникам на кухне, какие заказы сейчас в работе, какие продукты сейчас нужно готовить. С другой стороны — оцифровывать все процессы на кухне. Когда в заказе появляется новый продукт например, пицца , он попадает на станцию трекера «Раскатка». На этой станции стоит пиццамейкер, который берёт плюшку нужного размера и раскатывает её, после чего отмечает на планшете трекера, что выполнил свою задачу и передаёт раскатанную основу теста на следующую станцию — «Начинение». Там следующий пиццамейкер начинает пиццу, затем отмечает на планшете, что выполнил свою задачу и ставит пиццу в печь это тоже отдельная станция, которую нужно отметить на планшете. Такая система была с самого начала в Додо и самого начала существования Dodo IS. Она позволяет полностью отслеживать и оцифровывать все операции. Кроме того трекер подсказывает, как готовить тот или иной продукт, проводит каждый вид продукта по своим схемам изготовления, хранит оптимальное время приготовления продукта и трекает все операции над продуктом. Так выглядит экран планшета на станции трекера «Раскатка» Откуда нагрузки? В каждой из пиццерий примерно по пять планшетов с трекером. В 2016 году у нас было больше 100 пиццерий а сейчас более 600. Каждый из планшетов делает раз в 10 секунд запрос на бэкэнд и выгребает данные из таблицы заказа связка с клиентом и адресом , состава заказа связка с продуктом и указание количества , таблицы учёта мотивации в ней трекается время нажатия. Когда пиццамейкер нажимает на продукт на трекере, происходит обновление записей во всех этих таблицах. Таблица заказа общая, в неё же одновременно идут вставки при принятии заказа, обновления от других частей системы и многочисленные считывания, например, на телевизоре, который висит в пиццерии и показывает готовые заказы клиентам. В период борьбы с нагрузками, когда всё и вся кэшировалось и переводилось на асинхронную реплику базы, эти операции с трекером продолжили ходить в мастер-базу. Тут не должно быть никакого отставания, данные должны быть актуальными, рассинхрон недопустим. Также отсутствие собственных таблиц и индексов на них не позволяло написать более специфичные запросы, заточенные под своё использование. Для примера, трекеру может быть эффективно иметь индекс на пиццерию на таблице заказов. Мы всегда выгребаем из базы трекера заказы по пиццерии. При этом для приёма заказа не так важно, в какую пиццерию он падает, важнее, какой клиент сделал этот заказ. А значит там нужен индекс по клиенту. Ещё для трекера в таблице заказа не обязательно хранить id напечатанного чека или связанные с заказом бонусные акции. Эта информация наш сервис трекера не интересует. В общей монолитной базе таблицы могли быть только компромиссным вариантом между всеми пользователями. Это было одной из изначальных проблем. Изначально архитектура была такая: Даже после выделения в отдельные процессы большая часть кодовой базы оставалась общей для разных сервисов. Всё, что ниже контроллеров, было единым и жило в одном репозитории.
Франшиза «Додо пицца»
Search code, repositories, users, issues, pull requests... | База знаний Додо. В Базе хранится вся наша история! Мы выкладываем туда свежие новости компании, обсуждаем актуальные тренды, храним все стандарты, обучающие статьи и курсы. |
Франшиза «Додо Пиццы»: сильный продукт, передовые технологии и честные условия | Александр Андронов — CEO Dodo EngineeringDodo Engineering — часть Dodo Brands, развивает собственную цифровую платформу Додо ИС для управления ресторанным. |
Автоматизируем бизнес по-крупному: создаём свой «цифровой мозг» | Главная» Новости» Додо новости. |
Как открыть пиццерию по франшизе
Кроме того, клиенты получают ответы быстрее, следовательно, у них повышается лояльность к компании. Для создания бота были использованы следующие технологии: Платформа для разработки чат-ботов zDialog; ИИ-сервис аналитики чат-ботов OneDash; Технология распознавания и синтеза речи Yandex SpeechKit.
Detailed production monitoring with Prometheus, visualization with Grafana, and log collection by Azure Data Explorer. Technology radars.
Ранее клиент мог связаться с оператором контакт-центра только двумя способами — позвонить на горячую линию либо отправить письмо на электронную почту. Оба варианта коммуникации имели свои недостатки: клиентам не всегда удобно звонить, некоторые просто не любят, а ответ по электронной почте, как правило, не всегда достаточно оперативен. Опыт и анализ отзывов показали, что для федеральной сети пиццерий двух каналов связи не хватает.
ДДмитрий Пильщиков На 9 из 10. На основании их отчетов составляется рейтинг пиццерий. Лучшим пиццериям достаются бонусы. О каких бонусах идет речь? ААндрей Елькин Бонусов нет. ААндрей Елькин Не знаю о таких бонусах, мы первыми не становились. А тайные покупатели, действительно, приходят 8 раз в месяц. ДДмитрий Пильщиков Бонусов нет никаких, только моральное удовлетворение, что твоя пиццерия в топе по качеству. Франчайзер заявляет, что срок окупаемости франшизы 3 года. Это реальный показатель?
Ваша франшиза окупится за этот период? ААндрей Елькин Да, реальный. Плюс-минус 3 года. ААндрей Елькин Первые франшизы окупились, остальные в процессе. Все зависит от города и локации. Но три года - это, скорее, максимальный показатель, хотя есть партнеры, у которых ситуация не очень хорошая, они дольше окупались. А есть те, кто очень быстро смогли выйти на окупаемость, например, за 1,5 года. У нас в среднем показатель окупаемости плюс-минус 2,5 года. ДДмитрий Пильщиков Да, именно наши окупились быстрее 2-х лет. Потому что не было инвестора.
Согласуются ли финансовые результаты с заявленными франчайзером? Заявлено на сайте франчайзера: доход в месяц от 250 000 рублей ААндрей Елькин Да. ААндрей Елькин Да. Но надо понимать, что на такой доход ты выходишь не с первого месяца, а приблизительно через полгода. ДДмитрий Пильщиков Да. Но, опять же, у каждого индивидуальные показатели. Додо Пицца публикует рейтинг продаж. Отслеживаете ли вы данный показатель? С каким годовым процентом вы завершите год? ААндрей Елькин Продажи растут каждый год.
Но в этом году в зале продажи упали. Но это компенсировалось повышенным приростом продаж на доставку.
База знаний додо
На рассмотрении Разбивка по NPS базы клиентов по пиццериям для более детальной работы по клиентской базе. Додо Пицца ИС личный кабинет и профиль сотрудника — информационная система, которая позволяет инвестору контролировать бизнес. Специалисты Додо Пиццы написали статью про базу знаний и запустили курс по созданию интерактивных элементов.
Франшиза «Додо пицца»
Стандарты Додо пицца. База знаний додо. Личный кабинет сотрудника. Додо is личный кабинет. Палочки с креветками Додо. Додо ис смены. «Додо ИС» — это «Скайнет» среди систем управления предприятием. Страница предлагает авторизоваться или зарегистрироваться на сайте.
Автоматизация контактного центра «Додо Пиццы»
Менеджер открывает смену и контролирует работу сотрудников. В конце каждой смены менеджер сверяет денежные средства, полученные от курьера, с количеством сделанных за день заказов, используя его рабочий мобильный планшет. Также при закрытии смены сверку денежных средств производит кассир. Если при сведении кассы возникнут расхождения, система соберет информацию о возврате продуктов и ненапечатанных чеках.
Таким образом автоматизированная система управления решает сложные вопросы в считаные минуты. Построение рабочего графика После того как каждый работник пиццерии отметил нерабочие дни в своем ЛК, менеджер смены, используя информацию из «Сводной карты возможностей», составляет график работ, применяя автоматизированную систему Dodo IS. График составляется как на 1 день, так и на неделю с учетом выборки работников системой, благодаря которой сотрудники «Додо» имеют полное представление о своем рабочем расписании.
Общая база контактов В «Личном кабинете» работника пиццерии есть справочник контактов всех сотрудников ресторана. Он нужен для того, чтобы в случае необходимости обратиться к управляющему или в кратчайшие сроки найти замену. Общая база контактов содержит сведения о следующих работниках: руководителях предприятия; В общей базе есть справочник контактов всех сотрудников ресторана.
По словам финансового директора компании «Додо пицца» Дмитрия Соловьева, в "сердце" сети организации - облачная система управления пиццерией «Додо ИС». Соловьев подчеркивает, что это ЕРП-система, которая охватывает все аспекты Додо-бизнеса: заказы клиентов, мобильное приложение и сайт, процессы приготовления пиццы в пиццерии, работу кассы и прием платежей, всю операционную работу пиццерии и многое другое. Поэтому крайне важно защитить ее от сбоев и киберрисков, подытожил финансовый директор.
Сервис авторизации и аутентификации для бэкофиса. Трекер заказов на кухне. Сервис отметки статусов готовности при приготовлении заказа.
Касса Ресторана. Приём заказов в ресторане, интерфейсы кассира. Выгрузка отчётов в 1C для бухгалтерии. Оповещения и накладные. Менеджер Смены. Интерфейсы для работы менеджера смены: список заказов, графики производительности, вывод на смену сотрудников.
Менеджер Офиса. Интерфейсы для работы франчайзи и управляющего: приём сотрудников, отчёты по работе пиццерии. Табло Ресторана. Отображение меню на телевизорах в пиццериях. Настройки в конкретной пиццерии: меню, цены, учёт, промокоды, акции, баннеры для сайта и т. Личный Кабинет Сотрудника.
Графики работы сотрудников, информация о сотрудниках. Табло Мотивации Кухни. Отдельный экран, который висит на кухне и отображает скорость работы пиццамейкеров. Отправка sms и email. Собственный сервис для приёма и выдачи статических файлов. Первые попытки решить проблемы помогли нам, но стали лишь временной передышкой.
Они не стали системными решениями, поэтому было ясно, что с базами надо что-то сделать. Например, разделить общую базу на несколько более специализированных. Начинаем разгружать монолит: отделение Auth и Трекера Основные сервисы, которые тогда больше других записывали и считывали из базы: Auth. Чем занимается Auth Auth — это сервис, через который пользователи логинятся в бэкофис на клиентской части отдельный независимый вход. Также к нему обращаются в запросе, чтобы удостовериться, что есть нужные права на доступ, и что эти права не изменились с последнего входа. Через него же происходит вход устройств в пиццерии.
Например, нам хочется открыть на телевизоре, висящем в зале, табло со статусами готовых заказов. Тогда мы открываем auth. Телевизор сам перейдёт на нужный интерфейс своей пиццерии и начнёт отображать там имена клиентов, заказы которых готовы. Откуда нагрузки? Каждый залогиненный пользователь бэкофиса на каждый запрос ходит в базу, в таблицу пользователей, через sql-запрос вытаскивает оттуда пользователя и проверяет, есть ли у него нужные доступы и права на эту страницу. Каждое из устройств делает то же самое только с таблицей устройств, проверяя свою роль и свои доступы.
Большое количество запросов в мастер-базу приводит к её загрузке и трате ресурсов общей базы на эти операции. Разгружаем Auth У Auth изолированный домен, то есть данные о пользователях, логинах или устройствах поступают в сервис пока будущий и там остаются. Если они кому-то понадобятся, то он пойдёт в этот сервис за данными. Схема работы изначально была такой: Хочется немного пояснить, как это работало: Запрос извне приходит на бэкэнд там Asp.
Схема работы изначально была такой: Хочется немного пояснить, как это работало: Запрос извне приходит на бэкэнд там Asp. Net MVC , приносит с собой куку сессии, которая используется для получения сессионных данных из Redis 1. В ней либо есть информация о доступах, и тогда доступ в контроллер открыт 3,4 , либо нет. Если доступа нет, нужно пройти процедуру авторизации. Здесь для упрощения она показана как часть пути в том же атрибуте, хотя это переход на страницу логина. В случае позитивного сценария мы получим правильно заполненную сессию и перейдём в Backoffice Controller. Если данные есть, то нужно проверить их на актуальность в базе пользователя. Не изменилась ли его роль, не надо ли его не пускать теперь на страницу. В этом случае после получения сессии 1 надо напрямую сходить в базу и проверить доступы пользователя с помощью слоя логики аутентификации 2. Далее либо на логин-страницу, либо переход в контроллер. Такая вот простая система, но при этом не совсем стандартная. Если все процедуры пройдены, то пропускаем дальше в логике в контроллерах и методах. Данные пользователей отделены от всех других данных, они хранятся в отдельной таблице membership, функции из слоя логики AuthService вполне могут стать api-методами. Границы домена определены вполне чётко: пользователи, их роли, данные о доступах, выдача и отзыв доступов. Всё выглядит так, что можно вынести в отдельный сервис. Так и сделали: У такого подхода есть ряд проблем. Например, вызов метода внутри процесса — не то же самое, что вызов по http внешнего сервиса. Латенси, надёжность, поддерживаемость, прозрачность операции совершенно другие. Подробнее именно о таких проблемах рассказывал Андрей Моревский в своем докладе «50 оттенков микросервисов». Сервис аутентификации и с ним сервис устройств используются для бэкофиса, то есть для сервисов и интерфейсов, используемых на производстве. Аутентификация для клиентских сервисов вроде сайта или мобильного приложения происходит отдельно без использования Auth. Отделение заняло около года, а сейчас мы опять занимаемся этой темой, переводя систему уже на новые сервисы аутентификации со стандартными протоколами. Почему отделение длилось так долго? По пути было множество проблем, которые замедляли: Нам хотелось перевести данные о пользователях, устройствах и аутентификации из баз по стране в одну. Для этого пришлось переводить все таблицы и использование с идентификатора int на глобальный идентификатор UUId недавно перерабатывали этот код Роман Букин «Uuid — большая история маленькой структуры» и open-source проект Primitives. Хранение данных по пользователям так как это персональная информация имеет свои ограничения и для некоторых стран надо хранить их отдельно. Но глобальный идентификатор пользователя должен быть. Много таблиц в базе имеет аудит информацию о том пользователе, который совершил операцию. Это потребовало дополнительного механизма, чтобы была консистентность. После создания api-сервисов был долгий и постепенный период перевода на другую систему. Переключения должны были происходить бесшовно для пользователей и требовали ручной работы. Схема регистрации устройства в пиццерии: Общая архитектура после выделения Auth и Devices-сервиса: Чем занимается Трекер Теперь про второй из нагруженных сервисов. Трекер выполняет двойственную роль: С одной стороны, его задача — показывать сотрудникам на кухне, какие заказы сейчас в работе, какие продукты сейчас нужно готовить. С другой стороны — оцифровывать все процессы на кухне. Когда в заказе появляется новый продукт например, пицца , он попадает на станцию трекера «Раскатка». На этой станции стоит пиццамейкер, который берёт плюшку нужного размера и раскатывает её, после чего отмечает на планшете трекера, что выполнил свою задачу и передаёт раскатанную основу теста на следующую станцию — «Начинение». Там следующий пиццамейкер начинает пиццу, затем отмечает на планшете, что выполнил свою задачу и ставит пиццу в печь это тоже отдельная станция, которую нужно отметить на планшете.