Individualūs sprendimai ar SaaS: kada verta keisti įrankius

SaaS prenumerata teoriškai visada atrodo prieinama. Bet tikroji kaina slypi visai kitur - prisijungimuose, eksportuose, rankiniuose pataisymuose ir nesibaigiančiose Slack žinutėse, ieškant kažkieno patvirtinimo. Pati sąskaita pigi. O štai darbas, kuris susikuria aplink ją, jau visai ne.

BCG (opens in new tab) agentinį DI programinės įrangos rinkoje vertina kaip daugiau nei 3 trilijonų dolerių galimybę. Tai aiškus ženklas, kad būdas, kaip įmonės naudoja programinę įrangą, yra perbraižomas iš naujo. O remiantis Newsweek apžvalga apie Retool 2026 Build vs. Buy ataskaitą (opens in new tab), 35% įmonių jau pakeitė bent vieną SaaS įrankį pačių susikurta sistema, o 78% planuoja kurti dar daugiau 2026-aisiais.

Mygom (opens in new tab) kuriame programinę įrangą, kuri pakeičia neefektyvius SaaS įrankius sistemomis, pritaikytomis pagal realų darbo procesą. Šiame straipsnyje aptariame, kada toks pakeitimas tikrai atsiperka, kada ne, ir ką supratome iš keturių projektų, kuriuose vietoj SaaS sukūrėme savo sistemas.

Pigi Prenumerata, Brangus Darbas

Komanda mato vieną prenumeratą už vartotoją ir mano, kad viskas tvarkoje. Tada įmonė pradeda augti, ir žmonės pradeda kilnoti duomenis tarp įrankių, gaudyti patvirtinimus per Slack, taisyti įrašus jau po fakto. Štai kur pasimato įrankių chaosas: vėlavimuose, perdarymuose, neaiškiame atsakomybių pasiskirstyme.

Matėme komandas, kurioms vos vienai užklausai sutvarkyti reikėjo daugiau nei dešimties veiksmų. Mokami įrankiai jau nebebuvo pagrindinė sistema. Tikroji sistema - tai skirtukai, pašto dėžutės ir atmintis. Tuo momentu klausimas jau nebėra „kiek kainuoja šis įrankis?", bet „kiek kainuoja visas šis darbo procesas?"

Daugiau įrankių - lėtesnis darbas

Dauguma komandų SaaS įrankius keičia ne dėl kainos, o dėl lėtėjančio darbo.

Jei naujam klientui įvesti pakanka trijų prisijungimų, dviejų eksportų ir greitos Excel lentelės patikros, tie įrankiai jau trukdo procesui. Vadovai tą pastebi - lėtesnis darbuotojų įvedimas, ilgesni mokėjimų ciklai, vėluojančios ataskaitos. Vadovybė mato, kai paprastam klausimui gauti reikia penkių žmonių, o atsakymai prieštarauja vieni kitiems.

Retool tyrimas (opens in new tab) parodė, kad per metus net 60% komandų programinę įrangą kūrė ne IT, o kita verslo dalis. Žmonės ima apeidinėti sistemas, kai jos pradeda trukdyti. Tai įvyksta greitai, net jei to nenorima.

Kai apėjimai tampa pagrindine sistema

Įmonės retai keičia įrankius vien todėl, kad sąskaita per didelė. Jos keičia tada, kai apėjimai jau perima visą darbą į savo rankas.

Tai diena, kai Excel lentelės pradeda valdyti užsakymų pildymą. Diena, kai sąskaitos statusas gyvena kažkieno laiškų dėžutėje. Diena, kai pristatymas laukia greitos Slack žinutės, nes niekas nebepasitiki tuo, ką rodo sistema.

Tai ir yra lūžio taškas. Senasis nustatymas veikė puikiai - kol verslas išaugo ir pradėjo lįsti įtrūkimai. Kai apėjimai tampa pačia sistema, likti vietoje paprastai brangiau nei keistis.

Keturi atvejai – tas pats modelis

