Ny LAMP-baseret platform skal afløse udskældte Skoleintra

Illustration: REDPIXEL.PL/Bigstock
Aula skal være kommunernes nye platform for kommunikation mellem lærere, elever og forældre. Forbedret brugerflade og bedre tilretningsmuligheder er blandt nyhederne.

En ny platform skal afløse Skoleintra som redskab til kommunikation mellem skole, forældre og elever. Der er plads til forbedringer, da Skoleintra ikke har det bedste ry blandt landets forældre til børn i folkeskolen:

»Det har været svært at tilrette til den enkelte skole. På forældresiden har det altid været en gammeldags platform,« siger Mette With Hagensen, som er landsformand i foreningen Skole og Forældre, der har været kritisk overfor det tidligere system.

Blandt andet har muligheden for at modtage beskeder været begrænset til systemets mobilapp, og det har også været svært at etablere for eksempel diskussionsgrupper på tværs af klasser.

Men det skulle der nu være råd for i Skoleintras afløser, som har fået navnet Aula.

»Usability er noget af det, der fylder allermest i tildelingskriterierne,« fortæller projektleder Jakob Volmer fra Kombit, kommunernes it-fællesskab. Det handler for eksempel om, at notifikationer er relevante for brugerne.

I det hele taget er markant øget brugervenlighed et succeskriterium i det nye system.

»Der er en løsning, som den enkelte kommune kan konfigurere. Aula er meget mere tænkt som konfigurerbart for kommunen end forgængeren. Det betyder, at kommunen kan udføre en planlagt strategi for, hvordan man vil kommunikere med brugeren.«

Læs også: It-professor: »Forældre har ikke specielt behov for et nyt kæmpe skolesystem«

Sikkerheden testes minutiøst

Den nye platform er britisk og hedder Frog ligesom firmaet bag. Produktet anvendes i 23 lande og med mere end 20 millioner brugere.

Systemet har bevist sin duelighed i store lande som Malaysia, fortæller Thomas Koefoed, der er projektleder hos Netcompany, som skal producere det nye system. Især sikkerheden er vigtig i et produkt, som håndterer massevis af følsomme oplysninger.

»Man skal skrive sin kode rigtigt og sørge for, at den er sikker, og når man har valgt et produkt som Frog, så er sikkerheden allerede godt afprøvet. Sikkerheden bliver også testet minutiøst. Man kommer ikke igennem denne leverance uden at bestå en meget omfangsrig sikkerhedstest, som udføres af et eksternt firma.«

Der skal være 25-30 udviklere på projektet, som bygger på den såkaldte LAMP-stak – Linux, Apache, Mysql og PHP. Udviklingen starter efter sommeren, og den endelige udrulning sker i 2019.

»Det, jeg synes er rigtig interessant i dette projekt, er brugerinvolvering. At sørge for, at vi får lavet en løsning, som passer til alle de forskellige brugertyper – en løsning, der skal være super brugervenlig for børn, forældre og lærere. Den helt centrale udfordring er, at det skal give en løsning, som fungerer ude i skolerne. Det er et fagsystem for lærere og en kommunikationsplatform for forældre og børn, samtidig med at systemet skal være fuldstændigt sikkert,« siger Thomas Koefoed.

»Det kræver ikke specielle kompetencer at drive den daglige administration. Jo mere konfiguration du stiller til rådighed, desto mere skal du have fokus på brugervenlighed, for at det fungerer i praksis, og dette er et område, vi har enormt stort fokus på i vores tilbud.«

Løsningen har allerede været igennem en række brugertests. Derudover skal Netcompany bestå fem yderligere tests i brugervenlighed undervejs, for at løsningen godkendes.

»Så der er mega-mega stort fokus på både brugervenligheden og sikkerheden.«

Meddelelsesbogen kan smides væk

Mette With Hagensen mener som repræsentant for forældrene, at et godt succeskriterium er, hvis det er naturligt for forældrene at have Aulas app på forsiden af deres smartphone. Det er Jakob Volmer fra Kombit helt enig i.

