Кастомні workflow у Paperclip: де ламається типовий сценарій
Типовий сценарій автоматизації погоджень упевнено проходить на демо-даних і розвалюється на живому потоці заявок.
Кастомні workflow у Paperclip ми збираємо не як копію готового шаблону, а як карту процесу: де дані переходять між системами, хто підтверджує етап, що відбувається при відмові зовнішнього сервісу.
Різниця проявляється на другому тижні експлуатації — коли у черзі з'являються заявки з частково заповненими полями.
Перше вузьке місце — ручні операції у процесі. Співробітник вивантажує таблицю, перекладає статуси, переносить реквізити з пошти в картку.
Кожен такий крок — точка, де губляться заявки й з'являються дублі записів у довідниках: контрагент заводиться двічі, бо попередня спроба не збереглася до кінця.
Друге — погодження без явного власника етапу. Заявка йде на перевірку, відповідальний іде у відпустку, ескалації не передбачено — звернення висить до дзвінка клієнта. Автоматизація погоджень зобов'язана закривати етап за таймаутом сама, а не за нагадуванням у чаті.
Третє — тиша при збої зовнішньої системи. Інтеграція повернула помилку, сценарій формально завершився, і про це ніхто не дізнався до звірки звітності. Розбираємо, як це закривається: журнал подій по кожному кроку, повторні спроби з наростаючою затримкою, окрема гілка для відмови.
Що дає ручне складання процесів замість готових шаблонів
Готовий шаблон закриває типовий сценарій до першого виключення: щойно з'являється додаткова гілка або зовнішня система, шаблон починають обходити руками. Тому у Paperclip схему збираємо за фактичним маршрутом заявки, а не підганяємо процес під готову форму.
Ефекти, які видно на метриках
- Частка операцій без людини. Перевірка полів, розподіл за типом, повідомлення йдуть на автоматику; на людях залишаються тільки рішення з неповними даними.
- Час проходження заявки скорочується за рахунок прибраних очікувань, а не прискорення людей: строк рахується від надходження до закриття і видно по кожному етапу.
- Відновлення після збою гілки. Стан кроку зберігається, тому процес продовжується з останньої успішної дії, а не з початку маршруту.
- Прозорість маршруту. У кожного кроку зафіксовано відповідального, строк і умову переходу — видно, у кого заявка і що саме її тримає.
Який клас відмов зникає
- Помилки введення: обов'язкові поля й перевірки форматів переносять контроль на вхід, брак не доїжджає до виконавця.
- Загублені заявки: передача між кроками фіксується в схемі, а не у листуванні.
- Завислі погодження: таймери повертають крок відповідальному замість нескінченного очікування.
- Дублі: повторний запуск кроку не створює друге завдання за тією самою заявкою.
Підсумок — не «гарна схема», а обчислювані метрики: менше ручних операцій, коротший маршрут заявки, передбачуване відновлення після збою і розібраний перелік причин відмов.
Три підходи до складання сценарію та їхні обмеження
Зібрати сценарій автоматизації можна трьома шляхами: взяти типовий шаблон, доопрацювати готовий або описати логіку з нуля. Різниця між ними проявляється не на простих кроках, а там, де з'являються умовна логіка розгалуження, обробка виключень і повторні спроби.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Типовий шаблон | процес повторюється без відхилень: заявка, погодження, повідомлення | логіка задана заздалегідь; нестандартне розгалуження і свої виключення не виразити |
| Доопрацювання готового сценарію | базовий ланцюжок закриває більшу частину процесу | правки йдуть у чужу структуру; частина перевірок залишається поза вашим контролем |
| Ручне складання | кілька джерел даних, різна логіка за типами заявок | вищі вимоги до схеми, тестів і супроводу |
Типовий шаблон: налаштування параметрів
У шаблоні змінюються тільки параметри — адресати, строки, обов'язкові поля картки, — а структура залишається незмінною. Це швидкий старт, але межі видно відразу: щойно потрібен свій набір умов або повторний запуск після збою зовнішнього сервісу, шаблон упирається в обмеження. Розширювати його точковими правками часто дорожче, ніж описати потрібну гілку заново.
Ручне складання розгалужень і виключень
Тут ми самі будуємо дерево умов: за якою ознакою процес іде в ту чи іншу гілку, що вважається помилкою, після якої кількості повторів завдання передається відповідальному. Такий сценарій переживає збої зовнішніх сервісів і нештатні дані, не зупиняючи весь процес.
Плата за гнучкість — схема потоку, тести на кожну гілку та інструкція для тих, хто буде супроводжувати сценарій після запуску.
Як ми збираємо сценарій: етапи інженерної роботи
Сценарій збираємо від процесу, а не від інтерфейсу: фіксуємо, які кроки сьогодні роблять люди, де дані перекладають руками і що вважається завершенням завдання. Розбір дає карту вузьких місць і чесний список того, що автоматизація справді знімає.
Підготовка схеми та зв'язків між системами
На схемі кожен крок — блок із явними входами й виходами: що приходить з облікової системи, що йде далі, за якої умови сценарій іде гілкою виключення.
Зв'язки налаштовуємо на подіях, а не на опитуванні за розкладом, — реакція приходить за секунди, а зайві запуски не навантажують системи.
- Розбір процесу — інтерв'ю з виконавцями, цільовий результат, список кроків під автоматизацію.
- Схема сценарію — гілки, умови переходів, точки відмови; погоджуємо до складання, щоб правки не спливали в готовому сценарії.
- Налаштування зв'язків — права доступу, формати обміну, правила зіставлення записів: дублі й загублені заявки відсікаються на вході.
- Гілки виключень — поведінка, коли даних не вистачає: відкласти, повернути відповідальному, підняти повідомлення.
Перевірка на бойових даних
- Прогін на копії реальних даних за минулий період — сценарій проходить усі гілки, включно з рідкісними.
- Тести відмов — імітуємо недоступність зовнішньої системи й перевіряємо, що операція повторюється без дублів.
- Передача в супровід — схема, інструкції, журнали й оповіщення про помилки.
Далі сценарій живе: метрики за кроками показують, де накопичується затримка, і правки вносяться точково, без перезбирання всього процесу.
Що залишається у вас на руках після здачі проєкту
Після здачі проєкту у вас залишається не тільки робочий сценарій, а й повний комплект документації, за яким його можна розвивати своїми силами або передати іншій команді.
Артефакти розділені на дві частини: технічну — для інженерів, і експлуатаційну — для співробітників і власника процесу.
Технічна частина
- Схема маршрутів — усі переходи, розгалуження й точки виклику зовнішніх систем нанесені на діаграму з умовами спрацьовування: новому інженеру не потрібно відновлювати логіку за журналом.
- Правила доступу за ролями — матриця «роль → дія → ресурс», окремо описано сервісні облікові записи, строки їхнього життя та порядок відкликання.
- Налаштування обробки помилок — політика повторів із наростаючою затримкою, перелік виключень і сценарій оповіщення відповідального, коли зовнішня система не відповідає.
Експлуатаційна частина
- Інструкції для співробітників — короткі сценарії на кожен ручний крок: що робити при поверненні завдання, як передати його колезі, куди дивитися при сумніві.
- Регламент змін — правки маршруту проходять через тестовий контур і перевірку другим інженером, а не вносяться прямо у робочу версію.
- Журнал подій — налаштовано збір і зберігання записів про запуски, збої та ручні втручання: розбір інциденту займає хвилини замість годин пошуку у листуванні.
Комплект оновлюється в міру розвитку процесу — ви отримуєте не разовий документ, а живу базу знань зі своєї автоматизації.
Кейс: як прибрали ручні погодження у закупівлях
Заявки приходили у пошту й месенджери, потім вручну переносилися у таблицю, погодження йшло ланцюжком із чотирьох людей. Ніхто не бачив, на чиєму кроці закупівля застрягла, а історія правок жила у листах.
Ми розібрали процес покроково й зібрали кастомні сценарії у Paperclip: маршрутизація за правилами, перевірки полів і єдиний журнал змін.
Що було
Середній строк погодження заявки — 4 робочі дні, за терміновими позиціями сягало тижня. Частка повернень на доопрацювання — 38%: заявку відхиляли через незаповнені поля або неправильну категорію, і вона йшла по колу заново.
Погоджувач витрачав на звірку й листування близько 11 годин на тиждень, а дані повторно вводилися в облікову систему.
Що стало
Маршрут будується за типом закупівлі, сумою та підрозділом — заявка йде учасникам без ручного пересилання.
Строк погодження скоротився до 9 робочих годин, частка повернень на доопрацювання — 7%: обов'язкові поля й вкладення перевіряються до відправлення, відхилена заявка повертається автору з конкретним зауваженням.
14 з 17 операцій переведено з ручного режиму в автоматичний — постановка завдань, повідомлення, вивантаження в облікову систему.
Завантаження погоджувача знизилося до 2 годин на тиждень — вивільнений час пішов на роботу з постачальниками. Журнал змін показує, хто і коли правив заявку, тому спірні випадки розбираються за фактами, а не за пам'яттю.
Що робити, якщо у Paperclip уже зібрані типові сценарії?
Зібрані у Paperclip типові сценарії — не проблема, а фундамент: переписувати їх з нуля не потрібно. Розбираємо маршрути за трьома ознаками: де логіка збігається з цільовою, де розходиться частково, а де тримається на обхідних рішеннях.
Перша група переноситься як є, друга доповнюється кроками, третя перезбирається — зазвичай близько чверті.
Технічний борг в автоматизації проявляється саме тут: дубльовані умови у різних гілках, ручні підтвердження, поставлені колись «на час», копії одного погодження під різні відділи.
Такі ділянки зводяться до спільних правил — після цього правка одного кроку не зачіпає п'ять маршрутів.
Міграція без зупинки роботи йде у два контури. Нові маршрути збираються поряд зі старими й проганяються на копії процесу: звіряємо статуси, повідомлення й записи в облікових системах на однакових заявках.
Поки розбіжності залишаються, робочий потік іде колишньою гілкою, а перемикання робимо групами заявок — з можливістю відкотити окрему групу.
Історія заявок зберігається: ідентифікатори, вкладення, коментарі та ланцюжки переходів переносяться з прив'язкою до тих самих карток. Звітність і пошук за минулими зверненнями не рвуться, а фахівець відкриває заявку й бачить увесь шлях, який вона пройшла до переходу.
Що переписувати, а що залишати як є, залежить від устрою ваших маршрутів. Опишіть поточну картину — повернемося з планом перезбирання та порядком перемикання.
Технічні сумніви та обмеження платформи
Paperclip упевнено закриває типові маршрути погодження, а питання починаються на межах: глибокі розгалуження, чужі сервіси, живі довідники. Нижче — прямі відповіді про те, де обмеження платформи реальне, а де знімається проєктуванням.
Ми розбираємо ці межі на етапі схеми, а не після першого збою в роботі. Тому кожна відповідь описує і межу, і обхідний шлях.
Наскільки складні розгалуження платформа витримає?
Рушій тримає вкладеність, але читабельність схеми падає раніше, ніж можливості. Гілку глибше 3-4 рівнів виносимо в окремий підпроцес із явним входом і виходом — його можна тестувати окремо й викликати з різних сценаріїв.
Паралельні гілки зводимо кроком-об'єднанням із заздалегідь прописаним правилом, що робити при конфлікті результатів.
Що відбувається, якщо зовнішня система недоступна в момент виклику?
Сценарій не падає: виклик іде у повторні спроби з наростаючою паузою, а після їх вичерпання — у чергу необроблених на ручний розбір. Завдання не губиться, відповідальний бачить його окремим списком, інші гілки процесу продовжують роботу. Критичні кроки позначаємо так, щоб продовження було неможливе без підтвердження оператора.
Чи зламається сценарій при зміні довідників?
Відповідності полів виносимо окремим шаром: змінюється структура довідника — правиться одна таблиця зіставлення, а не логіка маршруту. Версія довідника фіксується на момент запуску процесу, тому вже запущені екземпляри не ламаються й завершуються за попередніми правилами.
Хто супроводжує сценарії після здачі?
Передаємо схему, опис кроків, правила обробки помилок і журнал змін. Кожна правка — нова версія сценарію з можливістю відкату до попередньої за хвилини, без зупинки поточних процесів. Типові доопрацювання закриває ваша команда за нашою документацією, складні зміни беремо на себе.
Обговоримо завдання: що увійде в оцінку та план робіт
Щоб повернутися з оцінкою та планом, а не із загальними формулюваннями, потрібен вхід з вашого боку: опис процесів, як вони йдуть зараз, ролі учасників і кроки, де найчастіше накопичуються затримки.
Корисні приклади документів, перелік зовнішніх систем для обміну та обмеження за доступами — що можна підключати, а що залишається у закритому контурі. Ділянки, що живуть у таблицях і листуванні, теж надсилайте: за ними найкраще видно, де автоматизація знімає навантаження.
У відповідь ви отримуєте розбір, за яким уже можна ухвалювати рішення:
- карту процесів: де зараз ручні операції, де дублювання і які ділянки закриваємо у першу чергу;
- склад етапів із трудомісткістю кожного та порядком виконання;
- точки контролю: на яких кроках ви бачите проміжний результат і встигаєте скоригувати курс;
- порядок передачі: доступи, середовища, регламент виведення у робочу експлуатацію та відкату до попередньої версії;
- критерії приймання: які перевірки на ваших даних підтверджують, що процес відпрацьовує повністю;
- перелік ризиків і обмежень із варіантами обходу;
- формат звітності та порядок підтримки після запуску.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом, де кожен етап прив'язаний до результату й точки контролю.
