Home » Media / Tech » Citesti:

De ce nu merge cardul de sănatate?

Mihai Badici martie 26, 2017 Media / Tech
26 comentarii 2,820 Vizualizari

Dacă tocmai aţi câştigat un contract pentru mentenanţa sistemului cardului de sănătate, nu aveţi noroc, habar n-am de ce nu merge acest sistem, va trebui să vă descurcați singuri. Ceea ce vreau să discut este în general situaţia proiectelor mari de acest tip, nu acest caz particular.

Desigur, ne-am obişnuit ca sistemele implementate de stat, fie că e guvern sau instituţii subordonate, să meargă în general prost sau foarte prost. Este, evident, în mare parte rezultatul corupţiei; banii sunt cheltuiţi fără prea mare responsabilitate şi în final nimănui nu îi pasă. Dar acesta este doar răspunsul simplu;  din păcate proiectele mari au tendinţa să eşueze şi în alte părţi, unde nu zic că nu există corupţie ( ba cum nu!) , dar măcar corupţii sunt  un pic mai responsabili.

În general, eventualitatea ca un proiect să reuşească este benefică pentru cei care l-au promovat. Chiar dacă o parte din bani s-au dus pe panseluţe sau pe maşini de lux absolut necesare proiectului, dacă finalul este fericit există o probabilitate mare ca nimeni să nu mai întrebe cum şi de ce; nu că nu ar fi motive, ci pur şi simplu pentru că atenţia publică va fi deturnată de cele care nu reuşesc; cum astea sunt majoritare, e prea mult de lucru ca să le urmăreşti pe toate. Deci am zice că, în afară de varianta „tunurilor”, în care cei implicaţi fug în insulele Belize ( sau pe unde s-o mai fugi în ziua de azi) a doua zi după încasarea facturii, toată lumea îşi doreşte ca proiectul să reuşească. Totuşi, de cele mai multe ori proiectele se transformă într-un fel de mort viu care este ţinut „pe perfuzii” până la următorul proiect, la fel de prost, care îl va înlocui.

Prima problemă, despre care am mai scris de-a lungul timpului, este analiza insuficientă. Dacă, să zicem, când implementezi un ERP într-o companie cam ştii la ce să te aştepţi, cu mici variaţii , şi la final oricum vei avea o grămadă de retuşuri de făcut şi un număr de utilizatori mai mult sau mai puţin nemulţumiţi, un proiect inedit cum este cel al cardului de sănătate, pe care o să îl folosesc drept exemplu în continuare, este extrem de greu de analizat corespunzător. Beneficiarul de fapt nu ştie exact ce vrea ( ceea ce e oarecum normal) iar furnizorul încearcă să transpună într-un limbaj funcţional bruma de informaţii. E o dilemă din care nu cred că se poate ieşi decât prin sistemul „trial and error”. Adică o implementezi cum ţi se pare ok, vezi ce iese şi modifici până obţii un rezultat corespunzător.

Numai că acest sistem nu prea corespunde cu ciclul de implementare al proiectelor de la noi, majoritatea implementate pe fonduri europene. Asta cam presupune ca la un moment dat să „închizi” proiectul, semnezi recepţia, plăteşti factura şi o dai mai departe spre decontare. E puțin loc pentru partea de customizare ulterioară, mai ales că furnizorul, dacă ştie cam câtă muncă înseamnă  nu prea e interesat de această fază şi va încerca să o „sară”. Dacă beneficiarul nu îşi dă seama, sau e „ajutat” să nu îşi dea, norocul furnizorului, sau, ca să citez din cineva: „ghinion”.

O altă problemă ar fi capacitatea tehnică. Chiar dacă firmele mai mari de IT de la noi şi de aiurea au destui programatori dintre care suficienţi sunt experimentaţi, o arhitectură de dimensiuni mai mari necesită o experienţă pe care foarte puţini o au. Din păcate, industria IT s-a diversificat puternic, domeniile s-au specializat foarte mult şi este greu să pui toate elementele laolaltă: soluţiile hardware, zona de reţea, disponibilitatea și diversele componente software.Să ne gândim doar că de la începerea până la finalizarea unui asemenea proiect, care se poate întinde pe câţiva ani, s-ar putea ca o tehnologie să fie complet înlocuită. Plastic vorbind, începi pe Windows 7 şi termini pe Windows10.

