B2B SaaS: ezeket érdemes mérlegelni szoftverfejlesztés előtt

A SaaS (Software-as-a-Service) mindenkinek jelent valamit, de a tapasztalat azt mutatja, hogy mindenkinek egy kicsit mást. Ennek oka az, hogy a “SaaS” jelentése a gyakorlatban nem fix, sokkal inkább egy skálán mozog. Minden üzleti döntés előtt célszerű átgondolni, hogy egy adott, SaaS-ként emlegetett megoldás a skála mely pontján is van, és ez milyen előnyöket, hátrányokat vagy kockázatokat hoz magával rövid- és hosszútávon.

Ha megkérdezzük a Google-t vagy a Chat GPT-t, hogy milyen előnyei vannak a SaaS modellnek az egyedi szoftverfejlesztéshez képest az ügyfél, illetve megrendelő szempontjából, akkor nagyjából ezeket a válaszokat fogjuk kapni: alacsonyabb kezdeti költségek, kiszámítható működési költségek, könnyű skálázhatóság, gyors frissítések, rugalmas hozzáférhetőség, platformfüggetlenség, kisebb karbantartási teher. 

Ezek a jellemzők egy ideális állapotot írnak le, amelyek a SaaS vegytiszta formájára nézve – többnyire – igazak. Az üzleti szükségletek és adottságok viszont bőven produkálhatnak olyan helyzeteket, amikor ilyen vegytiszta SaaS valamilyen okból kifolyólag nem elérhető, vagy nem megfelelő megoldás. Cikkünkben szó lesz arról, hogy milyen SaaS-alapú megoldások vannak még, illetve mik a SaaS-skála kezdő-, közép-, és végpontjának legfontosabb jellemzői.

Mit érdemes mérlegelni a SaaS bevezetése előtt? 3 különböző megoldás elemzése

A következőkben részletesen megvizsgáljuk a B2B SaaS kapcsán felmerülő legfontosabb értékelési szempontokat. A cél, hogy legyen egy jól használható útmutató, amely alapján a döntéshozó szoftverfejlesztés előtt mérlegelheti a rövid- és hosszútávú költségeket, hasznokat és kockázatokat.

Alapvetően a SaaS-skála három meghatározó pontját mutatjuk be különböző szempontok alapján:

1. A “tradicionális termék és professzionális szolgáltatások” (PS) modellje
2. SaaS szemlélet “feature flagekkel”
3. Standard, önkiszolgáló, vegytiszta SaaS szoftver

Az elemzési szempontok közé tartozik a bevezetés, a funkciócsomag kialakítása, a hoszting megoldások, az árazási modellek, valamint a termék által megtermelt érték, illetve az adott modellel járó legfőbb kockázatok és előnyök.

1. Ma már szinte boomer: a “tradicionális termék + professzionális szolgáltatások” modellje

Ez az együttállás a SaaS-skála egyik végpontja, mondhatni a “legkevésbé”, vagy “éppen hogy SaaS” modell. Amennyiben a bevezetés kevés egyedi fejlesztéssel valósul meg, akkor a már előre lefejlesztett termék adja a felhasználás alapját – ilyenkor tehát a SaaS jelleg már fellelhető. Ennél a modellnél a termék alapvető funkcionalitása tehát fix, de a bevezetés során – több-kevesebb – egyedi szoftverfejlesztéssel bővítik és módosítják azt. 

Ez a megközelítés előnyös lehet azoknak a megrendelőknek, akiknek speciális igényeik vannak, de hátrányos a hosszútávú kompatibilitás és karbantarthatóság szempontjából. Jellemzően ide tartoznak az ERP-k vagy a core-banki rendszerek.
Hogy mennyire széles skálán mozoghat akár még ma is, hogy mit nevezünk SaaS-nak, arra jó példa, hogy 2010 környékén az egyik telekommunikációs vállalat webshopját is SaaS-ként emlegették. Bár a használat havi díjas alapon működött, a terméket nem a vállalat üzemeltette és nem birtokolta a licencet sem, a termék egyedi fejlesztések révén gyakorlatilag teljes egészében a vállalatra lett szabva.

