Как создать мобильное приложение для простых снимков остатков

Что значит «снимок остатков» и зачем он нужен

«Снимок остатков» — это быстрый зафиксированный факт о товаре в конкретном месте и времени. В мобильном приложении для инвентаризации он обычно состоит из трёх частей: фото, количественное значение (штуки/коробки/кг) и контекст — где это было, кто считал, когда, при каких условиях.

Важно: снимок не пытается «пересчитать весь склад». Он помогает быстро ответить на прикладной вопрос: что реально стоит на полке/в ячейке прямо сейчас.

Какие задачи решает

Снимки остатков товара закрывают несколько типовых сценариев без тяжёлого внедрения:

• Быстрый контроль: проверка топ‑позиции, витрины, конкретной зоны или поставки.
• Аудит и сверка: сравнение с учётом в Excel/1С/ERP, поиск расхождений.
• Приёмка: подтверждение количества и состояния товара «на входе» с доказательством в виде фото.
• Выездные проверки: когда команда работает в полях и нужна инвентаризация со смартфона.

Чем отличается от WMS/ERP — и когда этого достаточно

Полноценная WMS/ERP управляет движением товара: приходами, отгрузками, перемещениями, сериями/партиями, правилами размещения, заданиями персоналу. Снимок же — это точечное измерение, не претендующее на «единую правду» о запасах.

Снимков достаточно, если вам нужен MVP для складского учета: быстро собирать данные, прикладывать фото, а затем выгружать результаты (например, экспорт в CSV) и принимать решения. Это часто работает лучше, чем пытаться сразу автоматизировать всё.

Кому подходит

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

Формулируем сценарии и требования без лишней сложности

У «снимков остатков» есть соблазн превратиться в большой проект: справочники, учет партий, интеграции, роли, отчеты. Чтобы MVP действительно заработал, начните не с функций, а с конкретных ситуаций, в которых человек достает телефон и что-то фиксирует.

2–4 сценария, которые покрывают 80% пользы

Выберите несколько самых частых и понятных процессов — это станет основой экранов, полей и логики:

• Обход полок/склада: сотрудник идет по маршруту и быстро фиксирует «что и сколько есть» в каждой зоне.
• Приемка поставки: нужно сверить ожидание с фактом и оставить комментарии по расхождениям.
• Контроль витрины/мерчандайзинг: важно наличие, выкладка, иногда — фото как доказательство.
• (Опционально) Точечная проверка: руководитель или супервайзер делает выборочный контроль нескольких позиций.

Сразу договоритесь: снимок — это «быстрая фиксация текущего состояния», а не полный бухгалтерский учет.

Единица учета: что именно мы считаем

Определите минимальный уровень детализации, без которого снимок теряет смысл:

• SKU (товарная позиция) — базовый вариант для MVP.
• Место хранения (склад → зона → стеллаж/полка) — если важно понимать «где лежит».
• Категория — если ассортимент большой и нужен быстрый фильтр.
• Партия/срок годности — добавляйте только если это критично (например, продукты или фарма). Иначе усложните ввод и замедлите обход.

Хорошая проверка: «Сможем ли мы принимать решения, если будем знать только SKU + количество + место?» Если да — начните с этого.

Что фиксируем в момент снимка

Состав полей должен поддерживать скорость и качество:

• Количество (число или «нет в наличии»).
• Фото (по необходимости: витрина, проблемная позиция, расхождения).
• Комментарий (свободный текст или быстрые шаблоны: «повреждено», «не найдено», «замена»).
• Время (автоматически).
• Геометка — только если реально помогает (например, выездная торговая точка) и есть согласование по политике персональных данных.

Требования к скорости: считаем секунды

Скорость — это не «хотелка», а измеримый критерий MVP. Зафиксируйте ориентиры:

• 5–10 секунд на позицию при сканировании штрихкода и вводе количества.
• 30–60 секунд на полку/небольшую зону при групповом вводе или работе по списку.

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

Модель данных: что хранить, чтобы было полезно

Чтобы «снимок остатков» превращался в управленческое решение, данные должны быть достаточно структурированными — но не перегруженными. Хорошая модель для MVP отвечает на два вопроса: где считали и что/сколько нашли, плюс кто это сделал и в каком состоянии находится результат.

