Додо пицца история бизнеса: История успеха «Додо Пицца» Федора Овчинникова

История архитектуры Dodo IS: ранний монолит / Хабр

Или каждая несчастная компания с монолитом несчастлива по-своему.

Разработка системы Dodo IS началась сразу же, как и бизнес Додо Пиццы — в 2011 году. В основе лежала идея полной и тотальной оцифровки бизнес-процессов, причем своими силами, что еще тогда в 2011 году вызывало много вопросов и скептицизма. Но вот уже 9 лет мы идем по такому пути — с собственной разработкой, которая начиналась с монолита.

Эта статья — «ответ» на вопросы «Зачем переписывать архитектуру и делать такие масштабные и долгие изменения?» к предыдущей статье «История архитектуры Dodo IS: путь бэкофиса». Начну с того как начиналась разработка Dodo IS, как выглядела изначальная архитектура, как появлялись новые модули, и из-за каких проблем пришлось проводить масштабные изменения.

Серия статей «Что такое Dodo IS?» расскажет про:

1. Ранний монолит в Dodo IS (2011-2015 годы). (You are here)

2. Путь бэкофиса: раздельные базы и шина.

3. Путь клиентской части: фасад над базой (2016-2017 годы). (In progress…)

4. История настоящих микросервисов. (2018-2019 годы). (In progress…)

5. Законченный распил монолита и стабилизация архитектуры. (In progress…)

Изначальная архитектура

В 2011 году архитектура Dodo IS выглядела так:

Первый модуль в архитектуре — прием заказа. Бизнес-процесс был такой:

• клиент звонит в пиццерию;

• трубку берет менеджер;

• принимает по телефону заказ;

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

Интерфейс информационной системы выглядел примерно так…

Первая версия от октября 2011:

Чуть улучшенная в январе 2012

Информационная система Додо Пицца Delivery Pizza Restaurant

Ресурсы для разработки первого модуля приема заказа были ограничены. Нужно было делать много, быстро и малым составом. Малый состав — это 2 разработчика, которые и заложили фундамент всей будущей системы.

Их первое решение определило дальнейшую судьбу технологического стека:

• Backend на ASP.NET MVC, язык C#. Разработчики были дотнетчиками, этот стек был им знаком и приятен.

• Фронтенд на Bootstrap и JQuery: интерфейсы пользователя на самописных стилях и скриптах. 

• База данных MySQL: без затрат на лицензии, простая в использовании.

• Серверы на Windows Server, потому что .NET тогда мог быть только под Windows (Mono обсуждать не будем).

Физически это все выражалось в «дедике у хостера». 

Архитектура приложения приема заказа

Тогда уже все говорили о микросервисах, а SOA лет 5 использовалось в крупных проектах, например, WCF вышел в 2006 году. Но тогда выбрали надежное и проверенное решение.

Вот оно.

Asp.Net MVC — это Razor, который выдаёт по запросу с формы или от клиента HTML-страницу с рендерингом на сервере. На клиенте уже CSS и JS-скрипты отображают информацию и, по необходимости, выполняют AJAX-запросы через JQuery.

Запросы на сервере попадают в классы *Controller, где в методе происходит обработка и генерация итоговой HTML-страницы. Контроллеры делают запросы на слой логики, называемый *Services. Каждый из сервисов отвечал какому-то аспекту бизнеса:

• Например, DepartmentStructureService выдавал информацию по пиццериям, по департаментам. Департамент — это группа пиццерий под управлением одного франчайзи.

• ReceivingOrdersService принимал и рассчитывал состав заказа.

• А SmsService отправлял смс, вызывая API-сервисы по отправке смс.

Сервисы обрабатывали данные из базы, хранили бизнес-логику. В каждом сервисе был один или несколько *Repository с соответствующим названием. В них уже находились запросы к хранимым процедурам в базе и слой мапперов. В хранимках была бизнес-логика, особенно много в тех, которые выдавали отчетные данные. ОРМ не использовался, все полагались на написанный руками sql. 

Еще был слой доменной модели и общих классов-хелперов, например, класс Order, хранивший заказ. Там же, в слое, находился хелпер для преобразования текста отображения по выбранной валюте.

Всё это можно представить такой моделью:

Путь заказа

Рассмотрим упрощенный первоначальный путь создания такого заказа.

Изначально сайт был статический. На нем были цены, а сверху — номер телефона и надпись «Хочешь пиццу — звони по номеру и закажи». Для заказа нам нужно реализовать простой flow: 

• Клиент заходит на статический сайт с ценами, выбирает продукты и звонит по номеру, который указан на сайте.

• Клиент называет продукты, которые хочет добавить в заказ.

• Называет свой адрес и имя.

• Оператор принимает заказ.

• Заказ отображается в интерфейсе принятых заказов.

Все начинается с отображения меню. Залогиненный пользователь-оператор в один момент времени принимает лишь один заказ. Поэтому draft-корзина может храниться в его сессии (сеанс пользователя хранится в памяти). Там объект Cart, в котором продукты и информация о клиенте.

Клиент называет продукт, оператор нажимает на + рядом с продуктом, и на сервер отправляется запрос. По продукту вытаскивается информация из базы и добавляется информация о продукте в корзину.

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

Далее вводим адрес и имя клиента. 

При нажатии «Создать заказ»:

• Запрос отправляем в OrderController.SaveOrder().

• Получаем Cart из сессии, там лежат продукты в нужном нам количестве.

• Дополняем Cart информацией о клиенте и передаем в метод AddOrder класса ReceivingOrderService, где он сохраняется в базу. 

• В базе есть таблицы с заказом, составом заказа, клиентом и они все связаны.

• Интерфейс отображения заказа идет и вытаскивает последние заказы и отражает их.

Новые модули

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

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

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

Технически модули оформлялись как Area (вот такая идея даже осталась в asp.net core). Там были отдельные файлы для фронтенда, моделей, а также свои классы контроллеров. В итоге система преобразовалась из такой. ..

…в такую:

Некоторые модули реализованы отдельными сайтами(executable project), по причине совсем уже отдельного функционала и частично из-за несколько отдельной, более сфокусированной разработки. Это:

• Site — первая версия сайта dodopizza.ru.

