Revista >> Martie 2009 [Nr. 113] >> Opinia Consultantului

“Tips and tricks“. Partea a II-a – Contractul

Catalin Hristea

23 Martie 2009

Ştiţi să scrieţi un Caiet de Sarcini?
Dar să pregătiţi un Contract pentru implementarea unui sistem informatic?

Vorbeam în cadrul primei părţi a acestui articol din numărul trecut al Market Watch de impactul pe care un Caiet de Sarcini bine făcut îl poate avea asupra implementării cu succes a unui proiect informatic şi am detaliat în acest sens câteva dintre aspectele deficitare ale Caietelor de Sarcini tipice: inflaţia de specificaţii de produs în dauna celor funcţionale, lipsa cerinţelor de calitate şi de performanţă, slaba detaliere a serviciilor de implementare solicitate, inclusiv a celor de project management. Fără a considera epuizat subiectul Caietului de Sarcini, voi trata în această a doua parte a articolului o altă componentă critică a unui proiect IT de succes: Contractul.

De ce am nevoie de un Contract detaliat? Caietul de Sarcini este foarte clar...

Se spune că, odată semnat, un Contract trebuie pus pe raft şi nu mai trebuie deschis vreodată, pentru că dacă este deschis înseamnă că proiectul are probleme majore... Într-o lume ideală, poate că lucrurile ar sta aşa. În lumea în care clienţii mei activează însă, întotdeauna vine momentul când nemulţumirea faţă de nivelul de calitate al produselor sau al serviciilor unui furnizor atinge pragul de suportabilitate şi, în acel moment, inevitabil se ajunge la... Contract. Este adevărat că un Contract este făcut ca să ne protejeze în situaţiile în care parteneriatele nu mai funcţionează, când promisiunile nu mai sunt onorate, iar un simplu ”gentleman’s agreement” nu mai este suficient. Dar, tocmai din acest motiv, dacă am ajuns într-o astfel de situaţie, atunci Contractul trebuie să fie suficient de complet şi de clar încât să ne ajute să rezolvăm problema, nu să ne încurce şi mai mult şi să agraveze problemele de implementare prin adăugarea unei dispute juridice asupra interpretării Contractului.

Ce formă de contract folosesc?

Chiar dacă nu deţineţi cunoştinţe juridice şi nici nu vă permiteţi serviciile unui consultant cu experienţă în redactarea contractelor, există şi alte surse de inspiraţie când vine vorba despre redactarea Contractului. În 9 cazuri din 10 însă, am constatat faptul că beneficiarii (mai ales cei din sectorul public) preiau ”mot-a-mot” formele de contract incluse cu titlu de exemplu în legislaţia de achiziţii publice şi, fără o minimă personalizare, le folosesc în cadrul documentaţiilor de atribuire. Este varianta cea mai uşoară de a ”scăpa” de problema Contractului, dar şi cea mai păguboasă, deoarece aceste forme standard de Contract nu conţin niciun fel de clauze specifice implementării unui sistem informatic.

O sursă alternativă de informaţii generale în vederea redactării unui Contract sunt formele de contracte de furnizare utilizate în proiectele cu finanţare de tip PHARE (disponibile pe Internet). O altă sursă de informare privind clauzele unui Contract tipic de implementare a unui sistem informatic pentru administraţia publică este Anexa la ”Ghidul Metodologic pentru Managementul Proiectelor TIC”, realizat de ANIAP şi disponibil pe site-ul asociaţiei (www.aniap.ro), în secţiunea ”Download”.

Care sunt cele mai importante clauze ale unui Contract?

Fără a avea pretenţia de a epuiza acest subiect în spaţiul limitat al acestei rubrici, voi trece în revistă câteva dintre cele mai importante clauze care trebuie să se regăsească într-un Contract pentru implementarea unui proiect IT:

1. Lista documentelor care compun Contractul, precum şi ordinea de precedenţă a acestor documente (ordinea în care aceste documente vor fi interpretate, în cazul unor contradicţii între ele). De exemplu: Acordul Contractual şi Anexele acestuia, Condiţii Speciale şi Generale, Clarificările la Caietul de Sarcini, Caietul de Sarcini, Oferta furnizorului, alte documente agreate de părţi pe durata derulării contractului.

2. Procedura de acceptanţă: tipurile de teste care se vor realiza, pentru fiecare tip de livrabil în parte (echipamente, licenţe, aplicaţii standard, aplicaţii dezvoltate, servicii de implementare, de instruire şi project management), în vederea acceptanţei acestor livrabile. Este foarte important ca toate serviciile să fie acceptate şi plătite numai pe baza finalizării unor etape clar definite şi după acceptarea unor livrabile (Raport Analiză şi Specificaţii Funcţionale, Raport Proiectare şi Specificaţii Tehnice, Strategie de Integrare, Scenarii de Testare, Plan de Instalare si Configurare, Raport de Instalare, Raport de Testare, Raport de Instruire). Tipurile de teste care se pot realiza includ: Teste de instalare (Calitative şi Cantitative), Teste Funcţionale, Teste de Performanţă, Teste de Recuperare în caz de Dezastru, Testare Pilot etc.

3. Modalitatea de plată pentru fiecare tip de livrabil în parte şi conform procedurii de acceptanţă. Valoarea Contractului trebuie să fie detaliată, astfel încât, în cazul în care este necesară aprobarea unei variaţii la Contract, aceasta să poată fi evaluată pe baza preţurilor unitare, atât pentru produse, cât şi pentru servicii.