Egyedi fejlesztések kockázata

A SaaS skálának ezen az oldalán a legnagyobb kockázat az egyedi fejlesztésekben rejlik. A megrendelő cég szükségleteire szabott funkciók, egyedi fejlesztések ugyanis gyakran nem lesznek kompatibilisek a későbbi verziókkal. A kompatibilitás elérése előbb-utóbb további fejlesztési és karbantartási költségként jelenik meg az ügyfél kiadásai között, ezeket a munkálatokat pedig kizárólag – de legalábbis messze a legkönnyebben – az a vendor tudja majd elvégezni, amelyik az eredeti terméket szolgáltatta, és az ahhoz tartozó fejlesztéseket bonyolította. 

Ez a megoldás tehát egyrészt rugalmasságot biztosít az ügyfelek számára a termék minél cégre szabottabb kialakításában, azonban hosszútávon akár jelentős karbantartási problémákat, akadozó frissítéseket, csapdahelyzetet, a vendortól és a vendor árazásától való kiszolgáltatottságot eredményezhet. 

A bevezetés folyamata

A vendor-megrendelő kapcsolat a “tradicionális termék + professzionális szolgáltatás” modellben a bevezetés és a funkciócsomag véglegesítése alatt közvetlen és folyamatos. Ez a megrendelő és a vendor oldaláról is erőforrásigényes és hosszú folyamat. Az is gyakori megoldás ezekben az esetekben, hogy a szoftver gyártója (a vendor) egy professzionális szolgáltatási (PS) partnerrel dolgozik együtt, aki jól ismeri a terméket, így képes elvégezni a bevezetést, illetve az ügyfél számára kívánatos egyedi fejlesztéseket.

A vendor, vagy a vendor PS partnere tehát mélyrehatóan megismeri és megérti az ügyfél üzleti folyamatait és technikai követelményeit. Az erre a megértésre épülő egyedi fejlesztések a lehető leghatékonyabb és legkényelmesebb szolgálatot nyújthatják a megrendelő cég számára. Azonban minél komplexebb egyedi fejlesztést igényel a funkciócsomag véglegesítése, minél cégre szabottabb adott pillanatban a végeredmény, annál inkább kitett a megrendelő cég a fent tárgyalt, hosszabb távú kockázatoknak. Miért?

Minden új funkció erősen épít néhány termékfunkcióra, valamint illeszkedik egy globális funkcióhalmazba. Ez azt jelenti, hogy ha az érintett funkciók változnak egy újabb verzióban, az azonnali törést okozhat az egyedire fejlesztett rendszer működésében. Ennél is nagyobb fejtörést okozhat, amikor maga a globális funkciócsomag változik meg. Ilyenkor még nehezebb észrevenni, hogy valamilyen adottság módosult, amelyre egy testreszabás vagy fejlesztés – gyakran implicit és nem dokumentált módon – építkezett.

“Custom-tailored”, azaz “cégre szabott” megoldás

Az angolszász szolgáltatás szektorban kezdték el először használni a “custom tailored” címkét, ami az egyedi, cégre szabott állapotnak felel meg. 

Találó analógia, mivel ezekben az esetekben az elkészült és bevezetett termék valóban hasonlatos egy méretre szabott ruhadarab életútjához: amíg a divat marad és a megrendelő is őrzi méreteit, addig tökéletesen áll; “előgyártott” konfekcióhoz nem hasonlítható. 

Ám ahogy a körülmények változnak, úgy az eredetileg sem olcsó megoldás egyre költségesebbé válik, nem beszélve arról, ha nem egy, hanem, mondjuk, 500 szabott öltönyt kell átalakíttatni. Ráadásul a túl sokszor átszabott, átvarrt ruhadarab esetében már az összhatás is sérülhet. Hasonlóan, egy a 90-es évek végén egyedileg lefejlesztett rendszer ma már egész biztosan nem tudja azt nyújtani sok-sok kiegészítő fejlesztés árán sem, mint amit egy mai szemmel és eszközkészlettel tervezett szoftver.

