Näin perintätoimisto vaihtaa perintäjärjestelmän

Perintäjärjestelmälle ei ole olemassa tiettyä vaihtamisajankohtaa tai ikää, jonka jälkeen se pitäisi uusia. Tarkastelkaa sen sijaan toistuvia rakenteellisia rajoitteita, jotka vaikeuttavat liiketoiminnan pyörittämistä tai kehittämistä. Yksittäinen harmituksen aihe riittää harvoin perusteeksi; eri asioissa, toimeksiantajilla ja tiimeissä toistuvat ongelmat kertovat enemmän.

Merkkejä voivat olla esimerkiksi se, että työnkulkujen muutokset edellyttävät manuaalisia kiertoteitä tai toimittajan tekemää kehitystyötä, poikkeustapauksia käsitellään järjestelmän ulkopuolella tai työntekijät siirtävät tietoja toistuvasti työkalusta toiseen. Myös hauraat integraatiot, käsin laadittavat raportit tai puutteellinen näkyvyys eri salkkuihin voivat olla syy järjestelmälliseen arviointiin.

• Toimeksiantajien sääntöjä ja uusia prosesseja on vaikea määrittää järjestelmään.
• Toistuvat työvaiheet ovat edelleen manuaalisia tai vaativat räätälöityä kehitystyötä.
• Talous-, CRM-, maksu- tai viestintäjärjestelmien integraatiot ovat hauraita.
• Luotettavan toimintatiedon saaminen tai asioiden seuranta eri salkuissa on vaikeaa.
• Järjestelmä ei vaikuta pystyvän tukemaan odotettavissa olevia muutoksia toimeksiantajissa, markkinoissa, kanavissa tai asiamäärissä.

Järjestelmä voi olla iäkäs ja silti tukea toimintaa hyvin. Toisaalta uudempi ratkaisu voi sopia organisaation prosesseihin huonosti. Pelkkä nimitys ”legacy” ei kerro, soveltuuko järjestelmä käyttöön.

Keskeinen kysymys ei siis ole: ”Kuinka vanha järjestelmämme on?” Kysykää sen sijaan: ”Tukeeko se nykyistä toimintamalliamme ja tarpeita, joita voimme realistisesti ennakoida tuleville vuosille?” Vertailkaa nykyisen järjestelmän säilyttämisen, modernisoinnin ja vaihtamisen kustannuksia ja riskejä ennen päätöksentekoa.

Perintäjärjestelmä sisältää muutakin kuin aktiiviset asiat. Historialliset tapahtumaketjut voivat sisältää tietoja velallisesta ja toimeksiantajasta, saldon, maksuja, kirjeenvaihtoa, muistiinpanoja, asiakirjoja, tiloja, oikeudellisia toimenpiteitä ja aikaleimoja. Muunnoksessa on säilytettävä tietojen merkitys jatkokäsittelyn ja dokumentoinnin kannalta.

Talouslukujen täsmäytys vaatii erityistä huomiota: avoimet saldot, tapahtumat, kulut, korot, suoritukset ja maksujen kohdistus on pystyttävä ymmärtämään uudessa ratkaisussa. Sama koskee asian nykyistä vaihetta. Toimiston prosesseista riippuen vaiheita voivat olla esimerkiksi vapaaehtoinen perintä, varsinainen perintä, maksusuunnitelma, riitautus, oikeudellinen prosessi tai päätetty asia. Siirrettävät, säilytettävät tai arkistoitavat tiedot on arvioitava toimiston toiminnallisten, liiketoiminnallisten ja oikeudellisten tarpeiden perusteella.

• Integraatiot ERP-, CRM-, maksu-, viestintä-, toimeksiantaja-, data- ja tunnistuspalveluihin, oikeudellisiin ratkaisuihin ja raportointiin.
• Jäljitettävyys, dokumentointi, käyttöoikeudet, historia, auditointijälki ja asiaankuuluvat säilytysvaatimukset.
• Asian tilan, taloustietojen, aiempien tapahtumien ja seuraavan toimenpiteen välinen yhteys.

Aloittakaa dokumentoimalla, mitä järjestelmä käytännössä tekee arjessa – älkää tyytykö käsikirjan tai sopimuksen kuvaukseen. Seuratkaa edustavia tapauksia koko prosessin läpi ja keskustelkaa asianhoitajien, operatiivisen toiminnan, taloushallinnon, compliance-toiminnon, IT:n sekä toimeksiantajasuhteista vastaavien kanssa.

Kartoittakaa työnkulut, manuaaliset tehtävät, integraatiot, tiedot, raportointi, valvontatarpeet ja toimeksiantajakohtaiset määritykset. Kirjatkaa myös kunkin alueen vastuuhenkilö ja se, missä poikkeuksia käsitellään. Tuloksena pitäisi olla yhteinen kuva todellisesta toimintamallista ja ongelmista, joita pyritte ratkaisemaan.

• Prosessit, työnkulut ja manuaaliset kiertotiet.
• Toimeksiantaja- ja salkkukohtaiset säännöt sekä poikkeukset.
• Tiedot, asiakirjat, raportit ja taloudellinen täsmäytys.
• Järjestelmät, integraatiot, omistajuus ja virhetilanteet.
• Toiminnalliset ja oikeudelliset vaatimukset, joita ratkaisun tulee tukea.

Kuvatkaa, miten työn pitäisi jatkossa sujua, ennen uuden alustan valintaa. Selvittäkää, mitkä työnkulut ovat yhteisiä, mitkä vaatimukset riippuvat toimeksiantajasta tai salkusta, missä automaatio on järkevää ja missä työntekijän pitää voida arvioida tai hyväksyä seuraava toimenpide.

Ottakaa huomioon raportointitarpeet, integraatiot, markkinat, odotettavissa oleva kehitys ja prosessien vastuut. Hyödyntäkää järjestelmän vaihto päättääksenne, mitkä vanhan ratkaisun rajoitteet tulee korjata – älkää kopioiko niitä automaattisesti uuteen.

Kaikkia tietoja ei välttämättä pidä siirtää uudelle alustalle samalla tavalla. Rajauksen tulee perustua siihen, mitä tarvitaan jatkuvassa toiminnassa, mitä dokumentointi tai liiketoiminta edellyttää ja mitä voidaan mahdollisesti arkistoida erikseen.

Sopikaa tietoluokista, omistajuudesta, käyttöoikeuksista ja siitä, miten arkistoidut tiedot löydetään myöhemmin. Pyytäkää asiaankuuluvia laki- ja compliance-vastaavia arvioimaan säilytys- ja käyttöoikeusvaatimukset niillä markkinoilla, joilla toimitte; älkää olettako, että yksi yleinen ratkaisu kattaa kaikki lainkäyttöalueet.

• Siirretään ja käytetään aktiivisesti päivittäisessä toiminnassa.
• Siirretään, mutta toiminnallisuus voi olla rajallinen.
• Voidaan arkistoida ja käyttää sovitun menettelyn mukaisesti.
• Ei enää tarvita operatiiviseen käyttöön – jos tämä voidaan perustella ja hyväksyä.

Laatikaa kattava luettelo yhteyksistä esimerkiksi talous- ja ERP-järjestelmiin, CRM:ään, maksupalveluihin, viestintään, toimeksiantajiin, tietopalveluihin, oikeudellisiin järjestelmiin ja BI-ratkaisuihin. Sisällyttäkää API:t, tiedostosiirrot ja muut olennaiset menetelmät.

Jokaisesta yhteydestä tulisi tuntea tietosisältö, suunta, tiheys ja muoto, siitä riippuva prosessi, omistaja sekä se, mitä virhetilanteessa tapahtuu. Selvittäkää myös, pitääkö integraatio rakentaa uudelleen, muuttaa vai poistaa käytöstä ja kuka valvoo sitä käyttöönoton jälkeen.

Tietojen migraatio ei ole pelkkä ”vie ja tuo” -toimenpide. Vanha tietomalli on sovitettava uuteen: jokaiselle kentälle, tilalle ja suhteelle on määriteltävä merkitys. Tunnistakaa kaksoiskappaleet, puuttuvat arvot ja epäjohdonmukaiset tilat sekä päättäkää, miten ne käsitellään ennen tietojen lataamista.

Dokumentoikaa kartoitus ja täsmäyttäkää taloustiedot erikseen, jotta avoimet saldot, tapahtumat, korot, kulut, maksut ja niiden kohdistukset täsmäävät muunnoksen jälkeen. Säilyttäkää tarpeellinen historia sekä tapahtumien, kirjeenvaihdon ja asiakirjojen väliset yhteydet. Testatkaa prosessi edustavalla aineistolla ja pyytäkää liiketoiminnalta hyväksyntä tulokselle.

• Kenttien ja tilojen kartoitus vanhan ja uuden tietomallin välillä.
• Tietojen laatu, kaksoiskappaleet, puuttuvat arvot ja asioiden väliset suhteet.
• Saldojen, tapahtumien, maksujen ja täsmäytysten tarkistus.
• Asiaankuuluvien historiatietojen ja asiakirjojen säilyttäminen ja saatavuus.

