Dažniausiai užduodami klausimai apie programavimo projektus

Renkantis programavimo įmonę svarbu vertinti ne tik naudojamas technologijas, atliktų projektų skaičių ar valandinį įkainį. Patikimas partneris turėtų gebėti suprasti jūsų verslo procesus, įvardyti projekto rizikas, pasiūlyti realistišką įgyvendinimo planą ir paaiškinti, kodėl rekomenduoja vieną ar kitą sprendimą.

Prieš priimant sprendimą verta išsiaiškinti:

• kas bus atsakingas už projekto valdymą;

• kaip vyks verslo poreikių analizė;

• kaip bus atliekamas testavimas;

• kaip bus valdomi pakeitimai;

• kas prižiūrės sistemą po jos paleidimo;

• kam priklausys programinis kodas ir techninės prieigos.

Svarbu ir tai, kaip programavimo įmonė elgiasi tada, kai jūsų pradinė idėja nėra optimalus sprendimas. Geras technologinis partneris neturėtų tik vykdyti užduoties – jis turėtų padėti priimti geresnį sprendimą.

Vien galutinės kainos palyginti neužtenka, nes skirtinguose pasiūlymuose dažnai būna numatyta nevienoda darbų apimtis.

Viena įmonė į kainą gali įtraukti analizę, dizainą, projektų valdymą, testavimą, paleidimą ir garantinį laikotarpį, o kita – tik programavimo darbus.

Lyginant pasiūlymus reikėtų patikrinti:

• kas tiksliai įtraukta į kainą;

• kokiomis prielaidomis remtasi;

• kokie darbai nėra įtraukti;

• kaip vertinamos integracijos;

• ar įtrauktas duomenų perkėlimas;

• ar numatytas testavimas;

• kaip bus valdomi nauji pageidavimai;

• kas vyks po sistemos paleidimo.

Pigiau atrodantis pasiūlymas nebūtinai bus pigesnis galutiniame rezultate.

Individualus programuotojas gali būti tinkamas mažesnėms užduotims, konkrečiam funkcionalumui ar aiškiai apibrėžtam techniniam darbui.

Didesniam verslo projektui dažniausiai reikia daugiau skirtingų kompetencijų:

• verslo analizės;

• projektų valdymo;

• naudotojų patirties ir dizaino;

• programavimo;

• testavimo;

• infrastruktūros ir saugumo;

• tolimesnės sistemos priežiūros.

Programavimo įmonė taip pat gali užtikrinti didesnį darbų tęstinumą, nes projekto žinios ir atsakomybė nėra sutelktos vieno žmogaus rankose.

Mažiausia pradinė kaina nebūtinai reiškia mažiausią galutinę projekto kainą.

Per mažai laiko skyrus analizei, architektūrai ar testavimui, vėliau gali tekti taisyti netinkamai priimtus sprendimus, perdaryti funkcionalumą arba spręsti sistemos stabilumo problemas.

Vertėtų žiūrėti ne tik į tai, kiek kainuos sukurti pirmąją versiją, bet ir į tai:

• kiek kainuos sistemą prižiūrėti;

• ar ją bus galima plėsti;

• ar įmonė liks priklausoma nuo vieno tiekėjo;

• ar pasirinkta technologija bus tinkama po kelių metų;

• kiek kainuos klaidos arba sistemos neveikimas.

Programavimo projektą geriausia pradėti ne nuo funkcijų sąrašo, o nuo problemos, kurią norite išspręsti.

Pirmiausia reikėtų aiškiai suprasti:

• kas šiuo metu neveikia;

• kur įmonė praranda daugiausia laiko;

• kur dažniausiai atsiranda klaidų;

• kas naudosis būsima sistema;

• kokį rezultatą ji turėtų sukurti;

• kaip bus matuojama projekto nauda.

Tik tada galima spręsti, ar reikia individualios sistemos, standartinio įrankio, integracijos, proceso pakeitimo ar gerokai paprastesnio sprendimo.

Pilnai parengta techninė užduotis nėra būtina.

Į programavimo įmonę galima kreiptis turint:

• verslo problemą;

• pirminę idėją;

• dabartinio proceso aprašymą;

• funkcijų sąrašą;

• sistemos pavyzdį;

• norimą rezultatą.

Techniniai reikalavimai gali būti parengti analizės ir planavimo metu. Tačiau prieš pradedant didesnės apimties programavimo darbus turi būti pakankamai aiškiai sutarta, ką kuriame, kam kuriame ir kaip vertinsime rezultatą.

Analizės metu nagrinėjami verslo procesai, naudotojų poreikiai, esamos sistemos, integracijos, duomenys ir projekto apribojimai.

Jos tikslas nėra sukurti kuo ilgesnį dokumentą. Analizė turi padėti sumažinti neaiškumą prieš priimant brangius techninius sprendimus.

