Puncte cheie în negocierea unui contract pentru achiziţionarea unei soluţii ERP

Puncte cheie în negocierea unui contract pentru achiziţionarea unei soluţii ERP

Este cunoscut faptul că atunci când se doreşte semnarea contractului pentru achiziţia unei soluţii ERP (sau, dacă extindem un pic contextul, în aproape orice situaţie care implică achiziţia de produse şi/sau servicii), furnizorul este cel care stabileşte cadrul contractual.

Text de Mihai Ionescu, Senior Sales Consultant XAPT Solutions

Chiar dacă acest lucru nu este întotdeauna pe placul beneficiarului, în marea majoritate a cazurilor el nu poate fi schimbat ci doar adaptat, într-o oarecare măsură. Din acest motiv, clientul trebuie să se asigure cât mai bine că pe lângă un partener de încredere are la dispoziţie şi un cadru formal – contractul – care să îi protejeze investiţia de eventuale „derapaje”.

În cele ce urmează, va supun atenţiei o serie de factori pe care dacă îi veţi avea în vedere când negociaţi un contract de achiziţie pentru o soluţie ERP, v-ar putea fi de ajutor.

Delimitarea scopului proiectului: arii de acoperire şi funcţionalităţi care se vor implementa, dar şi activităţi care nu vor face obiectul contractului

Pentru a evita eventuale „neînţelegeri” care apar în timpul derulării proiectului cu privire la tipul sau numărul de funcţionalităţi care vor fi implementate sau la alte servicii conexe (necesare funcţionarii soluţiei, dar care nu cad implicit în sarcina implementatorului, cum ar fi: instalarea infrastructurii IT, politici de back-up, etc), trebuie că scopul proiectului să fie clar delimitat prin contract. Exprimările generice pot lasă foarte uşor loc de interpretări şi nu puţine sunt cazurile în care, în timpul execuţiei proiectului, clientul “descoperă” că bugetul a fost deja consumat (cu mult) înainte de finalizare şi că trebuie suplimentat, aparent “nejustificat”. 

În acest sens este de dorit că ariile funcţionale (ex: Financiar, Vânzări, Achiziţii, Stocuri) care vor face obiectul contractului să fie bine delimitate şi detaliate la  nivel de funcţionalităţi specifice fiecăreia dintre ele. De asemenea, este bine că în contract să fie indicate şi acele servicii şi/sau funcţionalităţi care nu vor fi parte a proiectului (ex: gestiunea activităţilor din depozit, instalarea sistemului de operare pe server-ul de aplicaţie, etc).

Nominalizarea activităţilor de proiect la nivel de faze de execuţie şi roluri

Evitaţi contractele în care nu sunt specificate fazele (activităţile principale) şi sub-fazele execuţiei proiectului, împreună cu timpul de implementare (numărul de zile-om necesar) aferent fiecăreia dintre ele. În cazul unor exprimări generale sau ambigue există riscul major ca efortul de implementare ofertat să fie sub-dimensionat în comparaţie cu cel necesar, ceea ce poate conduce la derapaje ale bugetului contractat.

În plus, aceste informaţii sunt esenţiale pentru planificarea activităţilor de proiect, constituind baza de pornire în definirea calendarului de implementare şi nominalizarea livrabilelor proiectului.

Anticipând următorul factor important în analiza unui contract, în baza lor se face şi o mapare la nivel de roluri pentru fiecare membru al echipei de proiect, lucru necesar în definirea responsabilităţilor.

De aceea, recomandarea este ca în cazul în care contractul nu include deja aceste detalii să îi solicitaţi în mod expres furnizorului să le adauge.

Descrierea clară a rolurilor şi responsabilităţilor fiecărui membru al echipei de proiect (implementator şi client)