Testatkaa muutakin kuin onnistunutta vakiomuotoista siirtoa. Tarkistakaa tiedot ja asiakirjat, työnkulut, integraatiot, taloudellinen täsmäytys, raportit, käyttöoikeudet ja poikkeustilanteiden käsittely. Ottakaa mukaan eri toimeksiantajien ja vaiheiden asioita, jotta testaus vastaa todellista toimintaa.

Kun se on tarkoituksenmukaista, edustavia asioita voidaan käydä läpi sekä vanhassa että uudessa ratkaisussa ennen käyttöönottoa. Määritelkää etukäteen hyväksymiskriteerit, hyväksyjä, virheiden kirjaustapa ja asiat, joiden on oltava kunnossa ennen etenemistä.

• Tietojen validointi ja asioiden sekä asiakirjojen otantatarkastukset.
• Tavallisten työnkulkujen, poikkeusten ja toimeksiantajasääntöjen testaus.
• Integraatioiden päästä päähän -testaus ja virhetilanteet.
• Taloudellinen täsmäytys, raportointi ja käyttäjien hyväksyntä.

Siirtymäajankohta edellyttää konkreettista suunnitelmaa: järjestystä, vastuuhenkilöitä, päätöspisteitä, viestintää, käyttöoikeuksia, tukea ja valvontaa. Kuvatkaa, miten avoimet asiat ja siirtymän aikaan syntyvät tapahtumat käsitellään sekä kuka tekee päätökset, jos edellytykset eivät täyty.

Sopikaa kriteerit jatkamiselle, keskeyttämiselle tai dokumentoidun palautumissuunnitelman käynnistämiselle, jos se on käytännössä mahdollista. Käyttöönoton jälkeen tiimin tulee pystyä ilmoittamaan ongelmista, priorisoimaan korjauksia ja seuraamaan toimintaa tiiviisti. Siirtymä on vakaa vasta, kun uudet työnkulut toimivat käytännössä – ei vain silloin, kun järjestelmä on teknisesti avattu.

Riskejä pienentävät selkeä omistajuus, dokumentoidut päätökset ja tärkeimpien toimintaprosessien testaaminen. Vaiheittainen siirtymä voi olla sopiva joissakin ympäristöissä, mutta se ei ole automaattisesti paras vaihtoehto: siirtymämallin valinta riippuu arkkitehtuurista, asiamääristä, riskiprofiilista ja toiminnan vaatimuksista.

Älkää vertailko pelkkiä ominaisuuslistoja. Arvioikaa, sopiiko alusta tavoiteltuun toimintamalliin, pystyykö se käsittelemään olennaisia salkkuja ja tukeeko se siirtymää, jota organisaationne pystyy hallitsemaan. Pyytäkää toimittajia näyttämään, miten konkreettisia esimerkkejä omasta toiminnastanne käsitellään.

Perintäjärjestelmän valintaa käsittelevä oppaamme syventää arviointia. Käyttäkää sen kriteerejä yhdessä migraatiovaatimustenne kanssa ja kysykää esimerkiksi, miten työnkulut määritetään, miten toimenpiteitä voidaan jäljittää, miten raportit tukevat toimintaa ja mikä toimittajan rooli on ennen käyttöönottoa, sen aikana ja sen jälkeen.

• Työnkulut: Voimmeko määrittää eri prosesseja toimeksiantajan tai salkun mukaan ilman, että joka kerta rakennetaan uusi ratkaisu?
• Automaatio: Mitä jäsenneltyjä asian käsittelytehtäviä voidaan automatisoida, ja miten työntekijät voivat tarkistaa tai ottaa prosessin haltuun?
• Useat toimeksiantajat ja salkut: Miten toimeksiantajien säännöt, tiedot ja käyttöoikeudet pidetään erillään samalla, kun toimistolla säilyy kokonaiskuva toiminnasta?
• Integraatiot ja API:t: Mitä integraatiomenetelmiä on käytettävissä, miten virheitä valvotaan ja miten tiedonsiirto testataan päästä päähän?
• Compliance ja jäljitettävyys: Mitkä tapahtumat, päätökset ja käyttöoikeuksien muutokset voidaan dokumentoida, ja miten käyttäjäoikeuksia hallitaan?
• Raportointi: Voivatko operatiivisesta toiminnasta vastaavat seurata asioiden tilaa, poikkeuksia ja salkkuja, ja voidaanko raportointi sovittaa tarpeisiinne?
• Skaalautuvuus: Miten alusta käsittelee asiamäärien muutokset, uudet toimeksiantajat tai markkinat, ja mitä edellytyksiä tähän liittyy?
• Ihmisen valvonta: Missä työntekijät voivat arvioida, hyväksyä tai ohittaa automatisoituja toimia?
• Migraatio: Mitä tietoja ja historiallisia asiakirjoja voidaan siirtää, miten kartoitus ja taloustiedot validoidaan ja mitä pitää arkistoida erikseen?
• Käyttöönotto ja tuki: Kuka omistaa suunnitelman, testauksen ja siirtymän, mitä toimiston työpanosta odotetaan ja millaista tukea on saatavilla käyttöönoton jälkeen?