Sprendimas pakeisti SaaS įrankį nepriimamas susirinkimuose ar pristatymuose. Jis ateina tada, kai pati kasdienybė pradeda keistis - kai apėjimai užima daugiau laiko nei pats darbas. Štai keturi Mygom projektai, kuriuose tai aiškiai pasimatė: Parkavimo Programėlės Transformacija (opens in new tab), DI sąskaitų automatizavimo platforma (opens in new tab), Plieno konstrukcijų gamybos ERP sistema (opens in new tab) ir DI agentų verslo analizės sprendimai (opens in new tab). Skirtingos pramonės šakos, skirtingos problemos, bet tas pats kelias: surasti darbo procesą, kuris iš tikrųjų generuoja pajamas, atsikratyti to, kas trukdo, perkelti viską etapais ir toliau tobulinti, kai sistema jau paleista.

Parkavimo programėlės transformacija

Klientas (opens in new tab) atėjo pas mus su platforma, kuri dar veikė, bet vos vos. Nauji vartotojai susidurdavo su problemomis pačiu blogiausiu momentu: kai bandydavo užsiregistruoti ir pirmą kartą sumokėti. Sąskaitos sukūrimas tęsdavosi amžinybę. Mokėjimai jausdavosi sudėtingi. Kiekvienas mažas vėlavimas mažino pasitikėjimą dar prieš tai, kai klientas spėdavo pastatyti automobilį.

Tiesiog pataisyti ekranus neužteko. Viską perstatėme pagal realią naudotojo kelionę - nuo registracijos iki mokėjimo. Sunkiausia buvo nustatyti darbų eiliškumą. Pirma reikėjo atnaujinti svarbiausius procesus, bet tuo pat metu išlaikyti senąją sistemą veikiančią, kitaip klientai būtų likę be galimybės sumokėti, kol naujoji versija dar tik kuriama.

Per pokalbius su jų komanda nuolat girdėjome tą patį: nauji žmonės dažnai pasitraukdavo dar prieš tapdami klientais. Pati registracija buvo ta vieta, kur prarandami santykiai. O tiems, kurie ją vis dėlto įveikdavo, laukdavo dar viena kliūtis - siauras mokėjimo būdų pasirinkimas. Programėlės naudotojas atsiduria pačiame paslaugos pradžioje su jausmu, kad sistema jam trukdo, o ne padeda.

Rezultatai pasimatė greitai. Sąskaitos sukūrimas tapo 80% greitesnis, mokėjimai pradėjo praeiti tris kartus sklandžiau, o klientų išlaikymas išaugo net penkis kartus. Pirmoji patirtis pagaliau atitiko tai, kokia paslauga turėjo būti nuo pat pradžių.

DI sąskaitų automatizavimo platforma

Mūsų pačių finansų procesas vos laikėsi. PDF failai buvo atsisiunčiami, pervadinami, persiunčiami patvirtinimui, o po to dar kartą rankiniu būdu suvedami į kitą įrankį. Vieną savaitę tai dar atrodė pakeliama. Bet vos sąskaitų kiekiui padidėjus, visa sistema pradėdavo trūkinėti.

Dažnai tokiu atveju norisi pridėti dar vieną įrankį - OCR, tvirtinimui, patvirtinimui. Mes pasukome kitu keliu. Sukūrėme vieną procesą, aprėpiantį visą kelionę - nuo sąskaitos gavimo iki galutinio tvirtinimo. Jokio antro skirtuko. Jokio naujo prisijungimo. Viena vieta, kur realiai vyksta darbas.

Sunkiausia buvo nepradėti taisyti to, ko taisyti nereikėjo. Šalia buvo dešimtys kitų problemų, kurias galėjome spręsti, ir lygiai tiek pat funkcijų, kurios gerai atrodytų demonstracijoje. Bet visas tikslas buvo išspręsti vieną konkrečią problemą - ne pastatyti pilną finansų sistemų rinkinį. Todėl išlaikėme aiškias ribas ir nepasidavėme pagundai plėstis.

Pirmiausia sistemą bandėme sau, įsitikinome rezultatu ir šiandien tą patį sprendimą (opens in new tab) pritaikome kitoms finansų komandoms. First Line Software tyrimas (opens in new tab) rodo, jog 40% įmonių programų naudoja DI, bet daugiau įrankių - nereiškia daugiau vertės. Tikroji nauda - kai pats darbas tampa paprastesnis.

Po paleidimo procesas tapo 40% greitesnis. Programinės įrangos išlaidos sumažėjo 30%. Kiekvienas darbuotojas aptarnavo 10 kartų daugiau sąskaitų nei anksčiau.

Plieno konstrukcijų gamybos ERP sistema

