Checklist 12 puncte pentru implementare software B2B în 2026

Fiecare implementare de software B2B eșuează diferit, dar cele care reușesc seamănă. După 30+ proiecte livrate, am decantat o listă de 12 puncte de care nu trecem niciodată înainte de go-live. E gândită pentru operațiuni cu peste 20 de utilizatori și procese cu impact financiar direct.

Dacă bifezi 10 din 12, riscul de a avea probleme majore în primele 90 de zile post-launch scade dramatic.

1. Sponsor executiv cu autoritate decizională

Nu manager de proiect — sponsor. Cineva care poate spune "da" la un trade-off de 5.000 EUR fără să convoace o ședință. Fără asta, fiecare blocaj devine o săptămână pierdută. La nivel de bord sau directorat e ideal.

2. Lista exhaustivă a stărilor de business

Pentru fiecare entitate critică (comandă, document de transport, factură, fișa de colectare): toate stările posibile, toate tranzițiile valide, toate excepțiile. Trebuie scrisă pe hârtie sau în Miro înainte ca cineva să atingă cod. Surprizele aici devin rework de 2-3 săptămâni mai târziu.

3. Inventarul integrărilor critice

Listă completă: cu ce sisteme vorbește aplicația ta (ANAF, ANPM, Smartbill, cântare, AVR-uri, transportatori, e-Factura, CRM, etc). Pentru fiecare:

• API documentat? Da/nu
• Authentication mode (OAuth, API key, mTLS)
• Rate limits
• Cine deține credențialele
• Plan B dacă serviciul cade 24h

4. Modelul de date congelat înainte de săptămâna 4

Pe primele 3-4 săptămâni se face descoperire și schema poate evolua liber. Începând cu săptămâna 4, fiecare schimbare de schemă devine migration — și migrațiile cu date de producție sunt scumpe. Disciplina aici plătește în luna 3.

5. Strategia de migrare a datelor istorice

Trei scenarii posibile, alegi unul:

• Hot cutover — duminică noapte se mută tot, luni pornește pe sistemul nou
• Parallel run — rulezi ambele sisteme 30 zile, reconcilieri zilnice
• Migrare etapizată — modul cu modul, în săptămâni separate

Fiecare are trade-off-uri. Ce nu e acceptabil: "vedem când ajungem acolo".

6. Setup pentru 3 medii — minim

• Development — pe care lucrează echipa
• Staging — clonă fidelă a producției, cu date sintetice
• Production — niciodată atins direct

Dacă vrei cu adevărat să nu pățești cu ștergeri accidentale, adaugi un al patrulea — UAT — în care clientul testează scenarii reale înainte de fiecare release major.

7. Strategia de backup și recovery testată

Backup automat zilnic e minimum legal. Recovery testat e minimum operațional. Fă cel puțin un drill complet (restaurare bazei într-un mediu izolat) înainte de go-live. Dacă n-ai testat recovery-ul, n-ai backup — ai un fișier.

8. Monitoring + alerting de la prima zi

• Uptime monitoring extern (UptimeRobot, Better Uptime)
• Application errors (Sentry sau echivalent) cu alertă pe canal dedicat
• Performance monitoring — măcar timpii pe rutele critice
• Business KPI alerts — alertă dacă volumul de tranzacții scade brusc cu 30%

Fără monitoring, primele probleme le afli de la clienți. Asta nu e un mod profesional de a opera.

9. Politica de access control documentată

Cine vede ce, cine modifică ce, cine șterge ce. Roluri și permisiuni mapate explicit înainte de go-live. Niciodată nu lăsa toți utilizatorii cu rol "admin" pentru că "așa e mai simplu". Auditează rolurile la fiecare 6 luni.

10. Plan de training pe roluri

Trei tipuri de utilizatori, trei tipuri de training:

• Power users — sesiune live de 4-6h, follow-up săptămânal în prima lună
• Operatori standard — video screencasts pe procese specifice + cheat sheet 1 pagină
• Management — focus pe rapoarte și KPI-uri, nu pe cum se introduce un document

Fără training structurat, adopția cade sub 60% în primele 30 de zile.

11. SLA pe suport, scris și semnat

• Timp de răspuns pe severitate (critic / major / normal / minor)
• Canal oficial de raportare incidente (nu WhatsApp pe telefonul personal al developerului)
• Escaladări — cine, când, cum
• Frecvența update-urilor de status pe incidente lungi

Nu te lăsa să intri în producție cu acord verbal "te sunăm dacă e ceva".

12. Plan de rollback pe primele 30 de zile

Dacă în prima săptămână descoperi un bug critic care afectează datele financiare, ce faci? Trei răspunsuri posibile:

• Rollback complet la sistemul vechi (necesită ca vechiul să rămână accesibil)
• Hotfix urgent + corecție de date (necesită backup-uri înainte de fiecare deploy major)
• Workaround manual pe procesul afectat (necesită ca operatorii să fi păstrat antrenamentul pe procesul vechi)

Ai 30 de zile în care decizia rezonabilă e "ne întoarcem". După 30 de zile, decizia rezonabilă devine "rezolvăm aici".

Cum folosim noi această listă

Pe fiecare proiect, primele două săptămâni de "discovery" se termină cu un document care răspunde explicit la cele 12 puncte. Dacă pe vreun punct răspunsul e "nu știm încă", nu trecem la dezvoltare — facem investigație suplimentară. Ne-a economisit, conservator, 8 luni de rework cumulat pe ultimele 12 proiecte.

Nu e un checklist exhaustiv. E un minim. Industria ta poate adăuga 5-10 puncte specifice (compliance, certificări, audit). Dar dacă nu bifezi măcar 10 din cele 12 de mai sus, riscurile cresc neliniar.

Ce facem dacă rămâi blocat pe un punct

Auditul tehnic gratuit pe care îl facem cu fiecare client nou parcurge fix această listă. Ieșim cu un raport scris pe fiecare punct — verde (ok), galben (atenție), roșu (blocant) — și un plan concret pe punctele care nu sunt încă acoperite.

Dacă deja ai un proiect în derulare și te uiți la lista asta cu un sentiment incomod — vorbim. Mai bine descoperit acum decât în săptămâna 2 post-launch.