På den negative side peger Mette With Hagensen på, at systemet kan være en ‘meddelelsesbog‘ som dækker barnet fra 3 til 16 år, og som måske indeholder for mange oplysninger i for lang tid ad gangen. Men man kan heldigvis også smide meddelelsesbogen i skraldespanden i Aula, hvis den enkelte kommune ellers ønsker at stille den funktionalitet til rådighed for brugeren.

Firmaet bag SkoleIntra, Itslearning A/S, har efter udgivelsen oplyst, at selskabet vil fortsætte med at udvikle, markedsføre og drive SkoleIntra, og at dette også vil være tilfældet efter introduktionen af Aula.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (30)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jonas Thomsen

Ud fra valget af LAMP-stakken, konkluderer jeg at de laver en web-løsning. Det undrer mig, hvis man ønsker at ramme forældrene, som jo ikke nødvendigvis sidder ved et skrivebord og venter på at der kommer noget i Aula, som de skal tage stilling til. Faktisk er de mobile og derfor burde man have designet løsningen til mobile first.

  • 0
  • 12
Jan Gundtofte-Bruun

Jamen dog. Det lyder næsten som om, nogen har fattet at den gamle model ikke duer -- og her tænker jeg ikke så meget SkoleIntra specifikt, men det her lyder ikke som den gængse "vi skal udvikle noget helt nyt fra bunden helt selv".

Hurra?

  • 5
  • 0
Lars K. Hansen

Rolig nu...

Der står jo i artiklen at PHP bruges sammen med mySQL, Linux og Apache. Så sarkasme og ikke-sarkasme er helt unødvendigt her.

Jeg tror diverse web-statistikker vil vise, at der ikke er noget i vejen med LAMP konstellation.

Hvis vi dropper mudderkastningen et øjeblik, vil jeg gerne hylde den person som tog beslutningen om IKKE at kode noget fra bunden... Hvor er det fedt at der er blevet valgt et gennemtestet produkt som bruges mange andre steder.

  • 11
  • 1
Mikal Schacht Jensen

Ud fra valget af LAMP-stakken, konkluderer jeg at de laver en web-løsning.


Det er en ikke en konklusion som du kan udlede.

Apps til mobile enheder benytter som regel også en server backend, med http som kommunikationsprotokol. Det er der intet usædvanligt ved. En LAMP-stak kan uden problemer understøtte både en webbaseret- og en mobil app frontend på samme tid.

"Mobile first" refererer specifikt til princippet med at designe et website til at blive vist på mobile enheder, og så aktivere evt. specielle tilpasninger for andre platforme (pc) når aktuelt, istedet for omvendt som var standarden i mange år. "Mobile first" har ikke som noget at gøre med arkitektur, eller valg af teknologi stak i et IT system.

  • 6
  • 0
Peter Hansen

.... eller hvis man tager LAMP bogstaveligt, hvorfor et sprog som php skal inddrages.


P'et i LAMP skal netop ikke tages bogstaveligt.

Det skal det måske i dette projekt - givetvis af historiske årsager - men generelt refererer P'et bare til et effektivt, højniveau scriptingsprog (Perl, Python, PHP, Ruby m.v.).

Generelt skal LAMP vel i disse tider bare tages som shorthand for en client/server-arkitektur baseret på open source-platforme.

  • 3
  • 1
Jonas Thomsen

Jeg er helt bevidst om, at en mobil løsning også kræver en backend. Jeg er også klar over, at en sådan backend (API) kan laves i PHP, men jeg har endnu til gode at se denne teknologi anvendt effektivt der. Til gengæld ser jeg masser af websites baseret på LAMP.

"Mobile first" refererer specifikt til princippet med at designe et website til at blive vist på mobile enheder