Problema capacităţii tehnice este cu atât mai dificilă cu cât s-ar putea ca nici măcar furnizorul să nu fie conştient de ea. Orice manager s-a obişnuit să îi dea o sarcină managerului de proiect iar acesta să se descurce. E mai degrabă o relaţie bazată pe încredere decât una bazată pe cunoaşterea competenţelor. S-ar putea ca managerul de proiect să fie grozav în alt domeniu decât cel de care ai nevoie; când construieşti proiecte unicat nu prea ai de unde să ştii.

Problema tehnologiei.  Furnizorul va folosi, evident, tehnologia pe care o are în prăvălie. Dacă are programatori de Java, va lucra în Java, dacă e distribuitor Oracle, va construi proiectul pe baza de date a acestora. Acesta este în general un lucru bun, nu are rost să pui ursul să sară într-un picior dacă el aleargă bine în patru; pe de altă parte tehnologia respectivă s-ar putea să nu fie cea mai potrivită scopului, din diverse motive, din care unele ar putea fi mai întâi financiare însă vor deveni în curând tehnologice, pentru că vor limita resursele disponibile. Câteva observaţii pentru exemplul nostru: în general giganţii bazelor de date preferă soluţiile centralizate, ceea ce conduce la achiziţionarea unor echipamente cu performanţe monstruoase; evident pentru soluţii de acest tip o arhitectură distribuită, chiar dacă e mai complexă din punct de vedere software, duce la fiabilitate mai bună şi la preturi acceptabile pentru hardware. Vorba unui profesor de-al meu, „după cum vedeţi, centralismul nu e bun NICI în tehnică”.

Problema monopolului. Un proiect original va construi un monopol artificial pentru întreţinerea ulterioară. Dacă beneficiarul a reuşit să facă în aşa fel încât să nu ceară codul sursă, practic nimeni altul decât furnizorul nu se va putea  încumeta la un contract de întreţinere ulterioară. Dar chiar şi dacă acel cod este disponibil, lucrurile sunt dificile pentru un eventual concurent, mai ales că documentaţia bine scrisă în IT e mai greu de găsit decât un politician bine intenţionat în Parlament.

Problema optimismului. Inginerii sunt optimişti prin definiţie. Dacă nu mă credeţi, mergeţi la Răzoare şi căutaţi plăcuţa cu „în trei ani aici va fi staţia ta de metrou”. Este pusă în 2009 cred. Dacă nu ar fi optimişti, nu s-ar mai apuca niciodată de vreun proiect. Din acest motiv, orice proiect durează mai mult decât este estimat; nu contează din vina cui. Într-o vreme, obişnuiam să înmulţesc cu doi orice estimare, dar asta nu m-a scutit totdeauna de surprize. Ca o consecinţă logică a acestui fapt, bugetul va fi aproape totdeauna depăşit, mai ales ca timp; software-ul va fi pus în funcţiune într-o fază incipientă şi bineînţeles va avea tot felul de probleme.

Problema adversarilor. Este utopic să crezi că un asemenea proiect va face pe toată lumea fericită. Evident unele persoane vor fi afectate de punerea în funcţiune a software-ului; cunosc cazuri în care angajaţi  au refuzat ani de zile să introducă datele în aplicaţie; atunci când n-au mai avut încotro am aflat şi de ce. Alţii îşi vor pierde slujba, aşa cum a fost cazul cu centralistele din satul meu natal atunci când s-a înlocuit centrala manuală. Când s-a pornit softul din exemplul nostru, îmi amintesc de un farmacist care a sărit pe fereastră; poate a fost o coincidenţă, nu ştiu. În tot cazul, e bine să ştii că orice proiect are adversarii lui.

Dar, cum spuneam, inginerii sunt optimişti prin definiţie şi încep mereu alte proiecte. Îmi vine să cred că şi Sisif tot pe la Politehnică a trecut….

Ai informatii despre tema de mai sus? Poti contribui la o mai buna intelegere a subiectului? Scrie articolul tau si trimite-l la editor[at]contributors.ro