Az elmúlt évek hirtelen és drasztikusan változó körülményei sokkal inkább a rugalmas feltételeknek és a minél kisebb elköteleződésnek kedveznek – ahogy a méretre szabott ruhadarab helyett sokkal inkább a tömeggyártott konfekció, úgy a hatalmas, egyedi fejlesztési projektek helyett egyértelműen a SaaS irányába mozdul a világ. 

Új funkciók és verziófrissítések

A “termék + professzionális szolgáltatás” esetében egy-egy frissítés, új termékfunkció bevezetése a legnagyobb fejfájást okozhatja - a többi SaaS-modell megoldásaihoz képest. Mivel az egyedi fejlesztések jelentősek, ezért szinte borítékolható, hogy minden upgrade és újabb verzió jelentősebb fejlesztési kapacitást igényel majd - időbe telik és anyagilag is megterhelőbb, mint a későbbi SaaS modellek esetében.

Hoszting

A “tradicionális termék + professzionális szolgáltatás” modellben a szoftver telepítése rugalmas, azaz az ügyfél a saját üzleti és technikai igényei szerint választhat: saját, vagy a vendortól bérelt hoszting környezetet szeretne-e.

A saját hoszting előnye, hogy az ügyfél saját infrastruktúráján futtatja a megoldást, ami lehetőséget biztosít a teljes kontrollra és a specifikus biztonsági követelmények betartására. Az ügyfél bérelheti a hoszting szolgáltatást a vendortól is, ennek előnye, hogy csökkennek az IT infrastruktúra és karbantartás költségei.

Árazás 

Az árazás ebben a modellben gyakran projektről projektre változik, figyelembe véve az egyedi fejlesztési és bevezetési igényeket. Az alapvető termék licencdíja fix, de az egyedi fejlesztések és testreszabások további költségekkel járhatnak. Az alapvető terméklicenc-díjak mellett különböző támogatási és frissítési, karbantartási díjakkal a bevezetést követően is folyamatosan számolni kell – ezek árazása leginkább a projektek és az egyedi fejlesztések komplexitásától függ. 

Összességében elmondható, hogy az árazás a SaaS-skála ezen pontján kalkulálható a legkevésbé biztosra – és ahogy telik az idő a bevezetéstől, a nagyfokú cégreszabottság miatt a bizonytalansági faktor is folyamatosan nő.

Ami ma a legnagyobb érték a szoftverben, az holnap már kockázat?

Természetesen nem ennyire sarkos a helyzet, de alapjaiban véve mégis erről van szó. Az ügyfél a bevezetés során – a cégre szabott megoldásoknak hála – jelentős értéket kap, de a hosszútávú értékteremtés a rendszer folyamatos karbantartásán és fejlesztésén múlik, ami viszont előre nehezen kalkulálható, adott esetben jelentős költségekkel járhat. 

A “tradicionális termék + professzionális szolgáltatás” modellben az ügyfél erősen függővé válik a vendortól, vagy annak professzionális partnerétől az egyedi fejlesztések miatt. Ez nehézkessé teszi a szolgáltatóváltást és hosszú távú elkötelezettségi kényszert eredményezhet. Ez a típusú megoldás így leginkább azoknak az üzleti szereplőknek lehet ideális, akik valóban specifikus üzleti igényekkel rendelkeznek, és hosszú távon is hajlandók rendszeres, akár költséges fejlesztésekbe fektetni. A termék+PS modell sajátosságai miatt nem ritka, hogy nagyvállalati szférában találkozhatunk 10-20, de extrém esetben akár 30-40 éves rendszerekkel is.

Kevesen tudják vagy gondolnak bele, hogy a nyílt forráskódú (ún. open source) szoftverek sok esetben ugyanazt a modellt (termék+PS) testesítik meg, illetve ezzé válnak. Nem feltétlenül ezzel a céllal készülnek ugyanis, de mivel hozzá lehet nyúlni a forráskódhoz, ezt a fejlesztők gyakran meg is teszik. 

Itt a fent is említett kulcsprobléma egyben jelentős veszéllyel is jár. Amennyiben a nyílt forráskódú szoftverhez egyedileg belenyúlnak, elveszik a verziófrissítési képesség, így adott esetben kritikus biztonsági frissítésekkel sem frissül a kód. Mivel a forráskód ismert, ezek a szoftverek pedig igen elterjedtek, ezért a jól dokumentált biztonsági résekre ún. exploitok (a feltörést kulcsrakészen elvégző szoftverek) fejleszthetők. A nyílt forráskódú szoftvereket tehát ennek tudatában érdemes használni.

2. Lehet nagyon “bogaras”, de remekül is működhet: SaaS szemlélet “feature flagekkel”

Elérkeztünk a SaaS-skála – hozzávetőleges – közepére: a funkciókészlet alapvetően fix és dobozos, de bizonyos mértékű rugalmasságot biztosít az egyedi igények kielégítésére. Ez a modell átmenetet jelent a “tradicionális termék + professzionális szolgáltatás” modell és a teljesen önkiszolgáló SaaS megoldások között, és leginkább a néhány száz felhasználót számláló, többnyire valamilyen niche piacot célzó szegmensre jellemző.

A termék-szolgáltatás egyensúly itt akkor működik jól, ha a későbbi verziókkal való kompatibilitása és az egyszerű karbantarthatóság megmarad, miközben azért némi testreszabhatóság is rendelkezésre áll.

Ha túl sok a választás, az a fejünkre nőhet

Ez a megoldás gyakran ún. “feature flageket” használ az egyedi igények egyszerű kielégítésére. A "feature flag" egy olyan technikai megoldás, amely lehetővé teszi a fejlesztők számára, hogy egyes funkciókat ki- vagy bekapcsoljanak anélkül, hogy a kódot újra kellene telepíteni. Ezzel lehetővé válik, hogy különböző ügyfelek eltérő funkciókat használjanak ugyanazon szoftver verzión belül – mivel az egyes partnerek számára készített egyedi funkciók mások számára kikapcsolhatóak .

Jól hangzik, de nem árt résen lenni: a túl sok ki-bekapcsolási pont a megtervezett felhasználói útnak rengeteg módosulását eredményezi, ezek kombinációi pedig már egy akkora monstrumot képeznek, amelyet gyakorlatilag lehetetlen maradéktalanul kitesztelni.

Vigyázat, bug-veszély!

Képzeljük el, hogy a szoftver működését 32 helyen lehet beállítani kétállású kapcsolókkal – azaz 32 helyen dönthetünk egy “bekapcsolás” vagy “kikapcsolás” mellett. Ez azt jelenti, hogy 2^32-en darab együttállása lehet a szoftver működésének, ami kb. 4 milliárd lehetőség. Találkoztunk már olyan kisvállalati ERP szoftverrel is, amelyben 800 feature flag van, ami 2^800-on lehetőség. Ennyi lehetőség kitesztelése még automatizációval is teljes képtelenség. Viszonyításképpen, a teljes univerzumban a részecskék számát 2^85-en darabra szokták becsülni. 

A bevezetés folyamata

A terméket itt a vendor adja át, de a cél az, hogy fejlesztési tevékenység ne legyen szükséges a bevezetési folyamatban. Tipikusan a SaaS skála ezen pontjához tartoznak a vendor által nyújtott oktatási anyagok, onboarding szolgáltatások és a paraméterezési (“feature flag”) segítség is. A használatba vételhez szükséges onboardingot gyakran partnercég végzi.

