Как мы автоматизируем доставку еды на Айко

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

Этим постом мы подводим двухлетние итоги внедрения системы автоматизации ресторанов – iiko («Айко», далее – система автоматизации ресторана, САР, иначе по правилам Хабра будет реклама). Это не будет хвалебный отзыв. Говорим, как есть, не скрывая проблем. При этом понимая, что для нас сегодня нет решения более продуманного и подходящего.

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

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

Да кто вы такие? И что себе позволяете?

Чтобы был понятен наш масштаб. Мы работаем в регионе, в 500 км от столицы. Считаем себя крупнейшей сетью доставки готовой еды (суши, пицца) в нашем городе, «сильнее» нас только один федеральный конкурент. В структуре компании: собственный склад, 4 точки (точка = производство = кухня), выделенный колл-центр, офис.

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

Так почему выбрали новую САР?

Когда стало ясно, что используемая система автоматизации («1С-Рарус: Ресторан + Бар + Кафе», далее – РБК) не позволяет компании двигаться вперед, мы начали поиск подходящего решения.

Провели «пилотные» внедрения нескольких продуктов: «Удобное решение», «Тардис Бистро», Dooglys. Съездили на PIR EXPO, внимательно поработали на стендах с демонстрациями R-Keeper, Poster, Tillypad и др. Шли недели и месяцы сравнений разных решений, но ничего не нравилось. Ни один игрок рынка не смог предложить «коробку», которая бы для службы доставки подходила на 100%. А заниматься заказными доработками и интеграциями в наших реалиях казалось удовольствием сомнительным – как минимум, долгим и дорогим.

Но нужно было двигаться вперед. Среди локальных оптимумов сравнительная табличка показала одного лидера. В конце 2017 года выбранная САР обещала выполнить следующие пункты технического задания на автоматизацию:

• подключение колл-центра к системе автоматизации;
• ведение единой базы данных (клиенты, заказы, технологические карты, ингредиенты и проч.), доступной на всех объектах компании (офис, колл-центр, склад, кухни-производства);
• интеграция с сайтом, мобильным приложением и агрегаторами доставки;
• СМС оповещение клиентов;
• установка курьерского приложения на смартфоны курьеров с историей и статусами заказов, навигацией;
• ведение складского учета и планирование закупок.

Сегодня, спустя почти два года после успешного внедрения САР (правда, временами приходя в отчаяние от регулярных ошибок интеграций и кажущегося отсутствия конструктива в общении с поддержкой и разработчиками), мы понимаем: выбор был оправдан. Более подходящего для нас решения пока не видно на горизонте.

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

Внедрение

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

Пытать счастья с местным дилером мы не стали (выбор был из одной альтернативы), поскольку подобных масштабов автоматизации в нашем городе больше нет. Соответственно, и опыта внедрения нет. Возможно, маленькой кофейне с одной кассой легче работать «очно» с инженером, который приедет и на месте «все сделает» (хотя при таких исходных данных у выбранной САР много сильных конкурентов – Эвотор, Dooglys, Poster, Frontpad и не только). Мы решили, что сможем внедрить систему автоматизации «заочно», совместно с инженерами головной компании, по удаленным каналам. Не ошиблись, решение оказалось подходящим.

Почти месяц потратили на согласование архитектуры внедрения (к сожалению, метод проб и ошибок – не самый удачный и быстрый для таких задач), получили следующую схему:



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

Между lifetime лицензией и арендой облачного решения выбрали второй вариант – iikoCloud. Да, возможно это дороже в итоге и появляется лишняя зависимость от поставщиков услуг (про сбои – ниже). Но при этом нет необходимости покупать свой сервер, резервировать данные, электропитание, каналы связи.

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

Бюджет решения

Сколько все это удовольствие стоит летом 2019 года?

Первоначальный запуск и настройка сервера в облаке оплачивается отдельно – 6000 рублей. Кроме того, каждый сервер производства нужно синхронизировать с центральным сервером iikoChain, еще 6000 рублей разово. Итого затраты на запуск нового производства – 12000 рублей.

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

