- Використання абстрактних синтаксичних дерев дозволяє моделювати та візуалізувати робочі процеси програмного забезпечення, сприяючи їх валідації, переносимості та автоматизованому аналізу.
- Рішення для тестування безпеки додатків (SAST, DAST, IAST, MAST, SCA, RASP та ASTO) охоплюють різні фази життєвого циклу додатків для виявлення та усунення вразливостей.
- Статичний аналіз коду та передові методи управління інформаційними потоками вимагають інтерналізації коду в якісному AST, подолання синтаксичних та семантичних неоднозначностей.
- Паралельно, автоматизація процесів за допомогою RPA та аналізу безпеки роботи застосовують ту саму філософію розбиття потоків для підвищення безпеки, ефективності та контролю.
Коли ми говоримо про AST у коді робочих процесів , ми фактично об'єднуємо кілька світів, які, хоч і здаються розрізненими, все більше взаємопов'язані: традиційна розробка програмного забезпечення , безпека додатків, автоматизація процесів за допомогою RPA, генерація коду за допомогою штучного інтелекту і, що цікаво, навіть запобігання професійним ризикам. Все це обертається навколо того, як ми моделюємо, аналізуємо, автоматизуємо та захищаємо робочі процеси, що керують складними системами.
Абстрактні синтаксичні дерева (AST) стали ключовим інструментом для розуміння та перетворення коду, автоматизації аудитів, створення тестів, посилення безпеки та навіть графічного представлення бізнес-процесів. Водночас абревіатура AST охоплює такі концепції, як тестування безпеки додатків (Application Security Testing) та аналіз безпеки роботи (Job Security Analysis), які вказують на іншу основну ідею: взяти робочі процеси (програмні чи людські) та піддати їх систематичному аналізу для виявлення недоліків, ризиків та можливостей для покращення.
AST як абстрактне синтаксичне дерево в робочих процесах та генерації коду
У розробці програмного забезпечення на замовлення використання абстрактних синтаксичних дерев (AST) дозволяє перейти від непрозорого коду до візуальних та зрозумілих структур, які точно описують логіку робочого процесу. AST розбиває програму на вузли, що представляють операції, структури керування, виклики функцій, дані та зв'язки між ними, так що логіка перестає бути «вільними рядками коду» та перетворюється на навігаційний граф.
Таке представлення особливо корисне під час керування агентами штучного інтелекту або розподіленими архітектурами, де робочі процеси є складними та важко їх розумово відстежувати. Перетворюючи код робочого процесу на AST (автоматичний аналіз програмного забезпечення), можна створювати діаграми, які інтуїтивно показують гілки рішень, залежності компонентів, порядок виконання та критичні точки процесу, що спрощує розробку, перевірку та прийняття технічних рішень.
Компанії, що спеціалізуються на програмному забезпеченні на замовлення, такі як Q2BSTUDIO , використовують ці синтаксичні дерева для перетворення складних робочих процесів на доступні, візуально зрозумілі та, перш за все, функціонально корисні діаграми. Йдеться не лише про «креслення рамок», а про структуровану модель, яку можна використовувати для вдосконалення алгоритмів, виявлення вузьких місць, локалізації логічних помилок та прокладання шляху для майбутніх оптимізацій.
Великою перевагою AST у цьому контексті є те, що він не залежить від кінцевої мови програмування . З одного й того ж дерева потік можна компілювати або перетворювати на різні мови чи платформи (наприклад, різні хмарні середовища виконання, такі як AWS або Azure), зберігаючи при цьому узгоджену бізнес-логіку. Це дозволяє створювати більш гнучкі, портативні та зручні в обслуговуванні архітектури, де ядро процесу визначається абстрактно, а виконуваний код є контрольованим походженням.
Ще одним ключовим моментом є повторне використання вузлів в AST . Можна визначити логічні блоки (наприклад, перевірки вхідних даних, шаблони доступу до даних або механізми аудиту), які повторно використовуються як безпечні та вже перевірені компоненти. Якщо ці вузли також відомі штучному інтелекту, що генерує код, він може посилатися на них, замість того, щоб винаходити їх з нуля, що значно підвищує безпеку та узгодженість згенерованого програмного забезпечення.
Генерація ознак на основі AST та штучного інтелекту: безпека, валідність та довіра
Поява моделей штучного інтелекту, що генерують код, відкрила новий фронт : як ми можемо довіряти функціям, написаним штучним інтелектом, не перевіряючи кожен рядок вручну? Надійним рішенням є не прямий запит «виконуваного коду», а структуроване представлення логіки за допомогою AST (Automatic Support Tool), яке потім перевіряється та перетворюється на код за допомогою надійного інструменту.
Працюючи з AST замість простого коду , ШІ генерує вузли, операції, структури керування та потоки даних, які можна автоматично аналізувати: типи, шляхи виконання, узгодженість параметрів, обробка помилок, граничні умови та інші властивості перевіряються перед тим, як потрапити до компілятора або інтерпретатора. Цей фільтр різко знижує ризик виконання шкідливого або просто неправильного коду.
Q2BSTUDIO та інші організації, що досліджують ці методи, приділяють особливу увагу забезпеченню відстежуваності та перевірки логіки, згенерованої штучним інтелектом. AST (автоматизований системний аналіз) стає «проміжною істиною», до якої застосовуються правила безпеки, стандарти якості, внутрішні політики та аналіз впливу. Таким чином, кожна згенерована функція вписується в бібліотеку безпечних вузлів, використовуючи попередньо перевірені елементи.
Такий підхід також відкриває шлях до багатоцільових збірок : з одного AST можна генерувати код різними мовами (наприклад, Python для мікросервісів, C# для внутрішніх сервісів або спеціалізовані скрипти для хмарних оркестраторів). Для компаній, що працюють у гібридних або мультихмарних середовищах, це особливо привабливо, оскільки гарантує узгодженість бізнес-потоку незалежно від кінцевого стеку.
Зрештою, використання вузлів багаторазового використання в AST дозволяє створювати сертифіковані «логічні бібліотеки». Замість того, щоб винаходити шаблони доступу до бази даних, перевірки безпеки або трасування журналів, ШІ конструює їх з цих будівельних блоків, покращуючи як безпеку, так і продуктивність, а також полегшуючи подальшу аналітику в таких інструментах, як Power BI або інших платформах бізнес-аналітики.
AST, застосований до інтелектуального тестування на Python та максимального покриття коду
AST також є основою передових рішень для автоматизованого тестування , таких як певні набори інструментів з відкритим кодом для Python, які використовують структуру коду для створення наборів тестів із набагато вищим покриттям, ніж зазвичай досягається шляхом написання їх вручну.
Цей тип інструменту поєднує три основні можливості : автоматичну генерацію модульних тестів для певного файлу Python, керований фаззинг для обробки критичних функцій екстремальними та неправильно сформованими вхідними даними, а також генерацію тестів, орієнтовану на покриття, де AST ретельно аналізується для виявлення всіх можливих гілок, циклів, умов та шляхів винятків.
Ключовим є те, що інструмент створює AST (аналоговий тестовий ресурс) коду Python та на його основі визначає шляхи виконання, які ще не охоплені тестами. Маючи цю інформацію, він доручає моделі штучного інтелекту (наприклад, Gemini) створити тестові випадки, спеціально розроблені для активації кожного шляху. Потім він виконує тести та вимірює охоплення за допомогою таких інструментів, як coverage.py, таким чином завершуючи автоматизований цикл безперервного вдосконалення.
Такий підхід не просто генерує початкову партію тестів ; він дозволяє ітерацію та вдосконалення. Якщо після першого раунду залишаються маршрути, які не були протестовані, вони повторно перевіряються за допомогою AST (Advanced Test Assay), і нові випадки запитуються у штучного інтелекту. Це робить процес адаптованим як до нового коду, так і до застарілих кодових баз з мінімальним попереднім тестуванням або без нього.
Проєкт налаштовано як сервер MCP (Model Context Protocol) , тому він функціонує як локальний сервіс, який можна викликати з редактора або командного рядка. Використання BAML гарантує, що згенерований тестовий код відповідає точному формату, його легко аналізувати та не порушує роботу інструментів безперервної інтеграції, які його використовують.
AST як аналіз безпеки праці: безпечні потоки в робочому середовищі
Під тією ж абревіатурою AST ми знаходимо ще одну широко використовувану концепцію в запобіганні професійним ризикам: аналіз безпеки роботи. Хоча він працює на іншому рівні, ніж код, він поділяє з абстрактними синтаксичними деревами ідею розбиття потоку (в цьому випадку людських завдань) на етапи, виявлення ризиків та визначення контролю перед виконанням.
Аналіз безпеки праці – це профілактичний процес, який застосовується переважно до видів діяльності з високим рівнем ризику, таких як робота на висоті, керування складним обладнанням або поводження з небезпечними речовинами. Робочий процес розбивається на кроки, і для кожного кроку визначаються конкретні небезпеки, оцінюється рівень ризику та визначаються заходи контролю (ЗІЗ, вивіски, інструкції на випадок надзвичайних ситуацій тощо).
Ключові переваги оцінки безпеки праці на робочому місці включають зменшення кількості нещасних випадків, покращення дотримання нормативних вимог, підвищення операційної ефективності та зміцнення культури безпеки. Чіткий розподіл робіт зменшує імпровізацію, запобігає перебоям у роботі через інциденти та знижує витрати, пов'язані з травмами, штрафами або зупинками виробництва.
Типова процедура проведення JSA у робочому середовищі включає: точне визначення завдання та його контексту (довкілля, обладнання, матеріали), поділ його на етапи, виявлення небезпек та ризиків на кожному етапі (падіння, вплив хімічних речовин, защемлення, відмови обладнання), встановлення конкретних заходів контролю, комунікацію та навчання залучених працівників, а також проведення постійного моніторингу та подальших дій для коригування аналізу у разі зміни умов.
Щоб цей аналіз був справді ефективним, доцільно використовувати матриці ризиків, контрольні списки та, все частіше, цифрові інструменти, які сприяють документуванню, моніторингу та відстеженню вжитих заходів. Консалтингові фірми, такі як GMS Consulting, інтегрують ці аналізи безпеки праці (JSA) у системи управління, такі як ISO 45001, допомагаючи організаціям проходити внутрішні та зовнішні аудити та підтримувати цикл постійного вдосконалення безпеки та гігієни праці.
Тестування безпеки застосунків (AST): SAST, DAST, IAST, MAST та інші
У сфері кібербезпеки AST зазвичай позначає тестування безпеки додатків (Application Security Testing ), тобто набір методів та інструментів, спрямованих на виявлення вразливостей у сучасних додатках, адаптуючи їх до гнучких методологій та зростаючої складності програмного забезпечення.
Рішення AST є основою будь-якої надійної програми AppSec , оскільки ручні перевірки коду та традиційні плани тестування є повільними та погано масштабуються до постійної появи нових вразливостей. Крім того, численні нормативні акти та нормативні бази (такі як PCI-DSS, серед інших) чітко вимагають використання таких інструментів.
У рамках тестування безпеки додатків сьогодні можна виділити кілька основних категорій : статичний аналіз (SAST), динамічний аналіз (DAST), інтерактивні та гібридні методи (IAST), тестування, орієнтоване на мобільні додатки (MAST), та інші додаткові сервіси, такі як SCA, RASP, виявлення додатків, тестування як послуга або інструменти кореляції та покриття.
Технологія статичного AST (SAST) аналізує код у стані спокою (вихідний код, байт-код або двійковий файл) під час фаз програмування та тестування життєвого циклу розробки програмного забезпечення. Це вважається тестом "білої скриньки", оскільки аналітик має доступ як до коду, так і до дизайну програми. Ці інструменти шукають слабкі місця, такі як числові помилки, проблеми перевірки вхідних даних, умови гонки, небезпечні посилання, переповнення тощо.
З іншого боку, технологія динамічного AST (DAST) зосереджена на запущеному застосунку , зазвичай у контрольованих тестових або виробничих середовищах. Імітовані атаки запускаються ззовні для виявлення таких проблем, як ін'єкції, збої автентифікації, погане керування сеансами, помилки інтерфейсу або проблеми з обробкою відповідей. Це підхід "чорної скриньки", де не передбачається знання внутрішнього коду.
Технології IAST поєднують найкраще від SAST та DAST . Додаток оснащений інструментами (наприклад, за допомогою агента в JVM або .NET CLR) для спостереження за його поведінкою зсередини під час виконання динамічних тестів. Це дозволяє корелювати потоки даних і виконання, розуміти, чи є теоретична вразливість насправді доступною для використання, та зменшувати кількість хибнопозитивних результатів шляхом перевірки результатів на льоту.
MAST, або тестування безпеки мобільних додатків , застосовує поєднання статичного, динамічного та криміналістичного аналізу, спеціально для додатків iOS та Android, включаючи їхні серверні компоненти. Ці рішення приділяють особливу увагу таким сценаріям, як рутовані або розблоковані пристрої, підроблені мережі Wi-Fi, неправильне керування сертифікатами, витоки конфіденційних даних та інші характеристики мобільного середовища.
Додаткові послуги: SCA, RASP, виявлення, бази даних та оркестрація ASTO
Багато постачальників послуг AST розширили свої пропозиції ключовими додатковими послугами , щоб охопити всю екосистему безпеки додатків та управління ризиками кібербезпеки , від створення програмного забезпечення до створення баз даних та оркестрації всіх інструментів.
Аналіз складу програмного забезпечення (SCA) зосереджується на виявленні сторонніх компонентів та компонентів з відкритим кодом, що містяться в програмі, та порівнянні їх з відомими базами даних вразливостей, такими як NIST NVD, CVE та комерційними репозиторіями, такими як VulnDB. Ці інструменти можуть виявляти застарілі версії або ті, що мають очікують оновлення безпеки, але зазвичай вони не виявляють вразливості у власному коді програми.
RASP (Runtime Application Self-Protection – самозахист програми під час виконання) виводить інструментарій на новий рівень, використовуючи методи, подібні до IAST, для моніторингу запущеної програми та блокування атак у режимі реального часу, певною мірою конкуруючи з традиційними WAF. Багато команд починають з активації інструментарію лише для діагностичних цілей (режим IAST), а коли вони впевнені в результатах, переходять у режим RASP з ефективним блокуванням атак.
Також актуальною є можливість виявлення застосунків , яка аналізує веб-екосистему організації та знаходить усі відкриті сайти та сервіси, включаючи ті, що були забуті, але залишаються потенційною точкою входу.
На рівні даних інструменти аналізу безпеки баз даних перевіряють версії, виправлення, конфігурації, паролі, політики доступу та інші вразливості як для даних, що зберігаються, так і, в деяких продуктах, для даних, що передаються. Це надзвичайно важливо, оскільки багато вразливостей, які можна використати, виникають через погане управління базою даних, а не через недоліки в коді програми.
Модель ASTaaS (тестування безпеки додатків як послуга) передає частину або весь процес тестування безпеки спеціалізованому постачальнику, поєднуючи статичний та динамічний аналіз, тестування на проникнення, оцінку API та аналіз ризиків. Вона особливо приваблива в хмарних середовищах, де налаштування та масштабування тестових середовищ простіші.
Щоб впоратися з потоком результатів, отриманих від різних інструментів, з'явилися рішення для кореляції результатів та аналізатори покриття. Перші об'єднують та пріоритезують вразливості, виявлені різними рішеннями, такими як SAST, DAST, IAST, MAST тощо, тоді як другі вимірюють, який відсоток коду або логічних гілок фактично було протестовано, допомагаючи встановити прийнятні пороги якості та виявити нетестований код.
Зрештою, оркестрація тестування безпеки додатків (ASTO) пропонує інтегрувати всі ці інструменти скоординованим чином у життєвий цикл розробки програмного забезпечення (SDLC) та конвеєри CI/CD з централізованим управлінням політиками, виконанням та звітністю. Хоча це все ще галузь, що розвивається, вона задовольняє потребу максимально автоматизувати тестування безпеки, не уповільнюючи темпи розробки.
Статичний аналіз вихідного коду, орієнтований на безпеку: стандарти, методи та проблеми
Статичний аналіз вихідного коду з акцентом на безпеку є дедалі більшою вимогою для організацій, які прагнуть дотримуватися стандартів безпечної розробки та найкращих практик. Такі фреймворки, як CLASP, OpenSAMM, Touchpoints та Microsoft SDL, чітко інтегрують цей етап у життєвий цикл розробки, підкріплюючи концепцію «безпеки за проектом».
Такі методології, як OWASP та безпечні фреймворки SDLC, надають конкретні рекомендації щодо виконання статичного аналізу, визначення критеріїв перевірки, використання результатів та зіставлення висновків з такими еталонами, як OWASP Top 10 (XSS, SQL-ін'єкції, включення файлів тощо). Існуючі інструменти SAST — як комерційні, так і з відкритим кодом — значною мірою покладаються на теорію компіляторів, AST та аналіз потоку інформації для вилучення корисних знань з коду.
Серед елементарних методів можна згадати розширений grep (пошук шаблонів та можливих секретів у звичайному тексті), перевірку відступів та структури, аналіз потоку даних для відстеження життя змінної від її визначення до використання, поширення констант для оцінки впливу незмінних значень та аналіз псевдонімів або вказівників для розуміння непрямих посилань у мовах низького рівня.
На рівні класифікації результатів корисно розрізняти помилки (відхилення між тим, що задумав програміст, і тим, що програмне забезпечення насправді робить), порушення найкращих практик або мовних правил (неідеальний код) та вразливості, що розуміються як підмножина проблем, що впливають на безпеку. Фрагмент коду може бути одночасно помилкою та порушенням, і все одно не бути придатним для використання через додаткові рівні безпеки.
Серйозною проблемою є те, що багато популярних інструментів SAST (таких як PMD, SonarQube або FindBugs) більше зосереджені на якості коду, ніж на чистій безпеці, і їхній повний потенціал реалізується, коли вони інтегровані з самого початку проекту, що трапляється не завжди. У середовищах, де перевіряється існуючий код, часто написаний третіми сторонами, ці інструменти можуть не давати результатів, що робить необхідним створювати власні аналізатори, адаптовані до потреб команди.
Процес побудови статичного аналізатора зазвичай організований як конвеєр: починаючи з вихідного коду (згенерований код, бінарні файли або машинний код не входять до цієї категорії), виконується процес інтерналізації для створення абстрактної моделі, що відповідає оригінальному коду (зазвичай збагачена AST), виводяться моделі сутностей та виконання, застосовуються методи аналізу і, нарешті, генеруються звіти. Якість усього процесу критично залежить від фази інтерналізації.
Інтерналізація та генерація AST: фронтенди, граматики та неоднозначності
Етап інтерналізації має на меті перетворення вихідного коду в структуру, якою може керувати синтаксичний аналізатор, зазвичай AST або подібний граф. Цього можна досягти за допомогою фронтендів існуючих компіляторів (таких як GCC для C, Mono для .NET або Eclipse JDT для Java), які забезпечують перевірені та ефективні структури.
Однак, використання цих фронтендів має недоліки . Багато з них розроблені для інтеграції з IDE, вимагають створення додаткових проектів та конфігурацій, а також генерують моделі, орієнтовані на взаємодію з користувачем, а не на масштабний аналіз. Крім того, вони часто працюють з попередньо обробленим кодом (наприклад, C з вирішеними макросами), що може призвести до розбіжностей з оригінальним вихідним кодом під час повідомлення про помилки.
Коли цих варіантів недостатньо , виникає необхідність вдаватися до класичних методів теорії компіляторів: побудова граматик, визначення парсерів за допомогою таких інструментів, як ANTLR, Bison або Flex, або навіть програмування комбінаторів парсерів чи рішень на основі PEG. Це вимагає глибокого розуміння синтаксису та семантики мови, що обробляється.
До поширених проблем на цьому етапі належать синтаксичні неоднозначності (вирази, які граматика може інтерпретувати кількома допустимими способами), контекстно-залежні або семантичні неоднозначності (наприклад, розрізнення того, чи фрагмент представляє множення, чи оголошення вказівника) та розв'язання посилань (знання в кожному використанні, на яку змінну, тип або член фактично посилаються).
У складних мовах програмування, таких як C++, або в змішаних середовищах — наприклад, ASPX з C#, Android з Java/Dalvik — ці неоднозначності множаться. Навіть у просунутих IDE спостерігаються помилки розфарбовування або розпізнавання символів у складних фрагментах, що ілюструє рівень складності для тих, хто створює власні інструменти аналізу.
Висновок полягає в тому, що чарівних рішень не існує : вам потрібно опанувати граматику, семантику, модель пам'яті мови, правила розпізнавання імен та мати дуже чітку мету аналізу, оскільки легко загубитися в деталях реалізації, які не додають цінності аудиту чи розглянутому випадку використання.
Розширені методи аналізу: інформаційні потоки та моделі виконання
Після того, як надійні внутрішні моделі (AST, моделі пам'яті та виконання) налаштовані , починається фактичний етап аналізу. Ключовим тут є аналіз потоку даних, який вивчає, як інформація поширюється через програму від ненадійних джерел (дані користувача, файли, сокети тощо) до потенційно небезпечних отримувачів ( SQL-запити , системні команди, неекранований рендеринг HTML тощо).
Аналіз потоку дозволяє вивчати всі можливі шляхи виконання, що з'єднують вхідні дані з вразливою точкою, як вперед, так і назад, що є важливим для методів аналізу пошкоджень. Він вимагає точного розуміння моделі пам'яті мови та механізмів неявного поширення (передача за значенням або посиланням, замикання, незмінні об'єкти, потоки тощо).
Також необхідно моделювати або включати поведінку сторонніх бібліотек , оскільки значна частина бізнес-логіки та точок входу/виходу знаходиться в них. Якщо це не враховувати, аналіз може генерувати велику кількість хибнопозитивних або, що ще гірше, хибнонегативних результатів, які залишаються непоміченими.
Ілюстративним прикладом є аналіз застосунку, вразливого до SQL-ін'єкцій : код може здаватися простим, але за допомогою аналізу пошкоджень можна спостерігати, як параметр, керований користувачем, поширюється через кілька функцій, доки не досягне конструкції запиту, яка виконується без належної параметризації. Без детальної моделі потоку та пам'яті ці залежності важко виявити автоматично.
Інший, складніший випадок стосується спільних статичних змінних, зворотних викликів або подій , де значення, що досягає приймача, залежить від попередніх виконань або менш очевидних шляхів. Тут модель виконання, що представляє стани, переходи та контексти, у поєднанні з AST дозволяє нам зібрати пазл докупи та зробити достовірні висновки щодо безпеки коду.
Хоча ці методи створюють додаткові труднощі , такі як міжмовний аналіз або точна оцінка виразів у високодинамічних середовищах, вони забезпечують високу якість результату: менше помилок інтерпретації, швидші процеси після побудови інфраструктури та стандартизована структура, яку можна адаптувати до різних проектів і технологій.
Автоматизація робочих процесів за допомогою RPA в AST (Арагонські телематичні послуги)
Окрім аналізу коду, робочі процеси в державному управлінні також оптимізуються за допомогою технологій робототехнічної автоматизації процесів (RPA). Ілюстративним прикладом є Aragonesa de Servicios Telemáticos (AST) – державна установа, яка надає послуги ІКТ уряду Арагона та діє як оператор телекомунікацій для автономної спільноти.
AST керує широким каталогом цифрових послуг — управління документами, електронний підпис, платіжні шлюзи, бізнес-аналітика, інфраструктури просторових даних, хостинг додатків, робочі станції, підключення та додаткові послуги — і зіткнулася з критичним вузьким місцем: ручним процесом створення рахунків-фактур, який споживав багато часу та ресурсів у дуже концентровані періоди.
Для вирішення цієї проблеми було залучено Hiberus , яка запропонувала рішення на основі RPA з використанням UiPath. Підхід дотримувався структурованої послідовності: створення спеціалізованого Agile-центру (консультанти RPA, архітектори, розробники, тестувальники), консультування з питань процесів для визначення автоматизованих даних, систем та робочих процесів, розробка PDD-документа з функціональним визначенням, і звідти – створення середовища та розробка рішення.
Автоматизація включала інтеграцію з корпоративною платформою цифрового підпису , ключовою системою для підписання рахунків-фактур, і навіть додавання системи сповіщень, якої бракувало в оригінальному інструменті. Було розгорнуто середовища розробки та виробництва, а також виконано спеціальний план тестування, спрямований на передвиробничі системи, що дозволило AST перевірити робота, не впливаючи на його щоденну роботу.
Після валідації рішення було впроваджено у виробництво , використовуючи сильні сторони UiPath: здатність автоматизувати складні та високооб'ємні процеси, низькі вимоги до програмування, легкість горизонтального масштабування, швидкість розробки, вбудовану систему сповіщень та можливість зупиняти виконання у разі виявлення будь-яких проблем.
Проєкт було завершено детальним навчанням для співробітників AST , спільно підготовленими посібниками користувача та практичними заняттями, щоб менеджери могли самостійно користуватися інструментом, налаштовувати параметри та розуміти результати, не покладаючись постійно на постачальника.
Кількісні результати були дуже значними : за два місяці було сформовано понад 500 рахунків-фактур, що на 60% більше, ніж попереднього року, а час обробки одного рахунку-фактури скоротився з 10 хвилин до приблизно 2, що означає скорочення середнього часу обробки на 80%. У середньостроковій перспективі прогнозується економія сотень годин ручної праці, окрім якісних переваг, таких як усунення людських помилок, більша гнучкість у повторному надсиланні рахунків-фактур, підвищення продуктивності та краще узгодження з цілями виставлення рахунків.
Зі стратегічної точки зору , цей пілотний проект RPA узгоджується з планом AST щодо впровадження роботизованої автоматизації процесів та автоматизованих адміністративних процедур в адміністрації Арагону. Крім того, він допоміг переглянути та уточнити бізнес-правила в процесі виставлення рахунків, покращити обмін інформацією між зацікавленими сторонами та визначити нові процеси, які можна автоматизувати на наступних етапах.
У сукупності ця картина показує, як концепція AST у різних її значеннях лежить в основі покращення робочих процесів: моделювання логіки програми за допомогою абстрактних синтаксичних дерев для інтелектуальної розробки та тестування, дослідження безпеки додатків за допомогою спеціалізованих інструментів, розбиття робочих завдань на частини для усунення ризиків або оркестрування роботів, які виконують повторювані завдання, щоб люди могли зосередитися на діяльності з вищою цінністю.