Po analizės turėtų būti aiškesni:

• projekto tikslai;

• pagrindiniai naudotojai;

• svarbiausi procesai;

• pirmosios versijos apimtis;

• prioritetai;

• integracijos;

• preliminarus biudžetas;

• įgyvendinimo etapai;

• pagrindinės rizikos.

Individuali sistema dažniausiai verta investicijos, kai įmonės procesai yra specifiniai, standartinės programos reikalauja daug kompromisų arba reikia sujungti kelias skirtingas sistemas į vieną veikiančią visumą.

Individualus sprendimas gali būti pagrįstas, kai:

• standartinė sistema neprisitaiko prie pagrindinio verslo proceso;

• darbuotojai daug veiksmų atlieka rankiniu būdu;

• duomenys išskaidyti keliose sistemose ir lentelėse;

• klientams ar partneriams reikia individualios savitarnos;

• technologija gali suteikti konkurencinį pranašumą;

• verslas auga, tačiau kartu neproporcingai didėja administracinis darbas.

Jeigu rinkoje jau egzistuoja tinkamas standartinis sprendimas, dažnai racionaliau pirmiausia išbandyti jį.

Standartinė sistema dažniausiai tinkamesnė, kai verslo procesas yra įprastas, o įmonė gali prisitaikyti prie programos veikimo logikos.

Individuali sistema prasmingesnė, kai:

• procesas yra specifinis;

• reikia nestandartinės kainodaros;

• reikia kelių sudėtingų integracijų;

• sistemoje dirbs skirtingi naudotojų tipai;

• būtina automatizuoti įmonei unikalią veiklos dalį;

• standartinė programa sukuria daugiau apribojimų nei naudos.

Dažnai geriausias sprendimas yra mišrus: naudojamos standartinės sistemos, o individualiai kuriamos tik tos dalys, kurios įmonei suteikia didžiausią vertę.

Taip. MVP yra pirmoji sistemos versija, kurioje įgyvendinamas svarbiausias funkcionalumas, reikalingas realiai problemai išspręsti ir sprendimui išbandyti.

Svarbu, kad MVP nebūtų tiesiog nekokybiška ar labai apribota galutinės sistemos versija. Jis turi turėti:

• aiškią paskirtį;

• konkrečią naudotojų grupę;

• vieną svarbiausią sprendžiamą problemą;

• kriterijus, pagal kuriuos bus vertinama jo nauda;

• techninį pagrindą tolimesnei plėtrai.

Sistemų integracijos kaina gali prasidėti nuo 300–500 eurų, jeigu reikia įdiegti standartinį modulį, prijungti jau paruoštą paslaugą ar atlikti nedidelį techninį pritaikymą.

Tokių darbų pavyzdžiai:

• mokėjimų modulio įdiegimas;

• siuntų tarnybos įskiepio prijungimas;

• naujienlaiškių sistemos integracija;

• užklausos perdavimas į CRM;

• standartinio dokumentų pasirašymo modulio prijungimas;

• duomenų eksportas į apskaitos sistemai tinkamą failą.

Paprastesnė individuali integracija dažniausiai kainuoja nuo 1 500 iki 6 000 eurų. Tai gali būti užsakymų, klientų, sąskaitų, prekių likučių ar mokėjimų perdavimas tarp dviejų sistemų.

Sudėtingesnė ERP, CRM, apskaitos, sandėlio ar kelių platformų integracija gali kainuoti nuo 6 000 iki 25 000 eurų ar daugiau.

Kaina didėja, kai duomenys perduodami abiem kryptimis, reikia sudėtingų verslo taisyklių, klaidų valdymo, nuolatinės sinchronizacijos ar kelių sistemų sujungimo.

Nedidelės individualios formos ar paprasto automatizavimo kaina gali prasidėti nuo 500–1 500 eurų.

Tai gali būti:

• nestandartinė užklausos forma;

• automatinis duomenų išsiuntimas atsakingam darbuotojui;

• registracijos patvirtinimas;

• PDF dokumento sugeneravimas;

• informacijos perdavimas į CRM;

• automatinis laiško arba pasiūlymo paruošimas;

• vidinė dokumento tvirtinimo forma.

Jeigu forma turi daugiau žingsnių, prisijungimą, administravimo aplinką, sudėtingesnes sąlygas ar integracijas, projekto kaina dažniausiai siekia nuo 2 000 iki 10 000 eurų.

Paprastos internetinės skaičiuoklės kaina dažniausiai prasideda nuo 1 000–2 000 eurų.

Pavyzdžiui, tai gali būti:

• paslaugos kainos skaičiuoklė;

• paskolos arba įmokos skaičiuoklė;

