BOCP UX Audit

Document confidențial — introduceți parola

Parolă incorectă

Acces restricționat

Audit UX & Plan de
Modernizare BOCP

Analiză obiectivă a uzabilității, arhitecturii tehnice și potențialului de scalare SaaS pentru Business Online Control Panel (BOCP / CloudERP.ro). Include plan concret de modernizare cu estimări și strategia de implementare paralelă via API.

Produs analizat
BOCP v3 — secure.bocp.eu
Data auditului
6 Aprilie 2026
Metodologie
Automated crawl + manual review
Module analizate
11 module, ~80 ecrane
3.5/10
Scor UX General
2/10
Navigare & IA
4/10
Design Vizual
1/10
Responsive
2/10
Accesibilitate
8/10
Performanță Server
8/10
Acoperire Funcțională
3/10
Potențial SaaS (actual)
Secțiunea 01

Sumar executiv

BOCP este un produs cu acoperire funcțională impresionantă — un ERP complet cu gestiune, vânzări, facturare, CRM, AWB, integrări eMag/eCommerce, contabilitate — construit de-a lungul anilor pentru nevoile reale ale IMM-urilor din România. Serverul este rapid (TTFB 104ms), iar echipa de dezvoltare este activă (changelog recent cu feature-uri noi).

Context echipă: BOCP a fost construit de o echipă de 3 programatori care au reușit singuri să aducă un ERP complet la un nivel funcțional pe care mulți competitori cu echipe mult mai mari nu îl ating. Aceasta este o realizare remarcabilă. Echipa este clar puternică pe partea tehnică și de logică de business. Provocarea nu este de competență, ci de specializare — UX/UI design este o disciplină separată, iar lipsa unui specialist dedicat se reflectă în interfață, nu în funcționalitate.

Problema fundamentală: interfața și arhitectura frontend-ului sunt blocate într-un tipar tehnologic de acum 10-15 ani. jQuery monolitic, navigare fără URL-uri reale, zero responsive design, și un design vizual inconsistent de la modul la modul. Acest lucru:

  • Face onboarding-ul noilor utilizatori extrem de dificil (curba de învățare abruptă)
  • Elimină complet utilizarea pe mobil/tablet — un deal-breaker în 2026
  • Blochează scalarea ca SaaS modern (self-service signup, freemium, product-led growth)
  • Creează risc de churn pentru clienți care compară cu SmartBill, Oblio sau alte soluții moderne

Vestea bună: valoarea stă în logica de business și integrările locale, nu în interfață. Cu o strategie corectă de modernizare — prin API-zarea completă a aplicației și construirea unei interfețe noi ca proiect separat, ghidat de un consultant UI/UX — BOCP poate deveni un produs SaaS competitiv fără a pierde funcționalitatea existentă.

Secțiunea 02

Starea curentă — galerie vizuală

Capturi realizate automat prin Playwright pe 6 aprilie 2026, la 1440×900. Detalii despre fiecare problemă în secțiunile următoare.

Dashboard BOCP
Dashboard — supraîncărcat, fără ierarhie vizuală
Sidebar Catalog expandat
Sidebar — dropdown flotant cu contoare " 0"
Catalog produse
Catalog Produse — funcțional, vizual datat
Modul Comenzi
Comenzi — tab-uri multiple, complex
CloudCRM Calendar
CloudCRM Calendar — cel mai curat modul Pozitiv
BOCP pe mobil 375px
Mobil 375px — complet inutilizabil
Secțiunea 03

Experiența utilizatorului — cum se simte să folosești BOCP

Dincolo de screenshot-uri și metrici tehnice — ce se întâmplă în capul unui utilizator real.

Critic

Curba de învățare — abruptă și descurajantă

Experiența tipică a unui utilizator nou: primești cont BOCP, te loghezi, și ești lovit de un dashboard cu 9 tabele, 8 grafice, un changelog tehnic, și un sidebar cu 11 module. Nu ai nicio indicație de unde să începi. Nu există ghid, nu există „Pasul 1", nu există nimic care să spună „fă asta acum".

Reacția naturală: te blochezi. Începi să dai click pe module random. Fiecare modul deschide un sub-meniu flotant cu 5-15 opțiuni sufixate cu „ 0". Nu înțelegi ierarhia. Dai click pe ceva, se încarcă un tabel, dar nu știi dacă ești în locul corect. Dai Back — te scoate din aplicație. Dai refresh — te readuce la dashboard. Ai pierdut contextul.

După câteva zile de frustrare, un utilizator tipic învață pe de rost calea către 3-4 funcții pe care le folosește zilnic (emite factură, vezi comenzi, verifică stoc). Restul aplicației rămâne terra incognita — funcționalități puternice pe care utilizatorul nu le descoperă niciodată pentru că nu știe că există sau nu știe unde sunt.

Critic

Cele 4 faze ale utilizatorului BOCP

1
Confuzie

Primele 1-3 zile. „Ce e asta? Unde dau click? De ce s-a schimbat ecranul?" Utilizatorul nu înțelege structura și nu găsește ce caută. Fiecare acțiune e un experiment.

2
Memorare forțată

Săptămânile 1-2. „Am învățat că Facturare e al 3-lea modul, apoi click pe al 2-lea sub-meniu." Utilizatorul memorează secvențe de click-uri, nu înțelege logica. Dacă interfața se schimbă minimal, se pierde din nou.

3
Zona de confort

Luna 1-2. „Știu să fac cele 4-5 lucruri de bază." Utilizatorul rămâne strict pe traseele memorate. Evită orice nu cunoaște. Funcționalități puternice ale aplicației rămân neutilizate.

4
Rezistență la schimbare

Luna 3+. „Nu atinge nimic, că merge." Utilizatorul are o relație de supraviețuire cu interfața. Orice modernizare este percepută ca amenințare — chiar dacă obiectiv ar fi o îmbunătățire.

