ADMINISTRAREA CONTRACTELOR

OBIECTIVE

intelegerea avantajelor si dezavantajelor folosirii bunurilor si serviciilor aduse din afara organizatiei;

distingerea diferitelor tipuri de contracte;

urmarirea strategiilor de care ai nevoie sa negociezi un contract;

schitarea continutului unui contract de bunuri si servicii;

cunoasterea planului de evaluare a unei propuneri sau a unui produs;

administrarea unui contract de la inceput si pana la sfarsit.

INTRODUCERE

In cazul in care banii nu sunt o problema pentru o organizatie, iar timpul personalului este redus, cumpararea bunurilor si serviciilor este mult mai atractiva decat realizarea acestora de catre organizatie. Totusi, exista riscuri pentru organizatiile care adopta o astfel de politica. Multe dintre aceste posibile pericole provin din faptul ca o mare parte din timpul si atentia personalului vor fi necesare pentru administrarea cu succes a proiectului reziliat. Cu toate ca rezilierea contractului se poate face in scopul reducerii efortului managerial, este esential ca organizatia sa-si exprime clar cerintele chiar de la inceputul planificarii proiectului si, in acelasi timp, sa se asigure ca bunurile si serviciile care vor rezulta sunt exact cele cerute.

Acest capitol descrie in continuare diferite tipuri de contracte si pasii care trebuie urmati in plasarea unui contract. In concluzie, sunt descrise cateva lucruri care trebuie facute in timpul executarii contractului.

TIPURI DE CONTRACTE

Resursele externe cerute pot fi sub forma de servicii. Un exemplu simplu ar fi acela al folosirii unui personal temporar pentru contracte pe termen scurt, pentru a se ocupa de unele aspecte ale proiectului. O alta utilizare a serviciilor externe ar fi aceea ca furnizorul poate nu numai sa livreze noul sistem dar sa si-l utilizeze in numele clientului.

Pe de alta parte, contractul poate fi realizat pentru o aplicatie deja existenta.

Acesta poate fi:

- bespoke system - este un proiect creat de la zero pentru un client

- off-the-shelf - este un proiect pe care-l cumperi asa cum este

- customized off-the-shelf (COTS) - este un proiect de baza modificat pentru nevoile unui anumit client.

Atunci cand este furnizat si echipament, acest lucru poate fi privit ca un contract pentru furnizarea de bunuri. In cazul furnizarii de soft acest lucru poate fi privit ca un contract pentru furnizarea de servicii sau ca garantarea unei licente de folosire a softului care ramane proprietatea furnizorului.

O alta modalitate de clasificare a contractelor se poate face dupa modul in care se calculeaza plata furnizorilor:

• contracte cu pret fix
• contracte referitoare la timp si materiale
• contracte pe baza de pret fixat pe unitate in avans

Contracte cu pret fix

Dupa cum sugereaza si denumirea, in cazul acestui contract, pretul este fixat la semnarea contractului. Clientul trebuie sa stie ca, daca nu exista schimbari in termenii contractului, pretul fixat va ramane pretul care va trebui platit la terminarea proiectului. Pentru ca acest lucru sa se realizeze, cerintele clientului trebuie sa fie cunoscute si fixate de la inceput. Cu alte cuvinte, cand contractul presupune realizarea unui sistem software, trebuie sa existe de la inceput o analiza detaliata a cerintelor. Odata inceputa dezvoltarea proiectului, clientul nu va mai putea face modificari asupra cerintelor fara renegocierea pretului contractului.

Avantaje:

cheltuiala clientului este cunoscuta

furnizorul are interesul de a realiza sistemul intr-o maniera eficienta a costului

Dezavantaje:

eventualitatea permiterii unui pret mai mare. Furnizorul amortizeaza riscul pentru orice erori in estimarea initiala a marimii proiectului. Pentru a reduce impactul acestui risc, furnizorul va trebui sa stabileasca o limita cand va calcula pretul.