• preliminaraus sutaupymo skaičiavimas;

• produkto kiekio apskaičiavimas;

• projekto biudžeto skaičiuoklė;

• draudimo ar paslaugų plano parinkimas.

Jeigu skaičiuoklėje naudojama daugiau verslo taisyklių, individuali kainodara, produktų duomenys, PDF pasiūlymų generavimas ar CRM integracija, kaina gali siekti nuo 5 000 iki 20 000 eurų.

Sudėtingi produktų konfigūratoriai, pagal daugybę parametrų parenkantys tinkamą sprendimą, skaičiuojantys kainą ir ruošiantys pasiūlymą, gali kainuoti nuo 20 000 iki 60 000 eurų ar daugiau.

Paprastos rezervacijų ar registracijos sistemos kaina gali prasidėti nuo 3 000–8 000 eurų, jeigu reikia paslaugų pasirinkimo, laisvų laikų kalendoriaus, registracijos ir pagrindinės administravimo aplinkos.

Sudėtingesnėje sistemoje gali būti:

• keli darbuotojai ar paslaugų teikėjai;

• skirtingos lokacijos;

• darbo grafikų valdymas;

• automatiniai el. laiškų ar SMS priminimai;

• išankstiniai mokėjimai;

• abonementai ir narystės;

• laukiančiųjų sąrašai;

• klientų prisijungimas;

• integracija su vidine įmonės sistema.

Tokios rezervacijų sistemos dažniausiai kainuoja nuo 10 000 iki 40 000 eurų. Didesnės rezervacijų platformos, aptarnaujančios kelis padalinius, partnerius ar skirtingas paslaugų grupes, gali kainuoti ir daugiau.

Paprastesnės elektroninės parduotuvės, kuriamos naudojant WooCommerce, Shopify ar kitą standartinę platformą, kaina gali prasidėti nuo 2 000–5 000 eurų.

Kaina priklauso nuo dizaino, prekių kiekio, atsiskaitymo būdų, pristatymo integracijų, kalbų ir reikalingų funkcijų.

Vidutinės apimties elektroninė parduotuvė su individualiu dizainu, papildomomis integracijomis ir nestandartinėmis funkcijomis dažniausiai kainuoja nuo 8 000 iki 25 000 eurų.

Individualus elektroninės prekybos sprendimas gali kainuoti nuo 25 000 iki 100 000 eurų ar daugiau, kai reikia:

• individualios kainodaros;

• sudėtingos prekių struktūros;

• produktų konfigūravimo;

• ERP ar sandėlio integracijos;

• kelių šalių arba rinkų;

• nestandartinio užsakymo proceso;

• skirtingų klientų grupių;

• didelio prekių ir užsakymų kiekio.

Nedidelio vidinio verslo įrankio kaina gali prasidėti nuo 3 000–5 000 eurų, jeigu jis skirtas vienai aiškiai užduočiai arba procesui.

Pavyzdžiui:

• užklausų registravimas;

• dokumentų tvirtinimas;

• darbų ar objektų sąrašas;

• klientų duomenų suvedimas;

• įrangos apskaita;

• paprastas užsakymų administravimas;

• darbuotojų užduočių paskirstymas;

• duomenų importas ir ataskaitų generavimas.

Jeigu įrankyje reikia kelių naudotojų vaidmenų, sudėtingesnių procesų, automatinių veiksmų ir integracijų, kaina dažniausiai siekia nuo 8 000 iki 25 000 eurų.

Paprastesnė užsakymų valdymo sistema gali kainuoti nuo 5 000 iki 15 000 eurų.

Tokioje sistemoje galima centralizuotai matyti:

• klientų užsakymus;

• užsakymo būseną;

• atsakingus darbuotojus;

• susijusius dokumentus;

• pristatymo informaciją;

• užsakymų istoriją.

Vidutinės apimties užsakymų valdymo sistema dažniausiai kainuoja nuo 15 000 iki 50 000 eurų. Joje užsakymai gali būti gaunami iš elektroninės parduotuvės, B2B portalo, el. pašto ar kitų sistemų.

Sudėtingesnė sistema, automatiškai tikrinanti kainas, likučius, kredito limitus, mokėjimus, generuojanti dokumentus ir perduodanti informaciją į apskaitą ar sandėlį, gali kainuoti nuo 50 000 iki 100 000 eurų ar daugiau.

Paprasto darbuotojų portalo kaina gali prasidėti nuo 5 000–10 000 eurų.

Jame darbuotojai gali prisijungti, matyti dokumentus, naujienas, darbo informaciją, pateikti prašymus ar užpildyti vidines formas.

Didesniame darbuotojų portale gali būti:

• atostogų ir kitų prašymų valdymas;

• dokumentų pasirašymas;

• darbo grafikų peržiūra;

