Rivile ERP — APP Marketplace ir APPS

Rivile ERP — APP Marketplace ir APPS

Šaltinis: vidinė medžiaga (Giedrius Lukoševičius).

Susiję: bendras pritaikymas — rivile-erp-customization-konceptas.html, automatizavimas — rivile-erp-automatizavimo-konceptas.html.

Projekto kontekstas: atstovų mokymas; organizacija ir formatas — Tema 1 · Įvadas ir planas.

1. Verslo modelis ir vizija

Tikslas: atvira Rivile APP Marketplace ekosistema, kurioje:

  • Partneriai gali kurti, testuoti ir publikuoti programėles, integracijas, automatizavimus.
  • Klientai gali lengvai atrasti, įsidiegti ir naudoti sprendimus.
  • Rivile gali centralizuotai valdyti kokybę, saugumą ir kainodarą.

2. Esama situacija

Dabar Rivile ERP leidžia automatizuoti per integracijas ir atstovų sprendimus, tačiau:

  • Automatizacijos ir pritaikymai dažnai individualūs projektai — sunkiai pakartojami.
  • Klientai ne visada žino, kokius papildinius Rivile jau turi.
  • Partneriams trūksta centralizuotos vietos dalintis, parduoti ir prižiūrėti sprendimus.

3. Techninė ir procesinė struktūra — „Sandbox“

Atskira kūrimo ir testavimo aplinka („sandbox“), kur būtų:

  • APP aprašymas, dokumentacija, versijavimas, konfigūraciniai parametrai.
  • Įrankiai automatizacijų kūrimui, testavimui ir publikavimui.
  • Integracijų testavimas su ERP duomenimis be rizikos gamybinei aplinkai.

Koncepcija: Rivile Developer Portal + Marketplace Sandbox (panašiai kaip Shopify App Store ar Odoo Apps).

4. Nauda Rivile ekosistemai

4.1 Rivile (centras)

  • Kokybė per centralizuotą tvirtinimą.
  • Daugiau kūrėjų ir galimybė klientams kurti savo automatizavimus (su kokybės procesu).
  • Matomumas: kurios organizacijos naudoja kokius apps — duomenys rinkodarbai ir pardavimams.

4.2 Partneriams / atstovams

  • Centralizuota vieta sprendimams saugoti ir platinti.
  • Reputacija — „sertifikuotas Rivile kūrėjas“.
  • Lengvesnis diegimas ir palaikymas: API, sandbox, versijos, matomumas (kurios org, kuri versija).
  • Monetizacija — pajamos už integracijas / papildinius.

4.3 Klientams (galutiniams naudotojams)

  • Lengva rasti standartinius sprendimus ir plėsti funkcionalumą.
  • Greitas diegimas / konfigūravimas — plug & play.
  • Kokybės / sertifikavimo galimybė iš Rivile pusės.
  • Dažnai mažesnė kaina nei vienaskiai projektiniai pritaikymai.

5. Įgyvendinimo etapai (roadmap)

Etapas Pavadinimas Pagrindinis rezultatas Apimtis
1 APP management aplinkos sukūrimas Kurti APP, publish, approval 200h
2 Sandbox aplinkos sukūrimas Kurti ir testuoti apps 50h
3 Monetizacijos sistema Billing plėtra, Rivile dalis 50h
4 Ekosistemos augimas Partnerių programa, sertifikavimas …

6. APPS dizainas (Figma)

Nuoroda į produkto dizainą:

https://www.figma.com/design/uVF6mUg0n80CZzjYrBeIOg/ERP-product-design?node-id=13444-3863&t=dVygY59wj1VIFcZd-0

7. APPS sąrašas ir paieška

Organizacijos nustatymuose — papildomai kaip moduliai, taip ir APP.

Sąrašų tipai:

  • Įdiegtos programėlės
  • Įdiegtos programėlės (deaktyvuotos)
  • Visos programėlės

(Šaltinyje — ekrano nuotraukos: image-20250928-090607.png ir kt.; čia neįterptos.)

