Toimitus ja jatkuva kehitys

ReApptorin rahoitus koostuu seuraavista:

• Toistuvat asiakastulot
• Projektityö usealle pitkäaikaiselle asiakkaalle
• Valikoidut julkiset ohjelmat sekä tutkimus- ja kehitysohjelmat

Emme ole riippuvaisia yhdestä sijoittajasta tai yhdestä projektista.

Nykyisten asiakassitoumusten ja myyntiputken perusteella toimintamme näkymä ulottuu usean vuoden päähän. Voimme tarvittaessa jakaa tarkempia lukuja NDA:n nojalla, mutta ydinviesti on:

• Kasvamme orgaanisesti
• Investoimme voitot takaisin alustaan
• Vältämme ottamasta sitoumuksia, joita emme pysty tukemaan

Hallitsemme avainhenkilöriskiä seuraavasti:

• Tiimissä on päällekkäistä osaamista (ei yhden kehittäjän varassa olevia järjestelmiä)
• Arkkitehtuurista, käyttöönotoista ja operoinnista ylläpidetään täydellistä dokumentaatiota
• Käytämme vakioteknologioita (jolloin korvaavia osaajia voidaan tarvittaessa palkata markkinoilta)

Jokaisen merkittävän asiakasratkaisun osalta varmistamme, että:

• Projektissa työskentelee aktiivisesti vähintään kaksi kehittäjää
• Lisäksi vähintään yksi muu kehittäjä tuntee koodikannan ja on valmiina antamaan varatukea
• Osaaminen säilyy repositorioissa ja dokumentaatiossa, ei pelkästään ”ihmisten päässä”

Tärkeintä on, että ratkaisumme noudattavat kaikilla asiakkailla samaa alusta-arkkitehtuuria ja samoja kehitysstandardeja, koodityyliä, nimeämiskäytäntöjä, työkaluja ja DevOps-käytäntöjä. Tämä tarkoittaa, että vaikka kehittäjä ei olisi aiemmin työskennellyt tietyssä asiakasprojektissa, hän pystyy luotettavasti tarttumaan työhön, koska ratkaisu on yhdenmukainen kaikkien muiden ReApptor-pohjaisten projektien kanssa. Käytännössä tämä pienentää operatiivista riskiä merkittävästi verrattuna kertaluonteisiin, täysin räätälöityihin toteutuksiin, joissa osaaminen on usein pääasiassa yksittäisten ihmisten varassa eikä toistettavassa kehitysjärjestelmässä.

Lisäksi valtaosa taustalla olevista moduuleista ja arkkitehtuurimalleista on jo todettu toimiviksi useissa tuotantokäyttöönotoissa, mikä vahvistaa koodin laatua, tietoturvaa ja luotettavuutta ajan mittaan.

Jos avainkehittäjiä lähtee tai rahoitusolosuhteet muuttuvat, ensisijainen tavoitteemme on:

• Pitää kiinni SLA-sitoumuksista
• Pitää järjestelmät vakaina ja turvallisina
• Sopia jokaisen avainasiakkaan kanssa jatkuvuussuunnitelmasta

Tähän voi sisältyä:

• Dokumentaation ja tiedonsiirron lisääminen
• Omien tai kolmannen osapuolen kehittäjiesi perehdyttäminen
• Suunnitelmat roolimme asteittaisesta pienentämisestä, jos päätät siirtää kehityksen omaan organisaatioosi

ReApptor on ensisijaisesti asiakasvetoinen yritys. Tiekarttaamme ohjaavat ennen kaikkea todelliset asiakastarpeet ja tuotannon käyttötapaukset, koska strategiamme on kasvaa pitkäaikaisten asiakassuhteiden ja ydinliiketoiminnan työnkulkuihin syvälle ulottuvan integraation kautta.

Lisäksi on kuitenkin aina kaksi muuta lähdettä:

Alustavetoinen (perusta)