• mokymų ir kvalifikacijų valdymas;

• užduotys;

• vidiniai pranešimai;

• integracijos su personalo ar apskaitos sistemomis.

Tokio portalo kaina dažniausiai siekia nuo 15 000 iki 50 000 eurų. Kelių šalių, įmonių ar darbuotojų grupių portalai gali kainuoti ir daugiau.

Paprastesnis partnerių ar tiekėjų portalas gali kainuoti nuo 8 000 iki 20 000 eurų.

Jame partneriai gali prisijungti, pateikti dokumentus, matyti užsakymus, gauti pranešimus, registruoti darbus ar peržiūrėti jiems skirtą informaciją.

Jeigu portale reikia paraiškų valdymo, užduočių, dokumentų pasirašymo, skirtingų partnerių vaidmenų, ataskaitų ir integracijų, projekto kaina dažniausiai siekia nuo 20 000 iki 60 000 eurų.

Sudėtingesnės partnerių platformos, apimančios pagrindinius bendradarbiavimo procesus, gali kainuoti nuo 60 000 iki 120 000 eurų ar daugiau.

Paprastos klientų savitarnos pirmoji versija gali kainuoti nuo 8 000 iki 20 000 eurų.

Pavyzdžiui, klientas gali:

• prisijungti prie savo paskyros;

• matyti sąskaitas ir dokumentus;

• peržiūrėti užsakymų istoriją;

• atnaujinti kontaktinius duomenis;

• pateikti užklausą;

• atsisiųsti sutartis ar kitą informaciją.

Vidutinės apimties klientų savitarnos portalas dažniausiai kainuoja nuo 20 000 iki 60 000 eurų. Jame gali būti mokėjimai, elektroninis pasirašymas, pranešimai, paslaugų užsakymas, skirtingi naudotojų vaidmenys ir integracijos su CRM, ERP ar apskaitos sistema.

Sudėtinga klientų savitarna, tampanti pagrindiniu klientų aptarnavimo kanalu, gali kainuoti nuo 60 000 iki 150 000 eurų ar daugiau.

Paprastesnio B2B užsakymų portalo kaina gali prasidėti nuo 10 000–20 000 eurų.

Jame verslo klientai gali prisijungti, matyti prekių katalogą, pateikti užsakymą ir peržiūrėti užsakymų istoriją.

Jeigu portalas integruojamas su verslo valdymo sistema, jame gali būti rodomos:

• individualios klientų kainos;

• prekių likučiai;

• užsakymo būsena;

• kredito limitas;

• sąskaitos ir dokumentai;

• ankstesni užsakymai.

Tokio B2B portalo kaina dažniausiai siekia nuo 25 000 iki 70 000 eurų.

Sudėtingos B2B prekybos platformos, turinčios dešimtis tūkstančių produktų, skirtingas kainodaros taisykles, kelių sandėlių likučius, užsakymų tvirtinimą, kelių šalių aptarnavimą ir daug integracijų, gali kainuoti nuo 70 000 iki 150 000 eurų ar daugiau.

Paprasta individuali CRM sistema gali kainuoti nuo 8 000 iki 20 000 eurų.

Joje gali būti valdoma:

• klientų informacija;

• kontaktai;

• pardavimo galimybės;

• užduotys;

• pokalbių ir veiksmų istorija;

• pagrindinės ataskaitos.

Jeigu reikia sudėtingo pardavimo proceso, individualių automatizacijų, pasiūlymų generavimo, teisių valdymo ir integracijų su kitomis sistemomis, kaina dažniausiai siekia nuo 20 000 iki 60 000 eurų.

Prieš kuriant individualią CRM sistemą verta patikrinti, ar įmonės poreikių negali patenkinti rinkoje esanti platforma su individualiais pritaikymais.

Paprasta dokumentų saugojimo, paieškos ar tvirtinimo sistema gali kainuoti nuo 5 000 iki 15 000 eurų.

Kaina didėja, kai reikia:

• dokumentų versijų;

• sudėtingo teisių valdymo;

• kelių tvirtinimo etapų;

• elektroninio pasirašymo;

• automatinių priminimų;

• dokumentų generavimo;

• integracijų su kitomis sistemomis;

• veiksmų audito istorijos.

Vidutinės apimties dokumentų valdymo sistema dažniausiai kainuoja nuo 15 000 iki 50 000 eurų, o sudėtingesni sprendimai gali kainuoti ir daugiau.

Paprastesnė individuali verslo valdymo sistema, skirta vienam konkrečiam procesui, gali kainuoti nuo 10 000 iki 30 000 eurų.

Pavyzdžiui, sistema gali būti skirta:

• užsakymų administravimui;

• darbų planavimui;

• objektų valdymui;

• nuomos procesui;