Se confirmă că succesul unei implementări ERP depinde în egală măsură atât de nivelul de experienţă şi gradul de implicare al implementatorului cât şi de participarea activă a clientului la activităţile din cadrul proiectului. Din acest motiv este necesar ca încă de la momentul semnării contractului (sau chiar din etapă de ofertare) să fie clar definite, înţelese şi asumate rolurile şi responsabilităţile fiecărui membru din Comitetul de Coordonare a Proiectului (ex: Project Manager, Sponsor, utilizatori cheie). În cazul în care ele nu pot face parte din contractul cadru, este bine să vă asiguraţi că se regăsesc în documente anexate proiectului.

Actualizarea modificărilor legislative

De multe ori generarea automată a documentelor financiare şi a declaraţiilor fiscale din soluţia  ERP poate deveni o reală problemă pentru companii, cu precădere în contextul modificărilor frecvente impuse de autorităţile fiscale.

De aceea, pentru a nu fi nevoiţi să apelaţi la „producerea” manuală a acestor documente – lucru care presupune timp sau, altfel spus, costuri – este bine să stabiliţi foarte clar, în contract, care sunt condiţiile (de timp, costuri, procedură, etc) în care furnizorul va asigura actualizarea în timp util a rapoartelor financiare şi a declaraţiilor fiscale.

Serviciile de asistenţă şi suport post-implementare

După ce proiectul a fost implementat cu succes există o perioadă (normală)  de tranziţie către noul ERP. În primele luni de la intrarea în producţie are loc aşa-numita “stabilizare” a sistemului precum şi adopţia soluţiei în rândul utilizatorilor, perioadă în care suportul implementatorului către client este deosebit de important. De aceea trebuie să fie clar specificate în contract atât durata furnizării acestor activităţi de suport cât şi modalitatea prin care vor fi livrate clientului (la distanţă sau la sediul clientului). În continuare, pentru problemele punctuale care necesită suport (ex: asistenţă la operare, erori de funcţionare, configurări, etc) este necesar să existe un sistem centralizat de ticketing, care să asigure condiţiile unei asistente de calitate: timp de răspuns reglementat, asumare, trasabilitate a incidentelor, etc.

Suplimentarea numărului de licenţe, contractarea serviciilor adiţionale etc.

Este firesc că pe măsură utilizării efective a noului ERP să apară idei de optimizare, de adăugare de noi funcţionalităţi sau de extindere a numărului de utilizatori (în urmă adăugării unor funcţionalităţi suplimentare sau ca urmare a angajării de noi oameni).

De aceea, beneficiarul trebuie să se asigure, prin cadrul contractual, că tarifele practicate pentru serviciile ulterioare finalizării proiectului iniţial sau pentru achiziţia de noi licenţe sunt reglementate.

Ca o paranteză, privind în urmă, este recomandat ca încă din faza de selecţie a soluţiei ERP să ne asigurăm că aceasta este suficient de scalabila, astfel încât ulterior să poată facilita extinderea cu noi funcţionalităţi într-un mod “controlat”.

Validarea internă cu coordonatorii de departamente şi cu sponsorul proiectului

Nu puţine sunt cazurile în care persoana desemnată de beneficiar să coordoneze procesul de achiziţie şi implict să negocieze condiţiile contractuale cu furnizorul, omite sau nu reuşeşte să valideze (nu mă refer din punct de vedere juridic) acele părţi din contract care impacteaza în mod direct activitatea unuia sau a mai multor responsabili de departament sau chiar a sponsorului proiectului (ex: Director General).

Din păcate, astfel de situaţii pot bloca bună desfăşurare a proiectului uneori chiar într-o faza incipientă şi cu implicaţii financiare nedorite pentru client.

Pentru a evita aceste situaţii, asiguraţi-va că există aviz pozitiv din partea tuturor personelor implicate în mod direct în execuţia proiectului şi nu doar pe forma juridică sau cea comercială.

În încheiere, probabil că realitatea demonstrează cel mai bine faptul că un contract nu poate înlocui experienţa, seriozitatea sau credibilitatea unui partener viabil, însă forma sa de prezentare oferă de multe ori suficiente argumente pentru a ne gândi cel puţin o dată în plus dacă suntem în faţa celei mai bune decizii.