Vakaa osuus tiekartan kapasiteetista on varattu alustan perusasioille, jotka hyödyttävät jokaista asiakasta (tietoturvapäivitykset, suorituskyvyn parannukset, luotettavuus, DevOps ja uudelleenkäytettävät komponentit). Tämä suojaa ratkaisuasi pitkällä aikavälillä ja pienentää operatiivista riskiä.

Sijoittaja- ja ohjelmavetoinen (valikoiva)

Kun osallistumme julkisiin tutkimus- ja kehitysohjelmiin, hankkeet valitaan niin, että ne vahvistavat alustaa alueilla, joita asiakkaat jo tarvitsevat (esim. soveltava tekoäly, dokumenttien käsittely, analytiikka). Ne eivät ohita asiakastoimituksia koskevia sitoumuksia.

Jokaisen asiakkaan vaatimuksilla on suora ja näkyvä vaikutus priorisointiin. Annamme tälle muodollisen rakenteen yhteisellä kehitysjonolla ja säännöllisellä ohjaustason priorisoinnilla, jotta sinulla on todellista vaikutusvaltaa ”toimittajan lupausten” sijaan.

Näkemyksemme mukaan yksi minkä tahansa liiketoimintajärjestelmän suurimmista pitkän aikavälin riskeistä ei ole tietyn teknologian vanheneminen vaan se, että järjestelmän oma kehitys pysähtyy.

Ratkaisu, jota ei kehitetä jatkuvasti, vanhenee ajan mittaan väistämättä sekä teknisesti että toiminnallisesti, vaikka se olisi ollut nykyaikainen ja hyvin suunniteltu alkuperäisen toteutuksen aikaan.

Tästä syystä jatkuva kehitys on rakennettu sisään kaupalliseen ja tekniseen malliimme.

Tavanomaiset tekniset päivitykset, joita olemassa olevan ratkaisun pitäminen toimintakunnossa ja ajan tasalla edellyttää – mukaan lukien sovelluskehysten, rajapintojen, protokollien, tietoturvan ja muiden taustateknologioiden muutokset – kuuluvat jatkuvaan ylläpitoon ja SLA:han.

Lisäksi alustalisenssiin sisältyy kolme pientä ominaisuutta tai parannusta kuukaudessa aktiivisen kehitysvaiheen jälkeen. Ne eivät ole pelkkiä ylläpitotehtäviä; niiden tarkoituksena on varmistaa, että ratkaisu paranee edelleen myös sellaisina jaksoina, jolloin aktiiviselle kehitykselle ei ole erillistä budjettia.

Näin syntyy jatkuvan kehityksen polku sen sijaan, että järjestelmä pysyisi muuttumattomana useita vuosia ja vaatisi sitten suuren korvaus- tai modernisointiprojektin.

Toinen tärkeä ero perinteisiin SaaS-tuotteisiin on se, että jokainen ReApptor-ratkaisu kehitetään tietyn asiakkaan liiketoimintaprosessien ympärille. Perinteisen SaaS-tuotteen on tasapainoteltava monen eri asiakkaan vaatimusten välillä, ja siksi se toimii väistämättä kompromissien varassa. Meidän mallissamme parannukset voidaan priorisoida nimenomaan asiakkaan prosessien, käyttäjien ja operatiivisten tarpeiden mukaan.

Uusia teknologioita, myös tekoälyn edistysaskeleita, voidaan siksi ottaa käyttöön vähitellen siellä, missä ne tuottavat todellista liiketoiminta-arvoa, ilman että asiakkaan täytyy käynnistää uusi kehitysprojekti aina, kun taustalla oleva teknologiakenttä muuttuu.

Ratkaisua ylläpidetään ja kehitetään jatkuvasti taustateknologian muuttuessa.

Tavanomaiset tekniset päivitykset, joita olemassa olevan ratkaisun pitäminen toimintakunnossa ja ajan tasalla edellyttää – mukaan lukien sovelluskehysten, rajapintojen, protokollien, tietoturvan ja muun teknologian päivitykset – kuuluvat jatkuvaan ylläpitoon ja SLA:han.

