Олександр Аблаєв: «Автоматизація необхідна бізнесу, але вирішальною є послідовність її впровадження»
Компанії по всьому світу вкладають значні бюджети у цифрові інструменти управління: CRM-системи, ERP-платформи та системи проєктного управління. Очікування просте — впровадження технологій наведе порядок в операційній діяльності, проте на практиці цифровізація нерідко лише робить проблеми більш видимими, не усуваючи їх.
Олександр Аблаєв — підприємець та автор методології ARM (Architecture for Renovation Management) — системного фреймворку, який структурує управління бізнесом через архітектуру процесів, від розбиття послуг на вимірювані елементи до автоматизації клієнтської взаємодії.
Методологію Олександр розробив на основі досвіду управління виробничою компанією у Чеській Республіці, де за два роки на керівній посаді він трансформував мікропідприємство з п’ятьма працівниками у серійне виробництво зі штатом 20 осіб, щомісячним обсягом понад 100 одиниць продукції та тижневим оборотом понад мільйон чеських крон у пікові періоди. Нещодавно він заснував будівельно-реноваційну компанію Alex Renovation у США, де ARM впроваджується як базова операційна архітектура з першого дня роботи.
Компанії активно інвестують у корпоративні системи управління, але часто не бачать очікуваного ефекту. У чому причина?
Поширена помилка полягає у сприйнятті автоматизації як універсального засобу боротьби з операційним хаосом. Насправді технології лише масштабують процеси. Неефективна модель роботи після автоматизації починає працювати швидше, але не краще. CRM лише фіксує всі дані у цифровому вигляді, роблячи їх більш помітними та зрозумілими.
Технології лише масштабують процеси. Неефективна модель роботи після автоматизації починає працювати швидше, але не краще.
Наведу конкретний приклад. У виробничій компанії, якою я керував у Чехії, на момент мого приходу облік замовлень вівся частково в таблицях, частково в усній формі. Першим кроком могло б стати впровадження CRM, але проблема полягала в тому, що сам процес обробки замовлень не був стандартизований, тобто не існувало єдиної послідовності дій від прийому замовлення до відвантаження готового продукту. Впровадження CRM на цьому етапі лише оцифрувало б хаос, таким чином система просто акуратно зберігала б дані, які все одно ніхто не зміг би ефективно використовувати. Тому в методології ARM технології підключаються лише після того, як процеси описані, стандартизовані та перевірені в реальній роботі.
Чи означає це, що автоматизація не потрібна?
Формальне впровадження без адаптації до реальної логіки роботи не створює цінності, а навпаки надає додаткове навантаження на команду.
Автоматизація залишається необхідною складовою розвитку бізнесу, проте вирішальне значення має послідовність впровадження. В ARM ця послідовність чітко визначена. Спочатку потрібно зафіксувати, як процес працює фактично: хто виконує яку роботу, в якому порядку, які рішення приймає і на основі чого. Далі цей процес стандартизується: фіксуються етапи, визначаються відповідальні, встановлюються критерії результату. І лише після того, як стандартизований процес перевірений у реальній роботі, доцільно підключати технології.
Без цього етапу навіть найдорожчі ERP-системи залишаються неефективними. Уявіть ситуацію: компанія купує систему обліку замовлень, але в реальності процес починається з телефонного дзвінка, де клієнт ще не знає половини деталей — ні точних обсягів, ні термінів, ні бюджету. Система вимагає заповнити десять полів для створення замовлення, а менеджер має лише ім’я і загальний опис запиту. Він змушений або вигадувати дані, або обходити систему і вести записи окремо. Формальне впровадження без адаптації до реальної логіки роботи не створює цінності, а навпаки надає додаткове навантаження на команду.
Які помилки трапляються найчастіше?
Бізнес купує систему, успішну в іншій галузі, і очікує аналогічного результату без урахування власної специфіки. У реальності ефективність з’являється лише тоді, коли система налаштовується під процеси, а не навпаки.
Ефективність з’являється лише тоді, коли система налаштовується під процеси, а не навпаки.
Також варто розуміти, що доступ до системи не дорівнює готовності з нею працювати. Професійний софт без контексту не працює, як і будь-який складний інструмент без підготовки.
У методології ARM значну увагу приділено прозорості. Яку роль вона відіграє?
Прозорість є фундаментом будь-якої автоматизації. Система здатна працювати лише з чітко визначеними процесами. Усна передача знань, індивідуальні інтерпретації та відсутність стандартів унеможливлюють ефективну цифровізацію.
Ми використовуємо підхід, який я називаю атомарною декомпозицією. Це розбиття будь-якого складного процесу на найменші можливі операції, кожна з яких має чіткий початок, дію та результат.
У рамках ARM використовується підхід, який я називаю атомарною декомпозицією. Це розбиття будь-якого складного процесу на найменші можливі операції, кожна з яких має чіткий початок, дію та результат.
Поясню на прикладі. Процес «ремонт ванної кімнати» для клієнта виглядає як одне завдання з однією ціною, але під час декомпозиції він розпадається на десятки елементарних операцій: демонтаж старої плитки, гідроізоляція поверхні, підготовка стяжки, укладання нової плитки, затирка швів і далі. Кожна з цих операцій має конкретну вартість, нормативний час виконання та критерії приймання результату.
Такий аналіз відразу показує, які операції піддаються автоматизації на рівні планування, а де потрібне рішення фахівця на місці. Наприклад, розрахунок необхідної кількості матеріалу для гідроізоляції — це стандартна операція, яку система може виконати автоматично за формулою. Однак вибір способу демонтажу залежить від стану конструкції, яку може оцінити лише спеціаліст безпосередньо на об’єкті. Спроба автоматизувати все одразу без такого розмежування призводить до надмірно складних і нестійких систем.
У CADEMA s.r.o. ми пройшли через цей аналіз для кожного типу дерев’яного будинку: розклали виробництво на елементарні операції, визначили, які з них повністю стандартні, а які потребують індивідуального рішення майстра. Результатом став вихід на обсяг понад 100 одиниць продукції на місяць, бо автоматизувалося лише те, що дійсно піддавалося стандартизації, а людський ресурс зосереджувався на задачах, де він незамінний.
Ви створили власну AI-систему автоматизації. У чому її відмінність?
Вона розроблялася як надбудова над конкретним процесом. В основі — детальний аналіз реального клієнтського шляху — від першого звернення до прийняття рішень.
Повторювані операції з чіткою логікою, а саме первинна кваліфікація запиту, надання стандартної інформації, планування контакту, були винесені в автоматизований контур.
Повторювані операції з чіткою логікою були винесені в автоматизований контур.
Таким чином менеджер отримує структурований запит з повним контекстом, що дозволяє одразу переходити до предметної взаємодії. Економічний ефект формується завдяки попередній структуризації процесу.
Розробити таку систему мені дозволила комбінація управлінського та технічного досвіду. У мене магістерський ступінь у галузі автоматизованого управління технологічними процесами, а також професійні сертифікації у SQL, Python та інструментах візуалізації даних — Tableau і Power BI.
Але головне — я будував цю систему не як окремий IT-продукт, а як складову ARM. Спочатку формалізував процес роботи з клієнтами, описав кожен етап від першого звернення до підписання договору. Потім визначив, які етапи повторюються і мають чітку логіку — саме їх можна передати машині. І лише після цього реалізував технічне рішення. Вартість обробки одного вхідного запиту в цій системі становить кілька центів, тоді як ринкова норма за один кваліфікований лід (потенційний клієнт, який підтвердив зацікавленість у послузі) — десятки доларів.
Як впливає використання кількох систем одночасно?
Технічна інтеграція систем між собою можлива лише після того, як в усіх підрозділах уніфіковано процеси і термінологію.
Розрізнені цифрові середовища створюють ефект ізольованих «островів». Дані з CRM не доходять до виробництва, а фінансові системи не бачать актуального статусу проєктів. У результаті співробітники витрачають час на ручну синхронізацію інформації. Методологія ARM передбачає принцип єдиного джерела істини для кожного типу даних.
Технічна інтеграція систем між собою можлива лише після того, як в усіх підрозділах уніфіковано процеси і термінологію.
В Alex Renovation, яку я заснував у США, ARM впроваджується з першого дня саме за цим принципом. CRM-система, автоматизовані робочі процеси на базі платформи n8n та серверна інфраструктура побудовані як єдина взаємопов’язана система, де кожен тип даних має одне джерело. Мій досвід у Чехії показав, наскільки дорого обходиться об’єднання розрізнених систем постфактум, тому в новому бізнесі архітектура даних закладалася ще на етапі проєктування компанії.
Які сигнали свідчать про системну проблему?
Найпростіший індикатор — поведінка команди. Компанія заплатила за CRM, але менеджери продовжують вести свої записи у Google-таблицях або блокнотах. Це означає, що система не відповідає тому, як робота відбувається насправді.
Другий сигнал — заповнення системи перетворюється на окрему задачу. Наприклад, після кожного дзвінка менеджер витрачає п’ять хвилин на ручне внесення інформації у CRM: вписує ім’я клієнта, адресу об’єкта, тип запиту, бажаний бюджет. При двадцяти дзвінках на день — це майже дві години чистого часу на введення даних, які потім ніхто не аналізує і не використовує для управлінських рішень.
Спочатку варто усунути хаос у процесах, а вже потім автоматизувати те, що залишилося.
Третій маркер — постійні запити на доопрацювання: «нам потрібен ще один звіт», «додайте нове поле», «зробіть ще одну форму». Зазвичай це вказує на помилки у базовій архітектурі процесів. У CADEMA s.r.o. я зіткнувся з подібним. Перш ніж впроваджувати цифрові інструменти, ми стандартизували самі процеси, і виявилося, що значна частина «необхідних функцій» зникла. Потреба в них була наслідком хаотичної організації роботи. Тому при створенні ARM я зафіксував цей принцип, адже спочатку варто усунути хаос у процесах, а вже потім автоматизувати те, що залишилося.
Який підхід ви рекомендуєте?
Оптимізація передує автоматизації. Лише після цього варто обирати технологію, орієнтуючись на відповідність процесу.
Початковим етапом має стати картування процесів. Детальний опис одного критичного процесу дозволяє виявити вузькі місця, дублювання та зони ризику. Оптимізація передує автоматизації. Лише після цього варто обирати технологію, орієнтуючись на відповідність процесу. Часто прості системи з правильним налаштуванням працюють ефективніше за складні enterprise-платформи.
За три роки керівництва виробничою компанією в Чехії та при запуску нового бізнесу в США я переконався, що компанії, які починають з процесів, а не з технологій, досягають результату швидше і з меншими витратами. У компанії загальна прибутковість бізнесу зросла більш ніж на 62%, компанія вийшла на загальнонаціональний ринок Чехії та організувала постачання до сусідніх країн. Основою цього зростання була структурна перебудова операційної моделі за принципами, які згодом стали фундаментом ARM. Технології підключилися пізніше, коли вже було зрозуміло, що саме вони мають автоматизувати.
