Разберём, как спроектировать мобильное приложение для обходов охраны: точки и QR-метки, офлайн-фиксация событий, синхронизация и отчёты.
Когда обходы фиксируются на бумаге или «на словах», быстро появляются пропуски точек, спорные ситуации и отчёты, заполненные задним числом. Руководителю смены нужны не описания, а простые ответы: кто был на маршруте, где и когда, и что произошло по пути.
Мобильное приложение для обходов охраны закрывает три базовые потребности: дисциплину (обход реально сделан), доказуемость (есть отметки по времени и месту) и понятную картину по инцидентам (что случилось и как отреагировали). Главное - не превратить контроль в дополнительную работу для охранника.
«Правильный» обход сводится к нескольким вещам: есть маршрут с контрольными точками, есть тайм-окна (например, каждые 60-90 минут), есть подтверждение присутствия на точке (QR или другой метод), есть события по ходу (инцидент, комментарий, фото, запрос на ремонт), и в конце формируется отчёт без ручного переписывания.
Роли лучше определить сразу, иначе начнутся споры о доступах. Охраннику нужна максимально простая работа: открыть смену, отметить точку, при необходимости зафиксировать событие. Старшему смены важно видеть выполнение в реальном времени или почти в реальном, разбирать спорные случаи и получать сводку. Админу нужны настройки: маршруты, точки, права, список объектов и выгрузка данных.
Есть ограничения, которые нельзя игнорировать. Связь на объектах часто слабая, особенно ночью и в подвалах, поэтому запись должна работать офлайн и не терять данные. Интерфейс должен быть крупным и быстрым: зимой в перчатках никто не будет заполнять форму на десять полей.
Простой сценарий: охранник обходит склад в 02:30, сканирует QR на воротах, видит открытую дверь подсобки, нажимает «Инцидент», добавляет короткий комментарий и фото. Интернет появляется только у проходной, записи синхронизируются, а старший смены получает полную картину без звонков и переписок.
Если вы планируете собирать такой прототип на TakProsto, задачу удобно описать текстом: маршруты, точки, роли и события. Офлайн-запись и синхронизацию лучше сразу выделить как отдельное обязательное требование.
Чтобы приложение для обходов работало без споров и «потерянных» записей, заранее договоритесь о простой модели данных. Она отвечает на три вопроса: где ходим (маршрут), что проверяем (точки), что фиксируем (события).
Маршрут - это шаблон обхода: название, список контрольных точек и ожидаемый порядок (строго по порядку или в любом). Смена (патрульная сессия) - конкретный запуск маршрута: кто вышел на обход, когда начал, когда закончил и с каким результатом. Один и тот же маршрут может запускаться десятки раз в сутки разными сотрудниками.
Контрольная точка - место, которое охранник подтверждает на объекте. У точки должен быть стабильный ID, понятное описание (корпус, этаж, вход, ориентир) и QR-метка, которая однозначно подтверждает «я здесь». Полезный флажок - обязательность: если точка критичная, система подсвечивает пропуск и просит комментарий.
Событие - запись внутри смены, привязанная к точке (или к маршруту в целом). Обычно хватает трёх типов: отметка, инцидент, комментарий. Фото и вложения лучше сделать опциональными, чтобы обход не зависел от камеры и связи.
Для отчётов и разборов чаще всего хватает такого минимума:
Время храните в двух видах: локальная метка на устройстве для офлайн-работы и серверное подтверждение при синхронизации. Тогда в отчёте видна реальная хронология, а спорные моменты проще разбирать.
Разметка объекта решает половину проблем с контролем обходов. Если точки поставлены «как получится», охранник тратит время на поиск меток, а отчёты становятся спорными. Лучше один раз продумать схему и сделать её понятной любому человеку на смене.
Начните с карты маршрутов: этажи, посты, периметр, отдельные зоны риска (входы, пожарные щиты, серверные, склады). У каждой точки должен быть простой смысл: что именно вы проверяете и почему это важно. Удобно размещать точки так, чтобы шаг между ними был 1-3 минуты, а ключевые места (ворота, КПП, эвакуационные выходы) обязательно попадали в маршрут.
С QR-метками важны две вещи: чтобы их было легко найти и сложно подменить. Клейте метку там, где охраннику удобно поднести телефон (уровень глаз или чуть ниже), но куда случайный человек не дотянется без внимания. Избегайте мест с водой, паром, прямым солнцем и постоянной грязью. Для защиты от подмены используйте ламинацию или прозрачный защитный слой, а лучше - пломбу или фирменный стикер, который рвётся при попытке снять.
В QR лучше кодировать не «адрес» и не название, а короткий идентификатор точки. При желании добавьте подпись для проверки глазами и версию схемы, чтобы приложение понимало, какая разметка сейчас актуальна. Идентификатор должен быть уникальным и не меняться при переименовании точки.
Повреждения меток неизбежны, поэтому предусмотрите запасной сценарий. Например, рядом с точкой можно разместить короткий код (6-8 символов), чтобы охранник мог ввести его вручную.
Перед запуском сделайте тестовый обход. Пусть один человек пройдёт маршрут так, как будет ходить смена: в темноте, в перчатках, с фонарём, в лифте и в зонах с плохой связью. Обычно на этом этапе всплывают мелочи, которые потом экономят недели: метку плохо видно, камера не фокусируется, точка привязана не к тому месту или маршрут слишком длинный.
Хорошее приложение держится на простом действии: охранник подходит к точке, сканирует QR-метку, выбирает событие и сразу сохраняет. Чем меньше лишних экранов и полей, тем выше шанс, что данные будут полными и честными.
Перед стартом смены человеку нужен один понятный экран без лишних решений. Обычно достаточно: названия маршрута и смены, коротких подсказок по объекту, списка точек с прогрессом, большой кнопки «Сканировать QR» и быстрого доступа к последним событиям, чтобы не дублировать записи.
«Отметка» должна делаться в 1-2 нажатия: сканирование и подтверждение. Остальное приложение заполняет само: время, точка, пользователь, а при наличии - координаты.
«Инцидент» лучше выделить отдельным типом, чтобы он не терялся среди обычных отметок. Форма должна быть короткой, но полезной для разборов. Как минимум: тип (например, дверь открыта, посторонний, пожарная тревога, повреждение), описание в свободной форме, важность (низкая/средняя/высокая), фото или файл при необходимости и отметка «нужна реакция старшего».
«Комментарий» подходит для коротких заметок без лишней бюрократии: «собака на территории», «свет мигает», «замок тугой». Это помогает фиксировать контекст, не раздувая статистику инцидентов.
Если вы собираете прототип в TakProsto, начните с описания этих трёх событий словами: что вводится и что сохраняется. Потом можно перейти к экранам и кнопкам, оставив только самые нужные поля.
Офлайн в приложении означает одно: каждое действие охранника не зависит от интернета. Отметка, инцидент и комментарий сразу сохраняются на устройстве и попадают в локальную очередь отправки.
Очередь надёжнее, чем попытка «дозвониться» до сервера каждый раз. Она хранит события по порядку, добавляет к ним время, точку, пользователя и служебный идентификатор, чтобы потом синхронизировать без потерь.
Синхронизацию удобно делать по двум правилам: автоматически при появлении сети и по явной кнопке «Отправить». Если отправка не удалась, приложение не должно просить пользователя повторять ввод. Оно оставляет событие в очереди и пробует снова через интервал, а при частых сбоях увеличивает паузу.
Чтобы охранник понимал, что происходит, показывайте статусы прямо в журнале обхода: «Не отправлено», «В очереди», «Отправляется», «Успешно», «Требует внимания» (например, при конфликте).
Конфликты встречаются чаще, чем кажется: два события подряд на одну точку, повторное сканирование QR из-за задержки, дубль после перезапуска приложения. Рабочая логика обычно такая: сервер принимает события как отдельные факты, а дубликаты склеиваются по уникальному идентификатору события и по ключу (точка + тип + время в пределах окна, например 1-2 минуты).
Минимальная безопасность на устройстве должна быть базовой, но обязательной: шифрование локальной базы и очереди, пин-код или биометрия, авто-выход при простое, запрет на экспорт логов без прав, возможность удалённо заблокировать аккаунт при утере телефона.
Старшему смены важны не «красивые графики», а быстрые ответы: кто сейчас на маршруте, где были пропуски, есть ли инциденты и кто их разбирает. Хорошая панель должна давать картину смены за 10-20 секунд.
Обычно хватает нескольких экранов: смены (активные и завершённые), маршруты (план и факт), события (общий журнал), инциденты (очередь на разбор) и отчёты (выгрузка и архив).
Отчёт по обходу лучше строить вокруг сравнения плана и факта: время старта и финиша, длительность, пропуски точек и отклонения (точка пройдена слишком рано или слишком поздно). Важно показывать не только ошибки, но и контекст: был ли комментарий, есть ли фото, что написано в описании.
Журнал событий полезен, когда есть быстрые фильтры по объекту, охраннику, смене и периоду. Для инцидентов достаточно простого цикла: новый, в работе, закрыт. Добавляйте короткие комментарии по разбору: кто посмотрел, что подтвердилось, какие действия приняты. Это спасает, когда через месяц приходит проверка и нужно восстановить ход событий.
Чтобы быстро получить прототип, начните не с экранов, а с требований. Коротко опишите, что это мобильное приложение для обходов охраны, и какие роли в нём есть: охранник, старший смены, администратор.
Дальше зафиксируйте события, которые записывает охранник: отметка на точке, инцидент, комментарий. Для каждого события сразу задайте минимальные поля: время, точка, автор, текст, фото (по желанию), статус синхронизации.
Практичный порядок работы выглядит так:
Для проверки возьмите один объект, распечатайте 3-5 QR-меток, приклейте их на места обхода и сделайте пробный ночной маршрут. Если планируете дальнейшую разработку, заранее предусмотрите экспорт исходников и безопасный выпуск новых версий.
Ночь, складской комплекс: длинный периметр, два корпуса, у ворот шлагбаум и пост охраны. Связь нестабильная, особенно за вторым корпусом, где сигнал часто «проваливается». Для таких объектов приложение должно работать так же уверенно, как и при хорошем интернете.
Маршрут задан на 12 контрольных точек. Три точки обязательные: ворота, щитовая и зона погрузки. У них есть тайм-окно, например 22:00-22:15, 23:30-23:45 и 01:00-01:15, чтобы было видно, что охранник не «закрыл» маршрут задним числом.
В 00:10 связь пропадает почти на 40 минут. Охранник продолжает обход: на каждой точке сканирует QR-метку, а приложение фиксирует отметку с временем и координатой (если доступно). В 00:27 он замечает приоткрытую дверь в подсобку у второго корпуса и оформляет инцидент: выбирает тип, добавляет комментарий и делает фото. Всё сохраняется офлайн в очереди событий.
Когда сеть возвращается, синхронизация автоматически отправляет накопленные записи. Старший смены видит полный путь по 12 точкам с фактическим временем, соблюдение тайм-окон на обязательных точках, инцидент с фото и временем создания, а также сам факт отсутствия сети как технический контекст, а не «пропажу» охранника.
Провалы в пилоте обычно не про «не тот стек», а про мелочи в полях, времени и доверии к данным. Если их не учесть, охранники начинают обходить приложение стороной, а старший смены перестаёт верить отчётам.
Частая ошибка - пытаться собрать «идеальный» инцидент с десятком полей. На посту это заканчивается раздражением и пропусками.
Оставьте минимум: 2-3 обязательных поля (например, тип и краткое описание, фото по необходимости). Остальное сделайте необязательным или показывайте только для отдельных типов. Хорошее правило: инцидент должен создаваться за 15-20 секунд.
Если человек сканирует QR дважды или приложение подвисло, появляются двойные «отметки», а иногда и двойные инциденты.
Помогают три меры: блокировка повторной отметки по точке в коротком окне (30-60 секунд), уникальный идентификатор события и серверная дедупликация при синхронизации, а также понятное подтверждение вроде «Точка принята, сохранено офлайн».
Если время устройства сбито или часовой пояс другой, а отчёт строится по серверному времени, обход «уезжает» на час и ломает доверие.
Храните два значения: локальное время устройства и серверное время при синхронизации. В отчётах явно показывайте, какое время используется, и фиксируйте часовой пояс объекта.
Когда офлайн-режим работает «в фоне», но не объясняется пользователю, люди думают, что данные потерялись.
Сделайте статус заметным: счётчик «ожидают отправки», время последней успешной синхронизации и простая кнопка «синхронизировать сейчас».
Если QR-метка - просто текст с номером, её легко сфотографировать, распечатать и «отмечаться» не выходя из будки. Со временем точки меняются, а старые коды продолжают жить.
Минимум защиты - подписывать данные в QR (токеном/подписью) и вводить версии: «точка A v3». Тогда старые QR проще выводить из оборота, а в отчёте будет понятно, какая версия точки была пройдена.
Перед пилотом важно убрать мелочи, из-за которых охранник бросит приложение уже в первую смену. Цель пилота - проверить, что обход действительно фиксируется, а старший смены видит понятную картину.
За один день прогоните маршрут сами или с опытным сотрудником и проверьте базовые вещи: точки заведены без двусмысленности (название и место понятны), QR-метки сканируются при плохом свете, тестовые логины и роли разделены, есть короткая инструкция на одну страницу, а офлайн-режим пройден руками (сохранение без сети, очередь отправки, синхронизация без дублей).
После этого сравните, что приложение считает «фактом обхода», а что ждёт руководитель. Например, при пропуске точки должно быть видно не только «пропуск», но и контекст: была ли связь, была ли попытка сканирования, был ли комментарий.
На 1-2 недели пилота заранее договоритесь о правилах оценки, иначе всё сведётся к спору «нравится/не нравится». Обычно смотрят на долю обходов с полными отметками, число пропусков, время реакции на инциденты и то, насколько отчёт совпадает с реальной сменой.
Проще всего запускать приложение без стресса с одного объекта и одной смены. Возьмите маршрут на 8-15 точек, добавьте 2-3 типовых инцидента и договоритесь, что первая неделя проверяет удобство и надёжность, а не «идеальную дисциплину».
Через 5-7 дней обычно всплывает одно и то же: формы слишком «умные». Часто помогает упрощение выбора и сокращение ввода текста. Например, вместо обязательного длинного описания сделать быстрые причины («дверь открыта», «посторонние», «повреждение»), а текст оставить опцией.
Дальше масштабирование упирается в правила данных: сколько хранить историю, кто имеет доступ, как подтверждаются спорные ситуации, как работает экспорт и аудит.
Если есть требование разворачивать всё в России и не отправлять данные за пределы страны, это стоит фиксировать в ТЗ. TakProsto (takprosto.ai) работает на серверах в России и использует локализованные модели, поэтому такой пункт часто проще согласовать при пилоте и дальнейшем внедрении.
Начните с трёх вещей: список маршрутов, контрольные точки (с понятным местом и уникальным ID) и события, которые фиксируются по пути (отметка, инцидент, комментарий). Затем добавьте роли и обязательное требование офлайн-записи, чтобы обход не зависел от связи.
По умолчанию достаточно трёх ролей: охранник, старший смены и администратор. Охраннику оставьте минимум действий (старт смены, скан, событие), старшему дайте контроль и разбор спорных ситуаций, а админу — маршруты, точки, права и выгрузки.
Практичный минимум — QR, который подтверждает присутствие на конкретной точке. Чтобы снизить риск подмены, кодируйте в QR короткий идентификатор точки (а не название), защищайте наклейку и продумайте запасной ручной код на случай повреждения метки.
Делайте шаг между точками таким, чтобы проход занимал 1–3 минуты, а критичные зоны (входы, ворота, эвакуационные выходы) обязательно попадали в маршрут. Каждая точка должна иметь понятное описание с ориентиром, иначе начнутся споры «где именно стоит метка».
Держите базовый набор событий: отметка, инцидент, комментарий. Инцидент выделяйте отдельно и делайте короткую форму (тип, краткое описание, важность, фото по желанию), а комментарий оставьте для бытовых заметок, чтобы не раздувать статистику.
Сохраняйте каждое действие локально на устройстве и отправляйте на сервер из очереди при появлении сети. Пользователь должен видеть статус записей в журнале (не отправлено, в очереди, отправляется, успешно), чтобы не было ощущения «данные пропали».
Лучше всего работают простые меры: уникальный идентификатор события, блокировка повторной отметки на той же точке в коротком окне и серверная дедупликация при синхронизации. Тогда повторный скан из-за подвисания не превращается в «двойной обход».
Храните два времени: локальное на устройстве (для офлайна) и серверное при подтверждении синхронизацией. В отчётах используйте понятную логику и фиксируйте часовой пояс объекта, чтобы обход не «уезжал» на час и не ломал доверие к данным.
Сфокусируйтесь на сравнении плана и факта: старт и финиш, длительность, пропуски точек и отклонения по тайм-окнам. Отдельно покажите инциденты в простом цикле «новый — в работе — закрыт» и сохраняйте комментарии по разбору.
Сделайте пилот на одном объекте: 8–15 точек, 2–3 типовых инцидента и тестовый ночной обход в реальных условиях (темнота, перчатки, лифт, слабая связь). Заранее договоритесь, как оцениваете результат — полнота отметок, число пропусков и время реакции на инциденты.
