Моя основная работа на распределительном центре — выдача и приём ТСД. Формально автоматизация этого процесса в мои обязанности не входила. Но когда я увидел, как устроена выдача оборудования, решил попробовать самостоятельно изменить процесс — получить практический опыт в автоматизации и оптимизации складских операций.

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

Ссылка на исходный код

Как изначально работала выдача

На складе использовались бумажные карточки сотрудников, и логика была такой:

1. сотрудник даёт карточку диспетчеру

2. карточка помещается в ячейку, а из этой же ячейки сотруднику даётся ТСД

3. в конце смены сотрудник возвращает ТСД, и диспетчер возвращает ему карточку

То есть карточка фактически использовалась как идентификатор сотрудника и одновременно как маркер того, что ТСД находится у него.На практике система работала не так идеально. Около 30% сотрудников периодически приходили без карточек. Причины были самые разные:

• теряли карту

• забывали дома

• случайно стирали её вместе с одеждой

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

Предвестники приложения

Я ввёл бумажные талоны. Сотруднику без карточки нужно было написать фамилию на бумажке и передать её диспетчеру.

Также то, что обычно давалось на доверии, даже не хранилось в ячейках. Часть оборудования просто находилась в коробке.

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

Почему карточки всё равно не прижились

Разумеется, бумажки — это временная мера, несолидно для крупного РЦ получать оборудование по бумажкам. Поэтому я задумался о том, чтобы каждому напечатать карточку, даже если нет закреплённого терминала. Универсальная карточка, а вот какой терминал выдадут — это лотерея. Закреплённый терминал — это, разумеется, плюс к скорости работы:

• у ТСД нужные настройки приложения

• настроенное крепление

• уже подключённое сканер‑кольцо

Когда ТСД выдавалось из общих, нужно подобрать крепление под свою руку, подключить сканер‑кольцо по Bluetooth, настроить громкость голосового отборщика и так далее

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

В результате аутстаффер приходил с карточкой, но каждый раз мог получить разный терминал. И возникал логичный вопрос:
«Зачем мне оставлять тебе карточку, если в следующий раз ты всё равно выдашь мне другой ТСД?»

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

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

Возврат карточек — проблема

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

Строим приложение

У каждого сотрудника уже есть пропуск СКУД. Он нужен для прохода через турникет, поэтому сотрудник и так носит его с собой. Я решил использовать его как идентификатор при выдаче оборудования. Для эксперимента приобрёл RFID‑считыватель и NumPad‑клавиатуру и начал создавать приложение.

Для приложения не требовалась сложная информационная система. Самый простой вариант:

• Python (Tkinter, Pandas)

• RFID‑считыватель

• сканер штрихкодов

• клавиатура NumPad

Все устройства должны были работать как HID‑устройства. Для программы это принципиально удобно: RFID‑считыватель, сканер штрихкодов и обычная клавиатура фактически передают данные в одну строку ввода. Поэтому не пришлось разрабатывать отдельные драйверы или сложный интерфейс взаимодействия с каждым устройством. Но была особенность: все значения со всех трёх устройств вводились в одно поле — код сотрудника, номер ячейки, номер ТСД, сканера‑кольца, мобильного принтера, планшета и так далее

Даже если у меня нет в базе кода сотрудника, программа должна всё равно понимать, что сотрудник приложил пропуск. Поэтому я решил использовать длину текста как признак. Код пропуска обычно содержит 7–10 цифр, а номер ячейки — не более трёх цифр (до 600). Если вводилось значение длиннее 6 символов — это код сотрудника. Фактическое количество ячеек было около 340, но диапазон я оставил с запасом.

В первой версии программы я столкнулся с ещё одной проблемой. Я ещё не успевал закончить выдачу одному сотруднику, как следующий уже прикладывал пропуск. Поэтому я разделил программу на сессии. После того как человек приложил пропуск, вносить можно только диапазоны ячеек и номера терминалов. Все остальные значения (например, код другого сотрудника) игнорировались. Для завершения сессии нужно было внести значение 0 (ноль).

Также одной из проблем было то, что код сотрудника 0001234567 и 1234567 — это два разных значения. Поэтому я сделал обязательное преобразование всех числовых значений в числа, чтобы таких коллизий не возникало.

В итоге логика получилась такая:
идентификация → начало сессии → выдача оборудования → завершение сессии.

Это особенно важно, когда перед диспетчером одновременно находится несколько человек.

База сотрудников

База сотрудников у меня уже частично существовала. Ранее я самостоятельно создавал карточки и хранил информацию о сотруднике, его имени, фотографии и закреплённой ячейке. Оставалось добавить идентификатор СКУД. После этого сотрудник стал появляться на экране, стоило ему приложить пропуск. Это давало дополнительный уровень контроля: перед выдачей оборудования диспетчер видел, кому именно оно сейчас выдаётся.

