Webaplikacija: kada reikia individualaus sprendimo?

Webaplikacija yra naršyklėje veikianti sistema, skirta darbui atlikti, o ne vien informacijai rodyti. Lietuvos įmonei individualios webaplikacijos gali prireikti, kai skaičiuoklės, el. paštas ir standartiniai įrankiai pradeda trukdyti sklandžiai darbo eigai.

Svetainė pristato įmonę ir padeda lankytojams susisiekti. Webaplikacija padeda atlikti darbą. Ji gali valdyti prisijungimus, vartotojų vaidmenis, formas, užsakymus, dokumentus, kliento savitarnos portalą, vidinį užklausų srautą, API integracijas ir ataskaitas. Esminis skirtumas tas, kad webaplikacija perima procesus, kurie kitaip vyktų rankiniu būdu.

Individualus sprendimas reiškia, kad darbo eiga formuojama aplink įmonę, o ne atvirkščiai. Wevo tokias sistemas kuria Lietuvos įmonėms, kai standartiniai įrankiai beveik tinka, bet nepakankamai gerai, kad būtų efektyvūs.

Kas yra webaplikacija?

Webaplikacija yra programinė įranga, veikianti per naršyklę. Atidarote nuorodą, prisijungiate ir dirbate sistemoje neįdiegę atskiros programos kompiuteryje. „Google Docs“, kliento portalai, registracijos sistemos, vidiniai skydeliai ir CRM įrankiai yra tipiniai pavyzdžiai. Mažesnei įmonei naršyklėje veikianti programėlė gali būti kur kas siauresnė: vidinis įrankis potencialiems klientams sekti, portalas, kuriame klientai įkelia dokumentus, arba skydelis, kaupiantis duomenis iš kelių sistemų.

Esmė ne ta, kad viską reikia kurti nuo nulio. Unikali proceso dalis neturėtų būti spraudžiama į sistemą, kuri jai nebuvo sukurta. Jei Eglė valdo personalo atrankos agentūrą Šiauliuose ir naudoja el. paštą, „Excel“ bei tris aplankus kandidatams ir užsakymams suderinti, greičiausiai jai nereikia didelės HR sistemos. Galbūt jai reikia paprastos žiniatinklio sistemos, kuri vienoje vietoje kauptų informaciją apie kandidatus, jų būseną, dokumentus ir tolesnius veiksmus.

Kada individualus sprendimas geresnis už skaičiuoklę?

Skaičiuoklės puikiai tinka, kol netampa svarbiausia darbo sistemos dalimi. Iš pradžių jose atsiranda keli lapai klientams, projektams ir būsenoms sekti. Vėliau prisideda spalvos, paslėpti stulpeliai, formulės ir failų kopijos pavadinimais „galutinis“, „naujas galutinis“ bei „tikrasis galutinis“. Kai niekas nebedrįsta keisti failo, skaičiuoklė tampa sistema be aiškios prieigos kontrolės, pakeitimų istorijos ir atsakomybės.

Kokie požymiai rodo, kad jums reikia individualaus sprendimo?

Svarbiausias požymis nėra tai, kad žmonės skundžiasi. Svarbiausias požymis yra tai, kad ta pati informacija rašoma kelis kartus. Kai duomenys įvedami formoje, kopijuojami į „Excel“, siunčiami el. paštu ir vėliau įvedami į CRM, mokate už trintį kiekvieną savaitę. Klaidos atsiranda ne todėl, kad žmonės tingūs. Jos atsiranda todėl, kad sistema kviečia klysti.

1. Tą pačią informaciją vedate į kelias sistemas.
2. Tik vienas žmogus supranta, kaip procesas iš tikrųjų veikia.
3. Klientai turi siųsti failus ar statusą el. paštu, nes portalo nėra.
4. Vadovybei trūksta aktualios apžvalgos, todėl ataskaitas tenka rengti rankiniu būdu.
5. Standartiniame įrankyje per daug funkcijų, bet trūksta būtent tos vienos, kurios jums reikia.
6. Mažos duomenų klaidos vėliau procese sukelia dideles pasekmes.

Jei du ar trys iš šių dalykų sutampa vienu metu, verta apsvarstyti individualaus sprendimo galimybę. Dažnai būtent API integracija su jau naudojamais įrankiais pašalina daugiausia dvigubo darbo. Ne todėl, kad individualus sprendimas skamba pažangiau, o todėl, kad darbo eiga jau pakankamai vertinga, kad nusipelnytų geresnio įrankio.

Ką turėtų apimti individualus sprendimas?

Sistema turėtų būti kuriama pagal realias darbo užduotis. Klinikai tai gali būti klientų užklausos, dokumentai, būsenos ir tolesni veiksmai. Statybos įmonei tai gali būti projektai, nuotraukos, nukrypimai, darbo valandos ir ataskaitos. Konsultantui tai gali būti kliento portalas, atsiskaitymai, tvirtinimas ir sąskaitų rengimas. Dažniausiai geriausia pradėti nuo siauresnės sistemos, turinčios tvirtą struktūrą.

• Prisijungimas su vaidmenimis darbuotojams, klientams ar partneriams.
• Formos, kurios patikrina duomenis prieš juos išsaugant.
• Skydelis su statusu, o ne vien skaičiais.
• Failų įkėlimas, komentarai ir istorija, kur to reikia.
• API integracijos su CRM, apskaita, mokėjimais ar specializuotomis sistemomis.
• Pranešimai apie veiksmus, kuriems reikia dėmesio.
• Eksportas ar ataskaitos, kuriomis vadovybė naudojasi.

Būtent todėl tokias sistemas reikia planuoti su saugumu nuo pat pradžių. Prieiga, duomenų minimizavimas ir žurnalai nėra puošmena. VDAI paaiškina tokius principus kaip integruota duomenų apsauga ir duomenų minimizavimas BDAR kontekste. Individualiam sprendimui tai reiškia, kad nerenkate daugiau duomenų nei būtina ir kad tinkami žmonės gauna tinkamą prieigą.

Kaip wevo kuria individualų sprendimą Lietuvos įmonėms?

Pradedu nuo proceso, o ne nuo technologijos. Pirmas klausimas visada: kas vyksta prieš užduotį, jos metu ir po jos? Tada nubraižomi vaidmenys, duomenų modelis ir svarbiausi ekranai. Kai tai aišku, sistemą galima kurti mažomis dalimis: pirmiausia pagrindinį srautą, tada integracijas, tada ataskaitas ir pagerinimus.

Wevo svarbi sprendimo nuosavybė ir skaidrumas. Sistema, kuri svarbi jūsų verslui, neturėtų būti neaiški ir nevaldoma. Turėtumėte žinoti, ką ji daro, kur laikomi duomenys, kokias API ji naudoja ir kaip ją galima plėtoti. Tai ta pati logika, kurią aptariu individualaus sprendimo ir standartinės programos palyginime: kurkite tik tada, kai tai sprendžia tikrą problemą.

Ką reikėtų išsiaiškinti prieš kuriant?

Geriausia pradžia yra proceso žemėlapis. Jokio ilgo seminaro su bendromis frazėmis, tik konkreti šiandien vykstančio darbo apžvalga. Kas ką daro? Kur procesas sustoja? Kokie duomenys turi būti teisingi? Kur dažniausiai kyla klaidų? Kurias užduotis galima automatizuoti? Toks žemėlapis dažnai parodo, ar reikia naujos sistemos, integracijos, ar tiesiog geresnės tvarkos.

Jei žemėlapis neatskleidžia aiškios problemos, verta palaukti su kūrimu.