• Export: выгрузка отчетов из Dodo IS для 1C. 

• Personal — личный кабинет сотрудника. Отдельно разрабатывался и имеет свою точку входа и отдельный дизайн.

• fs — проект для хостинга статики. Позже мы ушли от него, переведя всю статику на CDN Akamai. 

Остальные же блоки находились в приложении BackOffice. 

Пояснение по названиям:

• Cashier — Касса ресторана.

• ShiftManager — интерфейсы для роли «Менеджер смены»: оперативная статистика по продажам пиццерии, возможность поставить в стоп-лист продукты, изменить заказ.

• OfficeManager — интерфейсы для роли «Управляющий пиццерии» и «Франчайзи». Здесь собраны функции по настройке пиццерии, её бонусных акций, прием и работа с сотрудниками, отчеты.

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

Они использовали общий слой сервисов, общий блок доменных классов Dodo.Core, а также общую базу. Иногда еще могли вести по переходам друг к другу. В том числе к общим сервисам ходили и отдельные сайты, вроде dodopizza.ru или personal.dodopizza.ru.

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

Для лучшего понимания масштаба модулей, сделанных в системе, вот схема из 2012 года с планами развития:

К 2015 году всё на схеме и даже больше было в продакшн.

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

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

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

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

Параллельно с 2012 по 2015 появилось более 10 разработчиков, открылось 35 пиццерий, развернули систему на Румынию и подготовили к открытию точек в США. Разработчики уже не занимались всеми задачами, а были разделены на команды. каждая специализировалась на своей части системы. 

Проблемы

В том числе из-за архитектуры (но не только).

Хаос в базе

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

Но за 4 года разработки в базе оказалось около 600 таблиц, 1500 хранимых процедур, во многих из которых была еще и логика. Увы, хранимые процедуры не приносят особого преимущества при работе с MySQL. Они не кэшируются базой, а хранение в них логики усложняет разработку и отладку. Переиспользование кода тоже затруднено.

На многих таблицах не было подходящих индексов, где-то, наоборот, было очень много индексов, что затрудняло вставку. Надо было модифицировать около 20 таблиц — транзакция на создание заказа могла выполняться около 3-5 секунд. 

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

К одним и тем же таблицам производились очень разнородные запросы. Особенно страдали популярные таблицы, вроде упоминавшейся таблицы orders или таблицы pizzeria. Они использовались для вывода оперативных интерфейсов на кухне, аналитики. Еще к ним обращался сайт(dodopizza.ru), куда в любой момент времени могло придти внезапно много запросов. 

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

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

Связность и запутанность в коде

Модули, которые должны были отвечать за свой участок бизнеса, не делали этого честно. Некоторые из них имели дублирование по функциям для ролей. Например, локальному маркетологу, который отвечает за маркетинговую активность сети в своем городе, приходилось пользоваться как интерфейсом «Админа» (для заведения акций), так и интерфейсом «Менеджера Офиса» (для просмотра влияния акций на бизнес). Конечно, внутри оба модуля использовали один сервис, который работал с с бонусными акциями.

Сервисы (классы в рамках одного монолитного большого проекта) могли вызывать друг друга для обогащения своих данных.

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

Логика была либо в контроллерах, либо в классах сервисов. 

Это вроде незначительные проблемы, но они сильно замедляли разработку и снижали качество, что приводило к нестабильности и ошибкам. 

Сложность большой разработки

Трудности возникли и в самой разработке. Нужно было делать разные блоки системы, причем параллельно. Вместить нужды каждого компонента в единый код становилось все труднее. Было не просто договориться и угодить всем компонентам одновременно. К этому добавлялись ограничения в технологиях, особенно касаемо базы и фронтэнда. Нужно было отказываться от JQuery в сторону высокоуровневых фреймворков, особенно в части клиентских сервисов (сайт).

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

Команды и разработчики, занимающиеся своей областью явно хотели большей самостоятельности для своих сервисов, как в части разработки, так и в части выкатки. Конфликты при мерже, проблемы при релизах. Если для 5 разработчиков эта проблема несущественна, то при 10, а уж тем более  при планируемом росте, все стало бы серьёзнее. А а впереди должна была быть разработка мобильного приложения (она стартанула в 2017, а в 2018 было большое падение). 

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

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

Как блог Сила ума положил кассы в ресторанах

Если рост сети пиццерий (и нагрузки) продолжался бы в том же темпе, то через некоторое время падения были бы уже такими, что система и не поднимется. Хорошо иллюстрирует проблемы, с которыми мы начали сталкиваться к 2015 году вот такая история. 

В блоге «Сила ума» был виджет, который показывал данные по выручке за год всей сети. Виджет обращался к публичному API Dodo, которое предоставляет эти данные. Сейчас эта статистика доступна на http://dodopizzastory.com/. Виджет показывался на каждой странице и делал запросы по таймеру каждые 20 секунд. Запрос уходил в api.dodopizza.ru и запрашивал:

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

В эту же таблицу заказов ходили Кассы в ресторанах, выгружали список принятых за сегодня заказов, в неё же добавлялись новые заказы. Кассы делали свои запросы каждые 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 для запросов на отчеты. У этой базы доступность была ниже, но в неё ходили все отчеты. Пусть у них тяжелые запросы на огромные пересчеты данных, но зато они не влияют на основную базу и операционные интерфейсы. 

Кэши в коде

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

Несколько серверов для бэкэнда

Бэкэнд приложения тоже надо было масштабировать, чтобы выдерживать повышенные нагрузки. Необходимо было сделать из одного iis-сервера кластер. Мы перенесли сессию приложений из памяти на RedisCache, что позволило сделать несколько серверов, стоящих за простым балансировщиком нагрузки с round robin. Сначала использовался тот же Redis, что и для кэшей, потом разнесли на несколько. 

В итоге архитектура усложнилась…

…но часть напряженности удалось снять.

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

История архитектуры Dodo IS: ранний монолит

Или каждая несчастная компания с монолитом несчастлива по-своему.

Разработка системы Dodo IS началась сразу же, как и бизнес Додо Пиццы — в 2011 году. В основе лежала идея полной и тотальной оцифровки бизнес-процессов, причем своими силами, что еще тогда в 2011 году вызывало много вопросов и скептицизма. Но вот уже 9 лет мы идем по такому пути — с собственной разработкой, которая начиналась с монолита.

