{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Как навести порядок в компании и увеличить прибыль на 20%

Расскажу об одном картинге, которому команда Alto помогла наладить контроль и порядок в организации. Как результат — прибыль компании выросла на 20% и запустили новый филиал.

Turba karting hall — это самый большой картинг-центр в Екатеринбурге: отдельное здание с трассой на 386 метров, раздевалками, душевыми и кафе. Проводят детские и взрослые заезды. Есть своя школа для новичков и опытных спортсменов. Сайт — turbakarting.ru

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

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

Как было → Как стало

Когда мы начинали, в Turba karting весь учет вели в таблице Excel. Получалось так, что клиент приходил на кассу, оплачивал заезд. Менеджер заносил в расписание и отправлял к сотруднику парка. А заездов было много и не всегда было понятно какие заезды внесли в расписание. Это никак не отслеживалось. Был такой типичный неработоспособный учет, который жил только благодаря чьей-то ответственности.

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

  1. Посетитель подходит к стойке администратора;
  2. Администратор бронирует заказ в системе;
  3. После бронирования печатает билет;
  4. Посетитель проходит с билетом в закрытую зону, где ожидает заезд.

На видео показан процесс взаимодействия с новой системой:

Старт работ

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

Выбор технологии

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

В итоге наш выбор остановился на фреймворке Yii2 Advanced для реализации внутренней части. Для внешней части — React JS. Это »золотая середина» по соотношению цены и качества.

В своем выборе мы опирались на критерии и бизнес-задачи клиента:

  • Доступ с мобильных устройств;
  • Недорогая поддержка и легкая масштабируемость;
  • Единая база данных;
  • Отсутствие ограничений по операционным системам.

Модуль расписания

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

Также модуль контролирует работу администратора и защищает заказчика от манипуляций с заказами. Например, не позволяет добавить два заезда в одно время. Либо запрещает печатать билет, пока не заведена оплата.

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

Модуль заказа и печати билета

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

Модуль отчетов

Общий отчёт — модуль, ради которого создавался проект. Он позволяет в онлайн-режиме посмотреть:

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

Результаты проекта

Систему запустили в 2020 году. Уже прошло 3 года, взглянем на результаты:

  • Система по прежнему используется клиентом без регулярной технической поддержки.
  • Прибыль компании выросла на 20%.
  • Снизилась нагрузка на директора
  • Открыли новые филиалы, масштабировали систему без привлечения разработчика.

Остальные кейсы можно посмотреть в портфолио. Также подписывайтесь на мой телеграм-канал. В нём анонсирую статьи, рассказываю о работе команды, делюсь исследованиями.

0
19 комментариев
Написать комментарий...
Петр Любицин

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

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Самый классный вопрос. С этого и начали, не смотря на то, что не вднеряем предложили клиенту посмотреть на Битрикс24 и решения для записи по типу Yclients. Но, во-первых не было решения, которое позволяет именно такую шахматку сделать. Во-вторых, клиент не хотел разбираться в готовом, нужно было повторить прошлый интерфейс «как в экселе».

Ответить
Развернуть ветку
Ilya

«Повторить прошлый интерфейс как в экселе» - заберу в мемные кейсы 😁 Достаточно суровый аргумент

Но теперь понятно, спасибо )

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Это, если помните, у кинопоиска был плохой дизайн и яндекс решил сделать лет 6 назад хорошо. И сделали правда стильно, но пользователи захейтили, потому что сила привычки) Тут так же, привыкли и всё тут)

Ответить
Развернуть ветку
Влад Кошечкин

Тут все же не самое корректное сравнение. Миллионы пользователей или около десяти. Я бы все же сравнивал тогда стоимость внедрения готового (включая обучение, настройку и тд) и разработку кастомного приложения, и уже это использовал как аргумент.

Ответить
Развернуть ветку
Андрей Потапов

Тот же самый вопрос возник

Ответить
Развернуть ветку
Ilya

Потому что за иначе клиент не заплатит денежку? :)

Ответить
Развернуть ветку
Татьяна Никанорова

А какое готовое решение вы видите в данном вопросе?

Ответить
Развернуть ветку
Вячеслав Зыкин

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

Кейс крутой, да.

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Много времени ушло на составление ТЗ и прототипирование — месяца три. Чтобы утвердить всю логику. И потом реализация 3 месяца. Я, к сожалению, не знаю, какая прибыль у клиента. Да и если бы знал, то разглашать не мог, но +20% к прибыли думаю за несколько месяцев окупили систему.

Ответить
Развернуть ветку
Вячеслав Зыкин

спасибо. полгода — это довольно быстро, имхо.

а численный состав команды — не секрет?

Ответить
Развернуть ветку
Татьяна Никанорова

Иван, решение офигенно крутое! Я прочла от корки до корки. Но! Бюджет где? Пожалуйста, озвучивайте бюджет, ну хоть "от", хоть как угодно! Пожалуйста!

типа: Сейчас мы бы написали такую систему за столько-тоК рублей и столько-то месяцев.

Ответить
Развернуть ветку
Иван Ярославцев
Автор

Татьяна, спасибо) От 800т.р. и 3-х месяцев.

Ответить
Развернуть ветку
Татьяна Никанорова

Спасибо большое.

Ответить
Развернуть ветку
Лера Луц

неплохие результаты получились)

Ответить
Развернуть ветку
Иван Ярославцев
Автор

мы и сами охренели

Ответить
Развернуть ветку
Кирилл Зотов

Не знаю о чем статья, но за кота лайк!

Ответить
Развернуть ветку
Валерия Щербакова

Ну такой себе кот

Ответить
Развернуть ветку
Макс Симченко

Что против кота имеешь?

Ответить
Развернуть ветку
16 комментариев
Раскрывать всегда