Astăzi a început ALT Festival la Brașov, cel mai mare festival de tehnologie din Transilvania.
BITSoftware vă invită la Internet & Mobile World 2014, cea mai amplă expo-conferință B2B ce oferă soluții IT, digital, marketing, e-commerce și mobile.
Încă de la primul contact cu “strămoşul” sistemului ERP & CRM SocrateCloud, Compiere, mi-a atras atenţia afirmaţia “you can change anything - anytime”. Cu toate că aveam în momentul respectiv o bogată experienţă şi activitate în implementarea de ERP, afirmaţia mi s-a părut cel puţin avangardistă. Ştim cu toţii, atât consultanţii implicaţi, cât şi clienţii, că efortul de implementare al unui ERP este unul considerabil şi nu de puţine ori, de-a dreptul dureros. Deci, după ce în sfârşit reuşeşti să faci lucrurile să meargă, cum să vrei să mai modifici ceva? Din contră, afirmaţia e “nu vă mai atingeţi de ceea ce merge bine!”. Şi totuşi, uite că după ceva timp de la momentul respectiv, m-am regăsit la finalul anului trecut exact în ipostaza de a demonstra pe viu “you can change anything - anytime”. Un client cu o implementare funcţională şi stabilă, ne roagă să-l ajutăm în modificarea nivelului de urmărire a costurilor pe gestiune. A fost momentul în care exact afirmaţia cu pricina mi-a răsunat în urechi, dar de data asta chiar trebuia demonstrată!
Cum s-ar spune, mi-am luat inima în dinţi şi, înarmat cu cea mai nouă versiune de SocrateCloud, am pornit pe drumul schimbării. Pentru a înţelege cele ce urmează, am să fac o paranteză şi am să vă prezint pe scurt capabilităţile sistemului pe arealul gestiunii costurilor.
În acest moment SocrateCloud este integrat cu sistemele online banking puse la dispoziţia clienţilor de către băncile comerciale din România, respectând standardele MT100 şi MT940.
TREBUIE. Într-o formă sau alta este senzația pe care o experimentăm în orice proiect de implementare. Cu toții concepem liste, trasăm direcții cu CE TREBUIE și NU TREBUIE făcut. O implementare ERP se desfașoară în “lumea lui Trebuie” o lume guvernată de responsabilitate, asumare, termene limită, bugete. În condițiile acestea pe parcursul unui proiect de implementare intervine oboseala și apoi, odată cu ea și demoralizarea.
Orice implementare poate fi comparată cu o lungă şi dificilă călătorie.
Ne îmbarcăm cu toţii pe aceeaşi navă cu speranţa că vom ajunge în portul destinaţie. Dar numai speranţele şi bunele intenţii nu sunt suficiente pentru atingerea ţintelor.
Un lucru este evident - cu toţii ne dorim o implementare de succes, fie că ne aflăm în "barca" clientului, fie în cea a furnizorului. Un proiect, nu neapărat unul de implementare sistem ERP, este considerat un succes atunci când, în timpul şi în bugetul agreat sunt îndeplinite obiectivele stabilite la începutul proiectului.Totuşi, există proiecte de implementare care, în timp, sau chiar de la început se îndepărtează de la această definiţie. Unele din principalele motive pentru care o implementare este sortită unui eşec sunt:
sau
Despre Reticența la schimbare a utilizatorilor și despre cum se transformă din adversari în aliați odată cu trecerea timpului și cu obicinuirea cu noul 'program’.
N-ați avut senzația că vă aflați pe un câmp de luptă, atunci când utilizatorii încep în sfârșit lucrul în ‘noul program’?
Eu da, all the time, sau în cea mai mare parte a implementărilor.
Într-un fel, implementarea unui ERP, aka ‘noul program’ este un război ’ iar noi, implementatorii suntem cei din linia intâi.
Ca să fiu mai clar: unde se petrece conflagrația, cine este inamicul și cine sunt aliații?
Sistemele ERP sunt in continuă schimbare datorită, în primul rând modificărilor din organizație și a actualizărilor generate de acestea, care duc la necesitatea de a adăuga/dezvolta noi funcţionalităţi, precum și datorită modificărilor legislative. În plus, creşterea numărului de utilizatori și sistemului integrat de gestiune (ERP) în organizaţie, precum şi migrarea acestora duc la necesitatea de training în mod recurent. În concluzie, training-ul de ERP este o activitate care nu se face o singură dată, ci trebuie continuată de câte ori este nevoie.
Este în general recunoscut faptul că planificarea continuităţii activităţii în caz de dezastru este o activitate vitală, dar destul de rar implementată în sistemele IT medii şi mici din România. Înainte de crearea planului în sine, este esenţial să se ia în considerare efectele potenţiale ale dezastrelor şi riscurile asociate. Acestea sunt bazele pe care ar trebui să fie construit planul de continuitate sau de refacere în caz de dezastru. Planul în sine trebuie să fie întreținut, testat şi verificat, pentru a avea certitudinea că acesta rămâne adecvat nevoilor organizației.
