North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
Se mihin kaikkeen järjestelmää kannattaa käyttää, vaihtelee paljon järjestelmäkohtaisesti. Teknisiä ratkaisuja haetaan tyypillisesti kolmesta eri laarista: järjestöille suunnatuista jäsentietojärjestelmistä, geneerisistä CRM-ratkaisuista tai räätälöidyistä ratkaisuista.
Julkaisimme keväällä laajan selvityksen Suomessa käytössä olevista CRM-järjestelmistä, ja siihen liittyen myös vinkkimme CRM-järjestelmän valintaan. Tähän artikkeliin koostimme vinkkimme jäsenrekisterin valintaan erityisesti järjestöille.
1. Kirkasta ensin tavoitteet ja vaatimukset
Ehkäpä tärkein vinkkimme on, että ratkaisua ei kannata valita ennen huolellista tarvekartoitusta. Valmisteluvaiheessa oikaiseminen johtaa usein isoihin ongelmiin myöhemmin. Tarvekartoituksessa tulee selvittää ainakin:
- Miksi uusi järjestelmä tarvitaan?
- Kenelle järjestelmä ensisijaisesti on tarkoitettu?
- Mitä haasteita ja ongelmia halutaan ratkaista?
- Mitkä ovat järjestelmän tehtävät ja roolit?
- Mikä on hyväksyttävä hintataso?
- Miten ja missä aikataulussa järjestelmä otetaan käyttöön?
Tarvekartoituksen yhtenä tärkeimpänä tehtävänä on muodostaa selkeä käsitys siitä, mitkä ovat järjestelmäuudistuksen tavoitteet ja priorisoida ne. Onko ensisijainen tavoite esimerkiksi jäsenten tietojen hallittavuuden parantaminen, laskutuksen sujuvoittaminen, tapahtumien hallinnan parantaminen, itsepalveluasteen lisääminen tai jäsenviestinnän kehittäminen?
Olennaista on myös pyrkiä hahmottamaan siltä kantilta, minkälaisen roolin järjestelmä tulisi saamaan organisaation toiminnan tukemisessa: Onko roolina toimia vain melko yksinkertaisena asiakastietojen rekisterinä, järjestön koko toimintaa ohjaavana monipuolisena toiminnanohjausmoottorina vai jotain siltä väliltä?
Jo tavoitteiden selkeä priorisointi auttaa haarukoimaan hieman sitä, minkä tyyppisiä ratkaisuja kannattaisi lähteä kartoittamaan tarkemmin.
2. Määritä pakolliset ominaisuudet ja toiminnallisuudet
Jäsentietojärjestelmän ydintoiminnot voidaan toteuttaa useimmilla jäsen- tai asiakastietojen käsittelyyn tarkoitetulla järjestelmällä. Tällaisia toimintoja ovat esimerkiksi:
- Jäsentietojen hallinta: liittymiset, eroamiset, jäsenluokat
- Maksujen käsittely: laskutus, viitesuoritukset, verkkopankki- ja korttimaksut
- Raportointi ja analytiikka: jäsenmäärän kehitys, maksutilanne, aktiviteetit
Jäsenrekisteri ei kuitenkaan ole yksinäinen saareke, joten pelkästään näillä perustoiminnoilla ei vielä pitkälle pötkitä.
Järjestötoiminnassa korostuvat usein tietyt erityispiirteet, joita kaikki järjestelmät eivät välttämättä tuekaan. Esimerkiksi jäsenten itsepalvelukäyttöliittymät omien tietojen hallintaan, tapahtumiin ilmoittautumiseen tai laskujen maksamiseen ovat usein toiminnan kannalta kriittisiä, mutta niitä harvemmin löytyy valmiina CRM-järjestelmistä, jotka on suunnattu tukemaan ensisijaisesti yritystoimintaa.
Jäsentiedoissa voi myös olla tarvetta hyvin monimutkaisillekin hierarkkisille tasoille, rooleille ja riippuvuussuhteille, joihin yksityiselle sektorille suunnitelluista järjestelmistä ei löydykään tukea. Saman henkilön on ehkäpä voitava toimia eri ajanhetkinä eri rooleissa, ja hänellä voi olla toimintaan liittyen monenlaisia vastuita ja tehtäviä, kulloisenkin roolin mukaan. Alaikäiselle jäsenelle on tyypillisesti voitava myös kirjata yksi tai useampi huoltaja, joiden täytyy pystyä asioimaan alaikäisen puolesta.
Järjestelmän on oltava helppokäyttöinen kaikille käyttäjäryhmille hyvin monenlaisissa tilanteissa ja erilaisilla päätelaitteilla.
Laajempien toiminnallisten kokonaisuuksien osalta on tärkeää kirkastaa paitsi niiden tarve ylipäätään, myös tekninen kokonaisarkkitehtuuri ja eri järjestelmien väliset roolitukset. Tulisiko tällaisten toiminnallisuuksien sijaita jäsenrekisterissä, vai kenties jossakin toisessa järjestelmässä, joka integroitaisiin tai linkitettäisiin rekisteriin?
Esimerkkeinä tällaisista mainittakoon vaikkapa:
- Viestintätyökalut: sähköpostit, uutiskirjeet, kohdennetut listat
- Jäsenetujen hallinta: yhteistyökumppanit, jäsenedut, jäsentuotteet
- Tapahtumien hallinta: ilmoittautumiset, osallistujalistat ja -maksut, tapahtumatuotteiden myynti
- Kirjautumispalvelut jäsenille: tunnistautuminen, luvittaminen, sisältöjen kohdentaminen profiilitietojen perusteella
- Itsepalvelukäyttöliittymät jäsenille: omien tai huollettavien tietojen päivitys, laskujen maksaminen, jäsenkortit
- Asiointityökalut: Palvelupyynnöt, toimeksiannot, jäsenkysymykset, neuvontapalvelut
Järjestelmältä vaaditut, oman toiminnan kannalta pakolliset ominaisuudet on tärkeä tunnistaa mahdollisimman aikaisessa vaiheessa pureutumalla jokaiseen aiheeseen huolella ja miettimällä, mitkä ovat ne erityistarpeet juuri omassa organisaatiossa ja toiminnassa.
3. Hahmota vaihtoehtoiset toteutustavat
Kun tärkeimmät toiminnot on pääosin kartoitettu, kannattaa vielä miettiä, minkälaisia erilaisia toteutusskenaarioita toivottuun lopputulokseen pääsemiseksi tavoitellaan. Jos vaatimukset ovat kohtuullisen maltillisia, on täysin mahdollista, että markkinoilta löytyy valmistuotteista, jotka vastaavat ainakin suurimpaan osaan vaatimuksista. Todennäköisempää kuitenkin on, että tarvittava järjestelmäkokonaisuus kannattaa rakentaa useammasta palasesta.
Jos kaiken toiminnallisuuden keskittää yhteen järjestelmään, riskinä on, että uudesta järjestelmästä tulee valtava monsteri, jonka hallinnointi ja jatkokehittäminen käy ennen pitkää hankalaksi ja kalliiksi. Eri järjestelmien väliset roolitukset on tärkeä miettiä huolella ja keskittyä sujuvoittamaan prosesseja siellä, missä se on järkevää.
Esimerkiksi uutiskirjeiden, markkinoinnin tai vaikkapa tapahtumien hallintaan on usein järkevää käyttää siihen varta vasten suunniteltuja järjestelmiä. Myös vaikkapa mobiilikäyttöisten itsepalvelukäyttöliittymien toteutus voi onnistua parhaiten jollakin kolmannen osapuolen ratkaisulla. Erilaisten ratkaisumallien vertailu onkin olennainen osa hyvää valmistelutyötä.
Kaiken pohjalla on kuitenkin se jäsenrekisteri, joka keskustelee sujuvasti muiden ohjelmien kanssa. Ja tästä päästäänkin sujuvasti seuraavaan aiheeseen, eli rajapintoihin.
4. Varmista, että järjestelmässä on kattavat ja hyvin dokumentoidut rajapinnat
Jäsentoimintaan liittyvää tietoa on usein tallennettuna monessa järjestelmässä ja monessa eri muodossa. Jäsenrekisterin tehtävänä onkin usein keskittää ja yhdenmukaistaa tätä jäsentietoa siten, että sama tieto on käytettävissä yhdenmukaisena kaikkialla.
Jäsenrekisterit ja CRM-järjestelmät ovatkin korostuneesti järjestelmiä, joista haetaan tietoja muualle, ja jonne myös pitää pystyä viemään tietoa ketterästi rajapintojen kautta. Modernit, kattavat ja hyvin dokumentoidut ohjelmalliset API-rajapinnat mahdollistavat tiedon sujuvan siirron esimerkiksi jäsenrekisteristä taloushallinnon tai sähköpostimarkkinoinnin järjestelmiin.
Järjestelmien yhteensopivuus ja sujuva tiedonkulku eri järjestelmien välillä on tärkeää pyrkiä varmistamaan jo mahdollisimman aikaisessa vaiheessa. Monet järjestelmät tarjoavat valmiita liitännäisiä ja lisäosia, jotka parhaimmillaan voivat helpottaa ja nopeuttaa integraatioiden rakentamista paljonkin. Aina niistäkään ei ole apua, jolloin integraatioita on pakko tehdä enemmän tai vähemmän räätälöiden.
Hyvien rajapintojen merkitys korostuu usein myös järjestelmän käyttöönoton yhteydessä, kun selvitellään, miten esimerkiksi olemassa olevat jäsentiedot voidaan lukea koneellisesti vanhasta järjestelmästä uuteen.
5. Huomioi elinkaarikustannukset pitkällä aikavälillä
Järjestelmien kustannusvertailu on haastavaa, sillä hinnoittelumallit vaihtelevat paljon ja ovat usein tilaajakohtaisia. Esimerkiksi voittoa tavoittelemattomille järjestöille saattaa olla tarjolla normaalia edullisempia lisenssejä.
Useimmat jäsenrekisteri- ja CRM-järjestelmistä perustuvat kuitenkin jonkinlaiseen käyttäjämäärän perusteella määritettävään kuukausittaiseen hinnoitteluun. Järjestelmätoimittajan tulkinta voi kuitenkin vaihdella esimerkiksi siitä, lasketaanko käyttäjiksi vain ylläpitokäyttäjät vai myös esimerkiksi luottamustehtävissä toimijat tai jäsenkäyttäjät.
Käyttäjäkohtaisten hintojen lisäksi kannattaa selvittää muun muassa:
- Kertamaksut, kuten käyttöönottoprojektista, mahdollisista räätälöinneistä ja lisämoduulien hankinnasta koituvat kustannukset
- Jatkuvat kustannukset, kuten käyttöpalvelumaksut ja ylläpitomaksut
- Koulutus-, konsultointi- ja jatkokehityskustannukset
- Käyttäjämäärän kasvun vaikutukset tulevaisuudessa
Verrattuna esimerkiksi verkkosivustoihin ja verkkojulkaisemisen välineisiin, jäsenrekisterin elinkaari on tyypillisesti huomattavasti pidempi. Erityisesti jatkuvat kustannukset ja tulevaisuuden tarpeet onkin hyvä pyrkiä huomioimaan mahdollisimman pitkällä aikavälillä, esimerkiksi kymmenen vuoden ajalta. Näin pitkällä aikavälillä asioiden ennustaminen on toki hankalaa, kun tarpeet voivat muuttua paljonkin ja toimittajatkin saattavat muuttaa matkan varrella hinnoitteluaan. Vähintäänkin paras arvaus pitäisi kuitenkin aina pyrkiä selvittämään eri toteutusmalleista.
Eri ratkaisujen elinkaarikustannusten vertailu on usein hyvin silmiä avaava harjoitus. Jos käyttöönotto edellyttää esimerkiksi räätälöintiä, kustannukset voivat painottua vahvasti elinkaaren alkupäähän, mutta käyttö voi silti tulla SaaS-ratkaisuja edullisemmaksi pitkässä juoksussa. Pelkkään käyttäjäkohtaiseen lisenssiin pohjautuvat valmisratkaisut taas ovat tyypillisesti alkuinvestoinneiltaan edullisia, mutta voivat lopulta käydä kalliimmaksi, kun käyttäjämäärät myöhemmin kasvavat.
Tuotteiden ja toimittajien arvioinnissa on tärkeää selvittää paitsi se, vastaavatko tuotteen ominaisuudet juuri omia tarpeita, myös resurssien riittävyys sekä toimittajan että myös oman organisaation puolelta:
- Toimittajan kokemus: Onko toimittajalla kokemusta juuri omaa toimintaa vastaavista asiakkuuksista? Minkälaisia referenssejä toimittajalla on? Minkälaisia kokemuksia verrokkiorganisaatioilla on?
- Toimittajan kyky kehittää ja ylläpitää järjestelmää: Miten vakavarainen toimittaja on? Minkälaiset resurssit heillä on käytettävissä juuri tähän projektiin? Minkälaiset asiakkuuden hoidon ja asiakastuen mallit on käytössä käyttöönoton jälkeen?
- Omien resurssien riittävyys: Onko tarve avaimet käteen -ratkaisulle vai löytyykö omasta organisaatiosta aikaa ja osaamista räätälöidyn järjestelmän projektimuotoiseen kehittämiseen?
- Monitoimittajamallin hallinta: Valitusta ratkaisusta ja toteutustavasta riippuen, kokonaisuus voi myös koostua useiden eri tuotteiden ja toimittajien ratkaisuista. Onko tällaisesta aikaisempaa kokemusta? Tarvitaanko tähän ulkopuolista tukea?
Jos toimittajalla on aikaisempaa kokemusta järjestöjen kanssa toimimisesta ja referenssilistalta löytyy muitakin vastaavia organisaatioita, se luo jo jonkin verran perusluottamusta toimittajaan. Usein kuitenkin haasteet tulevat eteen vasta, kun ollaan jo siirrytty ylläpito- ja jatkokehitysvaiheeseen. Onko resursseja riittävästi myös tukeen ja jatkokehittämiseen? Kannattaa arvioida myös, miten ”kiinnostava” asiakas oma organisaatio tulisi olemaan verrattuna muihin kyseisen toimittajan asiakkaisiin. Tämä vähän raadollinenkin näkökulma vaikuttaa usein siihen, miten hyvää palvelua toimittajalta kulloinkin saa.
Toteutustavasta riippuen projektien pituudet vaihtelevat muutamasta kuukaudesta useisiin vuosiin, ja toimittajan suorittama tekninen osuus on tietysti vain yksi osa tätä kaikkea. Jos omaa työtä ei ole aikataulutettu ja resursoitu siten, että oikeat henkilöt ovat mukana oikea-aikaisesti ja heillä on myös aikaa panostaa projektiin, tästä muodostuu projektille helposti merkittävä pullonkaula.
Projektinaikaisen määrittely- ja suunnittelutyön lisäksi paljon aikaa ja resursseja vaativia vaiheita ovat myös esimerkiksi jäsentietojen ja muiden sisältöjen syöttö järjestelmään, migraatiot vanhoista järjestelmistä, testaukset projektin eri vaiheissa sekä uuden järjestelmän jalkauttaminen käyttökoulutuksineen. Hyvä on myös miettiä kannattaako järjestelmä ottaa käyttöön kerralla, vai olisiko hyvä vaiheistaa käyttöönottoa jotenkin.
Uuden jäsenrekisterin valinta on strateginen investointi
Suomessakin järjestöillä on hyvin monenlaisia ratkaisuja jäsentietojen hallintaan. Osa on rakentanut ratkaisunsa maailmanlaajuisestikin käytettyjen CRM-alustojen päälle, osa on kotimaisten ohjelmistotuotteiden asiakkaita, osa on avoimen koodin ratkaisujen käyttäjiä. Myös täysin räätälöityjä ratkaisuja näkee toisinaan.
Suomessa on monia jäsenrekisterituotteita ja niiden toimittajia. Yleiskäyttöisistä ratkaisuista suosituimpia ovat CRM-selvityksessämmekin mainitut Microsoftin Dynamics 365, Salesforce ja Odoo, joille kaikille löytyy myös useampia käyttöönottokumppaneita. Erityisesti järjestömaailmassa suosittuja kotimaisia ratkaisuja ovat CRM-Servicen ratkaisu sekä Kehätiedon Kilta-järjestelmä. Näiden lisäksi käytössä on paljon muitakin jäsenpalveluita, esimerkkeinä vaikkapa Vitec Avoine Oy:n Sense ja Yhdistysavain, Digian Lyyti, Populon, Futural sekä urheiluseurojen käyttämät Suomisport ja myClub.
Uuden jäsenrekisterin valinta on strateginen investointi, joka vaikuttaa koko järjestön toimintaan ja jäsenpalveluihin. Selkeiden tarpeiden, tavoitteiden ja arviointikriteerien tunnistaminen helpottaa vertailua ja auttaa valitsemaan järjestelmää, joka tukee järjestön kasvua ja vapauttaa resursseja siihen, mikä on tärkeintä: jäsenten palvelemiseen ja yhteisön vahvistamiseen.
North Patrol on auttanut useita järjestöjä jäsenrekisterin uudistustarpeiden arvioinnissa ja uudistushankkeissa. Tutustu palveluihimme ja ota yhteyttä, jos haluat keskustella vaihtoehdoista lisää.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme:
Intranetin sisältöjen kehitys ja ideoita kevyeen uudistusprojektiin (8.10.2025 klo 10:00).
Ilmoittaudu webinaariin
Lue palveluistamme
Pyydä tarjous
