HSL tietopyyntö: Asiakaspalvelun ja tarkastuksen työkalun (AsTa) suunnittelu ja toteutus

HSL pyytää tällä tietopyynnöllä alan toimijoiden näkemyksiä mahdollisista toteutusratkaisuista ennen hankinnan suunnittelun käynnistämistä. HSL aikoo toteuttaa asiakaspalvelua ja tarkastusta varten sovelluksen, jota koskevat tiedot ovat saatavilla osoitteesta: ¨ https://hslfi.azureedge.net/globalassets/yrityksille/asta-kuvaus-tietopyyntoa-varten.pdf Tähtäimessä on hankkia suunnittelu ja tuotanto samalta toimijalta, mutta tietopyynnöllä haetaan vahvempaa käsitystä soveltuvasta toteutustavasta. Työ tapahtuu monitoimittajaympäristössä, jossa hyödynnetään rajapintoja ja valmiita ohjelmistokomponentteja sekä useita eri taustajärjestelmiä ja työ suoritetaan HSL:n IT:n ja tulosyksiköiden ohjauksessa, sekä yhteistyössä muiden palveluntuottajien sekä sidosryhmien kanssa. Tällä tietopyynnöllä pyritään kartoittamaan HSL:n olemassa olevaan ympäristöön parhaiten sopiva toteutustapa. Tietopyyntö toteutetaan suomenkielisenä. Asiakirjat ovat saatavilla suomenkielisinä. Tietopyyntöön otetaan vastauksia vain Webropol -linkin kautta: https://link.webropol.com/s/hankinta-tietopyynto-asta Tietopyynnössä on yksi monivalintakysymys ja kolme avointa vastausta. HSL voi kutsua vastaajista yhden tai useamman valitsemansa tahon tarkempaan markkinavuoropuheluun. Tämä on tietopyyntö, johon osallistumisesta ei makseta korvausta. Tietopyyntöön osallistuminen tai osallistumatta jättäminen ei vaikuta toimijan asemaan mahdollisessa kilpailutuksessa. HSL voi hyödyntää olemassa olevia puitejärjestelyjään hankinnan toteuttamiseen.