• 5990 рублей – «Лицензия на ПО iikoCloud 2017 (первое АРМ)» (такая расшифровка будет стоять в счете);
• 1990 рублей – «Лицензия на ПО iikoCloud (1 доп. АРМ)»;
• 1990 рублей – еще одна «Лицензия на ПО iikoCloud (1 доп. АРМ)».

Т.е. считаются и рабочие места операторов, и кассы на производствах. Приобретенная лицензия может «активировать» любое рабочее место – или в колл-центре, или на производстве, не важно. Главное – оплатить общее количество рабочих мест.

Сегодня у нас 5 рабочих мест операторов колл-центра и 4 рабочих места на производствах. Итого 9 АРМ, расчет следующий:

• 5990 рублей – «Лицензия на ПО iikoCloud 2017 (первое АРМ)»;
• 5590 рублей – пакет из 3 дополнительных касс;
• 5590 – второй пакет из 3 дополнительных касс;
• 1990 – одна дополнительная касса;
• 1990 – еще одна дополнительная касса.

Итого 9 рабочих мест, общий ежемесячный бюджет: 5990 + 5590 + 5590 + 1990 + 1990 = 21150 (рублей).

В июле месяце мы получили уведомление. До конца 2020 года для нас сохраняются старые цены, а с января 2021 года мы переходим на новые тарифы. Грубый расчет показал, что стоимость аренды для нас вырастет «всего лишь» вдвое. Думайте сами, считайте сами.

Кроме того, мы еще дополнительно оплачиваем аренду коннектора «iikoDeliveryConnector (API)», 500 рублей ежемесячно. Это для того, чтобы внешние интеграции могли подключаться к облаку.

Не забываем про дополнительные услуги, оплачиваются отдельно. Например, настройка интеграции с виртуальной АТС «Mango Office» (далее – Манго) – 1500 рублей. Настройка одного рабочего места оператора – 6000 рублей. Запуск программы лояльности – 2000 рублей.

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

Подключение IP-телефонии (сразу освобождаем одну должность оператора)

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

САР предоставляет возможность подключения IP-телефонии, автоматического определения номера клиента и отображения «контекста» клиента сразу при входящем звонке: имя, адрес, история заказов. Это не просто удобно, это сразу же ощутимо ускоряет процесс оформления заказов.

Сотовые номера от МТС и МегаФон мы подключили к Манго, а затем с помощью модуля iikoPBX – на компьютеры операторов колл-центра напрямую к системе автоматизации. Вместо старых кнопочных телефонов появились гарнитуры (но старые телефоны не выбрасываем, Манго уже трижды в 2019 году сбоил). Теперь при входящем звонке определяется номер телефона клиента. Если он уже когда-то заказывал у нас, оператору открывается карточка клиента с историей заказов. Кроме того, перезвонить клиенту оператор может сразу из приложения одной кнопкой, сэкономив время на наборе цифр номера.

Такое, казалось бы, простое решение позволило нам освободить одну должность оператора колл-центра. Заказы стали обрабатываться быстрее, сервис стал лучше. Инженеры компании взяли прием на вооружение: начинали с колл-центра, сейчас заканчиваем подключение IP-телефонии на всех объектах компании. Пока одни плюсы.

Настройка скидок

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

И это не шутка, таковы реалии: раньше приходилось скидки и бонусы рассчитывать/перепроверять на калькуляторах.

Настройка интеграции с агрегаторами доставки

В декабре и январе, а также ближе к выходным и праздникам почти треть всех заказов мы принимаем от агрегаторов доставки – DeliveryClub (много) и ZakaZaka (меньше процента). В другие дни и месяцы чуть меньше, но доля остается значимой. Яндекс.Еда пока не работает в нашем городе.

Как обстояли дела раньше? В отдельном приложении агрегатора доставки операторы колл-центра принимали заказ и «перебивали» вручную в систему автоматизации РБК. Зачем? Настраиваем интеграцию c САР, DeliveryClub относительно быстро применяет все необходимые настройки.

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

