Sunteți pe pagina 1din 23

Managementul contractelor

1. Tipuri de contract
Resursele externe cerute pot fi sub formă de servicii. Un exemplu simplu ar fi
folosirea unei echipe temporare la contracte de durată mică, în vederea
îndeplinirii anumitor sarcini.
Pe de altă parte, contractul poate fi încheiat pentru livrarea unei aplicaţii
software complete.
Acesta poate fi:
• bespoke system (sistem comandat), i.e. un sistem care e creat de la zero,
special pentru un client;
• off-the-shelf (gata pentru cumpărare), pe care îl cumperi ca atare (“as is”) –
uneori se mai numeşte shrink-wrapped software;
• customized off-the-shelf (COTS) software – acesta este basic core system,
care e modificat pentru a îndeplini cerinţele unui anumit client.

Obs. Livrarea unui echipament, conform legii din Anglia, poate fi privită ca
un contract pentru livrarea de bunuri. Livrarea de software poate fi privită ca
oferirea unui serviciu (pentru scrierea software-ului) sau ca acordarea unei
licenţe pentru folosirea software-ului. Aceste disticţii au implicaţii legale.
O altă clasificare a contractelor este d.p.d.v. al modalităţii de plată către
furnizori:

• contracte cu preţ fixat;

• contracte de timp şi materiale;

• contracte cu preţ fixat per unitatea livrată.


Contracte cu preţ fixat

Preţul e fixat atunci când se semnează contractul. Clientul ştie că dacă nu


există schimbări în termenii contractului, preţul pe care-l va plăti este cel
consemnat în contract.

În acest caz trebuie ca analiza cerinţelor să fi avut deja loc. Odată începutî
dezvoltarea, clientul nu-şi poate schimba cerinţele fără să negocieze preţul
contractului.
Avantajele acestei metode sunt:
• Cheltuielile clientului cunoscute;
• Motivarea furnizorului;

Dezavantajele acestei metode sunt:


• Preţuri mai mari pentru a permite eventualele lucruri neprevăzute.
Furnizorul adaugă o marjă la calcularea preţului tocmai pentru a reduce
riscul apariţiei unor situaţii neprevăzute;
• Dificultăţi în modificarea cerinţelor;
• O presiune upward asupra costului schimărilor. În competiţi cu alţi
furnizori, furnizorul va încerca să ofere un preţ cât mai scăzut. Dacă, odată
contractul semnat, e nevoie de schimbări ale cerinţelor, furnizorul e în
poziţia forte de a cere un preţ mai mare pentru aceste schimbări;
• Ameninţare la calitatea sistemului. Nevoia de a menţine un preţ fixat
poate duce la deteriorarea calităţii sistemului.
Contracte de timp şi materiale
Clientul e taxat la o valoare fixă pentru unitatea de efort (de exemplu, oră
echipă). La începutul contractului, furnizorul oferă o estimare a costului,
bazată pe înţelegerea cerinţelor utilizatorului, dar aceasta nu e baza pentru
plata finală.

Avantajele acestei metode sunt:


• Uşurinţa în a schimba cerinţele;
• Lipsa presiunii preţului;

Dezavantajele acestei metode sunt:


• Handicapul clientului. Clientul e cel care se va înfrunta cu toate riscurile
asociate cu cerinţe vag definite sau care se schimbă;
• Lipsa motivaţiei pentru furnizor. Furnizorul nu are motivaţie să lucreze
într-o manieră care să încurajeze economia costurilor.
Contracte cu preţ fixat per unitatea livrată (preţ unitar fixat)
Acesta e asociat cu function point (FP) counting. Mărimea sistemului care
urmează să fie livrat e calculată sau estimată la începutul proiectului.
Mărimea sistemului trebuie să fie estimată în linii de cod, dar FPs pot fi
derivate cu uşurinţă de la documentaţia cerinţelor. E stabilit preţul per
unitate. Preţul final va fi preţul unitar înmulţit cu numărul de unităţi.

Exemplu. Tabelul de mai jos arată o astfel de estimare a preţurilor (tabel


preluat din Garmus, Herron, Measuring The Software Process, 1996)

Dacă sistemul conţine 2600 FPs, costul total va fi:


2000x967+500x1019+100x1058
Avantajele acestei metode sunt:
• Înţelegerea din partea clientului. Clientul poate vedea cum e calculat
preţul;
• Uşurinţa de a face comparaţii. Preţurile stabilite pot fi comparate;
• Emerging functionality. Furnizorul nu-şi asumă riscul funcţionalităţii în
creştere.
• Eficienţa furnizorului. Furnizorul are încă motivaţia să livreze sistemul la
funcţionalitatea cerută.
• Lyfe cycle range. Cerinţele nu trebuie specificate în forma finală la
început. Contractul poate acoperi atât etapa de analiza, cât şi etapa de
design.
Dezavantajele acestei metode sunt:
• Dificultăţi cu măsurarea dimensiunii software-ului. Numărul de linii de
cod poate fi mărit folosind un stil de codare “bombastic”. Folosirea regulilor
de numărare a FPs poate favoriza furnizorul sau clientul. Soluţia ar fi să fie
angajat un independent FP counter (numărător independent al FPs);
• Schimbarea cerinţelor. Anumite cerinţe pot afecta drastic tranzacţiile, dar
nu se adaugă la numărrea globală a FPs. O schimbare a cerinţelor făcută
târziu în ciclul de dezvoltare va necesita aproape sigur mai mult efort pentru
implementare decât dacă s-ar produce mai devreme.
O altă clasificare a contractelor (conform regulilor din Uniunea Europeană)
se face în legătură cu abordarea care e folosită pentru selectarea
contractorului:
• deschisă (open);
• restricţionată (restricted);
• negociată (negociated).

Open tendering process


În acest caz, orice furnizor poate face o ofertă pentru furnizarea de bunuri şi
servicii. Mai mult, toate ofertele care sunt în conformitate cu condiţiile
originale din invitation to tender trebuie să fie considerate şi evaluate în
acelaşi mod ca celelalte. La un proiect major, unde există o mulţime de
oferte şi procesul de evaluare e consumator de timp, acest mod poate fi
scump.
Restricted tendering process
În acest caz, sunt oferte doar de la furnizorii care au fost invitaţi de client.
Spre deosebire de open tendering process, clientul poate în orice moment
să reducă numărul furnizorilor potenţiali. Este în mod uzual cea mai bună
abordare. Există totuşi riscuri: acolo unde contractul rezultant e la un preţ
fixat, clientul îşi asumă responsabilitatea pentru corectitudinea şi
completarea cerinţelor specificate furnizorilor.

Negociated procedure
Sunt situaţii când procesul de ofertare restricţionată nu e cel mai potrivit.
În aceste cazuri, se poate justifica abordarea unui singur furnizor, caz în
care clientul poate fi acuzat de favoritisme.
2. Etape în definitivarea contractelor
Analiza cerinţelor
Înaninte de abordarea furnizorului, trebuie să fie specificate clar cerinţele.
Documentarea cerinţelor trebuie sp aibă, în mod tipic, secţiuni de forma
celor arătate în tabelul de mai jos (un asemenea document se numeşte
uneori operational requirement sau OR):
Cerinţele definesc cu grijă funcţiile care necesită să fie duse la bun sfârşit
de noua aplicaţie şi toate intrările(inputs) şi ieşirile(outputs) necesare pentru
aceste funcţii.
Cerinţele trebuie de asemenea să declare orice standard cu care trebuie să
fie conforme şi sistemele cu care noul sistem să fie compatibil.
Sunt necesare de asemenea cerinţe operaţionale şi de calitate (vezi
capitolul despre Calitatea produselor software).

Cerinţele obligatorii (mandatory) trebuie să fie îndeplinite. Dacă o propunere


nu îndeplineşte obligatorie, atunci propunerea va fi respinsă.
Dacă cerinţa e dezirabilă (desirable), dar nu obligatorie, atunci propunerea
poate fi acceptată din acest punct de vedere, dar trebuie ca alte aspecte ale
propunerii să compenseze acest neajuns.
Planul de evaluare (evaluation plan)
Odată specificată lista de cerinţe, trebuie schiţat planul despre cum va fi
evaluată propunerea. Pentru o aplicaţie off-the-shelf, sistemul însuşi va fi
evaluat.

