Yleiskäsite (ks. tiptop-määrittely)

Hakijasta tulee opiskelija hakuerän perusteella, opiskeluoikeus kuuluu johonkin ryhmään; opetussuunnitelmassa ryhmällä ei käyttöä; pitkälti kyse, että tulee päästä tavoitetilan pohdinnassa nykytilanteesta eroon; aikatietoakaan ei tarvitse olla opetussuunnitelmalla vaan riittäisi opintojaksoille

Avainkysymys on, periikö opiskelija ryhmältä tietoja? Ei, korkeintaan tuontivaiheessa siinä mielessä, että pitää täydentää tietoja

Ryhmätietoa tarvitaan ainoastaan kausitiedoissa

Ryhmäkäsite kaikissa järjestelmissä, vaikea tehdä geneeristä määritelmää

Tällä hetkellä winhaan luodaan ryhmiä, jotka siirretään peppiin - viittauksia järjestelmien välillä ehkä tarpeettomastikin

Tarvitseeko suunnitteluvaiheessa ryhmistä vielä tietää mitään? Ryhmän tunnus oikeastaan merkitsevä asia, ei sidos ryhmäpalveluun

Prosessi: opetuksen suunnittelu + ryhmätunnukset - > datan julkaisu; koulutuksen järjestäminen, ryhmätunnukset luovat pohjan ryhmien luomiselle ja jäsenyyksille; tällöin edellinen vaihe määrittää seuraavan, tieto rikastuu koko ajan; tällä menettelyllä palvelut toimisivat itsenäisemmin

Ryhmiä voisi tässä mallissa syntyä mistä tahansa

Tiivistettynä: ryhmät syntyvät vasta, kun niitä tarvitaan; pepissä puhuttaisiin siis vain ryhmätunnuksista

Ryhmällä ei tule pitää yllä opiskelijaan liittyviä tietoja

Nykyään ryhmän kautta liitetty opiskelija johonkin opetussuunnitelmaan, nyt voitaisiin sitoa suoraan opiskeluoikeus opetussuunnitelmaan; toteutukset voidaan osoittaa opiskelijoille tätä kautta

Perusrekisterissä historiataulun kautta saadaan muutoshistoria selville (saapumiserää tarvitaan vain perusrekisterissä, tarvitaanko tälle ryhmäpalvelua)

Vuosisuunnittelun näkökulmasta opiskelijamäärä on keskeinen tieto

Moni taustajärjestelmä pohjautuu ryhmien käyttöön - nämä täytyy huomioida ratkaisussa; tavoitetila täytyy suunnitella huolella ja tarvittaessa miettiä myös "exit-strategia" ryhmäkeskeisyydestä

Tamkissa lennossa vaihdetaan saapumisryhmää nykyään, jopa tutkinto-ohjelmasta toiseen samalla alalla; Virran näkökulmasta näyttäisi olevan helpompi toimia tällä tavoin

Vaikuttaa siltä, että saapumisryhmä ja hakuerä ovat yksi yhteen; voidaanko luopua koko saapumisryhmän käytöstä

Missä tilanteissa nyt ryhmillä tärkeä rooli:

• viestinnälliset tarpeet, kun viestintä voitu kohdistaa suoraan halutulle joukolle
• lukujärjestyksen julkaisu ryhmäkohtaisesti, suunnittelu ekonomisesti siten etteivät mene päällekkäin, kun toteutuksilla on ryhmäkoodi
• tarkistaminen että opinnoista kaikki tehty
• harjoittelujen ajoittaminen ryhmäkohtaisesti

Peppi ei siis tarvitsisi ryhmäpalveluun sidosta, helpottaisi palvelujen rajausta ja vähennetään riippuvuuksia järjestelmien välillä; ryhmäpalvelu voitaisiin toteuttaa niin, että tarvitaan aina tieto ryhmätunnuksesta; eli - erotetaan käsitteet ja rajataan palveult tarkemmin: ryhmätunnus ja käyttäjäryhmä

Onko ryhmäpalvelu täysin erillinen mokkula, jota perusrekisteri ja peppi käyttäisivät; organisaatio voisi ottaa kumman tahansa käyttöön ilman tarvetta ottaa toista sisarjärjestelmää käyttöönsä?

• jos käyttäjäryhmä koskee vain perusrekisteriä, sidoksia ei tarvitse luoda peppiin
• pystytäänkö jakamaan käsitteitä palvluieden välillä; vain perusrekisterissä luotaisiin ryhmiä, johon liitetään ainoastana tunnus muualta (pepistä)

Missä vaiheessa tutorryhmät luodaan?

• ehkä jatkossa ohjaajat itse luovat; tuskin tarvitaan suunnitteluvaiheessa
• pepin puolelle käyttöliittymä (siis opettajan/ohjaajan työpöydälle)

