ERP ir MES reikalavimai gamybai: ką sutarti prieš kalbantis su tiekėjais

Sistemos atranka dažnai prasideda nuo demonstracijų. Tiekėjas rodo planavimą, atsekamumą ir ataskaitas, o komanda bando įsivaizduoti, kaip visa tai atrodytų jos gamykloje. Po kelių susitikimų funkcijų sąrašas ilgėja, tačiau pagrindinis klausimas lieka neatsakytas: kokį sprendimą naujoji sistema turi padėti priimti geriau nei šiandien?

Prieš lyginant ERP, MES ar atskirus gamybos modulius verta susitarti dėl proceso, duomenų ir atsakomybių. Tai nėra techninės specifikacijos rašymas iš anksto. Tai būdas atskirti realų veiklos poreikį nuo patrauklios funkcijos, kuri demonstracijoje atrodo naudinga, bet kasdienio darbo nekeičia.

Pradėkite nuo sprendimo, kurio šiandien trūksta

Formuluotė „reikia geresnio gamybos valdymo“ tiekėjui palieka per daug vietos spėlioti. Daug naudingesni konkretūs klausimai. Kokios informacijos trūksta planuotojui, kai keičiasi prioritetas? Kada pamainos vadovas sužino apie nukrypimą? Kas patvirtina perplanavimą ir kur lieka sprendimo istorija?

Kiekvienam poreikiui užrašykite situaciją, atsakingą rolę, tuo metu reikalingą informaciją ir rezultatą, pagal kurį bus matyti, kad sprendimas veikia. Toks aprašymas padeda atskirti sistemos reikalavimą nuo darbo tvarkos klausimo. Jei niekas neturi teisės pakeisti prioriteto, naujas ekranas šios spragos neužpildys. Pirmiausia reikia sutarti atsakomybę, o tik tada nuspręsti, kaip sistema ją palaikys.

Nubrėžkite ribą tarp ERP, gamybos operacijų ir įrenginių

Vienas duomuo gali keliauti per kelis sluoksnius: užsakymas atsiranda verslo sistemoje, virsta gamybos užduotimi, ceche papildomas faktu, o įrenginys pateikia techninį signalą. Jei neaišku, kuri sistema už ką atsakinga, tas pats laukas pradedamas pildyti keliose vietose.

ISA-95 / IEC 62264 metodika atskiria verslo planavimo ir gamybos operacijų valdymo funkcijas bei tarp jų perduodamą informaciją. Praktiniam projektui nebūtina kopijuoti visos standarto struktūros. Pakanka kiekvienam svarbiam objektui — užsakymui, gaminiui, operacijai, įrenginiui ir medžiagai — nustatyti pirminį šaltinį, savininką, keitimo teisę ir perdavimo kitai sistemai taisyklę.

Aprašykite kasdienes išimtis, ne tik standartinį kelią

Demonstracijoje beveik visada matomas tvarkingas užsakymas. Realią sistemos vertę dažniau parodo išimtys: trūksta žaliavos, pasikeičia terminas, operacija atlikta iš dalies, gaminys grąžinamas taisymui arba užduotis perduodama kitai darbo vietai.

Atrankai paruoškite kelis trumpus scenarijus iš kasdienio darbo. Kiekviename turi būti pradinis įvykis, sprendimo teisė, būtini duomenys ir pageidaujamas rezultatas. Tiekėjo paprašykite parodyti visą eigą jo sistemoje, o ne vien galutinę ataskaitą. Taip paaiškėja, kiek reikės rankinių veiksmų, konfigūravimo ir papildomų integracijų. Išimtis rinkitės pagal dažnį bei poveikį, o ne pagal dramatiškumą.

Duomenų kokybę įvertinkite prieš migraciją

Sena sistema gali turėti daug duomenų ir vis tiek būti prastas šaltinis naujai. Patikrinkite, ar vienodai naudojami gaminių kodai, operacijų būsenos, įrenginių pavadinimai ir sustojimų priežastys. Reikia nuspręsti, kokia istorija būtina darbui, ką pakanka archyvuoti ir kurių įrašų perkelti neverta.

Europos Komisijos skaitmeninės brandos vertinimo metodika duomenų valdymą nagrinėja kaip atskirą skaitmeninimo sritį. Ši logika praktiška ir sistemos atrankoje: neužtenka nusipirkti funkciją, jeigu neaišku, kas prižiūrės klasifikatorius, taisys klaidas ir spręs dėl duomens reikšmės. Jei šių taisyklių dar nėra, pažymėkite spragą kaip projekto riziką, o ne palikite ją migracijai.

Integraciją formuluokite kaip informacijos sutartį

Reikalavimas „integruoti su ERP“ yra per platus. Tikslesnis aprašymas nurodo, koks objektas perduodamas, kuri sistema yra pagrindinis šaltinis, kaip dažnai informacija atnaujinama, ką daryti klaidos atveju ir kas prižiūri sąsają.

Prieš atranką nebūtina žinoti galutinio techninio protokolo. Tačiau būtina suprasti verslo taisyklę. Ar gamybos užduoties pakeitimas gali būti priimtas ceche, ar tik ERP? Ar faktinis sunaudojimas grįžta po kiekvienos operacijos, pamainos pabaigoje ar uždarius užsakymą? Kuri būsena laikoma patvirtinta? Šie atsakymai kasdieniam darbui svarbesni už integracijos pavadinimą.

Priėmimo kriterijus rašykite taip, kad juos būtų galima parodyti

„Patogi sistema“ nėra patikrinamas kriterijus. „Pamainos vadovas viename lange mato šiandienos užduotis, jų prioritetą, būseną ir nepatvirtintus nukrypimus“ — jau yra scenarijus, kurį galima pademonstruoti ir priimti.

Prie svarbaus reikalavimo nurodykite naudotojo rolę, pradinę situaciją, veiksmą sistemoje, tikėtiną rezultatą ir bandymui reikalingus duomenis. Taip pat atskirkite standartinę produkto funkciją, konfigūravimą ir programavimą. Šis skirtumas lemia ne tik pradinę kainą, bet ir atnaujinimų, palaikymo bei būsimo pakeitimo sudėtingumą.

Pilotą ribokite realiu darbo srautu

Pilotas neturėtų būti sumažinta viso projekto kopija. Pasirinkite vieną srautą, kuriame yra tikras sprendimas, keli naudotojų vaidmenys ir bent viena dažna išimtis. Iš anksto sutarkite, kokia dabartinė būklė bus palyginimo taškas, ką stebėsite ir kas nuspręs, ar galima plėsti apimtį.

Pirmojo etapo paskirtis — patikrinti, ar pasirinktas darbo modelis veikia, ar duomenys gaunami pakankamai patikimai ir ar komanda gali naudoti sistemą be nuolatinio projekto žmonių įsikišimo. Tik po to verta tikslinti platesnę diegimo apimtį.

Pirmiausia susitarkime dėl veiklos, ne dėl ekrano

Jei planuojate ERP, MES ar gamybos stebėsenos sprendimą, į pirmą pokalbį atsineškite vieną procesą, dabartinį informacijos kelią ir sprendimą, kurio komanda šiandien negali priimti laiku. UAB „Nėra-Bus“ padės patikrinti poreikį, suformuoti reikalavimų logiką ir paruošti pagrindą tiekėjų vertinimui.