• dokumentų ruošimui;

• paslaugų teikimo valdymui;

• gamybos užduotims;

• vidiniams tvirtinimams.

Jeigu sistema apima kelis tarpusavyje susijusius procesus, turi daugiau naudotojų vaidmenų, ataskaitas, automatizacijas ir integracijas, jos kaina dažniausiai siekia nuo 30 000 iki 100 000 eurų.

Didesnė sistema, apimanti didelę įmonės veiklos dalį ir pakeičianti kelias iki tol naudotas programas, gali kainuoti nuo 100 000 iki 300 000 eurų ar daugiau. Tokie projektai paprastai įgyvendinami etapais.

Paprastesnio dirbtinio intelekto sprendimo kaina gali prasidėti nuo 3 000–8 000 eurų, jeigu naudojami esami DI modeliai ir sprendžiama viena aiški užduotis.

Pavyzdžiui:

• klientų klausimus atsakantis pokalbių asistentas;

• vidinė dokumentų paieška;

• tekstų ar atsakymų ruošimo įrankis;

• informacijos iš dokumentų ištraukimas;

• dokumentų klasifikavimas;

• gaunamų užklausų suskirstymas.

Kai DI sprendimas integruojamas su įmonės duomenimis, CRM, klientų savitarna ar kitomis verslo sistemomis, projekto kaina dažniausiai siekia nuo 10 000 iki 40 000 eurų.

Sudėtingesni DI agentai, kurie naudoja kelis duomenų šaltinius, atlieka veiksmus sistemose, turi teisių valdymą ir veikia svarbiuose verslo procesuose, gali kainuoti nuo 40 000 iki 100 000 eurų ar daugiau.

Nedidelės sistemos MVP gali kainuoti nuo 8 000 iki 20 000 eurų, jeigu pirmojoje versijoje sprendžiama viena aiški problema ir nėra daug sudėtingų integracijų.

Vidutinės apimties MVP, turintis kelis naudotojų tipus, administravimo aplinką, automatizacijas ir integracijas, dažniausiai kainuoja nuo 20 000 iki 50 000 eurų.

Sudėtingesnio produkto MVP gali kainuoti ir daugiau, jeigu jau pirmojoje versijoje būtini mokėjimai, sudėtingi skaičiavimai, didelis duomenų kiekis ar aukšti saugumo reikalavimai.

MVP tikslas nėra kuo pigiau sukurti mažą sistemą. Jo paskirtis – kuo anksčiau pradėti naudoti svarbiausią funkcionalumą ir tik tada investuoti į tolimesnę plėtrą.

Nedidelės ir techniškai tvarkingos sistemos perėmimas gali kainuoti nuo 1 000–3 000 eurų.

Jeigu prieš perimant reikia atlikti išsamesnį techninį auditą, įvertinti kodą, architektūrą, infrastruktūrą, saugumą ir technines rizikas, darbų kaina dažniausiai siekia nuo 3 000 iki 10 000 eurų.

Po audito gali būti planuojamas:

• klaidų taisymas;

• technologijų atnaujinimas;

• infrastruktūros sutvarkymas;

• sistemos greitaveikos gerinimas;

• saugumo spragų šalinimas;

• naujų funkcijų kūrimas;

• dalinis arba visiškas sistemos perrašymas.

Tolimesnė projekto kaina priklauso nuo realios sistemos būklės ir planuojamų pakeitimų.

Paprastos svetainės ar nedidelės sistemos techninė priežiūra gali prasidėti nuo 100–300 eurų per mėnesį.

Aktyviau naudojamos sistemos priežiūra dažniausiai kainuoja nuo 300 iki 1 500 eurų per mėnesį. Į paslaugą gali būti įtraukti atnaujinimai, stebėsena, atsarginės kopijos, smulkūs pakeitimai ir pagalba įvykus incidentui.

Verslui kritinės arba nuolat vystomos sistemos priežiūros biudžetas gali siekti nuo 1 500 iki 5 000 eurų per mėnesį ar daugiau.

Kainą lemia sistemos dydis, infrastruktūra, naudotojų skaičius, reikalingas reagavimo laikas, saugumo reikalavimai ir planuojamų tobulinimų apimtis.

Du sprendimai gali būti vadinami vienodai, tačiau jų apimtis gali skirtis kelis ar net keliolika kartų.

Pavyzdžiui, viena klientų savitarna gali tik parodyti sąskaitas ir dokumentus. Kita gali priimti mokėjimus, generuoti sutartis, valdyti kelias paslaugų grupes, aptarnauti skirtingus klientų tipus ir perduoti duomenis į kelias vidines sistemas.

Kainą dažniausiai lemia:

• naudotojų ir vaidmenų skaičius;

• verslo procesų sudėtingumas;

