Проектирование единой ERP-архитектуры

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

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

Система проектировалась как веб-система с поддержкой PWA. Такой формат был выбран совместно с клиентом для того, чтобы пользователи могли работать через браузер, а при необходимости использовать интерфейс как приложение на рабочем устройстве. Для сети с несколькими филиалами это удобнее, чем классическое локальное ПО: обновления можно централизованно выкатывать на сервере, а доступ сотрудников контролировать через авторизацию и роли.

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

Web + PWA как формат работы сотрудников

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

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

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

Управление заказами и очередью

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

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

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

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

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

CRM клиентов и история обслуживания автомобилей

В рамках проекта была выполнена разработка CRM системы с нуля, встроенной непосредственно в операционный процесс автомойки и шиномонтажа. Это важно: CRM здесь не является отдельным справочником, куда кто-то вручную заносит клиентов после обслуживания. Она работает прямо в момент создания заказа.

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

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

Автомойка и шиномонтаж в единой логике

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

Подсистема шиномонтажа получила те же базовые разделы, что и автомойка: заказы, начисления, история заказов, дисконтные карты, сотрудники и предварительная запись. Это позволило сохранить единый пользовательский опыт для сотрудников, но при этом добавить специфический функционал шиномонтажа — хранение комплектов шин и дисков.

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

Подсистема хранения шин и генерация документов

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

В системе предусмотрено создание и редактирование договоров хранения. В договоре фиксируются марка и модель автомобиля, ФИО клиента, телефон, номер договора, адрес клиента, документ клиента и срок хранения. После заполнения данных система формирует договор в PDF-формате и переводит его на страницу печати.

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

Для активного договора предусмотрена возможность сформировать акт возврата. Таким образом, подсистема закрывает полный жизненный цикл хранения: договор, прием, учет комплекта, печатные документы и возврат клиенту. Это пример заказной разработки ПО, где стандартная CRM или кассовая программа не покрывает реальные процессы бизнеса, и требуется точная настройка под операционную модель заказчика.

Дисконтная система и программа лояльности

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

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

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

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

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

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

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

Это важная часть системы для B2B-сценариев. Автомойка и шиномонтаж работают не только с частными клиентами, но и с компаниями, у которых есть автопарк. Поэтому ERP должна была поддерживать не только разовые заказы, но и долгосрочные договорные отношения.

Управление персоналом, ролями и филиалами

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

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

Такая модель доступа нужна не только для безопасности, но и для чистоты отчетности. Кассир должен видеть данные своей точки, администратор — работать со своим потоком заказов, а управляющий — контролировать сеть целиком. Это уже уровень enterprise системы, где важно учитывать роли, филиалы, права, финансовые операции и управленческий контроль.

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

Управление услугами и ценами по филиалам

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

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

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

Финансовая аналитика и ежедневная отчетность

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

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

Этот блок можно рассматривать как внутреннюю систему бизнес-аналитики: она не заменяет полноценную BI-платформу, но дает руководителю рабочие показатели прямо внутри ERP. В системе появляются интерактивные отчеты, которые связаны с реальными заказами, оплатами, услугами, сотрудниками и филиалами.

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

Аудит операций и контроль изменений

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

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

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

‍