Роли и доступы

На старте достаточно трех ролей:

• Кладовщик/мерчендайзер — создает снимки, заполняет позиции, прикладывает фото, отправляет.
• Менеджер — просматривает, принимает/отклоняет, оставляет комментарии.
• Администратор — управляет справочниками (товары, локации), пользователями и правами.

Роль лучше хранить как поле users.role (или таблицу user_roles, если позже понадобятся расширения).

Основные сущности

Минимальный набор объектов:

• Товары (products): id, наименование, SKU/артикул, штрихкоды (лучше отдельной таблицей product_barcodes), единица учета.
• Локации (locations): склад/магазин/точка, зона, стеллаж/полка (можно иерархией parent_id).
• Снимки (snapshots): id, location_id, автор (created_by), время, статус, комментарий.
• Позиции снимка (snapshot_items): snapshot_id, product_id, количество, признак «нет в наличии», заметка; при необходимости — тип ввода («упаковка/штуки»).
• Задания (tasks): для плановых обходов — кому назначено, дедлайн, список локаций.
• Пользователи (users): контакты, роль, активность.

Связи и варианты учета

Снимок всегда привязан к локации и либо:

• к набору товаров (классический вариант: список позиций),
• либо к полке целиком (упрощенный вариант: один снимок + фото + комментарий, а позиции можно заполнять выборочно).

Это удобно реализовать флагом snapshots.mode = items | shelf.

Статусы и контроль изменений

Минимальные статусы: черновик → отправлено → принято/отклонено. Полезно добавить:

• submitted_at, reviewed_at, reviewed_by
• причину отклонения (поле review_comment)

Для качества данных в MVP достаточно хранить историю правок на уровне «кто и когда изменил» (updated_at, updated_by) и не усложнять полноценным аудит‑логом.

UX-поток: как пользователь делает снимок за 30–60 секунд

Цель UX для «снимков остатков» — снять нагрузку с пользователя: минимум полей, максимум подсказок и повторного использования данных. Если сотрудник может пройти полку за минуту, приложение будут реально использовать.

Два подхода к снимку

1) «Снимок полки»: одно фото полки + короткий список (например, 3–10 позиций с количеством) и метки (локация, полка, дата).

2) «Снимок товара»: отдельная карточка на SKU, где фото и количество привязаны к конкретному товару.

Для MVP чаще выигрывает «снимок полки»: он быстрее, терпим к неполному каталогу и подходит для «быстрого обхода». Компромисс — ниже точность по SKU и сложнее последующий разбор, если фото плохое. «Снимок товара» точнее и лучше для учета, но медленнее и требует надежной идентификации (штрихкод/каталог).

Навигация: локация → полка → снимок

Сделайте путь линейным и очевидным:

1. Пользователь выбирает локацию (магазин/склад/зона).
2. Выбирает полку/стеллаж (можно из списка или по QR‑коду на месте).
3. Нажимает «Сделать снимок» → камера → подтверждение → быстрый ввод количества/заметок.

Важно, чтобы возврат на уровень выше не сбрасывал уже введенные данные.

Подсказки и автозаполнение

Чтобы уложиться в 30–60 секунд, добавьте «умные костыли»:

• Шаблоны полок: заранее заданный набор товаров/категорий, который подставляется в список.
• Последние значения: показывайте прошлые количества по этой полке и позволяйте одним тапом «как было» с правкой.
• Автозаполнение: предлагайте товары по частоте на этой локации, подставляйте единицы измерения, сохраняйте комментарии‑шаблоны (например, «нет ценника», «перестановка»).

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

Ключевые экраны приложения и минимальные элементы UI

Чтобы «снимок остатков» делался действительно за минуту, интерфейс должен быть предсказуемым и «без выбора ради выбора». Минимальный набор экранов — это не «бедный» продукт, а способ снизить ошибки и ускорить обход.

1) Вход и выбор локации/задания

Пользователь должен попасть в работу за 2–3 касания. На старте достаточно:

• экран входа (номер/почта + код или пароль);
• выбор локации (склад, магазин, зона) или задания (сегодняшний обход);
• короткая подсказка: что именно нужно считать (например, «полка А3»).