Эта статья — «ответ» на вопросы «Зачем переписывать архитектуру и делать такие масштабные и долгие изменения?» к предыдущей статье «История архитектуры Dodo IS: путь бэкофиса». Начну с того как начиналась разработка Dodo IS, как выглядела изначальная архитектура, как появлялись новые модули, и из-за каких проблем пришлось проводить масштабные изменения.

Серия статей «Что такое Dodo IS?» расскажет про:

1. Ранний монолит в Dodo IS (2011-2015 годы). (You are here)

2. Путь бэкофиса: раздельные базы и шина.

3. Путь клиентской части: фасад над базой (2016-2017 годы). (In progress…)

4. История настоящих микросервисов. (2018-2019 годы). (In progress…)

5. Законченный распил монолита и стабилизация архитектуры. (In progress…)

Изначальная архитектура

В 2011 году архитектура Dodo IS выглядела так:

Первый модуль в архитектуре — прием заказа. Бизнес-процесс был такой:

• клиент звонит в пиццерию;

• трубку берет менеджер;

• принимает по телефону заказ;

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

Интерфейс информационной системы выглядел примерно так…

Первая версия от октября 2011:

Чуть улучшенная в январе 2012

Информационная система Додо Пицца Delivery Pizza Restaurant

Ресурсы для разработки первого модуля приема заказа были ограничены. Нужно было делать много, быстро и малым составом. Малый состав — это 2 разработчика, которые и заложили фундамент всей будущей системы.

Их первое решение определило дальнейшую судьбу технологического стека:

• Backend на ASP.NET MVC, язык C#. Разработчики были дотнетчиками, этот стек был им знаком и приятен.

• Фронтенд на Bootstrap и JQuery: интерфейсы пользователя на самописных стилях и скриптах. 

• База данных MySQL: без затрат на лицензии, простая в использовании.

• Серверы на Windows Server, потому что .NET тогда мог быть только под Windows (Mono обсуждать не будем).

Физически это все выражалось в «дедике у хостера». 

Архитектура приложения приема заказа

Тогда уже все говорили о микросервисах, а SOA лет 5 использовалось в крупных проектах, например, WCF вышел в 2006 году. Но тогда выбрали надежное и проверенное решение.

Вот оно.

Asp.Net MVC — это Razor, который выдаёт по запросу с формы или от клиента HTML-страницу с рендерингом на сервере. На клиенте уже CSS и JS-скрипты отображают информацию и, по необходимости, выполняют AJAX-запросы через JQuery.

Запросы на сервере попадают в классы *Controller, где в методе происходит обработка и генерация итоговой HTML-страницы. Контроллеры делают запросы на слой логики, называемый *Services. Каждый из сервисов отвечал какому-то аспекту бизнеса:

• Например, DepartmentStructureService выдавал информацию по пиццериям, по департаментам. Департамент — это группа пиццерий под управлением одного франчайзи.

• ReceivingOrdersService принимал и рассчитывал состав заказа.

• А SmsService отправлял смс, вызывая API-сервисы по отправке смс.

Сервисы обрабатывали данные из базы, хранили бизнес-логику. В каждом сервисе был один или несколько *Repository с соответствующим названием. В них уже находились запросы к хранимым процедурам в базе и слой мапперов. В хранимках была бизнес-логика, особенно много в тех, которые выдавали отчетные данные. ОРМ не использовался, все полагались на написанный руками sql. 

Еще был слой доменной модели и общих классов-хелперов, например, класс Order, хранивший заказ. Там же, в слое, находился хелпер для преобразования текста отображения по выбранной валюте.

Всё это можно представить такой моделью:

Путь заказа

Рассмотрим упрощенный первоначальный путь создания такого заказа.

Изначально сайт был статический. На нем были цены, а сверху — номер телефона и надпись «Хочешь пиццу — звони по номеру и закажи». Для заказа нам нужно реализовать простой flow: 

• Клиент заходит на статический сайт с ценами, выбирает продукты и звонит по номеру, который указан на сайте.

• Клиент называет продукты, которые хочет добавить в заказ.

• Называет свой адрес и имя.

• Оператор принимает заказ.

• Заказ отображается в интерфейсе принятых заказов.

Все начинается с отображения меню. Залогиненный пользователь-оператор в один момент времени принимает лишь один заказ. Поэтому draft-корзина может храниться в его сессии (сеанс пользователя хранится в памяти). Там объект Cart, в котором продукты и информация о клиенте.

Клиент называет продукт, оператор нажимает на + рядом с продуктом, и на сервер отправляется запрос. По продукту вытаскивается информация из базы и добавляется информация о продукте в корзину.

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

Далее вводим адрес и имя клиента. 

При нажатии «Создать заказ»:

• Запрос отправляем в OrderController.SaveOrder().

• Получаем Cart из сессии, там лежат продукты в нужном нам количестве.

• Дополняем Cart информацией о клиенте и передаем в метод AddOrder класса ReceivingOrderService, где он сохраняется в базу. 

• В базе есть таблицы с заказом, составом заказа, клиентом и они все связаны.

• Интерфейс отображения заказа идет и вытаскивает последние заказы и отражает их.

Новые модули

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

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

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

Технически модули оформлялись как Area (вот такая идея даже осталась в asp.net core). Там были отдельные файлы для фронтенда, моделей, а также свои классы контроллеров. В итоге система преобразовалась из такой. ..

…в такую:

Некоторые модули реализованы отдельными сайтами(executable project), по причине совсем уже отдельного функционала и частично из-за несколько отдельной, более сфокусированной разработки. Это:

• Site — первая версия сайта dodopizza.ru.

• Export: выгрузка отчетов из Dodo IS для 1C. 

• Personal — личный кабинет сотрудника. Отдельно разрабатывался и имеет свою точку входа и отдельный дизайн.

• fs — проект для хостинга статики. Позже мы ушли от него, переведя всю статику на CDN Akamai. 

Остальные же блоки находились в приложении BackOffice. 

Пояснение по названиям:

• Cashier — Касса ресторана.