Iš pažiūros šis gamybos klientas (opens in new tab) neturėjo programinės problemos. Excel, el. laiškai, patyrę žmonės užtikrino tęstinumą. Bet visa sistema buvo trapi - produkcijos stebėjimas vyko Excel, pirkimas, sandėlis ir cechas – visi dirbo su skirtinga informacija. Vadovai valandų valandas naujino lenteles ir vis tiek dirbo su pasenusiais duomenimis.

Jiems sukūrėme individualią platformą, apimančią visą gamybą - nuo pirmos užklausos ir užsakymo iki paskutinio komponento apdorojimo. Komandos galėjo formuoti užsakymus, kviesti tiekėjus dalyvauti konkursuose ir sekti detalią gamybos eigą.

Nepradėjome braižyti modulių lentoje. Pradėjome nuo to, kas iš tikrųjų stabdė darbą. Kas trukdė medžiagų atrinkimui. Kur vadovai prarasdavo daug laiko. Štai kur turėjo prasidėti sistema - ne nuo to, kaip atrodo vadovėlinis ERP, o nuo to, kas jiems realiai kainavo valandas.

Didžiausias iššūkis šiame projekte buvo ne tai, ką statyti. Klausimas buvo, kaip greitai viską diegti. Per lėtai - komanda lieka užstrigusi senoje sistemoje. Per greitai - žmonės cechė nespės prisitaikyti ir pradės ignoruoti. Todėl darėme tai etapais ir mokėme žmones pagal jų vaidmenis, o ne pagal funkcijų sąrašą. Šis žemiškas požiūris sieja darbą su mūsų individualių web aplikacijų kūrimo paslauga (opens in new tab) - sistema turėjo atrodyti taip, lyg ji čia buvo nuo pat pradžių, o ne tiesiog užmesta ant esamo darbo srauto.

Produktyvumas išaugo 15%. Medžiagų surinkimas ir paskirstymas tapo 35% greitesnis. Gamybos vadovai kasdien sutaupė po 3 valandas. Užsakymų apimtis augo be naujų žmonių.

DI agentų verslo analizės sprendimai

Šis projektas prasidėjo lygiai taip pat kaip ir sąskaitų - su mūsų pačių problema. Duomenys buvo išsibarstę per sistemas, sąskaitų išrašymo įrankius ir laiko sekimo programas. Skaičių matėme daug, bet sudėti juos į vieną aiškų atsakymą užtrukdavo valandų valandas rankinio darbo ir SQL užklausų. Klausimai, kurie iš tikrųjų rūpėjo — kurie projektai pelningi, kuriuos klientus galime prarasti, kur komanda perkrauta - likdavo neatsakyti, nes didžioji laiko dalis nueidavo techniniam darbui, o ne tikram analizavimui.

Todėl sukūrėme platformą (opens in new tab) — DI agentų sluoksnį, kuris sutraukia ataskaitų logiką iš visų tų įrankių į vieną vietą. Tikslas buvo, kad duomenys atsakytų į klausimus paprasta kalba, o ne versti žmones rašyti SQL ar iš naujo kurti suvestines kiekvieną kartą, kai kažkas pasikeičia.

Sunkiausia buvo padaryti skaičius patikimus. Reikėjo suderinti tų pačių dalykų apibrėžimus skirtingose sistemose, švariai sujungti išsibarsčiusius šaltinius ir įrodyti, kad rezultatas atitinka realybę - kitaip žmonės vis tiek tikrintų savo asmeninėse Excel lentelėse, ir nieko nepasikeistų.

Mes ne visada rekomenduojame ką nors keisti. Jei pakeitimas duoda tik 10% pagerėjimą, paleidimo skausmas paprastai to neapsimoka. Bet šiuo atveju nauda buvo reali. Prieiga prie verslo įžvalgų tapo tris kartus greitesnė. Viršvalandžių išlaidos sumažėjo 30%, kai vadovybė pagaliau galėjo matyti, kur komandos perkrautos. Apimties slydimas projektuose sumažėjo 25%, nes visi pagaliau dirbo su tais pačiais duomenimis.

Pradėjome kurdami šį įrankį sau. Dabar taikome ir kitoms įmonėms, kurių duomenys išsibarstę skirtinguose įrankiuose. Ir kai duomenų pateikimas tampa pasitikėjimo problema, padedame UX/UI dizaino paslauga (opens in new tab) - kad duomenys taptų ne tik prieinami, bet ir panaudojami sprendimams priimti.