Nej, Mobile First siger ikke noget om website. Mobile First handler om at skabe en "løsning", som er optimeret til mobile platforme frem for til andre. Nu bliver det jo nemt religiøst, men jeg har også til gode at se en god mobil oplevelse baseret på responsive web eller for den sags skyld dedikeret mobilt web.

  • 0
  • 3
Kevin Johansen

Okay, at foreslå "mobile first" behøves måske ikke at få SÅ mange down-thumbs...

Men altså, når man ikke ved eller ikke dikterer HVILKE enheder et system skal virke på (mobil, PC, TV etc.) så skal man ikke udvikle "noget"-first. Så skal man tilpasse UI til skærmstørrelse og interaction/dataflow til enhedskapacitet osv. MEN det koster altså kassen, ikke kun I design, men også I datadesign og workflow design

  • 0
  • 2
Anders Poulsen

Hvis man går ud i byen og køber et gennemprøvet standardsystem, hvordan i alverdens riger og lande kan det så tage 25-30 mand mindst 1,5 år at "udvikle" løsningen?
På den tid kan man bygge et temmeligt stort system HELT fra grunden OG have god tid til overs til at teste for skkkerhed.
Det lyder på mig som om man NETOP gentager fortidens fejl, ved at købe et standardsystem og så skulle lave så mange rettelser ovenpå efterfølgende at det er helt meningsløst.

  • 6
  • 1
Anders Poulsen

"»Man skal skrive sin kode rigtigt og sørge for, at den er sikker, og når man har valgt et produkt som Frog, så er sikkerheden allerede godt afprøvet".
Så må man sandelig ikke håbe at de ca 72.000 udviklertimer de regner med at putte i projektet medfører at der bliver skrevet ny kode, for med det argument lyder det jo som om manden ikke regner med at hans udviklere er i stand til at skrive sikker kode!

  • 2
  • 1
Christian Hansen

Jeg synes det lyder særdeles betryggende at de har sat godt med tid af til udviklingen. Husk at "udvikling" langt fra kun betyder "programmering" i moderne IT projekter.

At udvikle et system, der skal anvendes af 2 millioner borgere, har stor gavn af en betydelig mængde udviklingstimer - også selvom der anvendes et standardprodukt som kerne. Og tænk på hvor mange timer der skal til for at sikre den rette organisatoriske implementering ude i kommuner og skoler.

Jeg vil gætte på at de fleste af udviklingstimerne ikke går til at nyudvikling eller ændring af kernen, men i stedet bruges til, igennem omfattende involvering af brugerne, at designe den rette løsning.

  • 2
  • 0
Janus Knudsen

En kommentar om at det er en god idé at købe noget færdigt og i artiklen står der 20-25 mand i 1,5 år.
Det er det rene vanvidsprojekt igen. Igennem mine snart 25 år har jeg aldrig hørt om et "tilpasningsprojekt" der varer omkring 50.000 timer.

Skoleintra handler om at lærere, elever og forældre kan kommunikere med hinanden. Den slags system burde kunne udvikles under 2000 timer og det er endda et absolut topklasse system så.

Hvem betaler for det her?

  • 4
  • 1
Hans Torm

Ang. kommentar om åben API: Dette var centralt i det konkurerende bud der blev fravalgt af KOMBIT. (I den sidste ende var der kun to leveramdører tilbage da to af de andre kvalificerede leverandører valgte ikke byde alligevel.)

Og, ja, hvorfor det ikke var en central del af selve udbudet er en fortsat gåde.

  • 2
  • 0
Hans Torm

Kravssætningen i udbuddet gjorde at det i praksis var umuligt at byde med en standard-løsning, selv om det var det KOMBIT efterlyste.

Tag ikke fejl. Der er min overbevisning at der kun er valgt en standardløsning på papiret. I praksis bliver der tale om et nyt system, deraf udviklingstiden. Og nej, ingen ville kunne levere på det kravsatte på 2000 timer. Selv 50000 kan blive stramt.

  • 1
  • 0
Janus Knudsen