dificultati in modificarea cerintelor. Nevoia de a schimba scopul cerintelor devine uneori evidenta pe masura ce proiectul este dezvoltat.

presiunea cresterii costului aparute in urma schimbarilor. Cand concureaza impotriva unor potentiali furnizori, furnizorul va incerca sa propuna cel mai mic pret posibil. Daca, odata contractul semnat, apar alte cerinte din partea clientului, furnizorul are dreptul de a cere un pret mai mare pentru aceste schimbari.

pericol cu privire la calitatea proiectului. Nevoia de a respecta pretul fixat poate duce la o reducere a calitatii softului.

Contracte cu privire la timp si materiale

Cu acest tip de contract, clientului i se cere o taxa fixa pentru fiecare unitate (tip) de efort. De exemplu pe personal/ora. La inceputul proiectului, furnizorul, in mod normal prezinta un cost total estimativ bazat pe cerintele clientului, dar aceasta nu este baza pentru plata finala.

Avantaje:

usurinta schimbarii cerintelor

lipsa presiunii pretului (cand pretul nu e fixat) - poate permite o calitate mai buna a softului care va fi produs

Dezavantaje:

responsabilitatea clientului - clientul isi asuma toate riscurile asociate cerintelor schimbate sau prost definite.

lipsa stimulentelor pentru furnizori - furnizorul nu are nici un stimulent sa lucreze intr-o maniera eficienta

Pentru ca furnizorul pare ca primeste un cec in alb aceasta abordare in mod normal nu se bucura de aprecierea clientilor.

Contracte pe baza de pret fixat pe unitate in avans

Acesta este deseori asociat cu contabilizarea punctelor functionale. (FP)

Marimea sistemului care va fi livrat este calculata sau estimata la inceputul proiectului. Marimea sistemului ce va fi livrat poate fi estimata in mare prin linii de cod dar FP-urile (punctele functionale) pot fi derivate din documentele referitoare la cerinte. Este mentionat si un pret pe unitate. Pretul final este pretul unei unitati inmultita cu numarul unitatilor.

Avantaje:

Intelegerea clientului. Clientul poate vedea cum este calculat pretul si cum acesta va varia in urma modificarii cerintelor .

Comparabilitatea (comparatia). Schemele de preturi pot fi comparate

Eficienta furnizorului. Furnizorul va fi stimulat sa livreze functionalitatea produsului intr-o maniera eficienta (referitor la cost) spre deosebire de contractele referitoare la timp si materiale.

Categoria duratei de viata. Cererile nu trebuie specificate definitiv de la inceput. Astfel, contractul de dezvoltare poate acoperi atat etapa de analiza cat si cea de design a proiectului.

Dezavantaje:

Dificultati in masurarea marimii softului

Schimbarea cerintelor. Unele schimbari pot afecta drastic tranzactiile existente dar sa nu adauge nimic la numararea punctelor functionale. Trebuie luata o decizie pentru cum sa se actioneze in cazul acestor schimbari. O schimbare facuta tarziu, cu siguranta va necesita un efort mai mare decat una facuta mai devreme.

Pe langa metodele de plata mentionate, mai sunt si alte optiuni. De exemplu, implementarea unui lucru specificat deja, poate fi facuta la un pret fixat dinainte, pentru adaugirile si schimbarile ulterioare sa fie taxate pornind de la o baza FP. Un alt exemplu ar fi acela al antreprenorului (constructorului) care trebuie sa cumpere cantitati mari de echipament al carui pret poate varia si nu din vina antreprenorului. In acest caz este posibila negocierea unui contract unde pretul final contine o parte fixa pentru munca efectiva si o parte care depinde de costul componentelor folosite.

O problema cu softul se observa atunci cand sunt analizate obligatiile contractuale si de plata - si anume relativa sa invizibilitate si flexibilitate. Aceasta inseamna ca marimea sistemului si efortul de dezvoltare pot fi foarte greu de apreciat. Daca furnizorii cer, in mod realist, preturi fixe pentru munca lor, atunci sarcinile pe care trebuie sa le indeplineasca trebuie specificate cu grija. De exemplu, nu ar fi realist sa i se ceara unui furnizor sa dea un singur pret pentru toate etapele unui proiect: cum pot ei estima efortul necesar cand cerintele nu au fost inca stabilite? Din acest motiv, va fi deseori nevoie sa se negocieze o serie de contracte, fiecare acoperind o parte diferita a sistemului.