Lisäksi alustalisenssiin sisältyy kolme pientä ominaisuutta tai parannusta kuukaudessa aktiivisen kehitysvaiheen jälkeen. Näin varmistetaan, että ratkaisu kehittyy edelleen silloinkin, kun erillistä aktiivista kehitysprojektia ei ole.

Uskomme, että tämä jatkuva kehitys on muuttumassa erityisen tärkeäksi, koska tekoäly ei ole enää pelkkä automaation työkalu. Siitä on yhä enemmän tulossa käytännön väline liiketoiminnan johtamiseen, päätöksenteon tukeen, prosessien optimointiin, asiakasvuorovaikutukseen ja liiketoiminnan kehittämiseen.

Nykyisten tekoälyteknologioiden luomat mahdollisuudet ovat jo nyt merkittävästi suuremmat kuin vielä muutama vuosi sitten yleisesti odotettiin, ja monilla alueilla ne tarjoavat perustavanlaatuisesti toisen tason tehokkuuden verrattuna perinteisiin ohjelmistoihin ja perinteisiin tapoihin järjestää liiketoimintaprosessit.

Tämä luo erityisen tärkeän mahdollisuuden pienille ja keskisuurille yrityksille. Suurten organisaatioiden on usein paljon vaikeampi muuttaa järjestelmiään, prosessejaan ja sisäisiä toimintamallejaan nopeasti. Pienemmät ja ketterämmät yritykset voivat ottaa uudet teknologiat käyttöön nopeammin, integroida ne suoraan päivittäiseen toimintaan ja mukauttaa työtapojaan jatkuvasti.

Tästä syystä odotamme, että tulevina vuosina monet vakiintuneet toimijat menettävät yhä enemmän asemiaan pienemmille mutta joustavammille yrityksille, jotka pystyvät ja haluavat sopeutua nopeasti uusiin teknologisiin mahdollisuuksiin.

Tavoitteemme ei siksi ole ainoastaan pitää ratkaisua teknisesti yhteensopivana uusien teknologioiden kanssa vaan arvioida jatkuvasti, miten uusia tekoälyominaisuuksia voidaan käyttää parantamaan sitä, miten itse liiketoimintaa johdetaan ja kehitetään.

Järjestelmä, jonka kehitys pysähtyy, vanhenee vähitellen. Mallimme on suunniteltu nimenomaan välttämään tämä tilanne ja pitämään ratkaisu liikkeessä eteenpäin sekä teknologian että asiakkaan liiketoiminnan mukana.

ReApptor ei ole ”myynti edellä” toimiva yritys. Valtaosa liikevaihdostamme ja kasvustamme tulee luotettavista toimituksista, jatkuvista parannuksista ja pitkäaikaisesta yhteistyöstä nykyisten asiakkaiden kanssa. Tämä tarkoittaa, ettemme aseta lyhyen aikavälin myyntiä nykyisille asiakkaille annettujen sitoumusten edelle.

Käytännössä tasapainotamme kapasiteettia seuraavasti:

• Asiakastoimitusten kaista (käynnissä olevat projektit, sovitut välitavoitteet, SLA-sitoumukset)
• Alustakaista (tietoturva, suorituskyky, uudelleenkäytettävät komponentit), joka suunnitellaan niin, ettei se häiritse asiakastoimituksia

Pysyäksemme luotettavina myös kuormitushuippujen aikana käytämme lisäksi joustavaa resursointimallia: meillä on järjestelyt kumppaniyritysten kanssa, jotka voivat tarvittaessa tarjota asiantuntijoita (Suomi, Baltia, Puola, Intia). Tämä lisää toimitusvarmuutta ja pienentää ”ylilupaamisen” riskiä kasvun aikana.

Asiakkaan vaikutusmahdollisuudet varmistetaan hallintomallilla, ei epämuodollisilla lupauksilla:

Yhteinen kehitysjono ja priorisointi

