Tanker fra INN/FKS:
- FKS-konsortiet har bedt om å være sent i køen. Har større og vanskelige prosesser de tror det blir vanskelig å overføre.
- Har begynt å tenke på rutiner og prosesser, og hvordan samordne dette og samarbeide bedre i sektoren. Har starta et underprosjekt, Livssyklusprosjektet, hvor de også har bedt inn flere institusjoner utenfor FKS. Ca. 9 institusjoner per nå.
- Teknisk er det gjort lite, av flere årsaker, blant annet at det har vært lite informasjon fra SIKT og prosjektet generelt. Veldig lite tekniske detaljer å finne.
- Annet fokus i nærmeste periode med UH Sak.
- Informasjon rundt innføring er én ting, men det er også litt åpent hvordan mer løpende drift skal løses, hvem som har ansvar for hva og hvordan man kan endre på hvordan ting skal gjøres.
Svar fra SIKT:
- Hvordan kjøre fellesprosjekt hvor alle skal inn døra helt på slutten, og de store kravene er det som løses for den første? Vi har jobba veldig hardt med den første (UiB).
- I hvilken grad alle diskusjonene som tas er av interesse for alle andre er usikkert. Er grunnen til at folk spør så mye for å finne argumenter for å bli med eller for å ikke skulle bli med?
- Vil ikke gå ut og si ting man ikke er sikre på, det skaper fort bare mer usikkerhet og problemer
- Først nå har det blitt landa skyløsning som funker, og vi kan si noe om hvordan det vil gå. Var ikke så festa tidligere.
- Det har vært lite informasjon, men vi tror at nå er det kommet langt til at vi med mer trygghet kan si ting. Så bør kunne være enklere å si mer framover.
- Dere som medlemmer vil kunne bestemme hvordan denne løsninga utvikler seg over tid, er ikke låst og vi må følge etter og endre alle prosesser til å passe inn.
- Bør ikke få mange som er med i alle prosesser, slik at diskusjonene stopper opp. Men nok til at man får en god dekning geografisk og fra forskjellige institusjoner
- Det er ikke SIKT som skal bestemme hvordan dette fungerer, men dere som brukere
Tanker fra OsloMet:
- Vi har jobba tett med SIKT, hva har vi i dag, tilsvarende arbeidet UiO har gjort, med mindre integrasjoner.
- Ikke bare teknisk, mye HR og andre deler av organisasjonen som må være med og gjøre endringer. Begynt å ta i brukt IntArk og OrgReg.
- Framtida blir et teknisk samarbeid, utveksling gjennom forum. SIKT kommer ikke til å levere all RI-kompetanse, vi må bygge det hver for oss, men de kan ha retningslinjer vi følger.
Svar fra SIKT:
- Erfaring fra disse 2 åra og refleksjon knytta til IAM: Informasjonsbehovet som er der ute er nok delvis fordi IAM historisk har vært eiendommen til IT-avdeling, og blitt laget lokalt.
- Veldig mange som skripter og programmerer og er veldig lavt nede for å løse problemer. Håper å lukke panseret så man ikke lenger må ned i detaljene for å løse problemer.
- Dyktige folk hos institusjonene skal ikke trenge å sitte fast i smådetaljer for å lage løsninger. Skal kunne jobbe på et høyere nivå.
- Vant til veldig tekniske detaljer fordi man er nødt til det for å kunne levere. Det er meningen at det ikke skal være nødvendig å ha så detaljkunnskap.
Kommentar fra INN:
- Når vi sier teknisk dokumentasjon må det ikke være helt nede på detaljnivå, men det finnes omtrent ingenting, og noe må man ha. Selv om man ikke trenger å vite alt, skjer ikke ting magisk.
- Involvering: Jo flere kokker, jo lenger tid tar det, det er også erfaringen fra Livssyklusprosjektet med 7-9 institusjoner. Men på et punkt må man kunne ha mulighet til å si noe og få informasjon om hva som skjer.
- For å kunne ha tilbakemeldinger og komme med innspill må vi vite hva vi svarer på. Det legges en del betingelser i løsningen basert på hvordan den lages.
- Nå er disse betingelsene nesten bare satt av UiB ettersom løsninga piloteres der. Det er potensielt et større problem.
Tanker fra UiT:
- UH Sak i drift snart, IAM skal jobbes med fra februar og i drift i april om alt går etter planen. Har begynt å rigge prosjektet og hatt en nyttig tur til Bergen.
- UiB var veldig ærlige på hele prosessen og de fikk mye gode innspill på ting til sin prosess. Viktig å samarbeide og utveksle kunnskap.
- Skal ta i bruk GREG, og ser at mange er veldig hissig på å være med i prosess for innføring, og det er nyttig. Også videre for IAM etter dette.
Tanker fra OsloMet:
- Teknisk dokumentasjon: Fra teknisk side følte vi at vi i starten fikk lite informasjon, men i seinere tid har vi opplevd at det vi egentlig mangler informasjon om er hva som egentlig kommer ut av IAM. Hva må vi fortsette å dekke selv av komponenter, og hva dekkes og skal inn i IAM? Dette har blitt bedre og vil nok fortsette å bli tydeligere.
Svar fra SIKT:
- Den løsninga man har i dag kalles ofte for IAM, men er alt mulig utenfor også, ting som er bygd opp rundt men har vokst seg ut til å løse andre ting også. Tilsvarende som hvordan UiO snakket om, hvor Cerebrum har og fortsatt delvis løser veldig mye mer enn det egentlig var tenkt til originalt.
- Skal vi løse alt som ikke har med IAM inn i løsninga eller skal vi nå splitte opp og rydde i systemet? Tar mer tid.
- UiB valgte å rydde i alt. OsloMet beholdt gammel løsning litt for å kjøre noen ting i parallell.
- En del som har vokst så store at man ikke lenger vet alt det skal løse eller hvorfor (f. eks. Cerebrum nevnt tidligere av UiO).
- Har dere ikke kontroll på egen modell i dag er det kanskje lurt å få rydda.
Supplering fra OsloMet:
- Kjører også BAS (IAM) parallelt, funker omtrent som i dag, men skal være read-only, den leser kun fra andre systemer.
- Integerer med mye, har data som ikke finnes noe annet sted i dag. Veldig tilsvarende Cerebrum, system som har levd lenge, har man problem putter man det i BAS og så løser det problemet.
-