O alta modalitate de a clasifica contractele, cel putin la inceput, este in functie de modalitatea de selectare a furnizorului:

• Deschisa
• Restrictiva
• Negociata

Proces de ofertare deschis

In acest caz, orice furnizor poate licita pentru a furniza bunuri si servicii. Mai mult decat atat, toate ofertele care corespund conditiilor originale formulate la "invitatia de ofertare", trebuie analizate si evaluate in acelasi fel. Cand este vorba despre un proiect mare, unde sunt multe oferte si procesul de evaluare ia mult timp, acesta poate fi un mod foarte costisitor.

Proces de ofertare restrictiv

In acest caz, sunt oferte doar de la furnizori care au fost invitati de catre client. Spre deosebire de procesul de ofertare deschis, in acest caz, clientul poate reduce, in orice moment numarul de potentiali furnizori care vor fi analizati. Aceasta este de obicei cea mai buna abordare. Oricum, are si ea riscurile ei: atunci cand contractul este la un pret fixat in avans, clientul isi asuma responsabilitatea pentru corectitudinea cerintelor specificate pentru posibilii furnizori. Lipsuri in documentarea cerintelor, cateodata, face ca un furnizor acceptat sa ceara plati suplimentare.

Procedura negociata

Uneori, insa, sunt motive intemeiate pentru care un proces restrictiv de ofertare nu este cel mai potrivit in anumite situatii. Sa zicem, de exemplu, ca este un foc care distruge o parte a unui birou, inclusiv echipament IT. Grija principala in aceasta situatie este aceea de a inlocui echipamentul si de a-l face sa functioneze cat mai repede posibil si atunci nu este timp pentru un proces de ofertare de lunga durata. O alta situatie poate fi aceea cand un nou soft a fost facut si implementat de un outsider, dar clientul decide sa faca niste extensii ale sistemului. De vreme ce furnizorul original este personal familiarizat cu sistemul existent, ar fi inconvenabil sa abordeze alti potentiali furnizori printr-un proces de ofertare.

In acest caz, abordarea unui singur furnizor poate fi justificata. Oricum, este destul de clar ca abordarea unui singur furnizor poate face ca clientul sa fie acuzat de favoritism si poate fi facuta doar atunci cand exista o justificare clara.

ETAPE TIPICE IN ACORDAREA UNUI CONTRACT

Analiza cerintelor

Inainte de abordarea unui posibil furnizor, trebuie sa ai un set clar de cerinte. Trebuie accentuate doua puncte aici. Primul este acela ca acest pas poate fi sarit, cu usurinta, atunci cand utilizatorul are multe presiuni zilnice si nu foarte mult timp sa se gandeasca la dezvoltarea ulterioara. In aceasta situatie, poate fi util sa se aduca un consultant care sa intocmeasca un document cu cerinte. Chiar si asa, utilizatorii si managerii lor trebuie sa se uite cu atentie la documentul rezultat pentru a se asigura ca reflecta nevoile lor.

Sectiunile principale dintr-un document cu cerinte sunt:

1. Introducere
2. O descriere a sistemelor deja existente
3. Planurile sau strategiile viitoare ale clientului
4. Cerintele sistemului: - obligatorii (sunt absolut necesare pentru functionarea sistemului)

- preferate

5. Termene limita
6. Informatii suplimentare cerute de la potentialii furnizori

Cerintele definesc clar functiile pe care sa le indeplineasca noua aplicatie si tot input-ul si output-ul necesar pentru aceste functii. Cerintele trebuie de asemenea sa mentioneze standardele ce vor trebui sa fie respectate si sistemele existente cu care noul sistem trebuie sa fie compatibil. Pe langa aceste cerinte functionale, vor fi si cerinte operationale si referitoare la calitate, cum ar fi timpul de raspuns, soliditatea, folosinta si intretinerea noului sistem.