Invitaţia la ofertă (invitation to tender)


După analiza cerinţelor şi producerea planului de evaluare, e posibilă etapa
de a invita posibilii furnizoti să facă o ofertă. În esenţă, această invitaţie
trebuie însoţită de o scrisoare, în care să se ofere diverse informaţii: cum va
fi tratată legal oferta, care este termenul limită pentru prezentarea ofertei
etc.
Abordările privind această etapă nu sunt unitare în diverse ţări, de aceea
recomandăm consultarea normelor legale pentru fiecare ţară.
Evaluarea propunerilor
Procesul de evaluare trebuie făcut metodic şi planificat şi ar putea include:
• examinarea atentă a documentelor propunerii;
• intervievarea reprezentanţilor furnizorilor;
• demonstraţii;
• examinări ale site-urilor;
• teste practice.
Documentele propunerii oferite de furnizori pot fi examinate pentru a vedea
dacă conţin toate elementele ce satisfac cerinţele originale. Se pot cere
anumite clarificări asupra unor puncte ale propunerii.
Orice declarare factuală făcută de furnizor presupune o angajare legală din
partea lui dacă influenţează cumpărătorul să ofere contractul acelui furnizor.
Cumpărătorul poate lua iniţiativa de a păstra note ale întâlnirilor şi de scrie
apoi furnizorului pentru a obţine confirmarea asupra acurateţii lor.
Furnizorul poate, în finalul documentului contractului, să încerce să excludă
orice angajare la orice reprezentaţii făcute în negocierile precontract.
Când produsul livrat se bazează pe un produs existent, e posibil să vadă o
demonstraţie. Un pericol cu demonstraţiile este acela că sunt controlate de
furnizor. De aceea, clientul ar trebui să facă o planificare a lucrurilor pe care
doreşte să le vadă în demonstraţie, asigurându-se astfel că toate
elementele importante sunt văzute.

Cu un software off-the-shelf, e posibil să avem acces concret la aplicaţie.


De exemplu, o versiune demonstrativă poate fi valabilă (de genul celor care
după 39 zile nu mai sunt valabile). E nevoie de un plan de test, care să ne
asigure ca sunt evaluate caracteristicile importante.

O problemă frecventă este aceea că în timp ce o aplicaţie existentă


lucrează bine pe o anumită platformă, nu lucrează mulţumitor pe platforma
clientului. În acest caz sunt mai utile examinările unor site-uri operaţionale
care folosesc sistemul.
3. Termenii tipici ai unui contract
E nevoie să schiţăm anumite arii majore asupra cărora trebuie să ne
concentrăm:
Definiţii
S-ar putea ca terminologia folosită în documentul contractului să fie definită,
de exemplu ce se înţelege prin “client” şi “furnizor”.

Forma înţelegerii
De exemplu, e contract de vânzare, de leasing sau licenţă? De asemenea,
poate subiectul unui contract, cum ar fi licenţa pentru utilizare unei aplicaţii
software, poate fi transferată unei terţe părţi?

Bunuri şi servicii furnizate


Echipament şi software. Include o listă concretă a pieselor individuale de
echipament care vor fi livrate.
Servicii. Acestea acoperă lucruri ca:
• instruire;
• documentare;
• instalare;
• conversia fişierelor existente;
• mentenanţă;
• măsuri de asigurare temporare.

Proprietarul software-ului
Două chestiuni apar: mai întâi, poate clientul să vândă software-ul la alţii şi
a doua dacă furnizorul poate vinde software-ul la alţii.
Când un software e scris special pentru un client, clientul va dori probabil
să-şi asigure exclusivitatea, de exemplu prin cumpărarea copyright-ului sau
prin specificarea în constract că foloseşte exclusiv software-ul.
Mediul (environment)
Când trebuie instalat echipamentul fizic, trebuie specificată linia de
demarcaţie dintre responsabilităţile furnizorului şi clientului cu privire la
lucruri cum ar fi furnizarea de energie.
Când software-ul e furnizat, trebuie confirmată compatibilitatea cu
hardware-ul existent şi sistemul de operare existent.
Angajamentele clientului
Clientul trebuie să asigure accomodation pentru furnizori şi probabil alte
facilităţi (internet, linie telefonică etc).