Asiakaspalvelun ja tarkastuksen sovelluksen (Asta-sovellus) kehitys ja käyttöönotto on kiinteä osa käynnissä olevaa Lipputilihanketta. Asta-sovelluksen tavoitteena on helpottaa ja tehostaa asiakaspalvelun ja tarkastuksen prosesseja ja lisätä asiakastyytyväisyyttä. Lipputilihankkeessa siirrytään nykyisestä kahdesta lipunmyyntijärjestelmästä koostuvasta mallista tunnistepohjaiseen järjestelmään. Asta sovelluksen kehityksen ja käyttöönoton on oltavat saumattomasti linjassa Lipputilihankkeen kanssa. Asta-sovelluksen kehityksessä voidaan toisaalta hyödyntää Lipputilihankkeen taustajärjestelmiä ja prosesseja, esimerkiksi Lippukaupan ostoskoritoiminto voidaan ottaa käyttöön myös Asta sovelluksessa. Lipputilihankkeen yhteydessä ajetaan alas nykyinen Lippu- ja informaatiojärjestelmän (LIJ)  lipunmyynti, joten Asta-sovelluksen kehityksessä on huomioitava siirtymävaihe. Siirtymävaiheessa mm. nykyiset matkakortit siirtyvät tunnisteiksi. Asta-sovellus kokoaa yhteen tietoja useasta lähdejärjestelmästä, joten kehitystiimillä täytyy olla huomattavasti kokemusta kompleksista liittymistä ja järjestelmäkokonaisuuksista ml. maksujärjestelmäliittymistä. Myös erilaisten lukijalaitteiden esim. Nfc kytkemiseen liittyvien tekniikoiden tuntemista tarvitaan. Lipputilihanke toteutetaan ketteränä projektina ja on odotetavissa että hankkeessa tapahtuu aikataulun ja sisällön tarkentamista. Asta-projektin täytyy näin ollen olla myös joustava ja oltava toteutuksen osalta ketterä. Sovellus tulee helpottamaan matkustusoikeuden myyntiä palvelupisteessä,  ongelmatietojen ratkaisemista ja hyvitysten käsittelyä tarjoamalla ongelman selvityksen ja hyvityksen käsittelyn kannalta oleellisen lippu- ja asiakastiedon sekä näihin liittyvät toiminnallisuudet selkeässä, helppokäyttöisessä muodossa.  Sovelluksen tulee mahdollistaa LIJ järjestelmän alasajon ja Lipputilihankkeen etenemisen tukien uusien tuotteiden myyntiä ja mahdollistaen osaltaan tunnistepohjaisuuteen siirtymisen. Sovelluksen tulee helpottaa matkustusoikeuden myyntiä palvelupisteessä,  ongelmatietojen ratkaisemista ja hyvitysten käsittelyä tarjoamalla ongelman selvityksen ja hyvityksen käsittelyn kannalta oleellisen lippu- ja asiakastiedon sekä näihin liittyvät toiminnallisuudet selkeässä, helppokäyttöisessä muodossa.  Asta-sovellus mahdollistaa LIJ järjestelmän alasajon ja Lipputilihankkeen etenemisen tukien uusien tuotteiden myyntiä ja mahdollistaen osaltaan tunnistepohjaisuuteen siirtymisen. JÄRJESTELMÄN KEHITTÄMISPERIAATTEET • Järjestelmän alustana toimii HSL:n Azure-ympäristö • Järjestelmässä tulee hyödyntää mahdollisimman tehokkaasti Azuren pilvinatiiveja palveluita. • Järjestelmä tulee olla kuitenkin siirrettävissä toiselle alustalle kohtalaisella vaivalla. • Järjestelmän front-end kehitys toteutetaan Reactilla (ReactJS) • Järjestelmän tulee olla ylläpidettävissä kehitystiimin toimesta DevOps-toimintamallilla • HSL:n Azure-pilviympäristöllä on oma erillinen ylläpito- ja hallintamalli, jota DevOps tiimin ei tarvitse ylläpitää kokonaan. JÄRJESTELMÄN TOIMINNALLISET PERIAATTEET • Järjestelmä kyselee ja koostaa tietoja käyttöliittymään muista taustajärjestelmistä hyödyntäen näiden julkaisemia rajapintapalveluita. • Kehityksessä hyödynnetään taustajärjestelmien tarjoamia REST-rajapintoja suoraan. • Mikäli taustajärjestelmät eivät tarjoa REST-rajapintoja, tulee (mm. SOAP-pohjaiset) rajapintapalvelut julkaista HSL:n integraatioalaustalla (HIA) REST-rajapintoina. • Järjestelmään ei tule luoda vahvaa sidosta liiketoimintalogiikan käsittelyyn. • Hyödynnetään muita taustajärjestelmiä aina kun mahdollista • Järjestelmä tarjoaa mahdollisuuden hallinnoida asiakkaan tietoja: tehdä muutoksia ja ylläpitää asiakas-, matkustusoikeus- ja muita tietoja asiakaspalvelun sisäisessä työkalussa rajapintojen kautta • Asiakaspalvelun sisäisissä työkalut ei itse sisällä asiakkaiden masterdataa vaan hyödyntää muiden järjestelmien tietoja rajapintojen kautta • Vastuu tietojen hallinnoimisesta on taustajärjestelmillä, tarjottujen muokkausrajapintojen kautta. • Tietojen muokkauskyvykkyys palvelee vain asiakaspalvelun käyttötapauksia. Järjestelmän ei ole tarkoitus korvata taustajärjestelmien omia käyttöliittymiä. • Järjestelmään ei rakenneta varsinaista raportointikyvykkyyttä, mutta sen on mahdollistettava myyjän päivittäinen tapahtumaseuranta täsmäytystä varten JÄRJESTELMÄN MUKAUTETTAVUUS • Taustajärjestelmien rajapintojen päivittyessä ja muuttuessa järjestämän pitää kohtuullisella kehitystyöllä mukautua päivitettyihin rajapintoihin. Ts. Taustajärjestelmän rajapinnan toiminnallisuus ei saa suoraan määritellä käyttöliittymän toiminnallisuutta - > muutoshallinnan prosessia noudatettava (tässä ja muissa järjestelmissä) • Järjestelmän käytön laajentuessa esim. kuntien palvelupisteisiin, järjestelmään tulee kyetä luomaan uusia rooleja ja hallinnoida roolille oikeutettuja järjestelmän toiminnallisuuksia • Järjestelmään tunnistautuminen HSL:n ulkopuolisista organisaatioista tulee olla toteutettavissa käyttäen organisaation omaa tunnistautumista, mikäli organisaatio sallii sen ja toteutus on teknisesti mahdollista tehdä kohtuullisin kustannuksin. • Asiakaspalvelun prosessien ja käytäntöjen muuttuessa tulee käyttöliittymän olla mukautettavissa kohtuullisella työmäärällä uusien prosessien ja käytäntöjen mukaiseksi. Ts. Käyttöliittymästä ei saa tehdä liian jäykkää. JÄRJESTELMÄN TIETOTURVA- JA TIETOSUOJAPERIAATTEET • Järjestelmän tulee olla HSL:n tietosuoja- ja tietoturvavaatimusten mukainen • Järjestelmän tulee tukea roolipohjaista käyttöoikeushallintaa (RBAC) eri käyttäjärooleille. • Järjestelmän tulee tukea HSL:n Single Sign-On (SSO) kyvykkyyttä (AD, Azure ADFS) • Järjestelmän tulee tuottaa lokia järjestelmän käytöstä ja sen toiminnallisuudesta ylläpidon tarpeisiin (noudatettava tietoturvavaatimuksia) JÄRJESTELMÄN MUITA PERIAATTEITA • Järjestelmän tulee kyetä poikkeustilanteissa ohjaamaan käyttäjiä, sekä viestimään virhetilanteista ylläpitäjille, esim. Jos yhteys taustajärjestelmään on poikki tarjotaan poikkeustilannetta varten toimintaohjeet • Järjestelmässä tulee huomioida HSL:n yleiset arkkitehtuuriperiaatteet kilpailutuksessa ja kehittämisen eri vaiheissa

Tämä tietopyyntö käydään seuraavan alustavan aikataulun mukaan: Aikavyöhyke: Helsinki. Päivät ovat muodossa pp.kk. 2022 15.11. - Vastausaika loppuu 15.-25.11. - Mahdolliset lisäkysymykset luvan antaneille vastaajille 30.11. - Vastaukset anonymisoidaan