Свой сайт доставки

В старой схеме работы заказы с сайта тоже вручную дублировали в РБК. Лишнее действие, требуется автоматизация. Приступили к поиску исполнителей для настройки интеграции САР и сайта.

На сайте iiko.biz в магазине приложений есть такое решение – iikoDeliveryWidget. Это виджет, который можно встроить на свой сайт для автоматической передачи заказов с сайта в САР. Разработчик – jstore.me, официальный партнер, команда из Санкт-Петербурга. Базовых возможностей виджета нам не хватило, обратились к разработчикам за кастомным решением. Сроки и бюджет показались завышенными.

Тем временем нашли понравившийся шаблон для будущего сайта: https://sushi.bdbd.shop. Позже обнаружили его и в маркетплейсе 1С-Битрикс (название шаблона – «Delivery Shop»), познакомились с отзывами и обсуждениями. Связались с разработчиками шаблона из Новосибирска, снова сроки и бюджет кастомизации (методами API iikoDelivery подключить интеграцию сайта и системы автоматизации) показались завышенными. Кроме того, в целом желания работать с нами на индивидуальных условиях в глазах разработчиков не увидели.

Поиски продолжили по известной схеме. Обзвонили десяток клиентов из портфолио jstore.me и sushi.bdbd.shop. Технический директор одной мурманской службы доставки поделился опытом и рассказал, как они сменили исполнителей: вместо новосибирской команды подключили к проекту разработчиков vsem-edu.ru, Набережные Челны.

После близкого знакомства заключили договор с этой командой на разработку и интеграцию. Точнее, выкупили уже готовый продукт (120000 рублей в рассрочку на 6 месяцев, сайт + мобильное приложение) с небольшими доработками по ходу внедрения (1000-1500 рублей за один час работы программиста).

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

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

Семён Фудов и собственные разработки

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

Часть PHP кода открыта здесь: https://github.com/fisher85/iiko-api. Там же есть Jupyter блокнот для любителей machine learning – c предсказанием количества заказов на произвольную дату (python, scikit-learn).



Кстати, прогноз продаж есть и в iikoWeb (доступ бесплатный для тех, кто арендует iikoCloud). Правда, качество решения оставляет желать лучшего: простое добавление в признаковое пространство булевых флажков: «Сегодня праздничный день?» и «Есть ли сегодня маркетинговая акция у агрегаторов доставки?» позволяет заметно улучшить результаты.



Отдельная история – разработка плагинов для iikoFront на С#. Из задумок на будущее: плагин изменения статуса заказа в ручном режиме, монитор готовности заказов на производстве для клиентов take away, плагин печати рекламных листовок вслед за чеком.

UPDATE. В 2020 году направление собственных разработок отделилось и теперь более 30 преднастроенных отчетов и курьерское веб-приложение доступны как сервис «Семён Фудов» fudov.ru:



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

Электронная почта для связи с Семёном Фудовым – hello@fudov.ru.

Поддержка

После внедрения САР у нас стали возникать вопросы: «Как задать такое-то условие в скидочной программе?», «Как отредактировать шаблон чека?», «Как настроить автозаказ для кухни?», «Почему возникают ошибки интеграции с DeliveryClub?», «Почему ответ метода API iikoDelivery не соответствует документации?» и миллион других. Вопросы адресовались службе поддержки, поддержка первым делом смотрела на тариф. Если тариф «Базовый», то первые три заявки в месяц закрывались оперативно, а последующие – по мере освобождения специалистов, никто не торопился с ответом. Поэтому со второго месяца работы мы выбрали тариф «Standard» (в новой редакции тарифов такого нет, есть «Расширенный»).

