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

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

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

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

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

Согласование документов в мобильном приложении закрывает это не потому, что экран удобнее, а потому что у документа появляется один статус: у кого он сейчас, сколько висит, что осталось до подписи. Решение принимается из любой точки — подписать, отклонить с причиной, передать следующему, оставить замечание к пункту. Ниже разбираем, как это устроено в приложении и на стороне сервиса.

Измеримый эффект: скорость решений и меньше возвратов на доработку

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

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

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

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

Варианты реализации: нативный клиент, гибрид, веб-кабинет

Выбор платформы определяется не вкусом, а тем, откуда согласующий принимает решение и что нужно от устройства. Если в контуре есть подпись, сканирование бумажного оригинала, биометрия и регулярная работа без сети — требования к клиенту одни; если руководитель раз в неделю смотрит вердикт с ноутбука — другие. Ниже — реальные альтернативы, между которыми выбирают на старте проекта.

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

Этапы внедрения: от разбора маршрутов до передачи в поддержку

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

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

2. Настройка ролей и доступа. Матрица «роль × действие»: просмотр, правка, подпись, отзыв, делегирование. Права разграничиваем на уровне документа и вложения.

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

4. Интеграция и уведомления. Обмен с учётной системой; подпись идемпотентна — повторный запрос при обрыве связи не создаёт вторую визу.

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

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

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

Что остаётся у вас после запуска: конфигурации и регламенты

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

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

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

Кейс: согласование договоров с телефона за минуты

Заказчик — логистический оператор ТрансЛайн: юристы в головном офисе, коммерческие директора — в регионах и на объектах. Договоры согласовывали по почте, файл шёл по цепочке из шести участников, и к третьему кругу в переписке жили четыре разные редакции одного документа. Медиана цикла держалась на 7 рабочих днях, каждый пятый договор уходил на повторный круг, а потерянную правку иногда находили уже после подписания.

Что перестроили в маршруте

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

Метрики до и после

Медиана цикла согласования договора сократилась с 7 рабочих дней до 1,5. Доля возвратов на доработку упала с 34% до 11% — за счёт параллельных ветвей и раннего конфликта ревизий, а не «ускорения ради ускорения». Потерянные редакции исчезли как класс: журнал фиксирует, кто и что изменил в каждом пункте, и это снимает споры «мы согласовывали другую версию». Просрочка по внутреннему недельному нормативу срезалась с 22% до 3%.

Нативный клиент или веб-кабинет: что выбрать в вашем случае

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

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

Работа при слабом канале — это не только медленно. Клиент держит исходящие операции в очереди и дожимает отправку при появлении сети, повторяя её без дублей за счёт идемпотентных ключей; вложения уходят частями с проверкой целостности.

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

Частые вопросы по интеграции, доступам и защите

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

Кто и какие документы увидит?

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

Что происходит, если сети нет?

Доступные заранее документы читаются из локального кэша, а решение или правка встают в очередь отправки. При появлении связи операции уходят на сервер; если версия документа уже изменилась, система помечает расхождение, а не затирает чужое решение.

Как защищены данные на самом устройстве?

Локальное хранилище шифруется, кэш имеет ограниченный срок жизни и очищается при выходе из учётной записи. Скриншоты и копирование вложений закрыты, а при потере устройства доступ отзывается удалённо.

Что входит в поддержку после запуска?

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

Обсудим задачу и вернёмся с оценкой и планом

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

Что нужно от вас для оценки и плана работ:

• Роли и права: кто инициирует документ, кто согласует, кто только видит, кто может вернуть на доработку.
• Маршруты: типовые цепочки согласования, условия их ветвления и случаи, когда нужен дополнительный круг.
• Системы-источники: где документы лежат сейчас — хранилище, корпоративный портал, учётная система — и как к ним открыт доступ.
• Ограничения: закрытый контур, требования к хранению данных, корпоративные политики безопасности и вход сотрудников.
• Объём и сроки: примерное число пользователей, частота операций, дата, к которой приложение должно быть у людей.
• Ответственный за приёмку: человек, который подтвердит, что маршруты и уведомления работают как задумано.
• Пожелания к работе без сети: нужны ли черновики и подпись, когда связи нет.

Опишите задачу в свободной форме — роли, маршруты, системы и сроки достаточно. Мы вернёмся с оценкой, планом работ по этапам и вариантом передачи в поддержку после запуска.