8. APPS peržiūra ir diegimas organizacijoje

  • Programėlė diegiama organizacijos lygiu.
  • Aktyvuojama „Visos įmonės“ arba nurodoma konkreti įmonė (priklauso nuo APP galimybių).
  • Jei APP reikalauja kelių diegimų įmonėje („Instance“) — diegiant kuriamas arba nurodomas instance.
  • Sistema sukuria pagal naujausią versiją: parametrus, ext laukus, automatizavimus (kur nurodyta — įmonėje arba visos įmonės).
  • Fiksuojama įdiegimo ir aktyvavimo laikas (gali būti naudojama trial’ui).

9. APPS organizacijoje

  • UI žymėjimas: raudonai — papildomai gali „Atstovas“ (atstovo teisės).
  • (Šaltinyje — iliustracijos image-20250928-090939.png, image-20250928-100100.png.)

10. Modifikavimas ir versijos kūrimas (tik atstovas)

  • Tik atstovas gali koreguoti parametrus, ext laukus ir automatizavimus.
  • Sistema seka pakeitimus ir rodo įspėjimą „modifikuota“ organizacijoje.
  • Jei pasikeitė / prisidėjo parametrai ar ext laukai — rodoma organizacijos lygyje.
  • Jei pasikeitė bent vienas automatizavimas — rodoma prie automatizavimo, įmonės (instance) ir organizacijos.
  • Jei yra bent vienas modifikuotas elementas, atstovas gali kurti naują versiją pagal pakeitimus (nurodant įmonę ar instance, jei buvo automatizavimo pakeitimų).
  • Versijos numerį sistema siūlo didinant PATCH.
  • Modifikacijos (script) perkeliamos į APP management modulį.

11. Versijos naujinimas

  • Jei yra naujesnė versija nei įdiegtai — rodomas atnaujinti mygtukas.
  • Be modifikacijų: pasirinkimas — visose aktyviose įmonėse arba pasirinktose.
  • Su modifikacijomis: papildomai (numatytai) diegti ten, kur nėra modifikacijų.

Svarbu: parametrų ir ext laukų naujinimai taikomi visose įmonėse.

Automatinis atnaujinimas

  • Jei organizacijoje įjungta „Automatinis atnaujinimas“ — naujai versijai atsiradus, visose įmonėse be modifikacijų sistema gali automatiškai atnaujinti.

Atstatyti

  • Galima pasirinkti versiją (įskaitant Draft, rodoma būsena).
  • Parametrų ir ext laukų reikšmės atstatymo metu nekoreguojamos.
  • Atstatymas galimas tik visose įmonėse ir tik kai nėra modifikacijų.

12. Aktyvavimas ir deaktyvavimas

Aktyvavimas

  • Kaip diegiant APP — galima aktyvuoti kitose įmonėse.
  • Jei APP turi instance — rodomos įmonės ir instance; toje pačioje įmonėje negali būti dviejų to paties instance.
  • Jei leidžiama „Visos įmonės“ — galima taip pasirinkti.
  • Jei APP aktyvuota „Visos įmonės“, įdiegus tą patį instance — vykdomas tik tos įmonės instance kodas.

Deaktyvavimas

  • Įmonė / instance gali būti deaktyvuota — išjungiamos įmonės automatizavimai.
  • Jei deaktyvuojamos visos įmonės — deaktyvuojami ir parametrai, ir ext laukai.
  • Tokiam APP nebetinka automatinis versijos naujinimas.
  • Deaktyvuotos APP — prie įmonių galima aktyvuoti arba „aktyvuoti visas“; aktyvuojant — aktyvuojasi ir parametrai bei ext laukai.

13. APPS management (tik atstovas)

Centralizuotas valdymas atstovui. (Šaltinyje: image-20250928-100731.png.)

14. Informacija apie programėlę

Bendra informacija

Laukas Aprašymas
Pavadinimas Unikalus sistemoje.
Kodas Uppercase, unikalus visoje sistemoje; rezervuotas SS prefiksas; be spec. simbolių, tik tekstas; nekeičiamas; naudojamas parametrams, ext laukams, entitetams (klasifikatoriai ir pan.), kad diegiant apps nesikirstų pavadinimai.
Logotipas —
Paveikslėliai (screens) —
Trumpas aprašymas Rich text, rodomas kaip badge.
Aprašymas Rich text: galimybės, logika, instrukcijos, nuorodos.

