Cei care nu au auzit de aplicatia MySmis 2014, trebuie să afle că este faimoasa aplicație informatică (web-based) pe care Ministerul Fondurilor Europene se străduiește să o realizeze (cu sprijinul STS) pentru uzul aplicanților la fonduri europene, gestionarilor acestor fonduri și nu în ultimul rând controlorilor banilor europeni, fie ei din țară sau din partea Uniunii Europene.
MySmis 2014 trebuia sa fie gata din 2014
De finalizarea aplicației MySmis ei este condiționată de Comisie acreditarea noului sistem de gestionare, monitorizare și control al alocării financiare aferente cadrului financiar 2014-2020 (una din condiționalitățile ex-ante). Scopul final urmărit de oficialii europeni (am dubii dacă și de cei din România) este acela de a reduce povara administrativă plasată pe umerii beneficiarilor de fonduri europene. O să trecem peste promisiunile repetate (și neonorate) că aceasta va fi gata la timp și că va fi un progres „uimitor” față de învechita aplicație ironic denumită „action-web” (cei care au lucrat cu aceasta din urmă știu că numai despre acțiune nu putea fi vorba… atunci când încercai să introduci un document și trebuia să aștepți cu minutele până obțineai un feed-back de la serverul pe care rula minunăția, iar răspunsul era nu de puține ori „eroare de încărcare”, ați depășit limita (de acțiune) impusă ! )
Aplicatia MySmis 2014 – 5 probleme identificate si solutiile lor
În cele ce urmează ne vom concentra pe 5 probleme identificate, însoțite de o serie de soluții/sugestii ce ar putea fi luate în considerare de oficialii ce se ocupă de subiect.
1. Auto-save date
În acest moment, este foarte frustrant să observi că date pe care tu le considerai salvate (pentru că ai apăsat butonul „confirmă”), dispar ca prin minune în spațiul virtual.
De fapt în acest moment aplicația îți cere să confirmi de două ori salvarea anumitor date, ceea ce este complet eronat și anacron din punct de vedere al usabilității.
Cei care se ocupă de acest aspect ar trebui să remarce că opțiunea de autosave (a se înțelege NICIUN CLIC pentru salvarea automată a datelor) a fost introdusă de toate aplicațiile serioase (ex. toate produsele Google au opțiune auto-save, platforma wordpress a introdus opțiune auto-save). Acest fapt determină formarea unor obișnuințe ale utilizatorilor, ce nu ar trebui „contrazise”, nici chiar atunci când ai la îndemână mijloace coercitive de a obliga utilizatorii să folosească singura aplicație pe care Ministerul o pune la dispoziția celor interesați. O variantă minimă de implementare a acestei funcționalități ar fi salvarea automată a datelor introduse atunci când se navighează de la o pagină la alta prin aplicație. Logica din spatele acestei cerințe este super simplă : atunci când un utilizator introduce/scrie ceva în aplicație este pentru că dorește ca acele date să se salveze acolo, iar atunci când a greșit sau se răzgândește ARE ÎNTODEAUNA POSIBILITATEA de a edita/șterge datele introduse eronat.
2. Funcția de construcție Buget – de refăcut de la 0
Este imposibil să descriem coerent cât de absurd este totul! Înainte de a continua într-o manieră aberantă așa cum o fac acum specialiștii care se ocupă de asta trebuie musai să deschidă o aplicație matură de Project Management (gen Microsoft Project) și să încerce să înțeleagă cât de cât logica de acolo!
În acest moment există nu mai puțin de 6 subsecțiuni dedicate bugetului, iar cu aceasta cred că am spus tot, pentru că fiecare dintre ele este de fapt o sursă potențială de necorelare/eroare:
- Buget – Activități și cheltuieli,
- Buget – Câmp de intervenție
- Buget – Formă de finanțare
- Buget – Tip teritoriu
- Buget – Mecanisme aplic. terit
- Buget – Temă secundară FSE
Fiecare linie introdusă în buget generează între 4 și 6 linii suplimentare care sunt afișate utilizatorului în chip aiuritor, doar, doar se va lăsa de aventura numită „bani europeni”!
Pe scurt:
Paradigma corectă credem că este următoarea :
1. Există o tabelă cu Activități și o tabelă cu Resurse legate de o relație de tip many-to-many
2. Atunci când descrii activitățile identifici și asociezi resursele necesare și 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 totalizează într-o tabelă dedicată resurselor unde se adaugă informații precum cele legate de cost și disponibilitate (ex. costul om/oră manager proiect=100 lei, categorie cost – cheltuieli salariale, disponibilitate 25% (adică 2 ore/zi) etc.)
4. Odată introduse aceste informații de bază, reportarea diferitelor informații agregate sau nu în rapoarte de tip pivot-table se face automat !
Și mai pe scurt:
Am spune că paradigma și mai corectă ar trebui să fie următoarea:
1. Care sunt rezultatele la care tu beneficiar de finanțări europene te angajezi să le livrezi ?
2. Eu, finanțator, sunt dispus să plătesc x lei/unitate de rezultat
3. Bugetul proiectului = Cantitate rezultate X cost standard/rezultat
Restul sunt povești aiuritoare din filmul „somnul rațiunii naște monștri” în care chipurile se cere inovație și răspunsuri particularizate după specificul local, dar se listează din start tipurile de activități eligibile precum și o mie de alte constrângeri.
3. Completarea informațiilor proiectului – concurs cu multe capcane
Poate cei care lucrează la aplicație nu-și (mai) dau seama, dar pentru o organizație onestă care dorește să aplice pentru a rezolva o problemă reală cu ajutorul unei finanțări europene (avem ca referință școlile din mediul rural), realizarea unui proiect și introducerea lui în aplicația informatică este o misiune aproape imposibilă.
Un exemplu minor: pentru lista de achiziții se cere să se introducă data la care se va efectua o anumită achiziție (lucru care într-un soft performant se corelează automat în funcție de calendarul activității care are nevoie de resursa respectivă), Tip procedură, Dată publicare procedură, Dată publicare rezultat evaluare, Dată semnare contract.
Evident, probabil există replica pregătită… pe care am mai auzit-o și în trecut : „fondurile europene nu sunt pentru toată lumea” ! Dar atunci ar trebui să vă hotărâți, căci în momentul de față, tot sistemul pare a funcționa după vorba veche „drumul către iad e pavat cu bune intenții”, iar proiecte cu șanse de câștig vor avea șanse să scrie tot „tocătorii de fonduri”.
4. Erori user-friendly
Nu de puține ori logica utilizatorului nu coincide cu logica celui care a conceput aplicația. Asta nu este o noutate. Se mai intâmplă. Cele două logici se confruntă, în mod mai mult sau mai puțin belicos, și prin intermediul mesajelor de eroare. Ideal ar fi ca aceste erori ce sunt afișate utilizatorului să nu fie doar un mijloc de a spune „nu se poate”, ci să ne indice și ceea ce trebuie să facem ca să putem face ce intenționăm și chiar să ne furnizeze un link direct către etapa/secvența omisă de pământeanul-utilizator-lamda pentru a o putea remedia/completa.
5. Design
Știu, știu, țara arde și mie-mi pasă de design! Dar, în lumea normală (nu aceea a utilizatorilor prizonieri!), designul e foarte important. Nu trebuie să fii mare specialist pentru a realiza că nu există niciun designer în echipa care se ocupă de această aplicație.
Câmpurile obligatorii nu se diferențiază de cele non-obligatorii, decât în momentul în care apeși butonul save.
Câmpurile calculate automat nu se diferențiază de cele unde trebuie introduse date si sunt amestecate unele peste altele;
Trebuie să dai scroll, peste scroll, ca să vezi nenorocitul de buton SAVE
Într-un cuvânt, haos!
Ar mai fi multe de zis despre granularitatea sistemului de ACL (acces control level), despre cât de greoi este însuși sistemul de înscriere, despre cât de obsedat este de securitate și cât de puțin orientat spre „client”… despre cât de păguboasă este strategia de marketing prin care se „vinde” acest proiect, insistându-se foarte mult pe funcția antifraudă și mult prea puțin pe funcția de reducere a poverii administrative…
Articolul a fost publicat și pe Republica.ro
