Oma raportointi­alusta ostetun työkalun tilalle

Lähtötilanne

Asiakkaan raportointi rakentui kolmelle epä­optimaaliselle kerrokselle: kaupalliseen BI-tuotteeseen joka vaati lisenssi­maksun jokaisesta aktiivisesta käyttäjästä (mukaan lukien kumppaniorganisaatioiden vieraista), kymmeniin hand-maintained HTML-raportti­tiedostoihin joita ylläpiti yksittäinen henkilö, sekä Excel-taulukoihin joita johdanto vertaili manuaalisesti. Vieras­käyttäjien hallinta oli jatkuva kitka­lähde ja lisenssi­menot skaalautuivat väärään suuntaan jokaisen uuden kumppanin myötä.

Lisäksi suuri osa organisaation tiedosta oli dokumenteissa — toimintaohjeissa, sopimuksissa, pöytäkirjoissa, työehto­sopimuksissa — joita oli satoja tai tuhansia, eikä niistä löytänyt vastauksia ilman että joku tiesi missä etsiä. Loppukäyttäjän tietotarve syntyi, ja sen tyydyttämiseen kului asiantuntijan työpanos.

Tavoite oli korvata pino omalla interaktiivisella alustalla joka madaltaa tiedon hakuun kynnystä, ei maksa käyttäjä­määrästä, kunnioittaa rivitasoista käyttö­oikeutta automaattisesti ja on helppo laajentaa uusilla raporteilla ja ominaisuuksilla.

Tehty ratkaisu

Rakensin portaalin jossa sekä frontend että back­end elävät samassa monorepossa ja puhuvat tiukasti tyypite­tyllä OpenAPI-sopimuksella.

Loppukäyttäjän kannalta

• Luonnollisen kielen kyselyt datavarastoon. Käyttäjä kirjoittaa “paljonko jäseniä liittyi viime vuonna yhdistykseen X” tai “näytä eroamis­syyt viimeisiltä 12 kuukaudelta”. Portaali muuntaa kysymyksen SQL-kyselyksi suoraan käyttäjän oikeus­rajauksen sisällä, ajaa sen, ja esittää vastauksen sekä taulukkona että valittuna visualisointi­tyyppinä (aika­sarja, palkki, piirakka, heatmap). SQL-taitoa tai raportin tilausta ei tarvita.
• Dokumentti­haku RAG-mallilla. Asiakkaan satoja/tuhansia PDF- ja Word-dokumentteja indeksoidaan automaattisesti vektori­hakuun. Käyttäjä kysyy “mitä työehto­sopimus sanoo irtisanomis­ajasta tilanteessa X”, portaali hakee relevantit tekstikatkelmat ja vastaa niihin nojaten — vastaus on aina groundattu oikeisiin lähteisiin, ja linkit alkuperäisiin kohtiin ovat mukana jatkotutkimusta varten.
• Interaktiiviset raportit. Suodattimet, aikasarjat, porautuminen yhdestä näkymästä toiseen — ei enää kokoelma PDF:iä tai HTML-tiedostoja joita joku tuottaa kuukausittain.
• Samat käyttö­oikeudet, riippumatta työkalusta. Kirjautuneena omalla Entra ID -tunnuksella käyttäjä näkee vain ne tiedot joita kuuluu nähdä, olipa kyse raportista, vapaasta kyselystä tai dokumentti­hausta.

Arkkitehtuurin kannalta