Currently there are "26 comments" on this Article:

  1. Petre Opris Petre Opriş spune:

    Problemele apărute în România la sistemul informatic al cardul naţional de sănătate se repetă în Polonia, iar cauzele menţionate de domnul Badici în articolul său sunt identice la Varşovia.

  2. neamtu tiganu spune:

    Si pe aici proiectele mari sunt o catastrofa, cu citiva ani in urma a fost catastrofa “vignettei” pt. camioane, s-au depasit termenele cu anii si budgetul. Mai nou Philarmonia din Hamburg, a costat de zece ori mai mult si a intirziat de asemenea. Dar cea mai penibila istorie e BER, aeroportul din Berlin, a inceput in 2006, trebuia sa coste 1 miliard, pina acum s-au cheltuit 6 Miliarde si nu se stie cind va fi gata. Sau Airbus A 400, sau americanul F 35.

    Un exemplu pozitiv e insa tunelul Gotthard, care s-a terminat mai repede si a iesit mai ieftin decit prevazut.

    Pe de alta parte e un mit ca numai proiectele de stat merg uneori prost. Exista si nenumarate proiecte de firme sau concerne private care sunt macelarite, dar despre astea se vorbeste mai putin.

    Se spune ca pur si simplu mintea omeneasca nu ar fi in stare sa coordoneze chestii atit de complexe. Si cind te gindesti ca Dumnezeu a reusit sa faca o lume intreaga in numai 6 zile!

    • Mihai Badici Mihai Badici spune:

      Cred că tot la dumneavoastră în Germania e o catedrală care s-a terminat după vreo sută de ani, meşterul Manole a fost mult mai eficient la Curtea de Argeş :)
      Sigur că eşuează şi proiectele private, doar că alea ne privesc mai puţin dacă nu suntem implicaţi în ele. Am avut de-a face cu o cunoscută firmă de pantofi de sport care a migrat de la Scala la Navision si acum vor înapoi :) dar na, sunt banii lor, distracţia lor … insă în general firmele private îşi drămuiesc mai bine banii şi îsi iau măsuri si pentru “după”. In zona de stat, mai ales la noi, există si pericolul ca după ce vin “ceilalţi” să nu îti mai iei banii sau să se schimbe toţi funcţionarii din posturile cheie şi să nu mai ştie nimeni de unde a început proiectul…, dar cel mai rău e că nu e pe banii lor….
      Dumnezeu se pare că a reuşit pentru că a făcut totul singur, n-a avut nevoie de subcontractori sau furnizori :) Din păcate la noi e mai greu, că oricât am zice “să se facă lumină”… tot ai nevoie de un electrician pentru asta. Si oricum proiectul lui e si el departe de a fi perfect….

      • neamtu tiganu spune:

        Sagrada Famila a inceput in 1882 si cica va fi gata in 2026… oare cum va fi Catedrala Neamului?

        Cind faceam proiectare ne-am hotarit sa modularizam, dar in asa fel incit un modul sa nu depaseasca 400 de repere, cam atit e capabil sa tina-n mina un proiectant. Si a functionat f. bine … pina cind s-au combinat modulele, intotdeauna intre ele erau probleme, la asa numitele Schnittstelle…

        Cica-n ziua de azi e f. greu de coordonat proiecte mari si pt. ca legile au devenit extrem de stufoase, imi imaginez ca la problema cardului de sanatate trebuiesc niste legi de protectia pacientului… asa cum aeroportul din Berlin a uitat sa se uite la legile contra incendiu!

        • Mihai Badici Mihai Badici spune:

          Eu mă gândeam la domul din Koln, dar e bună si Barcelona :) La noi au fost “templele foamei” terminate în anii din urmă sub formă de Mall-uri, şi încă mai sunt din astea, ziduri părăsite şi neisprăvite… problema e că lucrurile nu depind numai de proiectare, mai depind si de finanţare, de politică, de ce se mai întâmplă prin lume ( mi-am adus aminte cum cumpăraseră rommânii o fabrică de lămpi când tocmai apăruseră tranzistorii…. )

        • mihai spune:

          Tare sunt curios cum naiba fac baietii aia care proiecteaza microprocesoarele din ziua de azi, cand creatiile lor au depasit miliardul de tranzistori! Pe schema dvs de modularizare la 400 de repere, mie imi ies trei niveluri de proiectanti, fiecare din ei cu cate 400 de subordonati…

          • Mihai Badici Mihai Badici spune:

            La microprocesoare mai merge si cu copy/paste, tranzistorii aia fac parte din blocuri identice, de exemplu regiştri de memorie, ca e unul, ca sunt 100 tot aia e, presupun că planul de asezare pe siliciu nu il fac cu tuş la planşetă. De aia presupun că e vorba de 400 de repere diferite, că doar n-or consta proiectele doar în 400 de cuie identice :)

  3. Fârtat Cicero spune:

    Înainte de a se apuca de scris, programatorii pot fi detaşaţi câte o lună în diferite puncte de lucru, ca să înţeleagă cerinţele sistemului; vor şti cu mult mai mare acurateţe la ce trebuie să răspundă aplicaţia. Apoi, dezvoltarea modulară poate rezolva multe probleme ulterioare. În al treilea rând, dezvoltatorul aplicaţiei trebuie să ceară şi să fie receptiv la feedback din partea utilizatorilor.

    • victor L spune:

      “programatorii pot fi detaşaţi câte o lună în diferite puncte”
      Ei bine, sinteti indulgent :P o luna doar.
      Legenda de acum citeva zeci de ani spunea ca absolventii de drept din Japonia aveau primul an de serviciu asigurat: un an la puscarie ca “sa vada ce si cum”.
      “Ce si cum” vor da pedepsele in urmatorii ani.

  4. Ghita Bizonu' spune:

    Din experenta mea personala (ceva tot in domneiul informaticii medicale)….
    aia care dintai se discuta habar nu au despre ce este vorba.
    Ala “manager” se sanatate habar nu are ce “se face” “mai jos” . Ei “stie” ce a vazut la televizor (Odisea spatiala , Terminator samd)
    Ala de la firma de informatica a cam legat la gard de ani de zile scrisu de cod. Ste ce vorbeste da nu prea stie unde se afla firma lui dpv al capcitatii (adica stii in gnl geografia cat sa ajungi la Braila .. da te afli la Urziceni si te crezi la Slobozia!!)

    In fine cand acordul partilor sa- realizat cineva dinsectiru medical este :condamnat: sa expllice analistului Partea proastra este ca nu stie ce “vrea” . Adica nu stie care este obiectul programului. Ca si le a vazut acelasi filme cu intigente artificiale … insa sa va spui un “mare secret” – nuel intocmeste raportarile! Si nicodata da niciodata nu esti pus sa discuti cu aia de la raportari. Ce naiba cum sa decida statiscinana in locul sefului de sectie? (Care este si aglomerat … si in gnl nu este dispus sa asculte parerile analistului)

    Sa nu uitam :pot aparea “frecusuri” intre manager (care a legat la gard de ani de zile .. asta daca a facut cumva un peorect de la cap la coada) atata de obisnuit ca managerului de proiect “să se descurce” si ii impune managerului de proiect o sarcina sa zicem “dubioasa” [adica poti face asa ceva insa rezulatele vor fi aleatorii ca forma de prezentare .. experenta proprie o saptamana poerduta]. Mai rau un ins cu exprienta in reralizarea proeictelor pot sa isidea seama rapid ca intra “in fundatura” si o zic. “Manager”ul face criza de personalitate …. gaseste alt manager de proiect care accepta (are mai putuina experenta) .. iese prost , se prelungesc termenele si ghici cine este de vina? Ala “batran” cu experenta !!!

    Cat despre cod sursa ….. un proect mare are multe linii . Si oricat de bume ar fi scisa documentatia … codul sursa depoinde intrisec de personalitatea celui care il scrie … Daca tu esti obisnuit sa mergi pe ramura de Then vei avea mici neplaceri depand codul unuia care mergea pe Else.. dar sunt si cestii si mai “grave” …. astfke incat ubnii ca considwere “imposibil” codul scris (f corect!) de altul . De exmplu unii considera “nebunie” sa “imbrici” vreo 7 If uri…. altii zic ca este “elegant”

  5. ioanadoe spune:

    Exista solutii pentru arhitectura cardului nu trebuie noi sa reinventam roata: ce fel de model clinic informatic, cum sa il faci “future-proof” ca sa nu mai conteze daca e pentru Windows 7 sau 10, si mai ales standardele, vocabularele, terminologiile: ICD-10 sau SNOMED. FHIR sau HLA7.

    • Mihai Badici Mihai Badici spune:

      Eu nu la “plastic” mă refer, plasticul merge. Problema e ca avem un intreg sistem, cu servere, cu baze de date, cu operatii decontate de casă şi operaţii nedecontate de casă ( urmăriti la medicul dvs de familie) cu calculatoare in fiecare cabinet…. Aici sunt problemele majore, nu la standardele de stocare sau la cititoarele de carduri.

      • neamtu tiganu spune:

        Ma-ntreb daca nu e mai simplu pur si simplu sa se cumpere un sistem existent. Asemenea sisteme exista in muilte tari din lume, nu vad de ce trebuie reinventata roata, o simpla traducere ar fi absolut suficienta.

        • Mihai Badici Mihai Badici spune:

          Nu m-am interesat in cazul asta specific, dar presupun că nu există prea multe implementări (sunt sub 200 de ţări parcă la ONU, si nu toate au sistem de sănătate centralizat) si probabil toate sunt “artizanale” .

          • David FK spune:

            Un exemplu de sistem centralizat de sanatate (health card) ar putea fi cel din Canada la nivel de provincie (de peste 10 milioane de locuitori) dar si la inter-provincial care functioneaza bine merci.

  6. Adrian B spune:

    Am avut ocazia sa vorbesc cu niste oameni care au lucrat in proiect si am avut si experienta impelementarii de asemenea proiecte. Da, probleme mentionate sunt reale … la un nivel superficial. Cauzele sunt mult mai simple: lipsa de expertiza la beneficiar si la castigatorul contractului.

    Beneficiarul nu are experienta de nici un fel ca sa scrie cerinte functionale. Ei au idee ce vor, dar nu stiu sa o formalizeze sau sa o valideze (cu utilizatorii, in primul rand). Pentru ca, fara nici o intentie de a jigni, in contractele in care beneficiarul e statul decidentul e un politruc incompetent si “informaticienii” sunt ratatii care nu si-au gasit ceva mai bun de facut pe o piata care plateste orice om decent de cateva ori mai bine decat statul. O un domeniu care necesita inalta calificare, in care un analist sau un arhitect software bun castiga mai mult decat un ministru. Pentru ca ei au competente formate in zeci de ani, nu la sedintele de partid.

    De partea furnizorului nu exista experienta. Da, exista experti, dar nu ii baga nimeni in proiecte cu statul, ca nu e nevoie: daca oricum specificatiile sunt dupa ureche si estimarile de cost umflate cu un ordin de marime, ca sa acopere orice nevoie care apare, e mai simplu sa iei echipe de incepatori platiti prost care sa scrie cod de proasta calitate decat sa iei experti care sa faca ceva eficient. De obicei asta pana se apropie termenul de predare si nu exista mai nimic, atunci cheama expertii care in 2 luni pun pe picioare ceva la care se lucra de 2-3 ani, dar in alea 2 luni fac si ei minimul posibil pentru ca proiectul pe bune ar fi necesitat 1 an cu experti.Tot ce conteaza e sa aibe suficiente functionalitati incat sa il accepte beneficiarul, cu promisiunea ca se rezolva pe parcurs problemele observate din start: de-aia e nevoie de contracte de mentenanta scumpe.

    In Romania si in multe tari exista experti in IT. Mai buni decat e nevoie pentru un asemenea sistem, dar sunt destul de rari si costa mult, pentru ca o asemenea expertiza se aduna in 10-15 ani de munca grea si invatat continuu, ceea ce omul de rand nu face. Si din mitul IT-ului romanesc o mare parte e efectul de halo al expertilor si a muncii lor, nu a marii mase de amatori cu ifose. In asemenea proiecte e nevoie de experti in procese, in interfete utilizator si uzabilitate, in arhitecturi de date, in baze de date (DB Administrators), in quality assurance, testing (test driven development suna cunoscut?), de front end developers, de specialisti in retele; ce companie in genul celor care castiga contracte cu statul au asemenea experti? Nici una, apeleaza la contractori cand le ajunge cutitul la os, dar pana se intampla asta pierd vremea cheltuind aiurea banii din contracte cu programatori “full stack” de 3000 de lei bucata.

  7. Stefan S spune:

    “programatorii pot fi detaşaţi câte o lună în diferite puncte”
    1. Depinde si metodilogia de implementare. In ultimele 2 proiecte am lucrat in echipe mixte. In acest fel implementatorul benefeciaza de cunostintele din interior iar, dupa finalizarea proiectului, beneficiarul are suportul tehnic necesar.
    2. Proiectul trebuie sa fie dorit cu ardoare de catre beneficiar, aduca sa nu fie doar un proiect pentru a arde niste bani europeni.

  8. victor L spune:

    Aceste disfunctionalitati, cam dese (unele inerente), nu cumva sint “gindite” si folositoare cuiva, undeva?
    Intreb, nu acuz.
    Intreb gindind la afirmatia lui @ Stefan S : “2. Proiectul trebuie sa fie dorit cu ardoare de catre beneficiar” nu doar pentru “a arde niste bani europeni”.

    • Mihai Badici Mihai Badici spune:

      Eu personal nu am informatii din cercurile respective; ca principiu am “bifat” şi faptul că orice proiect are si adversari. As putea bănui că, de exemplu în cazul nostru o parte din funcţionari au anumite interese într-o zonă politică, alţii în alta dar din moment ce s-a pus in functiune înseamnă că “s-a dorit”, există şi proiecte care nu s-au pus in funcţiune, sau s-au pus doar pe hârtie… “Cu ardoare” n-aş putea spune, cum ziceam, nu sunt banii lor, e mai bine să meargă decât să nu meargă, că nu mai punem atâtea întrebări, dar dacă nu merge n-o să devină depresiv nici un funcţionar, asta vă garantez :)

  9. dr. Fly spune:

    Poate un alt mecanism de plata ar motiva implementarea unor proiecte mai bune: abonamentul.

    Firma care implementeaza proiectul nu ia grosul banilor din implementarea in sine ci tocmai din intretinerea periodica si care presupune si modificari / actualizari. Asta inseamna ca in cazul in care le face corect va avea un cashflow predictibil pe urmatorii 10-20 ani fara prea multa munca.

    • Mihai Badici Mihai Badici spune:

      Da, dar de asta ziceam că in general proiectele noastre fiind pe fonduri europene trebuie să se cam incadreze intr-un exerciţiu bugetar. Iar noi oricum suntem mereu cu cel putin doi ani in urmă cu aceste exerciţii…

  10. ion spune:

    O sa mai dureze vreo 10-15 ani cred, pana o sa inceapa sa functioneze cat de cat bine aceste sisteme. Oricum nu vor fi finalizate niciodata, ele se vor perfectiona, evolua, modifica si renaste continuu. E utopie sa crezi ca un ciocan nu poate fi reinventat, sau ai cumparat un automobil si il vei lasa mostenire stranepotilor. Ei ar trebui sa contracteze sistemul ca serviciu nu ca produs.

  11. dana eugenia spune:

    bineee … da’ avem si noi o “stakeholders’ analysis”, cu strategii de “atac” pe fiecare categorie?

    metodologia PMI recomanda, in faza de initiere, sa se faca “analiza beneficiarilor”, clasarea in diverse categorii (pro, neutri, anti – proiect) si sa se schiteze niste “strategii” (stiu, e mult spus, da’ ofera imaginea completa) pentru mentinerea si/sau atragerea de “partea buna a fortei” …

  12. Adrian Munteanu spune:

    În cazul proiectelor/sistemelor cu care am avut ocazia să mă intersectez am constatat următoarele:

    - în „echipa proiectului„ au fost cerute cele mai firești dar și cele mai exotice certificări. Doar pentru a „securiza„ proiectul
    - caietele de sarcini/cerințele sînt scrise de parcă cineva de la beneficiar a mai lucrat la cel puțin încă „n„ proiecte de același tip.
    - specificațiile tehnice emanate de către benficiar sînt fix pe tehnologia X.
    - în cadrul proiectului, achiziția echipamentelor se face înainte de finalizarea etapei de analiză.
    - în nici un contract nu a existat o clauză de „software escrow„

    Exemplu: într-un proiect care însumează 520 de zile, etapa de analiză a fost de …49 de zile :) .

    Puține dintre proiectele IT publice au fost gîndite cu scopul de a rezolvă o problemă/problemele organizației.

  13. Smaranda spune:

    Am vazut un proiect de sanatate implementat. O companie de sanatate cu 4 milioane de clienti a inceput acest proiect acum 20 de ani. Responsabil pe proiect (beneficiar) a fost pe tot parcursul proiectului un singur om. In fiecare etapa proiectul trebuia sa fie functional altfel nu primeau o treime din bani. Bag-urile erau reparate pe banii proiectantului. Cerintele proiectului erau definite clar de la inceput si supuse licitatiei. Dupa primii cinci ani au simtit nevoia modernizarii si actualizarii programului. Acum programul este la un nivel foarte inalt (de vis) atit pentru medici, farmacisti si pacienti. Programul coordoneaza datele la un nivel de prelucrare automata pentru elaborarea de retete (in baza protocolului de tratament), mentinerea unui stoc de medicamente si consumabile in limite stabilite, pentru prescrierea si prelucrarea analizelor. Privind in urma, programul a pornit de la premize gresite care au marit costurile: au folosit sistemul de operare Windows care a evoluat, si a impus actualizari in masa pentru timpi scurti. In cazul caderi retelei sistemul de sanatate este blocat. Este drept ca au fost rare cazurile, dar trebuiesc luate in calcul .

  14. David spune:

    Din reacțiile la acest articol înțeleg doua aspecte;

    - softul nu este o autostrada așa ca la un control se spune așa – este pe aici pe undeva dar nu merge ca nu s-a plătit licența. Fiind bani grămadă interesul este sa nu meargă ca sa se semneze adiționale;
    - deși la toate marile aplicații IT din lume lucrează dezvoltatori romani, la noi aceiași romani au manageri corupți care nu-i lasă sa facă cum trebuie; Dovada este ca au fost puși sa posteze!

    Uite așa am ajuns de rasul lumii! Afara facem aplicații care merg iar in tara se scurg miliarde de euro pe aplicații care nu merg. Este de fapt realitatea cruda la cat de pricepuți sunt miniștrii politici. La tehnocrați se poate pe gratis iar la politicieni nu se poate cu căruțe de bani (la educație, sănătate, la BNR, la agricultura, la finanțe, etc). Dragnea poate fi mândru de miniștrii săi!



