Пре непуне две године написао сам текст „ERP интегратор – преводилац са корисничког на програмерски језик“.
Пратећи AI трендове, поново сам га прочитао и уочио колико ме је AI hype прескочио и колико је текст терминолошки застарео. Међутим, задовољан сам колико је сам концепт остао актуелан и како се непланирано добро уклопио у AI трендове.
Именице су се улепшале, али су глаголи остали непромењени. Једино сам ја, пратећи трендове, из активног прешао у трпни глаголски придев.
Друго издање овог текста претрпело би измене већ у самом наслову, али би порука остала иста: у међувремену је интегратор постао MCP server, корисник domain expert, а програмерски језик AI agent.
Тада сам предложио online интегратор, „прекидне тачке“ и мале сервисе које сам назвао minimum business logic, односно nano service architecture. Велики AI играчи су у међувремену тим идејама доделили стандардне протоколе, алате и много бољи маркетинг.
Иста архитектура, нове именице
У старом тексту предложио сам да познавалац домена склапа пословни процес, док програмер прави мале и прецизне коцкице. Front-end је имао „прекидне тачке“ са којих их позива, а back-end је нудио CRUD операције и минимум бизнис логике.
У том смислу, моју застарелу терминологију треба превести на нова, брендирана имена:
online интегратор постао је ERP MCP server;
minimum business logic / nano service постао је MCP tool или business capability;
подаци доступни интегратору постали су MCP resources;
прекидне тачке постале су trigger, webhook и domain event;
повезивање операција постало је workflow automation;
корисник који познаје посао постао је domain expert;
заменљиви front-end постао је agent, разговор, глас, dashboard, Excel или класична ERP форма.
Model Context Protocol не мења суштину пословне апликације. Он стандардизује начин на који AI апликација открива алате, чита ресурсе и позива функције. Другим речима, даје заједнички језик ономе што је раније сваки интегратор решавао засебно.
Главни ERP проблем није промена технолошке парадигме
Највећи ERP проблем био је комуникација.
Корисник је говорио језиком свог свакодневног посла. Консултант га је преводио на терминологију производа. Аналитичар је од тог превода правио захтев. Програмер је захтев претварао у структуре и алгоритме. Тестер је на крају проверавао да ли сви ти преводи значе исто.
На крају су се сви сложили да не значе.
Књиговођа каже „сторно“, магационер „поврат“, продавац „рекламација“, а програмер види негативну количину. Сви користе исправне речи из различитих перспектива, док база мора да изабере само једно значење.
AI ту доноси стварну промену. Корисник више не мора да научи језик апликације. Agent може његову намеру да преведе на ограничен скуп формално дефинисаних пословних операција.
То је важније од генерисања кода. Код смо и раније умели да напишемо. Проблем је био да прецизно утврдимо шта треба написати.
Где AI престаје, а пословна логика почиње
Основни проблем примене AI-а у ERP системима јесте немогућност да се гарантује поузданост резултата. Модел може да понуди убедљив одговор и када нема довољно података. ERP је област у којој уверљиво погрешан одговор брзо добије и своју финансијску вредност.
Зато agent не треба да обрачунава порез, просечну набавну цену, расположиву количину или финансијско књижење. Он треба да:
разуме намеру корисника;
прикупи потребан контекст;
изабере одговарајући алат;
предложи редослед операција;
затражи потврду када је ризик висок.
Егзактан алгоритам извршава nano service иза MCP алата. Улаз има schema-у, правила су верзионисана, права проверена, а резултат мерљив и поновљив.
Халуцинација тиме није нестала, али је ограничена на део система у ком је подношљива: тумачење намере и избор следећег корака. Из обрачуна и књижења је избачена. Погрешан параметар одбија доменска валидација, недозвољену операцију ауторизација, дупли позив idempotency механизам, а ризичну радњу human-in-the-loop потврда.
Најкраће: халуцинација се не лечи већом интелигенцијом, него мањом недефинисаном надлежношћу.
Agent, workflow, orchestrator и harness
Ови појмови се често користе као синоними, мада не раде исти посао.
Workflow следи унапред дефинисан пут. Предвидив је, тестиран и досадан, што су за ERP три веома пожељне особине.
Agent добија циљ и алате, па сам бира следећи корак. Користан је када треба тумачити захтев, пронаћи податке или одлучити коју операцију треба позвати. Разлика између унапред дефинисаног workflow-а и динамичког агента добро је објашњена у тексту „Building effective agents“.
Orchestrator, на пример n8n, управља целим током: trigger-има, стањем процеса, редоследом, грешкама, поновним покушајима и ескалацијом човеку. У једном кораку може користити егзактан сервис, у другом агента, а у трећем људску одлуку.
AI harness је окружење које agent-у даје контекст, алате, правила, memory, guardrails, логове, telemetry, evals и ограничења. Савремени harness engineering полази од тога да agent постаје поуздан тек када је исправан пут јасно видљив, а погрешан механички ограничен.
Модел је радник. Harness је организација у којој ради. Искуство нас учи да је организација често важнија.
Комуникација мора бити двосмерна
Није довољно да agent уме да пита ERP шта се догодило. ERP мора да уме да јави да се нешто догодило.
Када се прокњижи документ, падне залиха испод минимума, стигне уплата или истекне рок, back-end треба да објави domain event. n8n или други workflow server прима догађај преко webhook-а, message broker-а или event bus-а и покреће процес.
Пуни ток изгледа овако:
експерт → agent → workflow → MCP tool → nano service → ERP
а у супротном смеру:
ERP → domain event → workflow → agent, човек или други сервис
MCP је уговор са AI светом. Domain events су нервни систем пословне апликације. За поузданост су и даље потребни outbox pattern, retry, idempotency, audit и праћење статуса.
Тек када постоје оба смера, систем не чека да га корисник отвори. Он реагује на догађај, прикупља контекст, предлаже одлуку и извршава тачно дефинисану операцију.
Следећа фаза ERP компанија
Следећа фаза сваке ERP IT компаније јесте припрема производа за AI тржиште. Не додавање chatbot-а у доњи десни угао, већ претварање нагомиланог пословног знања у безбедне и машински откривљиве MCP capabilities.
Неке компаније ће се око тога намучити. Неке ће одустати. Неке ће тврдити да њиховим корисницима то није потребно, што је традиционалан начин да се техничка немогућност прогласи тржишном стратегијом. Неке ће користити спољне интеграторе. Друге ће имати капацитет да подигну сопствене MCP сервере.
Озбиљан ERP има хиљаде сервиса и милионе комбинација ентитета, операција, правила, права и контекста. Свака од тих могућности потенцијално је MCP tool или resource.
Ручно писање MCP алата за сваки сервис није решење. То је нови двадесетогодишњи ERP пројекат. У предности ће бити они који имају framework способан да из постојећих метаподатака, service registry-ја, schema-е, права и валидација контролисано генерише capability:
назив и опис алата;
input и output schema-у;
потребан пословни контекст;
права и валидације;
audit и idempotency правила;
структуру грешака;
догађаје које операција производи.
Ту ће се видети стварна вредност постојеће архитектуре. Компаније које имају јасне сервисне границе, metadata-driven моделе и одвојену бизнис логику моћи ће брзо да отварају нове capabilities. Оне код којих је логика расута по екранима, SQL процедурама, параметрима и знању најстаријег запосленог прво ће морати саме себи да објасне шта њихов производ ради.
AI не може да открије уговор који никада није постојао, али може да предвиди потребу за таквим уговором и да га генерише.
Зато право мерило AI readiness-а ERP производа неће бити који модел користи нити колико има агената. Биће то његов capability conversion rate: колико постојећих пословних сервиса може да претвори у безбедне, тестиране, верзионисане и агентима разумљиве MCP capabilities.
Ко овде има интерес
Инвеститор добија конкретније мерило од тврдње да компанија „користи AI“. Треба да пита колико је пословне логике формализовано, колико сервиса може аутоматски да постане MCP capability и ко контролише интерфејс према AI тржишту. Вредност није у моделу који свако може да закупи, већ у доменском знању претвореном у проверљиве операције.
ERP произвођач и програмер добијају ново тржиште за постојећи производ. Не морају поново да пишу ERP, али морају да одвоје логику од интерфејса, формализују уговоре и направе capability factory уместо стотина ручних интеграција.
Консултант и domain expert добијају могућност да од готових операција саставе сопствени workflow, извештај или вертикално решење. Њихово знање више не мора да путује кроз дугачак ланац спецификација да би постало извршива апликација.
AI ентузијаста (ако их још уоште има) добија нешто корисније од још једног chatbot-а: алате над стварним подацима, јасна права, мерљив резултат и окружење у ком agent може безбедно да делује.
Корисник бира front-end који му одговара: разговор, глас, табелу, dashboard или старо добро дугме. Интерфејс је заменљив; пословна логика остаје иста.
У шта треба инвестирати
Не у још један разговор са аутоматизацијом документације, већ у претварање доменског знања у извршиве уговоре:
каталог малих пословних операција;
metadata-driven capability framework;
MCP server са ауторизацијом, audit-ом и верзионисањем;
domain events и двосмерну комуникацију;
workflow-е које експерт може да разуме и промени;
observability, evals и human-in-the-loop контроле.
AI тржиште неће дуго питати: „Да ли ваш ERP има AI?“ Питаће: „Може ли мој agent да открије шта ваш ERP уме, да добије тачан контекст, безбедно позове операцију и преузме проверљив резултат?“
Ако може, производ је спреман за ново тржиште.
Ако не може, све остало је теорија. Или презентација теорије са chatbot-ом.
П. С.
Нова подела глобалног ERP посла подразумева присуство великих светских AI играча, јединих способних да постављају трендове, и малих оперативних тимова, способних да се брзо прилагођавају и трендовима и корисницима. Између њих и даље остају преводиоци.
Како ће се мале, средње и велике IT компаније у томе снаћи, зависи од њих. Али у времену када AI обара цену крајњег производа, правац већ назиремо.
Моја теза је да нису угрожени програмери, већ њихова радна места у компанијама какве познајемо. Контрадикција је само привидна: потреба за кодом, интеграцијама и егзактним пословним сервисима расте, док потреба за програмирањем опада.
0 comments:
Постави коментар