• ShiftManager — интерфейсы для роли «Менеджер смены»: оперативная статистика по продажам пиццерии, возможность поставить в стоп-лист продукты, изменить заказ.

• OfficeManager — интерфейсы для роли «Управляющий пиццерии» и «Франчайзи». Здесь собраны функции по настройке пиццерии, её бонусных акций, прием и работа с сотрудниками, отчеты.

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

Они использовали общий слой сервисов, общий блок доменных классов Dodo.Core, а также общую базу. Иногда еще могли вести по переходам друг к другу. В том числе к общим сервисам ходили и отдельные сайты, вроде dodopizza.ru или personal.dodopizza.ru.

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

Для лучшего понимания масштаба модулей, сделанных в системе, вот схема из 2012 года с планами развития:

К 2015 году всё на схеме и даже больше было в продакшн.

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

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

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

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

Параллельно с 2012 по 2015 появилось более 10 разработчиков, открылось 35 пиццерий, развернули систему на Румынию и подготовили к открытию точек в США. Разработчики уже не занимались всеми задачами, а были разделены на команды. каждая специализировалась на своей части системы. 

Проблемы

В том числе из-за архитектуры (но не только).

Хаос в базе

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

Но за 4 года разработки в базе оказалось около 600 таблиц, 1500 хранимых процедур, во многих из которых была еще и логика. Увы, хранимые процедуры не приносят особого преимущества при работе с MySQL. Они не кэшируются базой, а хранение в них логики усложняет разработку и отладку. Переиспользование кода тоже затруднено.

На многих таблицах не было подходящих индексов, где-то, наоборот, было очень много индексов, что затрудняло вставку. Надо было модифицировать около 20 таблиц — транзакция на создание заказа могла выполняться около 3-5 секунд. 

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

К одним и тем же таблицам производились очень разнородные запросы. Особенно страдали популярные таблицы, вроде упоминавшейся таблицы orders или таблицы pizzeria. Они использовались для вывода оперативных интерфейсов на кухне, аналитики. Еще к ним обращался сайт(dodopizza.ru), куда в любой момент времени могло придти внезапно много запросов. 

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

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

Связность и запутанность в коде

Модули, которые должны были отвечать за свой участок бизнеса, не делали этого честно. Некоторые из них имели дублирование по функциям для ролей. Например, локальному маркетологу, который отвечает за маркетинговую активность сети в своем городе, приходилось пользоваться как интерфейсом «Админа» (для заведения акций), так и интерфейсом «Менеджера Офиса» (для просмотра влияния акций на бизнес). Конечно, внутри оба модуля использовали один сервис, который работал с с бонусными акциями.

Сервисы (классы в рамках одного монолитного большого проекта) могли вызывать друг друга для обогащения своих данных.

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

Логика была либо в контроллерах, либо в классах сервисов. 

Это вроде незначительные проблемы, но они сильно замедляли разработку и снижали качество, что приводило к нестабильности и ошибкам. 

Сложность большой разработки

Трудности возникли и в самой разработке. Нужно было делать разные блоки системы, причем параллельно. Вместить нужды каждого компонента в единый код становилось все труднее. Было не просто договориться и угодить всем компонентам одновременно. К этому добавлялись ограничения в технологиях, особенно касаемо базы и фронтэнда. Нужно было отказываться от JQuery в сторону высокоуровневых фреймворков, особенно в части клиентских сервисов (сайт).

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

Команды и разработчики, занимающиеся своей областью явно хотели большей самостоятельности для своих сервисов, как в части разработки, так и в части выкатки. Конфликты при мерже, проблемы при релизах. Если для 5 разработчиков эта проблема несущественна, то при 10, а уж тем более  при планируемом росте, все стало бы серьёзнее. А а впереди должна была быть разработка мобильного приложения (она стартанула в 2017, а в 2018 было большое падение). 

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

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

Как блог Сила ума положил кассы в ресторанах

Если рост сети пиццерий (и нагрузки) продолжался бы в том же темпе, то через некоторое время падения были бы уже такими, что система и не поднимется. Хорошо иллюстрирует проблемы, с которыми мы начали сталкиваться к 2015 году вот такая история. 

В блоге «Сила ума» был виджет, который показывал данные по выручке за год всей сети. Виджет обращался к публичному API Dodo, которое предоставляет эти данные. Сейчас эта статистика доступна на http://dodopizzastory.com/. Виджет показывался на каждой странице и делал запросы по таймеру каждые 20 секунд. Запрос уходил в api.dodopizza.ru и запрашивал:

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

В эту же таблицу заказов ходили Кассы в ресторанах, выгружали список принятых за сегодня заказов, в неё же добавлялись новые заказы. Кассы делали свои запросы каждые 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 для запросов на отчеты. У этой базы доступность была ниже, но в неё ходили все отчеты. Пусть у них тяжелые запросы на огромные пересчеты данных, но зато они не влияют на основную базу и операционные интерфейсы. 

Кэши в коде

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

Несколько серверов для бэкэнда

Бэкэнд приложения тоже надо было масштабировать, чтобы выдерживать повышенные нагрузки. Необходимо было сделать из одного iis-сервера кластер. Мы перенесли сессию приложений из памяти на RedisCache, что позволило сделать несколько серверов, стоящих за простым балансировщиком нагрузки с round robin. Сначала использовался тот же Redis, что и для кэшей, потом разнесли на несколько. 

В итоге архитектура усложнилась…

…но часть напряженности удалось снять.

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

Додо пицца — еще одна история успеха — Фонд поддержки предпринимательства Каменск-Уральского городского округа

Победителем в номинации «Общественное питание» в Конкурсе «Каменск выбирает» в этом году стала компания «Додо пицца Каменск-Уральский» — все благодаря и поддержке поклонников их продукции, и собственной активной позиции предприятия.

И позиция эта неизменна, чем бы ни занималась «Додо пицца» и в каких бы проектах ни участвовала. О том, что такое залог успеха для компании в любом начинании и как он достигается, мы пообщались с управляющим Додо пицца в Каменске-Уральском Сергеем Леонтьевым.

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

