Šis straipsnis skirtas…
• IT vadovams, kurie svarsto naujos verslo valdymo sistemos (ERP) diegimą ir rengia jos poreikio bei investicijų pagrindimą.
• Verslo vadovams, kurie siekia geriau suprasti tikrąją investicijų apimtį, reikalingą ERP sistemos diegimui.
Šis straipsnis padės jums...
• Užtikrinčiau įvertinti planuojamos diegti verslo sistemos kaštus.
• Nustatyti veiksmus, reikalingus parengti realistišką ERP sistemos investicijų sąmatą.
• Aiškiai įvardyti informaciją, reikalingą atsakyti į klausimus apie ERP sistemos kainą, ir pagrįsti pateiktus vertinimus.
Dažnai pasitaikanti situacija: paprastas pavyzdys
Vienas mano draugų valdo palyginti nedidelę plytelių prekybos ir montavimo įmonę Ontarijuje, Kanadoje. Nusprendęs perkelti savo atsargas ir veiklą į naują sandėlį, jis pradėjo svarstyti apie kai kurių procesų automatizavimą ir paklausė manęs, kiek kainuotų tam tinkama programinė įranga.
Kadangi gerai pažinojau jo verslą, gana aiškiai supratau, kuriuos procesus būtų galima automatizuoti, ir jau buvau numatęs, kad sandėlio valdymui galėtų tikti „Odoo Inventory“. Tačiau net ir turėdamas šių žinių negalėjau lengvai pateikti tiesaus atsakymo į, atrodytų, visai pagrįstą jo klausimą. Tai buvo sudėtinga net ir tokio nedidelio projekto atveju, kuris greičiausiai apsiribotų tik sandėlio operacijų automatizavimu.
Jei būčiau gudrus pardavėjas, siekiantis sudominti klientą, galėčiau atsakyti: „Jums tai nieko nekainuos.“ Ir toks atsakymas nebūtų visiškai neteisingas. Juk viena internetinė „Odoo“ programa, pavyzdžiui, atsargų valdymo modulis, iš tiesų yra nemokama. Be to, joje jau yra mobiliojo brūkšninių kodų nuskaitymo funkcija, kurią už nedidelę papildomą kainą galima dar labiau išplėsti naudojant „Ventor“ programėlę.
O mano draugas juk klausė tik apie programinės įrangos kainą. Tad kodėl gi neatsakius: „0 €“?
Ką tai iš tiesų reiškia
Visų pirma, bet koks verslo valdymo sistemos diegimas ir naudojimas, ypač ERP, nėra vien tik programinės įrangos kaina. Taip vadinamos „bendrosios nuosavybės išlaidos“ (TCO – Total Cost of Ownership) apima diegimo darbus ir daugelį kitų aspektų, kaip aprašyta šiame straipsnyje. Todėl savo draugui pateikti 0 € kaip automatizavimo kainą, prieš tai neįsigilinus į tai, kad jo klausimas iš esmės yra netiksliai suformuluotas, būtų iš esmės klaidinantis atsakymas.
Pavyzdžiui, esu matęs SAP pasiūlymą didelei įmonei, kuriame buvo daugiau nei 1000 SKU per 30 ir daugiau puslapių. Kai dar nežinai, kokius ERP tiekėjus apskritai gali rinktis, visiškai neįmanoma pradėti sąmatos nuo „programinės įrangos kaštų“. Kur kas tikslingiau yra vertinti „šalutines“ diegimo išlaidas, kurios dažniausiai gerokai viršija pačios programinės įrangos prenumeratą. Tokios papildomos išlaidos dažnai yra nuvertinamos arba visiškai ignoruojamos.
Antra, dar tik svarstant ERP ar bet kurią kitą sistemą, kuri turėtų automatizuoti ir valdyti verslo procesus bei jų vykdymą, šių procesų apimtis ir pobūdis dažnai yra migloti, todėl tampa sunku įvertinti tiek funkcines, tiek technines galimybes. Tai galiausiai apsunkina investicijų kaštų įvertinimą bet kokiu pakankamu tikslumu.
Žemiau pateiktas paveikslas yra skirtas vizualiai parodyti ERP kelionę investicijų vertinimo tikslumo perspektyvoje. Nors jame nėra siekiama remtis statistiškai pagrįstais ar griežtais skaičiais, diagrama rodo, kad konkretaus ERP diegimo kaštų žinojimas yra laipsniškas, iteracinis procesas: jis gali prasidėti nuo visiško neapibrėžtumo (0 % tikslumo) ir tik projekto pabaigoje pasiekti 100 % tikslumą.
Sutartis galutinai užbaigiama „sutarties pasirašymo“ etape, tačiau faktinio diegimo metu vis tiek gali atsirasti netikėtų pokyčių. Būtent dėl to gera projektų valdymo praktika numato tam tikrą nenumatytų išlaidų rezervą (paprastai apie 10 % viso ERP diegimo biudžeto), skirtą nenumatytiems trikdžiams padengti. Tai atsispindi ir pateiktoje diagramoje. Gerai įgyvendinti ankstesni etapai sumažina netikėtumus, o tai leidžia tiksliau sudaryti biudžetą ir padeda išvengti vadinamojo „apimties plėtimosi“ (scope creep), kuris yra dažna ERP diegimo projektų problema ir gali padidinti kaštus net virš 10 % rezervo ribos (neretai – 50 % ir daugiau).
Šis apimties plėtimosi reiškinys atsiranda tada, kai projekto rezultatai, kurie iš pradžių buvo apibrėžti planavimo etape, ima plėstis už pradinio apibrėžimo ribų. Viena pagrindinių priežasčių yra nepakankamas pradinių reikalavimų surinkimas. Kai projekto suinteresuotosios šalys nepakankamai aiškiai įvardija savo poreikius arba nenumato būsimų pokyčių, projekto apimtis gali neapimti visų realių poreikių. Taip pat nepakankamas suinteresuotųjų šalių įsitraukimas ir komunikacija gali sukelti nesusipratimų arba neįgyvendintų lūkesčių, dėl ko vėliau atsiranda papildomi apimties pakeitimai jau projekto eigoje. Todėl, jei esate „nauji Odoo“ (kaip parodyta aukščiau) ir išgirstate „tai kainuos 10 €“, nereikėtų iš karto šokti į diegimą – tie „10 €“ labai greitai gali virsti 50 000 € ar daugiau.
Mano draugo situacijoje akivaizdžiausia apimties plėtimosi (scope creep) rizika buvo susijusi su sandėlio aprūpinimu užsakymais, kuris tuo metu buvo vykdomas spausdinant popierines formas iš specialiai sukurto, su integracinėmis sąsajomis nesujungto vidinio sprendimo. Reikėjo išnagrinėti galimas alternatyvas. Pavyzdžiui, ar toliau likti prie rankinio duomenų suvedimo iš tų pačių popierinių dokumentų? Ar sukurti integracines sąsajas su esama vidine sistema? Ar svarstyti galimybę tą užsakymų valdymo sistemą visiškai pakeisti, pavyzdžiui, kitu „Odoo“ moduliu? Nors šie klausimai yra techninio pobūdžio, juos reikia spręsti kartu su ne techniniais suinteresuotaisiais asmenimis, kurie geriausiai išmano dabartinę proceso vykdymo būklę, naudojant šią sistemą ir kitus susijusius sprendimus.
Kaštų vertinimo iteracinį pobūdį atspindi dar vienas dažnas veiksnys, prisidedantis prie apimties plėtimosi – technologijų dinamiškumas. Kaip ir minėtame paprastame pavyzdyje, ERP sistemos dažnai reikalauja integracijos su įvairiomis esamomis sistemomis, duomenų migracijos ir pritaikymo prie organizacijos procesų. Tobulėjant technologijoms atsiranda naujų funkcionalumų ir galimybių, kurios vilioja suinteresuotąsias šalis įtraukti papildomas funkcijas į projekto apimtį, taip plečiant projekto ribas. Potraukis „saldžioms ir blizgioms“ naujovėms gali tapti nesveikas, todėl jį reikėtų suvaldyti ir suderinti su projekto tikslais, nustatytais pačioje kelionės pradžioje. Priešingu atveju prieštaringi ketinimai gali sukelti konkuruojančius prioritetus ir nesuderintas darbotvarkes, dar labiau apsunkindami projekto apimties valdymą ir išteklių paskirstymą, o tai lemia vėlavimus ir biudžeto viršijimus.
Tęsiant mano draugo verslo operacijų pavyzdį, vienas pagrindinių jo tikslų buvo pašalinti komplektavimo klaidas, kurios turėjo stiprų neigiamą „grandininį efektą“ montuotojams, gaunantiems iš sandėlio išsiųstą produkciją. Brūkšninių kodų naudojimas ir skenavimas turėjo didelį potencialą sumažinti tokias klaidas, tačiau tam gali prireikti specialios įrangos. „Gali“ – nes „Odoo“ brūkšninių kodų modulis (įtrauktas į atsargų valdymą) arba patobulinta trečiųjų šalių „Ventor“ programėlė gali puikiai veikti ir būti naudojama įprastame išmaniajame telefone, prijungtame prie mobiliojo ryšio tinklo (t. y. LTE), o tai reiškia, kad infrastruktūros ar įrangos investicijos nebūtinos, jei sandėlio darbuotojai sutinka tam naudoti savo asmeninius telefonus. Tačiau tokio sprendimo patogumas (pvz., telefono laikymas judant po sandėlį), galimybės (pvz., veikimo nuotolis) ir patikimumas (pvz., ryšys) greičiausiai būtų abejotini, todėl kiltų rizika pakenkti pačiam tikslui – padidinti sandėlio operacijų efektyvumą ir tikslumą. Todėl, planuojant sandėlio IT infrastruktūros pritaikymą (t. y. patikimo „Wi-Fi“ ryšio įdiegimą) bei brūkšninių kodų skenavimo, spausdinimo ir kitos įrangos diegimą, mano draugo atveju viso projekto kaštus įvertinau iki 15 000 €. Tai gana didelis šuolis nuo teorinių 0 €. Tačiau kalbant apie kompiuterinę įrangą ir jos palaikymo sutartis, „lubų“ praktiškai nėra, todėl svarbu nepasiduoti nereikalingiems „blizgučiams“, bet kartu ir per daug nepaieškoti pigiausių sprendimų, nes vėliau biudžetą gali „sugriauti“ įrangos pakeitimai dėl apimties plėtimosi.
Kokie galimi sprendimai
Galiausiai šį mažą projektą savo draugui (kurio įprastai net nebūtų galima vadinti „ERP“) įvertinau kaip pirmųjų metų kaštus (įskaitant diegimą) nuo 8 000 iki 40 000 eurų, o antrųjų metų (ir vėlesnius) – nuo 2 000 iki 5 000 eurų. Šis „patirtinis spėjimas“ atitiktų apie 20 % tikslumą aukščiau pateiktoje ERP investicijų vertinimo diagramoje, kas praktiškai reikštų maždaug 27 000 ± 80 %. Tikslumas nėra didelis, bet tai jau pradžia ir geresnė pozicija nei visiškas neapibrėžtumas.
Kitas etapas – „vadovaujamas įvertinimas“ – siekia reikšmingai pagerinti biudžeto tikslumą (iki maždaug 50 %), kad jis taptų tinkamas projekto pagrindimui ir prasmingiems ROI skaičiavimams. Šis etapas atliekamas patyrusio specialisto, taikant tam tikrą metodiką ir vengiant intensyvaus ERP tiekėjų įtraukimo su pasiūlymais, demonstracijomis ar detalių reikalavimų rinkimu. Vietoje to, kad būtų lyginami tiekėjų pasiūlymai dar nežinomiems poreikiams, vertinami šie aspektai, padedantys suprasti sprendimo pobūdį, tikėtiną tiekėjų ekosistemą (t. y. produkto lygį), aukšto lygio architektūrą ir, atitinkamai, diegimo apimtį bei tikslesnius kaštus:
- pramonės specifika, įskaitant pagrindines funkcines galimybes, vaidmenų profilius, rizikos toleranciją ir reguliacinę aplinką;
- įmonės dydis ir sudėtingumas bei augimo planai, kurie lemia licencijų skaičių ir pageidaujamą produkto lygį;
- organizaciniai veiksniai, svarbūs sėkmingam diegimui, tokie kaip pokyčių kultūra, projektų valdymo biuro (PMO) pajėgumai, verslo procesų valdymo brandumas ir organizacijos sudėtingumas;
- IT brandumas, akcentuojant duomenų kokybę, taikomųjų sistemų aplinkos sudėtingumą ir darbuotojų patirtį su panašiomis iniciatyvomis.
Nors šis sąrašas mažam verslui, tokiam kaip mano draugo, gali atrodyti gana sudėtingas, šie ERP sprendimo vertinimo ir apibrėžimo principai vis tiek yra taikomi net ir labai mažoms įmonėms. Iš tiesų, mano draugo situacijoje esamas ir numatomas augimas gali tapti lemiamu veiksniu renkantis tarp vidinės sistemos tolesnio vystymo arba jos pakeitimo standartiniu („off-the-shelf“) sprendimu. Vien tik turto nuosavybė gali reikšmingai paveikti sprendimą dėl IT infrastruktūros atnaujinimo, o sandėlio automatizavimo perspektyva gali būti tik šio sprendimo katalizatorius. Darbuotojų prieinamumas ir patirtis su panašiais projektais taip pat turėtų lemti poreikį samdyti papildomus resursus – tiek sandėlio operacijoms, tiek projekto užduotims vykdyti. Ir visa tai, žinoma, tiesiogiai daro įtaką kaštams.
„Vadovaujamo įvertinimo“ etapo pabaigoje kaštai gali būti suskirstyti į šias bendras kategorijas, remiantis ne konkrečių ERP tiekėjų pasiūlymais, o panašių projektų patirtimi toje pačioje pramonėje ir pagal panašius organizacinius parametrus:
Prenumeratos kaštai
- pagrindinės licencijos ir papildomos funkcijos
- palaikymas
Diegimo (projekto) kaštai
- strategija ir tiekėjo / sprendimo pasirinkimas
- konfigūravimas ir pritaikymas
- procesų perprojektavimas
- duomenų migracija
- integracijos
- mokymai ir pokyčių valdymas
- projektų valdymas
- projekto rezervas (nenumatytiems atvejams)
Šių kategorijų aprašymas (taip pat ERP diegimo etapų ir veiklų, tokių kaip RFI/RFP, aptarimas) išeina už šio straipsnio ribų, tačiau gera pradžia yra šis ERP TCO straipsnis, o tie, kurie ypač domisi „Odoo“ kainodara, turėtų perskaityti „The True Cost of Odoo ERP: Pricing and Ownership Insights“.
Apibendrinant
Licencijavimo kaštų įvertinimas „pagrindimo“ etape nėra ir negali būti tikslus, o svarstant ERP dar tik pradiniame etape – jis būna dar mažiau tikslus. Tačiau vien programinės įrangos kaštai bet kuriuo atveju nėra didžiausia ERP projekto išlaidų dalis. Todėl verta sutelkti dėmesį į tai, kad būtų aiškiai suprasti organizaciniai veiksniai ir jų įtaka galimoms išlaidoms. Tokia strategija leidžia išvengti varginančios, daug darbo reikalaujančios ir potencialiai klaidinančios programinės įrangos kainų analizės, o vietoje to suteikia realistišką supratimą apie tikrąją investicijų apimtį, pakankamą aukšto lygio sprendimams priimti.
Sunku teisingai įvertinti ERP diegimo kaštus? Mes esame pasiruošę padėti!
Teksto autorius:
Gleb Lisikh
Info-Tech Research Group tyrimų ir konsultacijų direktorius