Kaip pasiruošti „Rita Grid“ diegimui: procesai, duomenys ir naudotojai

Pirmas sistemos diegimo susitikimas dažnai greitai nukrypsta į laukus, mygtukus ir ataskaitas. Tačiau dar prieš konfigūravimą reikia atsakyti į paprastesnius klausimus: kaip užsakymas juda per komandą, kas gali jį pakeisti ir kokiu duomeniu pasitikime. Aiškiai susitarus dėl šių dalykų, bandomasis etapas turi ribas. Papildomų pageidavimų nebereikia bandyti sutalpinti į pirmąją versiją.

Aprašykite dabartinę užsakymo eigą be idealizavimo

Aprašykite ne procedūrą, kuri turėtų veikti, o vakarykštę darbo dieną. Kaip atėjo užsakymas? Kas pastebėjo trūkstamą informaciją? Kada jis tapo tinkamas planuoti, kas priskyrė maršrutą ir pagal ką užduotis buvo uždaryta? Įtraukite kasdienius nukrypimus. Jei po suplanavimo laikas keičiamas nuolat, tai nėra reta išimtis ir sistemai toks scenarijus reikalingas nuo pradžių.

Nereikia braižyti kiekvieno paspaudimo. Užtenka būsenų, sprendimo taškų, atsakingų rolių ir perduodamos informacijos. Šalia pažymėkite dabar naudojamą įrankį bei konkretų nepatogumą: duomenys įvedami antrą kartą, būsena vėluoja, trūksta pristatymo įrodymo arba niekas nežino, kas gali patvirtinti pakeitimą.

Susitarkite dėl rolių ir teisių prieš kuriant naudotojus

Rolę kurkite pagal veiksmą, ne pagal pareigų pavadinimą. Kas įveda užsakymą? Kas gali pakeisti laiką po planavimo? Kas paskiria vairuotoją ir kas patvirtina, kad užduotis baigta? Taip atsiranda teisių modelis, kurį galima paaiškinti naudotojui. Pareigų sąrašas vienas tokio aiškumo nesuteikia.

Per plačios teisės mažina kontrolę, o per siauros verčia kiekvieną pakeitimą perduoti vienam administratoriui. Bandomajame etape verta patikrinti ne tik tai, ar naudotojas mato reikiamą ekraną, bet ir ar gali priimti jam priskirtą sprendimą. Atsarginės rolės taip pat svarbios pamainoms, atostogoms ir incidentams.

Standartizuokite būsenas ir privalomą informaciją

Paklauskite kelių žmonių, ką reiškia „paruošta“, ir galite išgirsti skirtingus atsakymus. Vienam tai patikrintas užsakymas, kitam – jau sukomplektuotas krovinys. Kiekvienai būsenai užrašykite aiškią įėjimo sąlygą, atsakingą rolę ir veiksmą, po kurio galima judėti toliau. Būsena „atlikta“ negali paslėpti trūkstamo dokumento ar neuždarytos išimties.

Privalomi laukai nustatomi pagal būsimą sprendimą. Jei informacija reikalinga planuoti, ją reikia gauti iki planavimo. Jei ji skirta tik analizei, nebūtina apkrauti vairuotojo papildomu veiksmu kritiniu metu. Geriau mažesnis patikimai pildomų laukų rinkinys nei didelė forma, kurią komanda apeina.

Įvertinkite pradinių duomenų kokybę

Prieš importuojant seną failą verta jį sustabdyti ir peržiūrėti. Kurie įrašai dar galioja? Kas atsako už adresus, kontaktus ar transporto identifikatorius? Kaip bus pataisyta klaida? Dubliuoto ar nežinomos kilmės įrašo nereikia perkelti vien todėl, kad jis yra faile. Prasti pradiniai duomenys bandomajame etape atrodys kaip naujos sistemos problema.

Duomenų parengimas taip pat apima sprendimą dėl istorijos. Kiek ankstesnės informacijos realiai reikia kasdieniam darbui, ataskaitoms ar teisiniam saugojimui? Perkėlimo apimtis derinama atskirai ir turi turėti patikrinimo taisykles. Pradinių duomenų kokybė tiesiogiai veikia bandomojo etapo patikimumą.

Integracijas formuokite kaip konkrečius scenarijus

„Reikia integracijos su ERP“ dar nėra reikalavimas. Užrašykite, kas tiksliai perduodama, kuria kryptimi, kuriuo momentu ir kurie laukai privalomi. Svarbiausias klausimas dažnai išryškėja tik tada: kuri sistema yra pagrindinis to duomens šaltinis? Taip pat aprašykite klaidos atvejį, nes ne kiekvienas perdavimas pavyks iš pirmo karto.

Integracijos apimtis priklauso nuo kitos sistemos sąsajų, duomenų struktūros, perdavimo dažnio, saugumo ir klaidų valdymo. Todėl ji vertinama atskirai. Bandomąjį etapą kartais racionalu pradėti su kontroliuojamu duomenų įkėlimu, jei tai leidžia pirmiau patikrinti operacinę logiką, tačiau toks sprendimas turi būti aiškiai pažymėtas kaip laikinas.

Pasirinkite reprezentatyvų, bet valdomą bandomąjį srautą

Vienas idealus užsakymas nieko neįrodo, o visos įmonės pilotas iš karto palieka per daug nežinomųjų. Pasirinkite srautą, kuriame dalyvauja pagrindinės rolės, pasitaiko įprastų pakeitimų, bet kurį komanda dar gali kontroliuoti. Aiškiai sutarkite, kada bandymas prasideda ir baigiasi. Reikia ir atsarginės tvarkos tam atvejui, jei kritinė funkcija neveiktų.

Priėmimo kriterijai turi vertinti visą scenarijų: ar užsakymas teisingai sukuriamas, ar planuotojas gali jį priskirti, ar vairuotojas gauna aktualią užduotį, ar įrodymas grįžta į sistemą ir ar atsakingas žmogus mato būklę. Kriterijai nėra tik defektų sąrašas. Jie parodo, ar procesas pasirengęs kasdieniam naudojimui.

Paruoškite naudotojus ir pagalbos tvarką

Mokyti geriausia pagal realią rolės dieną. Dispečeris turi pats suplanuoti ir išspręsti nukrypimą, vairuotojas – gauti bei uždaryti užduotį, o vadovas – rasti būklę ir neužbaigtą veiksmą. Bendras visų funkcijų pristatymas atrodo išsamus, tačiau pirmą darbo dieną žmogui vis tiek lieka klausimas, ką spausti būtent jo situacijoje.

Prieš startą susitarkite, kur registruojamas klausimas ar incidentas, kas nustato prioritetą ir kaip naudotojas sužino apie sprendimą. Pakeitimų pageidavimai turėtų būti atskirti nuo sutrikimų. Tai padeda išlaikyti bandomojo etapo apimtį ir kaupti argumentuotą tolesnio vystymo sąrašą.

Rezervuokite tikslinį „Rita Grid“ pristatymą

Prieš pristatymą atsiųskite trumpą proceso aprašymą, naudotojų roles ir du ar tris dažnus scenarijus. Tada galėsime kalbėti apie realią pirmojo etapo apimtį, o ne rodyti funkcijas, kurios jūsų darbui gali būti nesvarbios.