Fontos megjegyezni, hogy ez a modell bevezetés után már egészen jól skálázható, azaz nagyobb rugalmassággal képes megfelelni az üzleti elvárásoknak. A vendor több helyre tudja bevezetni a szoftvert, az ügyfél pedig olyan szoftvert használ, amelyet sokan mások (kompatibilitás). Itt már fejlesztés nincs, az ügyfelek automatikusan megkapják az újabb verziókat.

Új funkciók és verziófrissítések

A SaaS-skála ezen pontján egy verziófrissítés, egy új funkció használatba vétele lehet akár teljesen problémamentes, de igényelhet plusz fejlesztési órákat is. A szoftver struktúrája, a frissítések jellege, a feature-flagek száma és állapota mind meghatározók lehetnek ebből a szempontból.

Hoszting

Ebben a modellben a megoldás minden esetben egyedileg van telepítve az ügyfél számára, és többnyire a vendor által biztosított hoszting környezetben fut. Ez teszi lehetővé a skálázhatóságot és az egyszerű karbantartást.

Az ügyfél szempontjából nézve a megoldás hasonlít a cloud alapú szolgáltatásokhoz, de nem biztosít azonnali hozzáférést, és nem érhető el teljesen önkiszolgáló módon (a telepítés és konfiguráció során a vendor támogatására van szükség).

Amennyiben a hosztingot a vendor biztosítja, úgy az ügyfeleknek lehetőségük van bizonyos mértékig kontrollálni a hoszting környezetet és a biztonsági beállításokat, de a fő felelősség a vendornál marad. 

Árazás 

Ebben a modellben az alapvető termék és szolgáltatások árazása standard és transzparens, de mivel itt még mindig találkozhatunk bizonyos rugalmassággal az egyedi igények kielégítésére, ezért vannak, illetve adott esetben felmerülhetnek egyedi költségek is. Az árazás alapvetően a felhasználás mértékéhez igazodik, amivel például a felhasználói szám, vagy az ügyfél részéről felmerülő költségek rugalmasan kezelhetők, szükség szerint alakíthatók és transzparensen kalkulálhatók. 

Ideális esetben ez a modell rövid- és hosszabb távon is magas értéket képes biztosítani

A "laza", SaaS szemléletű modell célja, hogy az értékteremtés nagy része az out-of-the-box termékhez kapcsolódjon, és csak minimális egyedi fejlesztésre legyen szükség a termékben – az optimum vagy a tökéletesség (kinek-kinek preferenciái szerint) eléréséhez.

Az ügyfelek számára azonnali értéket biztosít a standard funkcionalitás és a vendor támogatása, miközben a hosszútávú értékteremtéshez is hozzájárul a könnyű karbantarthatóság, és a relatíve egyszerű kompatibilitás a későbbi verziókkal (utóbbi minimalizálja a jövőbeni fejlesztési és karbantartási költségeket). 

A standardizált árazás és a skálázható hoszting megoldások vonzóvá teszik ezt a modellt a közepes méretű vállalatok számára, akik gyorsan szeretnék élvezni a SaaS megoldások előnyeit anélkül, hogy teljesen elköteleződnének a teljesen önkiszolgáló megoldások mellett.

3. Ízig-vérig SaaS, mindenki kedvence – standard, önkiszolgáló, skálázható

A 100%-ig SaaS szoftver az a modell, amelyet a szoftveripar "szent Gráljaként" is emlegethetünk. Mindenki ezt szeretné – ügyfél és vendor egyaránt. Miért? Mert mindkét fél számára egy ideális állapotot jelent, hiszen számottevő rugalmasságot, magas fokú árazási transzparenciát és skálázhatóságot biztosít - mind a szolgáltató, mind az ügyfél-előfizető számára.

Ebben a modellben a felhasználók teljes mértékben önkiszolgáló módon vehetik igénybe a szolgáltatást, ami azt jelenti, hogy minimális beavatkozásra van szükség a szolgáltató részéről mind a termék bevezetése, mind a használata során. 

