Taisymas · · 5 min. skaitymo · Lurto · Atnaujinta
Taisyti ar kurti iš naujo sugedusią DI automatizaciją: dauguma taisymų kainuoja mažiau nei 3 700 €

Trumpas atsakymas
Taisykite, kai gedimo vietą galima tiksliai nurodyti: kai kas nors gali pasakyti „šis mazgas, šis promptas, šis webhook“ ir paaiškinti, kaip priežastis sukelia simptomą. Kurkite iš naujo, kai netinkamas pats pagrindas: no-code įrankis naudojamas ten, kur jo galimybių nebepakanka, nėra duomenų modelio, sistema tokia painti, kad niekas jos nebeatseka, arba ji iš esmės sukurta ne tam darbui. Tą patį rodo ir kainos. Smulkūs taisymai kainuoja nuo 700 iki 1 400 €, dauguma sugedusių sistemų taisymų nuo 1 400 iki 3 700 €, o kūrimas iš naujo nuo 3 700 iki 9 200 €. Taigi rekomendacija kurti iš naujo yra teiginys, kad Jūsų sistemos taisymas kainuotų daugiau nei 3 700 €, ir toks teiginys turi būti pateiktas raštu, su priežastimis.
Jūsų automatizacija sugedusi, ir gaunate dviejų rūšių patarimus. Vienas žmogus sako, kad tai nedidelis pataisymas. Kitas sako, kad viską reikia perdaryti iš naujo, šį kartą tinkamai. Skirtumas tarp šių atsakymų gali siekti nuo 700 iki 9 200 €, todėl verta neapsirikti. Čia pateikiame principą, kurį taikome patys, ir skaičius.
Taisyti ar kurti iš naujo: taisykite, kai gedimo vieta aiški
Taisyti verta, kai architektūra tinkama, o gedimai yra pavieniai, tai yra konkrečios problemos, kurių vietą galima nurodyti, šiaip tvarkingoje sistemoje. Sugedusi integracija yra aiškiausias atvejis. Pasikeitė API, baigė galioti prisijungimo duomenys, CRM lauke pakeistas pavadinimas; workflow tvarkingas, reikia tik iš naujo prijungti vieną jungtį, ir tai yra taisymas, kad ir ką sakytų pasiūlymą teikiantis žmogus.
Blogas promptas yra antrasis atvejis. Pokalbių robotas per daug kalba, nukrypsta nuo scenarijaus arba išgalvoja atsakymus, nes niekada nebuvo susietas su Jūsų dokumentais, o susiejus jį taip, kad robotas nustotų išgalvoti, keičiamas vienas sluoksnis, o visa kita lieka nepaliesta. Trūkstamas klaidų valdymas yra trečias ir dažniausias atvejis tarp tų, kuriuos esame vertinę: architektūra teisinga, bet supaprastinta, nėra pakartotinių bandymų, nėra įspėjimų ir niekas nesaugo nuo dubliuotų įrašų paleidus iš naujo. Būtent dėl tokių gedimų automatizacijos nustoja veikti po paleidimo, o esamą sistemą sutvarkyti užtrunka kelias dienas.
Palyginimui: patys prižiūrime kasdien veikiančias sistemas, tarp jų dokumentų generatorių hidrogeologijos klientui, kuris 2026 m. rugpjūčio duomenimis buvo sugeneravęs 168 dokumentus, ir beveik visos problemos, kurias su jomis turėjome, buvo būtent tokie pavieniai gedimai.
Visais šiais atvejais požymis tas pats: kas nors gali pasakyti „šis mazgas, šis promptas, šis webhook“ ir paaiškinti, kaip priežastis sukelia simptomą. Jei gedimo vieta aiški, taisykite.
Kurkite iš naujo, kai netinkamas pagrindas
Kurkite iš naujo, kai jokie pavieniai taisymai nepadės pasiekti stabilios sistemos. Kai kuriuos sugedusius pagrindus matome dažniau už kitus.
- No-code įrankis naudojamas ten, kur jo galimybių nebepakanka. No-code platformos gerai veikia savo ribose. Kai jomis bandoma vykdyti sudėtingą kelių žingsnių logiką su daugybe šakų, ilgus ciklus per tūkstančius įrašų ar realaus laiko balso pokalbius, kiekvienas pataisymas kovoja su platforma. Tai atpažinsite, kai kiekvienam pataisymui reikia apėjimo, o kiekvienam apėjimui dar vieno apėjimo.
- Nėra duomenų modelio. „Duomenų bazė“ išmėtyta po skaičiuoklių langelius, workflow kintamuosius ir pastabų laukus, be vieno patikimo šaltinio. Tas pats klientas egzistuoja tris kartus, skaičiai skirtingose sistemose nesutampa, ir niekas negali pasakyti, kuri kopija teisinga. Taisant tokios sistemos simptomus, nuolat atsiranda naujų.
- Sistema tokia painti, kad niekas jos nebeatseka. Dešimtys vienas kitą paleidžiančių workflow, jokios pavadinimų tvarkos, nebenaudojamos šakos, kurių niekas nedrįsta ištrinti. Kai niekas negali paaiškinti, kaip vienas įrašas juda per sistemą, o kūrėjo nebėra, senos sistemos supratimas pradeda kainuoti daugiau nei nauja sistema.
- Netinkamas sprendimas. Kartais tai, kas sukurta, tiesiog netinka darbui: naktinis paketinis apdorojimas ten, kur verslui reikėjo realaus laiko, arba pokalbių robotas ten, kur klientai skambina telefonu. Čia nėra ko taisyti.
Skaičiai
| Darbas | Kaina | Trukmė |
|---|---|---|
| Raštiška diagnostika | 450 €, įskaitoma į bet kokį tolesnį darbą | 2 darbo dienos |
| Smulkus taisymas | nuo 700 iki 1 400 € | nuo 2 iki 5 dienų |
| Įprastas sugedusios sistemos taisymas | nuo 1 400 iki 3 700 € | nuo 1 iki 2 savaičių |
| Kūrimas iš naujo | nuo 3 700 iki 9 200 € | nuo 2 iki 4 savaičių |
| Priežiūros planas | nuo 350 € per mėnesį | nuolat |
Visiems šiems darbams taikoma 30 dienų klaidų garantija. Atkreipkite dėmesį į lentelės struktūrą: dauguma taisymų kainuoja nuo 700 iki 3 700 €, o kūrimas iš naujo prasideda ten, kur baigiasi taisymai. Taigi rekomendacija kurti iš naujo reiškia, kad Jūsų konkrečios sistemos taisymas kainuotų daugiau nei 3 700 €, ir tai turi būti pagrįsta raštu. „Taisymas reiškia X, Y ir Z, o tai kainuoja daugiau nei nauja sistema“ yra išvada, kurią galite patikrinti. „Čia netvarka, reikia pradėti iš naujo“ yra tik įspūdis.
Rangovas, kuris visada siūlo kurti iš naujo
Kai kurios įmonės kurti iš naujo rekomenduoja kiekvieną kartą, ir naudinga suprasti kodėl. Kurti nauja maloniau nei gilintis į kito darbą, galima dirbti su mėgstamomis technologijomis, o ir sąskaita būna didesnė. Paklauskite, ką konkrečiai jie rado blogo dabartinėje sistemoje; šis klausimas priklauso kitiems klausimams, kuriuos verta užduoti prieš samdant DI agentūrą. Rangovas, kuris negali įvardyti, kas pagrinde sugedo, nieko neištyrė, ir Jūs mokėtumėte už kūrimą iš naujo vien todėl, kad jam taip patogiau.
Būna ir atvirkščiai. Mėnesius taisyti sistemą, kurios pagrindas netinkamas, taip pat reiškia permokėti, tik lėčiau. Kartais teisingas patarimas yra „nustokite mokėti už šios sistemos taisymą“, ir diagnostika, kuri niekada nedrįsta to pasakyti, nedaug verta.
Ką turi apimti raštiška diagnostika
Kad ir ką samdytumėte, nesitenkinkite žodine išvada. Raštu Jums reikia visų workflow, integracijų ir duomenų saugyklų, su kuriomis dirba sistema, sąrašo, nes nedokumentuotose sistemose visada būna staigmenų; gedimų sąrašo su kiekvieno priežastimi ir svarba, padalyto į „daro žalą dabar“ ir „pakenks vėliau“; išvados, taisyti ar kurti iš naujo, pagrįstos šiais radiniais; ir fiksuotos kainos bei termino rekomenduojamam sprendimui, kad prieš akis turėtumėte konkretų skaičių.
Turėdami tokį dokumentą galite ramiai apsispręsti ir su juo kreiptis į kitą kompetentingą rangovą dėl antro pasiūlymo. Todėl gera diagnostika verta pinigų pati savaime, kad ir kas galiausiai taisytų sistemą.
Vienintelė situacija, kai šis principas nepadeda, yra sistema, kuria niekas nesinaudoja. Jei automatizacija sugedo prieš tris mėnesius, o verslas toliau veikė, išjunkite ją ir atšaukite prenumeratas; tai ir yra visas atsakymas.
Būtent tokia diagnostika yra pirmas mūsų darbo žingsnis. Raštiška diagnostika už 450 €, pateikiama per dvi darbo dienas, visa suma įskaitoma į taisymo ar kūrimo iš naujo kainą, jei toliau dirbate su mumis. Jei prieš akis turite sugedusią sistemą ir dvi prieštaringas nuomones, pradėkite nuo mūsų sugedusių sistemų taisymo paslaugos arba atsiųskite tai, ką jau žinote.
Dažnai užduodami klausimai
Kuriuos gedimus verta taisyti, o ne kurti iš naujo?
Trijų rūšių. Sugedusi integracija: pasikeitė API, baigė galioti prisijungimo duomenys arba CRM lauke pakeistas pavadinimas, ir reikia iš naujo prijungti vieną jungtį. Blogas promptas: asistentas nukrypsta nuo scenarijaus arba išgalvoja atsakymus, nes niekada nebuvo susietas su Jūsų dokumentais. Ir trūkstamas klaidų valdymas: nėra pakartotinių bandymų, nėra įspėjimų, niekas nesaugo nuo dubliuotų įrašų paleidus iš naujo. Tai dažniausias iš trijų atvejų, ir jo sutvarkymas užtrunka dienas, ne savaites.
Kada kurti iš naujo iš tikrųjų yra teisingas sprendimas?
Kai jokie pavieniai taisymai nepadės pasiekti stabilios sistemos. Keturi pagrindai lūžta dažniau už kitus: no-code įrankis naudojamas ten, kur jo galimybių nebepakanka, ir kiekvienam pataisymui reikia apėjimo, o kiekvienam apėjimui dar vieno apėjimo; nėra duomenų modelio, todėl tas pats klientas egzistuoja tris kartus ir niekas negali pasakyti, kuri kopija teisinga; sistema tokia painti, kad ją suprasti kainuoja daugiau nei sukurti naują; ir iš esmės netinkamas sprendimas, pavyzdžiui, naktinis paketinis apdorojimas ten, kur verslui reikėjo realaus laiko.
Kaip atskirti pagrįstą rekomendaciją kurti iš naujo nuo neapgalvotos?
„Taisymas reiškia X, Y ir Z, o tai kainuoja daugiau nei švari nauja sistema“ yra sprendimas, kurį galite patikrinti. „Čia netvarka, reikia pradėti iš naujo“ yra tik įspūdis. Kai kurios įmonės kurti iš naujo rekomenduoja kiekvieną kartą, ir naudinga žinoti kodėl: kurti nauja maloniau nei gilintis į kito darbą, galima dirbti su mėgstamomis technologijomis, o ir sąskaita būna didesnė. Paklauskite, ką konkrečiai jie rado blogo dabartinėje sistemoje.
Ką turi apimti raštiška diagnostika?
Keturis dalykus, raštu, o ne žodinę išvadą. Visų workflow, integracijų ir duomenų saugyklų, su kuriomis dirba sistema, sąrašą. Gedimų sąrašą su kiekvieno priežastimi ir svarba, padalytą į „daro žalą dabar“ ir „pakenks vėliau“. Išvadą, taisyti ar kurti iš naujo, pagrįstą šiais radiniais. Ir fiksuotą kainą bei terminą rekomenduojamam sprendimui. Turėdami tokį dokumentą galite ramiai apsispręsti ir su juo kreiptis į kitą kompetentingą rangovą dėl antro pasiūlymo.
O jei sugedusia automatizacija iš tikrųjų niekas nesinaudoja?
Tada šis principas netaikomas. Jei automatizacija sugedo prieš tris mėnesius, o verslas toliau veikė, išjunkite ją ir atšaukite prenumeratas. Tai ir yra visas atsakymas.
Daugiau apie taisymą
Jūsų sistema veikia ne taip, kaip turėtų?