Автоматизація бізнесу: що це насправді означає і з чого почати

Автоматизація — це коли дані вводять один раз

Слово стерлося. Автоматизацією називають і розсилку, і чат-бота, і кнопку “згенерувати звіт”. Через це підприємцю важко зрозуміти, за що він платить і що саме зміниться в понеділок вранці.

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

Подивіться на звичайне замовлення. Клієнт пише в Telegram. Менеджер копіює його в таблицю. Питає склад, чи є товар. Створює ТТН у кабінеті перевізника. Переносить номер накладної назад у таблицю. Бухгалтер шукає оплату у виписці й позначає замовлення оплаченим.

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

Скільки коштує ручний крок

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

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

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

Третя — швидкість. Клієнт не знає, скільки у вас сервісів. Він бачить тільки те, як швидко ви відповіли, чи справдилася наявність і чи прийшов номер накладної без нагадування.

Що система робить сама вже сьогодні

У FEMIX автоматизація — не окремий модуль, який треба вмикати. Це те, як влаштований наскрізний шлях замовлення. Ось конкретні кроки, які відбуваються без людини.

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

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

ТТН Нової Пошти створюється з картки замовлення разом із друком етикетки і накладеним платежем. Статуси доставки оновлюються самі кожні півгодини — ніхто не заходить у кабінет перевізника перевіряти.

Прихід товару одночасно рухає склад, перераховує партії за собівартістю і створює проводки в журналі. Платіж розноситься по рахунках і сам переводить замовлення з “не оплачено” в “частково” або “оплачено”.

Сповіщення йдуть за подією, а не за розкладом: у Telegram, у браузер або на пошту, коли справді щось сталося. Замовлення з OpenCart і Rozetka приходять у ту саму обробку, а залишки й ціни повертаються на майданчик.

Чому це надійно, а не “іноді спрацьовує”

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

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

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

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

З чого почати: три кроки, які окупаються першими

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

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

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

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

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

Чого автоматизація не робить

Вона не виправляє процес, якого немає. Якщо в компанії немає домовленості, хто відповідає за клієнта після продажу, система не вигадає її за вас — вона лише швидше покаже, що її немає.

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

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

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

Куди це йде: окремий рушій процесів

Сьогодні наскрізні процеси у FEMIX описані в коді. Це надійно, але означає, що новий процес під конкретний бізнес додаємо ми, а не власник.

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

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

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