— Основатель компании Федор Овчинников начал свое дело в Сыктывкаре. Начинал практически с нуля и все делал сам. Постепенно, шаг за шагом развилась сеть, вышла за пределы маленького города. И вот теперь Додо Пицца — это международный бренд, чей создатель стал примером и вдохновителем для многих предпринимателей.

-Додо пицца, вне всякого сомнения, давно стала узнаваемым брендом и в Каменске-Уральском. Как добралась компания до нашего города?

— Любой «свободный» город с населением от 30 тысяч человек может стать городом присутствия компании. Правило таково: один город — одна компания, то есть один франчайзи. Правда, есть исключения – Москва и Санкт-Петербург.

Вообще, система открытия новых предприятий у нас в корне отличается от прочих франшиз. Ты не можешь просто так взять и открыть Додо пиццу в городе-миллионнике. Сначала необходимо отработать в небольших населенных пунктах. И если у тебя получилось, если ты доказал состоятельность свою как франчайзи, если в полной мере проникся корпоративной культурой и этикой компании, то тогда только на конкурсной основе ты можешь заявляться на открытие франшизы в больших городах. Вот почему Москва и Питер остались «на сладкое» — их освоение началось совсем недавно, когда накоплен был уже достаточный опыт.

Так что открытие Додо пиццы в Каменске-Уральском – вполне закономерный и своевременный процесс. Более того, планируется открытие еще одного заведения – уже в Синарском районе. Так можно еще улучшить качество услуг за счет сокращения времени на доставку – неизменное требование рынка, когда пиццерии, по сути, достигли пика своего развития. И конкуренция все жестче, и требования к продукции все выше. Поэтому для нас важно быть мобильнее.

-Так в чем же секрет успешного развития компании, не важно, в большом ли городе или в малом согласно «философии» Додо пиццы?

-Понятно, что для каждого предприятия (на словах точно) клиент всегда прав. А что на деле? Согласитесь, тот, кто регулярно посещает заведения общепита в Каменске ли или в других ли городах, может подтвердить — качество продукта и обслуживание далеко не на высоте. Культура сервиса оставляет желать лучшего. А нужна именно Культура с большой буквы, заложенная как основа основ компании.

Для Додо пиццы Культура — это набор стандартных действий по всему производственному процессу, который позволяет четко достигать поставленных задач. И у нашей компании эта культура сформирована в полной мере. Здесь и требования к качеству продукции, и соблюдение правил безопасности и соблюдение норм законодательства всех ГОСТов и многое-многое другое. У нас есть живые сообщества, где могут общаться все участники процесса, где можно решить проблему, обсудить спорную ситуацию, поделиться опытом.

-Но клиент все ж таки «всегда прав»?

-Самое главное — мы доверяем клиенту. Если он говорит, что у нас что-то не так – мы постараемся исправить ситуацию. И уважаем своего потребителя – пример тому — тот факт, что публичности мы не боимся. У нас проходят экскурсии, мастер-классы. Мы можем в любой момент без опасений принять гостей, а вы можете в режиме онлайн наблюдать за приготовлением вашей пиццы. Ведь мы твердо знаем, что у нас всегда все в порядке в плане гигиены и безопасности. Потому что нельзя в какой-то отрезок времени работать «на показуху» — потребитель прекрасно понимает, где действительно хорошо всегда, а где просто «на время».

Мы и в проекте «Каменск выбирает» с радостью поучаствовали, потому что знали–нам бояться нечего. Мы открыты и готовы к борьбе за звание лучших в своей сфере.

—Кадры – это ведь тоже немаловажный фактор успеха. Как удается их удачно «подбирать»?

Мы берем на работу молодежь без опыта. У нас можно начать с низшего звена и дорасти до управляющего – отличная база для профессиональной карьеры. И, самое главное, мы не наказываем за ошибки, у нас нет системы штрафов и наказаний, наши работники не боятся ошибаться.

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

-О чем следует помнить, начиная свой бизнес — по франшизе или без нее?

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

]]>

Есть ли франшиза Додо Пицца в Великобритании?

Если вы увлечены пиццей и хотите открыть собственный бизнес, почему бы не открыть франшизу пиццерии? «Додо Пицца» — это отличная возможность для франшизы, поскольку вы сможете следовать проверенной и успешной бизнес-модели на всем пути к успеху в высокодоходной отрасли. Читайте дальше и узнайте все, что вам нужно знать о потенциальных инвестициях во франшизу с Додо Пицца.

---

Бизнес по производству пиццы — один из лучших вариантов в мире франчайзинга в 2022 году, когда рынок доставки пиццы и еды на вынос в Великобритании оценивается в 3 миллиарда фунтов стерлингов и состоит из чуть менее 6500 предприятий [IBISWorld]. Если вы заинтересованы в том, чтобы получить кусочек действия с франшизой пиццы, есть несколько вариантов, столь же идеальных, как Dodo Pizza и ее уникальный цифровой подход.

Давайте будем честными: управление ресторанным бизнесом иногда похоже на жонглирование гранатами — черт возьми. С горящими пятками. Сотни операций каждый день — легко где-то облажаться. К счастью, есть технические решения, которые могут вам помочь. К сожалению, их может быть дюжина плохо интегрированных инструментов (вспомните монстра Франкенштейна). Разве не было бы неплохо, если бы кто-то создал единую платформу, охватывающую все? Ваше желание удовлетворено.

— Додо Пицца

Есть ли франшиза «Додо Пицца» в Великобритании?

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

Операция по доставке, которой управляет почти разоренный, но страстный предприниматель. Так началась история «Додо Пицца» в 2011 году. Теперь это самый быстрорастущий бренд пиццы в мире, IPO которого запланировано на 2024 год. И вместе мы можем добиться еще большего. Присоединяйтесь к нашему международному сообществу франчайзи и делайте пиццу (и историю) вместе с Додо.
— Додо Пицца

---

>> Читать дальше:

• 8 причин, по которым открытие франшизы пиццерии является разумным бизнес-решением
• Наслаждайтесь игрой в пиццерии
• Франшизы пиццерии: создайте свою собственную!
• Как открыть франшизу собственного ресторана пиццы
• 6 преимуществ франшизы итальянской пиццерии
• Топ-5 франшиз по доставке пиццы в Великобритании