Comenteaza:







Do NOT fill this !

Autor

Mihai Badici


Mihai Badici

Absolvent al Facultății de Electronică si Telecomunicații București ( 1991) si doctorand al aceleiași facultăți. Administrator de sistem cu peste zece ani de experienț... Citeste mai departe


E randul tau

Felicitări colegului meu de generaţie şi de universitate de la Cluj pentru articol şi pentru ati...

de: Valentin Naumescu

la "Ştiinţa a fost aservită lumii politice"

Cauta articole

aprilie 2017
Lu Ma Mi Jo Vi Du
« Mar    
 12
3456789
10111213141516
17181920212223
24252627282930

Valentin Naumescu – Marile schimbari. Crize si perspective in politica internationala. Editie bibliofila

contributors.ro

Contributors.ro este intr-o permanenta cautare de autori care pot da valoare adaugata dezbaterii publice. Semnaturile noi sunt binevenite cata vreme respecta regulile de baza ale site-ului. Incurajam dezbaterea relaxata, bazata pe forta argumentelor.
Contact: editor[at]contributors.ro

MIHAI MACI – Cel de-al doilea volum din Colectia Contributors.ro

"Atunci când abdică de la menirea ei, școala nu e o simplă instituție inerțială, ci una deformatoare. Și nu deformează doar spatele copiilor, ci, în primul rând, sufletele lor. Elevul care învață că poate obține note mari cu referate de pe internet e adultul de mâine care va plagia fără remușcări, cel care-și copiază temele în pauză va alege întotdeauna scurtătura, iar cel care promovează cu intervenții va ști că la baza reușitei stă nu cunoașterea, ci cunoștințele. Luate indi­vidual, lucrurile acestea pot părea mărunte, însă cumulate, ele dau măsura deformării lumii în care trăim și aruncă o umbră grea asupra viitorului pe care ni-l dorim altfel." - Mihai Maci

(An essay by Vladimir Tismaneanu and Marius Stan)