Kainodara

  • Planas: Mokamas / Nemokamas
  • Fiksuotas mokestis organizacijai / mėn
  • Fiksuotas mokestis už kiekvieną aktyvaciją / mėn
  • Trial (dienomis, 0 arba teigiamas int)
  • Naudojimo užklausų apmokestinimas (+ rėžiai) / mėn
  • Naudojimo dokumentų apmokestinimas (+ rėžiai) / mėn
  • Pagal naudotojų skaičių organizacijoje (+ roles sąrašas)

Nustatymai

  • Leisti kelis įdiegimus įmonėje (instances)
  • Leisti visas įmones
  • Leisti atstovams modifikuoti savo organizacijose
  • Numatytas automatinis atnaujinimas (bool)
  • Atstovas (sąrašas)
  • Atstovo el. paštas dėl publikavimo
  • Atstovo el. paštas dėl klaidų

15. Versijos (duomenys, kūrimas, tvirtinimas)

  • Versijos Nr. formatas: MAJOR-MINOR-PATCH

  • Release notes

  • Būsena: Draft, Approving, Published (galima plėsti)

  • Scope: Global / Scoped — jei scoped, nurodomos organizacijos, kurioms versija prieinama

  • Mažinti scope negalima, jei organizacija jau įsidiegė.

  • Scope keičiamas visose būsenose, bet tik atstovo organizacijose.

Sąrašai versijoje:

  • Automatizavimai — visi, išskyrus įmonę / instance (jie nurodomi diegiant).

  • Parametrai — visa konfigūracija (header), be reikšmių; reikšmėms — migracijos scenarijus.

  • Prefiksas griežtai pagal APP kodą, pvz. APP-SABIS-AUTH.

  • Papildomi laukai — lentelė, laukas, pavadinimas, tipas.

  • Ext prefiksas pagal apps kodą, pvz. extAppSabisStatus.

  • Migracijos scriptas — pažymėta kaip FUTURE.

Veiksmai

  • Nauja versija iš esamos (Checkout / Branch) — dublikatas su būsena Draft.
  • Esant Draft — redaguoti, kurti automatizavimus, parametrus, ext laukus; vykdyti negalima — tam reikia įdiegti.

Publish

  • Atstovas gali publish iš Draft.
  • Jei tiekėjas yra atstovas — nėra approval proceso.
  • Jei Scope tik atstovo organizacija — nėra approval proceso.

Approve

  • Jei publish kito atstovo naujos versijos ir scope global — būsena Approving, pranešimas owner; peržiūra ir tada publish.

16. Diegimai ir naudojimas

Sąraše: aktyvūs ir deaktyvuoti diegimai.

Stulpeliai (santrauka): Organizacija, Įmonė, Sprendimas, Versija, Modifikuota, Active/Inactive, Sukurta, Atnaujinta.

Naudojimo statistika pagal įmonę / sprendimą + mėnesį; detali info į CSV.

  • Užklausų skaičius
  • Dokumentų skaičius

Rodoma pagal atstovo organizacijas; Rivile mato visus.

17. Automatinis platinimas

  • Sistema tikrina org su įdiegta versija; jei diegimas be modifikacijų ir organizacijoje įjungtas automatinis atnaujinimas — gali automatiškai atnaujinti.
  • Valdoma laiku arba nedelsiant.
  • Naujinimas gracefully: kai nevykdomi automatizavimai, arba jie „įšaldomi“ ir po užbaigimo — atnaujinama.
  • Sistema nustato sisteminiai pakeitimai: automatizavimai, parametrai, ext laukai.
  • Jei versijoje yra migracijos script — vykdoma org lygyje (ateityje / TBD).

18. Mokymams — santrauka

  • Marketplace siekia pakartojamų sprendimų vietoj vienaskių projektų.
  • Sandbox ir versijų / approval srautas — kokybė ir saugumas.
  • Atstovas vs klientas: modifikacijos, versijos, diegimai — svarbios rolės mokymuose.
  • Sutapdinti su automatizavimo konceptu (įmonė, globalu, instance).