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

Погодження документів у мобільному застосунку: де розривається процес

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

Ціна такої схеми — затримки погодження, яких не видно у звітності: документ начебто в роботі, а фактично чекає на одну людину. Якщо погоджувач на об'єкті або у відрядженні, підпис чекає на його повернення до офісу, поки спливають строки за договором. А друга версія, прикріплена до листа, обнуляє весь цикл: підписи доводиться збирати заново.

Навіть коли в контурі вже стоїть 1С:Документооборот, мобільна частина часто зведена до перегляду: файл відкривається, а дія за ним недоступна. Погодження з телефона перетворюється на «прочитав, повернусь — підпишу». Вузьке місце тут не у зв'язку і не в екрані, а в тому, що маршрут не описаний як дані.

Погодження документів у мобільному застосунку закриває це не тому, що екран зручніший, а тому що в документа з'являється один статус: у кого він зараз, скільки висить, що залишилося до підпису.

Рішення ухвалюється з будь-якої точки — підписати, відхилити з причиною, передати наступному, залишити зауваження до пункту. Нижче розбираємо, як це влаштовано в застосунку та на боці сервісу.

Вимірний ефект: швидкість рішень і менше повернень на доопрацювання

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

Цикл погодження скорочується з кількох днів до годин, а документи, що зависли в очікуванні, перестають накопичуватися: строк більше не залежить від того, чи повернулася людина до робочого місця.

Повернення на доопрацювання падають завдяки тому, що зауваження не можна залишити «на словах». Екран погодження вимагає прив'язати правку до фрагмента документа, вибрати тип зауваження та вказати, що саме порушено.

Маршрут задається за ролями та типом документа, тому після правки документ не йде на повторне коло до тих, чиє погодження вже отримано — перепогоджуються лише порушені розділи.

Прозорість статусів тримається на явній моделі станів: чернетка, на погодженні, є зауваження, підписано, архів. Кожен перехід записується в журнал — видно, у кого документ зараз і скільки він там стоїть.

Історія правок зберігає всі редакції з автором і часом, тому «у мене була інша версія» перестає бути аргументом: потрібну редакцію відкривають і порівнюють рядок за рядком.

Інженерно це вимагає ретельної синхронізації. Застосунок кешує документ локально та працює за слабкого зв'язку, а черга операцій вирушає на сервер після її відновлення — без дублів підписів і повторних зауважень.

Обмін будуємо з чинним контуром електронного документообігу, включно з 1С:Документооборот, зберігаючи вже ухвалені маршрути, ролі та права доступу.

Варіанти реалізації: нативний клієнт, гібрид, вебкабінет

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

Якщо в контурі є підпис, сканування паперового оригіналу, біометрія та регулярна робота без мережі — вимоги до клієнта одні; якщо керівник раз на тиждень дивиться вердикт з ноутбука — інші. Нижче — реальні альтернативи, між якими обирають на старті проєкту.

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

На етапі вибору ми окремо перевіряємо, де зберігається чернетка, як розв'язуються конфлікти одночасних правок і що відбувається з документом, якщо мережа зникла в момент надсилання.

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

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

Тому етапи розробки застосунку йдуть послідовно: кожен спирається на погоджений артефакт попереднього.

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

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

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

4. Інтеграція та повідомлення. Обмін з обліковою системою; підпис ідемпотентний — повторний запит при обриві зв'язку не створює другої візи.

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

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

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

Що залишається у вас після запуску: конфігурації та регламенти

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

• Схема маршрутів погодження — усі гілки руху документа: послідовні, паралельні, з поверненням на доопрацювання, з умовним переходом за типом документа або сумою. Окремо позначені точки, де маршрут змінюється без випуску нової версії застосунку.
• Схема ролей і політики доступу — хто бачить, хто погоджує, хто лише читає, хто адмініструє. Правила описані на рівні ролей, а не конкретних співробітників, тому при кадрових змінах нічого не ламається.
• Регламент оновлень — порядок випуску: складання, внутрішня перевірка, поетапне розгортання на частку користувачів, відкат на попередню версію. Зазначено, які зміни можна викочувати без проходження магазинів застосунків.
• Регламент роботи із серверною частиною — розклад резервних копій, строк зберігання історії погоджень, порядок дій при недоступності зовнішніх сервісів. Перевірений на відновленні з копії, а не лише описаний.
• Інструкції для співробітників — короткі сценарії під ролі: як погодити, як повернути із зауваженням, як підписати офлайн, що робити при втраті доступу. З ілюстраціями екранів, а не описом кнопок.
• Опис інтеграцій — з якими системами пов'язані облікові записи, електронний підпис і повідомлення, якими правами наділено застосунок і що відбувається при відкликанні доступу.
• Порядок передачі та точка контакту — доступи до збірок, сховища та моніторингу переводяться на ваші облікові записи, а не залишаються на зовнішніх.

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

