Nyt olisi kyllä enemmän kuin poikaa saada muutama käyttäjäkokemus Efecten tuotteista ja palveluista sellaisilta kavereilta, joilla on laajaa kokemusta Efecten ja mielellään myös kilpailijoiden tuotteiden käytöstä. Onko kenelläkään omaa kokemusta tai lähipiirissä sellaisia tuttuja, joita voisi haastatella.
Toki verkosta löytyy aina joitakin käyttäjäkokemuksia ja -arvioita, mutta niiden todenperäisyyden arviointi on aina vähän niin ja näin.
Nopea kommentti tiedotteeseen 
Vaikea sanoa, kun pitäisi saada käytännön asiakaskokemuksia koko Efecten ITSM-kokonaisuudesta. Siihen asti on luotettava erilaisiin raportteihin.
Efecten Wikin historian perusteella, SaaS on lähtenyt kunnolla vasta viime vuosina.
Pienen talon on vaikea tehdä OnPremise tuotetta, koska asiakaat usein vaativat sen toimivan erilaisissa ympäristöissä. Usein toimittajan aikaa menee käyttöönoton tukee, eri konfiquraatioihin jne.
SaaS:ssa ei tarvitse tehdä kuin yhtä softaa. Pienikin talo voi pärjätä SaaS:ssa ja toki keskeistä on hyvä järjestelmän arkkitehtuuri ja kehitysprosessi. Itse uskon Efecteen ja jos usko loppuu, myyn osakkeet.
Edelliseen viestiisi: Deadlock:n vaikuttaa isolation level, lukituksen laajuus sekä muistaakseni mahdollinen indeksin puuttuminen (jos SQL joutuu kahlaamaan koko taulun läpi). Ainakin default Isoationlevelin jota käytetään, jos ei muuta koodissa anneta, voi asettaa kovin monella tapaa riippuen sovelluspalvelimesta. Asiakaskohtaisissa asennuksissa kaikki mahdolliset asetukset ovat ongelmapaikkoja.
Toki hyvin tehty koodi estää Deadlockit ja mainitsemasi deadlock exception olisi pitänyt käsitellä koodissa ja yrittää uudelleen.
Kuitenkin SaaS helpottaa kovasti pienen firman, kuten Efecten laadun varmistamista
Haluaisin kyllä opponoida tässä ja väittää että tämä ei pidä paikkaansa. SaaS on bisnesmalli, ei teknologinen toimintatapa. Se ei siis tarkoita etteikö palveluita räätälöitäisi asiakkaiden tarpeisiin. Erityisesti kun myyntitiimi lähtee vähänkään isommalle firmalle myymään niin neuvotellaan integrointiprosessi johon yleensä sisältyy räätälöintiä. Toki se ei sitten skaalaa samalla tavalla kun nämä Admicomit, mitkä myy samaa tuotetta kaikille pienyhtiöille eikä räätälöintiä tehdä edes maksusta.
Pilvipohjainen, ei kylläkään esim ACB-SaaS taitaa olla se juttu mitä haettiin (sori mutta onhan nyt perjantai-ilta). Pilvi on siis se ketteryyden ja skaalan taikasana joka ei tosiaan taida olla ihan itsestäänselvyys SaaS- mallissa
Olen eri mieltä, mutta toki olisi tylsää jos kaikki olisivat samaa mieltä.
Paikallisasennuksia tehtiin aikanaan siten, että työntekijöiden läppäreille tuli clientit varsinaisen palvelinsoftan lisäksi.
Sitten alkoi tulla sovelluspalvelimia asiakkaiden omiin konesaleihin ja työntekijät käyttivät sovellusta selaimella.
Ongelmat olivat ainakin nämä (On-premises tuoteasennuksen kanssa)
- asiakkailla oli eri vaatimuksia mm. käyttöjärjestelmälle (Linux, Windows) ja osin vaikka vaadittiin esim. IBM:n tai MS:n tekniikkaa. Nämä kaikki oli huomioitava sovelluksessa
- palvelimet olivat sisäverkossa ja usein etäkäytössä oli VPN ym. ratkaisut
- saatavuus hoidettiin aikaisemmin palvelimien klustereilla, nykyään tehokkaammilla kontainer-ratkaisuilla. Kantaklusteria ei käytännössä saanut yliheittämään tuotannon katkeamatta
- palvelimien resurssit joutuu mitoittamaan siten, että toinen palvelin kykenee pyörittämään yliheitossa järjestelmän. Lisenssi- ja palvelinkuluja menee turhaan
- palvelimet ja sovellus vaativat oman IT-operoinnin (jotka muuten käyttävät ITSM-järjestelmää)
- jne.
(ennen SaaS:a osa siirsi saman sovelluspalvelin pilveen virtuaalipalvelimelle, IaaS)
SaaS, asiakas näkee vain selainsovelluksen ja rajapinnat (integraatiot, mobiiliApp…)
- SaaS-firman voi perustaa pienemmällä pääomalla.
- pilveen (AWS, Google, Azure…) voi aloittaa TK-firma halvalla tekemään SaaS-sovellusta. Maksat vain käytöstä
- SaaS-arkkitehtuuri käyttää rautaa tehokkaammin kuin paikallisasennus ja on siksi aina halvempaa (edit:pilvi käyttää paikallisasennusta tehokkaammin rautaa, mutta vain yksi sovellusversio kaikille asiakkaille vielä tätä tehokkaammin)
- sovellus on helppo antaa asiakkaan testattavaksi tekemällä vain tunnarit
- SaaS-sovelluksen rajapinnat näkyvät nettiin, joten etäkäyttö ja mobiiliApit on helppo tehdä. API- ja UI-autentikointi tietoturvastandardien mukaisesti
- SaaS-toimittaja voi hoitaa järjestelmän operoinnin yhdellä laadukkaalla prosessilla
- softan päivitykset nopeasti hoidettavissa kaikille asiakkaille
- softassa ei tarvitse huomioida erilaisia IT-infran vaatimuksia
- saatavuus hoituu pilven arkkitehtuurilla (serverless, Auto Scaling…)
- periaatteessa yksi versio sovelluksesta, jossa parametreilla SaaS-toimittaja aktivoi eri toiminnallisuudet. (Toki varsinaisesti SaaS ei ota kantaa siihen, onko käytössä vain yksi versio)
- korkea tietoturva jne.
SaaS-haasteita
- hyvä skaalautuva arkkitehtuuri eli voidaan rakentaa toiminnallisuutta lisää kokonaisuuden pysyessä selkeänä. Käyttöoikeuksien hallinta kuuluu tähän
- integraatiot jotka ovat toki haaste myös paikallisasennuksessa
- mahdolliset asiakkaiden vaatimuksen oman datan eristämiselle
Edit: Nykyisellä mikropalveluarkkitehtuurilla, perinteisen klusteroinnin korvaamisen kontainereilla ja pilven hyväksikäytöllä voisi yllä mainitun On-premises tuoteen tehdä paljon paremmaksi kuin vuosia sitten. Joten yllä oleva teksti on hieman epätäydellinen ja vaatisi pidemmän sepustuksen
Voit perustaa SaaS firman pienellä pääomalla, mutta et lähes ikinä pysty myymään isoille yrityksille samaa tusinaSaaSsia mitä pienemmille ja keskisuurille. Ohessa legendaarinen kuva, joka hyvin demonstroi myyntitiimin tarvetta:
Olen monta kertaa ostajan puolella joutunut kuuntelemaan kun se pikkufirma yrittää myydä tuotettaan ilman kunnon ymmärrystä miten myydään ja se keskustelu menee about näin:
“Toimiiko se meidän kriittisen järjestelmän kanssa ja paljonko maksaa integrointi? Voiko sillä tehdä meidän tarvitsemat asiat x, y ja z ja jos ei paljonko maksaa lisätä ne? Ai ei onnistu kun ette ole sellainen SaaS-firma, no sitten me ei osteta. Kiitos ja näkemiin.”
Jos katsoo vaikka miten Vincit myy omia SaaS-palveluitaan, niin niissä on todella huono skaalauvuus ja hidas myyntisykli, koska niitä myydään isoille asiakkaille ja vaaditaan juuri noita integraatiopalveluita ja jonkinasteista räätälöintiä. Se toimintatapa eroaa täysin superskaalaavasta kaikille samaa tuotetta myyvästä autotalliSaaSista. Ohessa pätkä Inderesin raportista, joka kuvaa miten tämä toimii:
Jos emme löydä tästä yhteistä näkemystä niin se ei tietenkään haittaa. Mukavaa vaan että maailmaan mahtuu erilaisia näkemyksiä. Koen kuitenkin tuon ylemmän kuvan pätevän Efecteenkin. Isoilla asiakkailla on isosti neuvotteluvoimaa ja jos halutaan isoimpia asiakkaita niin se vaatii myyntitiimin ja asiakkaan tarpeiden täyttämistä ja sellaisten kriittisten ominaisuuksien lisäämistä, mitkä tuotteesta puuttuvat, mutta mitä asiakas tarvitsee. Tuote ei silloin enää myy itse itseään ja geneerinen ratkaisu ei yleensä enää riitä.
Tämä saattaa rikkoa yhteensopivuuden main brachin kanssa ja hidastaa päivityssykliä ja jopa vaatia päivitysprojektin aina kun ohjelmistoa muutetaan, mutta se ei ole asiakkaan ongelma. Se on palveluntarjoajan vastuulla silloin pyörittää useampaa versiota omasta ohjelmistostaan samaan aikaan siellä pilvessä ja pitää huolta että kriittiset tietoturvapäivitykset tulevat kaikkiin versioihin.
Edit: alkaa mennä off-topic ?
Iso SaaS voisi olla vaikka CRM SalesForce. Olin itse yhdestä vastaamassa isolla asiakkaalla.
Salesforce on SaaS, joka koostuu useista moduleista. SaaS-ratkaisua voi räätälöidä custom-koodilla, joka käyttää Salesforcen API:n.
CRM:n (asiakkaiden) tietomallia voi räätälöidä Salesforcen tietomallin päälle sovittujen sääntöjen mukaisesti.
Rajattomasti voi tehdä räätälöintejä käyttämällä Salesforcen API:ja
Tuossa linkissä on se vasemman puoleinen 3 min video kuvaa kokonaisuutta Salesforce vasen 3 min video
Nykyisessä ns. API-arkkitehtuurissa yritysten järjestelmät keskustelevat API:n kautta toisten järjestelmien (SaaS, Onprem, räätälöidyt…) kanssa.
Kun aikanaan yritysarkkitehtuuri kuvattiin “konesaliarkkitehtuurina” tulevaisuudessa järjestelmät ovat eri pilvissä ja Onprem-saleissa
Ei ole liian offtopic, jatkakaa niin meikä noob oppii tässä samalla. tää on niinku yöluento.
Joo, kyllä minä ymmärrän että mikropalveluarkkitehtuurilla ja hyvin tehdyllä API-arkkitehtuurilla hommat saadaan kyllä toimimaan fiksusti ja kohtuullisen skaalaavasti. Mitäs sitten kun asiakkaalla on 10 tehtäväkriittistä legacy-monoliittia, joissa on huonosti dokumentoidut rajapinnat ja joiden päälle on vuosien saatossa rakennettu erinäköisiä purkkaviritelmiä korjaamaan satunnaisia ongelmia käyttöliittymässä ja ominaisuuksien puutteissa? Homma ei olekaan enää niin helppoa. Isoihin asiakkaisiin vaaditaan paljon vaivaa ja huolenpitoa ja räätälöintiä, mutta siksi ne maksavatkin isot eurot.
Rakennusarkkitehtien kuvissakin on aina kesä ja vihreätä, mutta sitten kun raksamiehet alkavat toteuttamaan piirustuksia niin tulee ärräpäitä ja asiakkaat saattavat huomata että kesäratkaisu ei välttämättä toimi hyvin talvella kun tulee lunta ja loskaa ja on pimeätä 
Arkkitehtuuri ei ole itsetarkoitus vaan sen on tuettava yrityksen liiketoimintaa. Pilviarkkitehtuuria ei saisi tehdä siirtämällä järjestelmiä tai koodaamalla niitä pilveen.
Toisaalta uuden arkkitehtuurin rakentaminen vie vuosia ja jatkuu sen jälkeenkin jatkuvana liiketoiminnan muutoksia tukevana kehityksenä, joten on edettävä askeleittain mutta tavoite on oltava selvä
On ymmärrettävä millaisia järjestelmiä yrityksen tulevaisuuden strategia ja visio tarvitsevat.
Ensin on kirkastettava tulevaisuuden liiketoiminnallinen tahtotila ja suunniteltava sen mukaisen IT-arkkitehtuurin tavoitetila. Sen jälkeen priorisoitava eteneminen ja tehtävä roadmap
Tulisi pohtia asioita kuten: miten yritys voi palvella asiakkaita tulevaisuudessa paremmin, mitä tämä vaatii yrityksen sisäisiltä prosesseilta jne.
Jos lähdetään vain pohtimaan teknisiä asioita kunten siirretäänkö järjestelmä pilveen vai ei, ei kokonaisarkkitehtuuri tue yrityksen liiketoimintaa
Tavoitetilaa ja arkkitehtuuria tarkennetaan säännöllisesti ja tämä tulisi olla jatkuva tapa.
Lopulta se siirretäänkö järjestelmä pilveen, koodataanko uusi tai käytetäänkö SaaS-palveluja ei ole mitenkään keskeistä
Tekniset ratkaisut ovat vain liiketoiminnan ja kokonaisarkkitehtuurin tavoitetilan mukaisia loogisia päätöksiä.
Olen samaa mieltä, jos hommat tehdään hyvin niin kaikki onnistuu. Entäs kun asiakkaalla ei ole kovinkaan paljon IT-osaamista ja IT-järjestelmät nähdään vain kulueränä, joihin halutaan investoida absoluuttinen minimi? Anteeksi jos näkökulmani kuulostaa kyyniseltä, mutta olen nähnyt liian monta sössittyä IT-projektia elämäni aikana että jaksaisin enää uskoa ihmiskuntaan 
Reaktorin ja Futuricen listautumista odotellessa…
Ettei nyt mene mega off-topic niin uskaltaisiko kysyä @niilo_fredrikson kommentteja? Miten te pärjäätte isoimpien asiakkaiden kanssa ja tuleeko heidän kanssaan paljonkin räätälöintiä yms. skaalausta haittaavaa säätöä?
Hyvää keskustelua ja varmasti vaikea sanoa yleispätevästi miten legacy yrityssovelluspuoli tulee modernisoitumaan… Tässä pari karkeasti jaoteltua polkua joiden välillä firmat voivat valita;
A) Purkkaviritykset ja ruma puukotus.
- hyvin pitkälle tähän asti suosittu malli
- tekohengitetään nykyisiä legacy sovelluksia
- lisätään pistemäisiä moderneja ratkaisuja, pilveä ja SaaS:ia, yritetään integroida, reverse enhoneerata ja puukottaa niin että saadaan järjestelmät toimimaan yhteen (esim Salesforce on usein raiskattu käyttökelvottomaksi)
- Headless sovellukset, API-mania, ”Platform of Platforms” (konsolidoidaan useita alustoja yhden alustan alle, yritetään rakentaa yhteinen käyttöliittymä useille legacy-järjestelmille kokoamalla siroteltua dataa apien kautta)
- ominaisuudet pääsääntöisesti paljon huonommat kuin parhaimmillaan voisi olla
B) Greenfield
- hyväksytään ettei legacy turdistä saa kiillotettua timanttia ja dumpataan vanha, otetaan suoraan pilvestä uusi (yksinkertaistaen)
- data migroidaan tai sitten ei
- kallista ja pelottavaa mutta odotusarvo vaihtoehto A:han verrattuna parempi
Isoissa firmoissa tilanne on luultavasti gridlockissa koska ison it-rempan hyötyjä on vaikea perustella liiketoiminnalle. Pankkitoimiala on lähtenyt tosi isoihin core-järjestelmien uudistuksiin pakon edessä tosin.
Legacyn uudistaminen, varsinkin B-vaihtoehdolla on kallista koska kulut tulevat kerralla. A-vaihtoehdolla voidaan lirutella vuositolkulla pistemäisiä quick fixejä liiketoiminnan tarpeisiin tehden. Harva CIO on kuitenkaan tarpeeksi rohkea (hullu?) lähteäkseen greenfield big bang uudistamiseen, ja/tai harva liiketoimintajohtaja on tarpeeksi visionäärinen ymmärtämään uudistamisen hyötyjä. Lisäksi johdon insentiivit on yleensä sidottu Q tai FY tasolle, jolloin strateginen (pitkäjänteinen) kehittäminen lentää ikkunasta ulos. Tämän takia monilla isoilla vanhoilla firmoilla on niin kovia vaikeuksia uudistua digitalisoituvassa maailmassa.
Tilannetta voisi verrata Windowsin ja Symbianin tilanteeseen, jossa koodia ei vaan uskallettu/jaksettu/älytty kirjoittaa uusiksi from the ground up. Tuloksena monimutkainen, hidas, buginen ja repaleinen sillisalaattikoodi joka kaatuili, kehittäminen vaikeaa ja UX aivan kamala.
Toisaalta mielestäni iOS ja muu Apple softa on suuntaamassa samaan suuntaan!
Nyt monet näistä ohjelmistokonsulttifirmoista tekee paljon tätä ”puukotusta”. Tehdään purkkavirityksiä asiakkaan arkkitehtuuriin jotta saadaan esim data kulkemaan paremmin ja reaaliaikaisemmin. Esimerkkinä reverse engineerataan muiden toimittajien järjestelmiä ja viritellään data-streameja… Kiva juttu(?) näille it-konsulteille koska laskutettavaa työtä riittää loputtomiin tuossa suossa.
Huono juttu asiakkaille koska purkka ei pitkässä juoksussa ratkaise oikein mitään kunnolla, eikä näiden ”ratkaisujen” tukeminen oikein kiinnosta näiden ohjelmistotalojen rokkistaradevaajia. Joten kovin kallista ’sovellusylläpitoa’ luvassa repaileiseen arkkitehtuuriin asiakkaan näkökulmasta.
Ihailen itse Efecteä siitä, että tällaisia firmoja meillä pitäisi olla enemmän. Graalin malja ICT-puolen firmoissahan on ultraskaalautuva omaan IP:hen perustuva erittäin kannattava ja bisneskriittinen SaaS jossa syvä moat, korkeat vaihtamiskustannukset ja korkea barrier to entry.
Omistajien, sijoittajien ja kansantalouden kannalta tällainen SaaS bisnes potentiaali on tuhansia kertoja suurempi kuin perus it-palveluiden pyörittäminen tai devaajien myyminen kotimaisille asiakkaille. Viimeksi mainittuhan on periaatteessa toistemme paitojen pesemistä rumasti sanottuna, eikä se skaalaudu koska ne laskuttavat devaajat tuppaa loppumaan jossain vaiheessa jolloin liikevaihdon kasvukin loppuu. Sitten se projekteista kisaaminen kotimaassa on nollasummapeliä siitä eteenpäin.
SaaS talolla taas ei ole tällaisia rajoitteita, virtuaali-instanssit ei pilvestä lopu kesken, jakelu globaalia ja jos menestystä tulee niin käsiä ja jalkoja (kumppaneita) alkaa olemaan ovella jonoksi asti eri maissa.
Sijoittajan kannalta ehdottomasti kiinnostavampaa olla menestyksekkäässä SaaS tarinassa mukana, kuin menestyvässä it-konsultointitarinassa. Noissa konsulttifirmoissa voi tehdä OK rahat jos pääsee tarpeeksi ajoissa mukaan (pre-IPO mielellään). SaaS voi räjähtää käsiin myös post-IPO, mutta toisaalta globaali kilpailu on myös kovaa. It-konsulttitalot kilpailee lähinnä paikallisesti nyt kun offshorekin meni pois muodista. Tosin isot legacy palvelutalot alkaa varmasti puskemaan isommin myös konsultointiin ja nearshore (Viro, Puola, Baltian maat, jopa Venäjä) polkee hintoja.
Tämä meni nyt vähän ajatusten virraksi. Olisi tosiaan kiinnostavaa kuulla Efecten ajatuksia ylläkäydyistä pointeista keskustelussa.
Edit: tulipa monta kirjoitusvirhettä luurilla, korjailin niitä
Virtuaalivalkusta juttua
Tervehdys @Pohjolan_Eka ja kiitos kysymyksestä! Suora vastaus on että kyllä me hyvin pärjätään isoimpienkin asiakkaiden kanssa 
Emme koodaa erillistä versiota tuotteesta edes isoimmille asiakkaille, vaan kaikilla asiakkailla on käytössään sama tuote (sama ohjelmisto). Tuotteen päällä oleva konfiguraatio vaihtelee luonnollisesti asiakkaittain, ja isoimmille asiakkaille konfiguroidut prosessit, työnkulut ja integraatiot voivat muodostaa isoja kokonaisuuksia. Tässä on juuri Efecten alustan voima: ilman ohjelmointia voidaan vastata monipuolisiin asiakastarpeisiin.
Teknisesti tärkeä asia on että Efecten ohjelmisto ja konfiguraatiokerros on eristetty toisistaan. Sen ansiosta pystymme säännöllisesti päivittämään uusimman Efecte-version asiakkaiden käyttöön, vaikka heidän Efecte-konfiguraatiot ja käyttötarkoitukset vaihtelevat paljonkin.
Hei Niilo!
Tämähän on oikein mukavaa kuulla ja hyödyllistä tietoja sijoittajille. Kiitos vastauksesta!
Efecte julkaisi videon uusista ominaisuuksista. Kiinnostava on tuo AI pohjainen Virtual Coach.
Siinä kun käyttäjä kirjaa jonkin vikatilanteen, ehdottaa Virtual Coach vastaavan kaltaisia vikatilanteita Efecten vanhojen vikatietojen perusteella. Efecte AI Virtual Coach
Tuo Efecten AI-ominaisuus tuntuu hyödylliseltä mutta hieman yksinkertaiselta enkä hahmota, tarvitaanko tuohon edes neuroverkkoa.
Itse olen käyttänyt neuroverkkoa myös sijoittamisessa.
Neuroverkkoa voisi yleisesti käyttää paljon enemmän kuin nykyään.
Efecten tapauksessa, jos Efecte integroituisi ison yrityksen keskitettyyn lokijärjestelmään (johon voi lokittaa erilaisia tapahtumia vaikka palvelimien ongelmista, verkkopalvelujen ja rajapintojen hitauksista jne.) voisi Efecte ennakoida reaaliaikaisesti tulevia incidenttejä.
Hyvin paljon muitakin skenaarioita neuroverkkojen hyväksikäytölle on.
Neuroverkkoa opetetaan millä tahansa datalla, esim. eri alijärjestelmien statustietoja (rajapintojen vasteaika, vikakoodit…) sillä hetkellä, kun incident(vika) ilmaantuu. Kun tätä opetusdataa syöttää paljon, neuroverkko osaa jatkossa tunnistaa vastaavia tilanteita
Yleisesi sijoittamisen tuote- vs funda-asioihin. Itsellä ensimmäinen kriteeri osakkeen valinnalle on se, kuvittelenko yrityksen tuotteella olevan kaupalliset mahdollisuudet, millainen oletettu markkinoiden koko ja siten kasvumahdollisuuden.
Vasta jos nämä ovat ok, tutkin muita fundamentteja tarkemmin. Toistaiseksi tarjonnut mahdollisuuden leivän tienaamiseen
@niilo_fredrikson onko tuo AI-ominaisuus täysin talon sisällä kehitetty ratkaisu, vai onko ostettu joltain alihankkijalta?