Kravssætningen i udbuddet gjorde at det i praksis var umuligt at byde med en standard-løsning, selv om det var det KOMBIT efterlyste.


Hej Hans, ok. Det lyder som om du ved lidt mere end hvad der lige står skrevet i artiklen og derved kan du naturligvis også bedre komme med et rough estimate på timeforbruget.
- Ved du hvor man kan finde kravspecifikationen?

Er der nogen der ved noget om hvorfor den slags kommer i udbud? Er det ikke valgfrit for skolen at vælge det bedste system?

  • 0
  • 0
Hans Torm

Materialet var i starten frit tilgængeligt her: https://eu.eu-supply.com/app/rfq/publicpurchase.asp?PID=175221
Det er dog senere blevet lukket af så det kun har været tilgængeligt for budgivere, uden at jeg kan forklare dig hvorfor.
Materialet var dog så omfattende at alene besvarelsen af buddet har taget et par årsværk pr. leverandør. Omkostninger som i hvert fald vinderen jo vil sørge for bliver dækket.
Det er værd at bemærke at den samlede pris i runde tal for Aula fra leverandørens side må antages at ligge imellem 200-300 millioner. Dertil skal ligges yderligere 100-150 millioner til STIL for støttesystemer og KOMBIT for udbud og projektstyring. Denne omkostning dækker udvikling, udrulning, undervisning og 10 års drift. Alt i alt mange penge, men egentligt på den billige side taget projektets størrelse i betragtning.

  • 2
  • 0
Jan Nielsen

Det er det rene vanvidsprojekt igen


Enig..
I virkeligheden er der 3 systemer i et:
1. Skolernes ressourcestyring: skemaplanlægning, lærerressourcer og lokaler
2. LMS (Learning Management System): digitale UV-midler, undervisningsplanlægning, didaktik osv.
3. Kommunikation med forældre: skema, kontaktbog osv.

I forhold til 1 og 2 har forældrene ingen eller meget begrænset behov for selvstændig adgang. Hvis forældrene har brug for at interagere med LMS-systemet, bør det vel foregå sammen med barnet, f.eks. hvis man skal hjælpe med lektier.

I forhold til punkt 3:
Hvad er der galt med email, publicerede kalendere og to-do's?
Hvorfor skal kommunikationen absolut pakkes ind i diverse IT-systemer, når vi ved at samtalen som dialog-form er den absolut bedste?

Burde man ikke fokuserer på basis IT-dannelse? - Fremfor at få serveret en overfyldt flødeskumslagkage som Aula.
Jeg frygter at aula bliver et nyt "to big to fail"-system, og er utroligt glad for at min yngste datter er på de sidste år i folkeskolen!

  • 1
  • 0
Hans Torm

Er der nogen der ved noget om hvorfor den slags kommer i udbud? Er det ikke valgfrit for skolen at vælge det bedste system?

Udbudet kom som en del af den samlede pakke der kaldes Brugerportalsinitiativet. Du kan læse om det her: http://www.kl.dk/Kommunale-opgaver/Born-og-unge/Digitalisering/Brugerpor...
Idéen har været at have en fælles tilgang til for alle kommuner i landet. Man har valgt at bibeholde den frie konkurrence for læringsplatforme, men at lave et samlet udbud for kommunikationsplatformen (Aula). Alle kommuner har tilsluttet sig Aula for folkeskolerne og majoriteten også for dagtilbudsområdet.
KL og KOMBIT argumenterer for at Aula også er konkurrencefremmende, da det er tanken at Aula skal være åben for at tredjepartleverandører kan levere indhold ind i Aula i for af widgets eller lignende. Personligt mener jeg man har valgt at udskifte et de facto monopol, SkoleIntra, med et reelt tildelt monopol, da der i dag allerede findes rige muligheder for tredjepartsleverandører at få indhold ind i SkoleIntra på lignende vis.
Skolerne skal nok forvente at blive pålagt at bruge Aula da den er del af en samlet tværpolitisk aftale, og aftalen mellem kommunerne, KL og KOMBIT binder dem til at betale for Aula, men det kan da ikke udelukkes at kommuner rundt omkring vil tillade skolerne at forsætte på SkoleIntra for egen regning.

  • 2
  • 0
