Як програміст Олег Моргоч автоматизував білінг у США за допомогою ШІ

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

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

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

Попередній код було написано мовою VB.NET, яку в корпоративній розробці використовують дедалі рідше. За допомогою GitHub Copilot інженер переніс програму на C# — поширенішу мову тієї самої платформи .NET — та оптимізував внутрішню логіку. Для роботи з кодом він обрав одну з моделей OpenAI, яка, за його оцінкою, найкраще справлялася із завданнями. Окремо Моргоч створив допоміжний інструмент, що автоматично запускав і перевіряв звіти всіх клієнтів. Найбільше технічних труднощів виникло саме на перевірці даних: після формування файлу система мала підтвердити, що це звіт потрібного клієнта і що в ньому перелічено виконані замовлення.

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

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

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

Подальші плани Олега викладені в бізнес-плані BillingBridge AI: платформа має підключати застарілі білінгові системи до API, хмарних сервісів і аналітики без повної заміни ERP чи бухгалтерської інфраструктури. Серед потенційних ринків у документі названо Північну Америку та Європу.