Mida ütleb arendaja kaasaegse ERP tarkvara arendamise kohta
Allikas: Äri-IT Kevad 2022
Autor: Villem Heinsalu, BCS Itera arendaja
Ärikeskkond muutub väga kiiresti ja ettevõtted peavad uute oludega hoobilt kohanema. Nüüdisaegne äritarkvara ERP on just loodud nõnda, et vajalikke muudatusi saab kiirelt ja ilma suurema vaevata tarkvarasse sisse viia.
ERP tarkvara on äritarkvara, mis on eluks vajalik enamikule teatud suuruse saavutanud ettevõtetele, aidates neil läbi viia igapäevaseid äriprotsesse, näiteks raamatupidamist, finantsarvestust, laondust, tootmist jpm.
Karbist tulev ERP tarkvara sisaldab endas standardseid lahendusi, mis võimaldavad seda kõike korraldada. Rõhk siin on sõnal standardsed. Kuna ettevõtted teevad aga lisaks sarnastele asjadele paljusid toiminguid ka täiesti erinevalt, isegi kui nad tegutsevad samas ärivaldkonnas, siis tuleb ERP tarkvara laiendada ja kohandada vastavalt ühe või teise ettevõtte vajadustele.
ERP arendamine enne
ERP tarkvara arendamine on ajalooliselt olnud alati ajast natukene maas ja pole kaasas käinud kõige viimaste trendidega.
Paljud tänapäevased tarkvaraarenduse standardid, näiteks Giti versioonihaldus, automaattestid ja Devops, ei ole ERP arendamises olnud tavapärased. Kui enamik igapäevaselt kasutatavat tarkvara on kolinud juba ammu veebi, siis ERP on paljuski jäänud veel töölaua rakendusteks.
ERP arendamine tähendas tavaliselt rätsepalahendust ehk kliendi jaoks nullist mingi äriprotsessi disaini, arendamist ja testimist. See tegi iga arenduse kulukaks ja pikaks protsessiks, kus oli palju osapooli.
ERP arendamine nüüd
Tänaseks on rahvusvahelised tuntumad ERP tarkvarad jõudnud sellisele tasemele, kus kõiki uusi ja häid standardeid on võimalik töövoogu lihtsasti lülitada ning need on tootja poolt toetatud ning tarkvarasse integreeritud.
Versioonikontroll
Nüüd ilma versioonihalduseta keegi enam ERP jaoks koodi ei kirjuta. Kui minevikus tähendas arenduse live’i viimine tekstifailide võrdlemist ja lootust, et keegi ei ole otse tootmiskeskkonnas midagi muutnud, siis nüüd selliseid muresid enam ei ole. Samuti on alati olemas muudatuste logi ja ajalugu, mis aitab probleemide korral väga kiiresti aru saada, mis ja millal valesti läks.
Tootja koodi muutmine
Varem asus ERP tarkvara ainult kohapealsetes serverites, nüüd on see aga ka pilves, mis tähendab, et tootja antud põhilahenduse koodi ei saa muuta, kuna see teeks uuendused pilves võimatuks. Aga uuendusi on palju, iga kuu tuleb värske koodiuuendus. Samas on tarkvara vaja kohandada, oma äriloogikat juurde lisada ning standardtarkvara käitumist muuta.
Äpid ja sündmuste-kuulajate arhitektuur
Kui on vaja lisada funktsionaalsust või muuta standardtarkvara käitumist, siis teeb arendaja uue äpi. See äpp sõltub põhilahendusest ja seda kasutades saame muuta põhilahenduses vajalikke asju, kuid standardkood jääb muutmata.
Kui meil on vaja muuta standardtarkvara loogikat, näiteks seda, millistel tingimustel kontrollitakse asukoha tähise olemasolu müügitellimuse ridadel, siis me ei muuda standardtarkvara, vaid n-ö kuulame sündmust. Näiteks sündmus „Tellimuse vabastamine“ ütleb, et tellimus vabastati ja me saame oma kontrolli rakendada. Varem oleks pidanud sellise kontrolli rakendamiseks muutma standardtarkvara koodi, mis oleks teinud tuleviku versioonivahetused keerulisemaks.
Selline äppide ja sündmuste-kuulajate arhitektuur muudab ERP arendamise väga mugavaks ja paindlikuks. Me saame luua eri funktsionaalsuste jaoks oma äpid, neid uuesti ära kasutada ja vajadusel maha võtta, pöörates nii kogu muudatuse hetkega tagasi. Versiooniuuendused on kas päris automaatsed pilves või siis võtavad kohapealsetes installatsioonides väga vähe aega võrreldes varasemaga.
Ohud ja puudused selles arhitektuuris
Uued arendusvõimalused kätkevad endas ka mõningaid aspekte, mida peab silmas pidama.
Andmebaasis loovad äpid uusi tabeleid. Kui me laiendame näiteks müügitellimuse rea tabelit ja lisame sinna uue välja, siis andmebaasis tekib uus tabel. Ning iga kord kui me uues äpis sama müügitellimuse rida laiendame, tekitatakse andmebaasi uus tabel.
Kui küsime rakenduses andmebaasist andmeid, siis tehakse SQL Join. Nii tekib olukord, kus alates 6–7 äpist, mis sama tabelit laiendavad, võib jõudlus väheneda. Selle probleemi vastu aitab oma äppide ja lahenduse läbimõtlemine, et vältida olukorda, kus tekib väga palju väikeseid äppe, mis samu tabeleid laiendavad.
Sündmuste-kuulajate arhitektuur on oma olemuselt väga hea, aga siin on ka oht, et ühe arendaja tehtud sündmuse kuulamine ja loogika võib järgmise sündmuse ära nullida. Kui meil on näiteks kood, mis konteerib müügiarvet ja seal on kaks sündmust, siis arendaja number üks võib kirjutada koodi, mis esimese sündmuse peale teeb midagi ja ütleb, et järgmise sündmuseni ei ole vaja minna. Teine arendaja teises äpis kirjutab oma koodi ja tahab kasutada sündmust number kaks, aga selle sündmuseni tegelikult ei jõutagi, kuna esimene arendaja koodi jaoks on oluline, et sündmust number kaks ei juhtu.
Mõlemad probleemid on aga väga hästi lahendatavad ja kogenud arendajad oskavad neid ennetada.
CI/CD (pidev integreerimine / pidev tarnimine)
CI/CD annab arendajatele väga head võimalused töö kvaliteeti tõsta. Nii saavad nad arendada oma lokaalses masinas ning ei pea üldse teadma kliendi keskkonda ja spetsiifikat.
Kui arendaja on oma tööga valmis saanud, siis saab ta viia oma muudatused vastavasse koodiharusse ja need üles panna. Devops loob seejärel uue Dockeri baasil keskkonna, kus äpp kompileeritakse (teisaldatakse masinkoodi), jooksutatakse testid läbi ja kui kõik on korras, siis selle kompileerimise tulemus paigaldatakse automaatselt kliendi keskkonda, kas kohapealsesse serverisse või pilve. Näiteks Testi harust võib äpp minna kliendi testserverisse ja Toodangu harust toodangu keskkonda.
Samuti võimaldab see tuleviku vastu ennast kindlustada, näiteks proovida äppe kompileerida juba järgmiste veel mitte tootmises olevate versioonide vastu.
Mis kasu sellest kõigest uuest on?
Äri võib muutuda väga kiiresti, näiteks tahab traktoreid tootev ettevõte hakata ühel päeval internetis neid rentima. Äppide võimalused lubavad võtta nende olemasoleva ERP ja panna sinna peale rentimise äpi, nii et nad saavad kohe pihta hakata. Varem oleks taoline muudatus võtnud kuid või isegi aastaid.
Veel näiteid eelistest, mida tänapäevase äritarkvara kasutaja saab:
- võimaldab tõsta arenduste kvaliteeti ja kiirust,
- võimaldab automatiseerida tegevusi,
- isoleeritud eraldiseisvad äpid, mida saab uuesti ära kasutada,
- automaatsed versioonivahetused pilves,
- lihtsad versioonivahetused kohapealsetes lahendustes,
- funktsionaalsuse uuendused tootjalt peaaegu iga kuu,
- tehnoloogia tulevikukindlus.
Plussiks võib lugeda ka seda, et tänu tänapäevasele arenduskeskkonnale tahavad ja julgevad arendajad koolidest või teistest valdkondadest ERP arendamisse tööle tulla. Kui selliseid võimalusi ei oleks, siis oleks arendajate leidmine kindlasti palju raskem.
Üks asi, millega ERP arendaja peab arvestama, on see, et kõik muutub väga kiiresti ja uusi asju tuleb tema jaoks väga kiiresti ja väga palju juurde. Nii ei saa ta jääda kauaks lootma oma praegustele teadmistele, vaid peab ennast pidevalt arendama ja uuega kursis hoidma.
ERP kui ettevõtte arendusplatvorm
Kas ERP sobib ühe ettevõtte tarkvara südameks, mille peale saab hakata funktsionaalsusi arendama? Jah, sobib, väga hästi.
Kui ettevõte tegeleb kaupade tootmisega ja müüb neid kahes e-kanalis ja ka otse B2B-klientidele, siis kaupade laoseis, klientide andmed, tellimused jms võiksid asuda ERP-s ning teised tarkvarad võiksid käia neid seal uuendamas ja küsimas.
Kui on vaja toote jaoks e-kanalisse hind leida, siis selle võiks API (rakendusliidese) vahendusel ERP-st küsida, selle asemel et seda loogikat mujal arendada.
Kui on vaja erilahendust, mis aitab tootmisest tulnud toodangu kvaliteeti jälgida ja registreerida muudatusi, siis sellise lahenduse jaoks ei ole vaja osta ega luua nullist tarkvara, vaid on võimalik väga edukalt ERP-d arendada ja nii integreerida erilahendus teiste protsessidega.
Tänapäeva ERP vastab kõigile tarkvaraarenduse nõuetele, see on hästi kohanduv ja võimas.
* CI/CD – tarkvaraarenduse tööpõhimõtted, tänu millele on võimalik koodimuudatusi kiiremini ja sujuvamalt teha. CI automatiseerib rakenduste tarnimise soovitud keskkonda, CD tagab automaatse viisi, kuidas koodimuudatus edastatakse.