---

История франшизы бизнеса Додо Пицца

Как упоминалось выше, «Додо Пицца» была основана в 2011 году Федором Овчинниковым в «подвале без окон в глуши» [Додо Пицца]

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

Согласно «Додо Пицца»: «Наша фирменная платформа R&Digital помогает нам проводить вкусовые исследования прямо в мобильном приложении и глубоко анализировать продукт: внешний вид, содержание воды, температуру, интенсивность вкуса и т. д. Мы получаем подробные отзывы о каждом продукте. от реальных клиентов, и в них участвуют тысячи респондентов. Бесценные данные для завоевания сердец (и животов) людей». Если вы хотите завоевать сердца с Додо, вы можете начать свою собственную франшизу пиццы с компанией сегодня. Мир возможностей ждет.

Начните франшизу в секторе пиццы с франшизой Додо Пицца 

Если все, что вы узнали о путешествии «Додо Пицца» — от крошечного бизнеса до всемирной торговой марки — заставило вас все больше инвестировать, продолжайте читать. Ответы на три вопроса, приведенные ниже, предоставят вам все знания и информацию, необходимые для того, чтобы сделать полностью обоснованные инвестиции во франшизу с Додо Пицца…

1. Как вы собираетесь открыть собственный франчайзинговый магазин «Додо Пицца»?

Чтобы узнать больше о «Додо Пицца» или заявить о своей заинтересованности в франчайзинге с брендом, вы можете посетить специальную вкладку «Франчайзинг» на веб-сайте Dodo Brands. Хотя Dodo не раскрывает свои идеальные черты франчайзи, бренд упоминает о своих четырех ключевых ценностях — ценностях, которые вы также должны поддерживать, чтобы хорошо работать с пиццерией: Цифровой подход, интеграция облачных вычислений , приверженность радикальной прозрачности и способность быть гибким.

2. Сколько нужно инвестировать?

Чтобы стать франчайзи «Додо Пицца», вам необходимо сделать минимальные первоначальные инвестиции в размере 110 000 фунтов стерлингов, при этом плата за открытие магазина составит 3 600 фунтов стерлингов, а роялти взимаются по ставке 5% . Это выше средней стоимости запуска франшизы, которая составляла 42 200 фунтов стерлингов по состоянию на 2018 год [Британская ассоциация франчайзинга], но этот факт неудивителен, учитывая, что франшизы ресторанов и продуктов питания, как правило, требуют более высоких инвестиций и накладных расходов. Чтобы дать вам лучшее представление о том, какое место занимает «Додо Пицца» в более широком секторе пиццы, вот еще несколько примеров инвестиционных затрат:

• Caprinos Pizza — Чтобы стать франчайзи Caprinos Pizza, вам необходимо сделать минимальные первоначальные инвестиции в размере 85 000 фунтов стерлингов, при этом плата за франшизу составляет 5 000 фунтов стерлингов, а общая стоимость инвестиций составляет 95 000 фунтов стерлингов.
• Snappy Tomato Pizza — Чтобы стать франчайзи Snappy Tomato Pizza, вам необходимо сделать минимальные первоначальные инвестиции в размере 10 000 фунтов стерлингов, а общая стоимость инвестиций — 25 000 фунтов стерлингов.
• Toni Loco — Чтобы стать франчайзи Toni Loco, вам необходимо сделать минимальные первоначальные инвестиции в размере 200 000 фунтов стерлингов.

---

>> Подробнее:

• 12 вещей, которые следует учитывать при выборе подходящего места для франшизы вашего ресторана
• 3 способа получить финансирование для ресторанной франшизы
• Правила и лицензии, необходимые для открытия ресторана
• 14 советов по определению и охвату целевых клиентов вашего ресторана
• Наем сотрудников для вашего ресторана
• Выбор концепции для вашего ресторана

---

3. Что вы получаете за свои инвестиции?

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

По словам Додо Пицца, «Каждый день 50 программистов работают несчетное количество часов, чтобы добавить новые интересные функции в приложение Додо. И не зря: только вчера (17 февраля) он обработал 155 717 заказов. Теперь это приложение способствует развитию бизнеса наших партнеров в Европе, Азии и Африке. В Эстонии, например, на приложение приходится 60% дохода — в среднем ежемесячные продажи на единицу продукции составляют 120 000 долларов». Помимо возможностей приложения, вы также получите следующие преимущества:

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

Возможности франшизы «Додо Пицца» — отличный способ начать собственное дело 

Надеюсь, теперь вы знаете все, что нужно для успешного инвестирования в эту компанию. Но если пицца ваше сердце все еще на заборе? Оставайтесь на Point Franchise и продолжайте свои исследования. Только в этом секторе существует множество инновационных брендов, а возможности инвестирования во франшизы пиццы всегда доступны. От Mostro Pizza до Bella Italia, вы обязательно найдете то, что вам подходит!

‎Додо Пицца. Доставка пиццы в App Store

Скриншоты iPhone

Описание

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

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

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

Находится в 13 странах, имеет более 700 магазинов от России до Великобритании. Мы самая быстрорастущая сеть пиццерий. Попробуйте нас! Загрузите приложение и закажите прямо сейчас.

Если у вас есть какие-либо предложения, отправьте их по адресу [email protected].

3 окт. 2022 г.

Версия 8.37.1

Ничего особенного, исправлено несколько ошибок.

Рейтинги и обзоры

951 Рейтинг

Простота

Простота регистрации и использования.

Спасибо за высокую оценку!
Пробуем 💪

Худший UX

Уважаемая Додо Пицца. Поскольку вы называете себя ИТ-компанией, пытались ли вы нанять в свою компанию специалистов по UX? У меня был худший пользовательский опыт с этим приложением. Нет настройки языка и редактирования адреса. Я только что удалил свой адрес, затем добавил другой, но приложение показывает мне два одинаковых старых адреса. У вас есть общая стоимость 159 тысяч долларов, но вы не можете нанять пару нативных разработчиков iOS. Очень обидно осознавать, что некоторые компании абсолютно не заботятся о своих клиентах.

Хорошая идея, плохая реализация.

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

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

