ERP reikalavimų dokumentas neturi būti 80 puslapių teorijos. Vadovui reikia aiškaus, palyginamo ir praktiško pagrindo: ką sistema turi išspręsti, kur yra didžiausia rizika ir kaip suprasite, kad projektas pavyko.

1. Verslo tikslas

Pradėkite nuo klausimo, kokį verslo rezultatą ERP turi pagerinti: greitesnius užsakymus, tikslesnes atsargas, mažiau rankinio darbo, geresnes ataskaitas ar aiškesnę atsakomybę tarp padalinių.

2. Procesų apimtis

Aprašykite, kokie procesai patenka į projektą: pardavimai, pirkimai, sandėlis, finansai, gamyba, dokumentai, klientų valdymas. Kiekvienam procesui svarbu turėti pradžią, pabaigą, savininką ir dažniausias išimtis.

3. Duomenys ir tiesos šaltinis

Įvardinkite, kur gyvena klientai, prekės, kainos, likučiai, sutartys, dokumentai ir statusai. Jei nėra vieno tiesos šaltinio, ERP projektas tampa duomenų ginčų projektu.

4. Integracijos

Atskirkite, ką ERP turi gauti ir ką turi perduoti: e. komercijai, WMS, CRM, SharePoint, BI, bankams, transporto ar kitoms sistemoms. Integracijoms reikia savininko, duomenų formato ir klaidų valdymo logikos.

5. Rolės ir teisės

Reikalavimuose turi matytis, kas kuria, tvirtina, koreguoja, mato ir eksportuoja duomenis. Tai ypač svarbu augančiose komandose, kur vienas žmogus nebegali būti visų sprendimų vartai.

6. Ataskaitos ir rodikliai

Neužtenka parašyti „reikia ataskaitų“. Įvardinkite sprendimus, kuriems jos reikalingos: pirkimų planavimas, pardavimų kontrolė, marža, atsargos, projektų statusas ar vadovybės dashboardai.

7. Testavimo scenarijai

Tiekėjas turi parodyti ne vien funkciją, o realų scenarijų: užklausa, užsakymas, likutis, sąskaita, grąžinimas, pakeitimas, klaida ir ataskaita. Taip greičiau paaiškėja, ar sprendimas atitinka kasdienį darbą.

Praktinis principas: Jei reikalavimuose nėra proceso savininko, duomenų savininko ir testavimo scenarijaus, projektas dar nėra pasiruošęs rimtam tiekėjų palyginimui.

DUK

Dažniausi klausimai apie ERP reikalavimus

Ar tai turi būti labai detalus dokumentas?

Ne. Pirmame etape svarbiau aiški struktūra ir sprendimų logika. Per daug detali specifikacija be proceso supratimo dažnai tik užmaskuoja neaiškumus.

Ar šabloną galima siųsti tiekėjams?

Taip, jei jame yra procesai, duomenys, integracijos, rolės ir testavimo scenarijai. Tada tiekėjai atsako palyginamai, o ne pagal savo demonstracijos scenarijų.

Kada verta įtraukti konsultantą?

Kai reikalavimai liečia kelis padalinius, yra integracijų, neaiškūs duomenys arba tiekėjų pasiūlymai sunkiai palyginami.