Ką šie keturi projektai turi bendro

Skirtingos pramonės šakos, skirtingi pradiniai taškai, bet kiekvienu atveju problema gilumoje buvo ta pati.

Klientas turėjo parkavimo platformą (opens in new tab), kuri nebeatitiko to, kaip žmonės iš tikrųjų nori registruotis ir mokėti. Plieno gamykla (opens in new tab) valdė visą gamybą Excel lentelėmis, kurios subyrėdavo vos apimtims šoktelėjus. Mūsų pačių finansų komanda skendo PDF failuose ir niekada nesibaigiančiose patvirtinimų grandinėse (opens in new tab). O ataskaitos (opens in new tab) buvo taip išsibarsčiusios per skirtingus įrankius, kad nė vienas susitikimas nesibaigdavo su tuo pačiu skaičiumi rankose.

Visais atvejais tikroji sistema jau seniai nebebuvo mokami įrankiai. Tikroji sistema buvo apėjimai: Excel lentelės, naršyklės skirtukai, pašto dėžutės, greitos Slack žinutės. Darbas vis dar buvo padaromas, bet tik todėl, kad žmonės jį laikė savo rankomis.

Štai kodėl visi keturi projektai galiausiai virto individualiais sprendimais. Ne todėl, kad rinkoje nebuvo paruoštų sistemų. O todėl, kad pati problema gyveno darbo procese ir jokia SaaS sistema iš išorės to nebūtų išsprendusi.

Skirtingi keliai į pradžią, bet tas pats darbo metodas: rasti procesą, kuris iš tikrųjų varo verslą, atsikratyti to, kas trukdo, viską daryti etapais, žiūrėti, kaip žmonės naudoja naują sistemą, ir tobulinti toliau jau po paleidimo.

Niekas iš to nevyko sklandžiai. Senos sistemos viską apsunkindavo. Žmonėms reikėjo laiko priprasti. Diegimo tempas kartais buvo svarbesnis už pačią technologiją.

Bet kiekvieną kartą pasitvirtindavo tas pats dalykas. Pergalės kildavo ne iš sudėtingos architektūros, o iš to, kad pasirinkdavome teisingą darbo procesą ir nesileisdavome blaškomi visko, kas vyksta aplinkui.

Individualūs sprendimai ar SaaS

Iki šiol kalbėjome apie tai, kada apėjimai tampa tikrąja problema. Kitas klausimas - kiek kainuoja prie jų pasilikti, o kiek kainuoja juos pakeisti.

SaaS atrodo prieinamas, nes sąskaita visada tvarkinga. Kaina už vartotoją nuspėjama. Įdiegti viską galima per kelias dienas. Bet tikroji kaina susikaupia ten, kur jos niekas nemato - kasdieniame darbe, žmonių laike ir nesibaigiančiuose laukimuose kažkieno patvirtinimo.

Pagalvokite apie finansų komandą, kuri dar prieš pietus turi septynis naršyklės skirtukus atvirus. Niekas neva nesugriuvę. Bet kiekvienas eksportas, kiekvienas duomenų perdėliojimas, kiekvienas papildomas paklausimas atima dar truputį laiko.

Todėl SaaS niekada nevertiname kaip vien prenumeratos. Skaičiuojame administracinį laiką, suklijuotas integracijas, dvigubus duomenų patikrinimus, tiekėjo apribojimus ir tai, kiek brangu laukti, kol kažkas kitas savo plane pataisys tai, ko reikėjo dar praėjusią savaitę. CIO (opens in new tab) neseniai rašė, kad viešųjų SaaS bendrovių vertė sukrito 300 milijardų dolerių - ženklas, kad rinka pradeda abejoti senąja SaaS ekonomika.

Kiek kainuoja individualūs sprendimai

Individualus sprendimas ne visada pigesnis. Jei darbo procesas yra standartinis, SaaS dažniausiai laimi. Bet jei procesas tiesiogiai veikia maržą, greitį, atitiktį arba kliento patirtį — individualus sprendimas gali greitai pralenkti.

Kūrimo kainą skaidome į keturias dalis: paruošiamuosius darbus, kūrimą, diegimą ir palaikymą. Tada lyginame šitą sumą su tikrąja esamos sistemos našta - apėjimais, papildomais patikrinimais, prarasta darbuotojų talpa, įrankių persidengimu. Būtent čia ir matosi reali grąža, ypač kai sprendimas suderinamas su mūsų individualių web aplikacijų kūrimo paslauga (opens in new tab).

