Po dviejų verslo valdymo sistemų pristatymų pasirinkimas gali likti toks pat neaiškus. Vienoje demonstracijoje matėte patogų užsakymo kūrimą, kitoje – išsamias ataskaitas. Abi sistemos pasirodė tinkamos, tačiau vis dar nežinote, kaip jose darbuotojai atliktų jūsų įmonei svarbius darbus.
Sprendžiant, Odoo ar SAP geriau atitiktų įmonės poreikius, verta abiem sprendimams parengti tą pačią praktinę užduotį. Joje turi būti aiški pradžia, darbuotojų veiksmai ir laukiamas rezultatas. Toks palyginimas padeda pamatyti, kur darbą atliksite standartinėmis funkcijomis, kur reikės papildomų sprendimų ir kiek veiksmų vis dar liks darbuotojui.
Pirmiausia pasiūlymuose turėtų būti įvardyti konkretūs produktai. SAP pavadinimas apima skirtingus ERP sprendimus. Pavyzdžiui, SAP Business One skirtas mažoms ir vidutinėms įmonėms, todėl SAP pasirinkimo negalima sieti vien su didelėmis organizacijomis. Vertindami pasiūlymą išsiaiškinkite, kuris produktas pristatomas ir kokie papildomi sprendimai į jį įtraukti.
Odoo atveju taip pat svarbu žinoti leidimą ir talpinimo būdą. Community ir Enterprise yra Odoo leidimai. Odoo Online, Odoo.sh ir įmonės pasirinktas serveris – skirtingi sistemos talpinimo variantai. Nuo pasirinkto varianto priklauso pritaikymo galimybės ir atsakomybė už aplinkos priežiūrą. Pavyzdžiui, Odoo.sh leidžia naudoti individualius pritaikymus ir trečiųjų šalių programas.
Paprašykite, kad demonstracijoje būtų aiškiai atskirta, kas priklauso pačiai sistemai, kas įdiegta papildomai ir kas dar tik siūloma sukurti. Kitaip vieną produktą galite vertinti pagal standartinę versiją, o kitą – pagal konkrečiai demonstracijai išplėstą sprendimą. Tokį skirtumą reikia žinoti prieš darant išvadas.
Sąraše pažymėtas „pardavimų valdymas“ dar neatskleidžia, kaip užsakymas pasieks sandėlį, kas patvirtins pakeitimą ir kada bus išrašyta sąskaita. Naudingiau pasirinkti vieną įprastą užsakymą ir aprašyti visą jo eigą per kelis padalinius.
Ruošdamiesi demonstracijai pasikalbėkite su darbuotojais, kurie tą užsakymą tvarko kasdien. Kokius duomenis gauna pardavėjas? Ką jis perduoda sandėliui? Kokią informaciją buhalterija tikrina prieš išrašydama sąskaitą? Pažymėkite vietas, kuriose duomenys kopijuojami, sprendimo laukiama el. paštu arba naudojama atskira lentelė.
Tada apibrėžkite rezultatą, kurį norite pamatyti demonstracijoje. Pavyzdžiui, po prekių išsiuntimo darbuotojas turi rasti pristatytą kiekį, likusią užsakymo dalį ir su pristatymu susijusią sąskaitą. Toks aprašymas leidžia tikrinti konkretų darbą, o ne vien ekrane matomų laukų skaičių.
Abiem tiekėjams pateikite tuos pačius pradinius duomenis ir sąlygas. Galima naudoti nuasmenintą užsakymo pavyzdį su keliomis prekėmis, sutarta kaina ir pristatymo terminu. Jei vienos demonstracijos metu scenarijus pakeičiamas, užfiksuokite kodėl: gal išryškėjo sistemos apribojimas, o gal pasiūlytas paprastesnis darbo būdas.
Sklandžiai įvykdytas užsakymas atskleidžia tik dalį sistemos veikimo. Daugiau galima sužinoti pakeitus vieną jo sąlygą. Toliau pateikti hipotetiniai pavyzdžiai skirti demonstracijai pasiruošti. Juos pritaikykite savo veiklai ir paprašykite parodyti, kaip siūlomas Odoo arba SAP sprendimas susidorotų su konkrečiu pakeitimu.
Tarkime, klientas užsakė 20 prekių, tačiau sandėlyje šiuo metu yra 12. Sutariama jas išsiųsti iš karto, o likusias pristatyti kitą savaitę. Per demonstraciją paprašykite parodyti visą užsakymą, o tada – kaip užregistruojamas dalinis pristatymas ir parengiami jo dokumentai.
Stebėkite, ar darbuotojui aišku, kiek jau išsiųsta ir kiek dar reikia pristatyti. Paprašykite parodyti, kur matoma likusių prekių pristatymo klientui data ir kaip ji derinama su numatomu atsargų papildymu. Taip pat patikrinkite, kokius duomenis gauna sąskaitą rengiantis žmogus. Sąskaitos išrašymo tvarką pasirinkite pagal savo įmonės susitarimą su klientu.
Tuomet įtraukite dar vieną pakeitimą: klientas atsisako keturių nepristatytų prekių. Patikrinkite, kas turi teisę pakeisti kiekį, kokią informaciją po to mato sandėlis ir ar pardavėjui reikia papildomai apie tai pranešti kolegoms. Čia išryškėja, kiek proceso apima sistema ir kiek jo tenka suderinti atskirai.
Įsivaizduokime, kad gamybai reikalingas komponentas vėluoja, o technologas leidžia naudoti tinkamą pakaitalą. Dalies gamybos užsakymų vykdymas jau pradėtas. Tokiam bandymui paruoškite gaminio sudėtį, užsakymo kiekį ir aiškiai nurodykite, kuriam užsakymui leidžiamas pakeitimas.
Paprašykite parodyti, kaip pakeitimas užregistruojamas ir kaip jį pamato gamybos bei sandėlio darbuotojai. Svarbu patikrinti, ar pakeista tik konkretaus užsakymo sudėtis, ar kartu pasikeitė ir kitiems užsakymams naudojama specifikacija. Tai skirtingi veiksmai, kurių pasekmės taip pat skiriasi.
Bandymą užbaikite medžiagų sunaudojimo ir gamybos rezultato peržiūra. Ar galima atsekti, kuris komponentas panaudotas? Kaip patikrinti jo kiekį ir savikainą? Jeigu daliai šių veiksmų siūlomas papildomas modulis ar programavimas, pažymėkite tai prie konkretaus reikalavimo. Vien pažado, kad „gamyba palaikoma“, tokiam procesui įvertinti neužtenka.
Paslaugų įmonės pavyzdyje klientas projekto metu paprašo papildomų darbų. Komanda jau registruoja laiką, o pradinis biudžetas patvirtintas. Demonstracijos užduotis – parodyti, kaip papildomas darbas suderinamas ir atskiriamas nuo anksčiau sutartos apimties.
Pradėkite nuo pakeitimo patvirtinimo: kas jį užregistruoja, kas priima sprendimą ir kur darbuotojas pamato, kad gali pradėti darbą. Toliau patikrinkite, prie ko priskiriamas sugaištas laikas ir kaip sąskaitą rengiantis žmogus atskiria papildomai apmokamus darbus.
Pabaigoje paprašykite parodyti projekto rezultatą: pradžioje sutartą apimtį, patvirtintus papildymus ir faktiškai atliktą darbą. Jei šiai informacijai surinkti reikia eksportuoti kelias ataskaitas ir jas sujungti lentelėje, tai verta užfiksuoti. Tuomet galėsite sąmoningai nuspręsti, ar toks darbo būdas jums priimtinas.
Per demonstraciją pasakytas „galima“ gali reikšti kelis skirtingus dalykus. Funkcija jau veikia, jai reikia nustatymų, būtinas papildomas modulis arba ją dar reikės programuoti. Kiekvienam svarbiam reikalavimui paprašykite nurodyti, kuris variantas siūlomas.
Palyginimo užrašuose pravartu turėti vienodą lentelę abiem sprendimams:
Ką užfiksuoti | Ką įrašyti po demonstracijos |
Tikrinamas veiksmas | Konkreti darbuotojo užduotis ir laukiamas rezultatas |
Parodytas rezultatas | Kas atlikta nuo pradžios iki pabaigos, kas liko neparodyta |
Įgyvendinimo būdas | Standartinė funkcija, nustatymai, papildomas modulis ar programavimas |
Likęs rankinis darbas | Duomenų kopijavimas, derinimas kitur, atskiros lentelės |
Neatsakytas klausimas | Ką dar reikia išbandyti ir kas pateiks atsakymą |
Papildomas programavimas savaime nereiškia, kad sprendimas netinka. Tačiau jo rezultato negalima laikyti jau patikrintu. Jei nuo tokio pakeitimo priklauso svarbiausias įmonės procesas, prieš priimant sprendimą verta sutarti dėl išsamesnio bandymo ar prototipo ir aiškių jo priėmimo sąlygų.
Vertinimo užrašuose palikite vietos ir sąlygoms, kuriomis bandymas atliktas. Ar duomenys buvo įvesti iš anksto? Ar veiksmus atliko administratorius, ar įprastas naudotojas? Darbuotojui suteiktos teisės ir pasirengimas gali pakeisti tai, ką jis galės atlikti kasdien. Todėl svarbų scenarijų verta pakartoti naudojant darbuotojo paskyrą su jam numatytomis prieigos teisėmis.
Pirmiausia atskirkite reikalavimus, be kurių įmonė negalės dirbti, nuo pageidaujamų patogumų. Gražesnė ataskaita nekompensuos to, kad nepavyksta įvykdyti būtino užsakymo scenarijaus. Kartu nereikėtų atmesti sistemos vien todėl, kad ji siūlo kitokią, bet darbuotojams priimtiną veiksmų seką.
Rezultatus aptarkite su demonstracijoje dalyvavusiais darbuotojais. Kur jie mato papildomą darbą? Kur reikės naujo susitarimo tarp padalinių? Kuris klausimas liko neatsakytas? Tokia diskusija padeda atskirti sistemos galimybes nuo įmonės pasirengimo jomis naudotis.
Jei svarstote, ar verta pereiti nuo SAP, tą pačią užduotį naudinga atlikti ir dabartinėje aplinkoje. Palyginimas padės įvertinti, ar naujas sprendimas pagerintų šį procesą ir kuo skirtųsi nuo dabartinio. Kartu gali paaiškėti, kad dalį problemų sukelia neatnaujinti nustatymai, netikslūs duomenys ar nesuderinta darbo tvarka. Tuomet turėsite pagrindą vertinti ir esamos sistemos sutvarkymą.
Į pokalbį su diegėju verta ateiti su vienu aiškiai aprašytu procesu, jo išimtimis ir norimu rezultatu. Susisiekite su „Sandas“ – aptarkime, kaip tokį procesą būtų galima įgyvendinti Odoo aplinkoje ir ką reikėtų patikrinti prieš pasirenkant sprendimą.