• integracijų kiekis;

• duomenų struktūra ir perkėlimas;

• automatizacijų kiekis;

• saugumo reikalavimai;

• individualus dizainas;

• administravimo funkcijos;

• sistemos naudojimo mastas;

• projekto neapibrėžtumas.

Todėl projekto kainą tiksliau nusako ne jo kategorija, o konkretus funkcionalumas ir procesai, kuriuos sistema turės aptarnauti.

Preliminarų biudžeto intervalą dažnai galima pateikti jau po pirmojo pokalbio.

Tikslesnei kainai reikia suprasti:

• pagrindinius naudotojus;

• verslo procesus;

• reikalingas funkcijas;

• integracijas;

• duomenų struktūrą;

• projekto ribas;

• saugumo ir infrastruktūros reikalavimus.

Mažesniems ir aiškiai apibrėžtiems darbams dažnai galima iš karto pateikti fiksuotą kainą. Didesni projektai gali būti skaidomi į analizės, dizaino, MVP ir tolimesnio vystymo etapus.

Atsakingas kainos pasiūlymas turėtų parodyti ne tik galutinę sumą, bet ir paaiškinti, kas į ją įtraukta, kokiomis prielaidomis remtasi ir kas galėtų pakeisti projekto biudžetą.

Fiksuota kaina tinkamiausia tada, kai projekto apimtis yra aiški ir mažai tikėtina, kad darbų metu keisis esminiai reikalavimai.

Valandinis apmokėjimas suteikia daugiau lankstumo, kai sprendimas kuriamas etapais ir dalis sprendimų priimama gavus realių naudotojų grįžtamąjį ryšį.

Didesniuose projektuose dažnai taikomas mišrus modelis:

• atskirai įvertinama analizė;

• sutariama dėl konkretaus pirmojo etapo;

• naujos idėjos ir pakeitimai vertinami pagal faktinę jų apimtį;

• tolimesnis vystymas planuojamas periodais.

Didžiausią sutaupymą dažniausiai sukuria ne pigesnė programuotojo valanda, o mažesnis nereikalingų darbų kiekis.

Projekto kainą galima sumažinti:

• pirmiausia kuriant svarbiausią funkcionalumą;

• naudojant standartinius sprendimus ten, kur nereikia individualaus programavimo;

• aiškiai paskiriant sprendimus priimantį žmogų;

• anksti išsigryninant pagrindines verslo taisykles;

• mažinant integracijų skaičių pirmojoje versijoje;

• projektą skaidant į savarankiškai vertę kuriančius etapus;

• iš anksto sutvarkant duomenis;

• greitai priimant sprendimus projekto metu.

Per daug sumažinus analizės, testavimo ar architektūros apimtį galima pasiekti priešingą rezultatą. Projektas iš pradžių atrodys pigesnis, tačiau vėliau daugiau kainuos jo taisymas ir plėtra.

Terminas priklauso nuo projekto apimties, integracijų, sprendimų priėmimo greičio ir kliento komandos įsitraukimo.

Nedidelė sistema ar pirmoji MVP versija gali būti sukurta per 1-2 mėnesius. Vidutinės apimties sistema dažniausiai kuriama kelis mėnesius, o didelės verslo platformos įgyvendinamos etapais ir vystomos ilgiau.

Patikimesnis būdas planuoti terminą yra suskaidyti projektą į aiškias dalis ir numatyti, kada verslas galės pradėti naudotis pirmąja vertę kuriančia versija.

Projektai dažniausiai vėluoja ne vien dėl programavimo darbų.

Terminą gali prailginti:

• neaiškūs arba besikeičiantys reikalavimai;

• lėtai priimami sprendimai;

• nepakankamas kliento komandos įsitraukimas;

• sudėtingesnės nei planuota integracijos;

• netvarkingi duomenys;

• priklausomybė nuo trečiųjų šalių;

• vėlai pastebėtos verslo proceso išimtys;

• dideli pakeitimai jau pradėjus kūrimą.

Todėl projekte svarbu ne tik nustatyti galutinę datą, bet ir aiškiai apibrėžti sprendimų priėmimo bei pakeitimų valdymo procesą.

Dažniausiai galima, jeigu esamos sistemos turi integracijoms skirtas sąsajas arba suteikia kitą saugų būdą keistis duomenimis.

Dažniausiai integruojamos:

• ERP sistemos;

• CRM sistemos;

• apskaitos programos;

• sandėlio valdymo sistemos;

• mokėjimų paslaugos;

• dokumentų pasirašymo platformos;

• elektroninės parduotuvės;

• siuntų ir logistikos sistemos;

• personalo valdymo sistemos;

• rinkodaros platformos.