Ridicat

Profiluri de utilizatori și cum reacționează diferit

Profil utilizator Reacție tipică Ce pierde
Operatorul
procesează comenzi, emite facturi, 8h/zi în aplicație		 Memorează click-urile, lucrează cu „mușchi memory". Dacă un buton se mută, e criză. Niciodată nu explorează funcții noi Automatizări, scurtături, bulk operations — funcții care i-ar salva ore pe zi
Managerul
verificări rapide: stoc, comenzi, sold, ocazional din telefon		 Deschide aplicația, se uită la dashboard-ul aglomerat, nu găsește rapid informația. Pe telefon — renunță complet Rapoarte, analize, KPI-uri — exact funcțiile pentru care un manager ar plăti premium
Contabilul
facturi, cheltuieli, rapoarte fiscale		 Funcțional, dar navighează prin trial-and-error între module. Confuzie între „Financiare" și „Documente" — unde e factura? Integrări contabile, rapoarte avansate, export-uri care există dar nu le găsește
Utilizatorul nou (evaluare)
testează dacă BOCP e potrivit pentru firma lui		 Părăsește aplicația în 10-15 minute. Fără onboarding, fără ghid, interfața pare veche și complicată. Alege SmartBill/Oblio care „pur și simplu funcționează" Devine clientul competiției — chiar dacă BOCP e funcțional superior
Ridicat

Sindromul „nu știu ce nu știu"

Cel mai costisitor efect al unei interfețe greu de navigat nu este frustrarea — este funcționalitatea invizibilă. BOCP are module de producție, rețete, CRM, AWB generator, integrări marketplace, document management — capabilități pe care competitorii nu le au. Dar dacă un utilizator nu descoperă niciodată aceste funcții, e ca și cum nu ar exista.

Un produs cu 100 de funcționalități din care utilizatorul folosește 10 este, practic, un produs cu 10 funcționalități. Iar alea 10 le are și SmartBill — cu o interfață mai clară. Diferențiatorul BOCP dispare dacă nimeni nu-l descoperă.

De ce rămân totuși clienții actuali: BOCP oferă o funcționalitate integrată care ar fi foarte greu și foarte scump de reprodus cu alte unelte — gestiune + facturare + CRM + producție + AWB + marketplace într-un singur loc. Clienții existenți rămân pentru că alternativa e mai rea, nu pentru că experiența e bună. Dar nu folosesc produsul la ce poate — ci doar la ce au reușit să învețe prin memorare. O interfață modernă nu ar fi doar un facelift — ar fi o invitație pentru clienții existenți să descopere și să folosească pe bune produsul pentru care deja plătesc.

Mediu

Frica de a „strica ceva"

Un pattern comun la utilizatorii BOCP: nu explorează de frică să nu strice ceva. Într-un ERP, orice click greșit poate genera o factură, modifica un stoc, sau trimite un document. Fără Undo, fără draft/preview, fără confirmare clară înainte de acțiuni ireversibile, utilizatorul preferă să nu riște. Rezultat: adoptarea rămâne superficială, iar funcțiile avansate rămân neutilizate.