Hans Torm

  1. Skolernes ressourcestyring: skemaplanlægning, lærerressourcer og lokaler
  2. LMS (Learning Management System): digitale UV-midler, undervisningsplanlægning, didaktik osv.
  3. Kommunikation med forældre: skema, kontaktbog osv.

Delvist forkert. Ovenstående er hvad Brugerportalsinitiativet i sin helhed dækker. Mere specifikt kan jeg sige om de enkelte punkter:

  1. Skemaplanlægning og lærerresourcer planlægges stadig i skolernes eksisterende administrative løsninger. Disse er med overlæg ikke medtaget i Aula. Lokaleplanlægning var en option i Aula hvis jeg husker korrekt.
  2. LMS er heller ikke del af Aula. Derfor er det noget spøjst at man vælger et LMS system, FROG, som udgangspunkt for Aula.
  3. Denne del er hvad der dækkes af Aula.

Ang. din kritik af hvor for ikke bruge standard systemer til dette, så gør kravsætningen i udbuddet det svært, men det var faktisk samtidigt hvad KOMBIT til dels ellers lagde op til i udbuddet. Ja, materialet var mange steder dybt selvmodsigende. Udbudet manglende en samlet gennemført vision, og var klart resultatet af et forsøg på at samle mange modstridende brugerkrav, desværre uden succes er min egen holdning.

  • 5
  • 0
Jan Nielsen

Denne del er hvad der dækkes af Aula.


Interessant - Så må vi jo håbe at kommunikation bliver en halv milliard bedre...
Vores eget brug af Skoleintra har begrænset sig til kontrol af ugeplan, diverse beskeder om fællesarrangementer, tilmeldelse til årlige skole/hjemsamtaler og kontaktbog nogle få gange om året.
- Gad vide hvordan de vil gøre det tilsvarende bedre

Iøvrigt rart at få at vide at de ikke benytter det som LMS,- selvom det sætter endnu større spørgsmålstegn ved prisen

  • 0
  • 0
Henning Wettendorff

Lokaleplanlægning var ikke en option, Hans, men i Aula-specifikationen:
"Nogle Ressourcer administreres i Løsningen (almindelige lokaler f.eks.) og andre modtages fra andre systemer (f.eks. undervisningslokaler fra skemalægningssystemer)."
Ærgerligt at kravene ikke længere er offentligt tilgængelige (dokumentoversigten ses via dit link). Til orientering findes et notat om funktioner i BPI ift. SkoleIntra, som siger at udover almindelig kalenderfunktionalitet skal kalender blandt andet understøtte "Booking af læringsmaterialer, vikarer, lokaler og tekniske ressourcer" http://www.kombit.dk/sites/default/files/user_upload/documents/Samarbejd...

Du har ret i, at "samarbejdsplatformen" Aula er noget ganske andet end Frog Education, som primært er et LMS.
Da det danske "brugerportalinitiativ" (BPI) består dels af fælleskommunal samarbejdsplatform (Aula) og dels af privatleverede læringsplatforme (LMS'er) er relationen mellem de to dele yderst vigtigt. Manglende integration, tilsagn ved dataudveksling, dobbeltklikkeri som lærerhverdag, etc. - farerne lurer mange steder i udbudsmaterialet. Det giver på den måde god mening at have en erfaren LMS-partner om bord, som ikke er en af de danske storleverandører af samme. Når jeg skimmer kravene til Aula giver det også god mening, at der vil ryge en lille halv mia. på udviklingen og implementeringen (ja sikkert langt mere på sidstnævnte, men de udgifter kommer til at ligge ude på skolerne og i kommunerne).

  • 2
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize