Мы предлагаем сравнивать готовую систему выездного сервиса и своё приложение на таком проверяемом примере. Ниже разберём четыре пути, матрицу отраслевых проверок и полную стоимость владения. Вы сможете подготовить одинаковые исходные данные для поставщиков, проверить результат в 1С и выбрать состав пилота до закупки. Правила ТО и сроки обслуживания возьмите из своих регламентов и договоров: от них зависит, подходит ли конкретное решение.
Как выбрать один из четырёх путей
Мы предлагаем начинать с готовой системы выездного сервиса, если её можно настроить под ваши обязательные правила. Доработка подходит, когда основа устраивает, а пробел ограничен конкретной функцией. Свой мобильный модуль имеет смысл, если офис уже работает в подходящей CRM или 1С. Отдельную систему стоит оценивать, когда критичные правила обслуживания и обмена не удаётся собрать на приемлемых условиях.
Чтобы различить эти варианты, попросите провести один ваш наряд от оборудования до учётного результата. В сравнении участвуют и инженер, и диспетчер, и сотрудник, который принимает акт и расход запчастей. Их действия покажут, сколько работы останется после внедрения.
| Путь | Когда подходит | Что подтвердить до покупки |
|---|---|---|
| Готовая платформа с настройкой | Паспорт, ТО, сроки, материалы и акт проходят проверку штатными средствами. | Нужные функции входят в выбранный тариф; роли, импорт и обмен доступны вашей команде. |
| Доработка платформы | Основной процесс подходит; нужно добавить определённое правило, форму или обмен. | Есть поддерживаемый способ расширения. Названы исполнитель, стоимость и ответственность после обновлений. |
| Мобильный модуль к текущей системе | Офисное ядро уже хранит оборудование, наряды и учёт. Инженеру нужен удобный рабочий интерфейс. | Ядро отдаёт нужные данные и принимает результат; понятны права, сервер обмена и поддержка обеих сторон. |
| Собственная система | Критичные правила, документы и интеграции требуют собственной модели процесса. | В смете есть мобильная часть, офис, сервер, миграция, интеграции, проверки и дальнейшая эксплуатация. |
Мы используем эту таблицу как порядок отбора. Провал обязательного требования останавливает вариант до выяснения способа решения: красивый календарь не компенсирует смешанную историю двух агрегатов или расход детали без связи с нарядом.
Что мы уже связали с 1С
В «Бакаеве» мы разработали мобильный магазин и админ-панель, помогли перенести локальную 1С в облако и настроили двусторонний API-обмен. Сервер синхронизации передаёт изменение фотографии товара из панели в 1С. Заказ через приложение отражается в остатках панели и учётной системы; изменения из 1С возвращаются к мобильной витрине.
Реальный проект 13FOX
«Бакаев»: приложение, панель и учёт
Команда магазина управляет каталогом в панели, связанной с 1С. Товары, остатки и изображения участвуют в обмене.
Этот опыт помогает нам разбирать направление обмена и его результат для сотрудников. В сервисной компании нужно дополнительно решить, где хранится история оборудования, кто подтверждает расход и какой документ ждёт бухгалтерия. Эти решения войдут в проверку вашего наряда.
Подготовьте наряд, который покажет ограничения
Возьмите завершённый выезд с обычной для вашей компании сложностью. Уберите персональные данные, сохраните связи: клиент и объект, единица оборудования, основание обслуживания, работы, детали, акт и итог в 1С. Для сравнения всем поставщикам нужен одинаковый исходный набор.
Допустим, на объекте стоят два одинаковых насоса. В выбранном наряде инженер обслуживает один из них, меняет уплотнение и согласует дополнительную работу. После визита офис должен найти расход, принять акт и увидеть следующую дату ТО именно этого агрегата. Такую демонстрацию мы сначала оформим как прототип и сверим с руководителем сервиса и инженером; перечень операций возьмём из вашего регламента.
К наряду приложите образец паспорта, форму акта, правило расчёта срока и пример нужного результата в 1С. Если обслуживание зависит от счётчика наработки, добавьте его показание. Без этих исходных данных поставщик покажет свой удобный сценарий, а отличия проявятся уже при внедрении.
Матрица проверки готовой системы и разработки
Для каждой строки запишите результат: «работает в выбранной конфигурации», «настраивается», «нужна доработка» или «не проверено». Рядом оставьте доказательство, ответственного и связанные расходы. Обязательные требования отметьте заранее: неопределённость по ним должна быть закрыта до закупки.
| Критерий | Что сделать на наряде | Что считать результатом |
|---|---|---|
| Паспорт оборудования | Найти агрегат по серийному номеру. Открыть модель, договор и историю. Показать второе такое же устройство. | Два агрегата различаются; работы и заменённые детали относятся к нужной единице. |
| Плановое ТО | Создать наряд по вашему правилу. Перенести визит и проверить следующую дату. Для ТО по наработке ввести показание счётчика. | Следующий цикл рассчитан по регламенту; видны основание, перенос и причина пропуска. |
| SLA по договору | Создать обращение вне часов обслуживания. Добавить ожидание запчасти или согласования. | Сроки реакции и решения рассчитаны по договору. Пауза имеет основание, автора и историю. |
| Запчасти и допработы | Выдать деталь инженеру, отметить фактический расход и возврат неиспользованного. Согласовать дополнительную работу. | Выдача, расход и возврат различаются. Сохранены номенклатура, количество, склад и связь с нарядом. Видны согласовавший допработу и её состав в акте. |
| Акт и подтверждение | Сформировать вашу форму с работами и материалами. Вернуть на исправление и повторно принять. | Офис и клиент получают согласованную версию; подтверждение относится к этой версии документа. |
| Обмен с 1С | Передать результат в тестовую базу. Потерять ответ после отправки и повторить операцию. | Наряд связан с нужным объектом в 1С; повтор обработан по согласованному правилу без второго расхода в этом тесте. |
| Роли и экспорт | Зайти инженером и диспетчером. Выгрузить наряд с актом, оборудованием и материалами. | Каждая роль видит разрешённые сведения; выгрузка сохраняет нужные связи и доступные вложения. |
Саму карту испытаний можно использовать для каждого из четырёх путей. Для готовой платформы вы проверяете доступную конфигурацию, для доработки добавляете подтверждение механизма расширения. В мобильном модуле и собственной системе эти строки станут критериями приёмки, которые мы согласуем до разработки.
На какие готовые функции можно опереться
Okdesk описывает цифровые паспорта оборудования, историю и повторяющиеся работы. Planado предлагает шаблоны нарядов и актов, обязательные поля и API. В 1С:ТОИР КОРП предусмотрены объекты ремонта, наработка и ремонтные циклы. Это отправные точки для проверки: состав лицензий, мобильных функций и интеграций нужно уточнить для выбранного решения. Возможности проверены 3 октября 2026 года.
Обратите внимание на смысл полей. Адрес объекта может объединять несколько агрегатов; паспорт нужен каждой обслуживаемой единице. Повторяющийся наряд по календарю требует отдельной проверки, если ваше ТО зависит от моточасов. В демонстрации попросите показать именно такое правило.
Согласуйте, что означают сроки и акт
SLA — обязательства по срокам обслуживания из договора. Разделите реакцию на обращение, прибытие и устранение, если договор задаёт их отдельно. Окно планового визита храните как самостоятельное правило. Например, ожидание детали может приостанавливать один срок и оставлять другой активным: система должна воспроизвести ваш порядок расчёта.
Форму акта проверьте с сотрудником, который принимает документы. Вид подтверждения клиента, требования к подписи и правила исправления согласуйте с заказчиком и профильным специалистом. Изображение подписи на экране само по себе не определяет юридический статус акта. Для конкретного оборудования регламент работ также задаёт ваша сервисная служба.
Проверьте, что именно получит 1С
Приложение сервисных инженеров с 1С нужно оценивать на уровне операции: какой справочник даёт оборудованию идентификатор, откуда загружается номенклатура и куда возвращаются работы и расход. Серийный номер помогает искать агрегат; для обмена мы отдельно согласуем устойчивый внутренний идентификатор, чтобы переезд оборудования не создал новую историю.
До оценки мы проверим конфигурацию и версию 1С, её размещение, доступные объекты, права и способ обмена. Например, официальная инструкция 1С:Фреш по OData описывает программное чтение и запись с настройкой доступных объектов. Возможность доступа ещё требует согласования бизнес-операции: какой документ создаётся, кто его проверяет и когда фиксируется расход.
Демонстрация двух состояний записи
Этот прототип показывает различие статусов на условном наряде. Он помогает согласовать подписи с инженером и офисом; в рабочем приложении состояния будут зависеть от фактических подтверждений сервера и 1С.
Сохранено на устройстве. Запись работ и расхода находится в локальном хранилище телефона. Офис ещё не подтвердил её получение; результат обмена с 1С неизвестен.
На пилоте мы дополнительно проверим третий этап: результат принят учётной системой по согласованному правилу. Если 1С недоступна, офис должен видеть ожидающую операцию и ответственного за неё. После потерянного ответа повтор нужно сверить с уже обработанной записью. Удобно искать все шаги по одному идентификатору наряда.
Заранее назовите основную систему для каждого поля. Например, 1С отвечает за номенклатуру и учётный расход, сервисная система за назначение и принятие акта. При одновременной правке офисом и инженером потребуется правило разбора конфликта. Подробный состав такого обмена мы рассматриваем в услуге API-интеграций.
Считайте стоимость на одном горизонте
TCO — общая стоимость владения за выбранный период. Сравнивайте варианты за один и тот же период, например три года, с одинаковым составом функций и числом инженеров, диспетчеров и других оплачиваемых ролей. Зафиксируйте также объём оборудования, нарядов и вложений: он влияет на перенос данных, хранение и нагрузку.
Запросите у каждого исполнителя две части сметы: запуск и работа системы после запуска. Каждую работу учитывайте один раз: разработку обмена при запуске, его сопровождение в регулярных расходах. Включённую в тариф поддержку повторно не прибавляйте. Затем добавьте затраты своей команды. Если сотрудник после каждого выезда вручную переносит расход в 1С, посчитайте наблюдённое время операции, реальное число нарядов и стоимость часа. Такой расчёт покажет цену оставшегося ручного шага.
| Расход | Что включить в сравнение |
|---|---|
| Запуск и перенос данных | Настройку или разработку, очистку паспортов и справочников, перенос истории и вложений, обучение, контрольный выезд. |
| Лицензии и инфраструктура | Нужные роли и функции, API, хранение файлов, серверы, используемое ПО, устройства и связь. Общие для вариантов расходы учитывать одинаково. |
| Интеграция и сопровождение | Обмен с вашей 1С, работу её специалиста, обновления, проверку совместимости доработок, наблюдение за сбоями и восстановление. |
| Работа команды | Администрирование, поддержку сотрудников, ручные переносы и исправления по вашим наблюдениям. |
| Изменения и выход | Новый тип оборудования или акт, изменение договора, экспорт связанной истории и перенос в другую систему. |
Стоимость доработки системы выездного обслуживания зависит и от поддержки после изменения. Попросите показать, как она переживёт обновление платформы и кто исправит обмен после обновления 1С. Для собственной системы также нужны ответственные за сервер, резервные копии, мобильные обновления и развитие. Владение кодом само по себе не оплачивает эту работу.
Итог сравнения: полная стоимость за период = запуск + регулярные платежи + сопровождение и изменения + работа вашей команды + выход из системы. Условия и неизвестные суммы держите отдельными строками; решение принимайте после проверки обязательных требований.
Зафиксируйте результат пилота до договора
Один наряд позволяет отсеять неподходящий вариант и определить, что проверять дальше. Для пилота подберите ещё исключения из вашего процесса: перенос ТО, недоступную деталь, исправление акта и повтор обмена. Мы предложим ожидаемый результат каждого испытания и согласуем его с тем, кто принимает работу.
Если готовая система проходит обязательные строки и её условия вас устраивают, можно двигаться к внедрению. Когда проверка выявила ограниченный пробел, оцените доработку или модуль. Если нужен собственный процесс, на странице приложения для сервисных инженеров мы описываем состав предлагаемого решения. Общие сценарии фото и работы без связи разобраны в статье о выездных сотрудниках.
Что уточнить перед сравнением
Можно ли сохранить текущую 1С и сделать только приложение?
Да, если она уже поддерживает нужный учёт и доступный способ обмена. Мы проверим, какие данные можно передать инженеру и какой результат база примет обратно. В состав модуля могут войти мобильный интерфейс, сервер и интеграция.
Как понять, что доработка готовой системы будет поддерживаться?
Попросите описать механизм расширения, его ограничения и проверку после обновлений. В предложении должны быть ответственный за доработку, порядок исправления и расходы на сопровождение.
Достаточно ли демонстрации одного наряда для покупки?
Это начало отбора. После него проверяют исключения, роли, перенос данных, работу без связи и восстановление обмена. Состав пилота зависит от ваших обязательных требований.
Покажите один наряд и форму акта
Оставьте контакт для обсуждения процесса выезда. После обращения покажите обезличенный наряд, акт, правило расхода запчастей и название конфигурации 1С. Мы разберём действия инженера и диспетчера, передачу результата в 1С и предложим состав приложения, интеграций и проверок для пилота.