Studiu de caz

Claybeck: o platforma, patru aplicatii de teren

Capitolul mobil al platformei logistice a unui producator de materiale de constructii: o aplicatie de comenzi pentru comercianti, una pentru soferi cu proof-of-delivery offline, o tableta de picking pentru curte si un portal pentru transportatori, toate pe acelasi back-end Laravel. 8+ ani pe ea ca inginer senior, livrata white-label printr-o agentie partenera.

Anonimizat sub NDA: produsul apare aici ca „Claybeck”, cu clienti si date fictive.

LaravelPHP 8.3+MySQLLaravel Passport (OAuth2)REST APIsAplicatii native iOS + AndroidSincronizare offline in lotPusherAzure Blob Storage

Patru roluri de teren care nu vedeau aceeasi comanda

Fiecare livrare trece prin patru randuri de maini din afara biroului: operatorul care o incarca, transportatorul care preia cursa, soferul care o duce si comerciantul care o asteapta. Niciunul nu vedea aceeasi comanda. Comerciantii sunau la birou sa intrebe unde e o livrare, doi operatori puteau rezerva aceeasi incarcatura, iar o livrare facuta fara semnal ramanea un bon pe hartie introdus de cineva mai tarziu. Fiecare rol are nevoie de alta parte din aceleasi date, pe alt dispozitiv, asa ca platforma a ajuns sa aiba cate o aplicatie client pentru fiecare, in jurul webului operational pe care il foloseste biroul.

Peste o suta de mii de comenzi au trecut prin ea.

Laptop, tableta si telefon in aceeasi scena: un dashboard operational pe laptop, un ecran de picking pe tableta si o lista de comenzi de comerciant pe telefon. — [fig. 1] Familia platformei: webul operational, tableta de picking din curte si aplicatia comerciantului. Webul operational plus doua dintre cele patru aplicatii client, pe un singur back-end.

Aplicatia comerciantului

Aplicatia pentru iPhone si Android raspunde exact la intrebarea pentru care comerciantii sunau la birou: unde imi e comanda? Comenzile active si cele livrate apar sub forma de carduri, cu intervalul de livrare si cine o aduce.

Doua ecrane de telefon ale aplicatiei de comerciant: o lista de carduri de comenzi cu etichete de split si intarziere si un detaliu de comanda cu pasi de status si linii de produs. — [fig. 2] Aplicatia comerciantului: carduri de comenzi dupa PO, cu etichete de split, pasii care duc comanda de la confirmed la dispatched si apoi delivered, o comanda intarziata cu noua ei data si transportatorul numit pe fiecare card.

Curtea, drumul si transportatorul

Operatorul deschide un load si il rezerva, ca sa nu lucreze doi oameni aceeasi comanda, inregistreaza ce s-a cules efectiv, apoi aloca vehiculul, remorca si soferul.

Aplicatia soferului preia pe drum, cu o semnatura la fiecare oprire si cu livrarile inregistrate fara semnal sincronizate ulterior. Portalul transportatorului e al patrulea: accepta sau refuza fiecare load oferit, contra cronometru.

Tableta cu un ecran de load: cantitati de picking pe comenzi, campuri de alocare a transportului, un buton de confirmare si un panou de chat pe load. — [fig. 3] Aplicatia de picking (tableta). Un load rezervat de operator: cantitati pe fiecare linie de comanda, alocarea transportului cu tip de vehicul, remorca si sofer, PIN-ul de load si banda de cantar, plus chatul pe load cu dispeceratul.

Ce s-a schimbat

Statusul comenzii: de la un telefon la self-serve: comerciantii isi urmaresc comenzile in aplicatie, cu tot cu datele de intarziere.
Curtea: load-uri rezervate si chat pe load: doi operatori nu mai pot lucra aceeasi comanda, iar discutia despre paletul lipsa ramane pe load.
Drumul: livrarile nu mai asteapta semnal: proof-of-delivery se captureaza offline si se sincronizeaza cand soferul revine in semnal.

8+ ani, o singura platforma, crescuta pe loc: o platforma interna single-tenant cu aplicatii companion, construita in jurul felului in care lucreaza un producator.

Dashboard operational cu un comutator intre trei divizii, contoare de comenzi si load-uri, un jurnal de cantar si un panou deschis de notificari de load. — [fig. 4] Webul operational in care raporteaza aplicatiile: comutatorul de divizii (numele diviziilor anonimizate ca REGION A / REGION B / PACKAGING), contoare live, jurnalul de cantar si feedul de notificari de load pe care biroul il urmareste toata ziua.

Ai ceva similar de construit?

Spune-mi de ce are nevoie partea de teren a platformei tale (o aplicatie, un portal, un dispozitiv in curte) si iti spun ce presupune.

Rezerva un apel gratuit Incepe o discutie

Sau scrie-mi direct: office@ecdevlabs.com