Proceduri de acceptare
Un sistem va fi acceptat numai după a trecut de testele de acceptare. O
parte a contractului va specifica detalii ca timpul pe care-l are clientul să
facă testele, deliverables de care depind testele de acceptare şi procedura
pentru semnare atunci când testarea e completată.

Standarde
Clientul poate cere furnizorului dovada că diverse standarde sunt
respectate.
Managementul proiectului şi al calităţii
Contractul trebuie să ceară ca standardele din seria ISO-9000 să fie
îndeplinite, ca şi ISO 12207 (de exemplu).

Planificarea
Oferă o planificare a timpului în care trebuie completate părţile cheie ale
proiectului. Această planificare va obliga atât clientul, cât şi furnizorul. De
exemplu, furnizorul poate si în stare să instaleze software-ul la o dată
convenită numai dacă clientul face platforma hardware disponibilă.

Preţul şi metoda de plată


În contract trebuie stabilit preţul şi modalitatea de plată.

Cerinţe legale diferite


În contract pot fi specificate ce condiţii se aplică la subcontractarea muncii,
obligaţia pentru daune către o terţă parte şi liquidated damages.
Liquidated damages sunt estimatori ai pierderilor financiare pe care clientul
le suferă dacă furnizorul a eşuat în obligaţiile pe care şi le-a asumat.
4. Managementul contractului

La anumite puncte de decizie, clientul are nevoie să examineze munca deja


făcută şi să ia decizii despre direcţia viitoare a proiectului.

Proiectul va necesita ca reprezentanţi ai clientului şi furnizorului să


interacţioneze în multe puncte ale ciclului de dezvoltare.

Această interacţiune, sau alţi factori externi, conduc(e) de obicei la


necesitatea unor schimbări.

Pentru fiecare punct de decizie, trebuie să fie definite deliverables ce


urmează să fie prezentate de furnizori şi toate output-urile.
Odată contractul încheiat, trebuie avută în vedere calitatea muncii.
Standardul ISO 12207 oferă printre altele posibilitatea existenţei unor
agenţi, angajaţi independent de client sau furnizor, care se vor duce la bun
sfârşit verificarea, validarea şi asigurarea calităţii.

Pe măsură ce sistemul se dezvoltă, apare uneori nevoia unor schimbări în


cerinţe, care pot duce la modificarea termenilor contractului. Va fi nevoie
deci de o procedură de control al schimbărilor, care să înregistreze cerinţele
pentru schimbări, împreună cu acordul furnizorului şi eventualele costuri
suplimentare necesare pentru munca în plus.

Clientul, pe de altă parte, trebuie să se asigure că în contract se specifică şi


felul cum sunt tratate situaţiile în care furnizorul nu respectă una sau mai
multe obligaţii legale.
5. Acceptarea

Când munca e terminată, clientul trebuie să înceapă activitatea legală


pentru realizarea testării de acceptare (acceptance testing). Contractul
poate stabili o dată limită pentru cât poate dura testarea, astfel încât clientul
să poată face testarea înainte de expirarea timpului, în vederea corectării
problemelor ridicate.
O parte a plăţii sau chiar toată plata va depinde de testul de acceptare.
Uneori o parte a plăţii finale va fi reţinută pentru perioada rulare operaţională
şi va fi plătită dacă nivelul de fiabilitate este conform specificaţiilor
contractate. Există de obicei o perioadă de garanţie, în timpul căreia
furnizorul poate pune la punct orice eroare apărută. Probabil că furnizorul
poate cere o perioadă de garanţie mai mică (30 zile, de exemplu), în timp ce
clientul ar încerca să ducă perioada de garanţie până spre 120 zile, de
exemplu (aceste valori sunt orientative, dar pot fi întâlnite adesea în
realitate).
Concluzii

Câteva dintre punctele cheie din acest capitol pot fi astfel


rezumate:
• contractarea cu succes necesită timp important;
• e mai uşor să se obţină concesii din partea furnizorului înainte
de semnarea contractului decât după;
• un contract va stabili obligaţii şi pentru client, şi pentru
furnizor;
• negocierea contractului va include înţelegerea asupra
managementului relaţiei dintre furnizor şi client în timpul
executării proiectului.

S-ar putea să vă placă și