Ylläpidämme yhteistä kehitysjonoa, jonka kohteet järjestetään liiketoiminnallisen prioriteetin mukaan yhdessä kanssasi.

Säännölliset ohjauskatselmukset

Priorisointi käydään läpi sovituin väliajoin (esim. kahden viikon välein), erityisesti tuotantokäyttöönoton ja skaalautumisen välitavoitteiden yhteydessä.

Kerrosten selkeä erottelu

Asiakaskohtaiset tarpeet toteutetaan ratkaisusi repositorioon, kun taas useita asiakkaita hyödyttävät yhteiset parannukset viedään soveltuvin osin uudelleenkäytettäviin komponentteihin.

Käsittelemme tiekarttaasi strategisesti tärkeänä ja pidämme priorisoinnin läpinäkyvänä, dokumentoituna ja päätöksiin perustuvana.

Vältämme aktiivisesti liiallista räätälöintiä ja ”kertaluonteisia haaroja”:

• Pitämällä ydintietomallin ja moduulit yhteisinä
• Toteuttamalla asiakaskohtaisen logiikan konfiguraatioilla, laajennuksilla ja eristetyillä räätälöidyillä moduuleilla
• Dokumentoimalla mallit, joita voidaan käyttää uudelleen

Asiakkaalle tämä tarkoittaa, että ratkaisu on räätälöity omaan prosessiin, mutta siitä ei tule täysin eristettyä koodikantaa, jota on vaikea ylläpitää.

Toimitus- ja tukimallimme on suunniteltu skaalautumaan: ympäristöt, CI/CD, valvonta, tikettien käsittely ja julkaisutyönkulut on standardoitu kaikille asiakkaille. Näin voimme tukea useita ratkaisuja rinnakkain luomatta ”kertaluonteisia” operatiivisia järjestelyjä. Kun kuormitus kasvaa, voimme lisätä kapasiteettia kumppaniverkostomme kautta olemassa olevien kumppanijärjestelyjen avulla.

Erotamme toisistaan:

• Asiakaskohtaisen toiminnallisuuden (toteutetaan asiakkaan omaan repositorioon ja kehitysjonoon)
• Uudelleenkäytettävät komponentit (viedään jaettuihin moduuleihin vasta, kun malli on todettu toimivaksi ja laajasti sovellettavaksi)

Näin jokainen asiakasratkaisu pysyy räätälöitynä siellä, missä sitä tarvitaan, eikä alustasta tule pirstaleista ”lumihiutalealustaa”.

Keskeiset opit (ja miten ne on nyt rakennettu sisään alustaan ja prosessiin):

• Tietomallien varhainen epäselvyys aiheuttaa kitkaa myöhemmin – edellytämme nyt tiukempaa määrittelyvaihetta, jossa käytetään konkreettista esimerkkidataa ja ”ohuen siivun” prototyyppejä jo varhain.
• Integraatiot pettävät reunoilla (master datan omistajuus, tilat, idempotenssi) – standardoimme integraatiomallit: master datan säännöt, auditointilokit, uudelleenyritykset, täsmäytysnäkymät ja erilliset virhejonot.
• Operatiivinen erinomaisuus ei ole valinnaista – investoimme vahvasti valvontaan, CI/CD-kuriin sekä hallittuun julkaisuun ja edellisen version palautukseen, jotta tuotannossa ei tarvita ”sankarisuorituksia”.

• Aloita varhain asiakkaan todellisella datalla (pienilläkin otoksilla) ja lukitse ”omistajuussäännöt” (mikä tieto hallitaan asiakkaan ERP-järjestelmässä ja mikä sovelluksessa) ennen kuin ratkaisua laajennetaan.
• Määrittele hyväksymiskriteerit ja suorituskykyodotukset nimenomaisesti heti alusta alkaen (läpimenoajat, tiedostokoot, samanaikaisuus, raportointitarpeet).
• Laadi migraatio- ja tuotantoon siirtymisen suunnitelma täysipainoisena tuotoksena, älä loppuvaiheen tehtävänä.