Кейс: погодження договорів з телефона за хвилини

Замовник — логістичний оператор ТрансЛайн: юристи в головному офісі, комерційні директори — у регіонах і на об'єктах. Договори погоджували поштою, файл ішов ланцюжком із шести учасників, і до третього кола в листуванні жили чотири різні редакції одного документа.

Медіана циклу трималася на 7 робочих днях, кожен п'ятий договір ішов на повторне коло, а загублену правку іноді знаходили вже після підписання.

Що перебудували в маршруті

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

Правки прив'язані до пункту договору, а не до копії файлу: учасник працює з одним мастер-документом, при збереженні система звіряє ревізії та одразу показує конфлікт.

Сповіщення веде прямо до спірного пункту — рішення ухвалюється одним дотиком, а документ читається й без мережі: рішення вирушає в чергу та застосовується при появі зв'язку.

Метрики до та після

Медіана циклу погодження договору скоротилася з 7 робочих днів до 1,5. Частка повернень на доопрацювання впала з 34% до 11% — завдяки паралельним гілкам і ранньому конфлікту ревізій, а не «прискоренню заради прискорення».

Загублені редакції зникли як клас: журнал фіксує, хто і що змінив у кожному пункті, і це знімає суперечки «ми погоджували іншу версію». Прострочення за внутрішнім тижневим нормативом скоротилося з 22% до 3%.

Нативний клієнт чи вебкабінет: що вибрати у вашому випадку

Вибір визначається сценаріями: де співробітник підписує та править документи і чи є там мережа. Якщо погодження відбувається в дорозі, на об'єкті або без покриття, потрібен нативний клієнт під платформу з локальним сховищем і офлайн-підписом.

Якщо майже все погодження відбувається з офісу, вебкабінет закриває завдання без релізів на парк пристроїв.

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

Сервер веде ревізії та журнал операцій, тому конфлікт версій документа розв'язується не за правилом «хто останній записав — той правий», а звіркою базової ревізії: розходження віддається користувачеві як конфлікт із вибором — залишити свою правку, чужу чи об'єднати обидві.

Робота за слабкого каналу — це не лише повільно. Клієнт тримає вихідні операції в черзі та додомує надсилання при появі мережі, повторюючи його без дублів завдяки ідемпотентним ключам; вкладення вирушають частинами з перевіркою цілісності.

Ми вибираємо варіант за часткою операцій поза офісом і критичністю офлайн-підпису — це видно з журналу погоджень, а не з побажань до інтерфейсу.

Часті запитання щодо інтеграції, доступів і захисту

Перед стартом зазвичай спливають ті самі технічні питання: як застосунок стикується з працюючим документообігом, хто побачить конкретний документ, що станеться при обриві зв'язку. Розбираємо за пунктами — без загальних формулювань.

Хто і які документи побачить?

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

Що відбувається, якщо мережі немає?

Доступні заздалегідь документи читаються з локального кешу, а рішення або правка стають у чергу надсилання. При появі зв'язку операції вирушають на сервер; якщо версія документа вже змінилася, система позначає розходження, а не затирає чуже рішення.

Як захищені дані на самому пристрої?

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

Що входить у підтримку після запуску?

Оновлення виходять без зупинки роботи, діагностика збирається за знеособленими подіями. Тримаємо сумісність з актуальними гілками операційних систем і регламент реакції на звернення.

Обговоримо завдання та повернемося з оцінкою і планом

Щоб старт проєкту не розтягнувся на місяці листування, достатньо описати процес так, як він відбувається зараз. Погодження документів майже завжди зав'язане на людей, а не на регламент: хто ставить першу візу, хто підписує, на якому кроці папір зазвичай застрягає.

Чим точніше опишете цей шлях, тим менше припущень закладаємо в оцінку — і тим менше правок спливе на прийманні.

Що потрібно від вас для оцінки та плану робіт:

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

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