Käyttäkää kysymyksiä saadaksenne konkreettisia ja vertailukelpoisia vastauksia. Selvittäkää, kuka tekee mitä, mitä toimiston pitää itse toimittaa ja miten vastuut ja päätökset dokumentoidaan.

Yleisimmät sudenkuopat syntyvät, kun siirtymää käsitellään teknisenä siirtona toiminnan muutoksen sijaan. Niitä voidaan ehkäistä ottamalla mukaan asiat tuntevat tiimit ja testaamalla muutakin kuin järjestelmän vakioprosessit.

• Virhe 1 — Migraation käsittely puhtaasti IT-projektina. Operatiivisten tiimien tulee kuvata asian käsittelypolut, poikkeukset ja keskeytysten seuraukset.
• Virhe 2 — Alustan valinta ennen nykyisen toimintamallin ymmärtämistä. Kartoittakaa ensin, miten järjestelmää todella käytetään, mukaan lukien manuaaliset kiertotiet.
• Virhe 3 — Kaiken siirtäminen tarpeita rajaamatta. Päättäkää, mitkä tiedot tarvitaan operatiivisesti ja mitkä voidaan arkistoida hyväksytyn prosessin mukaisesti.
• Virhe 4 — Integraatioiden merkityksen aliarvioiminen. Yhteys voi vaikuttaa suorituksiin, viesteihin tai asian päivityksiin; kirjatkaa kunkin tietovirta, omistaja ja virhetilanne.
• Virhe 5 — Vain ”happy path” -polun testaaminen. Ottakaa mukaan puuttuvat tiedot, hylätyt maksut, kaksoiskappaleet, riitautukset ja muut olennaiset poikkeukset.
• Virhe 6 — Toimeksiantajakohtaisten työnkulkujen sivuuttaminen. Testatkaa edustavien toimeksiantajien säännöt ja vaihtelut sen sijaan, että olettaisitte yhden prosessin sopivan kaikille.
• Virhe 7 — Käyttöönoton pitäminen maaliviivana. Suunnitelkaa valvonta, tuki ja vakauttaminen, kun käyttäjät ottavat uuden toimintamallin käyttöön.
• Virhe 8 — Legacy-prosessien kopioiminen uuteen alustaan. Erottakaa välttämättömät liiketoimintavaatimukset tavoista, joita voidaan parantaa.

Onnistuminen ei tarkoita vain sitä, että toimistolla on uudempi järjestelmä. Se tarkoittaa, että toiminta jatkuu hallitusti, tietoja voidaan käyttää ja täsmäyttää ja työntekijät tietävät, miten asioiden käsittely jatkuu siirtymän jälkeen.

Hyviä merkkejä voivat olla tarpeettomien manuaalisten vaiheiden väheneminen, mukautettavat työnkulut, ylläpidettävät integraatiot, selkeä raportointi ja asianmukainen ihmisen valvonta. Arvioikaa tulosta suhteessa tavoitteisiin, jotka määrittelitte ennen toimittajan ja alustan valintaa.

• Vakaa toiminta ja luotettavat asia- ja taloustiedot.
• Hallittu siirtymä ja selkeä vastuunjako.
• Sovitun toimintamallin tukevat työnkulut ja integraatiot.
• Läpinäkyvä raportointi ja mahdollisuus kehittää prosesseja ajan mittaan.

Tässä osiossa kuvataan Debbien omaa näkökulmaa. Debbie kehittää perintäalustaa, joka yhdistää järjestelmiä, asioita ja velallisia perintäprosessin eri vaiheissa. Tuotemateriaaleissa kuvataan määritettäviä työnkulkuja, jäsennellyn asian käsittelyn automatisointia ja integraatiomahdollisuuksia, ja samalla ihmiset voidaan ottaa mukaan silloin, kun tarvitaan harkintaa.

Tämä ei yksin kerro, sopiiko Debbie tietylle toimistolle tai pystyykö se siirtämään toimiston nykyisen järjestelmän tiedot. Soveltuvuus, migraation laajuus, vastuut ja integraatiotarpeet on selvitettävä toimittajan kanssa tapauskohtaisesti ja arvioitava toimiston toimintamallia vasten.