Обращения нигде не фиксировались
Сколько было звонков и заявок, откуда пришли, от кого, чем закончились. Заказ-наряд создавался, когда транспорт уже загнали на проверку, — значит все, кто позвонил и не доехал, для системы не существовали.
Сервисный центр по ремонту и обслуживанию коммерческого транспорта, больше двадцати машиномест. В 1С велись заказ-наряды, и эту часть работы система закрывала хорошо. Проблема была в том, что заказ-наряд появлялся только когда машина уже заехала в бокс, — всё, что происходило раньше, компания не видела вовсе.
Ключевая идея проекта: 1С никуда не делась и продолжает вести заказ-наряды. Битрикс24 встал перед ней и вокруг неё — закрыл всё, что происходит до появления наряда и параллельно с ремонтом.
С этим запросом обратился технический директор. 1С справлялась со своей задачей — оформлением заказ-нарядов, — но четыре вопроса управления оставались без ответа.
Сколько было звонков и заявок, откуда пришли, от кого, чем закончились. Заказ-наряд создавался, когда транспорт уже загнали на проверку, — значит все, кто позвонил и не доехал, для системы не существовали.
Постов больше двадцати, но понять, когда освободится очередной, можно было только обойдя цех или обзвонив мастеров. Записать клиента на конкретный день превращалось в угадывание.
Автомобиль в простое — это занятый пост, недовольный клиент и невыставленный счёт. Причины бывают разные: ждём деталь, ждём согласования, ждём свободного специалиста. Без фиксации причины простой просто длился.
Автослесарям приходилось постоянно ходить и спрашивать: есть ли деталь в наличии, когда придёт нужная для этого наряда. Это отнимало время у обоих и всё равно не давало точного ответа.
Это главный вопрос любого сервиса, у которого уже есть учётная система. Ответ на него определил всю архитектуру проекта: мы ничего не переносили из 1С и не дублировали её функции.
Это её профильная задача, и решает она её лучше любой универсальной системы.
Обращения, планирование ресурса, коммуникация между сотрудниками и история клиента.
Не пять контуров, а один сквозной путь: обращение, консультация, запись, приёмка, ремонт, выдача. Сервисный цикл здесь короткий и однородный по составу участников — дробить его на отдельные воронки было бы ошибкой.
Когда машина принята в работу, заказ-наряд формируется в 1С автоматически, а обмен данными идёт онлайн. Двойного ввода нет: приёмщик не заносит одно и то же в две системы, а состояние наряда видно в Битрикс24 без переключения окон.
Автомобиль заведён отдельной сущностью и закреплён за компанией-владельцем. Это меняет логику работы с клиентом: у автопарка десять машин, и история каждой должна храниться отдельно, а не сваливаться в общую карточку организации.
Самая заметная для цеха часть проекта. Потребность в детали фиксируется прямо из наряда, заказ уходит снабжению, а когда деталь поступает — слесарь получает уведомление в мобильном приложении Битрикс24. Именно в телефон, потому что человек стоит у машины, а не за компьютером.
Посты стали видимым ресурсом: занятость каждого отображается наглядно, вместе со сроком освобождения. Запись клиента перестала быть обещанием наугад — приёмщик видит свободное окно и называет реальную дату.
Видно, сколько людей обратилось, из какого канала, и сколько из них доехало до сервиса. Появилась цифра, которой раньше просто не существовало.
Приёмщик видит занятость постов и называет клиенту реальный день. Меньше очередей на въезде и меньше машин, которые приехали и ждут неизвестно сколько.
Автомобиль, который стоит, отображается с причиной: ждёт деталь, ждёт согласования, ждёт специалиста. Руководителю есть на что реагировать.
Уведомление о поступлении детали приходит слесарю в телефон. Обоим вернулось время, которое уходило на хождения и повторные вопросы.
Повторный визит начинается не с расспросов, а с открытой карточки машины, где видно все прошлые работы.
Заказ-наряд формируется в 1С автоматически. Сотрудник заносит данные один раз, а не переписывает их из системы в систему.
В этом проекте связка с 1С была обязательной. Но мы не считаем её обязательной вообще: на мебельном производстве мы интеграцию делать не стали, хотя 1С у клиента тоже есть.
Интеграция оправдана в двух случаях: одни и те же данные вносятся дважды или без обмена не собирается нужная картина.
Здесь оба условия выполнялись. Приёмщик вводил бы информацию о машине сначала в одну систему, потом в другую. А уведомление слесарю о поступлении детали невозможно построить без данных складского учёта — они живут в 1С, и взять их больше неоткуда.
На мебельном производстве в 1С считали себестоимость изделия, и этой задаче обмен был не нужен: данные не дублировались и в другой системе не требовались. Интеграция добавила бы стоимость проекта и обязанность поддерживать обмен годами — без пользы.
Поэтому вопрос «нужно ли связывать с 1С» не имеет универсального ответа. Он решается разбором конкретных процессов, и иногда правильный ответ — не нужно.
Первичное обучение прошло, сотрудники работают в системе. Сейчас идёт этап, который многие подрядчики пропускают, — донастройка по живой работе.
Каждую неделю разбираем, что мешает: где сотрудникам неудобно, где система требует лишних действий, где процесс на практике идёт иначе, чем задумывалось. По итогам вносим правки. Именно на этом этапе система превращается из правильно настроенной в удобную, и без него внедрения чаще всего и не приживаются.
Когда данные накопятся и процесс устоится, соберём сводные показатели: поток обращений и конверсия в запись, загрузка постов, средний срок ремонта, структура простоев. Собирать дашборды раньше, чем данные станут достоверными, бессмысленно.
1С отвечает на вопрос «что мы сделали и сколько это стоило». Она не отвечает на вопросы «сколько людей к нам обратилось», «сколько из них доехало», «когда освободится пост» и «почему эта машина стоит третий день». Это не недостаток 1С, а её назначение: она учётная система, а не система управления обращениями и ресурсами. Заменять её не нужно, нужно закрыть то, что она не покрывает.
Нет, это и есть смысл интеграции. Заказ-наряд формируется в 1С автоматически из данных, которые уже введены при приёме машины, а обмен идёт онлайн в обе стороны. Если после внедрения сотрудники продолжают заполнять одно и то же в двух местах — интеграция сделана неправильно.
Каждый пост становится ресурсом с собственным расписанием, и занятость видна наглядно вместе со сроком освобождения. Приёмщик при записи клиента видит свободные окна и называет конкретное время. Дополнительный эффект: становится видна реальная загрузка сервиса — какие посты простаивают, а на какие очередь.
Через мобильное приложение: уведомление приходит на телефон и привязано к конкретному наряду. Заходить в портал и что-то искать не нужно, работать за компьютером тоже. Это принципиально — если сотруднику неудобно, он вернётся к привычному способу и снова пойдёт спрашивать лично.
Зависит от конфигурации, её доработок и того, какие данные нужно передавать. Типовая конфигурация без переделок связывается быстро. Сильно доработанная 1С требует предварительного разбора: что именно и в какую сторону должно передаваться. Начинать всегда стоит с минимального набора данных, а не пытаться синхронизировать всё сразу.
Да, логика одинаковая для любого ремонта с ограниченным числом рабочих мест: обращение, запись на свободный пост, приёмка, ожидание запчастей, работы, выдача. Так устроены легковые сервисы, шиномонтаж, ремонт спецтехники и оборудования. Отличается длительность работ и номенклатура деталей, состав этапов остаётся тем же.
Если 1С у вас работает, но вопросы про обращения, загрузку и простои остаются без ответа — разберём процесс и покажем, что можно закрыть, не трогая учёт. Встреча на 40 минут, без обязательств продолжать.