Perusrekisteri itsessään ei tarvitse ryhmiä - onko käyttötarve hauissa? Vai tarvitaanko ainoastaan lukujärjestyksissä ja toteutuksissa?

• Miksi se siis olisi perusrekisterissä, kun perusrekisterissä tarve näyttää redusoituvan hakuihin?

Ryhmäpalvelu lopulta siis Pepissä? Vai erillisenä mokkulana?

Tietoja ei joka tapauksessa tulisi kopioida edestakaisin

Ryhmillä ei tee paljoakaan ilman opiskeluoikeuksia jotka kytketään niihin, ja opiskeluoikeudet on perusrekisterissä joten siksi "ryhmäpalvelukin"

Ajoitussuunnitelma tarvitsee ryhmiä, mutta se ei itsessään suoraan opetussuunnittelua - osuu jonnekin opetussuunnittelun ja vuosisuunnittelun välille

Ryhmistä ei oltane valmitta kokonaan luopumaan

Ratkaisu tulisi löytää suunnittelujärjestelmän toimivuuden näkökulmasta

Ryhmäkäsitteen sisältö muuttuu prosessin eri vaiheissa, mikä vaikeuttaa käsitteen ymmärtämistä

Arkkitehtuurin näkökulmasta asioiden ylläpitämistä kahdessa tai useammassa paikassa ei ole toivottavaa; tämä keskeinen ohjenuora sekä ryhmien että koodistojen osalta

• Koodistopalvelu yhteen paikkaan on helppo ratkaisu
• Ryhmät vaikeampi generalisoida
  • riippuvuuksien vuoksi (tarpeetonta monimutkaisuutta)
    • ehdotetulla toimintatavalla palveluiden jako helpompi toteuttaa
    • ryhmätunnukset olisivat aina pepin omistuksessa ja kun tehdään perusrekisterissä operaatioita, luetaan tieto pepistä
    • SOA-näkökulma
    • vrt ehdotettua mallia opintojakso vs. opintojakson toteutus

Ryhmätunnusta ei pitäisi voida pitää yllä kuin yhdessä paikassa

• ei ehkä toimiva ajatus, että olisivat vain "merkkijonoja"
• ainoastaan perusrekisteirssä ainoastaan ryhmiä, ei pepissä (siis palvelumielessä)

Keskipitkällä aikavälillä opetussuunnittelun tulee olla mahdollista myös ilman ryhmiä

Hopsin kautta syntyy varsin luotettava tieto tarvittavista toteutusten lukumääristä

Miten ajallisesti syntyy tarve eri ryhmille (esim. tuutoriryhmille); tulee huomioida ratkaisumallissa

Kustannuspaikka: liittyykö ryhmään vai koulutusohjelmaan - ko.n kustannuspaikka periytyisi toteutuksille

Kaksi käyttötapaa ryhmille

• vuosisuunnittelussa käyettään suunnittelun apuna
• perusrekisterissä ryhmään liitetään vain käyttäjiä

Toimittajaa pyydetään:

• huomioimaan tämän keskustelun vaatimukset
• ekosysteemin yleiset arkkitehtuurivaatimukset
• laatimaan ehdotuksen / ehdotukset, millä tavoin toimitaan
  • ryhmäpalvelu (perusrekisterissä (tai itsenäinen)) jota molemmat käyttävät
    • syncaus toimii tarvittaessa (huom ryhmään liittyviä tietoja täytyisi pystyä myös syncaamaan)
    • perusrekisteristä suoraan tietojen lukeminen toimii tarvittaessa
  • tunnukset pepissä (merkkijono), käyttäjäryhmät perusrekisterissä (toki pepissä voi olla nappi "luo ryhmä")

Ratkaisu: "Uusi Peppi-koodistopalvelu"?

• Pepin yksikköpalvelu
• Perusrekisterin koodistot
• Ryhmäkäsite

Käsite luotu perusrekisterin määrittelyssä: millä tiedoilla opiskeluoikeus tuotu järjestelmään (tämän avulla päästään palaamaan mistä hakukohteesta ja millä tiedoilla opiskelija tuot) "jäädytetty tilanne" lähtötilanteesta

Tietoja täydennettävä tuontivaiheessa, sillä kaikki tieto ei tule Opintopolusta / Oilista

Vrt. hakuerä nykyään

Winhassa käytetty siten, että saapumisryhmä pilkottu pienempii osiin esim. opetuksen toteutuksen näkökulmasta, jotta mahtuvat tiloihin; tuutorryhmät ovat yksi esimerkki hallinnollisesta ryhmästä; samat tiedot, mutta eri tyyppi

KOulutusohjelma voi luoda hallinnollisia ryhmiä "vapaasti"

TAMK:ssa opetuutoriryhmä ja hallinnollinen ryhmä ei ole sama; opetuksen suunnittelu tehdään hallinnollisille ryhmille