Dažnai šis klausimas iškyla tada, kai poreikis jau skubus. Senoji sistema nebeatlaiko augančių apimčių, darbuotojai vis daugiau darbo atlieka rankiniu būdu, o plėtra pradeda strigti. Procesai tuo metu dar nebūna aprašyti, reikalavimai nesurinkti, o būsimas vartotojų skaičius ir reikalingos integracijos neįvertintos.
Tada prasideda produktų demonstracijos. Jos tampa pagrindiniu informacijos šaltiniu, nors palyginti skirtingus sprendimus tokiu būdu labai sunku. Kiekvienas tiekėjas sistemą rodo pagal savo scenarijų ir natūraliai akcentuoja tai, ką jo produktas daro geriausiai.
Pasirinkimas neretai tenka sprendimui, kuris pristatymo metu atrodė įtikinamiausiai. Tikrosios pasekmės išryškėja vėliau: pritrūksta integracijos su buhalterine programa, licencijų kaina auga kartu su komanda arba sistema formaliai veikia, tačiau darbuotojai toliau dirba senuoju būdu.
Todėl prieš pirmą pokalbį su tiekėjais reikėtų atlikti dalį darbo įmonės viduje. Dažniausiai būtent šis pasiruošimas ir padeda suprasti, ar reikalingas rinkos produktas, individualiai kuriama sistema, ar abiejų modelių derinys.
Klausimas dažnai suformuluojamas per siaurai
Formuluotė „standartinė ar individuali sistema“ reiškia, kad visas sprendimas turi būti pasirinktas iš dviejų priešingų variantų. Praktikoje geriausiai dažnai veikia mišrus modelis: standartiniai procesai paliekami rinkos produktams, o unikali verslo logika kuriama atskirai.
Kur kas naudingiau užduoti kitą klausimą:
Kurios mūsų veiklos dalys yra unikalios, o kurios veikia panašiai kaip daugelyje kitų įmonių?
Didžioji dalis procesų nėra tai, kuo įmonės konkuruoja. Buhalterija, darbo užmokestis, dokumentų apskaita ar el. pašto rinkodara daugelyje organizacijų veikia panašiais principais. Individualiai kurti tokius sprendimus retai apsimoka, nes įmonė moka už tai, ką rinka jau yra išsprendusi ir nuolat tobulina.
Kita situacija atsiranda tada, kai kainodara priklauso nuo daugybės tarpusavyje susijusių sąlygų, gamybos planavimas remiasi išskirtinėmis taisyklėmis arba klientų aptarnavimo greitis yra vienas pagrindinių konkurencinių pranašumų. Bandant tokį procesą sutalpinti į standartinį produktą, gali tekti atsisakyti būtent to, kas įmonę išskiria.
Procesus naudinga suskirstyti į dvi grupes:
Procesai, kurie įmonę išskiria. Juos pastebi klientai, konkurentai jų neturi arba atlieka prasčiau, o jų supaprastinimas iki rinkos standarto sumažintų kuriamą vertę.
Procesai, kurie tiesiog turi patikimai veikti. Klientai jų nemato, konkurencinio skirtumo jie nekuria, todėl svarbiausi kriterijai yra patikimumas, diegimo greitis ir pagrįsta kaina.
Antroji grupė paprastai sudaro didžiąją įmonės veiklos dalį. Būtent jai pirmiausia reikėtų ieškoti rinkoje jau esančių produktų.
Septyni kriterijai, padedantys priimti sprendimą
Suskirsčius procesus, pasirinkimą galima vertinti pagal konkrečius kriterijus.
1. Kiek reikės nukrypti nuo standarto
Praktinė taisyklė paprasta: kai rinkos produktas be papildomo programavimo patenkina didžiąją dalį poreikių, jis dažniausiai yra tinkamas pasirinkimas.
Jei sprendimas atitinka maždaug pusę ar du trečdalius reikalavimų, reikia įvertinti, ar likusi dalis iš tiesų būtina. Kartais racionaliau pakeisti vidinį procesą, nei brangiai modifikuoti sistemą.
Kai standartinis produktas neatitinka net pusės svarbiausių poreikių, individualiai kuriamas sprendimas gali būti ne tik lankstesnis, bet ir stabilesnis ilgalaikėje perspektyvoje.
Kiekviena gilesnė standartinės sistemos modifikacija didina atnaujinimų riziką. Trečdaliu perdaryta sistema po kelerių metų gali būti praktiškai nebeatnaujinama, nes nauja versija sugadintų individualius pakeitimus.
2. Kaip dažnai keičiasi procesas
Jei veikimo modelis keičiasi kelis kartus per metus dėl teisės aktų, rinkos sąlygų ar verslo plėtros, svarbu iš anksto įvertinti, kaip bus atliekami būsimi pakeitimai.
Naudojant standartinę sistemą, įmonė priklausys nuo tiekėjo prioritetų ir produkto vystymo plano. Individualiai sukurtoje sistemoje pakeitimą galima užsakyti tada, kai jo reikia, tačiau kiekvienas toks darbas turės atskirą kainą.
Svarbu ne tik tai, ar sistema šiandien atitinka procesą, bet ir tai, kaip lengvai ji prisitaikys po dvejų ar penkerių metų.
3. Kiek reikės integracijų
Reikėtų suskaičiuoti visas sistemas, su kuriomis naujasis sprendimas turės keistis duomenimis: buhalteriją, elektroninę parduotuvę, sandėlį, logistikos partnerius, bankus, valstybės registrus ar kitus vidinius įrankius.
Kai integracijų daugiau, tampa svarbu patikrinti, ar produktas turi atvirą programavimo sąsają ir paruoštas jungtis su konkrečiomis įmonėje naudojamomis sistemomis.
Nemažai įmonių tik po pirkimo sužino, kad integracija su jų buhalterine programa kainuoja beveik tiek pat, kiek pats produktas.
4. Kiek bus vartotojų
Standartinės sistemos dažnai apmokestinamos už kiekvieną vartotoją per mėnesį. Toks modelis patogus nedidelei komandai, tačiau augant vartotojų skaičiui metinė kaina gali tapti reikšminga.
Licencijų sąnaudas reikėtų skaičiuoti ne pagal dabartinį darbuotojų skaičių, o pagal realų augimo scenarijų po trejų ar penkerių metų. Lūžio taškas tarp licencijuojamo produkto ir individualios sistemos kartais pasiekiamas gerokai anksčiau, nei atrodo iš pradinio pasiūlymo.
5. Ar sektorius turi specifinių reikalavimų
Medicinoje, finansuose, viešajame sektoriuje ir kitose srityse, kuriose tvarkomi jautrūs duomenys, gali būti taikomi papildomi reikalavimai duomenų laikymo vietai, prieigos kontrolei, auditui ar pakeitimų istorijai.
Tokie kriterijai dalį rinkos produktų gali atmesti dar prieš demonstracijas. Juos geriausia patikrinti pačioje atrankos pradžioje, kad nebūtų gaištamas laikas sprendimams, kurių įmonė vis tiek negalės naudoti.
6. Kas sistemą prižiūrės
Individualiai kuriama sistema yra ilgalaikis įsipareigojimas. Kažkas turės prižiūrėti infrastruktūrą, atnaujinti naudojamas technologijas, reaguoti į gedimus, taisyti klaidas ir planuoti tolimesnį vystymą.
Jei įmonė neturi vidinės IT kompetencijos, reikia iš anksto numatyti priežiūros partnerį ir biudžetą. Priešingu atveju po kelerių metų nuosava sistema gali tapti ne konkurenciniu pranašumu, o rizikos šaltiniu.
7. Kaip greitai reikia rezultato
Rinkos produktą dažniausiai galima pradėti naudoti per kelias savaites ar mėnesius. Individualios sistemos kūrimas užtrunka gerokai ilgiau, ypač kai reikia analizės, integracijų ir duomenų perkėlimo.
Jei problema verslą riboja jau dabar, diegimo greitis gali būti svarus argumentas standartinio produkto naudai. Tačiau reikia suprasti, kad greitas paleidimas dažniausiai reiškia didesnį įmonės procesų pritaikymą prie sistemos galimybių.
Kaip teisingai palyginti kainą
Dažniausia klaida – lyginti standartinės sistemos mėnesinį mokestį su individualaus projekto kūrimo sąmata. Tai skirtingo pobūdžio išlaidos.
Palyginimą reikėtų atlikti bent penkerių metų laikotarpiui ir įtraukti ne tik pradinę kainą.
Standartinės sistemos sąnaudos:
licencijos, įvertinus vartotojų skaičiaus augimą ir galimą kainų indeksavimą;
diegimas ir konfigūravimas;
integracijos su kitomis sistemomis;
duomenų perkėlimas;
darbuotojų mokymai;
individualios modifikacijos;
papildomi moduliai, neįtraukti į pradinį pasiūlymą.
Individualiai kuriamos sistemos sąnaudos:
analizė ir kūrimo darbai;
serveriai arba debesijos paslaugos;
priežiūra ir klaidų taisymas;
tolimesnis vystymas;
duomenų perkėlimas;
darbuotojų mokymai;
rezervas neapibrėžtumui ir projekto pokyčiams.
Prie abiejų variantų reikėtų pridėti eilutę, kuri dažnai apskritai nevertinama – pasitraukimo kainą.
Kiek kainuos atsisakyti sprendimo po penkerių metų? Ar duomenis bus galima eksportuoti suprantamu formatu? Ar sistemos logika dokumentuota? Kam priklausys programinis kodas? Ar kitai komandai bus įmanoma perimti priežiūrą?
Atsakymai į šiuos klausimus gali pakeisti iš pradžių patraukliausiai atrodžiusį pasirinkimą.
Hibridinis modelis
Praktikoje dažnai geriausiai veikia derinys, kuriame standartiniai procesai aptarnaujami rinkos produktais, o individualiai kuriama tik ta dalis, kuri iš tiesų yra savita.
Pavyzdžiui, buhalterija ir sandėlio apskaita gali veikti standartinėse programose, o klientų savitarna, kainodaros skaičiuoklė ar užsakymų paskirstymo logika sukuriamos atskirai ir integruojamos su likusia infrastruktūra.
Toks modelis leidžia neinvestuoti į tai, ką rinka jau išsprendė geriau, ir kartu išlaikyti įmonės konkurencinį pranašumą.
Pagrindinis jo sudėtingumas yra integracijos. Todėl iš anksto reikia aiškiai nuspręsti, kurioje sistemoje bus saugomi pagrindiniai duomenys apie klientą, prekę, kainą ir užsakymą.
Ko klausti tiekėjų
Kai vidinis pasiruošimas atliktas, keli konkretūs klausimai padeda atskirti realiai tinkamą pasiūlymą nuo gerai parengtos prezentacijos.
Standartinės sistemos tiekėjui:
Kurie poreikiai sprendžiami konfigūracija, o kuriems reikės programavimo?
Kas nutiks individualiems pakeitimams išleidus naują sistemos versiją?
Kokiu formatu galėsime eksportuoti visus duomenis?
Kaip keisis licencijų kaina ir kokia tvarka ji peržiūrima?
Ar galime pamatyti panašaus dydžio ir veiklos kliento sprendimą?
Individualaus sprendimo tiekėjui:
Kam priklausys programinis kodas ir intelektinė nuosavybė?
Kaip vyktų sistemos perdavimas kitai komandai?
Kokios technologijos bus naudojamos ir kiek specialistų jas išmano?
Kaip bus vertinami projekto metu atsiradę pakeitimai?
Kokios priežiūros sąlygos ir reagavimo terminai bus taikomi po paleidimo?
Šie klausimai naudingi ir kaip vidinis pasiruošimo testas. Jei įmonė negali paaiškinti, kiek vartotojų turės po kelerių metų ar su kokiomis sistemomis naujasis sprendimas turės keistis duomenimis, tikslų pasiūlymą parengti bus sunku bet kuriam tiekėjui.
Dažniausiai pasikartojančios klaidos
Sprendimas priimamas pagal funkcijų sąrašą
Ilgas funkcijų sąrašas prezentacijoje atrodo įtikinamai, tačiau kasdien dažniausiai naudojama nedidelė jų dalis.
Vertingiau patikrinti, kaip sistema atlieka penkis dažniausius įmonės veiksmus, nei skaičiuoti šimtus galimybių, kurių darbuotojai niekada neatidarys.
Neįtraukiami būsimi vartotojai
Sistemą dažnai renkasi vadovai, o kasdien su ja dirba vadybininkai, sandėlio darbuotojai, projektų vadovai ar buhalteriai.
Jei jų nuomonė ir darbo situacijos neįtraukiamos į pasirinkimą, žmonės dažnai susikuria alternatyvų procesą šalia naujosios sistemos. Dažniausiai tai būna dar vienas Excel failas.
Individualus sprendimas pradedamas be aiškių reikalavimų
Neapibrėžti reikalavimai yra viena pagrindinių priežasčių, kodėl projektai viršija biudžetą ir terminus.
Prieš pradedant kūrimą reikėtų turėti bent pagrindinę proceso schemą ir aiškų pirmosios versijos funkcionalumo sąrašą. Jei įmonė dar negali jo parengti, pirmiausia reikėtų užsakyti atskirą analizės etapą.
Vertinama tik pradžios kaina
Pigiai prasidedantis sprendimas nebūtinai bus pigus augant verslui. Licencijos, papildomi moduliai, integracijos ir pakeitimai per penkerius metus gali kainuoti daugiau nei didesnė pradinė investicija.
Sprendimą reikėtų priimti pagal bendrą nuosavybės kainą, o ne pagal pirmą sąskaitą.
Kaip organizuoti sprendimo priėmimą
Visą pasiruošimo ir atrankos procesą galima atlikti per keturias–šešias savaites.
Procesų sąrašas ir suskirstymas. Įvardykite, kurie procesai įmonę išskiria, o kurie tiesiog turi veikti patikimai. Įtraukite vadovus ir darbuotojus, kurie su šiais procesais dirba kasdien.
Reikalavimų dokumentas. Parenkite trumpą dokumentą, kuriame būtų aprašyta, ką sistema turi atlikti, su kuo integruotis, kiek turės vartotojų ir kokie apribojimai taikomi.
Rinkos peržiūra. Atrinkite kelis realiausiai tinkamus rinkos produktus ir kelis individualių sprendimų partnerius. Per didelis kandidatų skaičius dažniausiai tik apsunkina palyginimą.
Demonstracijos pagal jūsų scenarijus. Pateikite tiekėjams kelias konkrečias situacijas iš savo veiklos ir paprašykite parodyti, kaip jos sprendžiamos sistemoje.
Penkerių metų kainos skaičiavimas. Įvertinkite pradines, nuolatines, augimo ir pasitraukimo sąnaudas.
Sprendimo pagrindimas raštu. Trumpai užfiksuokite pasirinkimo prielaidas, vertintus variantus ir priežastis. Po kelerių metų šis dokumentas padės suprasti, kodėl buvo pasirinktas būtent toks kelias.
Didžiausią įtaką rezultatui dažniausiai turi ne tai, ar pasirinkta standartinė, ar individuali sistema. Kur kas svarbiau, ar prieš pasirinkimą buvo aiškiai suprasta, kokią problemą sistema turi išspręsti.