Cei care nu au auzit de aplicatia MySmis 2014, trebuie sa afle ca este faimoasa aplicatie informatica (web-based) pe care Ministerul Fondurilor Europene se straduieste sa o realizeze (cu sprijinul STS) pentru uzul aplicantilor la fonduri europene, gestionarilor acestor fonduri si nu in ultimul rand controlorilor banilor europeni, fie ei din tara sau din partea Uniunii Europene.
MySmis 2014 trebuia sa fie gata din 2014
De finalizarea aplicatiei MySmis este conditionata de Comisie acreditarea noului sistem de gestionare, monitorizare si control al alocarii financiare aferente cadrului financiar 2014-2020 (una din conditionalitatile ex-ante). Scopul final urmarit de oficialii europeni (am dubii daca si de cei din Romania) este acela de a reduce povara administrativa plasata pe umerii beneficiarilor de fonduri europene.
O sa trecem peste promisiunile repetate (si neonorate) ca aceasta va fi gata la timp si ca va fi un progres „uimitor” fata de invechita aplicatie ironic denumita „action-web” (cei care au lucrat cu aceasta din urma stiu ca numai despre actiune nu putea fi vorba… atunci cand incercai sa introduci un document si trebuia sa astepti cu minutele pana obtineai un feed-back de la serverul pe care rula minunatia, iar raspunsul era nu de putine ori „eroare de incarcare”, ati depasit limita (de actiune) impusa!)
Aplicatia MySmis 2014 – 5 probleme identificate si solutiile lor
In cele ce urmeaza ne vom concentra pe 5 probleme identificate, insotite de o serie de solutii/sugestii ce ar putea fi luate in considerare de oficialii care se ocupa de subiect.
1. Auto-save date
In acest moment, este foarte frustrant sa observi ca date pe care tu le considerai salvate (pentru ca ai apasat butonul „confirma”), dispar ca prin minune in spatiul virtual.
De fapt in acest moment aplicatia iti cere sa confirmi de doua ori salvarea anumitor date, ceea ce este complet eronat si anacronic din punct de vedere al usabilitatii.
Cei care se ocupa de acest aspect ar trebui sa remarce ca optiunea de autosave (a se intelege niciun clic pentru salvarea automata a datelor) a fost introdusa de toate aplicatiile serioase (ex. toate produsele Google au optiune autosave, platforma wordpress a introdus optiune autosave). Acest fapt determina formarea unor obisnuinte ale utilizatorilor, ce nu ar trebui „contrazise”, nici chiar atunci cand ai la indemana mijloace coercitive de a obliga utilizatorii sa foloseasca singura aplicatie pe care ministerul o pune la dispozitia celor interesati.
O varianta minima de implementare a acestei functionalitati ar fi salvarea automata a datelor introduse atunci cand se navigheaza de la o pagina la alta prin aplicatie. Logica din spatele acestei cerinte este super simpla: atunci cand un utilizator introduce/scrie ceva in aplicatie este pentru ca doreste ca acele date sa se salveze acolo, iar atunci cand a gresit sau se razgandeste are intotdeauna posibilitatea de a edita/sterge datele introduse eronat.
2. Functia de constructie Buget – de refacut de la 0
Este imposibil sa descriem coerent cat de absurd este totul! Inainte de a continua intr-o maniera aberanta asa cum o fac acum specialistii care se ocupa de asta trebuie musai sa deschida o aplicatie matura de Project Management (gen Microsoft Project) si sa incerce sa inteleaga cat de cat logica de acolo!
In acest moment exista nu mai putin de 6 subsectiuni dedicate bugetului, iar cu aceasta cred ca am spus tot, pentru ca fiecare dintre ele este de fapt o sursa potentiala de necorelare/eroare:
- Buget – Activitati si cheltuieli,
- Buget – Camp de interventie
- Buget – Forma de finantare
- Buget – Tip teritoriu
- Buget – Mecanisme aplic. terit
- Buget – Tema secundara FSE
Fiecare linie introdusa in buget genereaza intre 4 si 6 linii suplimentare care sunt afisate utilizatorului in chip aiuritor, doar, doar se va lasa de aventura numita „bani europeni”!
Pe scurt:
Paradigma corecta credem ca este urmatoarea :
1. Exista o tabela cu Activitati si o tabela cu Resurse legate de o relatie de tip many-to-many
2. Atunci cand descrii activitatile identifici si asociezi resursele necesare si cantitatea lor (ex. pt A1.1 am nevoie de 1 Manager proiect 100 om/ore), 1 soft de project management etc.)
3. Toate aceste resurse identificate anterior se totalizeaza intr-o tabela dedicata resurselor unde se adauga informatii precum cele legate de cost si disponibilitate (ex. costul om/ora manager proiect=100 lei, categorie cost – cheltuieli salariale, disponibilitate 25% (adica 2 ore/zi) etc.)
4. Odata introduse aceste informatii de baza, reportarea diferitelor informatii agregate sau nu in rapoarte de tip pivot-table se face automat !
Si mai pe scurt:
Am spune ca paradigma si mai corecta ar trebui sa fie urmatoarea:
1. Care sunt rezultatele la care tu beneficiar de finantari europene te angajezi sa le livrezi ?
2. Eu, finantator, sunt dispus sa platesc x lei/unitate de rezultat
3. Bugetul proiectului = Cantitate rezultate X cost standard/rezultat
Restul sunt povesti aiuritoare din filmul „somnul ratiunii naste monstri” in care chipurile se cere inovatie si raspunsuri particularizate dupa specificul local, dar se listeaza din start tipurile de activitati eligibile precum si o mie de alte constrangeri.
3. Completarea informatiilor proiectului – concurs cu multe capcane
Poate cei care lucreaza la aplicatie nu-si (mai) dau seama, dar pentru o organizatie onesta care doreste sa aplice pentru a rezolva o problema reala cu ajutorul unei finantari europene (avem ca referinta scolile din mediul rural), realizarea unui proiect si introducerea lui in aplicatia informatica este o misiune aproape imposibila.
Un exemplu minor: pentru lista de achizitii se cere sa se introduca data la care se va efectua o anumita achizitie (lucru care intr-un soft performant se coreleaza automat in functie de calendarul activitatii care are nevoie de resursa respectiva), Tip procedura, Data publicare procedura, Data publicare rezultat evaluare, Data semnare contract.
Evident, probabil exista replica pregatita… pe care am mai auzit-o si in trecut : „fondurile europene nu sunt pentru toata lumea” ! Dar atunci ar trebui sa va hotarati, caci in momentul de fata, tot sistemul pare a functiona dupa vorba veche „drumul catre iad e pavat cu bune intentii”, iar proiecte cu sanse de castig vor avea sanse sa scrie tot „tocatorii de fonduri”.
4. Erori user-friendly
Nu de putine ori logica utilizatorului nu coincide cu logica celui care a conceput aplicatia. Asta nu este o noutate. Se mai intampla. Cele doua logici se confrunta, in mod mai mult sau mai putin belicos, si prin intermediul mesajelor de eroare. Ideal ar fi ca aceste erori ce sunt afisate utilizatorului sa nu fie doar un mijloc de a spune „nu se poate”, ci sa ne indice si ceea ce trebuie sa facem ca sa putem face ce intentionam si chiar sa ne furnizeze un link direct catre etapa/secventa omisa de pamanteanul-utilizator-lamda pentru a o putea remedia/completa.
5. Design
Stiu, stiu, tara arde si mie-mi pasa de design! Dar, in lumea normala (nu aceea a utilizatorilor prizonieri!), designul e foarte important. Nu trebuie sa fii mare specialist pentru a realiza ca nu exista niciun designer in echipa care se ocupa de aceasta aplicatie.
Campurile obligatorii nu se diferentiaza de cele non-obligatorii, decat in momentul in care apesi butonul save.
Campurile calculate automat nu se diferentiaza de cele unde trebuie introduse date si sunt amestecate unele peste altele;
Trebuie sa dai scroll, peste scroll, ca sa vezi nenorocitul de buton SAVE
Intr-un cuvant, haos!
Ar mai fi multe de zis despre granularitatea sistemului de ACL (acces control level), despre cat de greoi este insusi sistemul de inscriere, despre cat de obsedat este de securitate si cat de putin orientat spre „client”… despre cat de paguboasa este strategia de marketing prin care se „vinde” acest proiect, insistandu-se foarte mult pe functia antifrauda si mult prea putin pe functia de reducere a poverii administrative…
Sursa: Republica