ForgeRockin menestystarina API-integraatioissa

Financial Accounting Standards Boardin (FASB) käyttöön ottama aihe ASC 606, Tuotot asiakassopimuksista, muuttaa merkittävästi sitä, miten yritykset kirjaavat tuottoja. ForgeRockin täytyi ymmärtää tietojensa tärkeys ja tuottojen kirjaamisen tarkkuus seuratakseen liiketoimintansa kokonaisterveyttä säilyttääkseen säännöstenmukaisuuden ja tunnistaakseen kasvumahdollisuuksia.

He tiesasivat, että heillä oli tiukka aikataulu ASC 606 -käyttöönoton loppuun saattamiseksi, ja resurssien, ajan ja budjetin puutteen vuoksi oli selvää, että nämä esteet saattaisivat viivästyttää projektin etenemistä. ForgeRock oivalsi tarvitsevansa väliohjelmistoratkaisun, joka on riittävän joustava varmistaakseen, että liikevaihto voidaan kirjata johdonmukaisesti koko liiketoiminnassa samalla, kun noudatetaan uutta tuloutusstandardia (ASC 606). Lisäksi ASC 606:n tarkka käyttöönotto edellytti useiden aiempien vuosien talousraportoinnin tarkastelua taaksepäin.

Yhden suhde yhteen -ratkaisun toteuttaminen muuttaa liiketoimintaprosessit radikaalisti

ForgeRock käytti Intacctin sopimusmoduulia, joka on kehitetty nimenomaan ASC 606 -standardin mukaiseksi. Jo ennen kuin ASC 606 -vaatimuksia otettiin huomioon Intacctin käyttöönotossa, Intacct-ratkaisun liiketoimintalogiikka olisi pakottanut tekemään merkittäviä muutoksia Salesforce-järjestelmän logiikkaan. Koko toimintatavan ja myyntiprosessin muuttaminen Salesforce:ssä ei tullut kyseeseen, koska se on sidottu suoraan Salesforce:hen yksi-yhteen-suhteessa. Näiden ei-toivottujen muutosten välttämiseksi ForgeRockin oli pidettävä nämä kaksi järjestelmää erillään. Yrityksen oli kuitenkin turvauduttava API-alustaan, joka pystyi ottamaan kaiken liiketoimintalogiikan, yhdistämään sen ja sijoittamaan sen API-palveluun käytettäväksi.

Tämä oli äärimmäisen monimutkaista, koska ForgeRockilla on 10–12 yhtiötä, joissa sillä on palkanlaskenta. Kaikissa yhtiöissä on provisioiden aktivointi ja konsolidoitu toiminnallinen valuutta. Eri osien monimutkaisuuden vuoksi ne oli jaettava tuotteiden, tuotenumeroiden (SKU) ja ehtojen kesken sekä ohjattava välikerroksen (middleware) kautta, jotta niitä voidaan hallita asianmukaisesti. Suunnittelussa oli monia liikkuvia osia, jotka edellyttivät työnkulkuja, joihin sisältyi API-kutsuja, jotka jakoivat tuotenumerot kahteen osaan, minkä jälkeen sovellettiin monimutkaista jäännöshintaan perustuvaa itsenäistä myyntihintaa (SSP) sekä kustannuslaskentaa.

KAAVIO: Forgerock RevRec -tietovirta.

Matkalla kohti historiallisesti vertailukelpoista lukua 606

Toinen suuri ja haastava osa projektia oli historiallisen datan uudelleenmäärittely. Heidän täytyi tyhjentää, poimia yksityiskohtia ja sitten konfiguroida historialliset tiedot uudelleen vertailukelpoisen historiallisen ASC 606 -tuloutusraportoinnin tuottamiseksi. Alun perin ForgeRock halusi käyttöönottoa vuoden 2017 alkupuolella, mutta aikataulussa pysymiseen oli liikaa monimutkaisuuksia. Niinpä he päättivät ottaa askeleen taaksepäin, tarkastella mitä se vaatisi, ja tulivat siihen tulokseen, että heidän täytyi lykätä projektia vuoteen 2018. Tämä päivämäärän muutos antoi ForgeRockille tarvittavan luottamuksen projektin onnistuneeseen loppuun saattamiseen sillä laatutasolla, jonka he tiesivät olevan pakko toimittaa.