Хорошая практика — показывать, что уже сделано: «12 из 40 позиций» и время последней синхронизации. Это мотивирует и помогает руководителю понимать прогресс без лишних звонков.

2) Камера: кадрирование, вспышка, серийная съемка, черновики

Экран камеры — главный рабочий. Здесь важны простые элементы:

• понятная рамка кадрирования (чтобы помещался ценник/этикетка или короб);
• кнопка вспышки и автофокус по тапу;
• серийная съемка (или «сделать 3 фото подряд»), если нужно снять полку целиком;
• сохранение черновика, если пользователь отвлекся или пропал сигнал.

Не перегружайте: фильтры, редактирование, «украшательства» обычно только замедляют. Достаточно предпросмотра и возможности переснять.

3) Ввод количества: быстрые кнопки, шаг, «0/нет в наличии», заметка

После фото — сразу количество. Лучший вариант: крупные кнопки и минимум ручного ввода.

• «+1 / +5 / +10» (настраиваемый шаг);
• «0 / нет в наличии» отдельной кнопкой;
• поле заметки (коротко: «упаковка порвана», «на верхней полке»).

Цель — чтобы даже в перчатках можно было быстро отметить остаток.

4) Проверка перед отправкой

Перед отправкой показывайте короткий чек‑лист: фото есть, локация выбрана, количество заполнено. Если чего-то не хватает — предупреждение и подсказка, как исправить.

На этом же экране полезны предпросмотр и подтверждение: «Отправить 8 снимков». Так пользователь уверен, что ничего не потерял, а качество данных не страдает.

Идентификация товара: штрихкод, поиск и каталог

Чтобы «снимок остатков» был полезен, приложение должно быстро и однозначно понимать, какой товар вы считаете. На практике работают три способа: штрихкод, поиск и каталог. В MVP достаточно поддержать все три, но сделать их простыми и без лишних шагов.

Сканирование штрихкодов: когда ускоряет, а когда мешает

Сканер — самый быстрый путь, если товары промаркированы и штрихкоды читаются. Он особенно хорош для однотипных полок, коробов и стандартной упаковки.

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

• штрихкод грязный, бликует или мятый — пользователь тратит время на «поймать фокус»;
• на товаре несколько кодов (производитель/поставщик) — растут ошибки;
• считаете не упаковки, а «насыпью/россыпью» (кабель, метизы) — проще выбрать позицию и ввести количество.

Правило для UX: после 1–2 неудачных попыток сканирования показывайте явную кнопку «Перейти к поиску» и не заставляйте пользователя «дожимать» камеру.

Поиск товара: по названию, артикулу, внутреннему коду

Поиск должен быть доступен всегда — как резервный путь. Минимально полезно:

• поиск по названию (с учетом частичных совпадений);
• по артикулу и внутреннему коду (точные совпадения + быстрые подсказки);
• недавние товары (последние 10–20 позиций) для повторяющихся обходов.

Хороший прием для скорости: показывайте в результатах не только название, но и 1–2 ключевых атрибута (упаковка/единица, бренд, фото‑миниатюра), чтобы не путать похожие позиции.

Импорт каталога товаров: CSV/таблица, ручное добавление для MVP

Для работающего MVP достаточно импорта каталога из CSV/таблицы. Обязательные поля: ID (внутренний), название, штрихкод (опционально), единица учета. Остальное (категории, цены, поставщики) можно оставить на потом.

Параллельно добавьте ручное создание товара «в один экран» — это спасает, когда каталог неполный.

Обработка неизвестного товара: «создать черновик» или «пометить»

Если товар не найден (по штрихкоду или поиском), важно не останавливать обход. Два понятных сценария:

1. Создать черновик: пользователь вводит название/фото/примерный код и количество, а ответственный позже сопоставляет с каталогом.

2. Пометить как неизвестный: фиксируется фото + количество + комментарий, без создания новой карточки.

Оба варианта сохраняют скорость и повышают качество данных: лучше собрать «неизвестное» отдельным списком, чем потерять позицию из-за неудобного интерфейса.

Офлайн-режим и синхронизация без потери данных

