Tarjouspyyntöön liittyvät kysymykset - Roopen täydennyksiä

Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 1/26
Yle IAM (YLE20120031)
Tarjouspyyntöön liittyvät kysymykset ja
vastaukset
1 Tarjouspyyntöön liittyvät kysymykset
1.
2.
3.
4.
5.
6.
7.
Tarjouksen tarjouspyynnönmukaisuuden arviointi:
Mitä Yle sisällyttää olennaisiin puutteisiin tässä kohtaa?
Vastaus: Tarjouspyynnössä on varsin selvästi kuvattu, mitä tarjousten edellytetään
sisältävän, jotta ne vastaavat tarjouspyyntöä, eivätkä sisällä olennaisia puutteita.
Lukekaa siis ystävällisesti tarjouspyyntö kaikkine liitteineen huolella!
Voidaanko käyttää alihankkijan referenssejä?
Vastaus: Kyllä voi, mikäli alihankkijan osuus tarjotussa ratkaisukokonaisuudessa on
merkittävä.
Ovatko kaikki V1 tason vaatimukset arvoltaan samanlaisia tarjouksen arvioinnissa,
vai ovatko jotkut vaatimukset kriittisempiä kuin toiset?
Vastaus: V1 -vaatimukset ovat siinä mielessä samanarvoisia, että ne kaikki ovat
ehdottomasti pakollisia vaatimuksia.
Miten otatte huomioon tarjouksia pisteytettäessä/vertailtaessa jos johonkin V1vaatimukseen on vastattu ei?
Vastaus: Tarjous ei tuolloin vastaa tarjouksen vähimmäisvaatimuksia ja joudutaan
hylkäämään. V1 -vaatimukset ovat ehdottomasti pakollisia vaatimuksia.
V1 -vaatimuksiin tulee kyetä vastaamaan ”kyllä”.
Otetaanko hinnoittelussa huomioon vain ”kyllä” vastaukset?
Vastaus: Hinnoittelussa otetaan huomioon sekä ”kyllä” että ”osittain” vastaukset.
Ne kaikki toiminnallisuudet ja palvelut joihin tarjoaja on vastannut ”kyllä” tai
”osittain” ovat mukana tarjouksen sisällössä ja niiden on sisällyttävä annettuun
hintaan.
Liite 3:n, välilehdet 3 ja 4: Jos vastaamme ”kyllä” / ”ei” / ”osittain” Vastaussarakkeessa, niin rajoittaako se sitä mitä voimme vastata ”Valmius” sarakkeessa vai
voimmeko vapaasti ottaa minkä tahansa vaihtoehdoista (peruspaketissa,
parametroitava, räätälöitävä, ei saatavissa)?
Vastaus: Valmius-sarakkeen vaihtoehdon voi valita vapaasti (mutta jos on
vastannut vaatimukseen ”ei” niin valmius-sarakkeen ainoa relevantti vaihtoehto on
vastaavasti ”ei saatavissa”).
Liitteen 3 Hankintakohdetta koskevat vaatimukset välilehdissä 3-IAM-toiminnalliset
vaatimukset ja 4-IAM-täydentävät vaatimukset pyydetään Vastauksen ja
Vastauksen perustelun lisäksi Valmius (sarake E). Mitä tällä käytännössä
tarkoitetaan ja millä tavalla siihen tulee vastata?
Vastaus: Ko. sarakkeeseen kirjataan kuinka valmiiksi toteutettuna ja käytössä
testattuna vaatimuksessa haluttu toiminnallisuus tarjotusta tuotteesta löytyy.
Valmius-sarakkeen tiedoilla pyritään kartoittamaan mm. tarjotun ratkaisun
räätälöinnin tarve.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 2/26
8.
9.
10.
11.
12.
13.
Saammeko ”Valmius” -sarakkeen vaihtoehdoista tarkat määrittelyt (peruspaketissa,
parametroitava, räätälöitävä, ei saatavissa)?
Vastaus: ”Peruspaketissa” = toiminnallisuus ja käyttöliittymä ovat helposti
otettavissa käyttöön lähestulkoon ilman konfigurointia; ”parametroitava” =
toiminnallisuus tai käyttöliittymä vaatii konfigurointia tai esim. yksinkertaisia
skriptejä; ”räätälöitävä” = toiminnallisuus vaatii kehitystyötä käyttöliittymä- tai
lähdekooditasolla tai monimutkaisia skriptejä; ”ei saatavilla” = toiminnallisuutta ei
ole saatavilla, eikä tähän haluta tarjota räätälöityä ratkaisua
Vaikuttavatko ”Valmius”-sarakkeen vaihtoehdot pisteytykseen ja jos, niin millä
tavoin?
Vastaus: Valmius-sarakkeen vaihtoehdot vaikuttavat pisteytykseen siten että
toiminnallisuudet jotka ovat valmiiksi ”peruspaketissa” tai ”parametroitava” ovat
Ylen mielestä houkuttelevampia (tyypillisesti kokonaistaloudellisesti edullisempia)
kuin ne jotka on ”räätälöitävä”. Pisteytysvaikutuksen suuruus on kuitenkin
vaatimuskohtainen eikä ole siten yleistettävissä.
Onko asiakas valinnut jo teknologian, millä he haluaisivat toteuttaa ratkaisun? Jos
on, niin mikä on valittu teknologia?
Vastaus: Teknologiaa ei ole valittu. Ratkaisun tulee kuitenkin teknologialtaan
soveltua Ylen arkkitehtuurin mukaisessa ympäristössä käytettäväksi ja sen tulee
täyttää tekniselle toteutukselle esitetyt vaatimukset. Ratkaisun ajoalustojen osalta
suositeltavia ovat Java tai .net -pohjaiset ratkaisut. Ratkaisun käyttämäksi
tietokanta-alustaksi suositeltavin on Ylen jaetussa ympäristössä sijaitseva MS
SQLServer, mutta myös muita vaihtoehtoja voi perustellusti esittää käytettäväksi.
Merkittävä teknologiaan liittyvä rajaus on se, että emme hae SaaS -mallin mukaista
ratkaisua.
Jotkut vaatimukset ovat hyvin (tuote)spesifisiä siitä miten ratkaisun halutaan
toimivan. Jos vaatimuksesta voi päätellä mikä on vaatimuksen haettu lopputulos,
voiko tarjota vaihtoehtoista ratkaisutapaa mikä sopii paremmin tarjouksessa
olevaan tuotteeseen?
Vastaus: Kyllä voi, ja tämä on tarkoituskin. Käyttötapaukset ja vaatimukset on
monilta osin kuvattu loppukäyttäjäperspektiivistä käyttäen kuvitteellista
käyttöliittymää apuna tarvittavien toiminnallisuuksien määrittämisessä. Näitä
määrityksiä tulee soveltaa tarjottavan tuotteen ominaisuuksiin, räätälöintitarpeen
minimissä pitämiseksi. Vaatimuksen lopputuloksen tulee kuitenkin säilyä ja esim.
käytettävyys ei saa kauttaaltaan olla olennaisesti heikompi kuin vaatimuksissa ja
käyttötapauksissa esitetty malli on (mutta käytettävyys saa toki olla parempi!).
Miten asiakkaalla on resurssoitu ja sitoutettu tarvittava henkilöstö projektiin?
Vastaus: Projektiin ja projektiryhmän toimintaan osallistuu aktiivisesti
henkilöstöhallinnon, tietohallinnon, turvallisuuden sekä eri liiketoiminta- ja
järjestelmäalueiden edustajat. Sitoutuminen projektiin on hyvä kaikissa näissä
ryhmissä.
Haluaako asiakas hinnoittelun federointi-tuotteesta vai tarvitaanko vain liityntä
kertakirjautumistuotteista federointi-tuotteeseen?
Vastaus: SSO-kokonaisuuden tulee sisältää myös federointituotteen hinta mikäli se
ei kuulu SSO-tuotteeseen. Federointituotteen hinnan voi esittää yksikköhinnoissa
kohdassa ”Muu mahd. hintakomponentti”, selitteen kera.
Huom: Ko. kentän summa ei automaattisesti siirry vertailuhinta-välilehdelle, vaan
sama summa täytyy kirjata myös sinne.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 3/26
14. Liitteessä 1, useassa kohdassa ”Käyttötapaukseen liittyvät vaatimukset”. Näiden
kohtien otsikoissa on myös ”Prioriteetti” ja ”Yhteyshenkilö” kolumnit. Mitä näillä
tarkoitetaan? Onko niihin tarkoitus vastata? Jos on, niin mihin vastataan?
Vastaus: Kyseisiin kenttiin ei ole tarkoitus vastata.
15. Arvosanat: pyöristetäänkö arvosanat tasalukuihin arvioinneissa vai millä
tarkkuudella ne annetaan? Koskeeko tämä myös hinnan arvosanaa?
Vastaus: Vaatimuksiin liittyvät arvosanat annetaan yhden desimaalin tarkkuudella.
Sama tarkkuus koskee hinnan arvosanaa.
16. ”Liite 1 Ratkaisun määrittelydokumentti” sisältää toiminnallisia vaatimuksia, joita ei
ole mainittu liitteessä 3. Tuleeko tarjoajan ottaa näihin vaatimuksiin kantaa, ja
miten tällaiset kannanotot huomioidaan tarjousta arvioitaessa (esim. vaatimusten
luokittelu)?
Vastaus: Ratkaisun määrittelydokumentissa olevien vaatimusten osalta on
luokittelu todellakin jäänyt puuttumaan. Näistä vaatimuksista kuitenkin kaikki
ehdottomasti pakolliset ovat liitteen 3 vaatimustaulukoissa, tosin eivät välttämättä
kirjattuna täsmälleen samassa muodossa kuin määrittelydokumentissa. Täten
voidaan todeta, että käyttötapauksien yhteydessä olevat muut kuin liitteestä 3
löytyvät vaatimukset ovat rinnastettavissa vaatimustaulukon V2 -vaatimuksiin, eli
eivät ole ehdottoman pakollisia mutta vaikuttavat merkittävällä tavalla
käyttötapausten pisteytykseen.
17. Tuleeko tarjottava ohjelma olla suomenkielinen, vai käykö myös englanninkielinen
toteutus?
Vastaus: Tarjouspyynnön vaatimusliitteessä on mainittu vaatimukset kielisyyden
suhteen. Yhteenvetona: Loppukäyttäjien käyttöliittymän tulee olla suomenkielinen,
muut käyttäjäkohtaisesti valittavissa olevat kielet (mm. ruotsi, englanti) ovat
eduksi. Administraattorien käyttämät käyttöliittymät voivat olla englanninkielisiä.
Ohjeiden tulee olla saatavilla suomenkielisinä.
18. Tuleeko täytetyt tarjous-dokumentit toimittaa suomenkielisenä, vai voiko tiedot
olla täytettynä englanniksi?
Vastaus: Vastaukset vaatimuksiin sekä tarjous ylipäätään tehdään suomen kielellä.
Tuote-esitteet ja muut vastaavat oheismateriaalit voivat olla englanninkielisiä.
19. Vaikuttavatko CV:t tarjouksen pisteytykseen?
Vastaus: Palvelun toteutukseen tarjottavien asiantuntijoiden CV:t huomioidaan
arvioitaessa toimittajan osaamista, kokemusta ja kyvykkyyttä ja siten ne vaikuttavat
pisteytykseen kohdissa "IAM-ratkaisukokonaisuus ja sen toimitusprojekti" sekä
"IAM-sovellusylläpito-, tuki-, pienkehitys- ja asiantuntijapalvelut".
20. Vaikuttavatko referenssit tarjouksen pisteytykseen?
Vastaus: Referenssit eivät sinällään vaikuta pisteytykseen, koska ne ovat tarjoajan
soveltuvuutta koskevia vaatimuksia. Referensseiksi mainituista asiakkaista
tarjouspyynnössä kuvatulla tavalla selvitettävä asiakastyytyväisyys vaikuttaa
pisteytykseen kohdassa "Yleiset palveluvaatimukset".
21. Ilmeisesti pääosa kohdan 1 vaatimuksista pätee vain sovellusylläpito-, tuki-,
pienkehitys- ja asiantuntijapalvelut sopimuksen ollessa voimassa tai on
sovellustoimittajan ja asiakkaan välinen järjestely jollei em. sopimus ole voimassa?
Vastaus: Emme ole varmoja ymmärsimmekö kysymyksen täysin oikein, mutta
oletamme että tässä tarkoitetaan vaatimusliitteen välilehdellä 1 olevia vaatimuksia.
Kyseiset vaatimukset koskevat koko palveluyhteistyötä eli sekä toimitusprojektia
että ylläpitoa, kyseistä palvelukokonaisuutta koskevan sopimuksen ollessa
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 4/26
voimassa. Osa vaatimuksista toki soveltuu ensisijaisesti ylläpidon osa-alueelle ja osa
puolestaan koskettaa enemmän toimitusprojektivaihetta.
22. Kysymys tarjouspyyntönne seuraavaan kohtaan liittyen ”Hankinnassa haetaan
Ylelle toimitettavaa järjestelmäratkaisua, toisin sanoen ei haeta identiteetin- ja
käyttövaltuushallinnan palveluita pilvipalveluna tai muulla SaaS-mallilla.”:
Onko SaaS-mallin mukaisen ratkaisun tarjoaminen täysin pois suljettu vaihtoehto
hankinnassanne?
Vastaus: Kuten tarjouspyynnössä mainitaan, emme ole tässä tapauksessa
hakemassa SaaS-mallin ratkaisua.
2 Tarjoajan ja tarjouksen soveltuvuuteen liittyvät kysymykset
1.
Liite 2, sivu 2, kappale 3. Kysymys: Tarkoittaako kohta: ”Mikäli kuitenkin tarjoajan
vaatimusten vastauslomakkeessa on tästä poikkeavia vastauksia, tässä kuvattu
vastaus on ensisijainen yksittäisiin vaatimusliitteen V1-vaatimusten vastauksiin
verrattuna.” sitä, että jos tähän kohtaan vastaa kyllä, tulkitaan sen olevan kyllävastaus kaikkiin V1-vaatimuksiin, vaikka vaatimusten vastauslomakkeessa johonkin
kohtaan olisi vastattu ’Ei’?
Vastaus: Juuri tuota se tarkoittaa. Tarjoajan on kuitenkin syytä käydä huolella
erikseen läpi kaikki V1-vaatimukset ja arvioida, voiko se niihin sitoutua tarjousta
antaessaan. Hankintalain ja oikeuskäytännön mukaan tarjouspyyntö sitoo tarjoajaa
ja hankintayksikkö on oikeutettu vahingonkorvaukseen, mikäli tarjoaja ei pidä kiinni
siitä, mihin on tarjouksellaan sitoutunut.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 5/26
3 Määrittelyyn liittyvät kysymykset
1.
2.
3.
4.
5.
6.
7.
Onko kaikissa IAM-järjestelmän hallintaan tulevien kohdejärjestelmien
käyttäjätileissä uniikki tunniste jolla voidaan tunnistaa tilin omistaja (esim.
työntekijänumero)? Jos ei ole, niin kuinka monesta hallintaan tulevasta
kohdejärjestelmästä uniikki tunniste puuttuu?
Vastaus: Ylen henkilönumero on vain muutamassa järjestelmässä (mm. HERA, AD,
HenkHa, kulunvalvonta). Suurimmassa osassa järjestelmissä ei ole muuta uniikkia
tunnistetta kuin käyttäjätunnus. Ylen järjestelmissä käyttäjätunnukset kuitenkin
noudattavat selkeästi määriteltyä peruskaavaa aivan muutamaa poikkeusta lukuun
ottamatta.
Mitkä peruskäyttöoikeuksien kohdejärjestelmistä on liitetty ActiveDirectoryyn
tunnistautumista ja/tai authorisointia varten?
Vastaus: HERA, intranet (Sharepoint), tilanvarausjärjestelmä Tilari,
medianhallintajärjestelmä METRO.
Käyttöoikeuksien siirtymäajan hallinta, pitääkö järjestelmän tukea siirtymän
käsittelyä työnkuvan muutoksissa automaattisesti vai tehdäänkö muutokset
esimiehen (tai vastaavan henkilön) toimesta manuaalisesti osana muutosprosessia?
Vastaus: Työnkuvan muutokset (ja uuteen työnkuvaan liittyvät valtuudet) hyväksyy
aina esimies. Järjestelmän tulee kuitenkin hallita automaattisesti vanhaan
työnkuvaan liittyvät valtuudet ja niiden siirtymät.
Lisäoikeuksien hakeminen ja työrooli, tarkoitetaanko tässä työroolilla esimiehen
määrittämää henkilön työkuvaa ja onko henkilöllä yksi vai useampia työnkuvia
samanaikaisesti voimassa?
Vastaus: Tähän kysymykseen liittyy keskeisesti se seikka, miten käytetään termejä
työrooli ja käyttövaltuuspaketti. Työroolin voidaan käsittää olevan työnkuvaan
sidoksissa oleva kokonaisuus, käyttövaltuuspaketti puolestaan vapaasti määriteltävä
joukko käyttövaltuuksia. Esimiehen määrittämä ja HR-järjestelmään kirjattu
henkilön työnkuva vastaa vähintäänkin käyttäjän ns. oletusroolia, joka määrittyy
automaattisesti. Työntekijällä voi kuitenkin olla tehtäviä jotka eivät suoraan paljastu
työnkuvamäärityksestä ja näitä varten tarvitaan tapa jolla niitä voidaan hallitusti
myöntää ja hallita. Tämä voi tapahtua joko mahdollistamalla usean roolin
samanaikaisen käyttämisen tai vastaavasti myöntämällä käyttäjälle rooleihin
sopivasti määriteltyjä käyttövaltuuspaketteja. Toimittaja voi tarjota tuotteeseensa
sopivaa mallia tämän toteuttamiseksi.
Jatkoajan myöntäminen yksittäiselle käyttöoikeudelle, haetaanko jatkoaikaa
käyttöoikeudelle uusimisprosessin kaltaisesti vai miten on tarkoitus toimia?
Vastaus: Jatkoaika voidaan hakea uusimisprosessin mukaisesti.
Siivousprosessin toteutus, pitääkö siivousprosessissa tarkastaa käyttövaltuuksien
todellinen tilanne kohdejärjestelmistä vai vain IAM:n käyttövaltuustietokannasta?
Vastaus: Prosessi voi tapauskohtaisesti sisältää molempia, esim. kevyempi
siivousprosessi jossa tarkastetaan tilanne IAM käyttövaltuustietokannasta ja
harvemmin suoritettu raskaampi prosessi joissa käydään läpi myös
kohdejärjestelmistä.
Tarkoittaako KT1, vaatimus 1.6 sitä, että käyttäjälle on mahdollista hakea
työsuhdetta pidempään voimassa olevia käyttöoikeuksia?
Vastaus: Kyllä tarkoittaa. Valtuuksia voidaan myös myöntää alkavaksi ennen
työsuhteen virallista voimassaoloa.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 6/26
8.
9.
10.
11.
12.
13.
14.
15.
Miten M2M ja yhteiskäyttötunnuksen vastuuhenkilö määritetään järjestelmään
(tapauskohtaisesti vai jotenkin muuten)?
Vastaus: Tapauskohtaisesti. Valittavissa olevien henkilöiden listaa on kuitenkin tarve
voida rajata.
KT4, Käyttäjien oikeudet, joita massamuutos ei koske jäävät voimaan normaalisti?
Vastaus: Kyllä
KT10, Onko tarkoitus, että käyttöoikeuksien hyväksyjien raportista nähdään kaikkien
hyväksyjien myöntämät oikeudet käyttövaltuuksien saajittain huolimatta hyväksyjän
omaa roolia (esimerkiksi esimies)?
Vastaus: Kyllä
Liite 1, kohta 4.3 Käyttötapauskuvaukset Kysymys: ”Käyttötapauksien normaali
kulku” osiot sisältävät varsin tarkkaa kuvausta käyttöliittymän toiminnallisuudesta.
Mikäli toimittajan tarjoama tuote ei ole käyttöliittymältään vastaava, niin voimmeko
tältä osin muuttaa käyttötapauksia tarjottavan käyttöliittymän toiminnallisuuden
mukaiseksi?
Vastaus: Kyllä voi, ja tämä on tarkoituskin. Käyttötapaukset ja vaatimukset on
monilta osin kuvattu loppukäyttäjäperspektiivistä käyttäen kuvitteellista
käyttöliittymää apuna tarvittavien toiminnallisuuksien määrittämisessä. Näitä
määrityksiä tulee soveltaa tarjottavan tuotteen ominaisuuksiin, räätälöintitarpeen
minimissä pitämiseksi. Vaatimuksen lopputuloksen tulee kuitenkin säilyä ja esim.
käytettävyys ei saa kauttaaltaan olla olennaisesti heikompi kuin vaatimuksissa ja
käyttötapauksissa esitetty malli on (saa olla parempi!).
Jatkokysymys edelliseen: Jos halutaan käyttötapauksien mukaista toiminnallisuutta
käyttöliittymään, niin miltä pohjalta näitä toiminnallisuuksia on määritelty? Onko
määrittelyn pohjana valmis tuote vai ovatko nämä asiakkaan itse tekemiä
määrittelyitä?
Vastaus: Määrittelyt ovat asiakkaan itse tekemiä, ilman että pohjalla olisi käytetty
mitään tuotetta.
Jatkokysymys edelliseen: Miten käyttöliittymän mahdollinen kehitystyö kirjataan
hinnoittelulomakkeelle? Siellä ei ole sille varattua kenttää.
Vastaus: Hinnan voi esittää yksikköhinnoissa kohdassa ”Muu mahd.
hintakomponentti”, selitteen kera.
Huom: ”Muu hintakomponentti” -kentän summa ei automaattisesti siirry
vertailuhinta-välilehdelle, vaan sama summa täytyy kirjata myös sinne.
Liite 1, sivu 6 ”Yleisradion henkilöstöjärjestelmä HERAan on kirjattu kaikki Ylen
sisäiset työntekijät sekä osa freelancereiksi luettavista työntekijöistä.” Kysymys:
Onko tarkoitus tuoda kaikki freelancerit jatkossa HERAan/tuoda nykyiset
freelancerit HERAan jotka eivät vielä ole siellä?
Vastaus: Jako on jo nyt varsin luonnollinen: Herassa ovat ne freelancerit joilla on
teknisesti ottaen työsuhde Yleen, ts. työsopimus. HERAn ulkopuolella ovat ne
freelancerit joiden sopimussuhde on jokin muu, ts. esim. laskutus oman yrityksen
kautta. Nämä freelancerit voidaan hyvin pitkälle rinnastaa ulkoisiin henkilöihin.
Liite 1, sivu 7 ”Esimiehen luodessa työsopimusta HERAan hän valitsee palkattavan
työntekijän työnkuvan (roolin), joiden mukaan nämä henkilölle kohdistettavat roolin
mukaiset käyttövaltuudet määräytyvät.” Kysymys: Onko roolit määritelty? (eli mitä
oikeuksia tietyn SAPissa valittavan työnkuvan perusteella työntekijä tulee saamaan
IDM-järjestelmän kautta)
Vastaus: Roolimääritykset eivät ole vielä valmiit. Rooleista on olemassa määrittelyitä
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 7/26
16.
17.
18.
19.
20.
21.
kattaen keskeisen osajoukon järjestelmistä. Työn tulokset eivät ole vielä sillä
valmiustasolla, että ne olisi voitu liittää osaksi tarjouspyyntöä.
Onko työroolit jo määritelty?
Vastaus: Kts. edellinen vastaus
Onko käyttövaltuuspaketit jo määritelty?
Vastaus: Myöskään käyttövaltuuspaketteja ei ole vielä määritelty tarkalle tasolle.
Työroolien ja käyttövaltuuspakettien määrittäminen kulkevat käsi-kädessä.
Liite 1, sivu 8 ”Ulkoiset käyttäjät palkannut henkilö tai hänen valtuuttama
vastuuhenkilö on vastuussa käyttövaltuuksien anomisesta. Näin ollen
käyttövaltuuksista tulee vastuuseen ulkoisen käyttäjän kustannuspaikan esimies.”
Kysymys: Tarkoittaako tämä sitä että ulkoisen käyttäjän palkkaa aina sen
kustannuspaikan esimies johon ulkoinen käyttäjä tulee kuulumaan? Vai että yleensä
eri henkilö on vastuussa käyttövaltuuksien anomisesta käyttäjälle kuin henkilö joka
on vastuussa käyttäjän käyttövaltuuksista?
Vastaus: Ulkoisen käyttäjän palkkaa juuri tuo kustannuspaikan esimies. Käytännön
järjestelyitä hoitaa kuitenkin usein joku muu henkilö (esim. joku esimiehen alaisista)
ja tässä tapauksessa käyttövaltuuksien hakija voi olla eri henkilö kuin se joka on
niistä vastuussa.
Liite 1, sivu 10 ”Työntekijä voi itse hakea lisäkäyttövaltuuksia
itsepalveluperiaatteella, etukäteen työroolin perusteella valitusta valtuusjoukosta.”
Kysymys: Mitä tarkoitetaan etukäteen työroolin perusteella valitulla
valtuusjoukolla? Eli onko jokaiselle työroolille määritelty tietyt oikeudet joita
käyttäjä voi hakea kun kuuluu kyseiseen työrooliin? Kuinka paljon työrooleja on
määritelty? Tuleeko jokaiseen työrooliin määritellä käyttäjälle haettavissa oleva
valtuusjoukko?
Vastaus: Tavoitteena on, että itsepalvelukäyttöliittymässä näytetään käyttäjälle vain
hänelle relevantteja asioita ja tämä sisältää myös haettavissa olevien valtuuksien
joukon rajoittamisen. Varsinaista määritystä näistä ei ole tehty, ts. mitä valtuuksia
näytetään millekin roolille, mutta tarve on rajata valtuusjoukkoja ainakin karkealla
tasolla, esimerkiksi siten että tietyt esimiesoikeudet eivät näy ei-esimiehille.
Toimittaja voi ehdottaa tähän omasta mielestään toimivaa mallia. Erilaisten
työroolien määrä pyritään ainakin alkuvaiheessa pitämään huomattavan pienenä.
Liite 1, sivu 10 ”Poistamisprosessissa käyttöoikeus ensin deaktivoidaan, jolloin
käyttöoikeuden käyttö estyy, mutta käyttäjän tietoja ei vielä poisteta. Mikäli
käyttöoikeutta ei aktivoida erikseen määritellyn ajan sisällä, poistetaan käyttäjä
kyseisestä järjestelmästä.” Kysymys: Tarkoitetaanko käyttöoikeudella käyttäjätiliä
vai voiko se olla esimerkiksi AD ryhmä?
Vastaus: Itsenäisten järjestelmien tapauksessa käyttöoikeuden poisto tarkoittaa
useimmiten samaa kuin käyttäjätilin deaktivointi/poisto. AD:n kautta kuitenkin
hallitaan usean järjestelmän valtuuksia, jolloin käyttöoikeus tarkoittaa samaa kuin
esim. AD-ryhmäjäsenyys.
Liite 1, sivu 11 ”Hallittavan identiteetin henkilökohtainen data poistetaan
järjestelmistä vasta pidemmän ajan kuluttua” Kysymys: Tarkoitetaanko
henkilökohtaisella datalla käyttäjätiliä kohdejärjestelmässä? Jos ei, niin mitä
tarkoitetaan henkilökohtaisella datalla?
Vastaus: Henkilökohtaisella datalla tarkoitetaan mm. dokumentteja, sähköposteja
jne. joita käyttäjälle on voinut kertyä ajan saatossa. Sillä ei siis tarkoiteta varsinaista
käyttäjätiliä.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 8/26
22. Liite 1, sivu 11 ”Käyttövaltuudet on uusimiseen liittyvissä raporteissa koottu
työroolin mukaisesti, tarkistustyön vähentämiseksi.” Kysymys: Mitä tämä
käytännössä tarkoittaa (koottu työroolin mukaisesti)?
Vastaus: Tässä kuvataan sitä, että käyttövaltuudet tulee olla raporteissa ryhmitelty
selkeästi ymmärrettäviin kokonaisuuksiin, esim. työrooliin automaattisesti kuuluvat
valtuudet ensiksi, tämän jälkeen lisävaltuudet/lisäroolit/paketit kukin omana
ryhmänään.
23. Liite 1, sivu 15, KT1 ”Järjestelmä näyttää mitkä roolipohjaiset käyttövaltuudet
kuuluvat henkilölle automaattisesti.”. Kysymys: Täytyykö erotella mitkä oikeudet
kuuluvat automaattisesti ja mitkä on haettu erikseen? Näytetäänkö vain työroolin
nimi vai myös tarkalleen mitä oikeuksia kyseinen työrooli antaa
(käyttäjätilit+ryhmäjäsenyydet?)
Vastaus: Käyttötapausta määritettäessä ajatuksena on ollut, että järjestelmä
näyttää mikä rooli (mitkä valtuudet) tulevat automaattisesti, ja mitkä on haettu
erikseen. Tässä ei kuitenkaan tarvitse näyttää yksityiskohtaisella tasolla kaikkia
käyttövaltuuksia joita rooliin kuuluu, roolin nimi ja kuvaus riittää. Rooliin liittyviin
tarkemman tason valtuustietoihin on kuitenkin oltava kohtalaisen helppo pääsy.
24. Liite 1, sivu 15 KT1 ”Käyttövaltuuden hakija tallentaa tiedot ja valitsee hyväksyjän,
mikäli se on eri kuin järjestelmän oletusarvoisesti ehdottama.” Kysymys: Kenet
käyttäjä voi valita vaihtoehtoiseksi hyväksyjäksi?
Vastaus: Tätä ei ole vielä täysin määritelty. Vaihtoehtoishyväksyjätilanteet liittyvät
usein esim. sijaisuuksiin, eikä tähän voida määrittää yksiselitteistä kaavaa.
25. Liite 1, sivu 16 KT 1 1.3 ”Valinnaisten käyttövaltuuksien listan tulee olla
suodatettavissa /jäsenneltävissä / ryhmiteltävissä esim. hierarkisesti” Mitä
tarkoitetaan hierarkisella suodatuksella?
Vastaus: Hallittavien valtuuksien määrä tulee todennäköisesti ajan myötä
muodostumaan siinä määrin laajaksi, että jonkinlainen valtuuksien hierarkinen
rakenne on tarpeen, esim. taloushallintoon liittyvät valtuudet ja
henkilöstöhallintoon liittyvät valtuudet omissa hierarkia-haaroissaan. Tässä sanoilla
”suodatettavissa/jäsenneltävissä/ryhmiteltävissä” kuvataan käytännössä samaa
asiaa, eli että voidaan ryhmittelemisen keinoilla helpottaa suurien valtuusmäärien
käsittelyä.
26. Liite 1, sivu 23 KT 5 ”Järjestelmä poistaa käyttövaltuuden saajan kaikki
käyttövaltuudet kerralla (siirtymäajat huomioiden).” ja liite 1 sivu 11 ” IAM-ratkaisu
huolehtii datan poistoon liittyvistä muistutuksista, mutta varsinaiseen datan
poistoon kuuluvat toimenpiteet eivät kuulu tähän prosessiin, eivätkä tässä
määriteltävän IAM-ratkaisuun.” Kysymys: Voisiko vaatimuksia selventää sen osalta,
mitä tarkalleen IAM-järjestelmä poistaa ja mistä (ja milloin)? Sekä mitä IAMjärjestelmä ei poista? Milloin poistolla tarkoitetaan ”disablointia” ja milloin
”deleteä”?
Vastaus: Tyypillinen poistamiseen liittyvä tapahtumien kulku menee siten, että
keskeisimmät valtuudet (erityisesti AD) pyritään disabloimaan mahdollisimman pian
poiston käynnistyttyä, estäen pääsyn järjestelmiin. Varsinainen käyttäjätilin poisto
(”delete”) voi tällöin tapahtua hieman myöhemmin. Varsinaisen poiston
viivästyttäminen on tarkoituksenmukaista mm. freelancereiden kohdalla, he tulevat
usein lyhyen ajan kuluttua takaisin ja kokonaan uuden käyttäjätilin perustaminen
aiheuttaisi turhaa työtä mm. käyttäjätiliin liittyvien tietojen ja asetusten suhteen.
Viivästämällä käyttäjätilin varsinaista poistoa voidaan turhat perustamiset ja poistot
välttää. Viimeisenä poistoketjussa on henkilökohtainen data eli dokumentit ja muut
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 9/26
tiedot joiden säilyttämisestä on omat linjauksensa (säilytysaika useita kuukausia,
ehkä vuosia). Näidenkin osalta haluaisimme järjestelmän kykenevän muistuttamaan,
jottei poisto unohdu.
27. Liite 1, sivu 36 ”AD ja muut käytössä olevat LDAP-hakemistot. Henkilötietojen,
tunnusten, hierarkioiden, ryhmien ja valtuuksien provisiointi ja de-provisiointi.”
Kysymys: Millaisia hierarkioita AD:hen on tarkoitus provisioida ja missä vaiheessa?
Ja mihin tarkoitukseen IAM-ratkaisun tulisi provisioida ryhmiä AD:hen/LDAP:n?
(sama kysymys lotus notesille).
Vastaus: AD:hen on tarkoitus provisioida mm. organisaatiohierarkiat, HERAsta
saatujen tietojen mukaan. AD-ryhmien avulla puolestaan hallitaan usean AD.ta
hyödyntävän järjestelmän käyttövaltuuksia, sekä mm. intranetin valtuuksia ja
oletusnäkymiä, jne... AD:n lisäksi Ylellä on käytössä muita LDAP-hakemistoja, liittyen
pääasiassa web-alustojen käyttövaltuuksiin, näihin pätevät samat periaatteet kuin
AD:hen. Lotus Notes tuntee myös organisaatiohierarkiat, sähköpostiryhmät,
sovellukset, työryhmätilat, jne. joiden ryhmiä ja valtuuksia on tarkoitus hallita.
28. Onko ulkoisille käyttäjille saatavissa määritelmää, joka kuvaisi heidän suhteensa
Yleen ja käyttöoikeuksiensa tarpeen?
Vastaus: Ulkoisten käyttäjien suhde Yleen on kuvattu määrittelydokumentissa
lyhyesti. Kansankielellä sanottuna he ovat ”ostettua työvoimaa”, eivät siis saa
palkkaa Yleltä vaan jonkin muun yrityksen kautta. Ulkoisten käyttäjien osalta IAMratkaisu on heidän identiteettitietojensa kirjaamispaikka ja master-varasto. He
tarvitsevat käyttövaltuuksia IAM-ratkaisun kohdejärjestelmiin, mutta eivät ainakaan
nykyisen määrityksen mukaisesti tarvitse itse käyttää varsinaista IAM-ratkaisua (sen
käyttöliittymän kautta).
29. Voidaanko tarjouspyynnössä täsmentää ulkoisille käyttäjille tarvittavaa IdMjärjestelmältä edellytettävää toiminnallisuutta?
Vastaus: Kts. edellinen vastaus
4 Hintalomakkeeseen liittyvät kysymykset
1.
2.
3.
4.
IAM Ratkaisun toimitusprojekti: Projektin hinnoittelu, hintalomakkeella
osakomponentit ilmoitetaan kokonaishintana sisältäen kaikki tarvittavat työt
tarjouspyynnön mukaisesti?
Vastaus: Kyllä
IAM-koulutuspalvelut (vaatimusliitteen välilehden 2, luvun 3.3 mukaisesti), mistä
tämä viittauksen mukainen luku 3.3 löytyy?
Vastaus: Kyseessä on kirjoitusvirhe, tässä viitataan vaatimusliitteen välilehden 2
kohtaan ”Koulutus” (vaatimukset 2.44 – 2.48)
Loppukäyttäjän koulutus – kuinka monta henkilöä tähän on tarkoitus osallistua
(kaikki Ylen työntekijät n. 3000 vai pienempi ryhmä esim. 20?
Vastaus: Yhteen loppukäyttäjäkoulutukseen osallistuu noin 20-30 henkilöä
kerrallaan. Hintalomakkeella haetaan yhden koulutuskerran hintaa. Mikäli Yle
haluaa kouluttaa suuremman joukon, järjestetään useampi vastaava koulutuskerta.
Mitä tarkoitetaan Ohje-välilehdellä rivillä 27 Pääasiallisen hinnoittelumekanismin
tulee perustua tähän hinnoittelupohjaan kuvattuihin ennalta määriteltyihin
hintaluokituksiin.
Vastaus: Tarkoitus on se, että hinnat esitetään vertailukelpoisuuden vuoksi
mahdollisimman pitkälle niille osoitetun hinnoittelurakenteen mukaisesti. ”Muu
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 10/26
mahdollinen hintakomponentti” -kentät on tarkoitettu sellaisille hintatiedoille, jotka
toimittajan mielestä ovat ”unohtuneet” hintalomakepohjasta tai jotka eivät muusta
syystä mitenkään ole osoitettavissa muihin annettuihin hintakenttiin. Näille
hinnoille on aina oltava mukana selite, mitä ne ovat.
”Muu mahdollinen hintakomponentti” -kenttiä ei tule käyttää väärin siten, että
niiden avulla yritettäisiin esim. saada näyttämään jonkin muun osakokonaisuuden
hinta suhteessa edullisemmalta.
5. Mikäli asiakkaalle mahdollisesti edullisempi ja hyödyllisempi tuote on niin sanottu
”bundle” tuote, joka sisältää kaikki asiakkaan tarvitsemat tuotteet (IAM, SSO ja
federointi), niin millä tavoin tämä kirjataan Yksikköhinnat välilehdelle? ”Bundle”
tuotetta ei voi eritellä erikseen eri osa-alueisiin.
Vastaus: Tarjoajan tulee ilmoittaa hinnat hintalomakkeessa esitetyllä tavalla
jaoteltuna. Mikäli kuitenkin tuotteet ovat erottamattomasti yhtä pakettia, voidaan
koko paketin hinta ilmoittaa ei-optionaalisessa osiossa (IAM-ratkaisu) ja Ylelle
optionaalisten osien hinnoiksi asetetaan 0 €, selitteen kera. Tämä voi toki vaikuttaa
ei-optionaalisten osuuksien hintaa nostavasti.
6. Vuosittaiset lisenssien ja käyttöoikeuksien ylläpitomaksut: Kysymys:
Ylläpitomaksujen kerroin on neljä. Yleensä ensimmäisen vuoden lisenssimaksu
sisältää ylläpidon. Pitäisikö kerroin olla kolme?
Vastaus: Tarjoajan tulee ilmoittaa hankinta- ja ylläpitomaksujen hinnat
hintalomakkeessa esitetyllä tavalla. Mikäli hankintahintaan sisältyy vuoden (tai
muun ajan) kestoinen ylläpito ja sen sisältyminen kuvataan selkeästi
tarjousdokumentaatiossa, Yleisradio ottaa tämän tarjousten hintavertailussa
huomioon ja korjaa vertailuhintaa tarvittavilta osin.
7. Kuinka halutaan hinnoittelu tehtäväksi jos valmistaja lisenssiehtojen mukainen jako
esim. sisäisten ja ulkoisten välillä on erilainen kuin Ylen määritelmä?
Vastaus: Tarjoajan tehtävä on sovittaa tarjoamansa lisenssit siten että ne kattavat
Ylen määrittämän käytön, vaikka se jossain tapauksessa voikin vaikuttaa hintaa
nostavasti.
8. Voiko hintalomakkeen saraketta F tai H käyttää selvittämään hinnoittelua?
Vastaus: Kyllä voi lisätä selitteen.
9. Kuinka halutaan merkittävän jos joku Ylen mainitsema komponentti jo kuuluu jollain
toisella rivillä esitettyyn hintaan?
Vastaus: Mikäli joku komponentti kuuluu toisella rivillä esitettyyn hintaan, asetetaan
sen hinnaksi 0 € ja lisätään asiaankuuluvat selitteet. Tämän suhteen on oltava
tarkkana, sillä kaikki optiot eivät kuulu vertailuhintaan. Mikäli vertailuhintaan
kuuluva komponentti on kytketty yhteen vertailuhintaan kuulumattoman
komponentin kanssa, on näiden yhteinen hinta esitettävä vertailuhintaan kuuluvalle
komponentille osoitetussa kentässä.
10. Ovatko seuraavat käyttäjämäärät tarjouspyynnön mukaisia hinnoittelun perusteita:
Sisäisiä käyttäjiä 3200, ulkoisia käyttäjiä 5000, passiivisia käyttäjiä 10000
Vastaus: Kyllä. Lisäksi hintalomakkeella pyydetään yksikköhinnat näiden määrien
kasvattamiselle.
11. Paljonko on virtuaalisia identiteettejä? Onko luku mukana ulkoisten käyttäjien
luvussa hinnoittelutaulukossa?
Vastaus: Virtuaalisia identiteettejä on arviolta 100-200 kpl ja ne sisältyvät ulkoisten
käyttäjien lukumäärään.
12. Voidaanko asiakkaan pyytämien optioiden kohdalla ilmaista jos option
toteuttamiseen vaadittavat lisenssit sisältyvät jo tarjouksen hinnoitteluun?
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 11/26
Vastaus: Kyllä, tuolloin ko. option kohdalle merkitään hinnaksi 0 € (jos kyse
puhtaasti lisenssistä/muusta vastaavasta), tai merkitään osakokonaisuuden
toteutushinta muuten siten että siihen ei ole laskettu ”tarpeettomia” lisenssejä.
5 Hankintakohteen vaatimuksiin liittyvät kysymykset
1 – Yleiset vaatimukset
o 1.60 Kattaako Asiakasdokumentaatio tyhjentävästi kokonaisdokumentaation
tarpeet? Vaatimuksissa on listattu useita dokumentaation osia, joiden osalta ei
ole erikseen mainittu ovatko ne käsitettävissä Asiakasdokumentaatioon
kuuluvaksi?
Vastaus: Asiakasdokumentaatio koostuu käytännössä kaikista vaatimuksissa
listatuista dokumentaatioista. Lisäksi, perusperiaate on että kaikkea
dokumentaatiota jota projektin tai palvelun aikana tuotetaan, koskee vaatimus
1.62 ”Oikeudet asiakasdokumentaatioon”.
2 - IAM-toteutus
o 2.2 Voiko toimittaja valita projektinhallintamenetelmän? Jos ei, niin mikä on
käytettävä projektinhallintamenetelmä?
Vastaus: Toimittaja voi esittää omaan toimintatapaansa soveltuvinta
projektinhallintamenetelmää. Yleisradiolla on menetelmät sekä ”perinteisiin”
vesiputousmallin projekteihin että ketterän kehittämisen projekteihin, näiden
käytöstä voidaan sopia erikseen.
o 2.18 Miten tämä järjestetään käytännössä?
Vastaus: Valitulle toimittajalle järjestetään perehdytys tämän hankkeen
kannalta relevanttiin ympäristökokonaisuuteen, esim. Ylen pääkäyttäjien ja
järjestelmävastaavien toimesta.
o 2.21 Mihin dokumentaatioon tässä viitataan?
Vastaus: Tässä viitataan Yleisradion määritysten pohjalta muodostettaviin
tarkempiin toteutuksen suunnitteludokumentteihin.
o 2.35 Onko testausmalli saatavissa etukäteen tarjouksen laadinnan tueksi?
Vastaus: testausmallista ei valitettavasti ole lyhyttä ja ytimekästä yhteenvetoa,
joka soveltuisi tarjouspyyntöön liitettäväksi materiaaliksi.
o 2.35 Toimittajan tulee käyttää asiakkaan testausmallia. Voitteko kuvata ko.
testausmalli?
Vastaus: Testausmalli perustuu käyttötapauksiin perustuviin testitapauksiin.
Testisuunnitelmaa ja testitapauksia luodessa, sekä testatessa sovelletaan ns.
laatuporttimenettelyä (Quality gates).
o 2.38 Tarkoitetaanko tällä ylläpitopalvelun käytäntöjen testausta järjestelmän
testauksen yhteydessä?
Vastaus: Kyllä
o 2.41 Miten kriteerit loogisuudelle ja helppokäyttöisyydelle määritellään ja
kenen toimesta?
Vastaus: Testitapauksia suunnitellaan yhdessä Ylen ylläpitovastaavien kanssa,
he määrittävät kriteerit.
o 2.45 Loppukäyttäjäkoulutus ei ole hankinnan piirissä vaikka on määritelty
optionaaliseksi?
Vastaus: Loppukäyttäjäkoulutuksen tarve täsmentyy projektin myöhäisemmissä
vaiheissa, siksi se on optionaalinen kokonaisuus. Vaatimus ei ole pakollinen,
eikä kuulu vertailuhintaan joten toimittaja voi jättää tämän kokonaisuuden
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 12/26
halutessaan tarjoamatta. Tyypillisesti Yle on itse hoitanut
loppukäyttäjäkoulutukset omien pääkäyttäjiensä voimin. Omien resurssien
käytön optimoimiseksi voimme harkintamme mukaisesti kuitenkin käyttää
loppukäyttäjäkoulutuksiin myös Ylen ulkopuolisia resursseja, tässä tapauksessa
loogisin koulutuksen toimittaja on IAM-ratkaisun toimittaja.
o Projektin aikataulu, milloin käytännön projektin on tarkoitus alkaa ja millä
laajuudella?
Vastaus: Käytännön projektin on tarkoitus alkaa tämän vuoden syksyllä.
Ideaalitilanteessa tämän vuoden lopussa olisi konkreettinen toteutus olemassa
(ts. osa 1-vaiheen toteutuksesta valmis). Vaiheen 1 valmistuminen varhain
vuoden 2013 alussa. Vaiheen 2 työt ajoittuvat pääasiassa vuoden 2013 puolelle.
Tarjoajan tulee esittää projektisuunnitelmassaan mielestään realistinen
aikataulutus varsinkin vaiheen 1 osalta.
o Kuuluvatko vaiheen 1 toteutukseen kehitys-, testi ja tuotantoympäristö vai
onko tarvetta useammalle ympäristölle?
Vastaus: 1-vaiheen toteutukseen kuuluvat yllämainitut ympäristöt, yksi kutakin.
3 – IAM-toiminnalliset-vaatimukset
o Miten ja missä laajuudessa tarjotun IAM-ratkaisun vastaavuus käyttötapauksiin
tulee kuvata?
Vastaus: Tarjottu ratkaisu kokonaisuudessaan kannattaa kuvata erilliseen
dokumenttiin (tarjouksen liite5, ”Tarjotun ratkaisun kuvaus”). Tällöin
käyttötapauksien kohdalta voi lisätä viittaukset ko. dokumenttiin. Hyvässä
kuvauksessa on miten ratkaisu käyttötapauksen osalta toimii ja mukana on mm.
kuvaruutukaappauksia, josta käy ilmi tarjotun tuotteen käyttölogiikka.
o 3.23 Mitä tietomallin käsitteitä tämä vaatimus koskee?
Onko jotain alustavaa tietoa olemassa?
Vastaus: Tämä vaatimus tarkoittaa käytännössä sitä, että ratkaisun tietomallin
tulee olla jossain määrin sovitettavissa Ylen tarpeisiin, se ei saa siis olla liian
kiinteäksi määritetty. Tietomallitarpeista ei ole tarkkaa määritelmää, mutta
emme usko että vaatimukset poikkeavat merkittävästi siitä mitä yleisesti IAMratkaisujen yhteydessä käytetään.
o 3.28 Ratkaisun tulee tarjota toiminnallisuus ja käyttöliittymä identiteetin ja
siihen liitettyjen käyttäjätilien tilapäiseen tai pysyvään sulkemiseen
(deaktivointiin). Kysymys: Tarkoitetaanko "pysyvä sulkeminen" vaatimuksella
poistoa, vai jotain peruuttamatonta lukitsemistapaa?
Vastaus: Pysyvä sulkeminen tarkoittaa samaa kuin poisto.
o 3.30 Ratkaisun tulee kyetä tunnistamaan ja yhdistämään eri lähdejärjestelmissä
sijaitsevat saman henkilön identiteetit. Kysymys: Onko kaikilla identiteeteillä
jokin yhteinen arvo mitä voidaan käyttää yhdistämisessä? Ja tarkoitetaanko
yhdistämisellä tilien liittämistä henkilön "omistukseen" vai toisiinsa?
Vastaus: Ttällä vaatimuksella tarkoitetaan eri lähdejärjestelmissä sijaitsevien
identiteettien (ja identiteettitietojen) yhdistämistä toisiinsa, perustuen jonkin
yhteisen tiedon käyttöön. Ylen henkilönumero on muutamassa järjestelmässä
(mm. HERA, AD, HenkHa, kulunvalvonta). Suurimmassa osassa muista
järjestelmistä uniikki tunniste on käyttäjätunnus. Ylen järjestelmissä
käyttäjätunnukset noudattavat selkeästi määriteltyä peruskaavaa aivan
muutamaa poikkeusta lukuun ottamatta.
o 3.30 – 3.31 Mitä yhdistäminen tässä kohtaa tarkoittaa käytännössä?
Vastaus: Kts. edellinen vastaus. Käsin yhdistäminen tulee kyseeseen niissä
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 13/26
o
o
o
o
o
o
tapauksissa, missä yhdistämistä ei voida suorittaa automaattisesti, esim.
puutteellisten tietosisältöjen vuoksi.
3.33 Ratkaisun tulee tarjota tietomalli, jossa identiteetin attribuutit voivat liittyä
johonkin identiteetin rooliin (esim. eri puhelinnumero saman henkilön
freelancer ja konsulttirooleille) Kysymys: Mitä tarkoitetaan attribuutin
liittämisellä rooliin? Saammeko esimerkin?
Vastaus: Sama henkilö voi toimia erilaisissa sopimussuhteissa Yleen (joko eri
aikoina tai yhtä aikaa). Esimerkiksi: Henkilö työskentelee yhden ajanjakson
freelancerina osallistuen Ylen tuotannolliseen työhön ja toisena ajanjaksona
konsulttina jossain muussa asiassa. Henkilöllä on täten kaksi eri ”roolia” Yleen
päin ja näihin saman henkilön molempiin rooleihin voi joissain tapauksissa
liittyä erilaiset yhteystiedot.
3.34 – 3.42 Mikä on ”Ryhmä”-käsitteen määrittely näissä vaatimuskohdissa
(onko esim. LDAP-ryhmän tyyppinen objekti vai jotain muuta)?
Vastaus: Ryhmä -käsite on näissä vaatimuksissa varsin yleisellä tasolla.
Tapauksesta riippuen ryhmä voi teknisesti muodostaa LDAP-ryhmän,
sähköpostilistan, tai jonkin muun käyttövaltuusryhmän. Ryhmä voi myös olla
vain ryhmätieto (esim. henkilön organisaatio/tiimi) joka voidaan välittää
henkilötietojen mukana, ilman että ryhmätietoon olisi varsinaisesti liitetty
yhtään käyttövaltuutta. Yleisesti ottaen, se että identiteettejä, rooleja ja
käyttövaltuuksia voidaan hallita hierarkisten mallien avulla, helpottaa ja
jäsentää ratkaisun käyttöä.
3.35 Ratkaisun tulee tukea hierarkisia organisaatio-, ryhmä-, rooli- ja
käyttövaltuusmalleja. Kysymys: Tarkoitetaanko tällä että kaikkien täytyy olla
säädettävissä hierarkisiin suhteisiin (parent/child) vai sitä että tämän lisäksi
pitää olla funktionaalinen suhde (esim: child roolin jäsen automaattisesti parent
roolin jäsen)
Vastaus: Hierarkinen rakenne on tärkeä erityisesti tietojen hallittavuuden ja
jäsenneltävyyden kannalta. Tämän lisäksi on eduksi, mikäli myös
funktionaalinen suhde voidaan määritellä, esim. siis siten että ylemmän tason
valtuudet/roolit periytyvät alemmille tasoille. Funktionaalinen suhde ei
kuitenkaan ole pakollinen.
3.37 Ryhmillä tulee voida olla omia attribuutteja. Kysymys: Tarkoitetaanko tällä
että ryhmien schemaa pitää pystyä muokkaamaan? IDM järjestelmässä vai
taustajärjestelmässä? Minkälaisia attribuutteja esimerkiksi?
Vastaus: Ryhmille tulee esim. voida antaa nimi ja kuvaustekstit ja mahdollisesti
joitakin muita varsin yksinkertaisia attribuutteja.
3.38 Ryhmiä tulee voida luoda vapaasti tarpeen mukaan. Ryhmillä on voitava
olla alaryhmiä (hierarkinen rakenne). Kysymys: Puhutaanko ryhmistä IDM
järjestelmässä vai taustajärjestelmässä? Jos IDM järjestelmässä, pitääkö
objektin olla ryhmä vai saako olla muu ryhmänkaltainen objekti, esim: rooli?
Vastaus: Vaatimuksessa puhutaan ryhmistä IDM-järjestelmässä. Kts. myös
vastaus kysymykseen joka liittyy vaatimuksiin 3.34 – 3.42
3.39 Ratkaisun tulee tarjota toiminnallisuus ja käyttöliittymä identiteetin
suorien ja epäsuorien (esim. jäsenyydet alaryhmien kautta) ryhmäjäsenyyksien
löytämiseksi. Kysymys: Puhutaanko ryhmistä IDM järjestelmässä vai
taustajärjestelmässä?
Vastaus: IDM-järjestelmässä
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 14/26
o
o
o
o
o
o
3.47 Identiteetteihin tulee kyetä kohdistamaan yksittäisiä käyttövaltuuksia ja
käyttövaltuuspaketteja vapaasti, roolipohjaisten valtuuksien lisäksi Kysymys: Jos
tuote ei tue käsitettä "käyttövaltuuspaketti", voidaanko kokoelma
käyttöoikeuksia myöntää roolin avulla? Kuinka monta erilaista
käyttöoikeutta/pakettia/roolia järjestelmässä arvioidaan olevan?
Vastaus: Termit ”rooli” ja ”käyttövaltuuspaketti” ovat osittain päällekkäisiä ja
tarjoaja voi tarvittaessa soveltaa niitä toisiaan korvaavasti.
3.50 Rooleilla, käyttövaltuuksilla ja käyttövaltuuspaketeilla tulee voida olla
vapaasti määritettävissä oleva alkamis ja päättymispäivä. Ratkaisuun tulee
voida määritellä näille automaattisesti asettuvat oletusarvot. Kysymys: Mitä
toiminnallisuutta tällä ominaisuudella haetaan? Saammeko esimerkin?
Vastaus: Pääasiallinen toimintamalli käyttövaltuuksien voimassaolon suhteen
perustuu henkilön sopimukselliseen tilanteeseen, ts. (työ)sopimuksen
voimassaoloon. Sopimustietojen avulla pyritään automatisoimaan valtuuksien
myöntämistä ja erityisesti poistamista. Yleisradion toiminnassa kuitenkin
suhteellisen säännöllisesti törmätään tilanteeseen, jossa sopimuksen
voimassaoloon perustuvat säännöt eivät mahdollista henkilöstön riittävän
joustavaa käyttöä (erityisesti lyhytkestoisia toimeksiantoja tekevät freelancerit),
vaan käyttövaltuuksien voimassaoloa tulee tarvittaessa voida manuaalisesti
säätää, esim. alkamaan ennen sopimuksen voimaantuloa ja/tai päättymään
vasta sopimuksen päättymisen jälkeen.
3.52 Mistä tiedoista tässä on kysymys?
Vastaus: Identiteetti- ja käyttövaltuustiedoista. Vaatimus tarkoittaa siis sitä,
että IAM-ratkaisun käyttäjällä ei oletusarvoisesti ole valtuuksia nähdä tai
muokata toisten identiteettien tietoja. Tällaiset valtuudet tulevat esim. esimiestai muiden roolien kautta.
3.53 Käyttövaltuushakemuksen hyväksyjä voi muuttaa hakemuksen sisältöä,
esim. lisätä tai poistaa valtuuksia hakemuksesta. Kysymys: Onko hyväksyttävä
vaihtoehto että käyttöoikeudet pyydetään ja hyväksytään yksi kerrallaan?
Vastaus: Yksittäin pyytäminen ja hyväksyminen eivät ole käyttömukavuuden
kannalta sellainen ratkaisu jota Yleisradio on hakemassa. Se ei ole vaihtoehtona
täysin poissuljettu, mutta käyttökokemusta heikentävä vaikutus otetaan
huomioon pisteytyksessä. Huomatkaa, että mahdollisuus niputtaa
käyttövaltuuksia rooleiksi/käyttövaltuuspaketeiksi on ehdoton vaatimus ja näitä
tulee voida hyväksyä siten että kaikki ko. paketissa olevat valtuudet tulevat
hyväksytyksi samalla kertaa.
3.57 Mitkä vaatimukset (liite3 hankintakohdetta koskevat vaatimukset)
koskevat tarjouspyynnön kohtaa 1 (Identiteetti- ja käyttövaltuushallinnan
tuotteet ja tuotteiden käyttöönotto(IAM-ratkaisu) Voisiko pelkkä WebSSO
riittää? Kuinka todellinen/taloudellisesti merkittävä tarve on ESSO ratkaisulle?
Vastaus: Ylen käytössä on muutama keskeinen ja varsin laajasti käytetty
järjestelmä, joiden SSO-ratkaisu Ylen näkemyksen mukaan vaatii ESSOratkaisua. Tarkkaa taloudellista vaikutusta ei ole laskettu.
3.58 Ratkaisun tulee kyetä hallitsemaan laitteille tai käyttäjille annettuja
sertifikaatteja. Onko tarkoituksena, että ratkaisu toteuttaa myös sertifikaattien
jakelun ja käyttöönoton (engl. enrollment), vai ainoastaa pyytämisen ja
myöntämisen?
Vastaus: Tarkoituksen on ensimmäisessä vaiheessa toteuttaa sertifikaattien
pyytäminen ja myöntäminen.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 15/26
o
o
o
o
o
o
o
o
3.58: Saadaanko tarkempi kuvaus siitä mitä laitteille annetuilla sertifikaateilla
tarkoitetaan? Onko mahdollista saada esimerkki?
Vastaus: Esimerkiksi palvelinsertifikaatti tai tablettitietokoneeseen
verkkotunnistautumista varten asennettu sertifikaatti.
3.59 Voidaanko tämä vaatimus toteuttaa erikseen tarjottavalla optiolla?
Vastaus: Kyllä. Hinnoittelu hintalomakkeen kohtaan ”Valinnaiset
toteutuskokonaisuudet -> Roolien louhinta ja analyysi” tai ”Valinnaiset
toteutuskokonaisuudet -> Muu mahd. hintakomponentti” (mikäli tarjotaan
tuotetta, ei kokonaispalvelua)
3.60 Ratkaisun tulee tallentaa ja säilyttää historiatietoa identiteettien tietoihin
ja valtuuksiin tehdyistä muutoksista, mukaan lukien muutosten hakijat,
hyväksyjät, tekijät ja aikaleimat. Kysymys: Pitääkö järjestelmän itse analysoida
ja ehdottaa rooli/käyttöyhdistelmiä vai riittääkö se että yhdistelmäpohjat
voitaisiin määritellä? Miten tämä vaatimus liittyy raportointiin ja
tarkastamiseen?
Vastaus: Vaatimus ei liity roolien/käyttöyhdistelmien hallintaan mitenkään.
Vaatimus liittyy identiteettien tietoihin ja valtuuksiin tehtyjen operaatioiden
auditoitavuuteen ja raportoitavuuteen.
3.61 Ratkaisun tulee kyetä lokittamaan käyttäjien tekemät operaatiot ja
työnkulut. Lokitusten taso ja kohteet tulee olla valittavissa. Kysymys:
Tarkoittaako ”lokittaminen” tässä tapauksessa tietojen kirjoittamista
ainoastaan lokitiedostoon vai sekä lokitiedostoon että tietokantoihin?
Vastaus: Ratkaisutapa on tuotekohtainen, lokitus voi tapahtua joko tiedostoon,
tietokantaan tai molempiin. Tietokantapohjainen ratkaisu mahdollistaa
helpomman raportoinnin.
3.61 Ratkaisun tulee kyetä lokittamaan käyttäjien tekemät operaatiot ja
työnkulut. Lokitusten taso ja kohteet tulee olla valittavissa. Kysymys: Jos audit
loki tallentaa kaikki käyttäjätapahtumat, mutta tasoa ei voi laskea, onko tämä
hyväksyttävää?
Vastaus: Kyllä, toimittajan tulee tällöin ehdottaa käyttökelpoinen ja
helppokäyttöinen ratkaisu lokien suodattamiseen (esim. käyttäen jotain muuta
työkalua).
3.62 Ratkaisun tulee voida raportoida kaikki tehdyt identiteettien,
organisaatioiden ja ryhmien hallintaan liittyvät toimenpiteet. Kysymys:
Tarkoittaako tämä vaatimus myös sitä, että järjestelmäasetuksien historiatiedot
pitää pystyä raportoimaan järjestelmän toimesta.
Vastaus: Ei, vaan sitä että kaikki identiteetteihin/identiteettitietoihin,
organisaatiotietoihin/organisaatiojäsenyyksiin ja
ryhmätietoihin/ryhmäjäsenyyksiin tehdyt muutokset tulee voida raportoida.
3.64 Mitä tarkoitetaan tässä yhteydessä raportoitavilla toimenpiteillä
käytännössä, voisiko saada esimerkkejä?
Vastaus: Esim. järjestelmään määritettyjen työnkulkujen muutoksien tekijät ja
sääntömuutoksien tekijät.
3.64 Ratkaisun tulee voida raportoida kaikki tehdyt käyttövaltuusmäärityksien,
käyttövaltuuspakettien, roolien, työnkulkujen, säännöstöjen, salasanojen sekä
muiden ratkaisun toimintaa ohjaavien tietojen hallintaan liittyvät toimenpiteet.
Kysymys: Tarkoittaako tämä vaatimus sitä että myös kyseisten toimenpiteiden
sisältö pitää olla raportoitavissa?
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 16/26
o
o
o
o
o
o
o
o
Vastaus: Toimenpiteiden sisällön ei tarvitse olla raportoitavissa. Mikäli ratkaisu
kuitenkin tarjoaa toimenpiteiden sisällön raportoinnin, katsotaan tämä eduksi.
3.66 Mitä tarkoitetaan siivousprosessilla tässä tapauksessa?
Vastaus: Tällä tarkoitetaan määrittelydokumentin mukaisia käyttövaltuuksien
siivousprosesseja.
3.66 Ratkaisun tulee pystyä todentamaan tehdyt siivous- ja käyttövaltuuksien
uudelleenhyväksymisprosessit. Kysymys: Mitä ”todentaminen” tarkoittaa
käytännössä?
Vastaus: Loki tai raportti josta näkyy että ko. tehtävät on käynnistetty ja
suoritettu loppuun.
3.67 Ratkaisun tulee pystyä raportoimaan käyttäjistä joilla on laajat
käyttövaltuudet (monessa järjestelmässä). Kysymys: Mitä käytännössä
tarkoittaa ”laajat käyttövaltuudet”? Pitääkö ”laajuuden” olla määriteltävissä
järjestelmässä?
Vastaus: Ratkaisuun tulee voida olla määriteltävissä tieto käyttövaltuuden
luonteesta, esim. tieto että kyseessä on admin-käyttövaltuus tai muu
pääkäyttäjävaltuus. Näiden tietojen perusteella voidaan muodostaa
raportti/raportteja käyttövaltuusyhdistelmistä joiden tulkitaan olevan ”laajoja”.
3.70 Ratkaisun tulee pystyä antamaan ehdotuksia
rooli/käyttövaltuusyhdistelmistä, olemassa olevien käyttäjä- ja
käyttövaltuustietojen perusteella. Kysymys: Tarkoittaa tämä vaatimus sitä, että
järjestelmässä pitää olla ”Käyttövaltuudet rooleittain” -niminen raportti vai
riittääkö se, että nämä tiedot ovat saatavilla esimerkiksi käyttöliittymän kautta?
Vastaus: Tässä vaatimuksessa haetaan jossain määrin roolilouhinnan kaltaista
toiminnallisuutta, ts. toiminnallisuuden avulla etsitään sellaisia
käyttövaltuusyhdistelmiä joista voisi muodostua käyttökelpoinen rooli tai
käyttövaltuuspaketti. Toiminnallisuuden ei tarvitse olla ”on-line” vaan voi
toteutua myös raportoinnin tai raporttiyhdistelmien kautta.
3.77 Raportti: Käyttövaltuudet järjestelmittäin (järjestelmän käyttäjien
käyttövaltuudet ryhmiteltynä valtuuden ja/tai henkilön mukaan, roolit joihin
järjestelmän valtuuksia kuuluu). Kysymys: Tarkoittaako tämä vaatimus sitä, että
kaikkien tietojen pitää löytyä yhdestä raportista vai onko hyväksyttävää, että
nämä tiedot löytyvät useammasta raportista?
Vastaus: Voivat olla toteutettuna useampana raporttina.
3.93 Ratkaisun tulee tarjota valmiita työkulkukaavoja eri tyyppisiin
hyväksyntäprosesseihin liittyen roolien, säännöstojen,
käyttövaltuusmääritysten ja käyttövaltuuspakettien muutoksiin. Kysymys:
Halutaanko siis hyväksyntä administratiivisiin toimenpiteisiin, kuten esim.
dynaamisten roolien filtterien muutoksiin? Vai muutoksiin jotka koskevat
suoraan käyttäjiä (esim. käyttäjän poistaminen roolista)
Vastaus: Tässä vaatimuksessa haetaan hyväksyntää administratiivisiin
toimenpiteisiin.
3.95, Mitä tarkoittaa asiakkaan näkemyksestä täysin räätälöity?
Vastaus: Vapaasti määriteltävä työnkulku (käyttäen tuotteen tukemia
”työnkulkukomponentteja/vaiheita”). Merkittävä paino tässä vaatimuksessa on
sanalla ”käyttöliittymä”, ts. että asiakas itse voi määritellä haluamansa kaltaisia
työnkulkuja, yksinkertaisella tavalla.
3.97 Mitä sisältyy "muihin attribuuttitietoihin"?
Vastaus: Vaatimuksella haetaan sitä, että käyttöliittymässä näkyvät sisällöt
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 17/26
o
o
o
o
o
o
o
o
mukautuvat käyttäjän tietojen pohjalta. Esim. esimiehille tulee näkyville
enemmän valtuuksiin liittyviä hallinta- ja raportointimahdollisuuksia kuin
tavalliselle työntekijälle. Se, käyttääkö ratkaisu tämän toiminnallisuuden
tekniseen toteutukseen valtuusmekanismia (ts. esim. esimies-roolia) vai
suoraan käyttäjien attribuuttitietoja (esimies-atttribuutin sisältö) on
tuotekohtainen. Tähän toiminnallisuuteen hyödynnettäviä attribuutteja voi
kuitenkin olla muitakin kuin ”esimiestieto”, esim. identiteetin tyyppi tai
sopimuksen tila.
3.100 Tarkoittaako käyttäjätietojen siivous myös ko. tietojen poistamista
järjestelmän tietovarastosta rekonsilioinnin yhteydessä?
Vastaus: Vaatimuksen 3.60 mukaan ratkaisun tulee kyetä säilyttämään ja
raportoimaan historiatietoa. Tietoja ei siis kokonaisuudessaan voida poistaa
tietovarastosta heti rekonsilioinnin yhteydessä. Käyttövaltuuksien ja
käyttäjätilien status- ja olemassaolotiedot (tai tietojen sijaintipaikka) päivittyvät
siten, että ne eivät tarpeettomasti ja tarkoituksettomasti näy käyttöliittymässä
ja raporteissa, mutta ovat kuitenkin tarvittaessa historiatietona käytettävissä.
3.100 Ratkaisun tulee tukea sekä ajoittaista että lähes reaaliaikaista
käyttäjätilien ja valtuuksien osittaista, inkrementaalista ja täydellistä
rekonsiliointia ja 3.102 Ratkaisun tulee kyetä automatisoimaan käyttäjätietojen
siivousprosessi, jossa verrataan ja täsmäytetään tietoja luotettavissa lähteissä ja
kohdejärjestelmissä. Miten edellä mainitut vaatimukset käytännössä eroavat
toisistaan?
Vastaus: Jälkimmäisessä vaatimuksessa viitataan ko. operaation
automatisointiin.
3.104 Salasanan resetointi pitää pystyä delegoimaan sekä käyttäjille itselleen
itsepalvelun kautta, helpdeskille, että jollekin muulle käyttäjälle. Kysymys:
Tarkoitetaanko tällä että ylläpito antaa näille tahoille oikeuden resetoida
jonkun tietyn käyttäjän salasana vai että käyttäjä myöntää salasanan resetointi
oikeuden näille tahoille?
Vastaus: Ylläpito antaa valtuudet resetoida käyttäjien salasanoja. Tätä valtuutta
käyttävät mm. helpdeskin ja/tai käyttäjäkonttorin henkilökunta.
3.105 Mitä tarkoitetaan kertakäyttöisen varmisteen käytöllä? Lasketaanko
kertakäyttöiseksi varmisteeksi TUPAS?
Vastaus: Tässä haetaan kevyempää ja helppokäyttöisempää ratkaisua kuin
TUPAS, esimerkiksi käyttäjän matkapuhelimeen tekstiviestillä lähetetty
varmiste.
3.106 Millä tavalla SSO ratkaisun tulee toimia yhteydessä Active Directoryn
kanssa?
Vastaus: SSO-ratkaisu käyttää AD:ta käyttäjätietojen lähteenä
3.107 Millä tavalla SSO-ratkaisun tulee toimia yhteydessä LDAP-yhteensopivien
hakemistojen kanssa
Vastaus: SSO-ratkaisu käyttää LDAP-hakemistoa käyttäjätietojen lähteenä
3.109 SSO-ratkaisun tulee mahdollistaa sertifikaattien käyttö käyttäjien
tunnistamiseen: Mitä tässä tarkoitetaan sertifikaattien käytöllä? Pitääkö tukea
muutakin kuin sertifikaatteja toimikorteilla tai USB-tokeneilla? Voitteko
tarkentaa toiminnallisella esimerkillä?
Vastaus: Kyseessä ovat yllämainitut sertifikaatit
3.112 SSO-ratkaisun tulee tarkistaa sekä käyttäjän identiteetti että hänen
valtuudet kohdejärjestelmään: Tarkentakaa, mitä tässä tarkoitetaan
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 18/26
o
o
o
o
o
o
o
o
kohdejärjestelmän valtuuksien tarkastamisella. Voitteko tarkentaa
toiminnallisella esimerkillä?
Vastaus: SSO-ratkaisu ei yritä tehdä käyttäjälle kertakirjautumista niihin
järjestelmiin joihin käyttäjällä ei ole valtuuksia
3.114 SSO-ratkaisun tulee toteuttaa minimivaatimukset salasanan vahvuudelle
ja salasanan uusimiselle. Kysymys: Mitä nämä minimivaatimukset ovat? Ja jos
salasanaa vaaditaan toisissa vaatimuksissa AD:sta ja toisissa IDM ohjelmistossa
resetoitavaksi, eikö salasanan minimivaatimukset olisi parempi säätää näissä
järjestelmissä?
Vastaus: Vaatimus linkittyy vahvasti AD:lle tehtyihin määrityksiin salasanan
vahvuudelle. SSO-ratkaisussa tämän tulee olla yhtenevä tai yhteinen AD:n
kanssa.
3.115 SSO-ratkaisun tulee tehdä käyttäjätilin lukitseminen ja yrityskertojen
rajoittaminen virheellisten kirjautumisyritysten perusteella. Tarkentakaa, mitä
tarkoittaa käyttäjätilin lukitseminen tässä tapauksessa. Voitteko kuvata
toiminnallisen esimerkin?
Vastaus: Käyttäjätilin lukitseminen tai kirjautumisyritysten estäminen joksikin
aikaa, tilapäisesti.
3.116 SSO-ratkaisun tulee mahdollistaa salasanan vaihto ja resetointi
itsepalveluna.: Tarkoitetaanko tässä käyttäjän domain- vai sovellustunnuksen
resetointia?
Vastaus: Kyllä. Sama toiminnallisuus voi olla toteutettuna myös IAM-ratkaisun
puolella jolloin sitä ei tarvita SSO-ratkaisussa.
3.117 SSO-ratkaisun tulee tukea Web SSO:n vaatimia mekanismeja. Onko
vaadittua Web SSO -toiminnallisuutta mahdollista eritellä tarkemmin?
Vastaus: Kts. muut Web SSO:ta koskevat vastaukset
3.118 SSO-ratkaisun tulee tukea perinteisiä client-pohjaisia sovelluksia.
Kysymys: Tarkoitetaanko tässä ”enterprise single sign on” tuotetta vai ”web
single sign on”- tuotetta vai molempia?
Vastaus: Molempia
3.118 SSO-ratkaisun tulee tukea perinteisiä client-pojaisia sovelluksia.
Oletamme, että vaatimuksella viitataan Enterprise Single Sign-On -ratkaisuun
(ESSO), jolla mahdollistetaan käyttäjien läpinäkyvä kirjautuminen clientpohjaisiin sovelluksiin ilman muutoksia sovellusten autentikointilogiikkaan.
Onko tulkinta oikea?
Vastaus: Kyllä
3.118 Onko vaatimusta mahdollista täsmentää? Voidaanko vaatimusta tulkita
siten, että Windows Native Authentication tekniikkaa käyttäen, vaatimus
voidaan toteuttaa tarjouspyynnön mukaisesti?
Vastaus: Windows Native Authentication tekniikkaa on mahdollista hyödyntää
joidenkin järjestelmien osalta. Kuitenkin merkittävä osa Yleisradion käyttämistä
mediatuotannon sovelluksista ei tue tätä tekniikkaa.
3.119 SSO-ratkaisun tulee toteuttaa federoitu SSO-toiminnallisuus Identity
Provider –käytössä ja 3.120 SSO-ratkaisun tulee toteuttaa federoitu SSOtoiminnallisuus Service Provider -käytössä. Kiinteähintaisen tarjouksen
antaminen edellyttää SAML-federointikyvykkyyden yksityiskohtaisempaa
rajausta. Onko esimerkiksi kertauloskirjautuminen (logout) vaatimuslistalla?
Voitteko eritellä vaadittavat SAML 2.0 -käyttötapaukset esimerkiksi viittaamalla
SAML 2.0 -testikriteeristöön
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 19/26
o
o
o
o
(http://kantarainitiative.org/confluence/download/attachments/42139721/Kan
tara_Initiative_SAML_Test_Plan_Final_Report_v3.3.pdf?version=1&modificatio
nDate=1281718540000)? Voitteko nimetä tuettavat Deployment Profile määritykset?
Vastaus: Viitattu dokumentti on luonteeltaan hyvin tekninen eikä Yleisradio
kaikilta osin ole kykenevä tässä vaiheessa määrittämään toiminnallisuutta tässä
kysymyksessä oletetulla tasolla. Tarjoaja joutuu paljolti luottamaan omaan
asiantuntemukseensa ja arviointikykyynsä tarjousta tehdessään. Ensisijaisesti
federoinnin tulee tukea Yleisradiota palveluiden käyttäjän ominaisuudessa ja
tämän myötä toteuttaa esim. yleisimmin julkisesti tarjolla olevissa
liiketoiminnan SaaS/pilvipalveluissa käytettyjä profiileja ja mekanismeja, sekä
tarvittaessa tukea Yleisradion mahdollisuuksia tarjota omia web-pohjaisia
palveluita federoituna kumppaniyrityksille turvallisesti mutta suhteellisen
vaivattomasti. Liittymismahdollisuus julkisen sektorin palveluihin, lähinnä Virtu,
on hyvä ottaa tarjouksessa huomioon (ainakin asiasisällöllisesti mm. tarjotun
ratkaisun ja Virtu-vaatimusten välisten eroavaisuuksien osalta), näiden
palveluiden käyttöönotto ei kuitenkaan ole lähitulevaisuudessa ajankohtaista.
Tarjottujen federointiominaisuuksien tulee perustua yleisesti käytössä oleviin
määrityksiin. Jossain määrin voidaan soveltaa kotimaisia julkisen sektorin
määrityksiä, esim. Virtu ja HAKA, ottaen kuitenkin huomioon se, että Yle toimii
federointinäkökulmasta lähinnä tavallisena palveluita käyttävänä yrityksenä, ei
julkisen sektorin palvelutarjoajana jossa luottamussuhteiden määritykset voivat
olla hyvinkin vahvoja ja sitovia. Yksinään merkittäviä määrityksiä ovat mm.
edellisiinkin sisältyvä Interoperable SAML 2.0 Web Browser SSO Deployment
Profile.
3.119 SSO-ratkaisun tulee toteuttaa federoitu SSO-toiminnallisuus Identity
Provider -käytössä. Vähimmäisvaatimuksena SAML 2.0 implementaatio.:
Voitteko tarkentaa toiminnallisella esimerkillä miten federoitu SSOtoiminallisuus toimisi tässä tapauksessa?
Vastaus: Yle käyttää hyväkseen esim. SaaS/pilvipalveluna toteutetun
järjestelmän tarjoamaa federointimahdollisuutta, toteuttaakseen single-sign-on
toiminnallisuuden ko. järjestelmään omille työntekijöilleen.
3.120 SSO-ratkaisun tulee toteuttaa federoitu SSO-toiminnallisuus Service
Provider -käytössä. Vähimmäisvaatimuksena SAML 2.0 implementaatio:
Voitteko tarkentaa toiminnallisella esimerkillä miten federoitu SSOtoiminallisuus toimisi tässä tapauksessa?
Vastaus: Yle tarjoaa omaan extranetiin tai muuhun vastaavaan kumppaneille
tarjottuun palveluun mahdollisuuden kirjautua federoidun käyttäjähallinnan
avulla. Tähän vaatimukseen liittyvät tulevaisuuden käyttöskenaariot eivät ole
vielä täysin jäsentyneet, vaatimuksella haetaan valmiuksia tämän
käyttöönottoon tarvittaessa.
3.121 SSO-ratkaisun tulee olla vikasietoinen tukea nopeita toipumisaikoja.
Kysymys: Mitä tällä tarkoitetaan?
Vastaus: SSO-ratkaisu on käyttäjien pääsyn kannalta kriittinen komponentti.
Siihen liittyvien ratkaisujen tulee olla vikasietoisia ja häiriötilanteissa nopeasti
toipuvia.
SSO federaatio, minkälaisia federointeja oletetaan toteutettavan?
Vastaus: Keskeisimmät federointiin liittyvät toteutukset liittyvät
pilvipalvelu/SaaS -periaatteella hankittavien liiketoimintapalveluiden
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 20/26
o
o
o
o
o
o
o
käyttöönottoon. Tarkkaa listausta näistä ei ole vielä olemassa, sillä monet
näihin liittyvät hankkeet ovat suunnitteluasteella ja niiden toteutuspäätökset ja
-aikataulut eivät ole tiedossa. Tässä vaiheessa haetaan ensisijaisesti valmiuksia
SSO:n hyödyntämiseksi näissä palveluissa.
Omistaako Yle jo käyttöoikeuksia Web SSO tuotteeseen?
Vastaus: Atlassian Crowd (pienimuotoinen käyttö ja käyttäjämäärä) ja Active
Directory Federation Services (ei tällä hetkellä ole käytössä), mikäli nämä
luetaan Web SSO tuotteiksi.
Onko Web SSO jo Ylellä jollain tavalla käytössä käytössä?
Vastaus: Vain pienimuotoisia toteutuksia, kts. edellinen vastaus.
Omistaako Yle jo käyttöoikeuksia Enterprise Single Sign-on tuotteeseen?
Vastaus: Atlassian Crowd (pienimuotoinen käyttö ja käyttäjämäärä), mikäli
luetaan enterprise SSO tuotteeksi.
Onko Enterprise Single Sign-on Ylellä jo jollain tavalla käytössä?
Vastaus: Client-pohjaisten sovellusten SSO ei ole käytössä. AD:ta hyödyntää
autentikointiin muutama järjestelmä, mm. intranet ja HERA.
Onko Ylellä jo tehty Proof-of-Concept tai vastaava jollain IdM-,WebSSO- tai
eSSO tuotteella? Mikäli tällainen on tehty niin millä tuotteella se on tehty ja
minkä yrityksen toimesta?
Vastaus: Yleisradio ei ole tehnyt PoC -testejä millään tuotteella.
SSO ratkaisu, mitkä sovellukset tai kuinka monta sovellusta on ajateltu
liitettäväksi SSO:n piiriin ja miten ne ovat jakautuneet erilaisten
sovellustyyppien ( Win, Java, selain, pääte, muut) kesken?
Vastaus: Windows-sovelluksia on SSO:n piiriin suunniteltu tulevan muutama,
näistä merkittävimpiä ovat mediatuotannon sovellukset (esim. Jutel Radioman,
Avid A/V-tuotteet, Mediagenix Whats’On). Näiden sovellusten käyttäjäpohja on
varsin laaja, satoja käyttäjiä. Web-pohjaisia sovelluksia on koko ajan lisääntyvä
määrä, merkittäviä ovat esim. Oraclen liiketoimintajärjestelmät,
raportointijärjestelmät ja matkahallinnon järjestelmät. Osa web-sovelluksista
on SaaS-mallin mukaisia. Myös näiden käyttäjämäärät ovat laajoja, satoja
käyttäjiä, joidenkin järjestelmien osalta kaikki Yleläiset. Java- tai päätepohjaisia
client sovelluksia SSO:n piiriin ei ole tulossa.
Kuinka monta järjestelmää oletetaan tulevan kertakirjautumisenpiiriin?
Mitkä nämä järjestelmät ovat?
Vastaus: Kts. edellinen vastaus
Mitä autentikointimekanismeja näissä on suunniteltu käytettävän?
Vastaus: Tällä hetkellä käytössä on käyttäjätunnus ja salasana, tätä ei
ole ainakaan keskipitkällä aikavälillä tarkoitus muuttaa
Onko joku näistä järjestelmistä SaaS tai pilvipalvelu tai vastaava?
Vastaus: Yle käyttää jonkin verran SaaS ja pilvipalveluita, niiden käytön
nähdään kasvavan tulevaisuudessa.
Odotatteko kertakirjautumisen vaativan Enterprise Single Sign-on ja
WebSSO tuotteen vai jomman kumman näistä?
Vastaus: Oletamme Yleisradion kaavaileman kertakirjautumisen
vaativan molempia.
Kuinka monta käyttäjätunnusta on kussakin kohdejärjestelmässä?
Vastaus: Kts. edellinen vastaus.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 21/26
o
o
o
Tarjouspyynnön kohta 2 (Identiteetti- ja käytttövaltuushallinnan
kertakirjautumisratkaisun (SSO, single-sign-on)) määritelmässä viitataan liitteen
1 toteutusvaihe 2:een.
Tarkoitus on siis toteuttaa vain kertakirjautuminen, ei mitään muita
toiminnallisuuksia, esim. provisiontia/de-provisiontia?
Vastaus: Tarjouspyynnön kohta 2, Kertakirjautumisratkaisu, kattaa
kertakirjautumisen ja provisioinnit kertakirjautumisjärjestelmään
(mikäli tarvitaan). Provisioinnit kertakirjautumisratkaisun
kohdejärjestelmiin eivät sisälly tähän kokonaisuuteen.
Mitä tarkoittaa “Kertakirjautumisjärjestelmän vaatimien tietojen
provisiointi ja de-provisiointi. IAM-ratkaisun kytkös SSO-ratkaisuun
pidetään löyhänä”
Vastaus: Yleisradion näkemyksen mukaan IAM-ratkaisu ja SSO-ratkaisu
ovat toisistaan varsin vähän riippuvaisia kokonaisuuksia. Teknisen
arkkitehtuurin hallittavuuden kannalta on järkevää, että niiden väliset
sidokset pidetään yksinkertaisina, esim. siten että IAM-ratkaisu syöttää
tarvittavat tiedot AD:hen ja SSO hyödyntää niitä sieltä (sen sijaan että
IAM-ratkaisu olisi tiukasti integroitu suoraan SSO-tuotteeseen).
Jos käytössä olisi pelkkä WebSSO kertakirjautumista varten ei tarvitsisi
provisioida dataa ja totetutus yksinkertaistuisi -> kustannussäästö
implementoinnissa. Onko ESSO ratkaisun tuomalle lisäarvolle laskettu
hintaa?
Vastaus: Ei ole laskettu tarkkaa hintaa. Tiedossa kuitenkin on, että
ESSO-ratkaisun piiriin kuuluvien sovellusten osalta esim. salasanan
resetointiin liittyviä tikettejä on vuositasolla huomattava määrä.
Mitä toiminnallisuutta tarvitaan passiivisten käyttäjien identiteetinhallintaan?
Vastaus: Passiiviset identiteetit ovat identiteettejä, joiden tiedot ovat
järjestelmässä (ja tietoja voidaan päivittää, käsin tai koneellisesti), mutta heidän
statuksensa ei ole aktiivinen (ts. ei ole voimassa olevaa (työ)sopimusta eikä
käyttövaltuuksia). Passiivisten identiteettien tietoja voidaan välittää IAMratkaisusta muihin järjestelmiin, mm. henkilötietolistojen kautta. Heitä voidaan
hallita kuten muitakin identiteettejä, esim. muuttaa aktiivisiksi sopimus- tai
käyttövaltuustietojen muuttamisen kautta.
Lotus Notesiin viitataan sekä määrittelydokumentissa että vaatimuksissa,
kuitenkin melko yleisellä tasolla
Halutaanko tarjouspyynnön kohdassa 1 kuvattuun toteutukseen ja
hintaan sisältyvän provisionti/de-provisionti vain sähköpostin osalta
vai halutaanko tämän käsittävän myös muita Lotus Notes
sovelluksia/toiminnallisuuksia. jos näin on niin mitä?
Vastaus: Provisioinnin ja deprovisioinnin tulee tukea myös Lotus Notes
sovelluksia ja muita toiminnallisuuksia (mm. työryhmätilat,
sähköpostilistat). Käyttöönotto ja sen laajuus tältä osin tulee
suunnitella toteutusprojektin yhteydessä harkiten, sillä näiden
valtuuskohteiden lukumäärä on huomattava (satoja).
Onko Notes implementoitu niin että se käyttää ID-tiedostoja?
Vastaus: Kyllä
Mikä on käytössä olevan Notesin versio?
Vastaus: Versio 8.5.3
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 22/26
4 – IAM-täydentävät-vaatimukset
o 4.6 Ratkaisun tulee vastaanottaa identiteettitietoja Ylen HR-järjestelmä
HERAsta (käyttäen reaaliaikaista rajapintaa, WebService tai REST). Ratkaisun
tulee voida vastaanottaa identiteetteihin liittyviä tietoja muistakin
järjestelmistä, useasta lähdejärjestelmästä samanaikaisesti. Kysymys:
Halutaanko välttämättä WebServices tai REST rajapinta? Onko tästä olemassa
tarkempaa speksiä? Onko muita rajapinta mahdollisuuksia?
Vastaus: Suosimme tämänkaltaista vaihtoa, mm. sen tarjoaman
reaaliaikaisuuden että helpon käytettävyyden vuoksi.
Lähdejärjestelmäintegraatioissa tullaan hyödyntämään Yleisradion ESBintegraatiovälinettä, joka välittää tiedot HERAsta IAM-ratkaisulle. Toisin sanoen,
IAM-ratkaisun ei itse tarvitse toteuttaa suoraa SAP HR -yhteyttä, vaan sen tulee
kyetä vastaanottamaan tiedot integraatiovälineen kautta/tarjoamana.
o 4.11, Mitä tarkoitetaan automatisoidulla tiedostorajapinnalla?
Vastaus: Järjestelmä kykenee automaattisesti lukemaan ja käsittelemään esim.
ns. ”watch-folderiin” tallennetun tiedoston.
o 4.7 Identiteettien tietojen vastaanotto tulee olla nopeaa ja järjestettävissä
tietoturvallisesti. Kysymys: Mikä osa identiteettien vastaanotosta vaatii
tietoturvallisuutta ja millaista tietoturvaa tarkoitetaan?
Vastaus: Esimerkiksi WebService/REST rajapintojen tietoliikenne tulee olla
salattavissa.
o 4.14 Ratkaisun tulee tarjota toiminnallisuus jolla lähdejärjestelmistä saadut
tiedot voidaan automatisoidusti puhdistaa ja niiden oikeellisuus tarkastaa
ennen tallentamista. Kysymys: Mitä tarkoittaa "puhdistaa ja niiden oikeellisuus
tarkastaa"?
Vastaus: Ratkaisu pystyy identifioimaan puutteellisina ja epätäsmällisinä saadut
tiedot (ts. tiedot joiden yhdistäminen jo olemassa oleviin tietoihin olisi
epävarmaa). Esimerkiksi: Tietojen täsmäyttämisen yhteydessä ei voida
varmuudella yhdistää saatuja käyttäjätilitietoja olemassa oleviin tietoihin, sillä
käyttäjätunnus on kirjattu väärässä muodossa.
o 4.15 Ratkaisun tulee kyetä provisioimaan ja de-provisioimaan käyttäjä-,
organisaatio- ja valtuustietoja automatisoitujen liittymien kautta reaaliaikaisesti
tai lähes reaaliaikaisesti. Kysymys: Puhutaanko nyt käyttäjän provisioimisesta
organisaatioihin/ryhmiin/jne vai kyseisten objektien luomisesta
kohdejärjestelmiin?
Vastaus: Myös ryhmäobjekteja ja vastaavia (esim. sähköpostin jakelulistat) on
voitava luoda järjestelmiin.
o 4.16 Tietojen provisiointi kohdejärjestelmiin tulee olla toteuttettu
tietoturvallisesti. Kysymys: Mikä osa tiedoista vaatii "tietoturvaa"? Onko muu
ympäristö kovetettu niin että tästä on käytännön hyötyä? Miten uusien
käyttäjien notifikaatit, pitävätkö ne sisällään salattavaa tietoa, esim.
salasanana?
Vastaus: : Esimerkiksi WebService/REST rajapintojen tietoliikenne tulee olla
tarvittaessa salattavissa. Tiedostopohjaisten liittymien järjestelyt on
suunniteltava siten että, niissä välitettäviin tietoihin eivät asiattomat pääse
käsiksi. Notifikaateissa voi kulkea salasanoja, näihin liittyvä käytännön
salaustarve suunnitellaan toteutusprojektin yhteydessä. Tavoitteena on, että
salasanatiedot menisivät käyttäjälle tiedoksi eri reittiä kuin käyttäjätunnukset.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 23/26
o
o
o
o
o
o
o
o
o
4.17 Voisiko saada luettelon "yleisimmät tietokanta-alustat" määritykseen?
Vastaus: Vaaditut tietokannat on kuvattu vaatimuksissa 4.22 ja 4.23
4.19 Ratkaisun tulee automaattisesti provisioida (ja de-provisioida) identiteetit,
niihin liittyvät organisaatio- ja muut tiedot sekä ryhmät ja valtuustiedot Lotus
Notes / Domino -ympäristöön Kysymys: Puhutaanko nyt käyttäjän
provisioimisesta ryhmiin vai ryhmien luomisesta kohdejärjestelmiin?
Vastaus: Sekä käyttäjien provisioinnista että ryhmien luomisesta.
4.21 Ratkaisun tulee kyetä automaattisesti provisioimaan (ja de-provisioimaan)
identiteetit, niihin liittyvät organisaatio- ja muut tiedot sekä ryhmät ja
valtuustiedot tiedostopohjaisen liittymän kautta (vähintään CSV ja XML tiedostoformaatit) Kysymys: Jos provisioidaan tiedostoon, lisätäänkö tiedot
tiedoston perään vai luodaanko aina uusi tiedosto?
Vastaus: Useimmissa tapauksissa tiedot lisätään tiedoston perään
(mahdollistaen kohdejärjestelmälle sopivat import-aikataulut).
Eräajotyyppisissä siirroissa, joissa siirretään kerralla kaikki tiedot, tehdään uusi
tiedosto.
4.29 Ratkaisun komponentit tulee voida sijoitella usealle eri palvelimelle.
Kysymys: Halutaanko alkuvaiheessa jo hajautettu ratkaisu?
Vastaus: IAM-ratkaisun osalta alkuvaiheessa riittää hajauttamaton ratkaisu,
mikäli sellaisen suorituskyky on riittävä. SSO- ja federointiratkaisun tulee olla jo
alkuvaiheessa kahdennettu.
4.34 Ratkaisun tulee olla kahdennettavissa tai muuten järjestettävissä
vikasietoiseksi ja sen tulee olla sijoitettavissa kuormanjakolaitteiden taakse.
Kysymys: Halutaanko jo alkuvaiheessa kahdennettu ratkaisu? Vai vain niille
komponenteille missä yhden palvelimen kaatuminen on kriittistä (WebSSO/Federointi)?
Vastaus: Kts. edellinen vastaus
4.36 Ratkaisun tulee tukea automatisoituja ohjelmistojakelumekanismeja
(tapauksissa joissa komponentteja asennetaan usealle
palvelimelle/työasemalle/laitteelle). Kysymys: Halutaanko palvelinkomponentit
siis automaattiasentaa?
Vastaus: Tavoiteltu ympäristö ei ole niin laaja, että palvelinkomponenttien
asennuksia olisi tarve automatisoida.
4.37 Ratkaisun tulee tukea Ylen valvontaratkaisujen käyttöä (Nimsoft) Kysymys:
Tarkoitetaanko tällä sitä että kyseiselle valvontaratkaisulle pitää olla ns. plugin.
Vai mitä?
Vastaus: Ei tarvita pluginia. Ratkaisun on tarjottava joko valvontarajapinta
(esim. JMX) tai riittävät järjestelmälokit, joiden kautta järjestelmän tilaa voidaan
valvoa ja vikatilanteet voidaan havaita, parhaimmassa tapauksessa myös
ennakoida.
4.38 Ratkaisun tulee tukea Ylen varmuuskopiointiratkaisujen käyttöä (EMC
Avamar) Kysymys: Tarkoitetaanko tällä sitä että kyseiselle backup ratkaisulle
pitää olla ns. plugin. Vai mitä?
Vastaus: Ratkaisun käyttämät tietokannat ja muut tietovarastot, konfiguraatiot
jne. tulee olla varmuuskopioitavissa kyseisellä varmuuskopiointiratkaisulla
järjestelmän ollessa käytössä (ilman käyttökatkoja).
4.40 Ratkaisun käyttämä tietokanta tulee olla replikoitavissa toiseen paikkaan.
Kysymys: Mitä tarkoitetaan toisella paikalla? Replikapalvelinta?
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 24/26
Vastaus: Esitetyn tietokantaratkaisun tulee tukea lähes reaaliaikaista
replikointia toiselle vastaavalle palvelimelle tai muulla tavoin toiseen sijaintiin.
o 4.41 Ratkaisun tulee käyttää ActiveDirectoryä omien käyttäjätiliensä,
käyttäjäryhmiensä ja käyttövaltuuksiensa hallintaan sekä käyttäjien
autentikointiin. Kysymys: Haetaanko tällä sitä että ratkaisulla ei saa olla omaa
käyttäjätietokantaa? Vai sitä että AD kirjautumisesta pitää tulla SSO IDM
ratkaisuun?
Vastaus: Yleisradio suosii ratkaisuja joilla ei ole omaa itsenäistä
käyttäjätietokantaa. IAM-ratkaisun tapauksessa ei kuitenkaan tavoitella AD:hen
pohjautuvaa SSO-toimintoa.
o 4.42 Ratkaisun tulee olla aikasynkronoitu YLE:n AD-ympäristöön. Kysymys:
Tarkoitetaanko tällä replikointia?
Vastaus: Aikasynkronoinnilla tarkoitetaan sitä, että ratkaisun lokeissa ja muissa
toiminnoissa näkyvien aikaleimojen jne. tulee olla synkronissa Ylen ADympäristön kanssa. Tämä helpottaa mm. eri järjestelmien välistä vikaselvitystä
häiriötilanteissa.
o 4.43 Ratkaisulla tulee olla erilliset testi- ja tuotantoympäristöt. Kysymys:
Montako testiympäristöä halutaan Kehitys ja Tuotantoympäristön lisäksi?
Vastaus: Yksi testiympäristö.
o 4.44-4.45 Ratkaisun tulee kyetä tallentamaan ja siirtämään suojattavat tiedot
salattuna. Mitä muita tietoja kuin salasana-tiedot kyseiset suojattavat tiedot
kattavat? Pelkät salasanat tai mikä tahansa ratkaisun sisältämä tieto
tarkoitetaan (luettelo suojattavista attribuuteista olisi toivottava)?
Vastaus: Vaatimuksella tarkoitetaan tässä yhteydessä salasanatietoja, jotka
tulee säilyttää salakirjoitettuna tietokannassa sekä salata tiedonsiirron aikana.
o 4.53 Mitä pitää olla mahdollista muokata, eli mitä muokattavuus käytännössä
tässä yhteydessä tarkoittaa?
Vastaus: Käyttöliittymän ulkoasu tulee ainakin osittain olla säädettävissä siten
että se saadaan ”Yle-brändin” mukaiseksi, esimerkiksi värit ja logo. Lisäksi on
eduksi, mikäli käyttöliittymästä voidaan piilottaa näkyvistä kaikki ne toiminnot,
mitkä eivät ole Yleisradion käytön kannalta relevantteja.
5 – IAM-ylläpito-ja-pienkehitys
o 5.18 Mitä sisältyy Ylen mukaan tekniseen dokumentaation?
Vastaus: Tekniseen dokumentaatioon sisältyvät mm.
arkkitehtuurikuvaus/järjestelmäkuvaus ja integraatiokuvaukset,
infrastruktuurikuvaus, asiakkaalle toteutetut skriptit ja sovellukset, asennus- ja
päivitysohjeet, tietoturva- ja kovennusohjeet, sovellus- ja laitekonfiguraatiot
sekä testitapaukset, -tulokset, -välineet ja -menetelmät. Näiden lisäksi
tekniseen dokumentaatioon sisältyvät rajatusti: tarkennetut määritykset (esim.
tietomalli, roolimallit ja säännöt), kunnossapito-ohjeet sekä valvonta-,
varmistus- ja toipumisohjeet. Näiden osalta sovitaan erikseen, miltä osin
määritysten ja dokumentaation kehitys- ja ylläpitovastuu on toimittajalla,
asiakkaalla tai muulla kolmannella osapuolella.
o 5.19 Kuka tämän loogisuuden arvioi?
Vastaus: Yleisradion ylläpitovastaavat
o 5.27 Mistä takuuaika katsotaan alkavan tältä osin?
Vastaus: On huomioitava, että tämän vaatimuksen piiriin kuuluu monilta osin
työtä, joka jo muutenkin kuuluu sovellusylläpidon ns. peruskuormaan. Niinpä
vaatimus koskettaa tyypillisesti suurempia muutostöitä, joissa normaalit
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 25/26
o
o
o
o
o
o
takuuehdot ovat muutenkin voimassa ja takuuaika alkaa asiakkaan sovelluksen
hyväksynnästä.
5.31 Mitä tällä tarkoitetaan, voisiko saada esimerkin?
Vastaus: Toimittaja on tehnyt oman modulinsa ja tarjonnut sitä asiakkaalle
osana ratkaisua. Modulissa on kuitenkin toiminnallinen vika tai muu puute,
jonka vuoksi se ei toimi määritellyllä tavalla. Toimittaja tällöin korjaa vian,
tarvittaessa räätälöimällä modulia. Vastaavasti jos vika/puute on toimittaman
asiakkaalle tarjoamassa tuotteessa olevassa modulissa (jolle he tarjoavat myös
tuen) ja vika on korjattavissa parametroinnilla, toimittaja korjaa vian.
5.33 Mitä parametrointi käsittää tässä yhteydessä?
Vastaus: Konfiguroinnit / konfigurointityöt.
5.38 Mitä kuuluu toteutusdokumentaatioon (luettelo dokumenteista olisi
toivottava)?
Vastaus: Toteutusdokumentaatio-kokonaisuus on monilta osin sama kuin
tekninen dokumentaatio mihin viitataan vaatimuksessa 5.18. Edellä mainittujen
lisäksi tämä kokonaisuus kuitenkin kattaa sovellusylläpidon käytännön
toteuttamiseen liittyvää dokumentaatiota, lähinnä toimittajan
palvelutoteutukseen menetelmiin ja käytäntöihin liittyvän dokumentaation,
palvelupyyntöjä koskevat ratkaisut (ratkaisukanta) sekä lisenssitiedot ja muut
vastaavat inventaarit.
5.47 Halutaanko T2-tason tuki puhelimen välityksellä vai tarkoitetaanko tässä
yhteydenottopisteen eli Service Deskin kontaktointitapaa?
Vastaus: Tässä tarkoitetaan sitä, että tuki on Ylen näkökulmasta oltava
saatavilla puhelimen välityksellä. Tarjoaja voi käyttää tukipyyntöjen
vastaanottamiseen ja käsittelyyn ServiceDeskiä tai jotain muuta tapaa.
5.48 Halutaanko T2-tason tuki sähköpostin välityksellä vai tarkoitetaanko tässä
yhteydenottopisteen eli Service Deskin kontaktointitapaa?
Vastaus: Tässä tarkoitetaan sitä, että tuki on Ylen näkökulmasta oltava
saatavilla sähköpostin välityksellä. Tarjoaja voi käyttää tukipyyntöjen
vastaanottamiseen ja käsittelyyn ServiceDeskiä tai jotain muuta tapaa.
Kappale 5.1. Kuinka monta henkilöä on asiakkaan pääkäyttäjät ja tukitiimin
asiantuntijat yhteensä?
Vastaus: 5-7 henkilöä.
6 Sopimusehtoihin liittyvät kysymykset
Ylen JIT ehtojen tarkennukset
o Takuukorjausten kustannukset määrittely: Mitä asiakas tarkoittaa suorilla
kustannuksilla käytännössä pykälän mukaisesti?
Vastaus: Käytännössä pykälä tarkoittaa sellaisia lisäkustannuksia, jotka
aiheutuvat suoraan virheen korjauksesta ja ovat edellytyksenä korjauksen
onnistuneelle käyttöönotolle. Tyypillisimmin tällaisia ovat korjauksen
aiheuttamat lisähankinnat alkuperäiseen toteutukseen verrattuna, esimerkiksi
lisäinfrastruktuuri tai lisenssit. Toimittajalta ei myöskään saa tulla Yleisradiolle
minkäänlaista laskua takuukorjauksen osalta. Pykälä ei tarkoita välillisiä
kustannuksia, esim. korjauksista aiheutuvan käyttökatkon aiheuttamia
kustannuksia Yleisradiolle.
Yle IAM – Tarjouspyyntöön liittyvät kysymykset ja vastaukset
Julkinen. Versio 1.0
28.6.2012
sivu 26/26
o
o
Liite 5, sivu 5, Palvelutasoluokitus. Mikä on asiakkaan vaatima JHS 174
mukainen Tavoitettavuustaso (T1-T4) toimitettavalle ratkaisulle?
Vastaus: Ratkaisun osalta hankittava palvelu on ns. 2. tason sovellustuki, JHS
174 mukaisia tavoitettavuustason luokituksia ei tähän palveluun sovelleta
sellaisenaan.
Liite 5, sivu 5, Palvelutasoluokitus. Mikä on asiakkaan vaatima JHS 174
mukainen Ratkaisukykyluokitus (R1-R4) toimitettavalle ratkaisulle?
Vastaus: Ratkaisun osalta hankittava palvelu on ns 2. tason sovellustuki, JHS 174
mukaisia ratkaisukykyluokituksia ei tähän palveluun sovelleta sellaisenaan.
JIT 2007 Erityisehtoja konsultointipalveluista
o Testaus ja toimituksen hyväksyminen: ”Ellei muuta ole sovittu, toimittaja tekee
käytäntönsä mukaiset testit tilaajan etukäteen toimittamalla aineistolla.”
Millaisen aineiston YLE toimittaa? Onko osa vai koko tuotannon aineisto vai
testiaineisto?
Vastaus: Testiaineistona käytetään valittua otosta tuotannon aineistosta.
Kyseinen aineisto on käytettävissä myös niissä Ylen testiympäristöissä (esim.
HERA), joihin tarjottavan ratkaisun testiympäristön tulee liittyä.