Здравствуйте! Спасибо, что нашли время и дали нам обратную связь. Нам очень жаль, что Ваш заказ разочаровал. Это абсолютно не тот уровень работы, к которому мы стремимся. Мы хотели бы выяснить, что произошло, и извиниться перед вами. Не могли бы вы отправить свой отзыв и свой номер телефона на адрес [email protected]?
Что касается камеры, то она показывает процесс готовки в режиме реального времени, так что если больше не было заказов, то она может быть вашей. И мы предполагаем, что ваша пицца была в духовке, поэтому кухня была пуста, а статус был «пицца готовится» 🙂

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

Данные, используемые для отслеживания вас

Следующие данные могут использоваться для отслеживания вас в приложениях и на веб-сайтах, принадлежащих другим компаниям:

• Контактная информация
• Идентификаторы
• Данные об использовании

Данные, связанные с вами

Следующие данные могут быть собраны и связаны с вашей личностью:

• Контактная информация
• Идентификаторы
• Данные об использовании
• Диагностика

Данные, не связанные с вами

Могут быть собраны следующие данные, но они не связаны с вашей личностью:

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

Информация

Продавец

Додо Франчайзинг, ООО

Размер

78,8 МБ

Категория

Еда, напиток

Возрастной рейтинг

12+ Нечастое/умеренное употребление алкоголя, табака или наркотиков или рекомендации

Авторское право

© 2021 ООО «Додо Франчайзинг»

Цена

Бесплатно

• Тех. поддержка
• Политика конфиденциальности

Еще от этого разработчика

Вам также может понравиться

«Прямой маркетинг дает нам 19 % доходов от доставки и самовывоза» / Mindbox Journal

Александр Макаренко и Оксана Тюльпинова рассказали нам о персонализированном маркетинге в международной сети ресторанов «Додо Пицца». У нас состоялся разговор о том, как платформа Mindbox помогает им развивать это направление, каковы результаты и каким будет директ-маркетинг в 2019 году..

Как работал прямой маркетинг в «Додо Пицца» до Mindbox?

Александр Макаренко: Начну с небольшого предисловия. Я начал работать в «Додо Пицца» в апреле 2017 года. На тот момент не было федерального маркетинга, мы с коллегой только начинали его строить. Я отвечал за лояльность клиентов, а часть моего коллеги заключалась в привлечении новых клиентов.

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

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

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

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

Мы выбрали Mindbox из-за его гибкости, которая позволила нам начать с небольшой базы по небольшой цене. Когда стало понятно, что система прибыльна, мы перешли на использование Mindbox для всей базы.

Какова маркетинговая стратегия Додо Пицца?

A.M.: Мы постоянно переключаемся между подходами. Когда мы начинали, мы проводили много акций. Когда к нам присоединилась Оксана, мы переключились на продвижение нашего бренда. Теперь мы вернулись к акциям.

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

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

Пирамида ценностей нашего бренда называется ВКОД+ и означает вкус, качество, открытость и доверие (вкус, качество, открытость и доверие соответственно). Все начинается, когда человек впервые пробует нашу пиццу. Если им понравится, они смогут узнать о нашем подходе к качеству. Открытость позволяет нашим клиентам больше узнать о компании и даже наблюдать за процессом приготовления через веб-камеру. Так мы зарабатываем долгосрочную лояльность клиентов.

Как вы думаете, какую ценность больше всего поддерживает Mindbox?

A. M.: Думаю, все, потому что Mindbox — это инструмент. Если вам нужно забить гвоздь, вы можете сделать это без молотка? Я так не думаю. Что ж, можно попробовать, может, что-то другое подойдет… Но все равно потеряете время и силы. Майндбокс и есть тот самый молот, без него мы бы очень долго страдали.

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

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

Как Mindbox помогает вам в работе?

Оксана Тюльпинова: Mindbox — это система, на которой строится вся наша непосредственная коммуникация. Если бы у нас не было ни его, ни какой-либо другой альтернативы, мы практически остались бы без нашего прямого общения.

Неудобно использовать разные решения для разных каналов. Мы не можем собирать аналитические данные в одном месте или совмещать электронные письма, push-уведомления и SMS. Поэтому мы выбрали Mindbox, он универсальный и агрегирует каналы. Кроме того, мы можем включить другие каналы, если захотим. Например, мы очень гладко интегрировали мессенджеры ВКонтакте.

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

Более того, Mindbox действительно помогает обогащать профили пользователей данными, которые мы собираем. Некоторое время назад мы провели опрос о детях, в котором мы спрашивали людей, есть ли у них дети в возрасте до 12 лет. Данные собирались и добавлялись в профили, а затем людей, у которых были дети, знакомили с книжками-раскрасками. Это работает лучше для людей, потому что это близкая тема для них. Мы бы не смогли сделать что-то подобное с нашими внутренними инструментами. Теперь Mindbox знает о наших клиентах гораздо больше, чем мы.

Расскажите о процессе работы с сервисом? Как это происходит?

O.T.: Все, что нам нужно, мы можем настроить прямо в Mindbox. Короче говоря, вы входите в систему, настраиваете ее и запускаете.

Это так просто?

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

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

Mindbox объединяет все заказы и действия клиентов. Если я хочу узнать, сколько клиентов заказали 25-сантиметровую пепперони четыре раза за последнюю неделю, Mindbox может мне это сказать. У нас есть возможность сделать это и без них, но это займет больше времени и усилий, чем просто войти в Mindbox и отправить запрос.

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

Можете ли вы привести примеры таких задач? Может быть, информационные бюллетени, которые вы запускали через Mindbox?

O.T.: У нас есть массовые и триггерные опросы. Мы используем массовые опросы, если нам нужно собрать большой объем данных. Один из таких случаев произошел, когда был день пиццы, и нам нужно было собирать отзывы. В данном случае мы разослали письма людям из нашей базы данных. Мы спросили, знают ли они о дне пиццы, были ли они когда-нибудь у нас и с какими проблемами столкнулись. Таким образом, мы получаем большой объем данных, с которыми можно работать.

Триггерные опросы мы также проводим по электронной почте. Например, после того, как мы запустили что-то новое: «Привет! Меня зовут Юлия Цыпанова, и я автор рецепта пиццы с салатом Оливье. Вы недавно заказали его, и ваше мнение важно для нас. Расскажите нам, что вы думаете об этом». Человек отвечает, а позже Юлия Цыпанова делится с нами своими выводами из опроса.