In general, acest document trebuie sa mentioneze "nevoile" cat mai exact posibil si trebuie sa evite specificarile de ordin tehnic. Potentialii furnizori trebuie sa identifice solutiile tehnice care cred ei ca corespund nevoilor specificate ale clientului. Pana la urma, ei sunt expertii tehnici care se presupune ca au acces la cea mai recenta informatie despre tehnologie.

Fiecare cerinta trebuie sa fie obligatorie, fie de preferat.

Obligatorie. Daca o propunere nu ia in calcul (nu respecta) aceasta cerinta, atunci propunerea va fi imediat respinsa. Nu va fi ceruta nici o evaluare.

De dorit (De preferat). O propunere poate sa nu respecte aceasta cerinta dar alte caracteristici ale ei pot sa compenseze.

Printre alte detalii care trebuie incluse in acest document care va fi prezentat potentialilor furnizori, ar fi si cerinte pentru orice informatie utila pentru a ne ajuta sa judecam pozitia organizatiei. Aceasta ar putea include raporturi financiare, referinte de la alti clienti si CV-urile personalului cheie.

Planul de evaluare

Dupa ce s-a trasat o lista de cerinte, trebuie facut un plan pentru a stabili cum vor fi evaluate propunerile. Situatia va fi putin diferita in cazul in care contractul este pentru un sistem care este special scris pentru un client spre deosebire de o aplicatie off-the-shelf. In cazul din urma, sistemul in sine este cel evaluat in vreme ce in prima situatie este evaluata propunerea pentru sistem.

In primul rand trebuie stabilita o modalitate de a verifica daca toate cerintele obligatorii sunt respectate. Urmatorul lucru care trebuie luat in considerare este cum pot fi evaluate cerintele optionale. Problema care pare aici este aceea de a cantarii valorile unei calitati spre deosebire de alta. Standardul ISO 9126 poate fi folosit pentru a decide daca un sistem este mai bun decat altul., dar daca apare o diferenta de pret intre cele doua, trebuie sa fim capabili sa judecam daca cresterea calitatii merita costuri in plus. Uneori banii sunt criteriul cheie. De exemplu, daca un sistem A are o anumita caracteristica si costa cu 1000 unitati monetare mai mult decat sistemul B care nu o are, atunci sistemul A are un avantaj. Daca insa sistemul A costa cu 5000 unitati monetare mai mult decat B, atunci lucrurile se schimba.

Trebuie accentuat faptul ca trebuie luat in considerare costul pentru intreaga durata a sistemului propus, nu doar costul pentru achizitionarea sistemului. De asemenea, acolo unde este mai mult decat probabil ca colaborarea dintre furnizor si client va fi de lunga durata, pe langa produse trebuie evaluata si organizatia furnizorului.

Invitatia de a oferta

Cererile si planul de evaluare fiind facute este acum posibila lansarea invitatiei la oferta a eventualilor furnizori. Este vorba despre o cerere insotita de o scrisoare de sustinere care poate contine informatii suplimentare despre cum vor fi depuse raspunsurile la invitatie. Va fi stabilit un termen si se spera ca pana atunci se vor primi propuneri cu pretul.

Pentru ca un contract sa existe trebuie sa fie o oferta de o parte care trebuie acceptata de cealalta parte. Invitatia la oferta nu este o oferta in sine ci o invitatie pentru eventualii furnizori de a face o oferta.

Acum apar anumite probleme noi. Cererile depuse pot fi satisfacute (rezolvate) in diverse feluri. Clientul trebuie sa stie nu numai pretul unui potential furnizor, dar si modul in care ei intentioneaza sa satisfaca cererile - acest lucru este important in special atunci cand contractul va cladi un sistem nou de la zero.