Обработка логов

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

1. идентификатор СКУД сотрудника;

2. ФИО в момент выдачи (чтобы знать, что в момент выдачи сотрудник видел имя на экране);

3. время начала сессии;

4. время окончания сессии;

5. список всего выданного оборудования (да, номера ячеек, ТСД и так далее — просто списком через запятую).

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

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

приложение → простой лог → обработчик → отчёт.

Для MVP этого было достаточно.

Нумерация оборудования

Отдельная проблема возникла с номерами самих ТСД. Исторически номер ТСД был связан с номером его ячейки. Но оборудование постепенно ломалось, списывалось, заменялось другими моделями — и получился бардак. Путались даже люди, когда на ТСД было написано 36, и ты не понимаешь: это номер ячейки, куда его класть, или номер ТСД. Идеально, чтобы все номера оборудования были четырёхзначными, чтобы избежать пересечений. Ставить номер ячейки и номер терминалов в одном диапазоне — ошибочная идея. Я решил проблему просто, добавив префикс:

125 (номер ТСД) + 880 000 (префикс) → 880 125

В результате диапазон от 880 000 до 889 999 зарезервирован под идентификаторы ТСД.

Нумерация сканер‑колец

Исторически сложилось, что на складе у сканер‑колец в качестве номера используется его Bluetooth‑имя. Bluetooth‑имя — это окончание серийного номера, потому что все их подключают через Bluetooth, и оно очень важно. У Urovo R70 всё было просто — 6 цифр от 100 000 до 400000. Со сканер‑кольцами Meferi MS300 было чуть сложнее. Имя представляло собой HEX‑значение: цифры + символы от A до F.

Здесь проявилась проблема HID‑ввода. Дело в том, что HID — это эмуляция клавиатуры, и если в QR‑коде записано значение C0BBD7, то при другой раскладке клавиатуры часть букв может интерпретироваться как «с0иив7». Поэтому в приложении по обработке логов пришлось прописать преобразование HEX‑символов в нормализованное значение.

Подготовка инфраструктуры

Параллельно я начал готовить физическую инфраструктуру под автоматизацию.

Штрихкоды ячеек

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

QR‑коды ТСД

Отдельно я сделал небольшой скрипт для генерации QR‑кодов оборудования. Чтобы не делать сотню QR‑кодов вручную, скрипт берёт из Excel все номера, сам подставляет необходимый нам префикс и выдаёт.pdf‑файл под печать. QR‑коды на ТСД и сканер‑кольцах нужны в тех случаях, когда человек берёт из ячейки только часть оборудования: либо одно из двух ТСД (например, у кладовщиков), либо только сканер‑кольцо или ТСД (у отборщиков).

То есть вместо привязки только к ячейке система могла точно фиксировать, какой физический терминал был выдан.

Сканер‑кольцо диспетчера

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

Чтобы освободить руки диспетчера, сканер‑кольцо планировалось использовать постоянно. Для его подключения к рабочему месту был установлен Bluetooth‑модуль.

На этом этапе физическая инфраструктура и программная часть MVP были практически готовы. Приложение использовалось мной и моими коллегами. Причём как пользоваться приложением, смог понять даже коллега, который не дружит с компьютерами, а это означает, что в целом оно может внедряться. Но использование проводного сканера тормозило всё — мы использовали приложение только для контроля выдачи мобильных принтеров, планшетов, а также аутстафферам и водителям погрузчиков (карщикам). Грубо говоря, мы закрывали только те самые 30%. В среднем это всего около 30–35 операций, от 30 секунд до 1 минуты на выдачу. Медленно, но эксперимент оказался успешным, потому что показал: программа работает, и нужно нарастить скорость. Для полноценного использования нужен Bluetooth‑сканер‑кольцо, чтобы руки были свободны и можно было быстро сканировать выдаваемое оборудование. Много времени уходило, чтобы достать USB‑сканер или набрать номер на numpad‑клавиатуре. Со сканер‑кольцом скорость выдачи составила бы около 5 секунд: можно заранее сложить оборудование в коробку и сканировать QR‑коды подряд, не бегая между ячейками.

Почему MVP не удалось внедрить

Но, увы, подключение Bluetooth‑устройств на корпоративных рабочих станциях не соответствовало требованиям информационной безопасности компании. Я около месяца обсуждал возможность использования Bluetooth‑сканер‑кольца с ответственными подразделениями. В итоге разрешение получено не было. Без него проект терял смысл, потому что прироста в скорости выдачи нет, а значит, и экономический смысл пропадает. Поэтому готовый MVP пришлось разобрать.

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