Soluție: Un sistem modern de confirmări contextuale („Ești sigur că vrei să emiți factura #1234 pe suma de 5.000 RON?"), mod draft/preview înainte de acțiuni finale, și Undo acolo unde e posibil tehnic.

Secțiunea 05

Design, Responsive și Accesibilitate

Absența unui Design System, zero suport mobil, și nerespectarea standardelor de accesibilitate.

Ridicat

Fără Design System unitar

Fiecare modul pare dezvoltat independent, în perioade diferite, cu stiluri diferite:

  • Butoanele — variază între <button>, <input type="button">, <a> stilizate ca butoane, și <div>-uri cu onclick. Nu există o clasă unitară de buton
  • Tabelele — unele au header colorat, altele nu. Unele au hover pe rânduri, altele nu. 9 tabele pe pagina de dashboard
  • Formularele — input-uri cu stiluri mixte, fără layout consistent (unele pe o coloană, altele pe două, fără regulă)
  • Culorile — mix de verde (#2e7d32), roșu, albastru, portocaliu fără o paletă definită. Fiecare modul își alege culorile
  • Tipografia — 3 fonturi încărcate: PT Sans Narrow, Roboto, Roboto Condensed. Folosite inconsistent
Mediu

Bug vizual: CSS în heading

Un element <h2> din pagina de dashboard conține literal cod CSS inline: ".tb-filter {float:left;}". Acesta este un bug care denotă lipsă de quality assurance pe layer-ul de prezentare.

Scăzut

69 de modale pre-încărcate în DOM

Dashboard-ul încarcă 69 de elemente modale în DOM la page load, chiar dacă niciuna nu este vizibilă. Aceasta indică o arhitectură "include totul, afișează la nevoie" care crește complexitatea paginii și poate cauza conflicte de ID/clasă între modale.

Responsive și Mobile

Critic

Zero suport mobil funcțional

Deși există tag <meta name="viewport">, nu există nicio media query sau layout adaptiv implementat. Rezultatele pe dispozitive mobile:

  • 375px (iPhone) — Sidebar-ul de 175px ocupă aproape jumătate din ecran. Conținutul este înghesuit pe ~200px lățime, cu text trunchiat și butoane imposibil de apăsat. Dashboard-ul este inutilizabil.
  • 768px (iPad) — Layout-ul se suprapune: sidebar, workflow-ul de comenzi și KPI-urile se amestecă. Tabelele ies din viewport. Navigarea rămâne funcțională dar experiența este degradată sever.
Meniu mobil rupt
Mobil — meniu — Labels trunchiate, butoane minuscule.
Content mobil rupt
Mobil — dashboard — Tabelele de comenzi înghesuitepe ~375px.
Tablet dashboard
Tabletă (768px) — Sidebar, workflow și KPI-uri se suprapun.

Impact business: În 2026, ~55% din traficul web vine de pe mobil. Un manager care vrea să verifice o comandă sau stocul de pe telefon pur și simplu nu poate folosi BOCP. Aceasta este o barieră directă la achiziția și retenția clienților.

Critic

Nu există aplicație mobilă sau PWA

Competitorii direcți (SmartBill, Oblio) oferă fie interfețe web responsive, fie aplicații mobile dedicate. BOCP nu oferă niciuna. Adăugarea unui simplu manifest.json + service worker ar permite instalarea ca PWA, dar fără layout responsive, nu ar ajuta.

Accesibilitate (a11y)

Ridicat

Rezultate audit automat

161/242
Imagini fără atribut alt (67%)
127/247
Link-uri goale (51%)
0
Landmarks ARIA
0
Skip navigation
  • Imagini fără alt: 67% din imagini nu au atribut alt. Screen reader-urile nu pot descrie conținutul
  • Link-uri goale: 127 din 247 de link-uri nu au text sau aria-label. Navigarea cu tastatura este imposibilă de înțeles
  • Zero landmarks ARIA: Nu există <main>, <nav>, <aside>, <header>, <footer> semantic sau roluri ARIA
  • Fără skip navigation: Un utilizator de screen reader trebuie să parcurgă tot sidebar-ul la fiecare pagină
  • Heading-uri goale: Mai multe elemente <h2> au conținut gol sau CSS injectat
  • Pozitiv: Atributul lang="ro" este setat corect pe <html>
De ce contează: Directiva Europeană privind Accesibilitatea (European Accessibility Act) intră în vigoare în 2025. Companiile din UE vor fi obligate să utilizeze software accesibil. Un client enterprise care face due diligence pe furnizori va respinge BOCP din această cauză.
Secțiunea 06

Arhitectura tehnică

Stack-ul tehnologic limitează posibilitățile de modernizare incrementală.

Critic

Stack frontend legacy

Tehnologie BOCP (actual) Direcția modernă (exemple)*
Framework JS jQuery 3.6.3 (vanilla) React / Vue / Svelte / etc.
Framework CSS CSS custom monolitic Tailwind / Design System propriu / etc.
Routing onclick + AJAX manual Router cu URL-uri reale (SPA sau MPA)
State management Variabile globale JS State management structurat
Build system PHP concatenation (__combinedbocp_js.php) Build modern cu bundling și tree-shaking
API layer AJAX direct la PHP endpoints REST API / GraphQL documentat
Testing Fără (implicit) Unit + E2E testing
Component reuse Copy-paste între module Component library documentată
*Notă: Tehnologiile din coloana dreaptă sunt exemple orientative, nu recomandări ferme. Alegerea concretă a stack-ului (React vs. Vue vs. altceva, Tailwind vs. altă abordare CSS) ar trebui făcută printr-o analiză separată care ia în calcul competențele echipei, ecosistemul existent, și obiectivele pe termen lung. Ce contează este direcția (framework modern cu componente, routing real, API structurat) — nu tehnologia specifică.
Pozitiv

Performanță server excelentă

Time to First Byte: 104ms. DOM ready: 590ms. Serverul este rapid și responsiv. Infrastructura nu este problema — frontend-ul este bottleneck-ul. 142 de resurse se încarcă la page load, dar transferul total este mic (arhitectura server-side rendering ajută).

Pozitiv

Existența unui REST API (BOCP Rest API)

Modulul "Integrări" include deja un BOCP Rest API și BOCP Connect. Aceasta este fundația pe care se poate construi o interfață nouă în paralel. Întrebarea cheie: cât de complet și documentat este acest API? Acoperă toate operațiunile CRUD pe care le face interfața curentă, sau doar un subset?

Secțiunea 07

Piață: branding, competitori, financiar

Cum se prezintă BOCP ca brand, cum se compară cu competiția, și ce spun cifrele.

Critic

Fragmentare de brand: BOCP vs. CloudERP vs. Real Life

Același produs, făcut de aceeași firmă, apare online sub 3 identități diferite:

  • BOCP (bocp.eu) — acronim de la „Business Online Control Panel". Generic, neintuitiv, nu comunică ce face produsul. Alt text-ul de pe site scrie „Business Control Online Panel" — nici expansiunea acronimului nu e consistentă
  • CloudERP (clouderp.ro) — un al doilea site WordPress, pentru același produs. Textul de pe pagină confirmă: „CloudERP face parte din Business Online Control Panel (BOCP)". Logo-ul de pe acest site scrie „Real Life Solutions" — nici BOCP, nici CloudERP
  • Real Life SRL — numele firmei. Apare pe unele materiale, pe altele nu. Nicio legătură semantică cu produsul ERP

Rezultat: Un potențial client care caută soluții ERP online se lovește de 3 branduri care nu fac referire unele la altele. SEO-ul se diluează între 2 domenii. Încrederea scade — „Sunt firme diferite? E același produs? De ce are două site-uri?"

Dimensiune BOCP / CloudERP SmartBill Oblio
Firma Real Life SRL Intelligent IT SRL Oblio Software SRL
Nume produs BOCP + CloudERP (2 branduri) SmartBill (1 brand) Oblio (1 brand)
Domeniu bocp.eu + clouderp.ro (2 site-uri) smartbill.ro oblio.eu
Aliniare nume Firmă ≠ Produs ≠ Domeniu Produs = Domeniu (firma invizibilă) Firmă ≈ Produs = Domeniu
Clar ce face? Nu — acronim + mega-meniu cu 10+ module Da — „program de facturare și gestiune" vizibil instant Da — „program de facturare" + cifre sociale
Sub-branduri vizibile 6+ module + 10+ CRM sub-branduri pe CloudERP 4 sub-produse cu prefix comun (SmartBill Facturare, Gestiune, Conta, POS) 0 sub-branduri — funcții ca navigare, nu branduri
Ridicat

Oportunitate strategică: spargerea în sub-produse

BOCP are de fapt mai multe produse într-unul singur — gestiune, facturare, CRM, AWB, marketplace, producție. Dar le prezintă toate într-un singur pachet monolitic, greu de înțeles.

Abordarea competitorilor funcționează: SmartBill are „SmartBill Facturare" (gratuit sau ieftin), care atrage utilizatorul, apoi face upsell la „SmartBill Gestiune" și „SmartBill Conta". Oblio oferă 1 an gratuit ca poartă de intrare.

Ce ar putea face BOCP: Odată cu interfața nouă, produsul se poate structura modular — un core gratuit/freemium (facturare simplă) care demonstrează calitatea tehnică, cu upgrade la module avansate (gestiune completă, CRM, producție, marketplace). Fiecare modul devine un sub-produs clar, ușor de explicat, ușor de vândut. Clienții actuali folosesc BOCP pentru că funcționalitatea e greu de reprodus altundeva și ar costa mult mai mult cu alte unelte — dar nu îl folosesc la potențialul real din cauza interfeței. O migrare la interfața nouă ar fi de fapt o invitație să folosească pe bune produsul.

Un model freemium cu sub-produse ar demonstra competența tehnică a echipei BOCP și ar atrage clienți noi care azi aleg SmartBill/Oblio din inerție — pentru că au onboarding simplu, nu pentru că sunt superiori funcțional.

Context

Comparație financiară: SmartBill vs. BOCP

Cifrele de mai jos arată dimensiunea oportunității. SmartBill (Intelligent IT SRL) și BOCP (Real Life SRL) au pornit în aceeași perioadă, cu produse comparabile ca scop. Diferența de traiectorie reflectă impactul UX-ului, branding-ului și go-to-market-ului — nu al funcționalității.

An SmartBill — Cifra de afaceri (RON) BOCP — Cifra de afaceri (RON) Raport
2016 4.498.354 254.493 18x
2018 10.531.869 379.327 28x
2020 17.222.792 536.726 32x
2022 30.535.513 655.893 47x
2023 43.128.285 756.796 57x
2024 74.645.588 953.853 78x
SmartBill 2024
74,60M RON
Profit net: 40,8M RON | 66 angajați | Cash: 93,7M RON
BOCP 2024
0,95M RON
Profit net: 43K RON | 7 angajați | Echipă mică, produs mare
Ce înseamnă aceste cifre: SmartBill a crescut de la 4,5M la 74,6M RON în 8 ani (17x) — cu un produs funcțional inferior BOCP-ului. Diferența: interfață modernă, branding clar, onboarding simplu, self-service sign-up. BOCP a crescut de la 254K la 953K (3.7x) în aceeași perioadă — cu un produs tehnic superior. Gap-ul de 78x nu reflectă diferența de calitate, ci diferența de accesibilitate. Un UX modern cu branding clar nu garantează aceeași traiectorie, dar elimină blocajul principal care o împiedică.

Comparație funcțională cu competitorii

Criteriu BOCP SmartBill Oblio FGO SAGA Cloud
Acoperire ERP ✓ Complet (gestiune, vânzări, CRM, AWB, producție) ● Facturare + gestiune de bază ● Facturare focus ● Facturare + gestiune ✓ ERP complet
UI modernă ✗ jQuery legacy, circa 2012 ✓ React, design modern ✓ Clean, modern ● Parțial modernizat ✗ Legacy Windows-like
Responsive / mobil ✗ Zero ✓ App mobilă + responsive ✓ Responsive ● Parțial ✗ Desktop only
URL routing ✗ Single URL ✓ SPA cu routing ✓ Da ✓ Da ✗
API public ● Existent, acoperire necunoscută ✓ REST API documentat ✓ REST API documentat ● Limitat ✗
Integrări eCommerce ✓ eMag, eCommerce, Baselinker, Altex ✓ Diverse ● Limitate ● Limitate ● Limitate
Integrări curieri ✓ Sameday, Cargus, Dragonstar, Fan + AWB generator ● Prin parteneri ✗ ● Limitate ✗
CRM integrat ✓ CloudCRM (Calendar, Task Manager) ✗ ✗ ✗ ● Basic
Self-service onboarding ✗ Necesită setup manual ✓ Sign up online ✓ Sign up online ✓ Sign up online ✗
Producție / Rețete ✓ Modul dedicat ✗ ✗ ✗ ✓

Concluzie competitivă

BOCP are cea mai largă acoperire funcțională din comparație — este singurul care combină ERP complet + CRM + AWB generator + integrări eCommerce + producție într-un singur produs. SmartBill și Oblio sunt superioare la UX și onboarding, dar inferioare ca funcționalitate ERP. SAGA Cloud este comparabil funcțional dar are aceleași probleme de interfață legacy.

Riscul strategic: SmartBill și Oblio extind constant funcționalitățile (gestiune, rapoarte avansate) și se apropie de acoperirea BOCP, dar cu o interfață modernă. Dacă BOCP nu modernizează UI-ul, diferențiatorul funcțional se va eroda în 2-3 ani.

Secțiunea 08

Strategii de modernizare

Trei opțiuni analizate — de la quick wins până la refactoring complet. Estimări în zile/om și luni.

Opțiunea A — Quick Wins (Îmbunătățiri incrementale)

Păstrarea stack-ului existent (jQuery + PHP) cu îmbunătățiri targetate pe cele mai dureroase probleme.

Efort total
60–90 zile/om
Durată cu 2 devs
2–3 luni
Risc
Scăzut
Impact UX
Scor: 3.5 → 5/10
  • URL routing cu History API — adaugă pushState() la BOCP_load_module() pentru URL-uri adresabile. ~10 zile/om
  • Responsive basics — sidebar colapsabil pe mobil (hamburger), tabele scrollabile, media queries. ~15 zile/om
  • Design cleanup — paletă de culori unitară, un singur font, clasă de buton standardizată. ~10 zile/om
  • Curățare dashboard — mută changelog în secțiune separată, prioritizează KPI-uri și comenzi. ~5 zile/om
  • Accesibilitate de bază — alt pe imagini, aria-labels, landmarks, skip nav. ~10 zile/om
  • Breadcrumbs + active state sidebar — ~5 zile/om
  • Eliminare bug-uri vizuale (CSS in heading, contoare " 0", modale inutile). ~5 zile/om

Limitare: Această opțiune rezolvă simptomele dar nu cauza. Arhitectura jQuery monolitic rămâne, iar fiecare feature nou va fi la fel de dificil de implementat ca înainte. Nu rezolvă problema fundamentală de scalabilitate.

Opțiunea B — Proiect separat: API-zare + Frontend nou + Consultant UI/UX

Interfața nouă se construiește ca proiect separat (branch out), nu ca patch pe legacy. Pas esențial înainte de orice frontend: API-zarea completă a aplicației. API-ul existent (BOCP Rest API) este probabil un addon ulterior, nu o fundație structurală — trebuie reconstruit cu gândul că întreaga interfață nouă va depinde exclusiv de el.

Efort total
240–350 zile/om
Echipă
3 devs BOCP + consultant UI/UX + 1-2 frontend
Risc
Mediu
Impact UX
Scor: 3.5 → 8.5/10
Esențial

De ce e nevoie de un consultant UI/UX

Echipa BOCP este formată din 3 programatori care au construit singuri un ERP complet — o realizare impresionantă. Au demonstrat competență tehnică excepțională și înțelegere profundă a domeniului. Dar UX/UI design este o disciplină separată de programare, la fel cum arhitectura este separată de construcții.

Un consultant UI/UX extern (nu angajat full-time, ci pe proiect) ar aduce:

  • Design System — paletă de culori, tipografie, spacing, componente standardizate. Echipa dev implementează, consultantul definește regulile
  • Wireframes și prototipuri — înainte de a scrie cod, se validează flow-urile cu utilizatori reali
  • Ghid de interacțiune — cum se comportă navigarea, tabelele, formularele, notificările — decizii pe care programatorii nu ar trebui să le ia singuri
  • Validare cu utilizatori — teste de uzabilitate pe prototipuri, nu pe cod finit (unde schimbările sunt scumpe)

Implicare estimată: Consultant UI/UX senior, part-time pe durata proiectului (2-3 zile/săptămână în primele 2 luni, apoi 1 zi/săptămână pentru review și iterații).

Pas 0 — API-zarea aplicației (Lunile 1–4)

De ce Pas 0 și nu Faza 1: API-ul existent (BOCP Rest API) a fost cel mai probabil adăugat ulterior, ca un layer peste funcționalitățile existente — nu a fost gândit structural ca fundație pentru un frontend complet. Dacă se începe direct cu interfața nouă fără un API solid, se va ajunge la un frontend frumos care depinde de hack-uri și workaround-uri pentru a comunica cu backend-ul. API-ul trebuie să devină sursa unică de adevăr (single source of truth) pentru toată logica de business.
  • Audit API existent — ce endpoints există, ce acoperă, ce e documentat, ce e ad-hoc
  • Reproiectare structurală — API-ul trebuie gândit pe resurse (produse, comenzi, contacte, facturi, stocuri), nu pe ecrane UI. RESTful corect, cu versionare
  • Acoperire completă — fiecare operațiune CRUD din interfața curentă (~80 ecrane) trebuie să aibă corespondent API
  • Documentare OpenAPI/Swagger — documentație generată automat, testabilă
  • Autentificare modernă — JWT/OAuth2, nu sesiuni PHP clasice
  • Cine face: Echipa BOCP (cei 3 devs) — ei cunosc logica de business cel mai bine. Aceasta este munca lor core
  • Efort: ~60–90 zile/om

Faza 1 — Design System + Prototipuri (Lunile 3–5)

Condusă de consultantul UI/UX, în paralel cu finalizarea API-ului

  • Consultantul UI/UX definește: paletă culori, tipografie, grid system, componente (Button, Input, Table, Modal, Card)
  • Wireframes low-fidelity pentru ecranele cheie: Dashboard, Catalog, Comenzi, Facturi, Contacte
  • Prototipuri interactive (Figma) — validate cu 3-5 utilizatori BOCP reali
  • Documentare Design System — ghid pe care developerii îl urmează
  • Efort consultant: ~15–20 zile

Faza 2 — Frontend nou ca proiect separat (Lunile 4–8)

Repo separat, echipă dedicată (poate include și devs externi), consumă exclusiv API-ul. Stack-ul concret se decide printr-o analiză tehnică separată — exemplele de mai jos sunt orientative.

  • Setup proiect cu framework modern (React, Vue, Svelte, sau altul potrivit echipei) + sistem CSS scalabil + component library
  • Implementare Design System definit de consultant
  • Module prioritare: Dashboard, Catalog Produse, Comenzi, Facturi, Contacte
  • URL routing real, responsive din start (mobile-first), căutare globală (Cmd/Ctrl+K)
  • Review periodic cu consultantul UI/UX (1 zi/săptămână)
  • Efort: ~100–150 zile/om (1–2 frontend devs + review consultant)

Faza 3 — Module secundare + migrare (Lunile 7–11)

  • Restul modulelor: Gestiune, Financiare, Documente, CloudCRM, Integrări, Rapoarte, Sistem
  • PWA support (install pe mobil/desktop)
  • Onboarding flow pentru utilizatori noi
  • Migrare graduală clienți (dual-access period — interfața veche rămâne disponibilă)
  • Efort: ~60–90 zile/om
De ce este recomandat: Interfața veche rămâne funcțională — zero risc de downtime. Echipa BOCP se concentrează pe ce știe cel mai bine (backend, logică de business, API). Consultantul UI/UX aduce viziunea pe care echipa tehnică nu o are (și nu ar trebui să o aibă — nu e rolul lor). API-ul creat devine asset pe termen lung — permite nu doar interfața nouă, ci și integrări third-party, aplicație mobilă nativă, și parteneriate tehnice.
Riscul principal: Dacă API-zarea se face superficial (doar wrapping peste cod existent), frontend-ul nou va moșteni limitările arhitecturale ale backend-ului. Pas 0 trebuie făcut corect, chiar dacă durează mai mult decât estimat.

Opțiunea C — Rescriere completă

Full rewrite: backend nou (Node.js/Go/Python) + frontend nou + bază de date reproiectată. Produs complet nou.

Efort total
500–800 zile/om
Durată cu echipă de 5
12–18 luni
Risc
Foarte ridicat
Impact UX
Scor: 3.5 → 9/10 (teoretic)

Nu recomandat. Rescrierea completă este "second system syndrome" clasic. Se pierd ani de logică de business validată, edge cases rezolvate, și integrări fine-tuned. Riscul de a livra ceva inferior funcțional este foarte mare. Joel Spolsky (co-founder Stack Overflow) numește rescrierea completă "cea mai mare greșeală strategică pe care o poate face o companie de software".

Secțiunea 09

Sugestii UX detaliate pentru interfața modernă

Cum ar trebui să arate fiecare aspect al aplicației modernizate (aplicabil Opțiunii B).

Fundamental

Înainte de UI — regândirea proceselor de business

O interfață nouă peste procese vechi produce doar un haos mai frumos. Înainte de a desena ecrane, trebuie mapate și simplificate procesele de business din spatele aplicației — nu doar transpuse 1:1 din interfața veche.

Ce înseamnă concret: Pentru fiecare modul major (Comenzi, Facturare, Gestiune, CRM), se identifică scenariile reale de utilizare și se simplifică la maximum fiecare flow:

  • Scenariu: „Operator procesează o comandă nouă" — Câți pași sunt azi? Ce informații vede pe ecran care nu îi sunt utile în acel moment? Ce decizii ia la fiecare pas? Poate fi redus de la 8 clickuri la 3?
  • Scenariu: „Manager verifică stocul unui produs" — Trebuie să navigheze prin 3 module sau poate vedea totul dintr-un singur ecran? Informația critică e vizibilă imediat sau ascunsă sub tab-uri?
  • Scenariu: „Contabil emite factură din comandă" — Datele se preiau automat sau se completează manual? Câte câmpuri din formular sunt cu adevărat necesare vs. „le-am pus pentru orice eventualitate"?
  • Scenariu: „Client nou — de la creare cont la prima factură" — Care e drumul cel mai scurt? Ce pași pot fi eliminați sau amânați?

Principiu: Fiecare ecran trebuie să răspundă la o singură întrebare: „Ce trebuie să facă utilizatorul acum?" — și să îi arate doar ce are nevoie pentru acea acțiune. Tot restul se ascunde, nu se șterge. Funcționalitatea avansată rămâne accesibilă, dar nu mai stă în cale.

Cine face asta: Consultantul UI/UX împreună cu echipa BOCP și 2-3 utilizatori reali (ideal: un operator, un manager, un contabil). Echipa BOCP știe ce face aplicația. Utilizatorii știu ce au nevoie. Consultantul traduce între cele două lumi. Acest exercițiu se face înainte de wireframes și prototipuri — este input-ul pe baza căruia se desenează interfața.

Riscul de a sări peste acest pas: Se construiește o interfață nouă, modernă tehnologic, dar care replică exact aceleași flow-uri și aceeași structură din aplicația veche. Utilizatorii tot nu înțeleg procesele, tot au nevoie de training, tot fac erori — într-un ambalaj nou. Valoarea reală a modernizării vine din simplificarea proceselor, nu doar din schimbarea tehnologiei.

01

Sidebar colapsabil cu tooltips + căutare globală

Sidebar-ul ar trebui să fie colapsabil la iconițe (60px) cu un toggle. Pe mobil, devine drawer care se deschide la swipe sau hamburger. Fiecare modul: iconiță + text label. Sub-modulele apar în flyout la hover/click. Modulul activ evidențiat cu background accent. Căutare globală (Cmd+K) care indexează toate modulele, acțiunile, și chiar datele (caută un produs, contact, factură — direct din search bar).

15–20 zile/om
02

Dashboard configurabil cu widget-uri

Înlocuiește dashboard-ul fix cu un sistem de widget-uri drag-and-drop. Fiecare utilizator își alege ce vede: Comenzi noi, KPI grafice, Sold casă, Calendar, Alerte. Changelog-ul devine o secțiune "What's New" accesibilă dintr-un bell icon din header, nu de pe dashboard. Default layout pre-configurat per rol (Manager, Operator, Contabil).

20–30 zile/om
03

Tabel component universal cu sort, filter, export

Un singur component <DataTable> reutilizat în toată aplicația: sortare pe coloane, filtre inline, paginare, selecție multiplă, export CSV/Excel, column resize, column visibility toggle. Bazat pe TanStack Table (fost React Table) — standard în industrie. Înlocuiește cele 9+ implementări de tabel diferite din aplicația curentă.

10–15 zile/om
04

Formulare consistente cu validare în timp real

Design System cu componente de formular standardizate: input text, select, date picker (înlocuiește flatpickr actual cu o soluție integrată), textarea, checkbox, radio, file upload. Fiecare input are label, placeholder, helper text, error state. Validare client-side cu mesaje clare în română. Layout formular: max 2 coloane pe desktop, 1 coloană pe mobil. Secțiuni colapsabile pentru formulare lungi.

10–15 zile/om
05

Workflow vizual pentru comenzi (Kanban board)

Dashboard-ul actual de comenzi (Comenzi Noi → Pregătire → Livrare) este o idee bună dar implementarea este rigidă (tabel cu iconițe). Înlocuiește cu un Kanban board drag-and-drop (stil Trello) unde comenzile se mută vizual între coloane. Fiecare card: client, sumă, produse, status curier. Click pe card deschide detalii într-un panel lateral (slide-over), nu într-o pagină nouă.

15–20 zile/om
06

Notificări și alertare modernă

Înlocuiește "Centrul de alerte" static cu un sistem de notificări în timp real (WebSocket): bell icon cu badge count în header, dropdown cu notificări grupate pe tip, mark as read, link direct la resursa relevantă. Notificări push pe mobil (via PWA + Push API). Configurabile per utilizator: ce tip de alertă, pe ce canal (in-app, email, push).

10–15 zile/om
07

Pagină de login profesională cu branding

Login page cu: logo centrat pe fundal alb/gradient subtil (fără cireși), companie name, opțiuni SSO (Google Workspace — relevant pentru business), 2FA cu authenticator app, "Remember me", forgot password flow, link către landing page produs. Adaptare automată cu logo-ul clientului (white-labeling) pentru multi-tenancy.

3–5 zile/om
08

Onboarding interactiv pentru utilizatori noi

Wizard de setup la prima autentificare: configurare companie, import date, tutorial interactiv (product tour cu tooltips pe fiecare zonă — librărie: Shepherd.js sau custom). Checklist de onboarding persistent ("Ai configurat facturarea? Ai adăugat primul produs?"). Obiectiv: un utilizator nou să emită prima factură în sub 10 minute, fără training extern.

10–15 zile/om
09

Keyboard shortcuts și Command Palette

Power users (contabili, operatori care lucrează 8h/zi în aplicație) au nevoie de shortcut-uri: Ctrl+N comandă nouă, Ctrl+F factură nouă, Ctrl+K search global, Esc închide modal. Pagină de shortcuts accesibilă cu ?. Reduce timpul per operațiune cu 30-50% pentru utilizatori frecvenți.

5–8 zile/om
10

Dark mode și personalizare vizuală

Dark mode nu este cosmetic — reduce eye strain pentru utilizatori care petrec ore în aplicație. Implementare: CSS custom properties (variabile) pentru toate culorile, toggle în header. Respectă prefers-color-scheme din OS. Bonus: densitate informațională configurabilă (compact/comfortable/spacious) — util pentru ecrane mici vs. monitoare mari.

5–8 zile/om
Secțiunea 10

AI ca forță de muncă principală, nu doar asistent

În 2026, AI-ul nu mai e un „nice to have" — este diferența dintre un proiect de 12 luni și unul de 5. Ideea nu e că AI-ul ajută developerii. Ideea e că developerii ghidează AI-ul care face grosul muncii.

Schimbarea de paradigmă: AI-first development

Abordarea clasică: un developer scrie cod, AI-ul sugerează autocompletare. Asta e 2023.
Abordarea 2026: AI-ul generează module întregi — componente, pagini, integrări API, teste, documentație. Developer-ul devine arhitect + reviewer: definește ce trebuie construit, validează output-ul, corectează edge cases, și se asigură că totul funcționează împreună. Cu o echipă de 3 devs care știu produsul + AI, se poate acoperi munca echivalentă a 8-10 devs.

Unde AI-ul face munca grea — concret, per fază

Pas 0 — API-zare (reducere ~40%)

  • Generare endpoints din cod existent: AI-ul poate analiza codul PHP/jQuery existent și genera automat endpoint-uri REST echivalente — inclusiv validări, tipuri de date, și documentație OpenAPI. Developer-ul review-uiește și ajustează logica de business
  • Documentare automată: Din endpoint-uri funcționale, AI-ul generează complet documentația Swagger/OpenAPI, cu exemple, descrieri parametri, și response schemas
  • Generare teste API: AI-ul scrie suita de teste (integration + contract tests) pentru fiecare endpoint — developer-ul adaugă doar cazurile specifice domeniului pe care AI-ul nu le cunoaște
  • Migrare autentificare: Boilerplate-ul JWT/OAuth2 este generat 95% de AI — este un pattern standard și bine documentat

Faza 2 — Frontend (reducere ~50-60%)

  • Componente complete din Design System: Consultantul UI/UX definește regulile (culori, spacing, comportament). AI-ul generează toată implementarea: fiecare componentă, fiecare variantă, fiecare stare (hover, disabled, error, loading). Developer-ul face fine-tuning, nu scrie de la zero
  • Pagini întregi din wireframe: Un wireframe Figma sau chiar o descriere text devine o pagină funcțională. AI-ul generează layout-ul, conectează la API, implementează filtre, sortare, paginare. Outputul e 70-80% production-ready
  • Responsive și adaptiv: Odată ce o pagină funcționează pe desktop, AI-ul generează toate breakpoint-urile (mobile, tablet) — acesta e un task mecanic perfect pentru AI
  • Formular → API → validare → error handling: Întregul flow de formular (câmpuri, validare client, submit la API, handling erori, success state) se generează complet dintr-o singură descriere
  • Teste E2E: AI-ul generează teste Playwright/Cypress pentru fiecare pagină — click flows, form submissions, edge cases. Developer-ul review-uiește, nu scrie

Faza 3 — Module secundare (reducere ~60-70%)

  • Pattern replication: După ce primele 5 module sunt construite, AI-ul înțelege pattern-urile proiectului. Modulele următoare se generează aproape complet — developer-ul doar adaptează logica specifică
  • Migrare date și flow-uri: AI-ul poate analiza flow-urile din interfața veche (via screenshots sau cod) și genera echivalentul în interfața nouă

Estimare realistă cu AI-first approach

Fază Efort tradițional Efort AI-first Ce face AI-ul
Pas 0 — API-zare 60–90 zile/om 35–55 zile/om Generare endpoints, docs OpenAPI, teste, boilerplate auth
Faza 1 — Design System 15–20 zile consultant 10–15 zile consultant Prototipare rapidă, iterații vizuale instantanee
Faza 2 — Frontend core (5 module) 100–150 zile/om 45–75 zile/om Componente, pagini, API integration, responsive, teste
Faza 3 — Module secundare + migrare 60–90 zile/om 20–35 zile/om Pattern replication — module aproape identice structural
TOTAL 240–350 zile/om 110–180 zile/om Reducere ~50-55%
Condiția esențială: Aceste reduceri presupun developeri care știu să lucreze cu AI — prompt engineering, iterare pe output, review calitativ. Un developer care nu a lucrat niciodată cu Claude Code sau Cursor va fi mai lent în prima lună. Investiția în onboarding pe AI tools (2-3 zile) se amortizează în prima săptămână de muncă reală.

⚡ Claude Code

Arhitect AI

Generare module întregi: „construiește pagina de Catalog Produse cu tabel sortabil, filtre, paginare, conectat la API endpoint /products". Output: pagină funcțională completă. Developer: review + deploy.

⚡ AI pentru API scaffolding

Pas 0 accelerator

Analiză cod PHP existent → generare endpoint-uri REST echivalente cu validări, documentație, și teste. Echipa BOCP review-uiește logica de business, nu scrie boilerplate.

⚡ AI pentru QA + Teste

Elimină bottleneck-ul

Generare completă de teste: unit, integration, E2E. Fiecare PR include teste generate de AI, review-uite de developer. Fără AI, testele se scriu ultimele (sau deloc). Cu AI, vin gratuit.

Workflow concret: cum arată o zi de lucru AI-first

// Dimineața — developer definește ce trebuie construit: 09:00 Review wireframe de la consultant pt. pagina Comenzi 09:15 Prompt AI: "Generează pagina Comenzi conform wireframe-ului, cu tabel sortabil, filtre status/data/client, detail panel slide-over la click pe rând, conectat la GET /api/orders" 09:20 AI generează pagina completă (~500 linii cod) // Mijlocul zilei — developer review-uiește și ajustează: 09:20–11:00 Review output: corectează logica de filtrare specifică BOCP, ajustează formatare date/sume, adaugă edge case pt. comenzi anulate 11:00 Prompt AI: "Adaugă responsive layout — pe mobil tabelul devine card list, detail panel devine full screen" 11:05 AI generează varianta responsive 11:05–12:00 Review + fine-tuning responsive // După-amiaza — teste și polish: 13:00 Prompt AI: "Generează teste E2E Playwright: filtrare, sortare, click pe comandă, verificare detail panel, flow mobil" 13:05 AI generează 15 teste 13:05–14:00 Review teste, adaugă 2-3 cazuri specifice domeniului 14:00–15:00 Prompt AI pentru pagina următoare (Facturi) // Rezultat: 2 pagini complete/zi în loc de 2 pagini/săptămână
Secțiunea 11

Concluzie și pași următori

BOCP este un produs cu fundament solid și acoperire funcțională superioară competiției. Logica de business, integrările locale (eMag, curieri, eTransport), și baza de clienți existentă reprezintă valoare reală care nu se poate replica ușor. Echipa de 3 programatori care a construit totul merită respect — au livrat un ERP complet acolo unde alții cu echipe mai mari au livrat doar facturare.

Interfața este singurul blocaj major. Nu backend-ul, nu funcționalitatea, nu infrastructura — ci modul în care utilizatorul interacționează cu produsul. Aceasta nu este o problemă de competență a echipei, ci de specializare — UX/UI design este o disciplină separată.

Recomandarea strategică: Opțiunea B — proiect separat cu 3 pași cheie:

  1. Pas 0 — API-zarea completă a aplicației (echipa BOCP, care cunoaște logica de business)
  2. Consultant UI/UX extern care definește Design System-ul și validează cu utilizatori
  3. Frontend nou ca proiect separat, construit exclusiv pe API

Efort estimat cu abordare AI-first: 110–180 zile/om, distribuibil pe 6–9 luni. Rezultatul: un produs cu aceeași funcționalitate robustă dar cu o interfață la nivel SmartBill/Oblio, plus avantajul funcțional pe care aceștia nu îl au.

Pași următori propuși

  1. Audit API (1 săptămână): Evaluare completă a BOCP Rest API existent — ce endpoints există, ce acoperă, ce e structural vs. ad-hoc, calitatea documentației. Acesta este factorul decisiv #1 — determină cât de mare este Pasul 0.
  2. Selectare consultant UI/UX (2 săptămâni): Identificarea unui consultant senior cu experiență în aplicații SaaS B2B. Briefing pe produs, echipă, și obiective. Nu trebuie să fie full-time — part-time pe proiect.
  3. Mapare și simplificare procese de business (2-3 săptămâni): Consultant + echipă BOCP + 2-3 utilizatori reali parcurg scenariile principale (comandă, factură, gestiune stoc, CRM) și simplifică fiecare flow la minimum necesar. Acesta este input-ul real pentru wireframes — nu interfața veche.
  4. Workshop + Wireframes (1 săptămână): Pe baza proceselor simplificate, primele wireframes pentru 3 ecrane cheie (Dashboard, Comenzi, Catalog Produse).
  5. Start Pas 0 — API-zare (în paralel): Echipa BOCP începe reproiectarea API-ului structural, modul cu modul. Acesta este efortul cel mai mare și cel mai important.
  6. POC (după 2 luni): Un singur modul (ex: Catalog Produse) implementat complet cu stack-ul nou (React + Tailwind + API reproiectat) pentru a valida abordarea și a calibra estimările.