In unele cazuri, va fi de ajuns sa se aduca niste clarificari post-oferta si negocieri care vor rezolva problemele din propunerea furnizorului. Cand este vorba de proiecte noi complexe, va fi nevoie de o abordare mai elaborata. O modalitate de a elabora detaliile propunerilor furnizorilor este aceea de a avea un proces de atestare in doua etape.

In prima etapa, sunt cerute propuneri tehnice de la potentialii furnizori care nu trebuie neaparat sa dea preturi in acel moment. Unele dintre aceste propuneri pot fi respinse deoarece nu corespund cererilor. In ceea ce le priveste pe cele ramase, vor fi tinute discutii cu reprezentantii furnizorilor pentru a clarifica si valida propunerile tehnice. Furnizorilor li se poate cere sa demonstreze anumite aspecte ale propunerilor lor. Unde sunt gasite defecte, furnizorului i se poate da posibilitatea de a le remedia.

Rezultatul acestor discutii poate fi numit Memorandum de intelegere cu fiecare furnizor. Aceasta este o acceptare a clientului, a faptului ca solutia propusa de catre furnizor este in acord cu cererea clientului.

In a doua etapa, sunt acceptate toate ofertele furnizorilor care au semnat memorandum-ul de intelegere. Oferta se va referi si la termenii financiari ai eventualului contract.

Daca trebuie produs si design-ul, ca parte a propunerii facute de furnizor, ca raspuns la invitatia de a oferta, atunci ar aparea o dificultate: aceea ca furnizorul va trebui sa faca o munca considerabila de design, cu o posibilitate foarte mica de a fi platit pentru ea. O modalitate de a reduce aceasta problema este prin a alege un numar mic de posibili candidati carora li se va plati o taxa pentru design. Acestea pot fi apoi comparate si contractul final pentru constructie va fi acordat celei mai atractive propuneri.

Evaluarea propunerilor

Aceasta trebuie facuta intr-o maniera metodica si planificata. Am mentionat deja necesitatea de a produce un plan de evaluare care va preciza cum fiecare propunere va fi verificata pentru a vedea daca aceasta corespunde cererii. Aceasta reduce riscul ca cererile sa nu fie trecute cu vederea si asigura faptul ca toate propunerile sunt analizate cu grija. Astfel, exista riscul ca o propunere sa fie pe nedrept favorizata din acuza prezentei unui amanunt care a fost cerut in cererea originala.

Procesul de evaluare poate include:

analiza propunerilor (si documentelor)

intervievarea reprezentantilor furnizorilor;

demonstratii;

vizitarea de site-uri;

teste practice.

Documentele legate de propuneri puse la dispozitie de furnizori pot fi analizate pentru a vedea daca acestea contin caracteristicile cerute de cererile originale. Poate fi nevoie de o clarificare a anumitor puncte. Orice declaratie facuta de furnizor implica un angajament legal din partea lor, daca il influenteaza pe client sa ofere contractul acelui furnizor. De aceea este important sa obtii o inregistrare scrisa a acestor inregistrari. Clientul poate lua initiativa, inregistrand intalnirile si scriind apoi furnizorilor pentru ca acestia sa continue corectitudinea notitelor (inregistrarilor). Un furnizor, in contractul final, poate incerca sa excluda orice angajament luat in negocierile pre-contractuale - de aceea, termenii contractului trebuie analizati.

Acolo unde produsul livrat se va baza pe un produs existent, poate fi vazuta o demonstratie. Pericolul cu demonstratiile este acela ca pot fi controlate de furnizori si ca si observator pasiv este uneori dificil sa ramai atent pentru mai mult de, jumatate de ora. Din aceasta cauza, clientul ar trebui sa realizeze o schema a ceea ce trebuie demonstrat, asigurandu-se astfel ca toate caracteristicile importante sunt vazute in lucru.