First Line Software (opens in new tab) skaičiavimais, programinės įrangos bendrovių vertinimo daugiklis krito nuo 18,6 iki maždaug 6 kartų. Pirkėjus dabar mažiau domina, kiek įrankių įmonė turi. Daug labiau - ką ta programinė įranga iš tikrųjų duoda verslui.

Kur Pirmiausia Matosi Grąža

Pirmoji nauda retai ateina iš pačios technologijos. Ji pasirodo paprastesniuose dalykuose: mažiau perdavimų tarp žmonių, trumpesni darbo ciklai, mažiau viršvalandžių, geresnis darbuotojų išlaikymas, mažesnė valdymo našta.

Tai kas pigiau - kurti ar pirkti? Pirkite, kai darbas standartinis ir vienodas. Kurkite tada, kai kliūtis yra pačiame jūsų verslo branduolyje - ten, kur viskas iš tikrųjų vyksta. Norint pasiekti grąžą, pirmiausia sutvarkykite procesą. Tada kurkite aplink svarbiausią kelią. Ir tik tada po vieną atsisakykite nereikalingų įrankių.

Gerus įrankius verta palikti

Kai kurie darbo procesai yra paprasta kasdienybė - atlyginimų skaičiavimas, paprasti elektroniniai parašai, išlaidų ataskaitos, kasdienė CRM tvarka. Jei įrankis veikia, komanda jį naudoja ir problema lieka vietinė, pirkti dažniausiai apsimoka labiau.

Tai, kad produkto komandai įrankis erzina, savaime nėra priežastis jį keisti. Turi būti aiški, išmatuojama žala verslui. Jei vadovybė negali jos įvardinti, dar nėra ko keisti.

Blogo proceso neverta automatizuoti

Individuali programinė įranga tik sustiprina tai, kas yra po ja. Jei vaidmenys neaiškūs, patvirtinimai vis keičiasi arba duomenų įvedimas vyksta be tvarkos, kodas tą netvarką tiesiog įamžins. Žemas proceso brandos lygis nėra ženklas kurti naują sistemą. Tai ženklas pirmiausia susitvarkyti.

Ankstyvojo etapo startuoliai turėtų tai išgirsti aiškiai. Nestatykite per anksti. Jei darbo procesas keičiasi kiekvieną mėnesį, SaaS leidžia išlaikyti lankstumą ir neužšaldo dar nesusiformavusių sprendimų į kodą.

Kaip konsultuojame klientus

Mūsų taisyklė paprasta: jei nematome aiškios kliūties, siūlome dar palaukti ir stiprinti integracijas. Sprendimas turi būti aiškiai susijęs su pajamomis, sąnaudomis, atitiktimi ar klientų patirtimi.

Toks požiūris padeda išlikti objektyviems. Net DI revoliucijos fone stiprūs tiekėjai išlaiko masto ir platinimo pranašumus, kaip pažymi ir BCG (opens in new tab). Todėl pirmiausia siūlome paprasčiausią veikiantį variantą ir tik esant realiai būtinybei pereiname prie individualaus kūrimo.

Pagrindinės išvados

Kiekvienu atveju matėme tą patį rezultatą: ne keitėme įrankius dėl pačių įrankių. Koncentravomės į vieną pagrindinį procesą, pašalinome vieną sunkų barjerą, o rezultatus vertinome pagal spartą, kaštus, produkcijos pokyčius ir lyderių svarbiausius rodiklius.

Paprastas modelis:

• Nauda: spartesni rezultatai, mažiau rankinio darbo, aiškesnė kontrolė
• Veiksmas: etapinis diegimas, ankstyvas vartojimo stebėjimas, valdymas kaip produkto pokytį
• Rezultatas: mažesnės sąnaudos, daugiau valandų komandai, didesnis našumas, aiški komercinė grąža

Pradėkite nuo vieno kritinio kelio. Diekite etapais. Stebėkite naudojimą nuo pirmos dienos. Pokyčių valdymas - tai darbo dalis nuo pat pradžių, o ne šalutinis projektas.

Jei norite pasitikrinti savo „kurti ar pirkti" atvejį – susisiekite su mumis (opens in new tab).