Если оценивать грубо, расширенная поддержка стоит около 2000 рублей в месяц за одно рабочее место. Чем больше рабочих мест, тем больше скидка. Для доставок АРМом считается не только компьютер с iikoFront на производстве, но и каждый компьютер оператора колл-центра. У нас 9 АРМов, ежемесячная стоимость поддержки выходит около 18000 рублей. Есть о чем подумать, особенно при условии необходимости полной предоплаты за предстоящие 3 месяца. У партнеров тоже можно подключить расширенную поддержку, обещают время реакции меньше, но и стоимость обслуживания выше (присматривались к Лемме и Open Service).

Как понять, нужна ли расширенная (за дополнительную плату) поддержка? По условиям 2018 года при переходе на тариф «Standard» мы получили неограниченное количество заявок в месяц и гарантированные сроки разрешения инцидентов. Теперь вместо средних 24 часов был установлен срок 4 часа на разрешение инцидентов.

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

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

Примерно полгода мы пользовались платной поддержкой и вели наблюдения: фиксировали время выполнения наших заявок и время разрешения инцидентов. А потом в качестве эксперимента решили на месяц-два перейти на бесплатную поддержку. Да, теперь мелкие доработки мы оплачиваем отдельно (час работы инженера ~1600 рублей). Но сроки разрешения инцидентов остались практически без изменений. Закончился уже четвертый месяц, возвращаться к платной поддержке не планируем.

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

Сопровождение и сбои

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

У нас давно ведется свой журнал нарушений работы, куда записываются все неисправности: когда неприятели перегрызли сетевой кабель и пропал основной интернет, когда сбоила IP-телефония Манго и перешли с гарнитур на обычные «трубки», когда электрики отключили питание и пришлось проверять бесперебойники на деле. Ведется без изысков, в Google Docs.

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

Для примера ниже на графике показана статистика обращений в поддержку, первый квартал 2019 года. Пила снизу – это номер дня недели, где пик – воскресенье. Примеры заявок в первые месяцы были выше, из последних обращений: «Измените адрес производства», «Обновите версию ПО на сервере», «Сбой! Устраните ошибку интеграции».



Сразу отметим, что количество заявок в поддержку больше, чем количество сбоев. В среднем каждый месяц мы передаем в поддержку 29 обращений, из них 3 обращения – по сбоям. Но сбои распределены неравномерно: январь – 3 сбоя, июль – 7 сбоев.

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

Самое неприятное в обслуживании нашей системы автоматизации – это регулярные сбои в часы высоких нагрузок на iikoCloud. Частота таких сбоев обескураживает и с трудом поддается прогнозам. Приводим статистику ошибок интеграции в июле 2019 года, интенсивность оцениваем временем простоя (при этом у нас была платная поддержка):

• 5 июля, пятница, 40 минут;
• 8 июля, понедельник, 30 минут;
• 15 июля, понедельник, 1 час;
• 20 июля, суббота, 3 сбоя, общий простой 2 часа 30 минут;
• 22 июля, понедельник, 30 минут.

Карл, 7 сбоев за один месяц! Плавно переходим к вопросам гарантии доступности облака САР.

Гарантии доступности

К сожалению, в оферте (на момент написания поста актуальная версия от 22 апреля 2019 года) нет ни слова о допустимом времени даунтайма iikoCloud. В устных переговорах отдел продаж и служба поддержки аккуратно говорят про Tier 3, значит, в примерный расчет можем брать отказоустойчивость 99.98%, даунтайм 105 минут в год.

Первый же крупный сбой iikoCloud, случившийся в декабре 2018 года, оставил нас без доступа почти на 2 часа (принимать заказы можно и в таких случаях, но при этом приходится считать скидки вручную, передавать заказы из колл-центра на производства по Telegram/WhatsApp и там уже вводить в iikoFront). Мы посчитали, что такая ситуация нарушает соглашение об уровне услуг (которого реально нет), и составили претензию, приложив расчет числа упущенных заказов. Решение было принято в нашу пользу – освободить от оплаты аренды iikoCloud в следующем месяце. Но к ожидаемым гарантиям начинаем относиться настороженно.

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