A SaaS demokratizálja a 21. századi vállalkozást és minimalizálja a vendornak való kitettséget

A SaaS mint koncepció egyik legfontosabb jellemzője, hogy egy-egy termék – megfelelően átgondolt felhasználói utakkal – adott esetben egy egészen kicsi cég, vagy akár egyéni vállalkozás igényeit ugyanúgy képes kiszolgálni, mint egy multinacionális vállalatáét. Bár a gyakorlatban azért a KKV és a multi megkülönböztetés gyakran leképződik a SaaS világában is, ami többek között az árazásban jól megmutatkozhat, illetve már a vertikális SaaS megoldások is egyre gyakoribbak, amelyek nem mindenkit, hanem kifejezetten egy-egy iparág igényeit igyekeznek a lehető legjobban kiszolgálni.

Itt egyedi igények már egyáltalán nem léteznek?

Ezt azért így nem jelenthetjük ki, sőt: a fejlettebb önkiszolgáló SaaS szoftverek lehetőséget biztosítanak az ügyfelek számára, hogy javaslatokat tegyenek új funkciókra, vagy szavazzanak a termékfejlesztési ütemtervre. Ez biztosítja, hogy a szoftver folyamatosan fejlődjön és igazodjon a felhasználói igényekhez.

Bár a szoftver alapértelmezett beállításai azonnal használhatók, az ügyfelek könnyen testreszabhatják a szoftver egyes funkcióit saját igényeik szerint, anélkül, hogy mély technikai ismeretekre lenne szükségük ehhez. Mit jelent ez?

Itt is vannak ugyan kapcsolók és beállítások, amelyekkel a különböző funkciókat szabályozni lehet (feature flagek). Azonban ezek nagyon jól dokumentáltak és egyszerűek, így a felhasználók könnyen megtanulhatják a használatukat. Fontos különbség az előző modellhez képest, hogy ezek a beállítások nem arra szolgálnak, hogy egyedi, azaz csak bizonyos ügyfelek számára készült funkciókat kapcsoljanak ki vagy be, ehelyett általános funkciókat irányítanak, amelyek sokféle felhasználási módot lefednek. 

A bevezetés folyamata 

Az ügyfelek azonnal hozzáférhetnek a szolgáltatáshoz, miután előfizettek. Nincs várakozási idő a telepítésre vagy a beállításokra, így a szoftver használata szinte azonnal megkezdhető. Amennyiben igény mutatkozik rá, úgy többnyire ezekben az esetekben is igénybe vehető tanácsadó cégek szolgáltatása, akik segítik a szoftver funkcióinak minél gyorsabb és gördülékenyebb bevezetését. 

Új funkciók és verziófrissítések

A teljesen önkiszolgáló, skálázható SaaS szintjén a verziófrissítések automatikusan és problémamentesen futnak le az előfizetők programjaiban – nincs szükség professzionális szolgáltatásra, külön fejlesztésre. 

Hoszting 

Az ügyfelek bármikor, bárhonnan hozzáférhetnek a szoftverhez, és saját igényeik szerint állíthatják be azt. Nincs szükség arra, hogy a szolgáltató bevonásával végezzék el a konfigurációs vagy bevezetési feladatokat, ami gyorsabb és rugalmasabb megoldást biztosít.

A SaaS szolgáltatók gyakran használják a nagy felhőszolgáltatók infrastruktúráját, mint például az AWS, a Microsoft Azure vagy a Google Cloud Platform. Ezek a megoldások biztosítják a magas rendelkezésre állást, a biztonságot és a skálázhatóságot. Néhány nagyvállalati SaaS – pl. Atlassian JIRA Data Center – biztosít on-premise vagy ún. private cloud üzemeltetési lehetőséget is. 