“Meidän piti mennä aina vuoteen 2012 asti, koska valitsemamme elinkaaren aikainen kustannusanalyysimme on nelivuotinen. Meidän täytyi tarkastella kaikkea sitä, mitä olimme oikaisemassa. Alun perin olimme oikaisemassa vuotta 2015 ja ottamassa sen käyttöön vuonna 2017, ja siellä oli niin paljon tietoa, kuten sopimuksia ja komissioita, jotka piti käydä läpi, jotta ymmärtäisimme täysin, millainen jaksotettu ja varojen saldo joulukuun 31. päivänä 2015 tulisi olemaan ASC 606 -standardin mukaan”, sanoi ForgeRockin talousjohtaja John Fernandez.

ForgeRockilla oli merkittäviä lähiajan liikevaihtomuutoksia

ASC 606 -standardin mukainen tuloutuksen muutos voi vaikuttaa merkittävästi millä tahansa tietyllä tilikaudella tuloutettuun liikevaihtoon ja siten vaikuttaa yrityksen vuotuisiin kasvuvauhteihin.

Pääomasijoittajayhteisö opettelee yhä ASC 606 -tilinpäätösstandardin vaikutuksia. Se on monessa suhteessa tottunut SaaS-yrityksiin, mutta keskustelua tästä ei vielä juurikaan käydä. Ne, jotka ovat ottamasti tämän käyttöön, kamppailevat ymmärtääkseen lukujen dramaattisen vaikutuksen.

“Lukujemme valossa tämä on aivan uusi maailma, ja meidän on tarkasteltava koko historiallista kehitystä vuodentakaiseen verrattuna ymmärtääksemme paremmin yrityksen suorituskykyä. Meidän on varmistettava, että ymmärrämme, miten lukuja tulee tutkia ennusteidemme parantamiseksi ja millainen tulosvaikutus provisioilla ja aktivoinneilla on. Muutos on ollut suuri, ja sen saamiseksi oikealle raiteille on käytetty paljon resursseja, rahaa ja työtä”, John Fernandez sanoi.

“Ennemmin tai myöhemmin tämä kaikki on mennyttä talvea ja kaikki ovat sopeutuneet uusiin standardeihin, mutta siihen asti uskon joidenkin sijoittajien olevan hämmentyneitä. Jos yritykset eivät tee tätä oikein, seurauksena saattaa olla jopa olennaisia oikaisuja tilinpäätöksiin, mikä on varmasti epämiellyttävää kyseiselle yritykselle. Juuri nyt tilanne on hyvin monimutkainen aikana, jolloin teknologioiden ja prosessien pitäisi yksinkertaistua.”

Ilman oikeaa alustaa olisi monia kipupisteitä

“Monet yritykset saattavat oikaista ja kovakoodata kaiken, mutta tehdessään ensimmäisen muutoksen ne huomaavat pian, että heidän menetelmänsä on puutteellinen ja he saattavat olla jopa unohtaneet jonkin tarvittavista yhteyksistä kirjanpidossa tai itse järjestelmässä. Virheitä syntyy, koska niillä ei ole asianmukaista väliohjelmistoa, joka auttaisi niitä etenemään prosessissa. Tarkastelimme muita iPaaS-ratkaisuja; niissä oli samanlainen toiminnallisuus API-kutsuille ja segmentoinnille, mutta em saaneet niistä haluamaamme käyttötapausta yksinkertaisella tavalla”, John Fernandez sanoi.

Jopa pisteestä pisteeseen -yhteyden tapauksessa ei ole keinoa asettaa tarvittavia message-tunnisteita jonoon. Toisessa päässä tapahtuvista asioista ei olisi lainkaan näkyvyyttä, ja kunkin päätelaitteen tila jäisi epäselväksi. Jos API-kutsu message luodaan lähdejärjestelmästä ja se palauttaa virheen, ja toinen järjestelmä on poissa käytöstä, siitä tulee suuri ongelma. Käsittely on suoritettava uudelleen, mikä on sinänsä jo toinen ongelma.