Prieš planuojant integraciją reikia įvertinti ne tik technines galimybes, bet ir perduodamų duomenų kokybę, sistemos tiekėjo ribojimus bei atsakomybę už informacijos sinchronizavimą.

Taip. Ne kiekvienai problemai spręsti reikia kurti naują didelę sistemą.

Kartais pakanka:

• sujungti dvi naudojamas sistemas;

• automatizuoti duomenų perkėlimą;

• sukurti nedidelį vidinį įrankį;

• įdiegti dokumentų generavimą;

• automatizuoti pranešimus;

• pridėti vieną trūkstamą modulį;

• pakeisti rankiniu būdu atliekamą tvirtinimo procesą.

Dažnai racionaliausia pradėti nuo proceso vietos, kurioje prarandama daugiausia laiko arba atsiranda daugiausia klaidų.

Nauji poreikiai yra normali programavimo projekto dalis, tačiau jie turi būti aiškiai registruojami ir įvertinami.

Prieš įtraukiant pakeitimą reikėtų suprasti jo poveikį:

• biudžetui;

• terminui;

• sistemos architektūrai;

• jau sukurtam funkcionalumui;

• testavimo apimčiai;

• projekto prioritetams.

Svarbiausia atskirti pirminės apimties patikslinimą nuo naujos idėjos, kuri turėtų tapti kitu sistemos vystymo etapu.

Kokybė kuriama viso projekto metu, o ne tik tikrinant jau užbaigtą sistemą.

Tam reikalingi:

• aiškūs reikalavimai;

• programuotojų atliekamos kodo peržiūros;

• automatiniai testai;

• rankinis testavimas;

• atskira testavimo aplinka;

• naudotojų scenarijų patikrinimas;

• kliento atliekamas verslo logikos testavimas;

• stebėsena po paleidimo.

Sudėtingoje sistemoje neįmanoma atsakingai pažadėti, kad niekada nebus nė vienos klaidos. Profesionalus procesas turi padėti klaidas pastebėti kuo anksčiau, greitai jas ištaisyti ir sumažinti jų poveikį verslui.

Programavimo įmonė gali prisiimti atsakomybę už analizę, projektavimą ir techninį įgyvendinimą, tačiau ji negali pakeisti kliento turimų verslo žinių.

Projekto metu reikalingas žmogus arba nedidelė komanda, galinti:

• paaiškinti verslo procesus;

• atsakyti į klausimus;

• priimti sprendimus;

• nustatyti prioritetus;

• patikrinti realius veikimo scenarijus;

• patvirtinti sukurtą funkcionalumą.

Kai sprendimai kliento pusėje priimami greitai, projektas juda sklandžiau ir sumažėja rizika sukurti techniškai veikiančią, bet praktikoje nepatogią sistemą.

Programinio kodo nuosavybės, naudojimo ir perdavimo sąlygos turi būti aiškiai apibrėžtos sutartyje.

Joje taip pat turėtų būti numatyta:

• kas valdo infrastruktūrą;

• kam priklauso domenai;

• kas turi prieigą prie duomenų bazės;

• kam priklauso dizainas;

• kas valdo trečiųjų šalių paskyras;

• ar sistema gali būti perduota kitam tiekėjui;

• kokios licencijos naudojamos.

Dar prieš pradedant projektą verta įsitikinti, kad pasikeitus partneriui įmonė nepraras galimybės naudoti ar toliau vystyti savo sistemos.

Saugumo reikalavimai priklauso nuo sistemos paskirties, duomenų jautrumo ir galimo incidento poveikio.

Dažniausiai vertinami:

• naudotojų prisijungimai;

• prieigos teisės;

• duomenų šifravimas;

• veiksmų registravimas;

• atsarginės kopijos;

• infrastruktūros saugumas;

• programinės įrangos atnaujinimai;

• asmens duomenų apsauga;

• trečiųjų šalių paslaugos;

• reagavimo į incidentus procesas.

Verslui kritinėms sistemoms saugumas turi būti planuojamas nuo projekto pradžios, o ne pridedamas tik prieš paleidimą.

Taip, tačiau prieš perimant sistemą rekomenduojama atlikti techninį auditą.

Jo metu vertinama:

• programinis kodas;

• sistemos architektūra;

• naudojamos technologijos;

• dokumentacija;

• infrastruktūra;

• duomenų bazė;

• saugumas;

• integracijos;

• pagrindinės techninės rizikos;

• galimybė toliau plėsti sistemą.

Taip pat būtina patikrinti, ar įmonė turi visas reikalingas prieigas ir sutartines teises naudoti, keisti bei perduoti sistemą kitam tiekėjui.

Sistemos nereikėtų perrašyti vien todėl, kad jos kodas nėra idealus arba naudojamos senesnės technologijos.

Tobulinimas dažniausiai racionalesnis, kai:

• sistema stabiliai veikia;

• architektūra leidžia ją plėsti;

• pagrindinės problemos yra lokalios;

• galima palaipsniui modernizuoti atskiras dalis;

• perrašymas sukeltų per didelę verslo riziką.

Perrašymas gali būti pagrįstas, kai sistema nebesaugi, jos praktiškai neįmanoma plėsti, naudojamos nebepalaikomos technologijos arba kiekvienas pakeitimas kainuoja neproporcingai daug.

Sprendimą verta priimti tik atlikus techninį auditą.

Po paleidimo prasideda realus sistemos naudojimas. Dažniausiai būtent tada atsiranda pirmasis tikslus naudotojų grįžtamasis ryšys ir paaiškėja, kurios sistemos dalys kuria daugiausia vertės.

Po paleidimo gali būti reikalinga:

• sistemos veikimo stebėsena;

• pastebėtų klaidų šalinimas;

• naudotojų pagalba;

• saugumo atnaujinimai;

• technologiniai atnaujinimai;

• infrastruktūros priežiūra;

• greitaveikos gerinimas;

• naujo funkcionalumo planavimas.

Dar prieš projekto pabaigą turėtų būti sutarta, kas prižiūrės sistemą, kaip greitai bus reaguojama į incidentus ir kaip bus planuojamas tolimesnis vystymas.

Beveik kiekvienai aktyviai naudojamai sistemai reikalinga bent minimali techninė priežiūra.

Keičiasi:

• serverių aplinka;

• naršyklės;

• operacinės sistemos;

• išorinių paslaugų sąsajos;

• saugumo reikalavimai;

• naudojamos bibliotekos;

• verslo poreikiai.

Net jeigu naujas funkcionalumas nekuriamas, sistemą reikia stebėti, atnaujinti ir užtikrinti, kad būtų daromos atsarginės kopijos.

Dirbtinis intelektas gali pagreitinti dalį analizės, programavimo, dokumentavimo ir testavimo darbų, tačiau jo poveikis priklauso nuo konkretaus projekto.

Sudėtingiausią projekto dalį dažnai sudaro ne pats kodo rašymas, o:

• teisingas verslo problemos supratimas;

• sistemos architektūra;

• verslo taisyklių išgryninimas;

• integracijos;

• duomenų kokybė;

• sprendimų priėmimas;

• atsakomybė už galutinį rezultatą.

Todėl dirbtinis intelektas turėtų būti naudojamas kaip komandos darbo įrankis, o ne kaip priežastis atsisakyti analizės, kokybės kontrolės ar patyrusių specialistų.

Taip. DI sprendimas nebūtinai turi būti atskiras produktas.

Jis gali būti integruotas į:

• klientų savitarną;

• CRM sistemą;

• dokumentų valdymo sistemą;

• B2B portalą;

• užsakymų valdymo sistemą;

• vidinį darbuotojų portalą;

• elektroninę parduotuvę.

Pavyzdžiui, DI gali padėti rasti informaciją dokumentuose, paruošti atsakymus klientams, klasifikuoti užklausas, ištraukti informaciją iš dokumentų arba pasiūlyti kitą veiksmą darbuotojui.

Didžiausią vertę paprastai sukuria ne atskiras pokalbių langas, o DI integracija į konkretų verslo procesą.

Projekto vertė neturėtų būti vertinama vien pagal sutaupytas darbuotojų valandas.

Reikėtų įvertinti ir:

• sumažėjusį klaidų skaičių;

• greitesnį klientų aptarnavimą;

• trumpesnį užsakymo procesą;

• greitesnį sprendimų priėmimą;

• didesnį darbuotojų pajėgumą;

• sumažėjusią priklausomybę nuo rankinio darbo;

• geresnę klientų patirtį;

• papildomų pajamų galimybes;

• galimybę augti nedidinant komandos tokiu pačiu tempu.

Geras technologinis sprendimas ne tik sumažina dabartines sąnaudas. Jis gali pakeisti ryšį tarp verslo augimo ir tam augimui reikalingų išteklių.

Projektas gali neatsipirkti, jeigu:

• sprendžiama nereikšminga problema;

• sistema kuriama neturint aiškaus naudotojo;

• verslas nėra pasiruošęs keisti procesų;

• kuriamas funkcionalumas, kurio niekas nenaudos;

• pasirinktas individualus programavimas, nors pakaktų standartinės sistemos;

• nėra žmogaus, atsakingo už sprendimų priėmimą;

• projektas neturi aiškaus tikslo ir prioritetų;

• bandoma vienu metu automatizuoti per daug skirtingų procesų.

Todėl prieš pradedant projektą svarbu įvertinti ne tik technines galimybes, bet ir tai, ar organizacija pasiruošusi naują sistemą realiai naudoti.