In software-ul off-the-shelf, ar trebui sa fie posibil accesul la aplicatie. De exemplu, o versiune de demonstratie care se inchide singura dupa 30 zile, poate fi disponibila. Inca o data un plan de testare este necesar pentru a fi siguri ca toate caracteristice importante sunt evaluate intr-o maniera complexa si consistenta. Odata ce un anumit pachet pare a fi candidatul cel mai probabil, acesta trebuie investigat cu grija pentru a vedea daca nu exista factori neprevazuti care ar putea invalida aceasta alegere.

In cele din urma va fi luata o decizie de a da contractul unuia dintre furnizori. Unul dintre motivele centrale pentru a folosi o abordare structurala si pe cat posibil obiectiva, pentru evaluare este acela de a demonstra ca decizia a fost luata impartial si pe merit. In organizatiile mari, acordarea unui contract presupune participarea unei a doua parti din cadrul organizatiei, cum ar fi un departament de contracte, care poate verifica daca s-au urmat procedurile corecte. De asemenea formatul final, legal a unui contract va cere aproape sigur expertiza legala.

Oricum, candidatul ales va trebui anuntat ca de altfel si candidatii care nu au fost alesi. Aceasta nu este doar o chestiune de bun simt. Exista o obligatie de a face aceasta in anumite situatii.

TERMENI TIPICI AI UNUI CONTRACT

Nu este posibila descrierea intregului continut al contractelor pentru servicii si bunuri IT. Este posibil, totusi, sa scoatem in evidenta unele dintre zonele majore de interes.

Definitii - Terminologia folosita in contracte trebuie definita, de exemplu la cine se refera cuvintele "client" si "furnizor".

Forma intelegerii - De exemplu, trebuie specificat daca este un contract de vanzare, de leasing sau de licenta.

Bunuri si servicii oferite - Echipamentul si software-ul oferite. Aceasta include o lista cu piesele de echipament ce vor fi trimise.

Servicii oferite - Acestea acopera lucruri ca:

trening (instruire)

documentatie

instalare

transformarea fisierelor existente

intretinerea

aranjamente de asigurare

Proprietatea software-ului

Cine detine dreptul de proprietate al softului? Sunt doua probleme cheie aici: daca clientul poate vinde softul si in al doilea rand daca furnizorul poate vinde softul. In ceea ce priveste softul off-the-shelf, furnizorul ofera o licenta de a folosi softul. Atunci cand softul este scris special pentru un client, atunci acel client va dori exclusivitatea utilizarii acestuia. - el ar putea obiecta cu privire la utilizarea softului concurentei, deoarece spera ca ii va da un avantaj in fata concurentei. Ei pot face acest lucru achizitionand drepturile de copyright sau specificand in contract ca vor drept exclusiv de utilizare.

Atunci cand softul este scris de catre un angajat ca parte a contactului de angajare, este evident ca dreptul de copyright apartine angajatorului. Atunci cand organizatia clientului a angajat un furnizor din exterior sa scrie softul, trebuie specificat in contract cine are dreptul de copyright - daca nu, in acest caz, in mod automat se presupune ca apartine clientului. Clientul s-ar putea sa fi decis sa preia responsabilitatea de intretinere si dezvoltare ulterioara odata de softul este livrat ti in acest caz el va avea acces la codul sursei. In alte cazuri, atunci cand clientul nu are posibilitatea proprie de intretinere, furnizorul poate retine codul sursei si clientul va trebui sa-l solicite pentru schimbarile ulterioare. Exista potentiale pericole in acest caz, nu in ultimul rand faptul ca furnizorul poate iesi din afaceri. In contract poate fi inclusa o intelegere care prevede ca o a treia parte sa detina copii actualizate ale codului sursei.

Mediu ambiant

Atunci cand echipamentul trebuie instalat, trebuie specificate responsabilitatile furnizorului si ale clientului cu privire la instalarea si alimentarea electrica. Atunci cand softul este furnizat, va trebui confirmata compatibilitatea dintre softul si hardul existent si platformele sistemului de operare.

Angajamentele clientului

Chiar si atunci cand este vorba de un angajat din exterior, proiectul de dezvoltare tot are nevoie de participarea clientului. Clientul va trebui sa asigure cazare pentru furnizori si poate alte facilitati cum ar fi de exemplu linii telefonice.

