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