Jos ForgeRock ei olisi ratkaissut tätä ongelmaa alustansa avulla, yritys olisi kohdannut monia esteitä. Esimerkiksi yrityksen olisi pitänyt kirjoittaa Salesforce:n ja Intacctin sovellusrajapinnat (API:t) ja kehittää niitä molemmissa järjestelmissä datapaketin muuttamiseksi. Tätä projektia ei olisi voitu toteuttaa ForgeRockin olemassa olevien teknologiatoimittajien avulla, eikä yritys halunnut palkata joukkoa kehittäjiä sovellusrajapintojen rakentamiseen.

Jos kuuden resurssin kokonaiskulut jaetaan kuuden kuukauden ajalle, projektin menot saattavat nousta miljoonaan dollariin tai sen yli. Jitterbit-alustan ansiosta ForgeRock pystyi noudattamaan tiukkoja määräaikoja, pysymään budjetissaan ja säästämään arvokkaita resursseja, joita tarvitaan muihin projekteihin.

“On vaikea kuvitella, ettei meillä olisi ollut alustaa, joka auttaa meitä saavuttamaan sen, mitä meidän piti tehdä. Aloitimme kesäkuussa, ja projektin oli määrä valmistua syyskuussa. Olisimme tarvinneet noin kuusi resurssia saavuttaaksemme kyseisen määräajan.” sanoi Anil Madithati, liiketoimintasovelluksista ja arkkitehtuurista vastaava senioripäällikkö.

Tarvitset alustan, joka on tehokas, nopea, skaalautuva ja luotettava.

Jitterbitin avulla ForgeRock luo mukautetun ohjelmistorajapinnan Intacctille; API:n ympärille täytyy toteuttaa paljon liiketoimintalogiikkaa. Nyt tietojen poimiminen järjestelmästä toiseen on äärimmäisen helppoa, jotta tiedot on valmiiksi paketoitu, ne päivittyvät automaattisesti ja siirtyvät nopeasti minne tahansa niiden täytyykään päätyä.

“Tarvitset alustan, joka pystyy hoitamaan uudelleenkäsittelymekanismin. Kyse ei ole vain siitä, että homma saadaan tehtyä, vaan myös skaalautuvuudesta. Jos jokin epäonnistuu, tarvitset alustan, joka auttaa jonottamaan, käsittelemään automaattisesti ja ilmoittamaan viipymättä pääkäyttäjälle, jotta voidaan ryhtyä toimiin heti. Jitterbitin avulla kaikki on automatisoitu, ja ohjelmistorajapintojen luominen on paljon yksinkertaisempi prosessi”, sanoo Anil Madithati.

Yhtiöllä on tällä hetkellä yksi sovellusliittymä (API) Intacct-järjestelmälle ja toinen Visual Compliance -sovellukselle, joka on ForgeRockin lakisääteisten tarkastusten hallintaan tarkoitettu sovellus. Tämä järjestelmä tarkastaa yhteystiedot, liidit ja kirjanpitäjät. Yrityksellä on myös oma sovellusrajapinta, joka poimii säännöllisesti tietoja vaatimustenmukaisuuden varmistamiseksi ja käsittelee ne sitten Salesforce-järjestelmään. ForgeRockilla on yhteensä neljä sovellusrajapintaa – Intacct, RevSym, Visual Compliance ja Salesforce – ja lisää on tulossa. Jitterbit toimii väliohjelmistona Intacct-ERP-järjestelmän ja Salesforce:n välillä. ForgeRock hyödyntää Jitterbit-sovellusliittymää poimiakseen tietoja, kuten myyntilaskut ja myyntitilausdataa, ja lähettää ne RevSym-järjestelmään ASC 606 -standardin vaatimustenmukaisuuden varmistamiseksi, mikä toteutetaan Jitterbitin kautta.