Rotberg Iavi 
Cristian Nechita La baza operațiunilor de plată a creanțelor curente stă etapa de detecție a furnizorului sau, în termeni mai simpli, găsirea furnizorului potrivit pentru a putea plăti serviciile consumate. Pentru companiile care au mii de sucursale și zeci de mii de furnizori, automatizarea procesului are un impact extraordinar în ceea ce privește reducerea costurilor asociate producției prin minimizarea muncii manuale.
Un model tradițional de detecție a furnizorului are defectul de a lăsa clientul să găsească manual furnizorul potrivit. Nu numai că această sarcină manuală este echivalentă cu "găsirea acului în carul cu fân", dar este și predispusă la erori. Imaginați-vă că vreți să cumpărați niște mere și, pentru că aveți preferințe clare în ceea ce privește merele, ați dori niște mere verzi "Granny Smith" bio. În acest exercițiu imaginar, dintr-o dată toate fructele de pe piață sunt închise în cutii negre și toate etichetele au doar "Fructe" scrise pe ele. După ce veți deschide niște cutii și veți găsi, cel mai probabil, portocale, pere, prune etc., cineva va fi mulțumit cu orice fel de mere, așa că va merge acasă cu niște mere "Red Delicious" și multă frustrare.
Atunci când se face detecția furnizorului, aceasta se bazează, de obicei, pe reguli dezvoltate manual și incremental, ceea ce oferă șansa ca un furnizor să fie găsit. Pentru a maximiza această șansă, este important ca respectarea acestor reguli să se realizeze în funcție de un anume context. Acest context este cheia mecanismului de detecție, dar, în același timp, face ca regulile să fie cea mai slabă verigă deoarece:
Regulile sunt integrate într-un context specific unui client și nu pot fi transferate altora.
Regulile devin greu de menținut, fiind dependente de context.
În timp, platforma va suferi o degradare a performanței, prin creșterea latenței.
Având în vedere cele de mai sus, se configurează un risc mare legat de faptul că experiența clientului se va degrada în timp și va genera o mulțime de reclamații și nemulțumiri.
Soluția este un sistem adaptabil care are la bază un algoritm de detecție dinamică, evitându-se, astfel, aproape complet elaborarea manuală a regulilor.
Acest lucru se poate face prin crearea dinamică a contextului necesar detecției și, ulterior, prin valorificarea puterii clusterului AWS Managed ElasticSearch de a executa tot acest context în câteva secunde.
Urmărind exemplul de mai sus, ne putem imagina: sistemul sortează automat toate cutiile din magazin și filtrează doar mere, apoi merele verzi și, în cele din urmă, doar pe cele bio. În centrul soluției există un model de creare a acestui context dinamic, care instruiește sistemul cum să parcurgă regulile pentru a ajunge la cel mai bun rezultat.
Al doilea ingredient care face posibilă această rețetă este : "Elastic Search". Selectarea acestuia ne-a permis să putem aplica toate modelele de detecție, într-un singur apel, astfel încât obținem rezultate care să corespundă tuturor combinațiilor posibile referitoare la șablonul de intrare, ordonate pe baza mecanismului nostru de adnotare dinamică.
Pentru a oferi utilizatorului control asupra mecanicii ce stă în spatele motorului de detecție, am optat pentru un fișier de configurare care respectă convențiile predefinite legate de ponderea (prioritatea) de căutare. De asemenea, pentru a putea gestiona cererile clienților din întreaga lume, (caz în care ne așteptăm ca anumite entități să aibă prioritate diferită), sistemul este capabil să încarce fișierul de configurare corect pe baza metadatelor fluxului de intrare.
Prezentăm în continuare o diagramă care exemplifică abordarea folosind componente AWS serverless (FaaS):
Prima regulă a proiectării unui sistem empiric este să învățăm modul în care sistemul răspunde în fața metricelor stabilite și, ulterior, să realizăm o reglare fină. Pentru a crește precizia detecției, se pot seta o serie de alarme care să fie declanșate la apariția unui eveniment. Astfel, de fiecare dată când o nouă cerere de detecție intră în sistemul nostru, ne asigurăm că introducem rezultatul cererii în fișierele de "logs". Aceste fișiere de tip jurnal sunt apoi redirecționate către Splunk, care, la rândul său, face agregările și procesările necesare în vederea alertării automate, atunci când anumite valori sunt în afara limitelor. În acest mod, administratorul sistemului poate lua măsuri de corecție rapid și eficient.
În continuare, se obține feedback de la client, cu privire la rezultatul detecției. Apoi, aceste informații noi sunt reevaluate pentru a actualiza scorurile de detecție cu un anumit "bias".
"Bias" poate fi considerat mecanismul de recompensă sau sancționare a rezultatului final al detecției unui furnizor. Acest mecanism poate fi valorificat pentru a evita coruperea modelului prin diferite personalizări dorite de clienți aflați în zone geografice diferite.
Echipa de dezvoltare își atinge potențialul maxim atunci când are suficientă autonomie pentru a experimenta, învăța și pune în practică. Folosind un așa model de dezvoltare, se poate asigura o tranziție fluidă de la inovație la linia de producție. Un astfel de mediu controlat poate să ofere un model ideal pentru a asigura o tranziție lină de la inovație la linia de producție. Acest exercițiu este cu atât mai valoros, cu cât nu există o serie de criterii clare pentru a valida cât de bun este produsul cu date reale, în situații concrete.
Folosind un așa-numit "client - pilot", organizația poate valorifica cele mai importante trei eșecuri: încercarea nereușită de a duce în producție și de a scala, defecțiuni neprevăzute ale sistemului și abateri masive ale datelor de intrare. Valorificarea acestora are cel mai mare potențial de învățare și de livrare a unui produs de succes.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
