Financiar-bancar
Dosarul de credit, cu fiecare pas reconstituibil
Într-un dosar de creditare, întrebarea nu e doar „ce s-a decis", ci „cine a văzut ce și pe ce bază". Un flux ținut pe mail nu poate răspunde la a doua.
Instituție financiară nebancară
De unde am pornit
Partea care lipsește din majoritatea studiilor de caz și singura care îți spune dacă seamănă cu situația ta.
Dosarele circulau pe mail, cu documente atașate și decizii comunicate în răspunsuri. Existau fișiere de evidență, dar ele consemnau rezultatul, nu drumul. Întrebarea „cine a văzut documentul acesta și când" nu avea un răspuns care să reziste la un control, iar întrebarea „pe ce bază s-a aprobat" avea un răspuns care depindea de memoria unui om.
Al doilea aspect era volumul. Fluxul funcționa pentru câteva dosare pe zi. Creșterea ar fi însemnat mai mulți oameni care fac aceeași muncă manuală, cu aceleași riscuri, înmulțite.
Ce se rupea, concret
- Nu exista o urmă completă a accesărilor și a deciziilor.
- Documentele cerute la fiecare etapă se verificau din obișnuință, nu din sistem.
- Separarea între cine analizează și cine aprobă era una de proces, nu una tehnică.
- Raportările obligatorii se compuneau manual, din mai multe surse.
Obiective
Ce trebuia să rezolve aplicația
Fiecare accesare și fiecare decizie să rămână în jurnal, cu autor și moment.
Etapele și documentele obligatorii să fie impuse de sistem, nu de disciplina omului.
Separarea rolurilor să fie tehnică: analistul să nu poată aproba, oricât ar vrea.
Raportările să se genereze din aceleași date, nu să se recompună de fiecare dată.
Ce am construit
Aplicația, pe module
Nu o listă de funcționalități, ci ce face fiecare bucată și de ce a fost nevoie de ea.
-
01
Fluxul de dosar
Dosarul trece prin etape definite, iar la fiecare are documentele și verificările ei obligatorii. Nu poate avansa cu ceva lipsă. Ce era înainte o listă de verificat în minte a devenit o condiție a sistemului.
Ce cuprinde
- Etape cu documente obligatorii, definite pe tip de produs
- Verificări automate pe criteriile instituției, cu punctaj
- Stări clare, vizibile pentru toți cei implicați
-
02
Roluri stricte și jurnal
Analistul pregătește, aprobatorul decide, administratorul configurează. Drepturile sunt aplicate la nivelul datelor, nu doar al ecranelor. Fiecare deschidere de dosar, fiecare document vizualizat și fiecare decizie intră în jurnal, care nu poate fi modificat de nimeni din aplicație.
Ce cuprinde
- Separare tehnică între analiză și aprobare
- Jurnal complet, nemodificabil din interfață
- Vizibilitate limitată la dosarele care îl privesc pe fiecare
-
03
Rapoarte și raportări
Rapoartele operaționale și cele necesare raportărilor obligatorii se generează din aceleași date, la cerere, pe perioadă. Nu mai există un pas intermediar în care cineva compune un fișier din mai multe surse și introduce, odată cu el, propriile erori.
Ce cuprinde
- Rapoarte pe perioadă, pe produs și pe analist
- Formate pentru raportările obligatorii
- Reconstituirea completă a unui dosar, la cerere
Decizii
Ce am ales și de ce
Alegerile care au schimbat proiectul: unde am mers pe varianta mai simplă, unde am insistat pe una mai scumpă și ce s-ar fi întâmplat altfel.
Jurnalul se scrie separat de datele de lucru
Cea mai simplă variantă ar fi fost un tabel de istoric alături de restul. Am separat jurnalul, cu drepturi diferite la nivel de bază de date: aplicația poate scrie în el, dar nu poate modifica sau șterge. Un jurnal pe care aplicația îl poate rescrie nu e o dovadă, e o listă.
Punctaj automat, decizie umană
Sistemul calculează un punctaj pe criteriile instituției și îl arată clar, cu ce l-a compus. Nu aprobă singur. A fost o alegere de proces, nu de tehnologie: într-un domeniu în care decizia trebuie asumată de o persoană, automatizarea deciziei mută responsabilitatea într-un loc unde nu poate sta.
Am construit scenariile de control înainte de funcționalități
Am început cu întrebările pe care le-ar pune un control — reconstituie dosarul acesta, arată cine a văzut documentul, demonstrează că analistul nu putea aproba. Le-am transformat în teste automate și abia apoi am construit. E invers față de ordinea obișnuită și e motivul pentru care nu a trebuit rescris nimic la final.
Cum arată munca acum
Fără procente și fără ore economisite — doar ce se vede deschizând aplicația.
Un dosar se poate reconstitui integral, cu toate accesările și deciziile lui, dintr-un singur loc. Regulile de etapă nu mai depind de atenția cuiva într-o zi aglomerată.
- Fiecare accesare și decizie are autor și moment, într-un jurnal separat.
- Un dosar nu poate avansa fără documentele cerute la etapa lui.
- Analistul nu poate aproba — nu e o regulă de procedură, e o restricție a sistemului.
- Raportările se generează din datele de lucru, fără pas manual intermediar.
Ce am învățat
Inclusiv ce am greșit
Într-un domeniu reglementat, cerințele de control nu sunt o etapă de la final. Dacă nu le pui la început, ele rescriu arhitectura la sfârșit, când e cel mai scump.
Un jurnal pe care aplicația îl poate modifica nu servește la nimic în momentul în care contează. Separarea drepturilor de scriere a fost decizia tehnică cea mai ieftină și cea mai valoroasă din proiect.
Întrebări frecvente
Ce ne întreabă lumea despre proiectul ăsta
Dacă întrebarea ta nu e aici, scrie-ne — răspundem la fel de direct.
Pune-ne o întrebareAplicația decide singură aprobarea?
Nu, și a fost o alegere deliberată. Calculează un punctaj pe criteriile instituției și arată din ce e compus, dar decizia rămâne a unei persoane, care și-o asumă și rămâne în jurnal cu numele ei.
Ce se întâmplă la un control?
Se poate reconstitui orice dosar: etapele parcurse, documentele la fiecare, cine le-a văzut, când, și pe ce bază s-a decis. Scenariile astea au fost scrise ca teste automate înainte de a construi funcționalitățile.
Se poate adapta pentru alt tip de produs financiar?
Etapele, documentele obligatorii și criteriile de punctaj se configurează pe tip de produs. Ce nu se schimbă e structura: flux pe etape, roluri separate tehnic și jurnal nemodificabil.
Ce am folosit din ce facem
Proiectul de mai sus a fost o singură dată. Paginile astea spun ce livrăm în general, pentru cine are sens și în cât timp.
Aplicații Symfony
Aplicații web construite pe Symfony, pentru procese pe care un CMS sau o soluție de raft nu le acoperă.
Detalii → 4-10 săptămâni ServiciuAudit de cod
O evaluare scrisă a aplicației tale: ce riscuri există, cât costă remedierea și de unde merită început.
Detalii → 1-3 săptămâni ServiciuInterfețe Angular
Interfețe pentru aplicații cu multe date, în care oamenii petrec ore întregi în fiecare zi.
Detalii → 4-10 săptămâniAlte proiecte
Vezi toate studiile →Concediile, scoase din Excel și din inbox
Evidența concediilor stătea într-un fișier ținut de o singură persoană, iar aprobările circulau pe mail. Funcționa, până când doi șefi aprobau în paralel aceeași zi.
Citește →Avizul de plată pe care proprietarul îl înțelege singur
Administratorul petrecea mai mult timp explicând calculul decât făcându-l. Aplicația nu a scurtat calculul — a făcut ca explicația să nu mai fie nevoie.
Citește →Bonul fotografiat pe loc, decontul închis fără teanc
Bonurile se strângeau în portofel și ajungeau la contabilitate o dată pe lună, îndoite și fără context. Jumătate din timpul de decontare se ducea pe reconstituit cine, unde și de ce a cheltuit.
Citește →Recunoști ceva din situația de mai sus?
Spune-ne cum lucrezi acum și unde se blochează. Prima discuție e despre tine, nu despre ce am făcut la altcineva.