Este cunoscut faptul ca atunci cand se doreste semnarea contractului pentru achizitia unei solutii ERP (sau, daca extindem un pic contextul, in aproape orice situatie care implica achizitia de produse si/sau servicii), furnizorul este cel care stabileste cadrul contractual.

Chiar daca acest lucru nu este intotdeauna pe placul beneficiarului, in marea majoritate a cazurilor el nu poate fi schimbat ci doar adaptat, intr-o oarecare masura. Din acest motiv, clientul trebuie sa se asigure cat mai bine ca pe langa un partener de incredere are la dispozitie si un cadru formal – contractul – care sa ii protejeze investitia de eventuale „derapaje”.

Mihai_Ionescu

Mihai Ionescu, Senior Sales Consultant

In cele ce urmeaza, va supun atentiei o serie de factori pe care daca ii veti avea in vedere cand negociati un contract de achizitie pentru o solutie ERP, v-ar putea fi de ajutor.

  • Delimitarea scopului proiectului: arii de acoperire si functionalitati care se vor implementa, dar si activitati care nu vor face obiectul contractului.

Pentru a evita eventuale „neintelegeri” care apar in timpul derularii proiectului cu privire la tipul sau numarul de functionalitati care vor fi implementate sau la alte servicii conexe (necesare functionarii solutiei, dar care nu cad implicit in sarcina implementatorului, cum ar fi: instalarea infrastructurii IT, politici de back-up, etc), trebuie ca scopul proiectului sa fie clar delimitat prin contract. Exprimarile generice pot lasa foarte usor loc de interpretari si nu putine sunt cazurile in care, in timpul executiei proiectului, clientul “descopera” ca bugetul a fost deja consumat (cu mult) inainte de finalizare si ca trebuie suplimentat, aparent “nejustificat”.

In acest sens este de dorit ca ariile functionale (ex: Financiar, Vanzari, Achizitii, Stocuri) care vor face obiectul contractului sa fie bine delimitate si detaliate la  nivel de functionalitati specifice fiecareia dintre ele. De asemenea, este bine ca in contract sa fie indicate si acele servicii si/sau functionalitati care nu vor fi parte a proiectului (ex: gestiunea activitatilor din depozit, instalarea sistemului de operare pe server-ul de aplicatie, etc).

  • Nominalizarea activitatilor de proiect la nivel de faze de executie si roluri.

Evitati contractele in care nu sunt specificate fazele (activitatile principale) si sub-fazele executiei proiectului, impreuna cu timpul de implementare (numarul de zile-om necesar) aferent fiecareia dintre ele. In cazul unor exprimari generale sau ambigue exista riscul major ca efortul de implementare ofertat sa fie sub-dimensionat in comparatie cu cel necesar, ceea ce poate conduce la derapaje ale bugetului contractat.

In plus, aceste informatii sunt esentiale pentru planificarea activitatilor de proiect, constituind baza de pornire in definirea calendarului de implementare si nominalizarea livrabilelor proiectului.

Anticipand urmatorul factor important in analiza unui contract, in baza lor se face si o mapare la nivel de roluri pentru fiecare membru al echipei de proiect, lucru necesar in definirea responsabilitatilor.

De aceea, recomandarea este ca in cazul in care contractul nu include deja aceste detalii sa ii solicitaţi in mod expres furnizorului sa le adauge.

  • Descrierea clara a rolurilor si responsabilitatilor fiecarui membru al echipei de proiect (implementator si client)

Se confirma ca succesul unei implementari ERP depinde in egala masura atat de nivelul de experienta si gradul de implicare al implementatorului cat si de participarea activa a clientului la activitatile din cadrul proiectului. Din acest motiv este necesar ca inca de la momentul semnarii contractului (sau chiar din etapa de ofertare) sa fie clar definite, intelese si asumate rolurile si responsabilitatile fiecarui membru din Comitetul de Coordonare a Proiectului (ex: Project Manager, Sponsor, utilizatori cheie). In cazul in care ele nu pot face parte din contractul cadru, este bine sa va asigurati ca se regasesc in documente anexate proiectului.

  • Actualizarea modificarilor legislative.

De multe ori generarea automata a documentelor financiare si a declaratiilor fiscale din solutia  ERP poate deveni o reala problema pentru companii, cu precadere in contextul modificarilor frecvente impuse de autoritatile fiscale.

De aceea, pentru a nu fi nevoiti sa apelati la „producerea” manuala a acestor documente – lucru care presupune timp sau, altfel spus, costuri – este bine sa stabiliti foarte clar, in contract, care sunt conditiile (de timp, costuri, procedura, etc) in care furnizorul va asigura actualizarea in timp util a rapoartelor financiare si a declaratiilor fiscale.

  • Serviciile de asistenta si suport post-implementare.

Dupa ce proiectul a fost implementat cu succes exista o perioada (normala) de tranzitie catre noul ERP. In primele luni de la intrarea in productie are loc asa-numita “stabilizare” a sistemului precum si adoptia solutiei in randul utilizatorilor, perioada in care suportul implementatorului catre client este deosebit de important. De aceea trebuie sa fie clar specificate in contract atat durata furnizarii acestor activitati de suport cat si modalitatea prin care vor fi livrate clientului (la distanta sau la sediul clientului). In continuare, pentru problemele punctuale care necesita suport (ex: asistenta la operare, erori de functionare, configurari, etc) este necesar sa existe un sistem centralizat de ticketing, care sa asigure conditiile unei asistente de calitate: timp de raspuns reglementat, asumare, trasabilitate a incidentelor, etc.

  • Suplimentarea numarului de licente, contractarea serviciilor aditionale etc

Este firesc ca pe masura utilizarii efective a noului ERP sa apara idei de optimizare, de adaugare de noi functionalitati sau de extindere a numarului de utilizatori (in urma adaugarii unor functionalitati suplimentare sau ca urmare a angajarii de noi oameni).

De aceea, beneficiarul trebuie sa se asigure, prin cadrul contractual, ca tarifele practicate pentru serviciile ulterioare finalizarii proiectului initial sau pentru achizitia de noi licente sunt reglementate.

Ca o paranteza, privind in urma, este recomandat ca inca din faza de selectie a solutiei ERP sa ne asiguram ca aceasta este suficient de scalabila, astfel incat ulterior sa poata facilita extinderea cu noi functionalitati intr-un mod “controlat”.

  • Validarea interna cu coordonatorii de departamente si cu sponsorul proiectului.

Nu putine sunt cazurile in care persoana desemnata de beneficiar sa coordoneze procesul de achizitie si implict sa negocieze conditiile contractuale cu furnizorul, omite sau nu reuseste sa valideze (nu ma refer din punct de vedere juridic) acele parti din contract care impacteaza in mod direct activitatea unuia sau a mai multor responsabili de departament sau chiar a sponsorului proiectului (ex: Director General).

Din pacate, astfel de situatii pot bloca buna desfasurare a proiectului uneori chiar intr-o faza incipienta si cu implicatii financiare nedorite pentru client.

Pentru a evita aceste situatii, asigurati-va ca exista aviz pozitiv din partea tuturor personelor implicate in mod direct in executia proiectului si nu doar pe forma juridica sau cea comerciala.

In incheiere, probabil ca realitatea demonstreaza cel mai bine faptul ca un contract nu poate inlocui experienta, seriozitatea sau credibilitatea unui partener viabil, insa forma sa de prezentare ofera de multe ori suficiente argumente pentru a ne gandi cel putin o data in plus daca suntem in fata celei mai bune decizii.

Share

Distribuie pagina prin urmatoarele canale:

0 share-uri

Mesaje

Mai multe noutati