Повтор после сбоя
Если ответ пропал, повторяем то же действие с прежним идентификатором и проверяем его результат. На приёмке проверяем, что согласованные повторы не создают второй расход детали или второй акт.
13FOX / мобильное рабочее место инженера
Разработка приложения для сервисных инженеров
Мы связываем наряд, оборудование, запчасти и акт в одном процессе выезда. Инженер фиксирует работу на объекте, диспетчер видит ход задания и получение результата.
Для сервисных компаний и служб технического обслуживания.
В Бакаеве мы связали мобильный магазин, админку и 1С. Показываем этот опыт на реальных экранах →
01 / от назначения до принятого акта
Один наряд.
Общая история выезда.
Когда фото и акт приходят в чат, диспетчеру приходится собирать итог вручную. Мы предлагаем связать каждое действие с нарядом и конкретной единицей оборудования: так следующий инженер видит, что уже делали на этом объекте.
- 01 / Диспетчер
Назначает выезд
Клиент, адрес, окно визита, инженер и оборудование. Для планового ТО добавляем ссылку на регламент.
- 02 / Система
Готовит задание
Загружает на устройство наряд, паспорт, нужную историю и чек-лист до зоны без связи.
- 03 / Инженер
Фиксирует работу
Сверяет серийный номер, добавляет фото, расход деталей и допработы. Заполняет акт и подтверждение клиента.
- 04 / Офис и клиент
Получают результат
После передачи пакета офис проверяет акт. Клиент получает согласованный документ; история оборудования пополняется.
Интерактивный прототип / вымышленные данные
Работа закончена.
Результат ещё на устройстве.
Наряд и вложения сохраняем локально. Состояние «получено офисом» показываем после подтверждения сервера о приёме полного пакета. Приёмку акта и передачу в 1С отмечаем отдельно.
Если связи нет, диспетчер видит последнюю полученную версию. Утрата устройства до синхронизации может привести к потере записей; срок хранения и порядок восстановления согласуем заранее.
Демонстрация меняет только подписи на странице. Здесь нет сохранения данных, отправки файлов или связи с офисом.
НАРЯД ДЕМО-024Плановое ТО
Приточная установка
- Паспорт и история
- Загружены до выезда
- Чек-лист
- Осмотр / замена фильтра
- Материалы
- Фильтр · 1 шт. · демо
- Вложения
- Фото и черновик акта
Сохранено на устройствеОфис: пакет ещё не получен
Фото, чек-лист и расход детали ждут связи. Наряд остаётся открытым для офисной приёмки.
Этот прототип нужно проверить с диспетчером и инженером на отраслевом интервью. Состав чек-листа и правила обслуживания определяет ваша сервисная команда.
02 / состав первой версии
Начинаем с одного
типа сервисного наряда.
Мы выбираем повторяющийся выезд и доводим его до приёмки. В первую версию предлагаем включить мобильное приложение, диспетчерский интерфейс, сервер и согласованный обмен. Платформы и парк устройств уточняем по условиям работы инженеров.
Что войдёт в рабочий процесс
- Наряд и роли
- Назначение инженера, статусы выезда и права диспетчера, исполнителя и руководителя. Каждый видит доступные ему объекты и действия.
- Оборудование
- Паспорт, серийный номер, история обслуживания и ближайшее ТО. Привязку к учёту проверяем на существующих идентификаторах.
- Результат работ
- Фото, чек-лист, фактический расход запчастей, допработы и акт. Перед списанием и дополнительным счётом задаём правило согласования.
- Работа без сети
- Предварительная загрузка, локальная запись и очередь передачи. Инженер видит состояние каждой записи и ошибку, которую нужно разобрать.
Для лифтовой сервисной компании
Лифтовой сервис: заявка, регламент и история оборудования
Мы предлагаем разработать приложение для обслуживания лифтов, в котором обращение диспетчера и плановая работа связаны с одним лифтом. Мастер получает наряд с нужной историей, руководитель эксплуатации видит результат и оставшиеся работы.
Начнём с карточки одного лифта и двух нарядов: планового и аварийного. Сопоставим их с вашим регламентом, ролями службы и учётом, затем предложим состав пилота.
Разобрать сервисный наряд
Пример связанной карточки
Следующий мастер видит, что осталось по этому лифту.
Один адрес может относиться к нескольким лифтам. Поэтому связываем наряд с идентификатором из вашего реестра и паспортом конкретного оборудования. В карточке сохраняем ссылку на применимый регламент и его версию, исполнителя, результат проверки и вложения.
Когда работа отложена из-за детали или доступа, сохраняем пункт, причину и ответственного за следующий шаг. Передача наряда другому мастеру остаётся в истории.
Данные в примере вымышлены. Кнопки показывают предлагаемые состояния карточки; они не сохраняют документы и не управляют оборудованием.
Лифт ДЕМО-Л01 / учебный объект
Карточка → наряд → результат
- Идентификатор / паспорт
- ДЕМО-Л01 / учебная карточка
- Применимый регламент
- Документ службы / демоверсия
- Наряд
- ДЕМО-П01 / плановая работа
- Исполнитель
- Мастер А / демонстрационная роль
- Подтверждение работ
- Запись мастера и фото: ожидают проверки
Один пункт отложен
Мастер указал причину: нет доступа. Диспетчер согласует повторный визит. Пункт остаётся открытым в истории лифта.
Как заявка становится сервисной записью
- 01 / ДиспетчерСвязывает обращение с лифтом
Выбирает оборудование, отмечает плановую работу или аварийное обращение и назначает мастера. Правила приоритета и эскалации берём из процесса вашей службы.
- 02 / МастерПолучает разрешённый состав работ
Видит наряд, применимый регламент и доступную историю. Записывает результат и материалы, прикрепляет фото. У каждого невыполненного пункта указывает причину.
- 03 / ПроверяющийПроверяет комплектность результата
Принимает запись либо возвращает конкретный пункт на уточнение. Получение файлов сервером отмечаем отдельно от проверки работ.
- 04 / Сервисная системаПополняет историю оборудования
Сохраняет связь лифта, наряда и подтверждения работ. В 1С передаёт согласованные данные; ошибку обмена оставляет видимой для ответственного.
Приложение ведёт сервисные записи. Решения о допустимых работах и эксплуатации принимает ответственный специалист в установленном порядке. Статус «проверено» в наряде не разрешает эксплуатацию лифта. Управление лифтовой автоматикой в этот проект не входит.
Что включим в пилот
Предлагаем проверить карточку одного лифта, плановый и аварийный наряд, роли диспетчера, мастера и проверяющего. Формы и состав работ берём из паспорта, документации изготовителя и принятых документов службы.
Для CRM и 1С сначала определим, где ведётся реестр лифтов, кто назначает наряды и кто подтверждает расход материалов. Проверим конфигурацию, версию, доступный интерфейс и права. Для каждого поля закрепим основную систему и направление обмена.
В Бакаеве мы связали мобильный магазин, админку и 1С через сервер синхронизации. Это опыт обмена бизнес-данными, на который опираемся при проектировании. Лифтовой сценарий предстоит разработать для вашей службы. Посмотреть кейс Бакаева →
Как примем результат
- История показывает конкретный лифт, версию регламента, исполнителя и подтверждение работ.
- После отправки результата мастером отложенный пункт остаётся открытым; смена мастера видна в истории.
- Мастер видит только разрешённые объекты. Аварийное обращение попадает ответственному по согласованному правилу.
- При неполной передаче фото результат не отмечается как полностью полученный. После восстановления связи сверяем комплект.
- Повтор передачи в согласованных сценариях не создаёт вторую запись в учёте. Ошибка и её исправление доступны для проверки.
Можно ли объединить плановое ТО и заявки диспетчера?
Предлагаем объединить их вокруг карточки лифта, сохранив разные основания наряда, приоритеты и состав работ. Плановые даты можно получать из вашей системы. Собственный планировщик, перенос архивной истории и подключение диспетчерского оборудования оцениваем отдельно.
Как будет работать приложение без связи?
В пилоте проверим предварительную загрузку наряда и локальное сохранение записей мастера. На устройстве покажем, какие данные ждут передачи. Офис видит последнюю полученную версию; утрата устройства до передачи может привести к потере записей. Объём хранения, новые аварийные назначения и порядок разрешения конфликтов согласуем заранее.
Заменит ли карточка обязательные документы лифта?
Статус документов и способ подтверждения согласуем по применимым требованиям, договору и формам службы. В пилоте карточка связывает паспорт, наряд и сервисную запись. Автоматическую замену обязательных журналов, паспорта или документов о допуске к эксплуатации мы не обещаем.
Разберём один сервисный цикл
Пришлите карточку лифта, два обезличенных наряда и роли службы. Разберём один сервисный цикл и подготовим карту данных, полномочий и состава пилота.
Оставьте удобный контакт. Документы можно передать после первого разговора; для разбора также понадобятся применимый регламент и сведения о вашей 1С.
03 / запчасти и учёт
Расход детали должен
дойти до учёта.
В начале мы выясняем, где хранится оборудование, кто назначает наряд и какая система утверждает расход. Для каждого поля задаём основной источник и правила обновления.
Устройство передаёт операции нашему серверу приложения. Сервер хранит результат, подтверждает приём и выполняет согласованный обмен с 1С. Доступ к базе, способ подключения и окружение выбираем после проверки конфигурации и прав.
Как мы проектируем API-интеграции →01 / 1С или сервисная системаОборудование, задания, номенклатура
В приложение: согласованные данные и дата их обновления.
02 / сервер приложенияПроверка, журнал, подтверждение приёма
В учёт: результат выезда, расход и акт в согласованном составе.
03 / устройство инженераНаряд и локальная очередь
Работа с заранее загруженными данными; передача при доступной связи.
Изменение в двух местах
Диспетчер отменил выезд, пока инженер без сети заполнил акт. Мы сохраняем обе версии и направляем конфликт ответственному. Автоматическое списание до решения блокируем по согласованному правилу.
Ошибка обмена с 1С
Полученный офисом пакет может ждать передачи в учёт. Показываем отдельный статус, причину и операцию в журнале. После исправления сверяем наряд, материал и итоговый документ по обе стороны обмена.
04 / наш опыт связанных систем
Мобильный клиент,
админка и 1С: Бакаев.
В мобильном магазине Бакаева мы помогли перенести локальную 1С в облако и настроили двусторонний обмен через сервер синхронизации. Команда ведёт товары и заказы в админ-панели, покупатель видит каталог и состояние заказа.
Как данные проходят
между системами
Сотрудник меняет фотографию товара в админке. Сервер синхронизации передаёт изменение в 1С. Обновления со стороны 1С проходят обратный путь к приложению.
Покупатель оформляет заказ с телефона. Остаток уменьшается в админ-панели и в 1С. В карточке заказа администратору доступны статус, сумма и назначенный курьер.
Бакаев работает в продуктовой торговле и доставке. Наряды сервисных инженеров, офлайн, акты и учёт запчастей мы предлагаем спроектировать и проверить для вашей службы.
Открыть кейс и экраны Бакаева →Смежный опыт
В Frost Mining мы разработали магазин термопрокладок и другой продукции для охлаждения техники с админкой и учётом остатков. Мы связали заказы магазина с CRM. Этот опыт работы с техническим ассортиментом и остатками применяем при проектировании обмена. Правила списания запчастей согласуем с вашей сервисной службой.
Кейс Frost Mining →05 / от разбора до контрольного выезда
Сначала согласуем сценарий.
По нему составим оценку.
Покажите один наряд, форму акта и процесс выезда. Мы опишем шаги инженера и диспетчера, определим данные для обмена с учётом и предложим состав приложения и интеграций.
Что понадобится для разбора
- Обезличенный наряд, паспорт оборудования и пример истории обслуживания.
- Форма акта, чек-лист, правило согласования запчастей и допработ.
- Название и версия 1С / CRM, способ размещения базы, парк устройств и условия связи.
Проверим, можно ли выполнить весь выезд по этому наряду в готовой платформе или в вашей текущей системе. Если достаточно настройки либо одного модуля, включим этот вариант в обсуждение.
Сравнить готовую систему и своё приложение →Что покажем в оценке
Состав первой версии, роли, движение данных, список интеграций и проверки на устройствах. Отдельно обозначим подготовку учёта, миграцию, запуск и поддержку.
Один тип оборудования и готовый API требуют другого объёма работ, чем несколько регламентов, перенос бумажной истории и доработка 1С. Стоимость и срок рассчитываем после уточнения этих условий.
Предусмотрим расходы на инфраструктуру, лицензии внешних систем и сопровождение обмена. Их состав зависит от выбранной архитектуры.
Критерии приёмки
Проверяем целый выезд
на рабочих устройствах.
Обсуждаем процесс с инженером и диспетчером, проверяем его в прототипе и разрабатываем согласованные функции. Перед запуском проводим контрольный выезд с инженером и диспетчером, фиксируем фактический результат и ответственного за приёмку.
- Назначение и права. Инженер получает свой наряд; чужой объект недоступен. Паспорт соответствует серийному номеру.
- Без связи и после перезапуска. Чек-лист, фото и материалы остаются на устройстве; приложение показывает ожидающие передачи записи.
- Передача и повтор. Офис получает полный пакет. Повтор в согласованных сценариях не создаёт второй акт или расход.
- Конфликт и учёт. Отмена выезда из офиса требует решения. После исправления ошибки проверяем итог в 1С и историю оборудования.
До начала проекта
Вопросы руководителя
сервисной службы.
Можно ли оставить нашу 1С и диспетчерскую систему?
Да, если у них есть подходящий способ обмена и необходимые права. Мы проверяем конфигурацию, версию, размещение базы и доступные операции на тестовом примере. Иногда достаточно мобильного модуля рядом с существующей системой.
Что инженер сможет делать без связи?
Открывать заранее загруженные задания, паспорт и согласованную историю, заполнять чек-лист, сохранять фото, материалы и акт. Свежие назначения, текущие остатки и подтверждение офисом требуют связи. Объём загрузки и срок хранения согласуем до разработки.
Будет ли подпись клиента в приложении заменять бумажный акт?
Способ подтверждения выбираем с заказчиком. Отметка или подпись на экране может входить в согласованный процесс, но юридический статус документа зависит от договора, вида подписи и требований к вашим работам. ЭДО и электронную подпись оцениваем отдельно.
Как учитываются плановое ТО и сроки по договору?
Привязываем обслуживание к конкретному оборудованию и согласованному регламенту. Правила периодичности, сроки реакции и исключения даёт сервисная команда. В первой версии можем получать дату ТО из вашей системы; собственный планировщик оцениваем отдельным блоком.
От чего зависят стоимость и срок разработки?
От количества типов нарядов и оборудования, формы акта, ролей, платформ, объёма офлайн-данных и готовности интеграций. В оценке отдельно показываем разработку, подготовку учёта, испытания на устройствах, запуск и поддержку. Для расчёта нужен пример вашего процесса.
Следующий шаг
Разберём ваш наряд
от назначения до акта.
Укажите удобный способ связи для первого разговора. После него можно передать обезличенный пример: мы предложим состав приложения, обмена и контрольного выезда.
Работаем с компаниями по России, в том числе из Москвы и Санкт-Петербурга.
Для общего процесса полевой работы: приложение для выездных сотрудников.