Початок: затвердження відряджень здійснюється за допомогою повідомлень у групах, а знайти відповідального за затвердження — шляхом запиту
У виробничому підприємстві з близько 200 співробітниками перша заявка на відрядження після новорічних свят була оформлена так: працівник зазначив керівника у групі, керівник відповів «ОК», працівник зробив скріншот і зберіг його; наприкінці місяця фінансовий відділ, підбиваючи розрахунки за відрядження, порівнював кожен скріншот із бюджетом; а відділ кадрів наприкінці року підраховував «кількість днів відряджень працівників» і виявив, що скріншоти неповні, а дані між підрозділами не збігаються.
Це не поодинокий випадок. У багатьох компаніях країни процес затвердження проходить саме так:
- Шукати людину — питати : у перший тиждень після прийняття на роботу найчастіше питають: «Кому подавати заявку на відпустку? Хто має затвердити мої витрати?»
- Повідомлення у групі як підтвердження : у чаті WeChat або DingTalk «@Босу затверджено» вважається підтвердженням, однак пізніше це неможливо перевірити.
- Несумісність даних між підрозділами : відділ продажів вважає, що відвідування клієнтів уже затверджено, а відділ маркетингу — що ні; фінансовий відділ оплатив за скріншотом відділу продажів.
- Доступ до системи — лише на словах : коли один із менеджерів звільнився, його права не були скасовані, а новий працівник не знав, у кого знаходиться контракт, який раніше затверджував попередній менеджер.
Корінь цих проблем не у тому, наскільки складним є процес затвердження, а у тому, що потік затверджень не перенесено до системи . Повідомлення у групах, усні розмови, скріншоти — лише тимчасові засоби; не вистачає структурованого, документованого, легко відстежуваного носія. Система OA (офісна автоматизація) саме це і структурує: усі дані — «хто, яке питання, коли, до кого зверталися, за якими правилами затверджували, як після цього обробляються дані» — зводяться до одного потоку затверджень.
01 Як розкласти бізнес-процеси: тришарова структура потоку затверджень
Розкладаючи процес затвердження, насправді виділяють три шари:
- Шар питань : працівники подають конкретні заяви — «відрядження, відпустка, відшкодування витрат, договір, скріплення печаткою, закупівля» — кожна з них містить суму, кількість днів, додатки та пов’язані бізнес-об’єкти (заява на відрядження пов’язана з замовленням продажів, відшкодування — зі фактурою).
- Шар процесу : питання переймається від одного вузла до іншого, а відповідальні за затвердження визначаються динамічно (за відділом, рівнем, сумою, категорією), а не закріплені раз і назавжди.
- Шар даних : після затвердження або відхилення дані мають повернутися до бізнес-систем (відділу кадрів, фінансового відділу, відділу продажів, бази договорів), а не залишатися лише у потоці затверджень.
Взаємозв’язок трьох шарів такий: питання — це вхід, процес — це головна лінія, дані — це вихід . Якщо при створенні системи OA врахувати лише процес, але не передбачити вихід даних, потік затверджень стане островком; якщо ж зосередитися лише на питаннях, не побудувавши процес, система перетвориться на «формулярну систему».
02 Як проектувати: трикомпонентний набір — динамічні вузли, матриця прав доступу, документування
Проектування вузлів: відповідальна особа за затвердження не закріплена раз і назавжди
Багато систем OA одразу встановлюють постійних затверджувачів: «Заява на відрядження → менеджер відділу → відділ кадрів → генеральний директор». У результаті, коли менеджер відділу змінює посаду, відділ кадрів входить до адміністративного відділу, а генеральний директор відлучається, вся система приходить у хаос.
Правильний підхід: відповідальність за затвердження визначається динамічно за правилами . Зазвичай існують чотири розміри правил:
- Розмір відділу : відділ, до якого належить заявник, відповідає чинному керівникові цього відділу (визначається в реальному часі за організаційним деревом).
- Розмір рівня : сума, кількість днів, суми договорів відповідають різним діапазонам, а відповідно — різним рівням затвердження.
- Розмір ролі : якщо сума договору перевищує 500 тисяч, обов’язково залучається юридичний відділ; якщо працівник відправляється за кордон, безпека та відповідність законодавству потребують підпису.
- Розмір представника : якщо затверджувач відсутній через відпустку або відрядження, автоматично передається представнику, якого визначає організаційна структура або відділ кадрів.
Поєднуючи ці чотири розміри у «правило-вираз», двигун процесу визначає вузли в реальному часі за цими правилами, не закріплюючи імена затверджувачів. При зміні посади або організаційній реструктуризації не потрібно змінювати шаблон процесу.
Проектування прав доступу: три рівні — меню, дані, поляПрава — це не «чи можна зайти в систему», а три рівні:
- Меню-рівень : чи можна бачити цей модуль (звичайні працівники не бачать «Управління організаційною структурою»).
- Даний-рівень : чи можна бачити ці дані (відділ продажів бачить лише витрати своїх працівників, а не витрати відділу другого продажу).
- Поле-рівень : чи можна бачити окремі поля цих даних (звичайний затверджувач не бачить поле зарплати заявника, але відділ кадрів бачить).
Після розбирання трьох рівнів прав доступу система OA здатна підтримувати складну організаційну структуру: конгломерат–філія–відділ–група; міжрівневі дані контролюються за двома правилами: «Я бачу лише свою лінію + Я є керівником цієї лінії».
Проектування документування: сім елементів журналу затверджень
Кожна операція затвердження має залишати сім елементів:
- Оператор : хто натиснув.
- Час операції : точний до секунди.
- Дія операції : погодження, відхилення, передача, додатковий підпис, відкликання.
- Думка оператора : при відхиленні обов’язково вказується причина, при погодженні можна залишити пусто.
- Місце вузла : на якому етапі процесу знаходиться зараз.
- Скріншот пов’язаних даних : під час затвердження значення полів бізнес-об’єктів (суми, додатки) зберігаються в первісному вигляді, не допускається пізніше змінювати бізнес-об’єкти, залишаючи записи затверджень незмінними.
- Сліди пристрою та IP : з якого пристрою, з якого IP надійшло повідомлення (для контрольно-ревізійних потреб).
Якщо хоча б один із цих семи елементів відсутній, під час аудиту завжди виникають суперечки. Звичайна помилка — «думка оператора можна залишити пустою», у результаті відхилення залишається без причини, працівники повторюють прохання, а потік затверджень доводиться розтягувати.
03 Як розробляти: трикомпонентний набір — двигун процесу, двигун форм, шина повідомлень
Основа розробки системи OA — три двигуни, а не N сторінок:
Двигун процесу
Двигун процесу не пише код, а працює за допомогою конфігурації. Необхідні характеристики:
- Послідовний, паралельний, підпис, або підпис : чотири основні типи потоків; заявка на прийом на роботу — послідовний (відділ кадрів → керівник → генеральний директор), закупівля — паралельний (фінансовий відділ і керівник закупівель одночасно затверджують).
- Розгалуження за умовами : розподіл за сумою, категорією, рівнем заявника; до 5 тисяч — простий потік, від 5 до 50 тисяч — подвійне затвердження відділу та фінансового відділу, понад 50 тисяч — додатково генеральний директор.
- Відкликання та відхилення: підтримується три типи відхилення — повернення до заявника, повернення до будь-якого вузла, або повернення до попереднього вузла.
- Додавання підписів та пересилання: затверджувач може передати завдання колезі (пересилання), а також залучити ще одного колегу для спільного розгляду (додавання підпису).
- Скасування та анулювання: заявник може скасувати справу, яка ще не була затверджена; адміністратор може анулювати надзвичайні справи.
було додано новий тип затвердження, який не потребує написання коду, — достатньо лише намалювати схему та налаштувати форму, і система одразу ж запускається. Саме це є ключовою відмінністю OA від «зовнішнього розроблення системи затвердження».
Двигун формФорми повинні мати «нульовий кодовий дизайн»: типи полів (текст, число, дата, вкладення, зв’язок з бізнес-об’єктами), правила перевірки, обов’язкові та необов’язкові поля, умови показу/схову — все налаштовується візуально шляхом перетягування. Таким чином, HR може змінювати поля для компенсації, а відділ продажів — додавати поля для контрактів, і при цьому
не потрібно планувати робочий час IT.
Двигун форм має підтримувати:
- Права доступу на рівні поля: для однієї й тієї ж форми різні затверджувачі бачать різні поля (звичайний затверджувач не бачить номер телефону заявника).
- Пов’язані поля : при виборі «Тип договору = Договір про надання послуг» автоматично розкриваються поля, специфічні для договорів про надання послуг.
- Запис даних назад : після затвердження автоматично записується назад у бізнес‑систему (стан договору, облік праці, фінансові документи).
Меседж‑бус
При затвердженні або відхиленні заявник і відповідні бізнес‑системи (HR, фінанси, продажі) одразу отримують сповіщення. Уніфікована розсилка через меседж‑бус:
- Системне сповіщення : внутрішнє повідомлення плюс справи до виконання.
- IM‑сповіщення : webhook для Enterprise WeChat, DingTalk, Feishu — повідомлення надсилаються у відповідні групи або окремим користувачам.
- Електронна пошта та SMS : резервне сповіщення на важливих етапах (затвердження договору, закордонна командировка).
- Повідомлення бізнес‑системи : після затвердження система записує повідомлення до списку справ до виконання в бізнес‑системі (фінанси отримують справу про відшкодування, HR — справу про прийняття на роботу).
Меседж‑бус — це не «прикраса», а «замкнуте коло» процесу затвердження: без сповіщень заявник не знає, до кого звертатися далі, і весь процес зависає.
Підсумок: порядок реалізації, ризики та показники
Введення OA‑системи відбувається у три етапи:
- Перший етап (1 місяць) : запровадити три найпоширеніші операції — відпустки, командировки та відшкодування — охопивши всіх співробітників. Спочатку перенести процедури затвердження з груп у месенджерах у систему , навіть якщо це лише три операції — дані між відділами одразу стануть узгодженими.
- Другий етап (2–3 місяці) : запровадити чотири середньочастотні операції — договір, складання печатки, закупівлі та оплату — інтегрувати з фінансовою системою. На цьому етапі потрібно забезпечити автоматичний запис даних назад (після затвердження договору він автоматично архівується у базі договорів).
- Третій етап (за потребою) : запровадити повний процес управління персоналом — оцінка результатів, підвищення, переведення на постійну роботу, набір, звільнення тощо. Цей етап очолює HR, потрібно забезпечити інтеграцію основних даних HR.
Поширені ризики:
- Надмірна гнучкість правил : конфігурація процесу затвердження занадто вільна, у результаті ніхто не знає, хто буде наступним. Принцип: шаблони процесів не повинні перевищувати 30 пунктів , інакше контроль втрачається.
- Недостатнє призначення замінника : якщо затверджувач у командировці не призначив замінника, процес зависає на 3 дні без жодного затвердження. Система автоматично сповіщає, якщо процес зависає більше ніж 24 години.
- Невідповідність запису даних назад : після затвердження в системі HR не оновлено облік праці, а у фінансовій системі немає відповідного документа. Запис назад має пройти «подвійну перевірку»: після запису в OA система самостійно звертається до інтерфейсу бізнес‑системи, щоб підтвердити отримання.
Показники успішності проекту:
- Середній час завершення затвердження : до введення в експлуатацію — 3 дні в групі, після — 1 день у системі, щоб замкнути цикл.
- Узгодженість даних між відділами : помилки у звірці трьох систем — HR, фінансів, продажів — зменшилися більш ніж на 80%.
- Рівень прослідковуваності аудиту : випадково відібрали 20 минулих процедур затвердження, і 100% виявилися повністю завершеними за всіма семи ключовими елементами.
Перенесення процесу затвердження з груп у месенджерах у систему — це не просто «переход до системи», а скоріше перетворення «пошуку людини» з залежності від конкретної особи на залежність від правил . Якщо правила чітко записані, незалежно від того, хто звільняється або як змінюється організація, процес затвердження залишатиметься стабільним.