Un ERP personalizat se construiește pornind de la procesele firmei, datele necesare și responsabilitățile oamenilor care îl vor folosi. Prima etapă utilă este o analiză care delimitează problema și prima versiune. Programarea vine după stabilirea regulilor și a modului în care rezultatul va fi verificat.
ERP-ul poate conecta informații despre comenzi, achiziții, stocuri, producție sau livrare, în funcție de proiect. Nu trebuie să cuprindă toate activitățile firmei de la început. Uneori, o aplicație pentru un proces și integrarea cu instrumentele existente reprezintă o investiție mai ușor de justificat.
Când are sens un ERP personalizat
Merită analizat când procesele importante nu sunt acoperite satisfăcător de o soluție disponibilă, iar diferențele produc muncă manuală, întârzieri sau lipsă de vizibilitate. Mai întâi trebuie testată și alternativa configurării unui produs existent. Vezi și criteriile de alegere între configurare și dezvoltare personalizată.
Semnele utile pentru analiză sunt concrete: aceeași comandă este introdusă în mai multe fișiere, statutul producției se află doar întrebând colegii, modificările nu au un istoric clar sau materialele necesare sunt cunoscute prea târziu.
Nu este suficient argumentul „vrem totul într-un singur loc”. Definește ce decizie va deveni mai simplă: ce comenzi sunt în întârziere, ce trebuie cumpărat, ce lucrare poate începe sau cine trebuie să aprobe următorul pas.
Etapa 1: descrierea procesului actual
Alege un flux complet și urmărește documentele, persoanele și excepțiile. Pentru fiecare pas notează ce îl declanșează, ce informație intră, ce rezultat trebuie să iasă și cine răspunde de el.
Exemplu ipotetic: într-un atelier, o comandă trece prin ofertă, aprobare, pregătire, producție și livrare. Dacă o modificare după aprobare nu este transmisă producției, problema trebuie rezolvată printr-o regulă de versiune și confirmare. Un câmp suplimentar în aplicație nu este suficient.
Folosește această etapă și pentru a elimina pașii fără rost. Automatizarea unui proces confuz poate face confuzia mai rapidă și mai greu de urmărit.
Etapa 2: delimitarea primei versiuni
Împarte cerințele în trei categorii: necesare pentru funcționarea fluxului ales, utile după lansare și idei care trebuie validate. Pentru prima versiune, stabilește explicit și ce rămâne în sistemele actuale.
De exemplu, proiectul poate urmări comenzile și producția, păstrând facturarea în aplicația folosită deja. Integrarea trebuie descrisă prin datele transferate, momentul transferului și comportamentul la eroare.
Definește criteriile de acceptare înainte de dezvoltare: cine execută scenariul de test, cu ce date și care este rezultatul corect. „Funcționează bine” nu poate fi verificat la fel de clar ca „o comandă fără aprobare nu intră în producție”.
Etapa 3: date, acces și integrări
Inventariază sursele existente și decide cine validează informațiile. Clienții dublați, produsele fără cod și unitățile de măsură neuniforme nu dispar prin import. Curățarea și reconcilierea datelor trebuie incluse în calendar.
- Date de bază: clienți, produse, materiale, servicii și utilizatori.
- Date în lucru: comenzi active, cantități și stadii confirmate.
- Istoric: ce trebuie migrat și ce poate rămâne într-o arhivă accesibilă.
- Acces: cine poate vedea, modifica, aproba și exporta fiecare categorie.
- Integrări: sistemul care păstrează versiunea principală a fiecărei informații.
Planifică o migrare de probă și verifică totalurile, legăturile între înregistrări și exemplele dificile. Un import încheiat fără mesaj de eroare nu dovedește singur corectitudinea datelor.
Etapa 4: dezvoltare și verificări regulate
Lucrează în livrări delimitate, fiecare cu o demonstrație pe scenarii reale sau date de test reprezentative. Responsabilul din firmă confirmă regulile, iar utilizatorii verifică dacă pot executa sarcinile zilnice.
Cerințele noi trebuie evaluate în raport cu bugetul, calendarul și scopul primei versiuni. Pentru fiecare schimbare, consemnează ce se adaugă, ce se amână și ce trebuie retestat.
O abordare pe etape apare și în ghidul Microsoft pentru implementări Dynamics 365, care separă strategia, inițierea, implementarea, pregătirea și operarea. Pașii de mai sus sunt o propunere practică de organizare; nu presupun folosirea platformei Microsoft.
Cine răspunde de fiecare parte a proiectului
| Rol | Responsabilitate principală | Rezultat de verificat |
|---|---|---|
| Decidentul firmei | Aprobă scopul, bugetul și prioritățile. | Prima versiune are un obiectiv și limite clare. |
| Responsabilul de proces | Explică regulile și decide cum se tratează excepțiile. | Scenariile și criteriile de acceptare sunt aprobate. |
| Responsabilul de date | Curăță și validează informațiile pentru migrare. | Importul de probă este reconciliat cu sursa. |
| Echipa tehnică | Proiectează, dezvoltă, testează și documentează soluția. | Funcțiile și integrările respectă cerințele convenite. |
| Utilizatorii cheie | Testează activitatea zilnică și semnalează blocajele. | Fluxurile pot fi executate cu instrucțiunile primite. |
| Responsabilul de operare | Urmărește incidentele, accesul și întreținerea. | Există o procedură de suport după lansare. |
Într-o firmă mică, aceeași persoană poate acoperi mai multe roluri. Responsabilitățile trebuie totuși numite, astfel încât echipa tehnică să nu fie nevoită să inventeze reguli comerciale sau operaționale.
Etapa 5: lansare controlată și continuitate
Înainte de trecerea la noul sistem, verifică fluxul complet, accesul pe roluri, performanța la un volum reprezentativ și tratarea incidentelor. Stabilește momentul importului final, persoanele disponibile și condițiile în care lansarea se amână.
Include copii de siguranță și o verificare a restaurării, o procedură pentru comenzi primite în timpul tranziției și un plan de revenire. După lansare, urmărește erorile, timpul de lucru și adoptarea de către echipă înainte de extinderea funcțiilor.
Fișă de lucru pentru o cerință ERP
Copiază modelul de mai jos pentru fiecare proces prioritar:
- Procesul și problema observată:
- Persoana care decide regulile:
- Evenimentul care pornește procesul:
- Datele obligatorii și sursa acestora:
- Pașii și aprobările necesare:
- Excepțiile întâlnite în activitate:
- Sistemele cu care trebuie să comunice:
- Scenariul de test și rezultatul așteptat:
- Ce măsurăm înainte și după:
- Ce nu intră în prima versiune:
Ce influențează costul
Bugetul depinde de complexitatea regulilor, integrări, calitatea datelor, drepturi de acces, rapoarte și cerințe de disponibilitate. Include analiza, implementarea, migrarea, instruirea, găzduirea și întreținerea. Timpul echipei interne pentru decizii și testare trebuie planificat separat.
Solicită livrabile și criterii de acceptare pentru fiecare etapă. Un preț fără un scop delimitat este greu de comparat cu altă ofertă.
Întrebări frecvente
Trebuie să înlocuiesc toate aplicațiile existente?
Nu. Un proiect poate păstra instrumentele care funcționează și poate conecta doar procesele care au nevoie de informații comune.
Pot muta toate datele vechi?
Posibilitatea se verifică după formatele disponibile și calitatea informațiilor. Definește ce istoric este necesar în operare și ce poate fi consultat într-o arhivă.
Cum știu că prima versiune este gata?
Când scenariile convenite sunt acceptate, datele sunt validate, echipa poate lucra și există responsabilități clare pentru suport. O demonstrație vizuală nu înlocuiește aceste verificări.
Pregătește un proiect care poate fi estimat
Alege un proces, completează fișa și adună exemple anonimizate de documente. Discuția despre dezvoltarea unui CRM sau ERP personalizat poate porni astfel de la nevoi verificabile. Pentru alegerea primului flux, consultă și ghidul automatizărilor pentru firme.