Gå til innhold

Kutter koding: Mener Nav kunne spart 75 prosent med dette norske systemet [Ekstra]


Anbefalte innlegg

Videoannonse
Annonse

Det som beskrives i artikkelen, har man jo vært i stand til å gjøre med stort sett alle de store ERP/CRM systemene de siste 30 årene. Til og med enkelte 4GL systemer på 90-tallet kunne vel til en viss grad plasseres i denne kategorien. A journalisten hos digi.no, ikke har nok kunnskaper til å spørre basisspørsmålet om hva som skiller N-able sin løsning i fra resten av bølingen er rett og slett dårlig håndtverk.

Det er likevel bra at et norsk selskap tar /Configuration over Code/ basert teknologi, og som ikke er knyttet til CRM/ERP, ut i markedet.

Dog, å få omtale på digi.no uten å engang ha en webside som presenterer løsningen - det er bare trist for N-able.

Det er fint om Bjørnemyr og Skumsnes, i en kommentar her på Digi, kunne utdypet litt mer teknisk hva løsnignen deres faktisk tilfører. Alle de store "No Code" leverandørene legger frem de samme argumentene vi leser om i artikkelen, så hva er egentlig fordelen med N-Able vs Force.com, MS Dynamics 365, OutSystems, Mendix, Appian, mfl? *

Force.com og Dynamics 365 er nok de mest utbredte PAAS løsningene per i dag, og er i bruk i fra alt fra Transport / Fleet Management Systems, og Hospitality Systems, til nøkkelferdige eiendomsmeglerløsninger og pasientjournalsystemer. I tillegg finnes det, som nevnt over, flere andre ikke-ERP/CRM systemer som til en viss grad lar deg gjøre det samme.

*) De nevnte systemene er tatt i fra øvre høyre del av Gartner Magic Quadrant (2019) for Enterprise Low-Code Application Paltform. I tillegg så regnes bla ServiceNow, Oracle APEX, Kony og Zoho med som utfordrere innenfor Low-Code løsninger.

 

  • Liker 7
Lenke til kommentar
  • 2 uker senere...

Interessant at de sier at man kan utvikle journalsystemer til en brøkdel av prisen, kun ved å kjøre kode i en database. Virker som de ikke kjenner særlig god til hva som er driverne til at dette koster penger. Det er IKKE utviklingen av journalsystemet.

Problemet ligger i at det er ca 50 til 200 systemer som journalsystemet skal snakke med, som igjen snakker med andre systemer igjen. Dette krever ekstremt mye koordinering, allokering av nøkkelressurser fra mange systemer, testing på testing på testing (lovkrav).

Bryte opp dette i mikrotjenester eller løse alt i et system vil begge deler gi problemer. Svært mange brukere, behov, oppretidskrav, masse integrasjoner til legekontorer med tilhørende egne systemer +++ Komplekst blir det uansett for å bli effektivt.

 

Hilsen en som faktisk har jobbet med journalsystemer.

Endret av morten7
  • Liker 2
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...