Самые частые случаи в нашей практике – это ошибки на стороне iiko.Biz, iikoCard и API iikoDelivery, два раза в месяц точно, а в июне-июле 2019 года вообще каждую неделю. Каждая такая ошибка приводит к остановке всех внешних интеграций (наш собственный сайт, наше собственное мобильное приложение, DeliveryClub, ZakaZaka, Яндекс.Еда), заказы с них перестают корректно поступать в САР в автоматическом режиме и требуют «ручного» сопровождения. Сейчас у нас более половины заказов поступает с внешних интеграций, представляете, какая лишняя (и главное – незапланированная) нагрузка появляется у операторов колл-центра? И за чей счет эта нагрузка.

Формально, доступность iiko.Biz, iikoCard и API iikoDelivery вообще не гарантируется. Нигде и никак. Это еще можно терпеть, когда сбои с понедельника по четверг и на полчаса. Но когда сбой происходит в пятницу или на выходных, в час пик, а потом второй раз, третий… Трудно найти этому объяснение.

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

Да, это не есть правильно, это «прыжки через голову», но нам не дают другого выхода. И, кроме того, у нас по-прежнему нет гарантий доступности iiko.Biz, iikoCard и API iikoDelivery.

Пока готовился этот пост (почти полгода), произошли заметные улучшения в доступности облачных сервисов. По состоянию на декабрь 2019 года ошибки интеграции по-прежнему возникают в среднем с той же периодичностью, но их продолжительность сократилась до нескольких минут. Предполагаем, что это связано с переходом на версию 7 (7.0.6022.0).

Что можно посоветовать тем, кто только знакомится или недавно начал внедрение САР?

1. Вести журнал учета всех сбоев у себя с фиксацией обращений в поддержку и номеров заявок.
2. Не стесняться отстаивать свои права и по всем повторяющимся сбоям требовать объяснений: почему такое возможно в компании, претендующей на мировое лидерство в области автоматизации ресторанов (цитата с официального сайта: «Мы вместе делаем лучший в мире софт для автоматизации ресторанов»)? И какие меры предпринимаются, чтобы сбои не повторялись? Если возник блокирующий сбой iikoCloud – не стесняться обращаться с претензиями и требовать компенсаций. Ничего личного, это бизнес.
3. С учетом июльского повышения цен – возможно, есть смысл отказаться от аренды iikoCloud и выкупить lifetime решение. Мы пока думаем, считаем, уточняем ограничения, все ли используемые нами сервисы можно будет развернуть локально. Предварительная информация: внешние интеграции в любом случае будут подключаться к локальному решению через арендуемое облако, поэтому от ошибок интеграции такая схема точно не избавит.

Обучение

Как мы учились и продолжаем учиться? Где брать знания?

1. Официальная документация. Лучшее, с чего стоит начать.
2. Официальные видеокурсы.
3. Официальные бесплатные вебинары.
4. Скринкасты во время сеансов удаленной настройки наших рабочих станций инженерами компании-разработчика САР.
5. Обращения в поддержку. Особенно активно пользовались этим источником, когда разбирались с API iikoDelivery.
6. База знаний для партнеров (доступ только для партнеров и желающих получить этот статус).
7. Telegram-канал (~200 подписчиков, чересчур приправленный маркетингом). Особенно комично читать историю про открытие офиса в Лондоне и рассказ Максима Нальского про лучшую в мире систему управления ресторанным бизнесом, когда второй день лежит сервер программы лояльности и поддержка не может устранить сбой.

Партнерство

За первый год работы с САР наша команда из 4 инженеров «прокачала» себя настолько, что мы поняли – готовы помогать другим. Чтобы самим продавать САР и оказывать услуги, необходимо получить статус партнера.

Детальные условия под NDA, делиться не имеем права. Но в общем смысл простой: компания-партнер подтверждает свой уровень квалификации (как минимум один сотрудник должен сдать экзамен и получить сертификат) и после этого получает вознаграждение за каждое внедрение САР. Плюс имеет право оказывать платную поддержку.