• BFF-arkkitehtuuri sisäisellä ingressillä. Back­end-API ei ole koskaan tavoitettavissa julkisesta verkosta. Vain frontin server-kerros voi kutsua sitä sisä­verkossa. Tunnistuksen kiertäminen on mahdotonta arkkitehtuurin tasolla — ei riippuvainen siitä että joku muistaa laittaa lukon päälle.
• Easy Auth reuna­tasolla. Entra ID -kirjautuminen hoidetaan Azure Container Apps -tasolla ennen kuin pyyntö päätyy sovelluksen koodiin. B2B-vieraat tunnistetaan natiivisti — ei SAML-konfiguraatiota sovelluksen puolella. Sisäiset työntekijät kirjautuvat saumattomasti, vieraat saavat oman hyväksymis­kulkunsa kerran, jälkeenpäin SSO.
• Row-level security kysely­tasolla. Jokainen SQL-kysely rajataan käyttäjän sallittuihin resursseihin automaattisesti back­endin yhdessä kohdassa — ei raportti­kohtaista “muista lisätä WHERE”-tarkistusta, jota voi unohtaa. Sama sääntö koskee myös LLM:n generoimia kyselyjä: käyttäjä ei voi pyytää dataa johon hänellä ei ole oikeutta.
• LLM groundattuna oikeaan dataan, ei muistiin. Sekä datakysely­ominaisuus että dokumentti­haku rakentuvat tiukasti sille periaatteelle että LLM ei kerro vastauksia — se hakee vastaukset ja esittää ne. Väärä luku tai olematon lause ei mahdu vastaukseen koska se ei löydy lähteestä.
• EU Data Zone alueellinen pakko. Kaikki Azure OpenAI / AI Search -resurssit on pinnattu Sveden ja Länsi-/Pohjois-Euroopan alueisiin ja DataZoneStandard-SKU:hun. Terraform-validaattori hylkää apply-ajon jos globaali alue yritettäisiin erehdyksessä konfiguroida.
• Dynaamiset raportit, ei HTML-artefakteja. Uusi raportti = yksi SQL-näkymä + yksi React-komponentti + yksi rivi raportti­rekisteriin. Ei build-aikaisia generointi­skriptejä, ei sata erillistä HTML-tiedostoa. Interaktiivinen suodatus ja porautuminen on oletus, ei jälkikäteis­projekti.
• Audit-loki kaikesta liiketoiminta­kriittisestä toiminnasta. Kuka kysyi mitä, milloin, ja minkä käyttäjän oikeuksilla (impersonaatio mukaan lukien) — tallennetaan immutabiliin lokiin jonka voi tarvittaessa tuottaa viranomais­selvityksessä. Kattaa raportit, vapaat datakyselyt ja dokumentti­haut.

Lopputulos

Asiakas sai oman brändi­mukaisen portaalin, joka:

• Madalsi radikaalisti tiedon­saannin kynnystä. Aiemmin “pitää osata SQL:ää tai pyytää asiantuntijalta” → nyt “kysy omalla kielelläsi ja saat vastauksen”. Sama koskee dokumentti­pinoa: ennen “tarvitset henkilön joka muistaa missä asia on kirjattu”, nyt “kysy ja katso viittaus”.
• Korvasi maksullisen BI-tuotteen asiakkaan ja kumppaniorganisaatioiden käyttäjille — käyttäjä­määrä ei enää aja lisenssi­kustannusta.
• Yhdisti aiemmin hajallaan olleet HTML-raportit yhdeksi interaktiiviseksi palveluksi, josta suodatus, aikasarjat ja porautuminen onnistuvat ilman että joku ylläpitää erillistä skripti­kokoelmaa.
• Kunnioitti käyttö­oikeuksia automaattisesti kaikissa kanavissa — raporteissa, datakyselyissä ja dokumentti­haussa.
• Täyttää EU-residenssi­vaatimukset sisään­rakennetusti — compliance on arkkitehtuurin ominaisuus, ei erillinen tarkistus­lista.

Projektissa yhdistyi strategia­taso (teknologia­valinnat, kustannus­mallin muutos, käyttö­kokemuksen radikaali parannus), tekninen arkkitehtuuri (BFF, RLS, RAG, NL-to-SQL, EU Data Zone -pakotus, OpenAPI-codegen) ja tuotteistus­ajattelu (per-deployment multi-tenancy, jotta alusta on siirrettävissä samankaltaisille organisaatioille).