Офлайн — не «приятная опция», а базовая необходимость: подвалы, склады с экранирующими стенами, торговые точки за городом, выездные пересчеты. Если приложение «зависает» без сети, пользователи возвращаются к бумаге.

Зачем нужен офлайн

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

Локальное сохранение: очередь и статусы

Сразу после сохранения «снимок» должен попадать в локальную очередь на устройстве. В интерфейсе достаточно трех понятных статусов:

• Сохранено на устройстве (еще не отправлено)
• Отправляется (идет загрузка)
• Отправлено / Ошибка (нужно повторить)

Важно: пользователь должен видеть, сколько записей «ждут сеть», и иметь кнопку «Синхронизировать сейчас». Это снижает тревожность и количество обращений в поддержку.

Конфликты и дубли: правила заранее

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

Рабочий минимум для MVP:

• Каждой записи присваивать уникальный идентификатор (UUID) на устройстве и отправлять его на сервер.
• Сервер обрабатывает повторную отправку как идемпотентную: если UUID уже есть — просто возвращает «ок» без создания дубля.
• Для повторных снимков по одному товару в рамках одной сессии выбрать понятное правило: «последний снимок побеждает» или хранить все версии с отметкой времени (второе полезнее для контроля).

Фото: лимиты и экономия трафика

Фото быстро «съедают» интернет. Установите ограничения: например, максимум 1–3 фото на позицию, сжатие до разумного качества и загрузка только по Wi‑Fi (настраиваемый переключатель). На слабой сети сначала отправляйте текстовые данные, а фото — в фоне.

Хороший офлайн делает приложение надежным: пользователи уверены, что данные не пропадут, даже если связь появится только вечером.

Фото и файлы: хранение, качество и управление

Фото — самый быстрый способ зафиксировать реальное состояние полки или ячейки. Но если хранить их «как получится», MVP быстро превратится в хаос: растут затраты, сложно искать нужное, появляются риски утечек и случайных удалений.

Где хранить фото

Практичный вариант для MVP — объектное хранилище (S3‑совместимое) или файловый сервер.

• Объектное хранилище лучше масштабируется и проще раздаёт файлы через подписанные ссылки.
• Файловый сервер проще в небольшой инфраструктуре, но сложнее с резервными копиями и доступом из разных зон.

В базе данных не храните сами картинки. Храните ссылку + метаданные: id снимка остатков, кто загрузил, время, место/точка, размер, тип, хэш (для дедупликации), статус (черновик/подтверждено).

Сжатие и качество: баланс читаемости и веса

Цель фото — чтобы можно было понять контекст и при необходимости приблизить важное (ценник, маркировку, проблемную зону).

Рекомендации для мобильного потока:

• Делайте две версии: превью (быстро грузится) и оригинал/«почти оригинал».
• Сжимайте на устройстве до разумного размера (например, 1600–2048 px по длинной стороне) и сохраняйте EXIF только если он реально нужен.
• Для проблемных мест добавьте переключатель «высокое качество» — но по умолчанию используйте экономный режим.

Сроки хранения и архивирование

Срок хранения стоит сделать настраиваемым: например, 30/90/365 дней. Старые фото можно:

• переводить в «архив» (дешёвое хранение),
• удалять по политике, оставляя только отчётные данные.

Важно: политика хранения должна быть понятной в настройках и в /privacy (если у вас есть раздел политики в приложении).

Права доступа и защита от удаления

Фото часто содержат коммерчески чувствительную информацию. Минимум для MVP:

• Доступ по ролям: просмотр/загрузка/удаление.
• Удаление только через «корзину» с восстановлением (например, 7 дней) и логированием: кто и что удалил.
• Ссылки на скачивание — короткоживущие (подписанные), без публичных URL.

Бэкенд и интеграции: что нужно для работающего MVP

Чтобы снимки остатков не превращались в «фотографии ради фотографий», MVP должен уметь надежно принять данные, сохранить их и показать результат тем, кто принимает решения. Серверная часть может быть минимальной — главное, чтобы она закрывала базовые сценарии.

Минимальная серверная часть

В MVP обычно хватает трех сущностей и простого API:

• Пользователи и доступы: вход (по номеру/почте/кодам), роли «сотрудник» и «менеджер», привязка к точке/складу.
• Снимки: заголовок (точка, дата/время, автор), строки товаров (товар, количество, комментарий), статус (черновик/отправлен/принят).
• Каталог: карточка товара (название, артикул, штрихкод, единица измерения). Даже если каталог небольшой, лучше хранить его отдельно, чтобы снимки были сопоставимыми.

Важно предусмотреть идемпотентность отправки: если связь «прыгнула», повторная отправка не должна создавать дубль.

Если вы хотите быстрее собрать такую серверную часть без тяжелого классического программирования с нуля, полезно рассмотреть vibe‑coding подход. Например, на TakProsto.AI можно в формате чата описать сущности (snapshots, snapshot_items, products, locations), роли и статусы — а затем получить каркас веб‑панели и API, с возможностью экспорта исходников и дальнейшей доработки командой.

Уведомления и обратная связь

Два типа уведомлений дают ощутимую пользу уже в пилоте:

• Подтверждение отправки снимка (пользователь уверен, что данные дошли).
• Комментарий менеджера к снимку или отдельной строке (уточнить единицы, попросить переснять позицию, отметить расхождение).

Это можно реализовать через push‑уведомления или внутренний «центр уведомлений» в приложении — без сложных сценариев.

Интеграции на старте

Не обязательно сразу подключаться к учетной системе. Практичный старт — это:

• Экспорт в CSV/XLSX по точке, дате, пользователю.
• Веб‑просмотр отчетов: простая страница со списком снимков и фильтрами для менеджера.

Если вы выбираете формат внедрения и сопровождения, можно посмотреть варианты на /pricing.

Отчеты и просмотр данных: превращаем снимки в решения

Снимок остатков ценен только тогда, когда его можно быстро прочитать и использовать: понять, где «провал», что нужно заказать, и что изменилось после поставки или пересортировки. Поэтому отчеты в MVP должны быть простыми, но отвечать на ключевые вопросы без выгрузок «в никуда».

Какие отчеты нужны в первую очередь

По локациям — показывает состояние полок/складских зон: сколько позиций отмечено, какие зоны не пройдены, где чаще всего расхождения. Это основной отчет для руководителя точки или кладовщика.

По товарам — карточка товара с историей последних значений и пометками (например, «повреждено», «нет на витрине»). Удобно для закупок и контроля матрицы.

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

Фильтры, которые экономят время

Сделайте фильтры «в один тап»:

• «Последний снимок» по выбранной локации/товару (чтобы не искать вручную)
• Отклонения от нормы: ниже минимального/выше максимального, если такие пороги есть
• Отсутствующие позиции: ожидаемые товары, которых не нашли (или не отметили)

Важно: даже если «нормы» пока нет, можно начать с простого правила — подсвечивать нули, резкие изменения и товары без данных в текущем обходе.

Сравнение снимков: до/после и динамика

В просмотре снимка добавьте переключатель «Сравнить с…» (предыдущим или выбранным). Покажите разницу числом и цветовой меткой: было 12 → стало 3 (−9). Это превращает снимок из списка в понятное действие: пополнить, переместить, проверить списания.

Экспорт и обмен

Для MVP достаточно четырех способов:

• Экспорт в CSV (для бухгалтерии, Excel и загрузки в учетную систему)
• Ссылка на отчет внутри приложения (с учетом ролей и доступов)
• Печать (PDF‑версия для подписи/передачи смене)
• Отправка файла из приложения (например, в почту или корпоративный чат)

Если вы планируете пилот, заранее определите, кто потребляет отчеты и в каком формате — это сэкономит недели на «переделайте выгрузку». С практической стороны помогает отдельная страница /reports с избранными представлениями и сохраненными фильтрами.

Качество данных: как избежать ошибок при быстрых обходах

Быстрый обход склада ценен только тогда, когда данные можно использовать без «ручной чистки». Поэтому качество нужно закладывать не в отчеты, а прямо в момент ввода: короткие проверки, понятные подсказки и прозрачная история изменений.

Валидации, которые ловят ошибки на месте

Самые частые промахи — это опечатки и пропуски. Минимальный набор проверок для MVP:

• Запрет отрицательных значений (количество, цена, вес — в зависимости от ваших полей).
• Порог «слишком большое число» с подтверждением. Например: если обычно вводят 1–200, то 2000 должно просить «Подтвердить, это точно?». Порог лучше настраивать по типу товара/локации.
• Обязательное фото там, где без него нельзя подтвердить результат (дорогие позиции, спорные зоны, пересортица). Если фото не требуется всегда — делайте правило опциональным и включаемым на уровне сценария.

Важно: формулировки должны быть человеческими («Похоже на ошибку: 2000 шт. в ячейке A‑12»), а не «Validation error».

Контроль качества без контроля «над душой»

Работает короткий чек‑лист перед отправкой: 3–5 пунктов, которые пользователь реально успеет пробежать глазами. Добавьте подсказки по съемке: «снимайте так, чтобы были видны этикетка и количество», «не закрывайте штрихкод рукой», «избегайте бликов». Это снижает количество уточнений после обхода.

Антидубликаты: не дать «снять одно и то же дважды»

Дубликаты чаще возникают, когда сотрудника отвлекли или связь пропала. Приложение должно предупреждать, если уже есть снимок:

• той же локации за последние N минут/часов;
• того же товара в этой локации (если это запрещено правилами);
• с тем же номером задания/обхода.

Предупреждение не обязано блокировать — иногда повтор нужен. Но оно должно заставить осознанно подтвердить действие.

Аудит изменений: кто и когда исправил запись

Даже в простом MVP нужен аудит: кто создал, кто изменил, когда, и что именно поменялось (старое/новое значение). Это помогает разбирать спорные случаи без поиска виноватых и повышает доверие к данным — особенно если снимки потом уходят в учетную систему.

План разработки и запуск: от прототипа до пилота

Запуск приложения для «снимков остатков» лучше планировать как серию коротких шагов: сначала проверяем идею на минимальном прототипе, затем — в пилоте на реальной точке, и только после этого расширяем функциональность. Так вы быстрее находите слабые места (обычно это UX и качество данных), не переплачивая за «идеальную» версию.

Выбор платформы для MVP

Для MVP есть два практичных пути:

• Один нативный клиент (iOS или Android) — если у компании уже доминирует одна платформа, а важны скорость сканирования, стабильность камеры и офлайн.
• Кроссплатформа — если нужно быстро покрыть обе платформы и проверить гипотезу на большем количестве пользователей.

Критерий выбора простой: что важнее в первые 4–8 недель — максимальная производительность на одной платформе или быстрый охват.

Отдельно стоит оценить путь, когда часть продукта (админка, отчеты, API) вы делаете максимально быстро, а мобильный клиент — по мере проверки гипотез. В этом сценарии TakProsto.AI может быть удобен как «ускоритель» для веб‑части: планирование, сбор требований, быстрые итерации, снапшоты и откат — все это помогает не застрять в долгих переделках.

План спринтов: прототип → пилот → доработки → релиз

Спринт 1 (прототип): кликабельный UX и «сквозной сценарий» — точка → зона → товар → количество → сохранение. На этом этапе важно согласовать термины и поля, а не «красоту».

Спринт 2 (MVP для пилота): офлайн‑сохранение, синхронизация, базовые роли/доступы, экспорт (например, CSV) и журнал изменений.

Спринт 3 (доработки по пилоту): ускорение потока, подсказки и проверки, улучшение поиска/сканирования, исправление крайних случаев.

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

Тестирование на реальных локациях

Полевые тесты почти всегда выявляют то, чего не видно в офисе: слабая связь, плохое освещение, работа в перчатках, мокрые этикетки, очередность обхода, скорость «одной рукой». Заложите время на проверку:

• сканирования на разных типах штрихкодов;
• удобства ввода количества «на ходу»;
• поведения офлайн и после восстановления сети.

Метрики успеха пилота

Заранее договоритесь, какие цифры означают «получилось»:

• время на снимок (например, 30–60 секунд на позицию/точку);
• процент ошибок (расхождения, дубли, неверные единицы);
• полнота охвата (сколько зон/категорий реально закрыли за смену).

Если эти метрики улучшаются от недели к неделе, можно масштабировать пилот и переходить к релизу.