Amennyiben saját SaaS szolgáltatásba vágunk bele, érdemes mérlegelni, valóban szükségünk van-e a legmagasabb szintű, TIER-1 Cloud szolgáltatásra, mivel ezek rendkívül költségesek lehetnek. Sok nagyvállalatot találunk – például a Dropbox és a Basecamp –, amelyek a költségek csökkentése érdekében saját adatközpontba költöztek. Kezdetben tehát célszerűbb lehet TIER-2 szolgáltatókban gondolkodni, mint például a Hetzner vagy a Digital Ocean, ezek ugyanis jóval kedvezőbb áron kínálnak megoldásokat.

Árazás

Az önkiszolgáló SaaS modell egyik legnagyobb előnye a teljesen standard, átlátható és felhasználáshoz igazodó árazási struktúra. Ez a megközelítés biztosítja, hogy az ügyfelek pontosan tudják, mire számíthatnak, és csak azért fizetnek, amit valóban használnak.

Átlátható

Az árazási struktúra teljesen átlátható, ami azt jelenti, hogy az ügyfelek pontosan látják, milyen szolgáltatásokért és funkciókért mennyit kell fizetniük. Nincsenek rejtett költségek vagy meglepetések.

Felhasználás alapú díjak

Az ügyfelek csak azért fizetnek, amit ténylegesen használnak. Ez a megközelítés különösen vonzó a kisebb vállalatok számára, akiknek nincs szükségük a teljes funkcionalitásra, de később skálázhatnak, ahogy növekednek.

A felhasználás – és így az árazás – számos adat alapján meghatározható: 

• a felhasználók számában (pl. Atlassian, JIRA)
• a tranzakciók számában (pl. RB2B.com)
• a bevétel mennyiségében (pl. Shopify, Stripe)
• vagy akár ezek kombinációjában is. 

Magasabb szintű csomagok

A standard csomagok mellett gyakran elérhetők magasabb szintű, prémium csomagok is, amelyek további funkciókat és szolgáltatásokat kínálnak. Ezek a csomagok gyakran tartalmaznak személyes konzultációs lehetőségeket is ("talk to us"), hogy az ügyfelek egyedi igényeikre szabott megoldásokat kaphassanak.

SaaS trendek és várakozások

A sok helyen emlegetett AI és gépi tanulás, valamint az egyre jobban integrálható és felhőalapú megoldások mellett jelenleg megfigyelhető, hogy egyre több vertikális SaaS megoldás jelenik meg a piacon.

Ezek célja nem az, hogy a lehető legnagyobb volumenű, legkülönbözőbb tevékenységi körű céget szolgálják ki, hanem hogy egy bizonyos szektornak vagy iparágnak adjanak olyan specifikus megoldásokat, amelyekre kifejezetten nekik van szükségük. Ez egyben azt is jelenti, hogy azok az iparágak, amelyekben a SaaS első, horizontális köre nem volt elég “egyedi”, hamarosan sokkal kevesebb egyedi fejlesztésű szoftveres megoldást fognak igénybe venni. 

Ugyanezt a tendenciát erősítik – csak éppen a “generalista” szinten – a “no-code”/”low-code” platformok is, amelyek célja, hogy minimális technikai ismerettel egyre összetettebb applikációkat tehessenek össze maguknak a felhasználók. Ezek tipikusan az olcsóbb, és a “mindenki” számára elérhető megoldások piacát erősítik. 

Több szempontból is látszik tehát, hogy a jövő az egyre kevesebb egyedi és az egyre inkább rugalmas, skálázható megoldások felé mutat a szoftverek piacán is – mindezzel együtt nagy valószínűséggel mindig lesznek olyan esetek, amikor az egyedi fejlesztés és a vendorral való hosszútávú együttműködés hatékonyabb, mint egy teljesen SaaS megoldás. 

A fenti szempontok ismeretében az üzleti döntéshozók jobban tudnak mérlegelni, a helyes kérdéseket tudják megfogalmazni egy-egy hosszútávú elköteleződést megelőzően.