De la aplicații separate la un sistem coerent
Digitalizarea nu a început de la tehnologie. A început de la traseul real al mărfii și al informației.
Flowers Market Holland este un distribuitor B2B de flori, plante și accesorii pentru profesioniști. Într-un asemenea business, aceeași informație trece prin mai multe contexte: clientul se înscrie și primește acces, cumpără din depozit sau online, produsele sosesc de la furnizori, sunt recepționate și etichetate, stocul se schimbă, comenzile trebuie clarificate, iar documentele ajung în contabilitate. Dacă fiecare etapă este tratată izolat, oamenii ajung să copieze aceleași date între formulare, emailuri, fișiere și aplicații.
Proiectul a crescut gradual. AYSA și Web-Development au pornit de la probleme concrete și au construit componente potrivite locului în care munca se desfășoară: interfețe web pentru client și back-office, instrumente operaționale pentru depozit, conectare cu NEXUS ERP, automatizări pentru documente și un canal conversațional prin WhatsApp. Flowers Market a rămas sursa regulilor comerciale și a validării din teren.
Rezultatul nu este prezentat aici ca un „ERP nou” care înlocuiește tot. Este un strat operațional care conectează sistemele și face procesele mai ușor de urmărit. Unele decizii pot fi automatizate, altele cer confirmarea unui om. Unele date pot fi comunicate clientului, altele trebuie să rămână în sistemele interne. Arhitectura este construită tocmai în jurul acestor granițe.
Harta ecosistemului
Fiecare aplicație are un rol. Valoarea apare în legăturile dintre ele.
Clientul vede cardul, webshopul și Oxalis. Echipa folosește instrumentele de administrare, recepție, etichetare, comenzi și comunicare. NEXUS rămâne sistemul de referință pentru entitățile și documentele contabile relevante.
01 · Relația cu clientul
De la înscriere la o identitate comercială folosită coerent.
Cardul nu este doar o imagine cu un cod. El face legătura dintre persoană, firmă, dreptul de cumpărare și sistemele care trebuie să recunoască relația.
Onboarding pentru persoane juridice și persoane fizice
Fluxul de înscriere colectează datele necesare, documentele și acordurile într-un traseu ghidat. Pentru firme, sistemul trebuie să păstreze separat compania, reprezentantul și persoanele delegate. Pentru persoanele fizice, identificarea are alte reguli și alte riscuri de duplicare. Aceste diferențe nu sunt lăsate la interpretarea unui singur câmp generic.
Documentele sunt verificate înainte ca procesul să fie considerat complet. Contractul, informarea privind datele personale și documentele de identificare au stări distincte. Dacă o etapă obligatorie lipsește, sistemul nu prezintă clientului un succes artificial. Cazurile neclare sunt direcționate spre verificare, în loc să fie „reparate” automat prin presupuneri.
Card, companie, delegat și corespondent în ERP
În spatele cardului există o relație între mai multe entități. Sistemul păstrează identitatea locală și referințele confirmate din NEXUS, aplică reguli deterministe pentru reluarea unui proces și verifică rezultatul după scriere. Scopul este ca o reîncercare tehnică să nu creeze încă un client, încă un delegat sau un cod diferit.
Confirmarea nu se bazează doar pe faptul că un server a răspuns. Fluxul interpretează rezultatul funcțional, păstrează starea fiecărei componente și separă situațiile recuperabile de cele care cer intervenția echipei. Emailul final și activarea sunt tratate ca etape urmărite, nu ca o singură bifă optimistă.
Administrarea relației după înscriere
Back-office-ul oferă echipei acces la profilul clientului, documente, carduri, comunicări și starea integrărilor. Operațiunile sensibile sunt protejate prin roluri și confirmări, iar acțiunile importante pot fi urmărite. Clientul nu trebuie să cunoască structura internă pentru a primi un răspuns clar; echipa, în schimb, are nevoie de contextul complet pentru a rezolva excepția corect.
Acest flux susține și accesul ulterior la webshop. Clientul profesional pornește de la o identitate verificată, iar canalele digitale pot folosi aceeași relație comercială, fără o a doua înscriere paralelă. Pentru detalii despre mecanismul general, vezi ghidul despre digitalizarea onboardingului clienților B2B.
| Etapă | Ce trebuie păstrat | Unde intervine omul |
|---|---|---|
| Înscriere | Date structurate, consimțăminte și documente asociate cererii corecte | Clarifică informațiile incomplete sau contradictorii |
| Identitate | Compania, persoana și delegarea ca entități distincte | Rezolvă potrivirile ambigue |
| Card | Cod permanent, stare și relație cu clientul | Confirmă excepțiile care nu pot fi reconciliate |
| ERP | Referințe confirmate și rezultat recitit | Validează cazurile de business neobișnuite |
| Acces | Activare și livrare urmărite separat | Oferă suport când livrarea sau asocierea eșuează |
02 · Operațiunile interne
Recepția, stocul și etichetarea trebuie să vorbească aceeași limbă.
În distribuția florală, produsul este fizic, loturile se mișcă repede, iar ambalarea contează. Software-ul trebuie să urmeze marfa, nu să inventeze o realitate paralelă.
Identitatea produsului înainte de automatizare
Același produs poate apărea cu denumiri, coduri sau descrieri diferite în documentele furnizorului și în sistemul intern. Înainte ca o linie să poată fi importată sau etichetată, sistemul trebuie să determine dacă produsul există, dacă potrivirea este suficient de sigură și ce informație trebuie păstrată pentru lotul primit.
Potrivirile cunoscute pot fi reutilizate, dar o asemănare de text nu devine automat adevăr contabil. Când codul sau caracteristicile nu oferă certitudine, linia rămâne pentru validare. Această alegere pare mai lentă decât „acceptă tot”, însă protejează stocul și documentele de erori care ar fi mult mai greu de corectat după recepție.
Sesiunea de etichetare pornește din recepție
Etichetele sunt generate în contextul unei recepții și al produselor confirmate. Sesiunea păstrează factura sau documentul sursă, liniile, cantitățile, asocierea cu produsele și istoricul tipăririi. Operatorul poate vedea ce a fost pregătit, ce a fost tipărit și unde este nevoie de o corecție controlată.
Tipărirea este adaptată mediului de depozit și poate folosi instrumente dedicate. Aplicația nu trebuie să oblige angajatul să lucreze ca un contabil, iar ERP-ul nu trebuie transformat într-o interfață de imprimantă. Fiecare componentă oferă exact comenzile necesare rolului respectiv, în timp ce identitatea produsului și a recepției rămâne comună.
Stoc util pentru echipă și informație sigură pentru client
Stocul agregat ajută echipa să pregătească și să verifice cereri. Totuși, cantitatea internă exactă nu trebuie expusă automat în orice canal. Pentru client, disponibilitatea poate fi comunicată prin benzi calitative — suficient, mediu, puțin sau indisponibil — deoarece marfa se poate modifica între conversație și confirmare.
Aceeași disciplină se aplică prețurilor și ambalărilor. Sistemul poate oferi un reper sau variantele cunoscute, dar prețul comercial final și marfa fizică sunt confirmate de echipă. Articolul despre digitalizarea depozitului, etichetare și trasabilitate explică mai în detaliu cum se proiectează acest tip de flux.
03 · Contabilitate și NEXUS ERP
O factură externă devine date verificabile, nu încă un fișier de reintrodus manual.
Automatizarea preia munca repetitivă, dar nu ascunde liniile ambigue sub un import „reușit”.
Facturile furnizorilor pot ajunge prin email, fișiere descărcate sau încărcări controlate. Sistemul detectează documentul, extrage informațiile disponibile și construiește un draft. Numărul, data, furnizorul, liniile, cantitățile, monedele și valorile sunt păstrate împreună cu sursa, astfel încât verificarea să poată reveni la documentul inițial.
Fiecare linie trebuie asociată cu produsul potrivit. Unde există o mapare confirmată, procesul poate continua. Unde descrierea este nouă sau contradictorie, operatorul alege produsul corect ori aprobă crearea controlată a unuia nou. Regula importantă este că automatizarea pregătește decizia; nu maschează incertitudinea.
După validare, sistemul poate pregăti și importa documentele necesare în NEXUS. Identificatorii stabili, verificarea existenței documentului și recitirea rezultatului reduc riscul unui import duplicat la reluare. Dacă integrarea răspunde neclar sau o reconciliere nu trece, draftul rămâne într-o stare care poate fi investigată.
Acest model este semi-automat acolo unde realitatea furnizorilor nu permite automatizare completă. Diferența este importantă: „semi-automat” nu înseamnă incomplet, ci faptul că omul aprobă exact excepția pentru care are context comercial sau contabil. Restul pașilor repetitivi sunt preluați de sistem.
Vezi cadrul complet pentru automatizarea facturilor furnizorilor și a NIR-urilor și comparația dintre ERP standard și software custom.
04 · Comenzi și logistică
Comanda trebuie să ajungă la depozit cu același sens pe care l-a avut pentru client.
Un canal nou nu ajută dacă echipa trebuie să rescrie comanda și să reconstruiască manual contextul.
Mai multe canale, un singur model operațional
Clientul poate planifica aprovizionarea din webshop, poate discuta cu echipa sau poate folosi Oxalis. Aceste intrări au interfețe diferite, dar produsele, cantitățile, ambalările, data solicitată și observațiile trebuie să ajungă într-o structură comună. Altfel, fiecare canal creează o coadă separată și o nouă sursă de neînțelegere.
Comanda asistată păstrează identitatea clientului și un rezumat care poate fi verificat. Ea nu este tratată ca vânzare finală înainte ca echipa să confirme disponibilitatea și condițiile. Într-un business cu stoc rapid, această separare dintre solicitare, draft și confirmare protejează atât clientul, cât și operațiunea.
Pregătire, ambalare și predare
După preluare, informația trebuie să fie utilă oamenilor care pregătesc marfa. Produsul ales, ambalarea, cantitatea și data nu ar trebui descifrate dintr-un șir de mesaje. Fluxurile interne organizează comenzile, sarcinile de pregătire și stările care arată ce urmează.
Logistica folosește aceleași referințe pentru a evita reintroducerea datelor. Acolo unde este necesar, sistemele pentru documente și transport pot fi conectate cu comanda și clientul. Nu toate operațiunile trebuie să fie complet automate; important este ca transferul dintre roluri să fie explicit, urmărit și reversibil atunci când apare o corecție.
Feedback-ul din depozit se întoarce în sistem
Software-ul operațional nu se termină la „trimite”. Dacă un produs nu este disponibil, ambalarea diferă sau clientul cere o schimbare, starea trebuie actualizată în fluxul canonic. Aceasta permite echipei comerciale să comunice pe baza aceleiași realități pe care o vede depozitul.
Ghidul despre integrarea comenzilor, stocului, depozitului și livrării arată cum se delimitează responsabilitățile între canale și sistemul operațional.
05 · Oxalis
Un coleg AI care cunoaște regulile businessului și știe când să cheme un om.
Oxalis este canalul conversațional Flowers Market pe WhatsApp. Clientul poate scrie firesc, poate trimite un mesaj vocal sau o fotografie și poate construi o cerere fără să învețe structura unui formular.
Limbaj natural
Separă produsele, culorile, cantitățile, lungimile și observațiile din text sau voce.
Catalog și ambalări
Folosește vocabularul comercial și cere clarificări când același produs are mai multe variante.
Stoc și repere
Consultă date structurate și comunică disponibilitatea fără să expună cantitatea internă exactă.
Confirmare explicită
Păstrează cererea ca draft și nu o transmite drept comandă confirmată fără acordul clientului.
Operator uman
Escaladează întrebările care cer judecată, păstrând contextul și revenirea controlată la asistent.
Învățare controlată
Răspunsurile stabile pot deveni propuneri pentru baza de cunoștințe, dar numai după review și aprobare.
Principii de arhitectură
Automatizarea este sigură când recunoaște limitele propriei certitudini.
Un singur flux canonic
Același tip de entitate sau document nu trebuie scris prin mai multe implementări cu reguli diferite. Interfețele pot varia; contractul operațional rămâne comun.
Reluare fără duplicare
Operațiunile folosesc identitate stabilă, blocare unde este necesar și verificarea stării înainte și după scriere.
Readback și reconciliere
Un răspuns tehnic nu este echivalent cu succesul de business. Sistemul recitește rezultatul important și păstrează nepotrivirile pentru control.
Omul aprobă excepția
Un operator nu reface munca automatizării. El intervine acolo unde lipsesc date, există conflict sau decizia produce un efect sensibil.
Acces proporțional cu rolul
Clientul, depozitul, contabilitatea și administratorul văd informații diferite. Fiecare suprafață oferă strict contextul necesar sarcinii.
Observabilitate fără expunere
Evenimentele și stările permit investigarea unui flux, însă datele personale și informația comercială nu sunt transformate în material de raportare publică.
Mai multe despre abordare în ghidul „Cum construiești software operațional fără să rupi procesele existente”.
Cum a fost construit
Un program operațional livrat în pași verificabili, nu un „big bang”.
Discovery în locul presupunerilor
Fiecare intervenție a pornit din urmărirea muncii reale: cine primește informația, unde o completează, ce verifică și ce dovadă îi permite să continue. Au fost urmărite atât cazurile normale, cât și documentele incomplete, produsele greu de identificat, reluările după eroare și situațiile care cer decizie comercială. În acest fel, cerința nu a rămas „să automatizăm facturile” sau „să facem un card”, ci a devenit un traseu cu intrări, stări, responsabilități și rezultat acceptat.
O sursă clară pentru fiecare adevăr
Clientul, delegatul, produsul, stocul, factura și comanda nu pot fi administrate sigur dacă fiecare aplicație inventează propria identitate. Pentru fiecare entitate a fost stabilit sistemul care o deține, identificatorul folosit la corelare și dreptul de modificare. Interfețele dedicate pot colecta sau prezenta informația, dar nu devin automat surse paralele. Când este necesară o scriere în NEXUS, aplicația păstrează corelația locală și recitește rezultatul funcțional.
O singură cale controlată pentru scrieri
Integrarea sensibilă nu este împrăștiată în mai multe ecrane și scripturi care pot produce rezultate diferite. Operațiile importante trec prin servicii canonice, cu validare, cheie de idempotency, jurnal redacționat și reconciliere. Dacă rețeaua întrerupe răspunsul, reluarea nu presupune automat că prima încercare a eșuat; sistemul verifică starea și evită dublarea. Aceeași disciplină este importantă pentru clienți, documente, NIR-uri și comenzi.
Interfețe potrivite rolului
Un client care completează date pentru card, un operator care etichetează marfa, un contabil care verifică o factură și un coleg care preia o conversație Oxalis nu au aceeași sarcină. Au nevoie însă de aceleași entități și stări, prezentate în forma potrivită momentului. Designul a urmărit să reducă deciziile inutile din fiecare interfață și să păstreze excepțiile vizibile, fără a expune date care nu sunt necesare rolului.
Pilot, read-back și reconciliere
Livrările au putut fi validate vertical: o intrare reală ajunge până la rezultatul final și poate fi recitită. Testarea include cazul normal, date ambigue, retry, dublu click, răspuns funcțional de eroare și revenire după întrerupere. Pentru etapele cu efect contabil sau comercial, succesul tehnic al unui request nu este suficient. Confirmarea vine din starea funcțională, iar diferențele intră într-o coadă de reconciliere sau într-un review uman.
Documentație care rămâne utilă după lansare
Regulile, identificatorii, stările și criteriile de acceptanță trebuie să poată fi înțelese și după schimbarea unei persoane din echipă. De aceea, documentația urmărește contractele dintre sisteme și procedura de operare, nu doar structura codului. Ea explică ce se întâmplă când un furnizor schimbă formatul, când un produs nu poate fi mapat sau când Oxalis are nevoie de operator. Această memorie permite evoluția sistemului fără redescoperirea acelorași riscuri.
Ce permite sistemul
Mai puține rupturi între momentele aceluiași proces.
Fără a publica indicatori interni sau a promite rezultate transferabile, putem descrie efectul structural al proiectului: datele clientului pot fi colectate și verificate într-un traseu coerent; recepția poate alimenta etichetarea; factura poate deveni un draft de document pregătit pentru validare; comanda conversațională poate ajunge la echipă într-o formă structurată.
Acest tip de sistem reduce nevoia de a reconstitui contextul la fiecare transfer. El face vizibile excepțiile, separă starea „pregătit” de „confirmat” și oferă echipei un punct mai bun de pornire. Beneficiul real trebuie măsurat în companie prin timpi, erori, adopție și calitatea serviciului, nu dedus din numărul de funcții.
Proiectul continuă să evolueze odată cu procesele Flowers Market. O integrare operațională nu este o livrare înghețată: regulile furnizorilor se schimbă, apar produse noi, echipa învață din excepții, iar canalele clienților se maturizează.
Pentru management, conexiunea dintre sisteme înseamnă și o delimitare mai bună a responsabilității. Se poate vedea dacă un caz așteaptă informație de la client, maparea unui produs, validarea contabilă, confirmarea unei comenzi sau intervenția unui operator. Vizibilitatea nu elimină excepțiile, dar le scoate din mesaje izolate și le transformă în muncă ce poate fi urmărită.
Pentru echipă, valoarea apare când o informație corectată într-un loc nu trebuie reintrodusă în fiecare etapă. Identificatorii stabili, stările explicite și istoricul acțiunilor reduc ambiguitatea la predare. Oamenii rămân responsabili pentru deciziile sensibile, însă primesc contextul și instrumentele necesare pentru a le lua mai repede și mai consecvent.
Pentru client, ecosistemul urmărește continuitatea: datele oferite la onboarding pot susține accesul și relația ulterioară, iar conversația comercială poate continua către o comandă confirmată fără promisiuni bazate pe date vechi. Experiența rămâne simplă la suprafață tocmai pentru că regulile și verificările sunt tratate riguros în spate.
Lecții pentru alte companii B2B
Nu automatiza organigrama. Automatizează traseul informației.
- 01
Începe cu o entitate importantă
Clientul, produsul, comanda sau documentul trebuie să aibă o identitate clară. Dacă aceeași entitate există în cinci forme incompatibile, orice automatizare va multiplica nepotrivirile.
- 02
Separă fluxul principal de excepții
Construiește întâi traseul frecvent și păstrează o cale controlată pentru situațiile rare. Nu transforma fiecare excepție istorică într-o regulă care complică experiența tuturor.
- 03
Integrează înainte să înlocuiești
Un ERP, o aplicație de contabilitate sau un canal comercial existent poate rămâne valoros. Un strat custom poate rezolva diferența dintre software-ul standard și munca specifică firmei.
- 04
Proiectează pentru locul în care se lucrează
Un operator din depozit, un contabil și un client pe WhatsApp nu au nevoie de aceeași interfață. Au nevoie de aceeași realitate exprimată potrivit sarcinii lor.
- 05
Măsoară adopția și rezultatul
„Funcția există” nu înseamnă că procesul s-a îmbunătățit. Verifică utilizarea, timpul economisit, excepțiile, erorile și feedbackul oamenilor care lucrează zilnic cu sistemul.
Pentru un cadru de pornire, citește ce procese conectezi mai întâi într-o companie de distribuție B2B.
Vezi sistemele publice
Dovezile destinate clienților rămân la Flowers Market. Metoda de lucru este documentată de AYSA și Web-Development.
Întrebări frecvente
Ce poate fi transferat din acest proiect într-o altă companie?
Flowers Market folosește un singur software pentru toate operațiunile?
Nu în sensul unei aplicații monolitice. Ecosistemul conectează interfețe și servicii potrivite fiecărui rol, iar NEXUS rămâne sistemul de referință pentru datele și documentele relevante. Coerența vine din identități, reguli și integrări comune.
De ce a fost nevoie de software custom dacă exista deja un ERP?
ERP-ul gestionează bine procese standardizate, însă înscrierea clienților, cardurile, experiența de depozit, documentele furnizorilor și conversația WhatsApp au cerințe proprii. Software-ul custom acoperă aceste diferențe și comunică cu ERP-ul, fără să-i copieze integral funcțiile.
Importul facturilor și NIR-urilor este complet automat?
Pașii repetitivi pot fi automatizați, dar liniile noi, potrivirile incerte și excepțiile rămân pentru validare. Obiectivul nu este eliminarea controlului contabil, ci pregătirea unui draft corect și reducerea reintroducerii manuale.
Oxalis vede stocul exact și poate confirma singur o comandă?
Oxalis folosește date structurate pentru a comunica disponibilitatea orientativă fără a expune cantitățile interne exacte. Cererea devine draft, clientul confirmă explicit, iar echipa Flowers Market verifică marfa și condițiile comerciale finale.
Oxalis înlocuiește operatorii Flowers Market?
Nu. Asistentul rezolvă întrebări și structurează cereri acolo unde are surse și reguli sigure. Când situația cere judecată sau clientul solicită un coleg, conversația poate fi transferată, iar contextul este păstrat.
Cum învață agentul din răspunsurile echipei?
Un răspuns uman stabil poate genera o propunere redactată și deduplicată. Propunerea nu devine automat cunoaștere publicată: un administrator o revizuiește, o editează, o aprobă sau o respinge. Datele volatile despre stoc și preț nu sunt transformate în reguli permanente.
Poate fi copiat sistemul Flowers Market într-o altă companie?
Principiile sunt reutilizabile, dar implementarea nu trebuie copiată mecanic. Fiecare companie are alte roluri, surse de date, integrări și excepții. Discovery-ul identifică fluxul comun și stabilește ce poate fi configurat, integrat sau dezvoltat.
Cum începe un proiect similar?
Cu inventarul proceselor, al sistemelor și al momentelor în care aceeași informație este reintrodusă sau se pierde. Alegem o zonă cu valoare operațională clară, definim starea actuală și criteriile de acceptanță, apoi construim în etape care pot fi testate de oamenii care vor folosi soluția.