North Patrol on digipalvelujen ja tietojärjestelmien suunnitteluun erikoistunut konsulttitoimisto. Muotoilemme ideoista vision ja palvelukonseptin, löydämme parhaat arkkitehtuuri- ja teknologiaratkaisut, suunnittelemme toimivan käyttökokemuksen ja kilpailutamme ihannekumppanin toteutustyöhön. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
Kansallinen Palvelutietovaranto (PTV) – kannattaako integroida?
Otathan huomioon, että tämä artikkeli on yli 7 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreempana lukemisena sinua voisi kiinnostaa vaikkapa jokin näistä artikkeleista:
Suomalaisessa julkishallinnossa on viime vuodet tehty massiivista digiloikkaa: on luotu kansallisten palvelujen infrastruktuuria, jonka avulla mm. helpotetaan kansalaisten asiointia viranomaisten kanssa. Yhtenä kehityskohteena on syntynyt kansallinen Suomi.fi-palvelutietovaranto (Palvelutietovaranto, PTV), johon organisaatiot tuottavat tiedot tarjoamistaan palveluista ja asiointikanavista – kunnille näiden tietojen tuottaminen on lakisääteistä.
Tälläkin hetkellä Suomen yli 300 kuntaa tuottavat tohinalla palvelukuvauksiaan PTV-järjestelmään, jonka kehitystilanne on seurattavissa beta.suomi.fi-palvelussa. Ajatus on erittäin kaunis ja lupaava, mutta siihen on vielä pitkä matka, että keskitetty palvelutietovaranto helpottaisi tai tukisi kuntien verkkopalvelujen sisällöntuotantoa. Siirtymävaiheessa tehdään paljon päällekkäistä sisällöntuotantoa, ja todennäköisesti myös lyhytikäisiä sovellusratkaisuja.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
Palvelutietovarannon luominen on käynnistynyt muutaman pilottikunnan avulla, ja ensivaiheessa (elokuussa 2016) on luotu syöttölomakkeet, joilla tarvittavat tiedot voidaan tuottaa ja ylläpitää. Syöttölomakkeet ovat melko kiduttavia täytettäviä metatietoineen, joten lakisääteinen tietojen syöttäminen on tuntuva ponnistus kultakin Suomen kunnalta. Jotta työläs tietojen keruu ei herättäisi hallitsematonta vastustusta, on kunnille esitelty PTV:n laajaa hyötypotentiaalia mittavilla koulutuskiertueilla.
Palvelutietovarannon lanseerauksessa on korostettu PTV:n rajapintoja, joiden avulla tietojen luominen / ylläpito onnistuu myös koneellisesti: palvelulupauksena on siis se, ettei tiedontuotanto PTV:hen ole välttämättä ”päällekkäistä työtä”, vaan integroituu luontevasti esim. omien verkkosivujen ylläpitoon.
Tästä lupauksesta innostuneena lukuisat kunnat pyrkivät kaukonäköisiin ratkaisuihin luodakseen julkaisujärjestelmiinsä PTV-integraatioita, jotta ”samoja asioita ei tarvitse ylläpitää monessa paikassa”. Integraatiot eivät kuitenkaan koskaan ole helppoja ja halpoja – PTV:n tapauksessa on vielä todella epäselvää, ovatko ne edes hyödyllisiä.
Ainakin ensimmäisinä kokeilukuukausina (viime kesästä lähtien) beta.suomi.fi on muuntunut esitystavoiltaan ja käyttökokemukseltaan lukuisia kertoja, joten vielä ei ole tiedossa, millaisessa kontekstissa ja millaisella logiikalla käyttäjä kohtaa PTV:n sisällöt. Niinpä kunnissa on hyvin vaikeaa hahmottaa, mitä tietoja oikeasti kannattaisi kertoa PTV:ssä, mitä omilla verkkosivuilla, mitkä tiedot olisivat molemmissa paikoissa, tai missä paikassa olisi ensisijainen tallennuspaikka palvelukuvauksille ja toimipaikkatiedoille. Kun tämä on vielä epäselvää, on erittäin vaikeaa lähteä luomaan kaukonäköisiä, järkeviä integrointitapoja.
Mitä palvelutietovarannosta löytyy?
Suomi.fi-palvelutietovaranto on eräänlainen ”julkishallinnon Keltaiset Sivut”, joka kokoaa kuntien palveluista yhteen seitsemänlaisia tietotyyppejä:
1. Organisaatioita (kuten Mikkelin kaupunki, Petäjäveden kunta tai Etelä-Savon koulutus Oy) 2. ”Lakisääteisiä” palveluja (kuten Kunnallinen perhepäivähoito, Kunnallinen päiväkotihoito, Esiopetuksen oppilashuolto, Koulukuljetus, Perusopetus, Tontin lohkominen, Löytöeläinpalvelut jne.) Palvelukanavia, joiden kautta kansalainen saa palvelut käyttöönsä: 3. Verkkoasiointikanavat (asiointipalvelut) 4. Puhelinkanavat 5. Palvelupisteet (kuten päiväkoti, infopiste, sosiaaliasema jne. ) 6. Tulostettavat lomakkeet 7. Verkkosivut
Nämä PTV:n kokoamat tiedot ovat siis ikään kuin tiivistelmä niistä lakisääteisistä palveluista, jotka kuntien on joka tapauksessa esiteltävä omilla verkkosivuillaan. Tietojen jäsentely, tietorakenteet ja metatiedot sekä esitystavat on kuitenkin PTV:n käyttötarkoituksia varten luotu, joten PTV-tietorakenteista on hyvin vähän iloa tai hyötyä kunnan oman verkkopalvelun esitystapoihin nähden.
Ja vastaavasti, kun kunnat esittelevät alueellisia palvelujaan omilla verkkosivuillaan, pitää kunnan esitellä palveluista suuri määrä sellaista yksityiskohtaista kuvailevaa tietoa, joka ei sovellu PTV:n esitystapoihin. Ja lisäksi kunnan verkkosivuilla pitää esitellä muitakin alueellisia palveluja kuin niitä, jotka PTV:stä löytyvät.
Palvelutietovarannon ”oliot” eivät siis mitenkään vastaa ”yksi-yhteen” kunnan verkkosivuilla esitettäviä ”palvelusivuja”.
Mitä kannattaisi integroida julkaisujärjestelmään?
Mitä näistä tiedoista sitten kannattaisi integroida omaan julkaisujärjestelmään ”yhdessä paikassa ylläpidettäviksi”? Ei oikeastaan mitään!
Tiedot kohdista 1, 2, 3, 4, 6 ja 7 ovat tietosisällöiltään hyvin vähäisiä ja harvoin päivittyviä, mutta PTV:n metatietomalleina monimutkaisia – tehokkainta on siis syöttää ne Palvelutietovarantoon PTV:n omilla ylläpitotyökaluilla, ja tarkistaa tiedot kerran vuodessa (tai kertarysäyksellä, jos verkkopalvelujen www-osoitteet muuttuvat).
Ainoastaan kohta 5 eli palvelupisteet on sellainen tietotyyppi, jonka tietoja (koulujen, päiväkotien, terveysasemien, infopisteiden jne. osoitteita ja puhelinnumeroita) voi olla turhauttavaa ylläpitää erikseen PTV:hen ja omille verkkosivuille. En kuitenkaan näe mitään järkeä siinä, että kumpikaan järjestelmistä valittaisiin ensisijaiseksi ”masterdatan” paikaksi, jossa kunnan toimipaikkojen yhteystietoja ylläpidetään ja josta ne siirrettäisiin yksisuuntaisella tiedonsiirrolla toiseen järjestelmään. Saati sitten kaksisuuntaisella tiedonsiirrolla, joka mahdollistaisi yhteystietojen ylläpidon ”kummassa tahansa” järjestelmässä!
Pikemminkin kuntien kannattaisi rakentaa palvelupisteiden yhteystietoja varten jokin muu ”masterdatan” varasto, jossa yhteystiedot ylläpidetään helposti ja tarkoituksenmukaisesti. Tuosta lähteestä yhteystiedot voidaan siirtää koneellisesti PTV:hen (yksisuuntaisella tiedonsiirrolla PTV:n IN-rajapinnoilla), ja verkkopalvelun tarpeita varten voidaan suunnitella, missä muodossa tiedot siirretään julkaisujärjestelmässä käytettäviksi.
Palvelukuvaukset
PTV sisältää valmiit ”pohjakuvaukset” lakisääteisistä kunnallisista palveluista, kuten ”kunnallinen päiväkotihoito”, ”yksityinen perhepäivähoito”, ”leikkipuistot”, ”esiopetus”, ”koulukuljetus”, ”kouluruokailu”, ”lukiokoulutus”, ”nuorisotilat” tai ”kirjastopalvelut”. Idea on aivan fantastinen, sillä onhan hullua, että Suomen yli 300 kuntaa joutuvat jokainen toistamaan omilla verkkosivuillaan vaikkapa sen, että ”esi-, perus- tai lisäopetuksen oppilailla on oikeus kunnan järjestämään maksuttomaan koulukuljetukseen, jos koulumatka on yli viisi kilometriä yhteen suuntaan tai jos se muutoin on oppilaan ikään tai olosuhteisiin nähden liian vaikea, rasittava tai vaarallinen.”
Eli kun vaikkapa Hyvinkään kaupunki tuottaa palvelukuvauksen koulukuljetuksista, sen ei tarvitse itse luoda tekstiä lakisääteisen palvelun tarjoamisen ehdoista. PTV-kuvausta luotaessa voi ottaa käyttöön valmiin pohjakuvauksen ja siihen voi lisätä kuntakohtaiset tarkennukset koulukuljetusten reunaehdoista.
Ongelmana on kuitenkin se, että esimerkiksi Hyvinkään kaupungilla (kuten muillakin kunnilla) on paljon yksityiskohtaista tarkennettavaa kuljetusten järjestämisestä tai korvauksista eri tilanteissa (A1-kielen opetuksen tai uskonnonopetuksen järjestämispaikan mukaan, vieraassa koulupiirissä koulua käyville oppilaille, maahanmuuttajien lapsille, starttiluokan oppilaille, työelämään tutustumisjaksolle jne.). Viedäänkö kaikki nämä tarkennukset PTV-tietoihin? Vai ylläpidetäänkö ne omilla verkkosivuilla? Kannattaako tarkennuksista mitään kertoa PTV-tiedoissa?
Ja vielä tässä esimerkissäni asiaa mutkistaa se, että ”koulukuljetus”-palvelukuvauksen lisäksi Hyvinkään pitäisi tuottaa PTV:hen myös kuvaukset palveluista ”esiopetuskuljetukset” sekä ”erityispäivähoidon kuljetukset” ja ehkä ”maahanmuuttajien lasten koulukuljetukset”, ne kun ovat metatietokategorioiltaan ja kohderyhmiltään ihan eri palveluja…
Ja jos ajatellaan vaikkapa ”kirjastopalvelut”-esimerkkiä, lienee ihan selvää, että pienenkin kunnan verkkopalvelussa aiheesta kerrotaan tyypillisesti 10–20 sivun verran, kun PTV:ssä palvelu tulee kuvatuksi parilla tekstikappaleella.
Tuntuu siis järjettömältä suunnitella tekninen integraatio, jonka avulla PTV:n muutama tekstikappale tulisi ”koneellisesti siirretyksi” julkaisujärjestelmään, kun integraation vaatimalla työmäärällä tekstien copy-paste tulisi tehtyä tuhansia kertoja…?
Kun palvelukuvaukset on lakisääteisesti pakko tuottaa PTV-ympäristöön, eikö niiden kannattaisi olla mahdollisimman pitkälle nimenomaan kansallisella tasolla yhdenmukaisesti vakiotekstein luotuja kuvauksia, ja kuntakohtaisesti näytetään vain viittaus siihen www-osoitteeseen, jossa kunta kertoo tarkemmat tiedot tämän palvelun järjestämisestä?
Palvelupisteet
PTV:n olennaista antia on se, että julkiset palvelupisteet (eli ”asiointipaikat”) kootaan yhteen. Yleisten aihekategorioiden, helppojen hakusuodatusten tai karttakäyttöliittymän avulla voi vaikkapa lomailupaikkakunnasta tarkistaa, missä olisi lähin kirjasto, terveyskeskus, työvoimatoimisto tai infopiste. Tai uuteen kaupunkiin muuttanut voi katsastaa, missä ovat päiväkodit, koulut, virastot, leikkipuistot jne. Palvelupisteistä löytyvät myös keskeiset hyötytiedot niiden käyntiosoitteista, aukioloajoista, puhelinnumeroista ja palvelukielistä.
Kunnille tämä on hedelmällinen lupaus, kun PTV:n tietovarantoa voidaan käyttää keskitettynä ”puhelinluettelona” kunnan palvelupisteistä. Mutta näihinkin palvelupiste-esittelyihin liittyy ongelmallista rajanvetoa siitä, miten paljon kuvailutietoa palvelupisteestä annetaan PTV:ssä, mikä taas on verkkosivuilla.
Verkkosivuillaan kunnat esittelevät esimerkiksi kaikki päiväkotinsa muutamalla verkkosivulla, jotka sisältävät vaikkapa kuvia, taulukoita, linkityksiä ja tunnelmallisia kuvailutietoja päiväkodin eri ryhmistä – näitä tietoja ei voida viedä palvelutietovarantoon, vaan PTV-kuvaus tiivistyy muutamaan muotoilemattomaan tekstikappaleeseen:
Ja kun PTV:n tietorakenteissa ja näkymissä palvelupiste ”päiväkoti” linkittyy useampaan ”palvelukategoriaan”, joita päiväkodista saa (kuten ”erityisvarhaiskasvatus”, ”esiopetus” jne.), pitäisi päiväkoti onnistua kuvailemaan kaikkien sen tarjoamien palvelumuotojen näkökulmasta. Ja mieluusti ”liitoskohtaan” pitäisi tuottaa jokin teksti kuvaamaan sitä, kuinka palvelu ja palvelupiste yhdistyvät (kuten alla olevassa kuvassa ”Esiopetus” ja Mikkelin erilaiset päiväkodit). Tyypillisesti kuntien verkkosivustoilla tehdään kokonaisvaltaisia ratkaisuja siitä, kuinka kunnan päiväkodit, esiopetus, erityisvarhaiskasvatus jne. esitellään kokonaisuutena, ja nämä ratkaisut eivät istu yksi-yhteen PTV-tietorakenteen kanssa.
Kunnan verkkosivuilla halutaan siis esitellä palvelupisteistä sellaisia rikkaita sisältöjä, joita ei voida siirtää PTV:hen.
Mutta kun palvelupisteiden perustiedot (yhteystiedot, sijaintitiedot, aukioloajat jne.) täytyy esittää PTV:ssä, ovat monet kunnat lähteneet ”päällekkäisen sisällöntuotannon” ehkäisemiseksi sille linjalle, että näiden tietojen ensisijainen luomis- ja ylläpitopaikka on PTV, ja ne tuodaan sieltä integraatioiden avulla omaan julkaisujärjestelmään.
Tässä ratkaisussa PTV-yhteystiedot siirtyvät ”koneellisesti” julkaisujärjestelmään erillisiksi ”sisältötyypeiksi” tai ”elementeiksi”, joita voidaan asettaa www-sivuille samaan tapaan kuin kuvia tai muita uudelleenkäytettäviä sisältöelementtejä (vrt. esimerkiksi Valu Digitalin koeponnistamat PTV-integraatiot WordPressiin). Tässäkään tapauksessa en ole ihan vakuuttunut siitä, että integraatioratkaisu helpottaa tai virtaviivaistaa sisältöjen ylläpitoa millään tapaa.
Metatiedot
Palvelutietovarantoon koottuja tietoja kuvaillaan ja luokitellaan metatiedoilla, jotka on suunniteltu kaukonäköisesti portaalimaisen Palvelutietovarannon kehittämisen näkökulmasta ja PTV-käyttöliittymien tarpeiden mukaan. Metatietoluokittelut valitaan niistä vaihtoehdoista, jotka on jäsennetty palvelussa Finto – Julkisten palvelujen luokittelu. Lisäksi palvelujen luokittelussa käytetään kansallisia ontologiakäsitteitä (JUHO, JUPO, YSO jne.), joita löytyy Finto-palvelusta.
PTV-tietojen luokitteluun pitäisi siis pystyä lisäämään kansallisen luokitteluvaraston mukaisia metatietoja, joita ovat:
Pakollinen palveluluokan valinta: 27 pääluokkaa, niissä useita alaluokkia (esim. päiväkotihoito kuuluu pääluokkaan P3 Perheiden palvelut, ja sen alaluokkaan P3.4 Lasten päivähoito)
Pakollinen pääkohderyhmä: kansalaiset, yritykset vai viranomaiset. Jos palvelu on tarkoitettu erityisesti jollekin alakohderyhmälle (kuten lapsiperheet, vammaiset, ikääntyneet), tämä tarkennetaan metatietoluokittelulla
Vapaaehtoinen ”elämäntilanteen” luokittelu (esim. Lapsen saaminen, Avioero, Vakava sairastuminen, Omaisen kuolema)
Pakollinen ”ontologiakäsite”, joka kuvaa Finton tarjoamista vaihtoehdoista palvelun mahdollisimman osuvasti (esim. ”ruotsinkielinen varhaiskasvatus”)
Näillä metatiedoilla ei ole kunnan tyypillisellä verkkosivustolla juurikaan käyttöä tai hyödyllistä soveltamistapaa: korkeintaan kansalaisten alakohderyhmille tehdään yleensä koontinäkymiä näille kohdennetuista palveluista. (Eikä niitäkään tavallisesti tehdä automaattisesti metatietojen perusteella, vaan manuaalisella toimitustyöllä.)
Niinpä kuntien verkkopalvelujen julkaisujärjestelmiin ei ole ollut tarvetta luoda moniulotteisia taksonomioita metatiedoille, saati sitten kytköstä julkisiin asiasanasto- tai ontologiapalveluihin.
Mikäli PTV-tietojen luomisessa ja ylläpidossa yritetään käyttää ”koneellista siirtoa” julkaisujärjestelmästä Palvelutietovarantoon, pitää julkaisujärjestelmään luoda räätälöidyt työkalut näiden metatietojen tuottamiseen, ylläpitämiseen ja käyttämiseen. Julkaisujärjestelmää täytyy siis räätälöidä PTV:n tarpeita varten tavoilla, joista ei ole hyötyä verkkosivuston ylläpitämisessä. Ja vastaavasti sisällöntuottajien pitää käyttää julkaisujärjestelmässä luokittelutyökaluja, jotka eivät vaikuta sisältösivujen esittämiseen.
PTV:n tarvitsemat metatietoluokittelut ovat välttämättömiä Suomi.fi-palvelun käyttökokemuksen kannalta, mutta verkkosisällöntuottajalle ne taitavat kyllä olla yksinomaan riesa – tästäkin syystä ”PTV-integraatio” julkaisujärjestelmään on mielestäni pikemminkin haitallinen kuin hyödyllinen.
Integraatioista saatava hyöty?
Kuntien on syötettävä palvelukuvauksensa PTV-hakemistoon heinäkuuhun 2017 mennessä, vaikka vielä on epäselvää, millaisia esitystapoja Suomi.fi-palveluhakemisto lopulta saa. Näiden tietojen pohjalta en itse lähtisi panostamaan minkäänlaisiin teknisiin integraatioihin PTV:n ja julkaisujärjestelmän välillä.
Palvelukuvaukset kannattaa alkuvaiheessa syöttää PTV-tietokantaan minimaalisin tiedoin, käyttäen hyväksi valmiita ”pohjakuvauksia” ja liittäen niiden ”asiointikanaviksi” tarkentavat www-sivut kunnan (tai palveluntarjoajan) verkkopalvelusta. PTV:ssä esitettävät kuvaukset ovat joka tapauksessa ”tiivistelmä” niistä rikkaista tiedoista, jotka verkkosivuilla ylläpidetään, joten en usko ”koneellisesta tiedonsiirrosta” syntyvän kovinkaan käyttökelpoisia ratkaisuja. PTV:n tarvitsemia palveluluokitteluja ei ole hyödyllistä monistaa verkkosivuille.
Palvelupisteet yhteystietoineen ja aukioloaikoineen ovat keskitetyn PTV-hakemiston käyttökelpoisinta antia, joten kuntien olisi hyödyllistä löytää ratkaisuja siihen, ettei näitä tarvitse ylläpitää erikseen PTV:ssä ja verkkosivuilla. Julkaisukanavissa esitettävät kokonaistiedot palvelupisteestä (päiväkodista, kirjastosta, sosiaaliasemasta jne.) ovat kuitenkin aivan erilaisia: Suomi.fi-palvelutietovaranto esittää hyvin tiiviit ja vahvasti rakenteistetut kuvaukset, kunnan verkkosivuille luodaan julkaisujärjestelmällä rikkaat ja monipuolisesti muotoillut kuvaukset. Kun PTV:n ja julkaisujärjestelmän käyttötarkoituksia varten tarvitaan ”samoista tiedoista” varsin erilaisia ilmentymiä, ei kumpikaan ympäristö vaikuta sopivalta tietojen ensisijaiseksi tallennuspaikaksi?
Palvelupisteiden tietojen ylläpidon kannalta vaikuttaisi kaikkein toimivimmalta ratkaisulta ylläpitää jonkinlaista kunnan omaa ”masterdata”-tietokantaa (”puhelinluetteloa”), jossa kunnan palvelupisteiden tiedot olisi helppoa tuottaa ja ylläpitää hajautetusti. Tästä masterdatasta tiedot voitaisiin siirtää PTV:ssä näytettäviksi sekä julkaisujärjestelmään www-sivuille yhdistettäviksi: kummassakin järjestelmässä tiedoille voidaan rakentaa sellainen konteksti, jota järjestelmän esityslogiikka tarvitsee.
…tällä ratkaisulla tosin saadaankin kuntien ylläpidettäväksi PTV:n ja julkaisujärjestelmän lisäksi vielä kolmaskin järjestelmä, johon on toteutettava integraatiot PTV:hen ja julkaisujärjestelmään. Etenkin kun kuntien omat ”keskitetyt puhelinluettelot” tuntuvat nykyiselläänkin olevan ongelmallisia rakennettavia, ovat arkityön tehostamisen ja virtaviivaistamisen tavoitteet vielä aika kaukana!
Vaatimusmäärittely on digiprojektissa keskeinen dokumentti, jonka avulla konkretisoidaan tietojärjestelmän tai verkkopalvelun suunnittelu, hahmotetaan tekniset ratkaisut, pyydetään toteuttajalta perusteltu työmäärä- tai kustannusarvio ja ohjataan ketterän toteutustyön työtehtäviä. North Patrolin vetämässä määrittelytyössä vaatimukset saadaan kirjattua laadukkaasti, asiantuntevasti ja kustannustehokkaasti.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme:
Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00).
Ilmoittaudu webinaariin
FM Virpi Blom on verkkopalvelustrategioiden, käyttökokemuksen ja palvelukonseptien asiantuntija. Virpi konsultoi asiakkaitaan strategisten linjausten, konseptoinnin, määrittelyn ja suunnittelun kysymyksissä. Hänen erityisosaamistaan on verkkopalvelujen hyötyodotusten kirkastaminen, positiivisen käyttäjäkokemuksen varmistaminen sekä hankittavien ratkaisujen konseptointi ja määrittely siten, että niin loppukäyttäjien kuin ylläpitäjienkin tarpeet täyttyvät.
Virpin 25-vuotinen kokemus verkkopalvelujen suunnittelusta sisältää satojen internet-, intranet- ja extranet-palvelujen määrittelyä, suunnittelua, toteutusta, käytettävyystestausta ja kehittämistä. Aiemmissa työpaikoissaan hän on mm. toiminut johtavana konsulttina, konsultoinut verkkopalvelujen suunnittelua ja toteutusta lukuisissa eri rooleissa ja vetänyt User Experience -tiimiä.
Autamme laajojen tietosivustojen suunnittelussa, määrittelyssä ja kilpailuttamisessa. Muotoilemme konseptin, tietorakenteet, käyttökokemuksen ja toiminnot hyötypalveluksi, jota on miellyttävä käyttää, helppoa ylläpitää ja kustannustehokasta kehittää koko elinkaarensa ajan.
Meitä on kymmenen konsulttia, kaikki kokeneita suunnittelijoita tai teknologia-asiantuntijoita. Joka vuosi viemme läpi yli 50 projektia, joissa autamme hankkeensa eri vaiheissa olevia asiakkaitamme luomaan uusia digipalveluja ja tietojärjestelmiä. Asiakkaamme ovat olleet erittäin tyytyväisiä työhömme (arvosana 9,5/10), ja monet heistä palaavat asiakkaiksi yhä uudestaan.
Olemme apunasi, kun kaipaat puolueetonta näkemystä teknologiavalintoihin, kirkastusta palvelukonseptin ideaan, tarkennusta vaatimusten määrittelyyn, konkreettista tukea tarjouskilpailuun tai ohjausta toteutusprojektin läpivientiin.
Olemme erikoistuneet digipalveluiden laadukkaaseen suunnittelutyöhön ja vaatimusmäärittelyyn. Missiomme on auttaa asiakkaita onnistumaan hankkeissaan luomalla mahdollisimman hyvät lähtökohdat toteutusvaiheelle – oli sitten kyse ketterästä toteutuksesta omalla tiimillä tai kumppanin kanssa tehtävästä hankkeesta tai julkisesti kilpailutettavasta urakasta.
Emme myy koodausta emmekä lisenssejä
Moni teknologiakonsultti suosittelee asiakkailleen teknisiä ratkaisuja, joita sama talo myös toteuttaa. Meillä tätä vinoumaa ei ole, koska meiltä ei voi ostaa koodausta tai lisenssejä eikä meillä ole riippuvuuksia teknologiatoimittajiin. Näkökulmamme ohjelmistomarkkinaan on laaja-alainen. Tavoitteena on aina löytää asiakkaalle parhaiten soveltuva ohjelmistoratkaisu, oli se sitten räätälöity ratkaisu, saas-palvelu, avoimen lähdekoodin alusta tai näiden yhdistelmä.
Tehokkuus, tavoitteellisuus ja tuloksellisuus
Toimeksiannoillemme sovitaan aina konkreettinen lopputuotos, jonka avulla asiakas pääsee hankkeessaan eteenpäin. Hioutuneiden menetelmiemme ja kokeneiden konsulttiemme ansiosta pystymme tuottamaan sen tehokkaasti, yllättävän vähäisillä työmäärillä, ja rahallesi syntyy vastinetta.
