Kilpailutus ei ala RFP:n julkaisusta.
Se alkaa yleensä paljon arkisemmin: joku toteaa, että nykyinen IAM-ratkaisu ei enää riitä ja seuraava pitäisi kilpailuttaa. Samaan aikaan pöydälle kertyy toiveita joka suunnasta: kirjautumiset, käyttöoikeudet, integraatiot, audit-löydökset ja uudet digipalvelut.
IAM on siitä hankala, että se koskee lähes kaikkea. On helppo päätyä tilanteeseen, jossa kaikki tarpeet, ajatukset ja vaatimukset ovat yhtä aikaa tärkeitä - mutta kukaan ei oikeastaan ole varma, mitä ollaan hankkimassa.
Silloin RFP:stä tulee helposti pitkä toivelista. Ja toivelista on huono tapa ostaa ratkaisu, joka määrittää vuosiksi eteenpäin päivittäistä toimintaa, käyttöoikeuksien hallintaa ja operointia.
Tässä artikkelissa käyn läpi 10 asiaa, jotka CIO:n ja IT-johdon kannattaa päättää ennen tarjouspyyntöä. Ne eivät ole lisävaatimuksia, vaan valintoja, jotka tekevät kilpailutuksesta selkeän ja toimituksesta hallittavan.
Miksi ajoitus ratkaisee
Moni organisaatio lähtee liikkeelle vasta, kun tarjouspyyntöä pitäisi jo kirjoittaa.
Silloin aikataulu pakottaa tekemään kaksi keskeistä virhettä:
- Rajauksen ja tavoitetilan määrittely jää vajaaksi.
- Vaatimuksia yritetään paikata yksityiskohdilla.
Tuloksena on RFP, joka näyttää perusteelliselta, mutta ei ohjaa oikean ratkaisun hankintaan. Toimittajat lukevat siitä eri asioita, tarjoukset eivät ole vertailukelpoisia, ja päätös tehdään lopulta demojen fiiliksellä.
Hyvä kilpailutus alkaa aiemmin. Se alkaa siitä, että ymmärretään mitä ollaan hankkimassa - ja miksi.
Yleisin karikko: ostetaan väärää asiaa
Usein ongelma ei ole se, että vaatimuksia olisi liian vähän. Ongelma on, että vaatimukset eivät kuvaa todellista tarvetta.
IAM on ennen kaikkea päätöksiä ja prosesseja: omistajuutta, elinkaarta ja valtuuksia. Teknologia seuraa näitä. Siksi tarjouspyynnönkin kannattaa kuvata ensiksi miten teidän pitäisi toimia - ei vain sitä, millaisia ominaisuuksia tuotteella pitäisi olla.
Kun yhteinen tavoitetila puuttuu, vaatimuslistaan kertyy helposti sekaisin:
- periaatteita ja toteutustapoja samassa rivissä
- sama asia pyydettynä usealla eri tavalla
- kriittiset kyvykkyydet hukkuvat yksityiskohtiin
- integraatiot ja operoitavuus jätettynä oletuksiksi
Silloin kilpailutus mittaa usein myyntipuheen sujuvuutta, ei ratkaisun soveltuvuutta.
10 asiaa, jotka kannattaa päättää ennen RFP:tä
Alla olevat kohdat ovat tarkoituksella ylätasoa. Niistä syntyy hyvä RFP ja hyvä toimitusprojekti. Yksityiskohdat tulevat myöhemmin - oikeassa järjestyksessä.
1) Mikä ongelma ratkaistaan - ja mitä ollaan oikeasti hankkimassa
Lähtökohta on usein selkeä: hankitaan IGA:ta, SSO/IdP:tä tai CIAM:ia. Mutta jo näiden sisällä on vivahteita, jotka muuttavat sekä ratkaisua että kustannusrakennetta.
- IGA: painopiste käyttöoikeuksien elinkaaressa, hyväksynnöissä, roolituksessa, raportoinnissa vai auditoinnissa
- SSO/IdP: pelkkä kirjautuminen vai myös MFA, riskipohjaisuus ja sovellusportfolion modernisointi
- CIAM: kuluttaja-CIAM vai B2B-kumppanit, organisaatiot ja valtuutus
Kirjaa myös rajaus: mitä ei ratkaista tässä vaiheessa ja mikä siirtyy seuraavaan vaiheeseen.
2) Kenellä on omistajuus ja päätösvalta
IAM ei toimi, jos se jää vain IT-projektiksi. Eikä silloinkaan, jos se nähdään pelkkänä tietoturvatoimenpiteenä.
- kuka omistaa IAM-kokonaisuuden nimettynä henkilönä
- missä arkkitehtuuri-, tietoturva- ja budjettipäätökset tehdään
- miten muutospyynnöt käsitellään, hyväksytään ja priorisoidaan
Kun päätösmalli on selkeä, hankinta pysyy asiakkaan ohjauksessa eikä oletusten varassa.
3) Keitä IAM palvelee: henkilöstö, asiakkaat vai kumppanit
Tämä on usein koko hankinnan ydin. Eri käyttäjäryhmät muuttavat valtuutusmallia, elinkaarta, integraatioita ja riskitasoa.
- mitkä käyttäjäryhmät kuuluvat ensimmäiseen vaiheeseen
- mitä kuuluu toiseen vaiheeseen ja millä periaatteella se liitetään mukaan
4) Identiteetin elinkaari ja master data
Mistä identiteetit syntyvät, milloin ne ovat käyttökelpoisia, ja miten varmistetaan että oikeudet poistuvat aidosti.
- mikä on master kullekin käyttäjäryhmälle
- miten muutokset välittyvät: reaaliaikaiset eventit vai ajastettu synkronointi
- miten deprovisiointi, roolien purku, sessioiden katkaisu ja audit trail toteutetaan
5) Integraatioperiaate ja sovellusportfolio
Useimmissa IAM-hankkeissa kustannukset ja aikatauluriskit syntyvät integraatioista, eivät itse IAM-tuotteen konfiguroinnista.
- mitkä integraatiotavat ovat ensisijaiset ja mitä tuettu tarkoittaa käytännössä
- mitkä sovellukset kuuluvat ensimmäiseen vaiheeseen
- miten "pitkän hännän" sovellukset liitetään mukaan: tuodaanko sovelluksia vaiheittain sovituissa erissä, hyödynnetäänkö mahdollisimman paljon valmiita liityntöjä, vai tehdäänkö integraatiot sovelluskohtaisesti tarpeen mukaan
6) Valtuutusmalli: roolit, attribuutit ja delegoinnit
Vastuullinen IAM-hankinta ei osta vain kirjautumista. Se ostaa vastauksen kysymykseen: kuka saa tehdä mitä ja millä perusteella.
- RBAC, ABAC vai selkeä yhdistelmä
- kuka voi myöntää oikeuksia ja kenelle
- miten roolit ja politiikat dokumentoidaan, hyväksytään ja auditoidaan
7) Operoitavuus ja automaatio
IAM-hanke ei pääty käyttöönottoon. Sen jälkeen alkaa pitkä arki, jota varten operoitavuus pitää määrittää alusta asti.
- mitä lokitetaan, kuinka pitkään ja miten lokit haetaan auditointiin
- kuka tekee muutokset, miten ne hyväksytään ja versioidaan
- miten provisiointi, deprovisiointi, raportointi, hälytykset ja seuranta automatisoidaan
8) Tietoturvan perusvalinnat ja yhtenäisyys
MFA, adaptiivinen autentikointi ja istuntojen hallinta on helppo kirjata vaatimuksiin. Vaikeampi osa on varmistaa yhtenäinen toteuma kaikissa sovelluksissa.
- missä MFA on aina pakollinen ja milloin käytetään step-upia
- mitä signaaleja adaptiivisuus hyödyntää
- mitä mitataan ja kenelle raportoidaan: CISO, IT-johto, palveluomistajat
9) Migraatio ja vaiheistus
Vanha ja uusi ratkaisu elävät lähes aina jonkin aikaa rinnakkain. Siksi migraatio kannattaa suunnitella omana kokonaisuutenaan.
- missä järjestyksessä käyttäjäryhmät ja sovellukset siirretään
- mitä pidetään rinnalla ja kuinka pitkään
- mitä valmis tarkoittaa: cutover-kriteerit, testauksen minimitaso, rollback/exit-suunnitelma
10) Arviointikriteerit ja PoC-/demorakenne
Kilpailutuksen lopputulos ratkaistaan käytännössä arvioinnissa, ei RFP:ssä. Jos arviointimalli on epämääräinen, paras myyntiesitys voittaa, ei paras ratkaisu.
- mitkä 5-7 kriittistä kyvykkyyttä ratkaisevat valinnan
- miten pisteytys ohjaa oikeaan suuntaan ja mitä ei voi kompensoida
- mitä PoC/demot todistavat, millä onnistumiskriteereillä ja miten tulokset dokumentoidaan
Kaksi esimerkkiä käytännöstä
Referenssi
Finanssialan CIAM: kun ratkaisu oli ajautumassa räätälöintiprojektiksi
Markkinoilta etsittiin CIAM-ratkaisua, mutta kokonaisuus oli jo kääntymässä suuntaan, jossa ratkaisu olisi toteutettu pitkälti räätälöimällä. Kustannus- ja toimitusriski kasvoi jokaisen uuden tarpeen mukana.
Kun palattiin peruskysymykseen mitä ollaan hankkimassa, tavoitetila, rajaus ja kriittiset kyvykkyydet selkeytyivät. Markkinakartoitus ja toimittajapolku muuttuivat, ja ratkaisu saatiin soveltuvaksi sekä kustannustehokkaaksi toteuttaa.
Referenssi
Julkisen sektorin IGA: kun hankinta käynnistettiin uudelleen
Ensimmäinen kierros johti epäonnistuneeseen toimittajavalintaan, koska scope, vaatimukset ja hankintakriteerit eivät muodostaneet toimivaa kokonaisuutta. Tarjouksia oli vaikea vertailla ja valinta ei osunut oikeaan.
Kun hankinta käynnistettiin uudelleen laadukkaalla tarjousmateriaalilla, selkeällä rajauksella ja arviointimallilla, kilpailutus saatiin raiteille ja vertailu alkoi ohjata päätöstä oikeaan suuntaan.
Kun ymmärrys siitä mitä ollaan hankkimassa on selkeä, vaatimuksetkin selkiytyvät. Tarjoukset ovat vertailukelpoisia, PoC todistaa oikeita asioita, ja toimitus lähtee liikkeelle hallitusti.
Yhteenveto
Hyvä RFP ei ole paperi - se on päätösten tiivistelmä
Kilpailutus onnistuu harvoin sillä, että kirjoitetaan lisää vaatimuksia. Se onnistuu sillä, että tehdään oikeat valinnat ajoissa. Kartoitus on maksuton eikä sido jatkoon. Saat 30 minuutissa tilannekuvan, tärkeimmät päätöskohdat ja ehdotuksen seuraavista askelista ennen RFP:tä.