Proceduri de acceptare

Este bine sa se accepte un contract doar dupa ce a trecut de testul de acceptare al clientilor. Aceasta parte a contractului va specifica detalii precum timpul pe care clientul il are la dispozitie pentru a realiza testele, lucrurile de care depind acceptarea si procedura de a preciza ca testul este incheiat.

Standarde

Aceasta se refera la standardele pe care trebuie sa le respecte bunurile si serviciile. De exemplu, un client poate cere furnizorului sa se conformeze standardului ISO 12207, cu privire la ciclu de viata al softului si documentatiei.

Proiectul si calitatea managementului

Trebuie stabilite aranjamente pentru managementul proiectului. Printre acestea ar fi frecventa si natura intalnirilor si informatia ce trebuie furnizata clientului.

Orar

Aceasta ofera un program al realizarii partilor cheie ale proiectului. Acest program il va implica si pe furnizor si pe client. De exemplu, furnizorul poate fi capabil sa instaleze softul la data stabilita doar daca clientul face disponibila platforma hardware pana la acel moment.

Pret si metoda de plata

Evident pretul este foarte important. De asemenea trebuie stabilit cand trebuie facuta plata. Trebuie sa existe un echilibru intre dorinta furnizorului de a primi banii si pretentia clientului de a fi sigur ca bunurile si serviciile sunt satisfacatoare inainte de a da banii.

Cereri legale diverse

Contractele au deseori clauze care se refera la probleme de genul: jurisdictie legala valabila pentru contract, ce conditii se vor aplica la sub-contractarea muncii, garantia unei a treia parti precum si la pierderile lichide. Pierderile lichide sunt estimari ale pierderilor financiare pe care clientul le-ar suferi daca furnizorul nu si-ar indeplini obligatiile. Penalizarile din clauzele de penalizare trebuie sa reflecte pierderile reale pe care clientul le-ar suferi si nu pot fi nerealiste. Chiar si aceasta limitare nu este de-ajuns in unele cazuri in ceea ce-l priveste pe furnizor. De vreme ce calculatoarele isi asuma roluri cat mai importante, din ce in ce mai mari in multe organizatii si in sistemele de siguranta pot fi chiar o amenintare a vietii in caz de nefunctionare, paguba posibila poate fi foarte mare.

Daca este o disputa, care duce la litigiu, este scumpa si pierdere de timp. O alternativa este sa fie o intelegere ca disputele sa fie rezolvate prin arbitrare. Aceasta presupune ca disputa sa fie intermediata de o a treia parte a carei decizie sa fie hotaratoare. Desi ca procedeu, este rapid si ieftin, exista si o alta optiune: rezolvarea alternativa a disputei unde o a treia parte are rolul de mediator care are doar capacitatea de a da sfaturi si poate incerca sa se ajunga la o intelegere intre cele doua parti.

MANAGEMENTUL CONTRACTULUI

Trebuie analizata comunicarea dintre furnizor si client in vreme ce proiectul se deruleaza. Ar fi probabil cel mai bine pentru cei implicati, daca furnizorul este lasat sa lucreze netulburat. Oricum, la anumite puncte-cheie (de decizie), clientul trebuie sa examineze ceea ce s-a facut deja si sa ia decizii cu privire la proiect. Proiectul cere ca reprezentantii furnizorului si clientului sa interactioneze in timpul ciclului de dezvoltare - de exemplu, utilizatorii trebuie sa ofere informatiile necesare pentru realizarea unui design detaliat de interfata. Aceasta interactiune, sau alti factori externi, adesea duc la necesitatea unor schimbari care fac sa vaneze termenii contractului, asa ca este nevoie de o procedura de contract a schimbarilor. Fiecare dintre aceste subiecte vor fi analizate in detaliu.