Сертификация и сдача экзаменов

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

Экзамен платный (1000 рублей), состоит из двух частей. Теория и практика. До практики допускают только после сдачи теории. Первая попытка закончилась «двойкой» и получением списка из 80 вопросов, выпавших в тесте. На проработку всего списка ушло 2 месяца.

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

Не сдались, на партнерском портале запросили бесплатные демо-лицензии САР и начали тренировки по разным сценариям на виртуальных машинах. В декабре 2019 года (третья попытка) наш инженер успешно сдал практическую часть и стал сертифицированным специалистом:



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

А стоит ли овчинка выделки?

Когда мы только присматривались к системам автоматизации, выбранная в итоге САР выделялась на фоне конкурентов какими-то заоблачными ценами. Представьте ситуацию. Директор службы доставки до сих пор использовал «полубесплатную» версию РБК, а тут ему новый молодой CTO говорит: в месяц нужно 50000 рублей на аренду софта. И это в регионе, где подобный бюджет превышает месячную зарплату квалифицированного сотрудника.

Но через полгода стали заметны первые результаты. Подключение SIP-телефонии прямо в систему автоматизации, настройка автоматического расчета скидок и интеграция с DeliveryClub позволили освободить одну должность оператора. Еще через несколько месяцев разработка нового сайта в связке с API iikoDelivery позволила освободить еще одну должность оператора. Оркестр заиграл с новой силой.

Кроме того, с внедрением САР бухгалтерия и склад начали использовать Диадок и DocsInBox, а в офисе увлеклись программированием на PHP и C#. Без сомнений: современная автоматизация развивает инженерную культуру внутри компании.

Теперь о проблемах и неприятностях. Ошибки интеграции – на наш взгляд, слишком частые для облачного решения. Высокая цена и аренды самого решения, и поддержки (при этом невозможно отказаться от неиспользуемого функционала, у нас – бухгалтерия, интеграция с видеонаблюдением и СКУД, половина отчетов и не только). Низкая заинтересованность главного офиса и поддержки API в сотрудничестве с «мелкими» партнерами-разработчиками. Индивидуальные доработки согласовываются вечно. Появляющаяся зависимость от выбранной САР при запуске каждого следующего элемента автоматизации: сайта, интеграций, мобильного приложения, собственных разработок.

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

Финал

Еще несколько наблюдений, которым не нашлось места по тексту.

1. С менеджером компании-разработчика нужно дружить, он фронтмен компании. Поможет сэкономить в правильном месте, принять претензию, «надавить» на поддержку. Александр, спасибо! Снимаем шляпу.
2. С поддержкой нужно дружить. Только они могут спасти в минуту сбоя. Если дружить с поддержкой не получается, нужно как минимум дружить с руководителем отдела поддержки.
3. Самые сложные и местами тупиковые вопросы решались неожиданно. Например, стоило приехать на METRO EXPO, познакомиться с директором по маркетингу и пожаловаться на нерасторопность менеджеров по обучению, поддержки API, рассмотрения сбоев – спустя несколько дней все заработало как часы.
4. Если вы из региона, посещение как минимум PIR EXPO должно стать для вас ежегодной традицией. Инженеры за один день смогут поработать на всех стендах с лучшими в стране системами автоматизации. Не торопитесь оплачивать билеты: если вы уже сотрудничаете с кем-то из крупных игроков рынка, можно попросить бесплатные пригласительные.

Пусть поисковые системы находят этот пост по запросу: «Отзыв об автоматизации ресторана на Айко». Уверены, эта история будет полезной для тех, кто только выбирает систему автоматизации или уже присматривается к R-Keeper, СБИС Presto, Poster, Tillypad, Frontpad, Quick Resto, Dooglys, Трактиръ или многим другим.

Жму руки всем коллегам, с которыми мы вместе уже два года автоматизируем доставку. И, конечно же, это не финал. Это только начало!

Титульная фотография: A first-hand review of Haidilao's smart hotpot restaurant in Beijing, South China Morning Post.