В каких случаях опрос повлиял на продукт?

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

Для чего еще вы используете Mindbox?

O.T.: Я думаю, мы могли бы назвать каналы, которые мы используем. Это web и push-уведомления, электронная почта, SMS и Viber.

Благодаря push-уведомлениям наша выручка взлетела до небес сразу после того, как мы начали использовать этот канал. Конечно, нельзя сказать, что это произошло исключительно благодаря Mindbox, потому что рано или поздно мы все равно реализовали бы эту функцию. Но благодаря Mindbox это было сделано легко и быстро. Мы просто интегрировали push-уведомления и начали с ними работать. Это позволило нам реально увеличить наши доходы и охват базы данных.

A. M.: Благодаря Mindbox в нашей работе многое изменилось. Например, раньше мы ежемесячно отправляли электронное письмо о новых продуктах. Текст в них был просто рекламным ходом, вроде «попробуй нашу новую и вкусную пиццу». Но в этом процессе не было никакой автоматизации, никаких сложных сценариев вроде опроса.

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

Додо Пицца — это огромная сеть. Создает ли это проблемы при работе с Mindbox?

A. M. : С самого начала мы столкнулись с организационными трудностями. Есть 450 пиццерий, но только 20 с лишним принадлежат мне. Остальные — франчайзи.

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

Но поначалу мы получали такие реакции, как «Что это за траты? Можем ли мы обойтись без него или сделать это собственными силами?» Или еще хуже: «Мы всегда осуществляли обмен сообщениями вручную, зачем нам эта система?» Но таких вопросов больше не осталось. Mindbox занял свое место в нашей структуре затрат и теперь является частью нашего федерального маркетинга. Наши инвестиции в Mindbox так же важны для нас, как и средства, которые мы потратили на рекламу на телевидении.

O.T.: Если наши партнеры работают на другой платформе, мы должны вручную просматривать все, что они присылают. Сложно собрать единую аналитику и работать с ней. Более того, это делает невозможным ограничение исходящих сообщений. Например, наш партнер в Москве может случайно отправить смс клиентам в Туле и прикрыть этот казус каким-нибудь неубедительным предлогом. Mindbox позволяет нам сделать это технически невозможным. Кроме того, мы устанавливаем ограничения на частоту сообщений. Другими словами, партнер может сколько угодно пытаться спамить свою клиентскую базу, но в рамках Mindbox он просто технически не сможет этого сделать.

Когда приходит новый партнер, получает ли он полный доступ к системе?

O.T.: Mindbox разработал классный интерфейс для наших местных партнеров. Теперь наши партнеры могут сами устанавливать прямые каналы связи через Mindbox. Мы разрешаем им использовать SMS и Viber для этой цели. Они получают специальный интерфейс и условия доступа. Нам нужно разыграть ситуацию, чтобы к апрелю все российские партнеры были в Mindbox.

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

Как далеко вы продвинулись в подключении партнеров к Mindbox?

O.T.: В декабре доработан интерфейс и технические средства для интеграции наших партнеров. Сейчас мы находимся на этапе тестирования с 15 партнерами, которые пытаются понять, что происходит.

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

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

Каковы результаты прямого маркетинга Додо Пицца в цифрах?

O.T.: У нас была цель, чтобы к лету 2019 года 10 % нашего дохода от доставки и доставки приходилось на прямые коммуникации. Мы уже достигли и превысили эту отметку за счет внедрения push-уведомлений.

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

A. M.: Мы думали, что 10 % уже много, потому что когда мы начинали, это было всего 0,5 %.

Почему 10%?

A.M.: Мы просмотрели открытые данные и поняли, что это процент посетителей сайта, которые наши конкуренты получают по электронной почте. Наибольшие показатели составили 10–15 %. И мы решили поставить перед собой такую ​​цель, которая заставит нас увеличить количество каналов и коммуникаций.

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

Каковы ваши маркетинговые цели в 2019 году?

A. M.: Если говорить о наших бизнес-целях, связанных с прямыми коммуникациями, то на год у нас довольно простая цель. Мы хотим получить доход в размере 1 миллиарда долларов к декабрю, используя нашу текущую модель атрибуции. Это значительная доля всех доходов. Почти вдвое больше, чем сейчас, ну, на самом деле ближе к 40%.

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

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

Какую роль будет играть Mindbox в маркетинге «Додо Пицца» в 2019 году?

A. M.: Mindbox — это инструмент, который мы используем для достижения наших целей. С тактической точки зрения нужно было объединить все сообщения, происходящие вне Mindbox, в одну систему. Со стратегической точки зрения, чтобы улучшить наши навыки, чтобы мы могли упаковать все в Mindbox и автоматизировать это.

Можете ли вы указать, что вам особенно нравится в Mindbox и что можно улучшить?

A. M.: Мне нравится открытость и гибкость. Это два ключевых фактора, которые нам нравятся в Mindbox. Система позволяет настроить практически все. Ваша фантазия и профессиональные навыки ограничивают возможности.

Вы можете использовать все данные внутри Mindbox. Это довольно редко, так как большинство сервисов никогда не публикуют данные и не делятся информацией об используемых алгоритмах. Что-то вроде сделки типа «заплати нам, и мы предоставим тебе результаты». Мы не об этом.

Если говорить о недостатках, то интерфейс оставляет желать лучшего, но это временно. На данный момент Mindbox переживает период роста, так как нагрузка на их сервисы увеличивается. Я уверен, ребятам удастся их преодолеть, и их стабильность будет отличной. Действительно, все вопросы удалось решить. Компания готова выслушать, услышать и помочь.

С вашей точки зрения, для каких компаний Mindbox можно рассматривать как хорошую инвестицию?

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

A.M.: Mindbox предназначен для хорошо сформированных и зрелых компаний. Я говорю это потому, что задачи, с которыми он помогает, не возникают внутри компании с самого начала. Если компания новая, то и большинство ее клиентов новые. Таким образом, общение с текущими клиентами, оставившими свои контактные данные, не так актуально.

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

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