Cand se negociaza contractul, pot fi identificate puncte cheie care au nevoie de aprobarea clientului inainte de a se initia proiectul. De exemplu, un proiect care vizeaza dezvoltarea unui sistem mare, poate fi divizat. Pentru fiecare segment poate fi o faza de design de interfata, si clientul trebuie sa aprobe design-ul inainte de lucru. De asemenea poate fi nevoie de decizie intre segmente.

Pentru fiecare punct de decizie, trebuie definite livrarile furnizorilor, deciziile ce trebuie luate de client si urmarile deciziilor. Aceste punte de decizie o importanta si mai mare daca platile catre furnizor se bazeaza pe ele. Nu numai furnizorul dar si clientul au responsabilitati in ceea ce priveste aceste puncte de decizie.

Atunci cand proiectul este facut de cineva din afara, va exista o preocupare pentru calitatea lucrarii. Standardul ISO 12207 prevede posibilitatea existentei de agenti angajati independent de furnizor sau de client care vor face verificarea, validarea si siguranta calitatii. Permite de asemenea revizuirea impreuna a proceselor si produselor proiectului a carei natura trebuie sa se stabileasca atunci cand contractul este negociat.

Pe masura ce sistemul este dezvoltat, deseori apare necesitatea schimbarii unor cerinte. Aceasta inseamna varierea termenilor contractului. Dovada orala nu este in mod normal admisa pentru a contrazice, de aceea schimbarile trebuie documentate corespunzator. O procedura eficienta de control al schimbarilor este necesara pentru a inregistra cererile pentru schimbare impreuna cu acordul furnizorului si taxele pentru munca suplimentara.

Se poate intampla ca furnizorul sa nu-si indeplineasca una sau mai multe din obligatiile legale. Aceasta se poate sa nu fie din vina lor, daca de exemplu, clientul a cauzat intarzierea prin amanarea aprobarii produselor intermediare. Daca nu se iau masuri atunci cand se intampla greseala, clientul poate fi considerat raspunzator pentru esec si aceasta poate duce la pierderea dreptului pentru redresare legala. Clientul trebuie, prin urmare, sa-si protejeze drepturile legale, anuntandu-l pe furnizor, cat se poate de repede, ca un esec a fost inregistrat. Se reaminteste ca, orice pretentie de pagube lichide trebuie sa se bazeze pe pierderi efective. Din punctul in care apare eroarea, clientul trebuie sa inregistreze toate pierderile efective aparute ca urmare a greselii si orice pierderi colaterale.

ACCEPTAREA

Cand lucrul a fost incheiat, clientul trebuie sa faca teste de acceptare. Contractul poate stabili o limita de timp pentru cat pot dura testele de acceptare, asa incat clientul trebuie sa fie organizat pentru a efectua testele inainte de data limita.

O alta problema este ca odata ce munca esentiala este incheiata, furnizorul vrea sa foloseasca echipa productiva la alte proiecte. Clientul poate descoperi ca toate problemele sale sunt rezolvate de membrii cu mai putina experienta din echipa furnizorului care poate nu sunt familiarizati cu toate aspectele sistemului livrat.

O parte sau chiar toata plata catre furnizor depinde de aceste teste de acceptare. Uneori o parte din plata finala va fi retinuta pentru o perioada si va fi platita daca se respecta termenii contractului. De obicei este o perioada de garantie in timpul careia furnizorul poate repara erorile fara nici o taxa. Furnizorul poate sugera o perioada de garantie foarte mica, de 30 zile de exemplu. Este in interesul clientului sa negocieze o perioada mai mare de garantie, de exemplu de 120 zile.

REZUMAT

Unele puncte cheie din acest capitol au fost :

contractarea unui proiect presupune un management al timpului

este mai usor sa castigi concesii de la un furnizor inainte de semnarea contractului decat dupa

propunerile alternative trebuie evaluate comparand costurile pe toata durata sistemului cu costurile de achizitie

contractul va stabili obligatii si pentru client si pentru furnizor

negocierea contractului trebuie sa includa un acord intre managementul relatiei client-furnizor pe parcursul executiei proiectului.