Koska se pienentää räätälöityjen ohjelmistojen suurimpia pitkän aikavälin riskejä:

Pienempi toimitusriski ja nopeammin saavutettava hyöty

Ratkaisu rakennetaan toistuvasti toimiviksi todettujen, hiottujen ja ”tositoimissa testattujen” ohjelmistomoduulien varaan (tilaukset, tehtävät, tarkastukset, mobiilikäyttöliittymän mallit, integraatiot, raportointi). Näin ensimmäisiä kuukausia ei kulu tyypillisten ”tyhjästä rakennettujen” peruspalvelujen virheiden selvittämiseen, vaan projekti voi keskittyä alusta alkaen asiakkaan todellisiin työnkulkuihin, dataan ja operatiivisiin prioriteetteihin.

Kapasiteetti ja skaalautuvuus ensimmäisestä päivästä alkaen (ilman uudelleensuunnittelua)

Alkuvaiheen kapasiteetti ja kasvuvara mitoitetaan sovittujen käyttöoletusten perusteella ja validoidaan kuormitustestauksella. Tavanomaiset pilvinatiivit mallit tukevat myöhempää skaalaamista, ja infrastruktuurin laajuuden tai maksujen mahdollisiin muutoksiin sovelletaan sovittuja kaupallisia ehtoja.

Validoimme tämän kuormitustestauksella käyttöönottovaiheessa ja skaalaamme AWS-resurssit sen mukaisesti.

Operatiivinen kypsyys on jo sisäänrakennettuna

Valvonta, lokitus, CI/CD, hallitut julkaisut ja edellisen version palautukset sekä tukityökalut on jo integroitu, ja ne on todettu toimiviksi nykyisissä asiakasympäristöissä. Nämä mekanismit ovat käyneet läpi todellisen tuotantokäytön koettelun ja useita parannuskierroksia (mukaan lukien tietoturva-auditointikierrokset), kun taas tyhjästä aloitettavassa räätälöidyssä toteutuksessa näiden kyvykkyyksien on tyypillisesti kypsyttävä vuosien todellisen käytön myötä.

Kokonaisvaikutus

Asiakas saa järjestelmän, joka voidaan ottaa tuotantoon nopeammin, joka toimii luotettavasti ja joka kehittyy ennustettavasti liiketoiminnan kasvaessa – ilman piilevien operatiivisten kustannusten tyypillistä pitkää häntää, joka ilmenee monissa perinteisissä kertaluonteisissa toteutuksissa.

Kaupallinen yhdensuuntaisuus ja toimituksen kannustimet

Liiketoimintamallimme on nimenomaisesti sidottu onnistuneeseen käyttöönottoon ja asiakkaan pitkän aikavälin hyötyyn. Luotamme alustamme laatuun ja kykyymme saada yhdessä asiakkaan kanssa aikaan mitattavaa operatiivista tehokkuutta; siksi voimme tarjota:

• Tilauspohjaisen kehitysmallin
• Osamaksut kiinteän laajuuden moduuleille
• Jatkuvan ominaisuuskehityksen lisenssin puitteissa (esim. määritelty määrä pieniä parannuksia kuukaudessa aktiivisen kehitysvaiheen jälkeen)

Monet toimittajat eivät pysty uskottavasti tarjoamaan tätä rakennetta, koska niiden toimitusmalli perustuu tyypillisesti kiinteään laajuuteen tai tuntilaskutukseen, jolloin ensisijainen kannustin on itse projektin toimittaminen – ei sen varmistaminen, että ratkaisu paranee edelleen ja tuottaa liiketoiminta-arvoa tuotantokäyttöönoton jälkeen.

Asiakas tekee päätöksen tuotantokäyttöönotosta. Ennen julkaisua sovitaan ydinlaajuus, toimitettavat tuotokset, hyväksymiskriteerit, operatiiviset vaatimukset ja välitavoitteet, jotta molemmat tiimit tietävät, minkä on oltava valmiina.

Maksuaikataulusta sovitaan erikseen ja etukäteen.